A background subagent told to STOP can keep waking and editing — design for it, do not rely on stop

Telling a background subagent to stand down is not a reliable kill: it kept going idle and then WAKING to make more edits (queued messages, its own follow-up loop), editing a shared file after two explicit stop messages. Relying on stop as your safety mechanism fails. What actually kept the tree healthy: (1) Single-writer-per-file, always — even a rogue late edit only damages if two agents share a file; when the confused agent happened to touch a different file than the active owner, the tree stayed coherent. (2) Commit-frequently + push after every item, so a late/duplicate edit lands on top of committed work instead of clobbering uncommitted work. (3) Verify every reported ‘done’ yourself: node --check all touched files + run the test subset + check braces before committing — this catches half-merges (duplicate declarations) from overlapping edits. (4) When two agents redundantly implemented the same tickets, they often CONVERGED (same spec -> similar output) and the union was coherent — so a merge-by-last-writer plus a verify pass is survivable if you commit small. (5) If you truly need one agent gone, require it to REPLY confirming it stopped, and stop sending it any messages (each message can re-wake it). Net: treat ‘stop’ as advisory; make correctness come from file-ownership + frequent commits + verification, not from agents obediently halting.