blaze-host: per-gate evidence capture, separating asserted from observed

For the live FIFA gates. Records switch rules, sidecar status, log, trace and
the Python contract result into a timestamped bundle, and reports CONFIGURED
and OBSERVED state as two distinct sections.

The separation is the whole point. 'blaze-switch.sh status = ON' is an
assertion produced by the same tooling that performs the switch, and that
tooling reported a successful rollback once when none had happened. The
observed half comes from an unrelated source: the sidecar's own record of
which peers connected to it. A non-loopback peer in that log proves the
client's Blaze traffic landed on Rust without depending on reading an iptables
rule correctly.

Verified both ways: loopback-only traffic reports 'a FIFA session did NOT land
here'; a non-loopback peer reports that it observably did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
funman300
2026-08-11 02:00:31 +00:00
parent cf3ddde3a6
commit 48aa955212
2 changed files with 154 additions and 0 deletions
+27
View File
@@ -200,3 +200,30 @@ be diffed against one against Python.
No credential or token is logged. Volatile values are replaced before they reach
the line, not truncated after, and a test asserts a known secret never appears
in trace output.
## Evidence capture per gate
```bash
./gate-evidence.sh <gate-label> # after each gate; never modifies anything
```
Writes a timestamped bundle (switch rules, sidecar status, log, trace, Python
contract result) and reports **configured** and **observed** state separately.
That separation is the point. `blaze-switch.sh status = ON` is an assertion from
the same tooling that performs the switch — and that tooling reported a
successful rollback once when it had not happened. The observed half comes from
a different source: the sidecar's own record of which peers connected to it. A
non-loopback peer in the sidecar log is proof the client's Blaze traffic landed
on Rust that does not depend on reading an iptables rule correctly.
The script says so explicitly, in one of two forms:
```
REMOTE peer(s) reached the Rust sidecar: 10.10.0.x
=> the client's Blaze traffic observably landed on Rust
```
```
no remote peer connected — only loopback (or nothing) reached Rust
=> a FIFA session did NOT land here
```