chaos night: the before-picture of the records that must survive the delete
gates / gates (push) Successful in 19s

drill-r50 and the tester-1 CUSTOMER record both captured at 200 while the
delete is still pending, with the four host records listed and the customer
page showing exactly one host - tonight's box.

The expected after-state is written down BEFORE the act, so it cannot be
adjusted to fit what happens: three host records left, the other three still
200, the customer record still 200 with zero hosts, and ep0 untouched. A fence
is only proven by a comparison, which is why ep0 was listed twice too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
2026-09-17 02:47:54 +02:00
parent 5337c3ba22
commit d6a0e7b80d
@@ -64,3 +64,22 @@ THE WAIT IS THE PRODUCT'S, NOT MINE TO SHORTCUT. The hub should mark the host st
00:53:43Z. The acknowledged delete is armed for 00:55Z with a guard that refuses to post while the
host still reads ONLINE. The fence says the hub is never blocked, stopped or changed - so the
correct response to a liveness gate is to wait for it, not to reach into the hub and move it.
## BEFORE-PICTURE OF THE RECORDS THE FENCE SAYS MUST SURVIVE (2026-09-17T00:47:30Z)
Taken while the delete was still pending, because it cannot be taken afterwards. The same reason
ep0 was listed twice: a fence is only proven by a comparison.
GET /hosts/drill-r50-0a4f9a -> 200, 26471 bytes (fence: "drill-r50 stays")
GET /customers/tester-1 -> 200, 188121 bytes (fence: "never RESET tester-1")
hosts the customer page lists -> tester-1-022354 (exactly one: tonight's box)
all host records right now -> demo-felhom-8363b5
demo-hp-bb76ea
drill-r50-0a4f9a
tester-1-022354
WHAT MUST BE TRUE AFTERWARDS, written down BEFORE the act so it cannot be adjusted to fit:
* three host records remain; tester-1-022354 is gone
* demo-felhom-8363b5, demo-hp-bb76ea and drill-r50-0a4f9a are all still 200
* /customers/tester-1 still answers 200 - the CUSTOMER is never reset, only its host record goes
* the customer page then lists ZERO hosts
* ep0's six snapshots across three namespaces are untouched