- 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
1.1 KiB
1.1 KiB
ADR-012: Node/edge attribute schemas are Module entries, not Type.Any()
Status
Accepted
Context
At the DB storage layer, node/edge attribute schemas are arbitrary JSON Schema blobs (Type.Unknown()). But at the application layer, graph type definitions should have full type safety for their attribute schemas.
Decision
At the application layer, node and edge attribute schemas are named Module entries with full type safety (CallGraph.CallNode, not schema: Type.Any()). At the DB storage layer, the meta-schemas (NodeType, EdgeType) still have schema: Type.Unknown() because the DB stores arbitrary JSON Schema blobs. The repository layer maps between the two: Module entries are the application-level validation, the DB is the persistence layer.
Consequences
- Compile-time type safety for graph type definitions
- Runtime validation via
Value.Check(Module.EntryName, data) - DB layer remains generic — any JSON Schema blob is accepted for storage
- Validation boundary is the repository layer, not the database