glm-5.1
e592caed57
Review of all ADR documents (001-007) and peripheral architecture docs identified 3 critical, 10 warning, and 7 suggestion issues. Addressed in this commit: - W-1: Add draft qualifier to ADR-002 reference to incremental exploration - W-2: Add Alternatives Considered section to ADR-001 - W-3: Add Document Lifecycle section to README.md (draft/stable/deprecated) - W-4: Clarify includeCompleted semantics (only 'completed' status triggers exclusion) - W-5: Document file I/O runtime constraints in frontmatter.md - W-6: Add ADR reference to architecture.md redirect - W-7: Verify CVE-2025-64718 (confirmed real, improved description) - W-9: Convert workspace-absolute paths to relative/monorepo references - S-7: Add future ADR-008 note to incremental-update-exploration.md Critical issues (C-1, C-2, C-3) and remaining warnings (W-8, W-10, S-4, S-5) were addressed by a parallel agent in a prior commit. All 16 review tasks created and resolved.
1.8 KiB
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.
An incremental update architecture has been explored (draft, not yet a decision) in incremental-update-exploration.md. The key finding is that the win is reactivity (fine-grained event notifications), not performance. For <200 node graphs, rebuild is always sub-millisecond. If a consumer needs reactive updates, they can use graphology's event system directly via graph.raw and implement change detection at the consumer layer, without the library taking on the complexity of diff-based updates.