glm-5.1
bde1cc4e70
The 751-line architecture.md violated the SDD process modular documentation target (~500 lines). It also had duplicate TaskGraph class definitions (one monolith, one decomposed) that directly contradicted each other, and embedded consumer-specific tool dispatch mappings that belong in downstream projects. Changes: - Split into 8 focused documents + 7 ADR records + redirect page - Removed the monolithic TaskGraph class (kept only decomposed version) - Moved CLI→plugin dispatch mapping out (belongs in plugin architecture) - Extracted implementation code (frontmatter splitter, findCycles, DAG propagation) into WHAT/WHY descriptions per architect role spec - Added proper ADR format for all resolved design decisions - Fixed review issues: C_fail mapping, DuplicateNodeError/DuplicateEdgeError types, ValidationError/GraphValidationError definitions, mutation error handling contract, enum naming convention, validation timing clarification
26 lines
1.2 KiB
Markdown
26 lines
1.2 KiB
Markdown
# ADR-002: Rebuild graph on change, not incremental updates
|
||
|
||
**Status**: Accepted
|
||
|
||
## Context
|
||
|
||
When task data changes (file edits, DB updates), the in-memory graph needs to reflect the new state. Two approaches: incremental updates (add/remove individual nodes/edges) or full rebuild from source data.
|
||
|
||
## Decision
|
||
|
||
**Rebuild.** For our graph sizes (10–200 nodes), `graph.import()` from a serialized blob is sub-millisecond. Both consumers (alkhub builds from DB query results; OpenCode plugin rebuilds from directory on file change) are well-served by rebuild.
|
||
|
||
## Consequences
|
||
|
||
### Positive
|
||
- No change-detection layer needed — no tracking ID renames, dependency removals, edge reconciliation
|
||
- Simpler codebase — no diff algorithm, no incremental update logic
|
||
- Always consistent — rebuild guarantees the graph matches the source data exactly
|
||
|
||
### Negative
|
||
- Technically wasteful for small changes (rebuilding entire graph when one task changed)
|
||
- Not suitable for very large graphs or extremely frequent updates
|
||
|
||
### Mitigation
|
||
|
||
If a future use case requires incremental updates, add it as an optimization then. The API surface (construction methods) supports both patterns — incremental construction exists via `addTask`/`addDependency`. |