fix(ci): the round tests had been skipping in CI since they were written

[gHashTag]

The round tests have been skipping in CI since they were written

queen-round.test.ts guards its behaviour cases with it.if(present), where present means "the policy binary exists on this machine". Nothing in the workflow ever built it. From the log of a green run:

(skip) queen round, lease lost > dispatches nothing once the lease has moved
(skip) queen round, lease lost > says so when it stands down mid-round
(skip) queen round, lease lost > dispatches the same issue while the lease is held
(skip) queen round, send-backs counted > returns a first failure for a second pass
(skip) queen round, send-backs counted > names the pass it is actually asking for
(skip) queen round, send-backs counted > escalates at the ceiling instead of returning for ever
(skip) queen round, send-backs counted > increments only on a send-back, in the statement that records it

Seven of them, every run, green.

This is the file that exists because nothing in the repository called runRound — the one whose own header records a critic deleting the watch.held && guard, the stand-down warning, and the heartbeat sweep, one at a time, and watching all 364 tests stay green through every deletion. The lease guard is the one that matters: every write below the choice is unfenced, so a round that has lost its lease and keeps dispatching writes bees onto the legitimate Queen's board.

In CI it has been proving nothing since the day it merged.

Two changes, because either alone leaves the hole open

1. Build the binary — in the same image the Dockerfile uses (swift:6.0-jammy), so the thing under test is the one Railway ships rather than a lookalike compiled by whatever toolchain a runner happens to carry.

The step asserts the artifact, not the exit code:

test -x queen-core/.build/release/queend

A build that prints an error and still exits 0 would otherwise leave the tests skipping exactly as before, under a step that looked like it had worked.

2. Make the skip loud — a build step can be removed, renamed, or start failing quietly a year from now.

The existing first case asserts the path string, which is true whether or not anything is at the end of it, so it cannot notice this. The new one fails when the binary is absent and CI is set. A laptop without it is a fair place to skip — that is what the guard is for — but CI is the only machine whose green anybody reads as coverage. It names the command that fixes it rather than merely refusing.

What this unblocks

The .catch() added in #476, which lets a round dispatch even when review or reaping throws, currently has no test — I said so in that commit. With this merged, runRound can be driven with a pool that fails the review, and the dispatch asserted. That test follows on #476.

Honest note

I claimed in #476 that testing this needed a live database. That was wrong — runRound is exported and takes a pool double, GitHub is stubbed at fetch, and the harness has been there all along. I had not read the file before asserting its limits.

[github-actions]

❌ Tests failed — 1/2089 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	975/975	0	0
✅ 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 — input tools > blocks coordinate-based actions with ACL intent rules

View workflow run

[gHashTag]

Result: Tests / server-api is green, with the round tests actually running

(pass) queen round, lease lost > has the policy binary wherever green is read as coverage
(pass) queen round, lease lost > dispatches nothing once the lease has moved
(pass) queen round, lease lost > says so when it stands down mid-round
(pass) queen round, lease lost > dispatches the same issue while the lease is held
(pass) queen round, send-backs counted > returns a first failure for a second pass
(pass) queen round, send-backs counted > escalates at the ceiling instead of returning for ever
(pass) queen round, send-backs counted > increments only on a send-back, in the statement that records it
(pass) queen round, boundary checked > names the files a bee committed outside its boundary
...
973 pass

What it took, and what each attempt taught

attempt	result
build in the Swift image	built fine — every test then failed exit 127: libswiftCore.so
--static-swift-stdlib	ran — but links libFoundationEssentials.a, a different Foundation
assert a clean exit from the binary	broke the step: queend answers a JSON question, so {} exits non-zero by design
dynamic build + runtime lifted from the image	production linkage, binary starts, 8 real failures surfaced

The static fix was the tempting one and it was wrong: a gate that changes the thing it measures is measuring itself. The linkage now matches Railway's, and the runtime travels beside the binary.

The 8 failures were two causes, neither a product defect

Four wording assertions had rotted. The policy now says a worker already has it where the test pinned a worker has it, and it is rejected - claimed, but no worker is attached yet where it pinned expected back. These reproduce on macOS with origin sources, so it is drift, not a platform effect — and the behaviour assertions beside them (chosen is null) passed throughout.

Four fixtures reproduced a bug the product had already fixed. They passed on macOS and failed on Linux. Widening one assertion to print the whole answer got the binary to say why:

{"kind":"error",
 "error":"could not decode the question: ... codingPath: [tasks, Index 0],
          \"Expected date string to be ISO8601-formatted.\""}

spentTask built timestamps with new Date().toISOString(), which always carries milliseconds; queend decodes with Swift's .iso8601, which does not accept a fractional second. The product has been right about this for months — isoSeconds in queen-tick.ts strips the fraction before any task reaches the policy, and its comment records the identical error at codingPath: ["tasks", "Index 67"].

I checked production before assuming: the registry board carries 2026-08-21T21:32:54Z, no fraction. The deployed Queen is not affected. The fixture was testing a program that does not exist.

Remaining red

• Tests / server-tools — AssertionError: Expected a point for #submit-btn, a browser-suite assertion. This change touches no browser code; a comment-only control branch passed this job earlier, and a re-run of an identical commit also passed, so it is intermittent. Stated as measured, not diagnosed.
• cla — the signing bot, on every PR here.