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

docs(workspace): add verify-then-commit loop to agent guides

Browse source
This commit is contained in:
Serkyo 2026-04-30 01:12:50 +02:00
parent 9e56bccb05
commit 1979308cbb
2 changed files with 26 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
AGENTS.md
View file

@ -97,6 +97,19 @@ The user is **learning** most of the stack used here (Rust, Vulkan/`ash`, `winit
In short: optimise for the user's understanding growing over time, not for the fastest path to working code.
### Verify-then-commit loop
When the user reports they've done what you asked, **do not take their word for it**. They are learning and may have misunderstood the task, edited the wrong file, or introduced an unrelated regression. Always verify against the actual repo state (read the files, run `cargo check` / `cargo clippy` / `cargo test` as appropriate, inspect `git diff`).
Then follow this loop on every step:
1. **Verify** the user's claimed change is actually present and correct.
2. If wrong or incomplete, explain what's off and let them fix it — do not silently patch it yourself.
3. Once correct, **create a git commit** capturing that step (following the commit conventions above) before moving on.
4. **Then** tell the user what to do next.
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.
## 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:

13
CLAUDE.md
View file

@ -97,6 +97,19 @@ The user is **learning** most of the stack used here (Rust, Vulkan/`ash`, `winit
In short: optimise for the user's understanding growing over time, not for the fastest path to working code.
### Verify-then-commit loop
When the user reports they've done what you asked, **do not take their word for it**. They are learning and may have misunderstood the task, edited the wrong file, or introduced an unrelated regression. Always verify against the actual repo state (read the files, run `cargo check` / `cargo clippy` / `cargo test` as appropriate, inspect `git diff`).
Then follow this loop on every step:
1. **Verify** the user's claimed change is actually present and correct.
2. If wrong or incomplete, explain what's off and let them fix it — do not silently patch it yourself.
3. Once correct, **create a git commit** capturing that step (following the commit conventions above) before moving on.
4. **Then** tell the user what to do next.
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.
## 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: