Files

T

gates / gates (push) Successful in 17s

Details

R-361 docs: the [FACT], the negative that cancelled Part 2, R-383/R-384, golden 0.221.1

07-backup-architecture.md gains a dated [FACT] on R-361 - a comment asserting an
invariant the code did not have, for four months - and a [DESIGN] on the db_dumps
decision INCLUDING the trap it created: a stable list lets the already-current
early return fire, so per-capture housekeeping must sit above it.

00-capability-map.md records the NEGATIVE from Part 3 so it is not re-derived: a
held app does NOT raise the dead-app alarm. It aggregates to unhealthy, which
IsDownState excludes. Measured on the shipped build with the scans demonstrably
running over it. No suppression was built and no row opened.

R-383: the double-failure message names an undo copy that is not there - R-361's
own class, one surface over, observed on both 0.220.2 and 0.221.1.
R-384: an app whose database has died reads unhealthy and raises no alarm.

R-361 closed and compressed. OPEN-ITEMS 325236 -> 327266 bytes.

Golden 0.221.1 baked, published and round-trip verified. The golden-currency gate
blocked this push and that block is not circular, so it was satisfied rather than
bypassed - no --no-verify anywhere in this session.

2026-08-23 00:33:12 +02:00

3.7 KiB

Raw Blame History

REPORT — R-361 and the two loose ends v0.220.2 left (2026-08-22 → 23)

Companion to felhom-controller v0.221.0 → v0.221.1. Full record: documentation/audits/DRILL-r361-2026-08-22/.

What this repo carried

documentation/architecture/07-backup-architecture.md — a dated [FACT] on R-361 (the comment that asserted an invariant the code did not have, and what it cost), and a [DESIGN] on the db_dumps decision including the trap it created: a stable list lets CaptureRecoveryUnit's already-current early return fire, so anything that must happen on every capture has to sit above that check.
documentation/architecture/00-capability-map.md — the negative from Part 3, recorded so it is not re-derived: a HELD app does not raise the dead-app alarm, measured on the shipped build, and the reading that said it would was wrong and why.
STATUS.md — the outcome in plain words; the deciding section says what happens if nothing is done.
documentation/tests/golden-0.221.1-2026-08-23/ — the golden bake.
Register — R-361 closed and compressed; R-383 and R-384 opened.

Part 3 — a measurement that cancelled a Part, and that is a good outcome

The runbook's reading was that a held app alarms as a dead app. It does not. On the shipped v0.220.2 a hold was created deliberately; docmost aggregated to unhealthy; IsDownState is {stopped, exited, degraded}; the dead-app heartbeat read 0 currently down at scans 600 and 620 with the scans demonstrably running over it. Part 2 was dropped in full and no register row was opened, exactly as the runbook directs.

The positive control took three attempts, and that is the second finding. Two live attempts failed to produce a lasting down state at all — privatebin went stopped (whitelisted by design) and bookstack went degraded then unhealthy. An absent alarm from a detector never shown working proves nothing, so the control was moved to the layer the detector lives in: classifyRunStates is a pure function, and it raises the banner for degraded/exited while staying silent for the states measured live.

Findings opened

R-383 (MEDIUM) — the double-failure message tells the customer "a korábbi állapot mentése megvan" while naming the very file whose absence caused the failure. Observed on both v0.220.2 and v0.221.1. R-361's own class — a sentence asserting a property the code does not check.
R-384 (MEDIUM) — an app whose database has died reads unhealthy and raises no dead-app banner and no customer e-mail, because aggregateState checks unhealthy > 0 before the mixed-case degraded branch. Not invisible everywhere (the health report counts it), but it does not alarm.

Register size: OPEN-ITEMS.md 325 236 → 327 266 bytes; CLOSED-ITEMS.md 66 777 → 68 464. R-361's full text: git show a8caa0fdde7c:documentation/backlog/OPEN-ITEMS.md.

The golden was baked here, and why

golden-currency refused the docs push: 0.221.1 released with no golden. Not circular — a golden needs the controller image, already pushed, not this commit — so the gate was satisfied by doing the work rather than bypassed. No push in this session used --no-verify.

Golden 0.221.1, sha256 1c8bf6cf08cadabeca6331f38360d905e867c235067cd10c2716915b6e6df089, 656 966 079 B, round-trip verified, all markers hit, both negative controls at zero, both token-leak greps proved able to convict before their zeros were accepted.

Operator follow-up

Vouch the golden — a three-field save: golden_version 0.221.1, agent_version 0.130.0, min_agent 0.129.0. Then raise the floor to 0.221.1, last, in its own save.

3.7 KiB Raw Blame History