vh
a4cf2ba0dc
Two additions, both from a 2026-09-22 exchange with svos-dev. THE RULE. Coverage is a property of the backup SYSTEM, not of one job's configured scope. A peer checked dev-backup.sh, found SRC=$HOME/development, and reported to the operator -- with specifics and unhedged -- that five home-directory paths including Miranda's entire conversation had never been backed up anywhere. All five were in that night's restic snapshot. dev-backup is the hourly job for one directory; resticprofile is the daily job covering all of /home/lkraven. Checking one job and generalising to the system produced a confident, false, escalated claim. The runbook now carries the query that answers the question properly. THE GAP THAT VERIFYING IT EXPOSED, and it is worse. grep -ic restic against scripts/backup-freshness-alert.sh returns 0. The checker inspects PBS guest ages and pings the rest-servers for liveness -- which confirms the server answers, not that a snapshot was written. If resticprofile stopped entirely the light would stay green, correctly by its own definition, forever. Restic holds the whole home directory; PBS holds VM images. The layer with the granular data is the unwatched one, and the light is not merely blind but actively reassuring about a system it cannot see. Recorded as an open gap rather than patched, because fixing it changes what an existing green light means and people have been reading that light for months.
docs/
Navigation map for the documentation tree. New session? Read
orientation.md first — it's the narrative overview
of the fleet, backup architecture, governing principles, and gotchas,
and it points at everything else.
Tree
docs/
├── orientation.md # start here — fleet overview + where-to-look guide
├── runbooks/ # ops runbooks (recovery, deployment phases)
│ ├── disaster-recovery.md
│ ├── nh3-prune-ritual.md
│ └── pbs-deployment.md
└── pfi/ # PFI-specific reference (services, models, VMs)
├── docker-stack.md
├── model-list.md
├── proxmox-vms.md
├── recommended-model-settings.md
├── vm-102-matrix-appservice.md
└── vm-102-matrix-synapse.md
What goes where
runbooks/— step-by-step ops procedures. Anything you'd reach for during an incident or while standing up new infrastructure. Examples: disaster recovery (blast-radius tiers + restoration steps), PBS deployment (9-phase rollout). New runbook → new file here.pfi/— PFI-specific reference material that's too narrow for the top-level CLAUDE.md but doesn't change incident response. AI model inventory, recommended inference settings, Matrix bridge config, Proxmox VM map. New stable reference → new file here.- Top-level (
docs/orientation.md,docs/README.md) — narrative guides about the workspace itself, not about specific infra.
Cross-references
- Fleet topology + servers table: top-level
CLAUDE.md. - Open work + recent milestones: top-level
STATUS.md. - Durable cross-session facts:
~/.claude/projects/-home-lkraven-development-eshpfi-management/memory/.
Conventions
- Markdown, GitHub-flavored. CommonMark renders fine in most viewers.
- File names are lowercase-kebab-case, descriptive. No dates in filenames — git history covers that.
- One topic per file. If a file grows past ~500 lines, look for a natural split before adding more.
- No checked-in binaries or checksums. Build/release artifacts belong
in a build pipeline or
tools/, notdocs/.