Storing decisions and components as nodes with real edges is what makes analyze useful: PageRank over a component graph tells you what matters, and connected-component detection tells you what has drifted apart. Optimisation is the risky operation, so it takes a snapshot before it runs and rollback restores the previous state; the conservative strategy caps deletions and uses a six-month staleness threshold.
A memory bank stored in a KùzuDB graph database. Entities and relationships are keyed so that each repository and branch gets its own view of a shared bank, and graph algorithms run over the result.
- memory-bank — initialise and manage the bank's metadata for a repository and branch
- entity — create, update, delete and retrieve every entity type: components, decisions, rules, files and tags
- associate — create relationships between entities
- query — one search across contexts, entities, relationships, dependencies, governance, history and tags
- search — full-text search over all entity types, backed by KuzuDB's FTS
- introspect — explore the graph schema and metadata
- context — manage the working context of a session
- analyze — run graph algorithms over a projected graph: PageRank, K-Core, Louvain and shortest path
- detect — find strongly and weakly connected components
- bulk-import — load entities in bulk
- delete — remove entities with dependency validation, including bulk deletes
- memory-optimizer — analyse the graph, preview an optimisation as a dry run, execute it with an automatic snapshot, list snapshots and roll back
Node.js with the project cloned and built. Configuration goes in a .env file: DB_FILENAME for the graph file, HTTP_STREAM_PORT and HOST for the HTTP stream server. The memory-optimizer needs a reasoning model — OPENAI_API_KEY or ANTHROPIC_API_KEY — and is the only part that does; everything else runs locally.