ci(security): make the security-fixes routine observable and stagger its schedules

[PMerlet]

Why

First real runs of the new routine (2026-07-30) gave mixed results:

Repo	Result
toolbelt	✅ #809 — 1 alert fixed, 4 stale resolutions removed
agent-ruby	✅ #337 — 1 alert fixed
forestadmin-server	❌ agent step failed: 1 turn, $0.00, is_error: true after ~180 s
forestadmin	❌ same signature
agent-nodejs	⏹ cancelled manually after 28 min of zero visible output

Two problems to address, neither in the agent instructions themselves:

1. No observability. claude-code-action hides all agent output unless show_full_output: true is set. A run that is working normally and a run that is stuck look identical in the logs — which is exactly why the agent-nodejs run was cancelled by hand, and why the two failures can't be diagnosed beyond "the first API request never completed" (total_cost_usd: 0 = nothing was ever billed).

2. Five concurrent Opus sessions on one API key. All five workflows shared the 0 11 * * 4 slot, so five sessions started within ~3 minutes. The two repos with the largest initial context (forestadmin-server, forestadmin — the biggest monorepos, both with a sizeable CLAUDE.md) started 53 s apart and both burned ~3 minutes of retries before giving up without a single billed token; the smaller repos, running with less overlap, succeeded. That is the signature of an input-token rate limit, not of a bug in the routine.

What

• show_full_output: true — agent progress becomes visible in the workflow log (GitHub still masks secrets).
• Staggered schedules, 30 min apart, so the five repos never run concurrently:
  forestadmin-server 11:00 · forestadmin 11:30 · agent-nodejs 12:00 · toolbelt 12:30 · agent-ruby 13:00 UTC.

workflow_dispatch stays available; when triggering several repos by hand, space them out.

Next

Re-run the three non-green repos manually one at a time after merging. With full output on, a repeat failure will name the actual API error — if it is a rate limit, the options are a higher API tier or --model claude-sonnet-5 for the two big monorepos.

🤖 Generated with Claude Code

Note

Make the security-fixes CI workflow observable on failure and stagger its schedule

• Adds a failure-only step to security-fixes.yml that reads the agent's execution output and emits a compact error summary (subtype, terminal reason, cost, etc.) without exposing the full transcript.
• Shifts the weekly schedule from 11:00 to 12:00 UTC on Thursdays to stagger runs and avoid rate limits.
• Bumps actions/checkout and actions/setup-node from v4 to v6.
• Updates security-fixes-prompt.md to use yarn install --ignore-scripts, scope pre-push linting to changed files only, and replace checkbox columns in PR tables with a separate 'Review checklist' task list.

^{Macroscope summarized 4c7d4b4.}

[qltysh]

Coverage Impact

This PR will not change total coverage.

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[macroscopeapp]

🟡 Medium workflows/security-fixes.yml:73

The failure-reporter step prints terminal_reason, api_error_status, and result as null/empty on the failures it is meant to diagnose, so it still cannot distinguish an API/auth failure from another terminal failure. The pinned claude-code-action result message does not expose those fields — it reports failures through its errors array. The jq filter selects .type == "result" but reads fields that are absent from that schema. Consider surfacing the result message's errors field (with truncation/redaction) instead.

Suggested change

	jq -r '[.. | objects | select(.type == "result")] | last
	| {subtype, is_error, terminal_reason, api_error_status,
	num_turns, total_cost_usd,
	result: ((.result // "") | tostring | .[0:400])}' "$F" \
	|| echo "Could not parse the execution log"
	jq -r '[.. | objects | select(.type == "result")] | last
	| {subtype, is_error, num_turns, total_cost_usd,
	errors: ((.errors // []) | map(.message // . | tostring) | join("; ") | .[0:400])}' "$F" \

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @.github/workflows/security-fixes.yml around lines 73-77:

The failure-reporter step prints `terminal_reason`, `api_error_status`, and `result` as `null`/empty on the failures it is meant to diagnose, so it still cannot distinguish an API/auth failure from another terminal failure. The pinned `claude-code-action` result message does not expose those fields — it reports failures through its `errors` array. The `jq` filter selects `.type == "result"` but reads fields that are absent from that schema. Consider surfacing the result message's `errors` field (with truncation/redaction) instead.