- 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
25 lines
1023 B
Markdown
25 lines
1023 B
Markdown
# ADR-013: Storage produces graphology format, flowgraph consumes it
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
Graph data needs to flow between storage (persistence) and flowgraph (in-memory operations). The question is whether storage should depend on graphology directly.
|
|
|
|
## Decision
|
|
|
|
Storage doesn't need a graphology dependency. It produces the JSON serialization format (`SerializedGraph`) that `@alkdev/flowgraph`'s `FlowGraph.fromJSON()` and `SerializedGraph` consume. The Module entries validate data flowing in both directions. Storage defines the data shapes; flowgraph operates on them in memory.
|
|
|
|
## Consequences
|
|
|
|
- `@alkdev/storage` has zero dependency on graphology
|
|
- The `SerializedGraph` factory signature stays the same — its schema arguments come from Module entries instead of standalone schemas
|
|
- Storage produces format, flowgraph consumes format
|
|
- `moduleToGraphology()` and `fromGraphologyExport()` bridge functions will be added in Phase 4
|
|
|
|
## References
|
|
|
|
- [metagraph-module.md](../metagraph-module.md)
|