From 168acf43004e6da6ceb9e499063e63fefe3ba68a Mon Sep 17 00:00:00 2001 From: Serkyo Date: Sat, 27 Jun 2026 22:58:27 +0200 Subject: [PATCH] docs(workspace): require graph refresh after large features --- AGENTS.md | 6 ++++++ CLAUDE.md | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 4111d04..6f4f52c 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -128,6 +128,12 @@ Then follow this loop on every step: Each verified step gets its own commit. This keeps history aligned with the teaching cadence: every commit corresponds to a concept the user has actually understood and produced working code for. Do not batch multiple verified steps into one commit, and do not move on to the next instruction without committing the previous one. +### Refresh the knowledge graph after every large feature + +After a large feature is complete and merged back into `dev` (not after every individual step-commit), refresh the graphify knowledge graph so it reflects the new architecture. The post-commit hook keeps the *code* side of `graphify-out/` current on each commit, but it runs AST-only and never re-runs semantic extraction on changed Markdown/YAML design notes. A full `/graphify . --update` is therefore required to bring the documentation and cross-system edges back in sync. + +Run `/graphify . --update` yourself once the feature is verified and committed, or — if the graph build is not desired inline — explicitly tell the user to run it before they move on. Do not silently skip it: a stale graph misleads later architecture questions. + ## Concurrency model The game is **multithreaded by design** — single-threaded would not meet the perf budget for voxel meshing, worldgen, rendering, networking, and simulation running together. Code should assume multiple threads and design data ownership accordingly: diff --git a/CLAUDE.md b/CLAUDE.md index 39bdab3..03544b7 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -128,6 +128,12 @@ Then follow this loop on every step: Each verified step gets its own commit. This keeps history aligned with the teaching cadence: every commit corresponds to a concept the user has actually understood and produced working code for. Do not batch multiple verified steps into one commit, and do not move on to the next instruction without committing the previous one. +### Refresh the knowledge graph after every large feature + +After a large feature is complete and merged back into `dev` (not after every individual step-commit), refresh the graphify knowledge graph so it reflects the new architecture. The post-commit hook keeps the *code* side of `graphify-out/` current on each commit, but it runs AST-only and never re-runs semantic extraction on changed Markdown/YAML design notes. A full `/graphify . --update` is therefore required to bring the documentation and cross-system edges back in sync. + +Run `/graphify . --update` yourself once the feature is verified and committed, or — if the graph build is not desired inline — explicitly tell the user to run it before they move on. Do not silently skip it: a stale graph misleads later architecture questions. + ## Concurrency model The game is **multithreaded by design** — single-threaded would not meet the perf budget for voxel meshing, worldgen, rendering, networking, and simulation running together. Code should assume multiple threads and design data ownership accordingly: