Clean up architecture specs: remove stale references, align docs with code, improve readability
- Replace stale DD references (DD3, DD6, DD9, DD10) with proper ADR links - Fix 'Open Question 1' → OQ-01/OQ-03 cross-references - Rewrite metagraph-module.md 'Why TypeBox Modules' to describe capabilities directly instead of framing as SchemaBuilder replacement - Remove 'Transition from SchemaBuilder' section, replace with Source Structure - Clean up implementation path: strikethrough phases → status table - Fix data model diagram: remove non-existent nodeTypeId, fix EdgeType label - Align EdgeConstraints examples with actual code (add default values) - Clarify validateNode/validateEdge error behavior in docs - Align EncryptedDataSchema code example with actual implementation - Fix overview.md: correct dependency table, update current state, fix TypeBox URL - Fix forward-look.md garbled text about dbtype element migration - Fix open-questions.md: correct OQ count (4→7 open), add summary table - Update doc statuses: schema-evolution, encrypted-data, open-questions → reviewed - Update AGENTS.md to reflect current implementation state
This commit is contained in:
@@ -7,9 +7,10 @@ last_updated: 2026-05-30
|
||||
|
||||
How the Module-based metagraph connects to the broader @alkdev ecosystem —
|
||||
typed graph pointers, dbtype table rendering, and the ujsx universal IR
|
||||
pipeline. These are forward-looking designs that justify why certain
|
||||
structural decisions are made now (DD9, DD10 in
|
||||
[metagraph-module.md](./metagraph-module.md)).
|
||||
pipeline. These are forward-looking designs that justify why certain structural
|
||||
decisions were made now
|
||||
(pointer abstraction deferred per [ADR-017](./decisions/017-pointer-abstraction-is-forward-looking.md),
|
||||
dbtype integration deferred per [ADR-018](./decisions/018-dbtype-integration-is-post-v1.md)).
|
||||
|
||||
## Overview
|
||||
|
||||
@@ -163,9 +164,10 @@ integration is deferred because:
|
||||
- The Module pattern for graph types can be adopted independently (no dbtype
|
||||
dependency)
|
||||
|
||||
When dbtype reaches Phase 1 (implementation), storage can adopt dbtype element
|
||||
to dbtype elements one table at a time. The Module-based graph type definitions
|
||||
are already compatible — they're both TypeBox `Type.Module` objects.
|
||||
When dbtype reaches Phase 1 (implementation), storage can migrate from
|
||||
Drizzle table definitions to dbtype elements one table at a time. The
|
||||
Module-based graph type definitions are already compatible — they're both
|
||||
TypeBox `Type.Module` objects.
|
||||
|
||||
## ujsx as Universal IR
|
||||
|
||||
@@ -209,7 +211,10 @@ Rendered to different hosts:
|
||||
|
||||
| Capability | Status |
|
||||
|-----------|--------|
|
||||
| `Type.Module` for graph type definitions | ✅ Ready to implement now |
|
||||
| `Type.Module` for graph type definitions | ✅ Implemented — Metagraph, CallGraph, SecretGraph Modules |
|
||||
| Bridge functions (`moduleToDbSchema`, `validateNode`, `validateEdge`) | ✅ Implemented |
|
||||
| Reference graph type Modules (CallGraph, SecretGraph) | ✅ Implemented |
|
||||
| Crypto utility (`encrypt`, `decrypt`, `generateEncryptionKey`, `EncryptedDataSchema`) | ✅ Implemented |
|
||||
| Codegen from TypeScript interfaces → Module entries | ✅ TsToModule exists |
|
||||
| dbtype element trees → Drizzle tables | ⚠️ dbtype Phase 0, no implementation |
|
||||
| `<graphSchema>` ujsx elements | ⚠️ Conceptual — needs HostConfig design |
|
||||
|
||||
Reference in New Issue
Block a user