nimmo/nixos-config
nimmo/nixos-config
Watch
1
0
Fork
You've already forked nixos-config
 0
Code Issues 15 Pull requests Wiki Activity Actions
Page: 00 Documentation Map and Scope
Pages
00 Documentation Map and Scope 00 Documentation Standards 00 Start Here and Governance 10 System Atlas 11 Fleet Overview 12 Host Inventory 13 Service Catalogue 14 Network and Access Topology 15 Storage and Data Map 16 Automation and Control Plane 20 Architecture Decisions 21 ADR 001 Electra Hardware Specialisations 22 ADR 002 Workload Placement 23 ADR 003 Network Exposure 23 Project Tracking 24 ADR 004 Engram Durable Agent Memory 24 Security Baseline 25 ADR 005 Auto Update Control Plane 26 ADR 006 Scoped Secret Files 30 Operations and Runbooks 31 Routine Fleet Operations 32 Safe Testing and Deployment 33 Host Provisioning 34 Monitoring and Service Investigation 35 Backup Verification and Partial Restore 36 Full Host Recovery 37 Electra Boot Trust Recovery 38 Secret Editing and Recipient Rotation 39 Auto Update Incident Response 39a Service Migration and Cutover 39b Wrapper Repository Packaging 40 Engineering Handbook 41 Repository Structure and Import Chain 42 Configuration Ownership Boundaries 43 Adding Packages and Flake Inputs 44 Adding a Module or Profile 45 Adding a Host 46 Adding or Migrating a Service 47 Testing and CI Contracts 48 Secrets Implementation Conventions 49 Documentation Maintenance 50 NixOS Learning Path 51 Guided Repository Tour 52 Nix Language Essentials 53 Declarative Configuration Store and Generations 54 Flakes and Inputs 55 NixOS Modules and Option Merging 56 SpecialArgs and Home Manager Argument Flow 57 Electra Specialisations Worked Example 58 Nix Troubleshooting Primer 90 Historical Material 91 Electra Secure Boot Hardening Record Home
4 00 Documentation Map and Scope
Nimmo edited this page 2026-09-14 07:42:33 +01:00
Table of contents

Documentation Map and Scope

  • Type: Policy
  • Status: Current
  • Scope: Project documentation
  • Canonical sources: AGENTS.md; README.md; .agents/skills/update-wiki/SKILL.md; wiki rebuild issue #219
  • Last verified: Source commit ef4ae2ce2f1b3fd8fc22262ded9c2374ac78c6ef (2026-09-14); wiki ownership and navigation audited 2026-09-14
  • Review triggers: Changes to project tracking, agent memory, project-report publishing, README scope, or wiki governance

Each project surface owns a different kind of truth. Keeping those boundaries clear prevents the wiki from becoming a stale copy of the repository or a second issue tracker.

Ownership

Surface Owns Does not own
nixos-config repository Executable configuration, tests, scripts, and implementation-adjacent contracts Narrative operating history or active project plans
README.md Entry point, essential commands, concise repository map, and links onward A second comprehensive manual or service catalogue
Forgejo issues and milestones Proposed and active work, ordered checklists, decisions pending implementation, progress, and acceptance evidence Permanent operating instructions after work closes
Repository wiki Curated system reference, policy, decisions, runbooks, engineering guidance, and repository-oriented learning Live work state, raw logs, or copied configuration inventories
BookStack Project Logs Chronological generated reports and historical project activity Canonical current-state reference or execution tracking
Engram Confirmed cross-session agent context, non-obvious discoveries, preferences, and concise outcomes; see ADR-004 Canonical documentation or the sole record of unfinished work
Git history Superseded wiki content and change provenance A convenient current navigation surface

Promotion lifecycle

  1. Plan and execute work in a Forgejo issue under an appropriate milestone.
  2. Record progress and validation in the issue while the work remains active.
  3. Implement authoritative behavior in the repository.
  4. Promote reusable knowledge into the appropriate wiki page.
  5. Preserve consequential rationale as an ADR when future maintainers need to understand the choice.
  6. Close the issue only after unfinished work remains tracked and durable knowledge has an appropriate home.

Raw session logs and one-off diagnostic output should normally be retired, not promoted. Engram can preserve a confirmed non-obvious fact until it becomes important enough to document canonically.

Cutover boundary

The former wiki combined an operating manual, repository reference, and NixOS course. Its reusable material now has separate current reference, runbook, handbook, decision, and learning owners. Superseded chapters are absent from current navigation and retained in wiki Git history. The Electra boot-trust rollout record remains visible only under Historical Material. Each current page identifies its own canonical sources, verification revision, and review triggers; the Home page does not assert wiki-wide source freshness.