hub v0.99.0 — the hub can see whether the operator can get in (R-260); G-1 gate closes, R-247 closes

oobDegraded tested five things and the sixth never arrived.

The agent has emitted `operator_key_configured` on every heartbeat since v0.72.0 — the SAME version
that introduced the `oob` stanza carrying it — and store.HostOOBRow mirrored five of the agent's
eight OOB fields. With no field for it, encoding/json discarded the fact on arrival, so a box with
felhom-sshd active, reachable, a valid config and a configured peer reported `ok` with NO OPERATOR
KEY INSTALLED AT ALL. Not a wrong answer: an answer to a question nobody was asking.
`operator_peer_configured`, which the hub did read, only says the peer IP is in desired-state — that
OOB is MEANT to work, not that entry is possible.

Now decoded: operator_key_configured, plus wg_handshake_age_s and healed_at. The last two ride the
ALERT TEXT and are deliberately NOT in the predicate — widening a check beyond the fact that is now
arriving is how a check stops being read.

SCENARIO F, decided on a measurement rather than a preference. operator_key_configured decodes as a
POINTER: nil = the agent never said, reported distinctly and never as ok. The version gate was
rejected because the field and its stanza shipped in the SAME agent version (v0.72.0), so a stanza
without the field cannot come from any released agent; the fleet is 0.113.0/0.127.0 and the vouched
floor is 0.127.0. Handled explicitly anyway and pinned, because "cannot happen" is a claim this
project has been burned by.

THE MESSAGE NAMES THE FAULT. oobDegradedReason is the single source for both predicate and text, so
the alert can never name a different fault from the one that fired. The old form derived it
separately and had a vocabulary of two — unreachable, or config invalid — with no way to say the key
is missing. The operator reads this at 07:00.

TESTS DRIVE THE DECODE BOUNDARY. Every hub OOB test before this built a HostOOBRow by hand, and a
test written that way CANNOT SEE A FIELD THAT NEVER DECODES — which is how this held a green suite
for five weeks. The pre-existing fixture oobReport() also omitted the field, so those scenarios ran
against a report shape no released agent produces (same family as R-262). Both fixed.

Red-proofs, 8 expected outcomes and 0 wrong, each with the mutation asserted applied: dropping the
field returns the false ok; an unconditional check alerts a healthy box; unknown-as-ok restores the
silent pass.

G-1 CLOSED — scripts/wire_contract_gate.py shipped as ranked, built BEFORE the fixes and seen
failing on 40 fields (documentation/tests/wire-contract-gate-2026-08-08/BEFORE.md). Two instrument
defects the control caught first: a substring false negative (grep -F healed_at matched
privsep_healed_at) and treating dr_recipe as wholly opaque when its top-level sections ARE decoded
through an allow-list that already cost offsite_restic (R-122).

The prompt for this session said "465 emitted tags, eight unreachable". Checked against the repo:
R-260 said "at least eight DECISION-BEARING facts", never eight tags. The real count is 40.

R-260 CLOSED (class gated, sharpest instance fixed). R-247 CLOSED (controller v0.209.0). R-264
MINTED and OPEN — the 21 facts with no consumer, allowlisted with reasons so that gating the class
could not be mistaken for deciding them. Still open and named: R-246, R-255..R-259, R-261..R-263,
and C7's test-comment half.

Capability map checked: it claims OOB access is implemented, never monitored, so no row was untrue;
what was untrue sat one layer down and the row now records it.

repo_gates --fast: all 8 OK. go build/vet/test green in hub, run separately from this commit.
This commit is contained in:
2026-08-08 08:47:02 +02:00
parent 560f0d4451
commit b080ecf411
13 changed files with 836 additions and 58 deletions
+15 -22
View File
@@ -1,6 +1,6 @@
# STATUS — what works, what's broken, what's next
**Updated 2026-08-08 (overnight — Campaign 12).**
**Updated 2026-08-08.**
> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority; this page restates
> part of it in plain words, and **nothing may exist only here**. Not `CONTEXT.md`, which is technical
@@ -46,33 +46,26 @@ it. *(R-252, R-253 — closed 2026-08-08.)*
clean teardown. No secrets involved, but it accumulates with each walk. *(R-244)*
- **Putting restored files back where they belong is still a manual step.** *(R-213)*
## Found overnight — we went looking for siblings, on purpose
## Fixed today — the thrown-away sentence, and a check so there is no next one
Every fault this month came in one of seven shapes; overnight we looked for the others **by shape**
reading and counting only, nothing changed or deployed, no machine touched. Eight new items, none
urgent. Full working: `audits/CAMPAIGN-12-class-sweep-2026-08-08.md`.
We could not tell whether your engineer could get into a machine. The machine says so every few
minutes; **the hub had nowhere to put the sentence and discarded it on arrival**, so a box with the
door open, the lock working and **no key issued** was reported as fine. Not a wrong answer — an answer
to a question nobody was asking. Fixed, and the alert now **names the missing key** instead of saying
"access degraded". *(R-260, R-247 — closed; hub v0.99.0, controller v0.209.0.)*
- **The one that matters.** The machine tells us whether your engineer's emergency key is really
installed — and **we throw that sentence away before reading it**, so a box can read as "we can get
in" when nobody can. Same shape in seven other places. *(R-260)*
- **A green tick meaning only "a backup exists"** — any age counts, and it reddens on a problem
measured across all apps rather than that one. *(R-258)*
- **A disk we failed to measure is drawn as an empty, healthy one** — "0.0 GB / 0.0 GB (0%)" in the
normal colour, while the right pattern sits two files away. *(R-259)*
- **Two comments promise more than the code does** (one guarded by a test that cannot fail on the
thing it names), and **two refusals still stop at "no"**, one in half-English.
*(R-262, R-263, R-256, R-257)*
- **Which shapes can a machine catch from now on?** That mattered more than the list: **one is cheap
and worth doing** (the thrown-away-sentence one, which would have caught every instance on the day
it was written), two need a small decision first, and **two are honestly not automatable**
including the one that looked most automatable, where the standard tool was tested and found blind.
Recorded, not built. *(ROADMAP G-1…G-8)*
**The check was built first and watched failing on 40 facts, before a single one was fixed** — the
night before, an off-the-shelf tool for a neighbouring shape was rejected for failing exactly that
test. Of the 40: three now change what we are told, sixteen are genuinely redundant, and **twenty-one
are recorded as undecided rather than quietly waved through** *(R-264)* — the strongest being
per-guest network health, which we already lost 1 h 15 m to once.
## What we're working on
- **Widening the check** so a fourth secret-in-a-page is caught by a machine, not by someone. *(R-255)*
- **Proving the hub really keeps the old sealed key** when a machine re-seals — needs its own session
and a second deliberate wipe. *(R-198)*
- **Deciding the twenty-one** — for each: give it a reader, or stop sending it. *(R-264)*
- **Proving the hub really keeps the old sealed key** when a machine re-seals. *(R-198)*
- Still open from the overnight sweep, none urgent: *(R-256…R-259, R-261…R-263)*
## Waiting on you