Keep the project knowledge graph in memory up to date after code changes. MUST trigger at the END of any session or task where you modified files under src/, especially src/engines/, src/stores/, src/db/, src/hooks/, src/components/, src/services/, src/types/, src/pages/, or src/config/. Also trigger when the user says "update the project graph", "refresh architecture", "rescan the project", or anything about keeping project knowledge current. This is a post-task housekeeping step — run it after your main work is done, not before.
You maintain a layered knowledge graph of the Writers Hoard codebase in memory files. After making code changes, check whether those changes affect the knowledge graph and update it if they do. This keeps future sessions from working with stale context.
Three memory files at /sessions/festive-cool-keller/mnt/.auto-memory/:
| File | What it tracks |
|---|---|
project_architecture.md | Tech stack, app structure, routing, stores, database schema (table list), services, hooks, shared layer, engine system overview, project modes |
project_engine_catalog.md | All engines profiled: purpose, key files, hooks used, maturity status (complete vs WIP) |
MEMORY.md | Index pointing to these files (keep in sync) |
After completing your main task, check: did any of your changes touch these areas?
Architecture map triggers:
src/stores/src/db/src/hooks/src/services/src/pages/ or App.tsxpackage.jsonsrc/config/src/shared/src/types/index.ts (new domain types)Engine catalog triggers:
src/engines/*/src/engines/_registry.tsIf none of these were touched, skip the update. Don't rescan just because you edited a CSS class.
Read project_architecture.md and/or project_engine_catalog.md — whichever is relevant to your changes.
Compare what the memory file says against what you just changed. You know exactly which files you touched and what the diff was — use that, not guesses.
Use the Edit tool to make targeted updates. Common patterns:
project_engine_catalog.md following the existing format. Update the engine count in project_architecture.md. If it changed project mode presets, update those too.project_architecture.md under the Database section.project_architecture.md.project_engine_catalog.md, update its status and file list, adjust the migration pattern note.If you changed the engine count or any description in the index entries, update MEMORY.md to match.
These rules exist because past updates introduced subtle errors that compounded over time.
Every piece of information you add to the knowledge graph must come from the actual code change you just made. If the prompt says "added a research engine with useResearchSessions and useResearchNotes hooks", those are the only details you know about that engine. Do not invent additional details like what database tables it uses, what its UI looks like, or what its "purpose" is beyond what's directly stated. A brief, factual profile based on what you know is far better than a rich-sounding one that's partly fabricated.
If you changed the DB schema but not any engines, do not edit project_engine_catalog.md at all. If you added an engine but didn't change the DB schema, don't modify the Database section. Each memory file section is independent — only edit sections directly affected by what you changed.
When updating counts (engine totals, table counts, hook counts), count the actual items listed in the file after your edit. Don't do mental math like "it was 14, I added 1, so it's 15" — off-by-one errors compound. After editing, recount the list and use that number.
The knowledge graph is a reference document, not a changelog. When you remove a hook from the central hooks list because it moved into an engine, just remove it — don't add "(moved to X engine)" or "Note: this was migrated." When you update an engine's status from WIP to Complete, just write "Complete" — don't add "Migrated from thin wrapper" or similar. If someone reads the file cold, they should see the current state, not a narrative of what changed. Every parenthetical note, migration comment, or explanatory aside you're tempted to add — delete it.
Match the heading levels, bold labels, spacing, and structure of the existing entries. Don't introduce new sections (like "Cross-Cutting Hooks") unless the change genuinely requires a new category. When adding an engine profile, copy the format of an adjacent entry.
If the user explicitly asks for a full rescan ("rescan the project", "rebuild the knowledge graph"), then do a comprehensive pass: