fix(claude-action): name the cause in the exited-non-zero outage annotation

[tend-agent]

Problem

A tend-outage issue records that a run failed but, on the most common failure path, can't say why. In claude/action.yaml the exited branch bailed on CLAUDE_EXIT -ne 0 and exited before the VERDICT jq ever inspected the stream:

exited)
  if [ "$CLAUDE_EXIT" -ne 0 ]; then
    echo "::error::claude -p exited non-zero (exit=$CLAUDE_EXIT) — see the session-logs artifact"
    tail -20 "$STDERR_LOG" 2>/dev/null || true
    exit "$CLAUDE_EXIT"
  fi
  # VERDICT jq (names the cause) only ran when CLAUDE_EXIT == 0

A session-limit exhaustion — the single most common outage cause — exits non-zero and emits a <synthetic> assistant message like You've hit your session limit · resets 8:30am (UTC). That text sits in the stream the action still has open, but nothing extracted it: the annotation, and the enrichment comment enrich-tend-outage-issues.sh derives from it, both read only the generic "see the session-logs artifact" line. A maintainer couldn't tell session-limit from auth failure from server error without downloading artifacts and writing jq.

Solution

In the exited-non-zero branch, extract the last assistant text from the stream and fold it into the annotation, keeping the generic fallback when the stream has no assistant text:

REASON=$(jq -r '
  select(.type == "assistant") | .message.content[]?
  | select(.type == "text") | .text
' "$STREAM_JSON" 2>/dev/null | grep -v '^[[:space:]]*$' | tail -1)

Because the nightly enrich-tend-outage-issues.sh pass posts the failure annotation into the issue, a self-diagnosing annotation carries into the tend-outage issue for free — no change to the enrichment script needed.

Testing

Inline action bash, so no pytest harness. Verified the extraction jq against a realistic stream-json sample (normal turns + tool_use + a trailing <synthetic> session-limit message): it returns You've hit your session limit · resets 8:30am (UTC), and returns empty for an empty stream (falls back to the generic annotation). YAML re-parses cleanly.

Scope

This is Gap 1 of #816. Gap 2 — a recovery pass that re-runs the event-triggered workflow a dead run stranded (e.g. a tend-review that never retries because it fires only on pull_request_target) — is a larger design change with real tradeoffs (which workflows to re-run, the quota-window ordering constraint, confirming the work is still missing first). I've left that for a maintainer to weigh in on rather than ship a partial recovery mechanism here; details and the reporter's proposed shape are in the issue.

---

Closes #816 — automated triage

[tend-agent]

Self-review — the change is sound. Session-limit exits non-zero and emits the <synthetic> assistant message (confirmed by #816), so the exited-non-zero branch is the right place, the extraction jq matches the shape used by the transcript-render jq earlier in this step, and it falls back to the generic annotation when there's no assistant text. One comment-accuracy nit inline.

[tend-agent]

The enrichment isn't report-failure.sh — that script only appends the run-link row. The nightly enrich-tend-outage-issues.sh is what fetches the failure annotations and posts them into the issue (as #816 itself attributes it). A maintainer chasing the enrichment path later would look in the wrong file.

Suggested change

	# artifact". report-failure.sh's enrichment then carries the
	# artifact". The nightly enrich-tend-outage-issues.sh pass then carries the

[tend-agent]

Fixed in 85e590d — the comment now credits the nightly enrich-tend-outage-issues.sh pass. report-failure.sh only records the run-link row; the enrich script fetches the failure annotations and posts them, so that's the path a maintainer would chase. Also corrected the same misattribution in the PR body.

[tend-agent]

Real-stream validation from a production outage, in case it helps prioritize this: tend's own account hit its weekly limit at ~09:41Z on 2026-08-04 and stayed exhausted until the 00:00Z UTC reset. Every review-reviewers run in that window failed on exactly this path — 14 consecutive hourly runs × 5 matrix legs, all Supervisor: status=exited elapsed=2s claude_exit=1 → the generic see the session-logs artifact annotation.

I pulled the claude-stream.json from one of those legs (run 30959115609) and ran this PR's extraction against it verbatim. It returns the right string:

$ jq -r 'select(.type == "assistant") | .message.content[]? | select(.type == "text") | .text' \
    claude-stream.json | grep -v '^[[:space:]]*$' | tail -1
You've hit your weekly limit · resets 12am (UTC)

The stream is five events (active_goal, system/init, rate_limit_event, one <synthetic> assistant message with error: "rate_limit" and is_api_error_message: true, then result), so the tail -1 picks the synthetic message with nothing else competing — the same shape as the session-limit case the PR describes, just the weekly variant. Zero tokens billed, num_turns: 1.

Cost of not having it: #831 took 77+ comments over those ~15 hours, every one a bare one-row table with no cause. Working out that this was a quota reset rather than an auth break or a server error needed an artifact download and jq — for a condition that self-resolves at a known clock time and needs no code change at all.

One optional belt-and-braces note if you're touching the block anyway: the trailing result event carries api_error_status: 429 and duplicates the same text in .result, so it's an independent source for the same fact if the synthetic-assistant shape ever changes. Not needed for this fix to work — the extraction as written is correct on the real artifact.

[tend-agent]

Fresh evidence from the 2026-08-04/05 window, since this has been open a couple of days: the failure mode this fixes recurred at 15× the scale of the incident that prompted it — 15 consecutive review-reviewers runs × 5 matrix legs = 75 job failures over 14.5 continuous hours, every one annotated claude -p exited non-zero (exit=1) — see the session-logs artifact with an empty $STDERR_LOG.

The text this PR would have surfaced was sitting in $STREAM_JSON the whole time:

You've hit your weekly limit · resets 12am (UTC)

Two details worth noting for the implementation here:

• The weekly limit produces the same synthetic-assistant shape as the session limit — a <synthetic> model message whose last text block carries the message — so tail -1 of the assistant text picks it up unchanged. No change needed.
• The stream also carries a structured rate_limit_event (rateLimitType: "seven_day", resetsAt, overageStatus) and the result event has api_error_status: 429. Not needed for the annotation, but they're there if a future pass wants to distinguish quota class or report a reset time.

Practical cost of not having this: outage tracker #831 accumulated 78 rows with no cause on any of them. The nightly enrichment pass ran and worked correctly — it just faithfully copied the uninformative annotation into every row. Diagnosing it meant downloading artifacts and writing jq by hand, for the second time in three days (#808 was the first).

Not proposing any change to the diff — it already does the right thing. Just recording that the evidence bar is now well past one occurrence. #845 separately cuts the cadence that drives the quota exhaustion; this makes the wall legible when it's hit anyway.