CHAOS NIGHT: fences clean, firewall baseline taken, and a third mistimed label

Fence check mid-night: demo-hp carries only this drill's VM 336; guests 9201 and
9202 are running with their full standing sets intact, bentopdf included.
Nothing of theirs was stopped, removed or redeployed tonight.

Firewall baseline recorded BEFORE the rounds that need it (7-9 block the box's
internet by flipping a host sysctl and inserting two physdev rules):
  iptables -S FORWARD -> "-P FORWARD ACCEPT" and nothing else
  physdev rules -> 0
  net.bridge.bridge-nf-call-iptables = 0
A control taken before the experiment, so that "it looks clean afterwards" can
be a measurement rather than an assertion - on a host that also carries the two
standing demo guests.

And a third mistimed reading of my own, recorded: I labelled a 21:36:00Z check
"end of window" when the fill runs to ~21:39:49Z. The readings are unchanged
(nothing fired), but the label is the point - "nothing yet, five minutes in" and
"nothing in the whole window" are different findings. From here the end-of-window
check is taken when the round's runner reports completion, because the runner
knows when it released the fill and I was guessing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/audits/evidence-chaos-night-2026-09-17/phase0-notes.txt

@@ -402,3 +402,23 @@ been established, it is a `systemd-run` transient unit (`household.service`, act
 than recording where it sits. It hits the guest's traefik from one hop closer than DooPlex would, so
 it does NOT exercise the LAN path between DooPlex and the box; anything that breaks only on that hop
 is invisible to it. The `use` rounds, which DO run from DooPlex, cover that hop.
+
+### Fences and the pre-block baseline, checked mid-night (2026-09-16 ~21:38Z)
+**Standing guests untouched.** `qm list` on demo-hp shows only VM **336** (this drill's own box);
+containers 9201 and 9202 are running. 9201 still carries its full standing set —
+adventurelog(+frontend,+postgres), **bentopdf**, bookstack(+db), calibre-web, cloudflared, docmost
+(+postgres,+redis), felhom-controller, filebrowser, kimai(+db), opengist, paperless(+postgres,
++redis), privatebin, romm(+db,+redis), traefik — and 9202 its three (controller, filebrowser,
+traefik). Nothing of theirs was stopped, removed or redeployed tonight. `drill-r50` does not exist on
+this host and was not created.
+
+**Firewall baseline on demo-hp, recorded BEFORE the internet-block rounds (7–9) need it:**
+    iptables -S FORWARD   ->  `-P FORWARD ACCEPT`  (nothing else)
+    physdev rules         ->  **0**
+    net.bridge.bridge-nf-call-iptables = **0**
+
+This is a control taken before the experiment, not after: rounds 7, 8 and 9 flip that sysctl to 1 and
+insert two `--physdev-in` rules for this VM's tap. When they finish, the same three readings must
+come back identical. Without the „before" reading, „it looks clean afterwards" would be an assertion
+rather than a measurement — and this host also carries the two standing demo guests, so an abandoned
+rule would be a fence breach rather than an untidy drill.

documentation/audits/evidence-chaos-night-2026-09-17/round-3.txt

@@ -69,3 +69,21 @@ end-of-window check remains owed rather than quietly satisfied by this reading.
 **What that already establishes, independent of how the window ends:** the household's twelve apps
 keep running and serving with the system disk at 96 % full, and after five minutes nobody has been
 told anything. The apps do not fall over; the silence is the finding.
+
+## A third mistimed reading — and why it matters more than it looks
+At 21:36:00Z I took what I labelled „the end-of-window alarm check". The fill window runs
+**21:29:49Z -> ~21:39:49Z**, so that was again mid-window, the third time tonight I have estimated
+the clock instead of reading it (the earlier two: „the window ends ~23:39" and the 21:34 reading).
+
+The readings themselves are consistent and unchanged — newest event still `controller_started` at
+21:28, **no `disk_critical`, no `disk_warning`, no `health_degraded`** — so no conclusion is altered.
+What is wrong is the LABEL, and the label is the whole point here: „nothing has fired yet, five
+minutes in" and „nothing fired in the whole ten-minute window" are different findings, and only the
+second one answers „would the household be told?".
+
+**Corrected practice for the rest of the night:** the end-of-window check is taken when the round's
+own runner reports completion, not when I think the clock has moved far enough. The runner knows when
+it released the fill; I was guessing.
+
+This is the seventh item on tonight's list of my own instrument errors, and it has the same shape as
+the rest — **a confident label on a measurement whose precondition was not met.**