fix: palace single-writer guard (T-065), 10M default cap (T-068), unstale model-picker test (T-070) — suite now 607/607

[aaroncoville]

The suite is fully green for the first time: 607 of 607, typecheck 0 errors.

The "known pre-existing failure" every hire was told to ignore all day is gone — T-070 is the reason.

Three independent tasks, one commit each, so any single one can be reverted without disturbing the others. Bundled because they are all small, all verified, and the green suite only arrives with all three.

---

T-065 (P0) — retainWorker mined outside the palace single-writer guard

memory.ts:298-300 states the invariant in its own comment: the palace permits a single writer, so mines MUST be serialized. mineNow honoured it; retainWorker called mineAgent directly and never touched the flag. The GC sweep runs every 60s against a 10-minute mine loop, so overlap was a matter of time, not luck — and two concurrent writers to a store documented as single-writer risks a corrupted palace, which would silently poison recall for every future agent.

retainWorker now waits for the lock rather than early-returning (a false return there would defer scratch deletion forever on a busy floor), with the wait inside the existing Promise.race so the 30s timeout bounds lock-wait and mine together.

Full lifecycle: dev kevin-t065 → god review → QA dwight-t065qa.

This was the strongest work of the day: my adversarial mutations found nothing. I removed the leak-guard the author claimed prevents a lock leak, and its own test caught it. QA then closed the two paths its tests did not reach — both of which fail silently:

• lock release when mineAgent throws — a leaked lock does not crash; it blocks every future mine with no error anywhere, and the palace just quietly stops learning
• the waiter queue beyond a pair — all original tests used exactly two writers, so a queue that works for two and drops the third passed the whole suite

Verified: leaking the release turns both new tests red.

T-068 — uncapped workers now default to 10M

Approved decision. A worker with no tokenCap in its spawn-request and none in its manifest previously spawned unlimited. The fallback mechanism already existed; the shipped value was simply 0.

defaultWorkerTokenCap: 0 still means unlimited — the change makes unlimited a decision rather than an omission. Verified: reverting to 0 turns "a worker with no cap of its own inherits the 10M shipped default" red, and the test asserts the literal behaviour rather than sharing the constant with the implementation.

This changes live behaviour for existing uncapped spawns, as intended.

T-070 — the long-standing suite failure

Diagnosed as a stale test, not a product bug: the codex model list was reordered and gained gpt-5.5.

It did more than unstale the assertion — it added the trap the flat id-list could never express. gpt-5.6-sol bills against an API key and is rejected under a ChatGPT login, so it must stay offered but must never be recommended. Recommending a slug the picker does not offer is exactly how gpt-5-codex shipped and 400'd every turn.

The slugs are spelled out literally on purpose — importing them from the catalog would make the test agree with the catalog by construction and protect nothing.

---

Verification

Every claim reproduced independently rather than relayed:

Mutation	Result
Leak the lock in retainWorker's finally	2 tests RED
Revert defaultWorkerTokenCap to 0	1 test RED
Full suite on merged result	607 of 607
npm run typecheck	0 errors

One thing worth flagging: merged onto the post-T-061 main, the T-065 branch's diff appeared to delete test/worktree-deps.test.cjs. That was a stale-base artifact — the branch predates the T-061 merge. I confirmed the file survives the actual merge.

[aaroncoville]

Closed per Aaron's decision: behaviour abandoned. Branch remains in git if this is ever revisited.