Lock takeover, five robustness fixes, and the game team as extensibility proof

[d6veteran]

Akira's remaining systems findings plus Toni's positioning work, from the three-way audit that graded B− systems / B− tests / C+ product.

268 tests (was 223). 17 fail against main, one per finding.

The fix I specified was wrong, and Akira measured it

I accepted his recommendation to make lock breaking single-winner by renaming the stale lock directory aside instead of removing it. Measured, it changes nothing: 5 lost updates in 30 rounds against 6 unfixed.

Renaming makes the removal single-winner, but the staleness verdict still gets applied to whatever occupies the path afterwards. An instrumented run caught the real sequence:

A renames the stale lock aside → B takes the freed path with a fresh mkdir → C renames away B's live lock → three processes hold the lock at once.

Any design that empties the path frees it for a moment, and a mkdir can land in that moment.

So a contender never removes the lock directory at all. It takes the lock over in place: renames the owner record aside (exactly one contender can), verifies what it actually claimed, then writes its own record. Only the owner ever removes the directory.

Design	Lost updates
Unfixed (rm -rf "$lock_dir")	6 / 30
Rename the directory aside (what I specified)	5 / 30
…plus verify-after-claim and rebuild	1 / 30
In-place takeover (shipped)	0 / 40

He flagged it rather than shipping a change that measured the same as before. That's the second time today a persona overruled my technical direction and was right.

The other five

Liveness outranks the age rule. kill -0 decides first; the 120s age test is the fallback where liveness can't be established. Tradeoff written into the comment: a post-reboot lock with a reused PID now wedges until the timeout rather than being broken. The timeout already prints the rm -rf, so that's loud and recoverable, which beats silently discarding a completed write.

_TMP_FILE cleanup made real. Every caller wrapped tmp_beside in a command substitution, so the subshell stranded the assignment and the EXIT trap could never fire. A SIGINT mid-rewrite left a full partial copy beside CLAUDE.md.

A titleless .md no longer kills list. It exited 1 printing nothing with empty stderr; help exited 0 with a silently truncated roster. The control test names the eight personas help was dropping.

install.sh survives stdin at EOF. A bare read ended the install mid-prompt, so any piped or CI run exited 1 with no summary after every earlier step had applied. EOF now skips the coordinator and says why; Enter still means casual.

cmd_sync explains a failed copy. My diagnosis was wrong here: set -e already stopped it, so the defect was unexplained, not silent.

Three bugs found on the way

• lock_acquire could hang forever — the stale branch skipped the deadline check, so a lock that could never be claimed spun with no timeout and no message. Latent before, reachable after his change, now dies loudly.
• assert_count could never pass with an expected 0 — grep -c prints 0 and exits 1, so the || echo 0 fallback produced two lines and bash raised a syntax error instead of comparing.
• A local declaration referencing its own earlier variable, which isn't in scope yet.

Toni: the game team as extensibility proof

Reiner, Cornelius, Ernie, and Piper are now packaged as a mini team that answers "why not wire up two or three personas myself in an afternoon?" The honest answer is that you could, because the mechanism was never the hard part.

Shown from three checkable facts, not asserted: each persona is defined as much by the lane it won't cross as the one it owns; the Handoff Briefs name each other in two closed loops (Reiner↔Piper, Cornelius↔Ernie, verified); and all four came from the same profile structure and generator as the other thirteen, for a domain the tool was never built for.

gtm.md also carried a stale roster throughout — "Ten of them", "one of ten", "10 named specialist personas" in the flagship post, and a "call X for Y" list missing Sage, Kai, Iris, and the studio. All at seventeen now.

Deliberately not claimed: that a game shipped. Nothing supports it.

Honest limits

• I could not independently reproduce the lock race. My first probe was underpowered (6 writers, no CPU pressure, 0/10 both ways) and my second timed out. I'm relying on Akira's harness for that measurement, and on the 17-failure control plus the deterministic takeover test for everything else.
• Runtime 9.4s → 15.5s, a 65% increase, flagged rather than absorbed. Mostly two extra install.sh runs, the 12-writer storm, and a 1s liveness observation window.
• The stale-lock storm is a probabilistic detector, documented as such in the test. The deterministic proof is the sentinel-survives-takeover assertion.
• A holder SIGKILLed between mkdir and its owner write still wedges that file for 15s per writer. Deliberate, but nothing tests the message the user actually sees.

---

Generated by Claude Code