Harden auto-pilot stalled-PR handoff routing

[stranske]

Why

Stalled PR recovery must route to a viable registered agent, dispatch an available handoff workflow, and avoid permanently setting agent:auto when dispatch fails.

Scope

Adopt existing PR #2826 as the implementation lane.

Tasks

• Use registry-derived required-secret availability.
• Allow a single viable alternate agent.
• Use the available root or consumer handoff workflow safely.
• Apply routing changes only after a successful dispatch and keep the template aligned.
• Resolve all current review feedback.

Acceptance criteria

• Workflows and consumer templates follow the same safe handoff semantics.
• Failed dispatch leaves retryable routing state.
• Focused tests and workflow validation pass.

[stranske]

Reopened for verifier sequencing (closer automation)

PR #2826 merged at 2026-08-01T03:38:59Z (squash 31339e1d9ba1cedd23648639e271c3c1cabbe939) and GitHub auto-closed this issue via the Closes #2864 reference. Per the closer lane's merge → verify-label → verifier-PASS → close sequencing, the issue is reopened until a durable verifier report lands on the merged PR.

Merge-readiness evidence at merge time (head 0d5058845216af9ccfd459d24c634a98e757bdc1):

• MERGEABLE / CLEAN; Gate / gate, summary, Health 45 Agents Guard / guard, CodeQL, Semgrep, zizmor, Selftest CI (Python/JS/package), and CodeRabbit all SUCCESS.
• 6 review threads, 0 unresolved.
• Diff is exactly the two agents-auto-pilot.yml copies (root + templates/consumer-repo), byte-identical (e2441272b → f3bc975e4 on both), so template parity holds by construction. The out-of-scope per-run langsmith artifact is no longer in the diff.

Acceptance criteria traced to the merged diff:

• Registry-derived required-secret availability — requiredSecretNames is derived from loadAgentRegistry() entries with capabilities.pr_keepalive === true, seeded from exported HAS_* flags and refined by actions.listRepoSecrets with a warning-only fallback. Verified eligibleAgents({registry, capability, secrets}) accepts and honours secrets (.github/scripts/agent_stall_rotation.js:34,47-53).
• Single viable alternate agent — the old keepaliveAgents.length > 1 gate is replaced by hasAlternative = keepaliveAgents.some(a => a !== currentAgent), with currentAgent from currentAgentFromLabels(...) || registry.default_agent. Both symbols are exported (agent_stall_rotation.js:143-149).
• Available root or consumer handoff workflow — dispatch tries agents-81-gate-followups.yml then agents-keepalive-loop.yml, breaking on non-404 and throwing a named error when neither dispatches.
• Failed dispatch leaves retryable routing state — agent:auto is added only after dispatchedWorkflow is set, so a transient dispatch failure keeps the existing concrete agent:<X> route. The rotation path also removes a stale agent:auto before assigning the next concrete agent, preventing the mixed-routing missing-agent-label state, and creates the agent:tried-* marker label when absent.

verify:compare is applied to #2826. This issue will be closed on a durable verifier PASS with no remaining review or disposition debt; a non-PASS becomes a bounded follow-up lane with the failure evidence recorded here.

[stranske]

Verifier wait condition is satisfied — durable PASS/PASS disposition exists

The reopen comment above set the wait condition as "reopened until a durable verifier report lands on the merged PR." That report has landed. Recording it here because a scoped blocker was subsequently filed against this issue on a misread of which workflow run is the verifier.

Durable verifier evidence (post-merge, merged head 0d5058845216af9ccfd459d24c634a98e757bdc1):

• Workflow run 30682409213 — Agents Verifier, event pull_request_target, conclusion success. Both jobs green: check and verifier / Run post-merge verifier.
• Provider Comparison Report posted to fix: harden auto-pilot stall handoffs #2826 at 2026-08-01T03:44:33Z:
  • openai / gpt-5.6-terra — PASS, 84% (Correctness 9.0, Completeness 9.0, Quality 8.0, Testing 6.0, Risks 8.0)
  • anthropic / claude-sonnet-5 — PASS, 62% (Correctness 7.0, Completeness 6.0, Quality 7.0, Testing 6.0, Risks 6.0)
  • Verdict: PASS from both providers. The sole concern from either provider is the absence of targeted regression tests for a workflow-YAML-only diff — a testing-depth observation, not a correctness or acceptance failure.

Correction to the scoped blocker filed at 2026-08-01T04:04:10Z. That blocker asserted "verify:compare workflow run 30682409160 is action_required with zero jobs; owner must approve/enable the Actions run, then verifier can produce durable disposition." Run 30682409160 is Create Issue from Verification (Enhanced), not the verifier. It is the downstream helper that opens a follow-up issue when a verification reports concerns. The verifier itself is the separate run 30682409213, which completed success and produced the report above — 20 minutes before the blocker was written. Because the verdict is PASS from both providers, the follow-up-issue creator has nothing to create, so its action_required state is moot rather than blocking.

There is therefore no owner approval gate on this issue. The scoped blocker has been cleared (clear-scoped-blocker stranske/Workflows#2864).

Next owner: closer lane. Remaining action is the ordinary post-merge disposition — close this issue against the PASS/PASS report and reset the chain. No follow-up issue or PR is warranted: the code is complete in merged PR #2826 (squash 31339e1d9ba1cedd23648639e271c3c1cabbe939), all 6 review threads were resolved before merge, and every required context was green at merge time.

_{opener lane (cursor) — evidence-only correction; post-merge verifier disposition remains closer-owned, so this issue was deliberately left open rather than closed here.}

[stranske]

Completion disposition — verifier PASS

Merged PR #2826 completed verifier run 30682409213 successfully. Its durable Provider Comparison Report is unanimous PASS: OpenAI gpt-5.6-terra (84%) and Anthropic claude-sonnet-5 (62%). The only noted gap is targeted regression-test depth for a workflow-YAML-only change; neither provider found an acceptance-criteria or correctness failure.

This disposition is based on the merged squash 31339e1d9ba1cedd23648639e271c3c1cabbe939, all six review threads resolved before merge, and green required merge checks. No follow-up issue or PR is warranted; closing #2864 completes the merge → verify-label → verifier-PASS → close sequence.