make cassettes — a prerequisite of make check — ran rm -f .trinity-dev/state/queen_delegation.json before each of four replays, and pkilled trios-dev around them. On 2026-08-17 that destroyed a live registry of four delegated tasks mid-cycle. No backup; the file is not under version control. The inbox survived only because it is append-only JSONL.
Proven with a planted sentinel: write the file, run make cassettes, the file is gone.
Cause
dev was doing two incompatible jobs — scratch space an agent restarts and wipes at will, and the workspace where the Queen keeps live delegated tasks. The deleting line looked deliberate and correct for months, because when it was written nothing lived there.
ProjectPaths.trinity's own doc comment states the principle the harness then violated one level down: if the dev build wrote there too, an agent iterating could corrupt the state of the app the user is actually using.
Fix
The harness runs as its own variant: com.browseros.trios.test, data root .trinity-test, port 9305. BuildVariant already described .test in full — only build.sh refused to produce it, and both of its variant switches were if dev / else, so an unrecognised variant would have been handed the release paths. Both are explicit three-way cases now.
Three instances of one defect, exposed by the move
isDevVariant was answering three questions with one word:
| question |
sites |
correct predicate |
| is this the dev supervisor build |
0 remaining |
isDevVariant |
| may this reach the real Keychain |
10 |
usesFileSecretStore |
| is there a supervisor inbox |
3 |
hasSupervisorInbox |
With two variants the three agreed. With three they did not: the harness was refused its own delegation with No inbox in a release build while running as test, and would have gone at the real Keychain — which does not fail, it blocks on a dialog, so the suite hangs rather than going red. Every comment at every site described the requirement correctly while the code asked something else.
The worst of the three
A cassette replaced the transport for workers only. The chat kept a live SSETransport — and the API-key precondition keys off type(of: transport) is SSETransport.Type. So the cassette suite silently required a real API key: it passed where one happened to exist, failed where none did, and blamed the Keychain. A recorded run must not depend on a secret; that is the entire reason to record it.
Both transports now come from one factory, which takes the timeout as a parameter — the chat keeps SSETransport's default and a worker keeps its hour. Folding them together would have changed the chat's patience as a side effect.
Result
4 of 4 cassettes pass, up from 3 of 4. The orphan-tool-call replay had been red for the API-key reason all along.
Driven with trios-dev running: same PID before and after (84479), sentinel byte-identical.
A cassette-isolation gate now fails if the recipe names trios-dev, .trinity-dev, DEV_APP, DEV_PROC or the dev log — and also fails if it stops naming the test variant at all, so a rename cannot satisfy it by accident. Both arms driven.
Landed in 7ff2eb62d. Follow-up to #1275.
make cassettes— a prerequisite ofmake check— ranrm -f .trinity-dev/state/queen_delegation.jsonbefore each of four replays, andpkilled trios-dev around them. On 2026-08-17 that destroyed a live registry of four delegated tasks mid-cycle. No backup; the file is not under version control. The inbox survived only because it is append-only JSONL.Proven with a planted sentinel: write the file, run
make cassettes, the file is gone.Cause
dev was doing two incompatible jobs — scratch space an agent restarts and wipes at will, and the workspace where the Queen keeps live delegated tasks. The deleting line looked deliberate and correct for months, because when it was written nothing lived there.
ProjectPaths.trinity's own doc comment states the principle the harness then violated one level down: if the dev build wrote there too, an agent iterating could corrupt the state of the app the user is actually using.Fix
The harness runs as its own variant:
com.browseros.trios.test, data root.trinity-test, port 9305.BuildVariantalready described.testin full — onlybuild.shrefused to produce it, and both of its variant switches wereif dev / else, so an unrecognised variant would have been handed the release paths. Both are explicit three-way cases now.Three instances of one defect, exposed by the move
isDevVariantwas answering three questions with one word:isDevVariantusesFileSecretStorehasSupervisorInboxWith two variants the three agreed. With three they did not: the harness was refused its own delegation with No inbox in a release build while running as
test, and would have gone at the real Keychain — which does not fail, it blocks on a dialog, so the suite hangs rather than going red. Every comment at every site described the requirement correctly while the code asked something else.The worst of the three
A cassette replaced the transport for workers only. The chat kept a live
SSETransport— and the API-key precondition keys offtype(of: transport) is SSETransport.Type. So the cassette suite silently required a real API key: it passed where one happened to exist, failed where none did, and blamed the Keychain. A recorded run must not depend on a secret; that is the entire reason to record it.Both transports now come from one factory, which takes the timeout as a parameter — the chat keeps
SSETransport's default and a worker keeps its hour. Folding them together would have changed the chat's patience as a side effect.Result
4 of 4 cassettes pass, up from 3 of 4. The orphan-tool-call replay had been red for the API-key reason all along.
Driven with trios-dev running: same PID before and after (84479), sentinel byte-identical.
A
cassette-isolationgate now fails if the recipe namestrios-dev,.trinity-dev,DEV_APP,DEV_PROCor the dev log — and also fails if it stops naming the test variant at all, so a rename cannot satisfy it by accident. Both arms driven.Landed in
7ff2eb62d. Follow-up to #1275.