feat: Worker portal Stage 2 ADR — composition override storage layering
Description
Ratify the storage layering architecture for composition overrides as an ADR before any Stage 3 runtime code lands. This ADR defines the DB schema for the three override layers, layer precedence rules, live-override lifecycle, and idempotent baseline reset semantics. ADR-only — no runtime code.
The five-layer storage model is top-wins:
- User personal layout (DB JSONB delta)
- Role overrides (DB)
- Jurisdiction live overrides (DB)
- Jurisdiction baseline (TOML on disk, in git)
- System defaults (bundled with binary)
Acceptance Criteria
-
docs/modules/ROOT/pages/adrs/adr-NNN-composition-override-storage-layering.adoc - ADR documents:
- DB schema: per-layer tables vs unified
config_documentswith(jurisdiction, layer, key)index — decision + rationale - Layer precedence rules (top-wins, formal merge semantics for JSONB deltas vs full documents)
- Live-override lifecycle: create → edit → promote → archive
- Idempotent baseline reset: how a worker reverts to "jurisdiction baseline" cleanly
- Audit obligations: every override mutation is a JWS-signed
AuditEvent(consistent with ADR-014) - Forward-only migration shape (ADR-016 compliant)
- DB schema: per-layer tables vs unified
- Antora nav updated
- Cross-referenced from worker-portal-redesign.adoc Design section
-
cargo xtask check-docsclean
Open questions (resolve in ADR)
- Per-layer table vs unified
config_documents? Plan flags both; pick one with rationale. - JSONB delta merge semantics: full document replace vs RFC 7396 (JSON Merge Patch) vs RFC 6902 (JSON Patch)?
- Audit retention per layer: 7yr case actions vs 1yr auth events vs per-jurisdiction override? (See #460 open question 5.)
Context & References
- Tracking issue: #460
- Epic: &51
- Plan: worker-portal-redesign.adoc, Stage 2
- Blocks: Stage 3 child issues
- Related: ADR-016 (forward-only migrations), ADR-014 (FTI audit hash-chain)
Labels
type::feature, priority::medium, program::infrastructure, service::web, workflow::ready