Committing updates refs/heads/<branch>, not the HEAD file, so watching HEAD
alone left the stamp one commit behind -- observed live, the banner read
a84a72e immediately after 2337431 was committed. build.rs now also watches the
resolved branch ref.
Belt and braces, since cargo still cannot see every source change: sidecar.sh
compares the binary's stamped commit against the tree's real HEAD at launch and
says so loudly on a mismatch. An evidence artefact that names the WRONG commit
is worse than one that names none.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The compiled-in dirty flag cannot be trusted for this job. Cargo does not
re-run a build script when another crate's source changes, so editing the
adapter and rebuilding the host leaves it reading 'clean' -- verified by
appending a line to the adapter and watching the flag not move.
So the stamp now only names the commit, and the real safeguards run at the
moment they matter and cannot go stale:
* sidecar.sh checks the working tree at LAUNCH and warns.
* check-live-parity.sh REFUSES on a dirty tree, since it produces the
artefact a migration decision is made from. ALLOW_DIRTY=1 overrides for a
throwaway check.
Both scope to the three migration crates, so unrelated submodule dirt does not
trigger them -- a warning that is always on is a warning nobody reads.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A whole-repo check read DIRTY permanently, because unrelated submodules carry
pre-existing modifications. A warning that is always on is a warning nobody
reads, which defeats the point: the flag exists so a mutated build announces
itself before it can be mistaken for parity evidence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Prerequisites for the live FIFA A/B. Two safeguards here exist because the
corresponding failure actually happened, not because it was imagined.
BUILD IDENTITY. build.rs stamps commit + working-tree cleanliness; the host
prints commit, tree state, profile and a fingerprint of the bundled config
table at startup, into both the log and the trace. A dirty tree prints an
explicit "do NOT treat results from this binary as parity evidence" warning.
The previous step left four sidecars running, two serving mutated builds, and
nothing in their output said so.
SIDECAR LIFECYCLE (sidecar.sh). start/stop/status/check-orphans/with. Start
refuses when any sidecar is already running or the port is busy. Stop kills,
waits, then PROVES it: PID gone AND port free AND no stray processes, failing
if any check does not hold. `with -- CMD` traps EXIT/INT/TERM so cleanup runs
however the command exits.
Bug found and fixed while testing it: orphan detection used `pgrep -f`,
which matched any process whose command line merely mentioned the name --
including the shell running the test script. It now matches the resolved
executable via /proc/PID/exe. `pgrep -x` is unusable because Linux truncates
the process name to "openfut-blaze-h".
BLAZE SWITCH (blaze-switch.sh). Redirects Blaze to the sidecar with a scoped
NAT rule instead of editing the frozen Python oracle, whose redirector
advertises a hardcoded BLAZE_PORT = 42130. Rules match only <LAN_IP>:42130;
127.0.0.1:42130 is deliberately left alone so Python stays reachable on
loopback and the A/B compares real Python against real Rust. Verified both
directions live: LAN->Rust with the switch on, LAN->Python with it off.
Bug found and fixed: `off` reported success while two rules remained active
and rollback had NOT happened. It matched `--comment "tag"` with quotes this
iptables does not emit -- and the verification used the SAME broken matcher,
so it confirmed its own failure. A rollback that lies is worse than one that
fails. Now matched on the bare tag, verified with iptables-save plus a
tag-independent check that nothing still redirects the port.
Second flaw fixed: `sidecar.sh stop` originally warned about a live switch
and then stopped anyway, creating the exact broken state it warned about. It
now REFUSES, with --force as the deliberate override.
The general rule this all converges on, now stated in the README: a
verification must not share the failure mode of the thing it verifies.
116 tests still passing; clippy clean; Python backend untouched and contract
suite 446/446. NAT table left clean, no orphan processes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
funman300