Files

glm-5.1 67ccfbf928 docs: restructure architecture docs to flowgraph pattern

- Create decisions/ directory with 32 numbered ADRs (ADR-001 through ADR-032)
  extracted from inline DD/SD/ED/SE decision sections
- Create open-questions.md with 16 OQs organized by theme, cross-referenced
  to ADRs, with status tracking (resolved/open)
- Create README.md as architecture index with doc table, ADR table, and
  lifecycle status definitions (draft/reviewed/stable/deprecated)
- Replace inline decision sections in all spec docs with ADR reference tables
- Replace inline open questions with OQ references to centralized tracker
- Update frontmatter: metagraph-module.md, overview.md, sqlite-host.md → reviewed;
  schema-evolution.md and encrypted-data.md remain draft
- DD1-DD10 → ADR-009 through ADR-018
- D1-D8 → ADR-001 through ADR-008
- SD1-SD5 → ADR-019 through ADR-023 (SD5 folded into ADR-006/008)
- ED1-ED5 → ADR-023 through ADR-027
- SE1-SE5 → ADR-028 through ADR-032

2026-05-29 07:19:03 +00:00

948 B

Raw Blame History

ADR-026: Application-managed key ring

Status

Accepted

Context

Encryption keys need management — storage, rotation, version tracking. The storage package could manage key rings internally or leave this to the consuming application.

Decision

The storage package provides encrypt(), decrypt(), and generateEncryptionKey() but does NOT manage the key ring. The consuming application stores keys in a secure location, loads them at startup, and passes the appropriate key based on keyVersion. Key rotation (decrypt with old key, re-encrypt with current key) is an application-level workflow.

Consequences

Storage package doesn't need to know about deployment infrastructure
Key management policies are application-specific
Encryption primitives are testable without a key ring implementation
Key rotation is an application concern, not a storage concern

References

encrypted-data.md

948 B Raw Blame History