Four defects of one family, all shipped today: something the box already knows, thrown away or drawn
as its opposite. Agent v0.128.0, controller v0.210.0. NO HUB CODE, no hub bump, no ArgoCD sync.
R-265 (this repo). timeout-minutes: 5 on the gates job — every honest run in the observed session
finished in 18-34s, so this is ~9x the slowest and far under whatever reaped run 264 at 834s with no
log. The alarm mail now carries Elapsed (start stamp via $GITHUB_ENV; an absent stamp prints
"unknown (no start stamp)", never a bogus 1.7-billion-second figure) and its "names itself in the run
log" sentence is qualified so it cannot mislead when there is no log.
⚠ THE UNKNOWN IS NOT CLOSED. Whether the if: failure() alarm fires for a REAPED job is still
unverified. The timeout makes the reap unreachable in practice; it does not answer what happens in
one. Demonstrating it means deliberately hanging a run on main, which would leave the branch red for
a parallel session. Said in the workflow comment, the changelog, R-265 and the report — none of them
claiming it is answered.
GOLDEN 0.210.0 baked, published, round-trip verified, NOT VOUCHED. The currency gate went red the
moment the controller was bumped — correct — and is closed by the bake, never --no-verify. No
--no-verify anywhere this session.
⚠ THE AGENT WAS NOT PUBLISHED UNTIL THIS SESSION CHECKED, AND IT MATTERED. R-221's fix is in the
AGENT, and a fresh install takes its agent from the Day-0 manifest. The binary had been hand-deployed
to felhom-pve and never published, so agent_version 0.128.0 was not selectable and a fresh install
would have received 0.127.0 — the golden would have carried the controller fixes and NOT the one the
headline defect needed. Caught by checking each Day-0 value was FETCHABLE rather than assuming.
Published from the live-deployed bytes, sha-verified across the hop first.
Registers. R-221, R-259, R-258, R-265 CLOSED. R-266 MINTED (READY): the failed root statfs still
travels to the hub as a 0-of-0 disk; ranked LOW because it is the quiet direction — it can only miss
a true alarm, never raise a false one — and it is now a two-repo wire change governed by G-1's gate.
Highest ID moved R-265 -> R-266.
CONTEXT S-39 rules the convention this project was missing: "we do not know" is never drawn as
"fine", and the codebase has ONE way of saying it — an explicit ...Known bool companion checked in
the template. ROADMAP G-3 was explicitly blocked on that decision and is unblocked; what remains
there is a survey-and-convert of existing sites, not the gate.
Capability map row 93 CHECKED and it was NOT claiming something untrue — it is about the operator
notification path. But its narrative ("the page you open to ask whether ONE app is backed up")
invites the wrong reading, and the adjacent thing WAS false until v0.210.0, so the row now records
that the two halves disagreed and only the operator half was true.
Six red-proofs across the two code repos, each with the mutation asserted applied. The one that
matters: Part 1 Scenario A FAILED against today's tree, with the intended message.
Part 1's operator-present live validation is OWED and is the session's STOP.
repo_gates --fast: all 8 OK.
CI went red on the two G-1 commits while the local pre-push hook was GREEN — which this workflow's
own alarm mail says outranks whatever the push was for, because it is a finding about the gates
themselves. It was.
CAUSE, reproduced rather than guessed: scripts/wire_contract_gate.py compares what one component
EMITS against what the other can RECEIVE, so it needs the SOURCE of the controller and the agent.
The workflow already fetched the controller (for golden-currency) but not the agent, so the gate
exited 2 INCONCLUSIVE. Reproduced locally by pointing the gate at a nonexistent agent path: same
exit 2, same message.
THE LESSON, and it is the reusable half: the pre-push hook runs on a workstation where every sibling
is a real clone, so a gate that needs a sibling passes there and is inconclusive here. **The two
automated homes are not interchangeable, and a NEW GATE MUST BE CHECKED IN BOTH.** Recorded in the
step's own comment beside the fetch.
Fixed by giving the gate what it needs. NOT by letting it skip when a sibling is absent — that is the
fail-open shape, and it would leave the gate running in NEITHER home, which is the R-29 census
failure this runner was built to end and which golden_currency_gate.py's docstring already warns
about at length.
CI checks out ONE repo, shallow. The R-242 gate reads the newest RELEASED
controller from the sibling clone's CHANGELOG.md - the same sibling assumption
reuse_refs_check.py and instructions_gate.py already make - so in CI it was
exiting 2 (INCONCLUSIVE) and CI went red on every push.
Caught by checking the CI result rather than assuming it: runs 241, 242 and
243 all failed while the gates were green locally.
A PERMANENTLY-RED CI IS THE DETECTOR-NOBODY-HEARS FAILURE THIS WORKFLOW EXISTS
TO PREVENT - people stop reading it, and then it catches nothing. So the fix
is to give the gate what it needs, not to let it skip when the sibling is
absent: a skip would be the fail-open shape this project keeps removing, and
the gate would then run in NEITHER of its two automated homes (the pre-push
hook and CI).
Depth 1, pinned to main, plain git - no JavaScript-action step, per the
workflow's own rule about the runner having python3 and git and nothing else.
If the fetch fails the gate still reports INCONCLUSIVE rather than passing.
Resend sits behind Cloudflare, which blocks the default 'Python-urllib/3.x' agent with its
own 403 (error 1010). That failure looks exactly like an auth failure and is not one, so
the reason is recorded next to the header. Verified from the runner image with a
deliberately invalid payload: with the agent set, Resend answers 422 missing-field, i.e.
the request now reaches the API.
The first version died on 'curl: command not found' — the runner image carries python3 and
git and nothing else on purpose. Reaching for a bigger image to send one HTTP request would
have been the wrong trade, so the step uses urllib. Verified from the image itself that
HTTPS to api.resend.com resolves and the certificate verifies.
The step also fails LOUDLY on an empty key or a non-2xx from Resend: a silent alarm is
worse than no alarm, because it reads as coverage.
P5 measured: a failed run produces NO mail, NO notification row and NO log line from Gitea.
A red tick in a web UI nobody watches is exactly the defect R-29 filed, rebuilt one layer
up, so the run alarms itself on the project's existing transactional path (Resend, the same
one the hub uses) and prints the provider's accepted id, making 'it was sent' an observable
rather than an assumption.
The key is a user-level Gitea Actions secret created out-of-band; it is in no committed
file. The recipient is the operator address the hub already uses and is not a secret.
This push is deliberately made while main is still carrying the Scenario B breakage, so the
resulting run fails and demonstrates the alarm end to end.
Replaces the Part 0 probe workflow, whose four measurements are recorded in
documentation/audits/SPIKE-ci-runner-2026-08-02.md.
Reports, does not refuse: pushes go straight to main with no pull request, so there is no
merge for a status check to stand at. The refusing half is .githooks/pre-push, which is
per-clone and --no-verify-able; this half notices when that was skipped.
No uses: step anywhere — JavaScript actions need a node runtime the host-mode runner does
not have. Probe P3 measured that a shallow git fetch of the exact pushed SHA from the
in-cluster Gitea service is sufficient, and that it equals the pushed commit.
The alarm step is deliberately absent until probe P5 measures whether Gitea already mails
on a failed run.
TEMPORARY. Deleted before the session ends. Measures whether a registered runner picks up
a job at all, whether python3 and git are visible to the JOB (not merely present in the
image), whether the source can be obtained with no JavaScript action, and that docker is
NOT reachable from a job.
admin