fix(queen): the Linux copy of the policy had drifted, and its gate ran nowhere

[gHashTag]

Eleven policy files exist twice, and the gate for it ran nowhere

rings/SR-00 is compiled by the app. agent-server/queen-core/Sources/QueenCore is the copy the Docker build compiles for Linux, because the build context cannot reach up out of the agent-server directory.

make queen-core-sync compares them byte for byte, and its own comment states the stakes:

"the copy is compiled by the Linux stage and the original by the app, and a policy that differs between them is two arbiters of the same rule."

It appears in no workflow. I checked all thirteen files: twelve identical, one not.

The drift, dated

ring gains a string-aware literal view	2026-09-05 — 5255e0bee (browseros-ai#1176)
Linux copy last touched	2026-08-29

The fix never crossed. And it is not a comment: the copy is missing var inString and the entire escape-and-quote branch.

So on Linux the literal view is still the version the ring's own comment describes being burnt by — a /* inside a quoted branch glob ("No empty queen/* branch …", line 6864 of ChatViewModel.swift) opening a phantom block comment and blanking the file from there to the end:

"6 726 lines of evidence invisible: corroboration saw no mentions past the glob, so browseros-ai#1158's two candidates tied at zero and rule 4 answered with a mid-body window of the wrong function."

QueenLocalisation is reached from QueenEvidencePolicy inside queen-core, so this is in the artifact Linux runs — not a stray file.

Two changes

The copy is synced to the ring.

The gate now runs, on ubuntu, in trios-logic.yml. It is cmp — it costs seconds and does not need the compiler that consumes its result. The workflow's paths gain trios/agent-server/queen-core/** so a hand-edit of either side wakes it; watching only the ring would leave the same hole facing the other way.

Proven both directions before wiring

with the drift:  [FAIL] the Linux copy of the Queen's policy has drifted:
                   DIFFERS  QueenLocalisation.swift
                 make: *** [queen-core-sync] Error 1

after the sync:  [OK] queen-core-sync: the Linux copy is byte-identical to rings/SR-00

How it was found

Yesterday's round discovered seven tests that had skipped in CI forever. The follow-up question was "what else never runs?" — and this is the answer for the Swift side: the group-coverage gate is excellent (run-test-group.test.ts cross-checks the CI matrix in both directions), so the hole was not there. It was in a make target no workflow invoked.

[github-actions]

❌ Tests failed — 1/2088 failed

Suite	Passed	Failed	Skipped
✅ agent	87/87	0	0
✅ build	9/9	0	0
✅ cdp-protocol	5/5	0	0
✅ eval	93/93	0	0
✅ server-agent	272/272	0	0
✅ server-api	944/974	0	30
✅ server-browser	6/6	0	0
✅ server-integration	10/11	0	1
✅ server-lib	273/273	0	0
✅ server-pglive	3/3	0	0
✅ server-root	68/68	0	0
✅ server-skills	31/31	0	0
❌ server-tools	241/242	1	0
✅ shared	14/14	0	0

Failed tests

• server-tools — search_dom > finds text across multiple elements

View workflow run

[gHashTag]

Widened: five gates now run, in 11 seconds

The same audit that found queen-core-sync unwired found five portable gates in total. Four more are wired here — and each was run against the shipping ref before being wired, not assumed to pass:

gate	what it guards
queen-core-sync	the Linux copy of the policy against the ring, byte for byte
sources-drift	the build's source list against the tree
sources-drift-selftest	…and the proof that gate can still fail
binary-drift	the shipped binary against what the tree builds
run-completeness-selftest	the test-run parser, against known transcripts

portable-gates   pass   11s

Separate steps, not one make a b c d: make stops at the first failure, and a single step would report one broken gate while hiding the state of the three behind it. Which gate failed is the whole content of the answer.

One gate deliberately left unwired

drift-guard came out of the same audit and is not here. It is one line — bash run_chat_sse_e2e.sh with an extra scenario enabled — it drives the Swift compiler, and it did not finish inside four minutes. Its own comment calls it "slow, explicit, never accidental", and the script it wraps already runs in swift-logic.

Wiring a gate that hangs is worse than leaving it unwired.

The audit tool was wrong twice, and both were caught the same way

tri unwired (in #475) classified check-bypass and drift-guard as portable. Both wrong:

• check-bypass is $(MAKE) check — following only prerequisites saw an empty recipe. Its own echo says "never for CI", which is how it was caught: the tool disagreed with the target's description of itself.
• drift-guard hides its compiler inside a shell script. A scan of make recipes sees one layer; a script is the second.

There is a third answer now — opaque — rather than a guess. The portable list went 11 → 9 → 6 → 3 as each layer was followed, and every step of that shrinking was a false accusation withdrawn.