v3.2.0 — the live channel can write, and a guard whose coverage was a coincidence

The toolkit can now ask the running game questions, and — for the first time — tell it to hold still. x4live pause / unpause / pausestate are the first verbs that change a live game, and they exist because a measurement taken while the simulation runs is a measurement of a moving target: a faction gains tens of objects a minute.

Upgrade for the guard fix if for nothing else

A recursive text search rooted above your 60 GB reference\ tree reached no rule at all, and this release is what broke it. The scope rules matched a search rooted AT reference\, or at the toolkit or game root — never at an ancestor. On a layout where reference\ sits inside what used to be the toolkit root, that ancestor was covered only by coincidence; retiring the dev repo moved the root and the coverage vanished silently.

Measured through the deployed hook, before the fix:

cd <parent-of-reference> && grep -rl "x" --include="*.md" .    ALLOW   <-- the hole
same shape at the toolkit root                                  deny
rooted at reference/ itself                                     deny
rooted at the game root                                         deny

Three controls that still denied is what makes it a hole rather than a rule change — the guard worked everywhere its authors had looked. No test could fail: the fixture set the toolkit root to the parent of reference\, so it encoded the same coincidence. It could vary the roots' values, never their relationship.

It was found by hook_false_positives, which replays every historical command through the real hook — and that gate had been red and unobserved, because it is slow and was not in the previous release's gate sweep. The suite stayed green throughout. (F127)

BaseX was quietly answering a different question under Git Bash

A query typed as an argument was rewritten by MSYS before Python ever saw it — //ware arriving as /ware — and the empty result was then certified as a negative finding. If you ran a corpus query from Git Bash and concluded "X does not exist", that conclusion may have been manufactured by your shell.

xq now takes --file, an argument query's zero is refused under Git Bash rather than reported, and every argument result prints the query as received so you can see what the tool actually ran. Found by a cold agent following the documentation's own example.

One repository

The development checkout is retired and archived; the public repo is now the only tree. The blind-spots register (F1–F127), the 2026-08 audit, four gates and the next-id script used to exist only in the private copy. They ship here now.

Weapon DPS is still an honest gap, deliberately

It was promoted to a computed field during this cycle and demoted again before shipping. A live sweep of the whole population found the per-channel derivation disagreeing with the engine on 20 of 345 weapon/turret macros — including one that derives 0.0 where the engine reports 30,315, which would have read as "this weapon does no damage" rather than as a defect.

So the tool still says "we cannot compute this". No shipped release has ever emitted a weapon dps, and this one does not either — nothing regresses. The work is kept and under test; re-promotion is two lines once the 20 are explained. The aggregation rule was corrected on the way and is exact (345 of 345), which is why the remaining gap is attributed to the per-channel inputs rather than to the sum.

x4live, in full

• Write verbs (pause, unpause, pausestate): the write vocabulary is a lookup table on both sides, every write reply leads with a write=yes advisory enforced at the reply choke point, the result is the engine's read-back rather than the verb's intention, and unpause undoes only a pause this channel made. query refuses both names, so its free-text passthrough is not a second door.
• A hard request-size cap (MAX_REQUEST_BYTES, 1900). Measured live: a request over ~1997 bytes tears the game-side pipe read down, and that teardown was followed by a crash whose minidump faults in X4's own UI event dispatch. The cap sits below the measured ceiling and refuses before the write.
• The FFI verbs ship disabled by default (X4_LIVE_ALLOW_FFI=1 to re-enable) — precautionary after that crash, reversible, and explicitly not a claim that FFI caused it.
• A "nothing connected" refusal that measures the cause instead of listing possibilities. The helper arms on game load, so at the main menu its marker is legitimately absent — and the old message sent you to check an install that was fine.

Verified at the tagged tree

suite 2,393 passed / 3 skipped / 0 failed in ONE invocation (26:16) · cold clone 2,209 / 65 / 0 over COMMITTED blobs, with all 10 configuration-dependent CLIs refusing exit 2 and no traceback · mutation_probe alone 54/54 killed, 0 survivors, 0 hangs, 0 unmeasured, tree verified restored · hook probes 169/0/0 · hook units 459 · hook_false_positives green (no drift, 22,718 shared commands, 0 changed) after it found F127 · gates: budget, routing 11/11, deploy parity 37/37, register_rederivation 80 entries / 72 naming a check · identifier scans clean over the tree and all 42 commits · build-release.sh --selftest still reproduces the v3.0.0 asset byte for byte · CI green on all three jobs, read per job · release review over v3.1.1..HEAD: 112 commits, 134 files, +25,272 / −2,663.

The 3 suite skips are one test file needing a privilege this account lacks (symlink creation, WinError 1314). A skip is counted and named, never folded into the pass count.

Two things stay open and are named rather than hidden: instrument_hygiene is red on the machine that produced this release, reporting command-hygiene regressions in my own sessions — the baseline was deliberately not re-recorded to clear it. And issue #3, one unexplained non-reproducing failure from the v3.1.0 sweep, has not reproduced in 30+ runs since.

Full detail in CHANGELOG.md.