mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 12:47:04 +00:00
kevinveenbirkenbachandClaude Opus 5
c9d8e85567
The role README claimed the backup machinery "operates transparently against the mount paths" and demoted the source-of-truth rule to advice in a prose box - both written before 2efc73d3b made that rule the code's behaviour. It now states what is enforced: this role skips export-backed volumes, svc-bkp-nfs-2-local is their single capture, and manager-pinned roles, roles forcing another compose_mode_force and nfs: false opt-outs stay covered here. It also names the limit the code actually has - the exclusion checks that some host is in the svc-bkp-nfs-2-local inventory group, not that the role ever ran successfully - because a README promising more than the code delivers is worse than one promising less. Its Schema section carried the role's timer flow; it now carries the mechanism the change set is about: meta/volumes.yml -> swarm_nfs_backed() as the single predicate -> its two consumers (the compose rewrite and the backup exclusion) -> the inventory-group gate -> the export host's single capture -> the restore path with its mountpoint probe -> the drill's [3b] guard against over-exclusion. The two swarm READMEs drew the drill with eight steps and pre-773a25ab6 semantics. Both now draw the nine that exist, including what makes the proof a proof: the pulled tree is wiped before the device recover, so the device holds the only copy left; the live export is wiped with the marker proven gone before it is restored; and [9] deletes the marker server-side before restoring the volume through its bound backing store. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Test Utilities 🧪
This directory holds the operational side of testing in Infinito.Nexus.
These assets are meant to support confidence, not ceremony. They help the project validate real-world behavior across local development, CI environments, and deployment-oriented smoke tests. The emphasis is on practical feedback: when something breaks, the surrounding test tooling should make the failure easier to understand, easier to reproduce, and easier to clean up. 🚀
Good changes in this area usually make the test experience more:
- repeatable
- diagnosable
- environment-aware
- safe to rerun
The ideal outcome is boring reliability: contributors should be able to trust that a test run says something meaningful about the system, not just about the machine that happened to execute it. ✅