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

1.0 KiB

Raw Blame History

ADR-031: moduleToDbSchema() for schema updates, not Value.Patch

Status

Accepted

Context

When a graph type Module changes, the stored schema in node_types.schema must be updated. This could be done by patching the stored schema with Value.Patch or by re-running moduleToDbSchema() on the full Module.

Decision

Re-run moduleToDbSchema() on the updated Module. Patch-based schema update (Value.Patch) is unreliable for Type.Ref/$defs changes — the diff is structural, not semantic, and may not capture $defs reorganization correctly. moduleToDbSchema() is more reliable because it always produces a fresh, complete projection.

Patch-based schema update is an optimization for later.

Consequences

Schema updates always go through moduleToDbSchema()
The full Module must be available at migration time
No risk of partial/partially-correct patches from Value.Diff
Patch-based update can be added as an optimization if needed

References

schema-evolution.md

1.0 KiB Raw Blame History