admin/felhom-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(R-71a): live evidence — 0.162.0 deployed both boxes, settle-gate GO captured

Browse Source 
demo-felhom 9201 + demo-hp 9201 (G1 break-glass, secret shredded) both clean +
healthy on 0.162.0 with the settle-gate GO line. Honest B' accounting recorded:
the floor is in-memory (not persisted) so both above-floor boxes logged
"awaiting floor knowledge" then GOed ~10s later once the report ACK landed —
the report-ACK latency the 90s sub-bound is sized to, not a regression. The
zero-wait-when-floor-known invariant stays unit-proven (test E).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7Drmtm2RzoqbkJZCNSFNQ
This commit is contained in:
authentik Default Admin
2026-07-24 07:53:49 +02:00
parent cb8bf14599
commit a71cc58327
2 changed files with 34 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
REPORT.md
+27 -6
View File
@@ -62,10 +62,31 @@ Injectable clock (no real sleeps), fake `SettleState`, recorded `Consumer`
## Ship / honesty
The deferral paths ship **unit-proven + red-proofed, NOT live-fired** — their precondition is now
structurally prevented by the v1.25.0 golden≥floor build gate, which is the point. The
live-observable leg is the **B′ first-poll GO line on both above-floor demo boxes** (proving zero
added latency on the common restart shape). **Layering: gate prevents, (a) defers, (c) heals.**
R-71 → SHIPPED with (a)+(c); (b) recorded rejected-by-design.
structurally prevented by the v1.25.0 golden≥floor build gate, which is the point. **Layering: gate
prevents, (a) defers, (c) heals.** R-71 → SHIPPED with (a)+(c); (b) recorded rejected-by-design.
_(Build/deploy to both boxes + the two first-poll GO log lines appended on completion of the publish
train.)_
## Build + deploy + LIVE (2026-07-24)
Image `gitea.dooplex.hu/admin/felhom-controller:0.162.0` (sha `e6e1146f…`, 145M) built + pushed.
Deployed to **both** boxes, clean start, healthy:
- **demo-felhom (guest 9201, `ssh felhom-pve`)** — `Up (healthy)`:
```
05:50:44 [INFO] [offsite-apply] settle-gate: awaiting floor knowledge (first report ACK) before offsite apply
05:50:54 [INFO] [offsite-apply] settle-gate: GO — at/above floor 0.156.0 (we are 0.162.0), no managed update running
```
- **demo-hp (guest 9201, G1 break-glass; secret extracted file→file + shredded)** — `Up (healthy)`:
```
05:52:53 [INFO] [offsite-apply] settle-gate: awaiting floor knowledge (first report ACK) before offsite apply
05:53:03 [INFO] [offsite-apply] settle-gate: GO — at/above floor 0.156.0 (we are 0.162.0), no managed update running
```
**Honest accounting of the B′ live leg:** both above-floor boxes GOed correctly, but NOT literally on
the first poll — because the floor is **in-memory, not persisted**, it is unknown at the very first
poll (the report ACK hasn't landed) so the gate logged `awaiting floor knowledge`, then GOed on the
next poll (~10 s later) the instant the floor became known and confirmed at/above. This is exactly
the documented finding, not a regression: the gate correctly refused to consume while the floor was
unknown, and added ~10 s to a background reconcile (invisible to any user). The B′ zero-wait-when-
floor-known invariant is unit-proven (test E); the ~10 s live wait is the report-ACK latency the 90 s
sub-bound was sized against. The important live proof holds: **the gate did not burn the one-time
password before the managed-update picture was clear.**