eho/atomic-design-poc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record the concurrent-agent trap that RD-17 hit

Browse Source 
`/clear` ends the supervisor's context. It does not stop the developer agent
that session spawned. A fresh supervisor read the half-finished tree as an
interrupted session and dispatched a second agent onto the same ticket. Both
agents then ran `dotnet test` in one checkout, which truncated the shared
SQLite file and produced the stale-database failure the Troubleshooting
section already records under a different cause.

Also record that a bare `dotnet test` runs the OpenZaak integration test that
both CI scripts filter out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
eho
2026-09-04 20:41:32 +02:00
co-authored by Claude Opus 5
parent e221834f6e
commit fb2e58ab87
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/project/readable-codebase/README.md
+28
View File
@@ -235,3 +235,31 @@ rm -f backend/bigregister.db backend/src/BigRegister.Api/bigregister.db \
```
These are build artifacts, not fixtures — removing them is always safe.
A second cause reaches the same error: **two agents running `dotnet test` at the same time in
one checkout.** They share those files, so one run truncates the other's database. RD-17 hit
this. The fix is the same three deletions, but the cause is concurrency — see the next entry.
**`dotnet test` reports one failure in `OpenZaakIntegrationTests`.** That test carries
`[Trait("Category", "Integration")]` and needs the live OpenZaak harness. Both `ci.yml` and
`scripts/ci-local.sh` filter it out. A bare `dotnet test` does not. Run `npm run ci` — a bare
`dotnet test` is the wrong command, not a red build.
**An unexplained dirty tree may be a running agent, not an interrupted session.** `/clear`
ends the supervisor's context. It does **not** stop the `developer` agent that session
spawned. That agent keeps writing to the same branch. In RD-17 a fresh supervisor read the
half-finished tree as an interrupted session, wrote a "continue from here" ticket, and
dispatched a second agent onto the work the first was still doing. Both agents then ran the
backend tests together, which produced the stale-database failure above.
Nothing was lost, because the second agent committed first and the first agent checked before
committing rather than committing blindly. That was luck. Before you dispatch, confirm no
agent is live:
```bash
git status --short # modified files nobody in THIS session touched = suspect
git log --oneline -1 # did an agent already commit the ticket?
```
If the tree is dirty and this session did not dirty it, find the agent before you write a
ticket around the evidence it leaves.