Synvael/synvael
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

docs(workspace): require graph refresh after large features

Browse source
This commit is contained in:
Serkyo 2026-06-27 22:58:27 +02:00
parent 48d4224a80
commit 168acf4300
2 changed files with 12 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
AGENTS.md
View file

@ -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. 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 ## 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: 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:

6
CLAUDE.md
View file

@ -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. 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 ## 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: 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: