fix(actions): report an outage when the run fails ahead of the agent

[tend-agent]

Problem

A run that fails before the agent step never reaches the outage tracker. Report failure is gated on the agent step specifically:

- name: Report failure
  if: failure() && steps.claude.outcome == 'failure'

Twelve steps run ahead of claude — the security preflight, the rate-limit preflight, bot-ID resolution, auth validation, proxy/uv install, sensitive-config restore, prompt composition, the mitmproxy cache, the sandbox build, the binary and plugin installs, and the adopter's sandbox_setup:. When any of them fails, steps.claude.outcome is skipped, the conjunct is false, and the run goes out red with no tend-outage issue and no comment on an existing one. The work it stranded leaves no trace anywhere a maintainer looks. codex/action.yaml carries the identical gate on steps.codex.outcome.

What it cost

On max-sixty/tend between 2026-08-05T11:37Z and 2026-08-06T00:07Z, the rate-limit preflight aborted every agent run on the repo — 36 failed runs across four workflows:

Workflow	Failed / total
tend-notifications	19 / 20
review-reviewers	12 / 13
tend-review	4 / 4
tend-mention	1 / 1

Every one aborted on the same line, with the burst counters at zero — the bot's daily item count had crossed the spike threshold and, since the guard runs before anything that could change that count, it stayed crossed until the UTC date rolled:

Rate limit: burst=0 PRs, 0 issues (20min); today=16 (limit: 15)
##[error]Rate limit: bot created 16 items today, above spike limit of 15 (baseline: 17 over past 6 days)

And in all 36, the outage step never ran — from the raw logs of both a review-reviewers leg and a tend-review run:

##[start-action display=Report failure;id=__max-sixty_tend.__run_13]
##[end-action id=__max-sixty_tend.__run_13;outcome=skipped;conclusion=skipped;duration_ms=0]

Zero tend-outage issues were filed or commented on across the whole 12.5-hour window; the label's most recent issues are still #831 and #832 from 2026-08-04, both closed. Those two got filed precisely because that outage failed inside the agent step. So the tracker works — it just can't see the half of the action that runs first, which is where a whole-repo, day-long stop lives.

The blackout self-cleared at 00:00Z when the daily counter reset, so nothing here needs a revert; the reason a maintainer never saw it is what this PR fixes.

Fix

Gate on the job being red rather than on which step reddened it, in both harness actions, and correct the report-failure.sh header comment that documented the old contract. A pre-agent failure strands exactly the same work as an agent failure, so it belongs in the same tracker.

The widened gate also admits post-agent failures (Mark event notification read, Token usage). Those are rarer and the agent's work has already shipped by then, but the run is still red and still worth a row — an outage issue that occasionally over-reports is the right side to err on relative to one that misses a 12-hour stop.

One exclusion: the security preflight. security-preflight.sh failing means the repo isn't safely gated for the bot — an unprotected default branch, or an update ruleset the bot can bypass. That's a config refusal, not an outage, and it's persistent: it stays failing until a human fixes the repo, so under a bare failure() gate it would file an issue titled "Bot temporarily unavailable" and append a row on every subsequent trigger, indefinitely, while the reporter records only a run link and so never names the cause. It's also the one path where reporting has the action write to the repo (gh issue create, plus gh issue close on the reconcile path) with the bot's PAT right after the security gate refused to let it operate there. The step now carries id: security and the gate is if: failure() && steps.security.outcome != 'failure'; it's the first step in both actions, so every other failure leaves that outcome success and the widening is otherwise unaffected. Note that the PAT-write argument is what carves it out, not persistence: Validate auth configured and the adopter's sandbox_setup: also fail deterministically until a human edits config, and they stay in. Bounding that repeated append belongs in report-failure.sh, where one change covers every such step without an enumerated exclusion list — tracked in #859.

The rate-limit abort's remediation is itself a counted item. Worth stating because the direction is counterintuitive when this is read back later: the tiers rate-limit-preflight.sh enforces count bot-authored issues — RECENT_ISSUES via repos/$REPO/issues?creator=$BOT, TODAY_POSTS via search/issues?q=author:... — so the first abort under the new gate creates a tend-outage issue and thereby nudges the very counter it tripped on. It's self-limiting rather than a loop: every later failure appends a comment to the now-open issue, and comments appear in neither query, so the exposure is +1 item per open-issue cycle.

This is diagnosability only — it doesn't touch the rate-limit thresholds. #856, from a sibling leg of this same run, retunes the guard that caused this particular blackout by demoting its spike tier to a creation pause. The two are complementary rather than overlapping: #856 stops the spike tier from failing the run at all, and this PR makes the tiers that still abort — the two burst checks and the hard limit it keeps — plus every other pre-agent step land in the tracker when they do.

Gate assessment

• Evidence level: Critical — 36 failed runs, four workflows, a 12.5-hour total stop of the bot on its own repo, invisible end to end. Acts on one occurrence.
• Structural, not stochastic: no decision point. steps.claude.outcome is skipped for every pre-agent failure, so the condition is false 100% of the time, for every consumer of both actions.
• Change type: targeted fix — one if: expression per action plus a comment correction.
• Passes both gates.

Evidence log: https://gist.github.com/dca23a6e6a0d8cae2665944ba31676fb

Related but distinct — both assume the agent step failed and so never fire on this path: #818 (naming the cause in the exited-non-zero annotation) and #809 (deduping outage comments across matrix legs).

[tend-agent]

Two things worth a second look before this lands. The core change is right — steps.claude.outcome == 'failure' is false for every pre-agent abort, so the tracker structurally can't see them.

The security preflight is a config refusal, not an outage. security-preflight.sh is the one pre-agent step whose failure means "this repo is not safely gated for the bot" — unprotected default branch, or an update ruleset the bot can bypass. Under if: failure() that repo now files a tend-outage issue and appends a row on every subsequent trigger, indefinitely: the failure is persistent, not transient, so the issue titled "Bot temporarily unavailable" with "Close it once the outage is resolved" never resolves, and since the reporter records only a run link the actual cause is never named in it. It's also the one case where the widened gate has the action write to the repo (gh issue create, and gh issue close on the reconcile path) with the bot's PAT after the security gate refused to let it operate there. Excluding just that step keeps everything else the PR is after — add id: security to the preflight step and gate if: failure() && steps.security.outcome != 'failure'. Every other pre-agent failure leaves that outcome success, so the widening is unaffected. Flagging as a judgment call rather than a defect.

The rate-limit abort's remediation is itself a counted item. The tiers rate-limit-preflight.sh keeps count bot-authored issues — RECENT_ISSUES via repos/$REPO/issues?creator=$BOT, and TODAY_POSTS via search/issues?q=author:.... The first abort under the new gate creates a tend-outage issue, so the guard's response to tripping nudges the counter it tripped on. It's self-limiting — every later failure appends a comment to the now-open issue, and comments appear in neither query — so the exposure is +1 item per open-issue cycle, not a loop. Worth a line in the PR body rather than a code change, I think, since the direction is counterintuitive when read back later.

One inline suggestion on the codex comment.

[tend-agent]

Both taken. Pushed adbb6dd.

Security preflight — excluded. Agreed, and the second half of the argument is what settled it: not just that "Bot temporarily unavailable" never resolves against a persistent config refusal, but that reporting is the action writing to the repo with the bot's PAT immediately after the security gate refused to let it operate there. Implemented as suggested — id: security on the step, if: failure() && steps.security.outcome != 'failure' on the reporter, in both actions. It's the first step in each, so nothing can fail ahead of it and leave the outcome unset; every other failure leaves it success and the widening is unaffected. The report-failure.sh header now documents the exclusion alongside the widened contract, since the script is shared verbatim and its comment is the only place the contract is written down once.

Rate-limit counter — noted in the body, no code change. Agreed on the disposition. Verified the mechanism before writing it up: RECENT_ISSUES reads repos/$REPO/issues?creator=$BOT and TODAY_POSTS reads search/issues?q=author:..., so a created issue counts against both, while the append path (gh issue comment) shows up in neither — self-limiting at +1 per open-issue cycle, as you had it. It's now a paragraph in the Fix section rather than a comment in the script, since the surprise is in the interaction between two files and neither is the obvious place to look.

One correction to the PR body while I was in there: the widened-gate comment in codex/action.yaml credited that action with an adopter setup step it doesn't have — details in the inline reply.

[tend-agent]

One follow-on from the exclusion; the rest of the widening reads right to me.

The security preflight isn't the only pre-agent step whose failure is persistent. The argument that carved it out — an issue titled "Bot temporarily unavailable" collecting a row on every trigger, because the failure won't clear until a human changes the repo — applies unchanged to two other steps the widened gate now admits:

• Validate auth configured fails whenever the harness credential input is empty. security-preflight.sh authenticates with GITHUB_TOKEN, not the model credential, so it passes and the new exclusion doesn't fire. This is what a per-workflow harness: codex trial without OPENAI_API_KEY looks like, or a credential-secret rename — the rest of the repo keeps working while that one workflow reddens on every trigger.
• Run adopter sandbox setup (Claude action) fails on any error in the adopter's sandbox_setup: — a bad package name, a moved URL. Deterministic, and red on every run until the adopter edits their config.

Either one then appends a row per trigger to an issue that records only a run link, so an adopter reading it sees "The bot failed to process a request" with no mention of a missing secret. The nightly enricher names the cause within a day, which bounds the confusion — but that's equally true of the security preflight, and it was excluded anyway. So what actually separates the excluded step from these two is the PAT-write argument on its own, not the persistence one.

I'm not suggesting more id:s — an enumerated exclusion list gets fragile as steps move. The narrower shape is to bound the append itself: skip commenting when the open outage issue already carries a row for this workflow inside some window, which covers every persistent-failure class at once. #809 is adjacent but doesn't reach it — it keys on the run id, so it collapses a matrix's legs within one run and still appends once per trigger across runs.

Reasonable to land the widening as-is and take that separately; flagging so the choice is deliberate rather than inherited from the one step that got a carve-out.

[tend-agent]

The critique lands, and I've made the choice deliberate rather than leaving it inherited. Pushed 3bf1d06.

The persistence argument doesn't single out the security preflight. Verified both counterexamples before agreeing. Validate auth configured is an emptiness check on the harness credential — validate-claude-auth.sh on the Claude side, an inline [ -z "${{ inputs.openai_api_key }}" ] on the Codex side — and security-preflight.sh authenticates with GITHUB_TOKEN only, so it passes clean while that one reddens. Run adopter sandbox setup fails on any non-zero from the adopter's script. Both deterministic on config state, both red on every trigger until a human edits something, both admitted by the widened gate. So the carve-out rests on the PAT-write argument alone.

I've rewritten the comment to say exactly that rather than lead with persistence, since the old wording implied a distinction that doesn't hold and would have justified the next carve-out by analogy.

No more id:s — agreed, and filed the narrower shape. #859 tracks bounding the append inside report-failure.sh: skip commenting when the open outage issue already carries a row for this $GITHUB_WORKFLOW within a window. Covers every persistent-failure class without per-step knowledge, and won't go stale as steps move. Your read of #809 checks out — it keys on the run id, so it collapses a matrix's legs within one run and still appends once per trigger across runs, which is the axis these repeat on. Noted #816 as complementary there: it makes each row name its cause, #859 stops rows the reader doesn't need.

Landing the widening as-is, with #859 as the follow-up.