mosaicstack/stack
1
0
Fork 0
Code Issues 42 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

brief: Decision #3 RATIFIED (Option A) + owner flexibility amendment (configurable recovery posture)

Browse Source
This commit is contained in:
homelab mos-comms
2026-07-13 16:39:21 -05:00
parent f4eb75dc6b
commit 32443452fa
1 changed files with 22 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
briefs/DECISION-BRIEF-KANBAN-SOT-D3.md
View File

@@ -62,3 +62,25 @@ Read-only `TASKS.md` exports remain useful for situational awareness and inciden
- **Risk: Longhorn loss exceeds local recovery assumptions.** Mitigation: treat Longhorn as an availability layer, not the only recovery layer; restore from external PostgreSQL backups/WAL to clean storage. - **Risk: Longhorn loss exceeds local recovery assumptions.** Mitigation: treat Longhorn as an availability layer, not the only recovery layer; restore from external PostgreSQL backups/WAL to clean storage.
- **Risk: stale read-only exports mislead operators.** Mitigation: include generated-at timestamp, source commit/checksum, and visible `READ ONLY / NOT AUTHORITATIVE` labeling; alert on export staleness. - **Risk: stale read-only exports mislead operators.** Mitigation: include generated-at timestamp, source commit/checksum, and visible `READ ONLY / NOT AUTHORITATIVE` labeling; alert on export staleness.
- **Risk: manual emergency database changes weaken the audit trail.** Mitigation: time-box break-glass access, require incident ID and SQL/audit capture, use peer review after restoration, and regenerate exports immediately after validation. - **Risk: manual emergency database changes weaken the audit trail.** Mitigation: time-box break-glass access, require incident ID and SQL/audit capture, use peer review after restoration, and regenerate exports immediately after validation.
---
## OWNER RATIFICATION + FLEXIBILITY AMENDMENT (Jason, 2026-07-13)
Decision #3 is **RATIFIED: adopt Option A.** Amendment for multi-tenant reality — the recovery *posture* must be per-deployment configurable so simpler/single-user installs are not forced into USC's high-assurance targets. The core safety invariant is unchanged.
### FIXED INVARIANTS (non-negotiable safety guarantees; NOT configurable)
1. PostgreSQL is the sole writable SOT.
2. Mutations FAIL CLOSED when write-health cannot be proven — never diverted to a writable file. (This is the anti-split-brain guarantee.)
3. Read-only exports (`TASKS.md` etc.) are non-authoritative and are NEVER an import/recovery source.
4. Out-of-band human notes are post-recovery PROPOSALS, never shadow Kanban state.
### PER-DEPLOYMENT CONFIGURABLE (recovery posture — tune to user need)
RPO/RTO targets · WAL archive cadence · PITR retention window · base-backup cadence + retention tiers · read-only export cadence · restore-test / break-glass drill frequency · backup storage location & failure-domain policy.
### Suggested default profiles
- **Lite (single-user default):** nightly logical backup, no external object storage required, PITR optional/short, manual restore. Minimal ops burden.
- **Standard:** daily base backup + WAL to external storage, ~7-day PITR, quarterly restore test.
- **High-assurance (USC profile):** RPO 15m / RTO 4h, ≤5-min WAL off-Longhorn/off-cluster, 35-day PITR, monthly restore test + quarterly break-glass.
The invariants hold in every profile; only the recovery-posture knobs vary. **Build hold LIFTS.**