The monolithic open-questions.md (1310 lines, 47 OQs) was large enough to be unmanageable, with high size variance (OQ-42 at 220 lines next to OQ-06 at 8). Decomposed into one file per OQ under docs/architecture/questions/ (NNN-slug.md, mirroring the ADR convention), with open-questions.md retained as the index: theme-grouped tables plus a cross-theme Deferred/Blocked section that surfaces the 6 deferred OQs with their Blocked-on conditions inline (the safe-exit visibility surface). Per-OQ content moved verbatim; all 62 inbound links stay valid (none used anchors). README's curated OQ summary dropped (now redundant with the index tables). Also seeds tasks/architecture/ with this task plus two follow-ups found during the decompose: OQ-09/10 missing structured Blocked-on fields, and the tasks/architecture/ blocker-task half of the Safe Exit protocol being unenforced.
985 B
985 B
OQ-22: Key Rotation Mechanism
- Origin: encryption.md
- Status: resolved
- Door type: One-way (path scheme), two-way (rotation policy)
- Priority: medium
- Resolution: Key rotation uses version-indexed derivation paths. Each key version maps to a distinct SLIP-0010 path:
m/74'/2'/0'/{version-2}'. v2 (current) is atm/74'/2'/0'/0'; v3 is atm/74'/2'/0'/1'; etc. Thedecryptmethod derives the key at the path indicated byencrypted.key_version(not always atPATHS::ENCRYPTION). Therotatemethod decrypts with the old version's key and re-encrypts with the new version's key — no new mnemonic needed. The assembly layer or a migration tool iterates stored blobs and callsrotateon each; the vault does not self-rotate. Partial rotation is safe (old keys remain derivable). See ADR-021. - Cross-references: ADR-020, ADR-021, encryption.md, service.md