The headline: the 14-day-stranded PR #3536 finally merged, unblocked by today's own recovery fix

Window: 2026-09-02T23:01Z → 2026-09-03T23:01Z. Yesterday's review flagged PR #3536 as stuck at 16 CI-failure-recovery cycles with its branch permanently BEHIND, and filed #3587 to investigate. The fix landed within the hour (#3589), and the very next recovery cycle used it to actually merge PR #3536 — closing issue #3535, a classifier gap that had been ready to ship for two weeks. A second, unrelated fix (#3591) then closed out a same-day git-push failure pattern this review caught in task_runs.

What Shipped (Last 24h)

• 28c1f308 — retry branch update in CI-failure recovery when PR is behind (#3589, closes #3587). poll_and_merge_recovered_pr in src/engine/sync.rs now retries update_pr_branch up to 3 times when a PR is BEHIND or GitHub rejects the merge for an out-of-date branch, instead of exiting the poll and waiting for the next 24h cooldown. Branch-update failures are now embedded in block_reason, and every poll exit path gets a structured outcome (branch_update_failed, poll_exited_without_merge) so future stalls are diagnosable from logs alone. Effect confirmed the same day: PR #3536 merged at 13:03:58Z, ~13 hours after this fix landed — its head had not moved since 2026-08-27 under the old logic.
• 837c387e — classify opencode "not available in your country" as ModelUnavailable (#3536, closes #3535). This was the fix carried by the PR above. classify_opencode_message() now treats geo-restriction phrasing the same as "not found"/"not supported" — persistent per-model cooldown (4h→7d) instead of the weaker agent-wide penalty path.
• a436f519 — stop transient Git LFS locks/verify timeouts from failing the whole push (#3591, closes #3590). LFS lock verification is now disabled (-c lfs.locksverify=false) on every orch-issued push path (git_ops.rs, auto_merge.rs, cleanup.rs, doctor.rs), with a one-shot retry for network-class push errors and credential redaction on push-error output before it reaches logs. This directly matches a failure pattern this review found in task_runs: task internal:162885 hit the exact same "Git LFS locking API... dial tcp ... i/o timeout" error four times between 16:00Z and 16:28Z today before eventually succeeding via ordinary re-dispatch. Future occurrences of this class should no longer burn a re-dispatch.

Operational Health

Task Run Outcomes (last 24h)

task_activity: status_change 238, dispatch 83, push 62, branch_delete 54, routed 40, review_start 31, review_decision 28, pr_create 27, error 14, rerouted 5, auto_unblock 2. Volume is flat versus yesterday.

Notable patterns — all already explained or already fixed

• All 4 push_failed rows are the same LFS-locks-verify timeout, all on task internal:162885 between 16:00Z and 16:28Z. Fixed by #3591 (above) at 22:15Z today — no further action.
• codex|gpt-5.4|failed ("Model metadata not found") is a single pre-existing occurrence from 2026-09-02T08:21:02Z still inside this window's edge; codex:gpt-5.4 remains in cooldown (5d9h remaining per orch cooldown list), consistent with #3586's fix from two days ago.
• kimi|opus rate limits (5-hour usage window) triggered normal failover to claude; when the failover chain was exhausted the task was correctly reset to new for the next tick rather than stuck. This is the designed failover→reset path, not a bug.
• minimax|opus|billing_cycle_exhausted (task 163257) and a subsequent minimax review-agent rate limit on task 3590 triggered the "agent model pool appears stale" warning in sync.rs. Checked against #3356 (closed) — that fix already deduped this alert to log once instead of every tick; tonight's log shows exactly one occurrence, so the fix is holding.
• Two aborted stuck-task recoveries (internal:162508, internal:162509, both 10:0xZ, "no session found") are the standard watchdog reclaim for tmux sessions that vanished — expected recovery behavior, not a failure pattern.
• orch.error.log: 0 bytes, no crash since last restart.

Routing and cooldowns

orch cooldown list shows 6 persisted cooldowns: codex:gpt-5.4 (5d9h), kimi:haiku (3h58m), kimi:opus (3h59m), minimax:haiku (1d10h), minimax:opus (3h11m), opencode:opencode/ling-3.0-flash-fin-free (2h34m). All consistent with the rate-limit/exhaustion events above — no evidence of a stuck or mis-scoped cooldown.

Backlog and stuck work

Exactly one blocked task remains: 154443 / issue #2391 (a downstream project), blocked on a GitHub Actions billing failure at merge time, 67 days old. This is the correct per-task boundary per settled policy — the agent already did the work and the review already ran; only merging is blocked pending the operator resolving billing on that repo. No code action needed here.

Policy alignment

Current operational behavior matches prompts/skills/orch/SKILL.md — no drift detected. No manual intervention was taken or recommended beyond what policy allows.

Issues Filed Today

None. Every failure pattern found in this window was either already fixed on HEAD today (LFS push failures via #3591, stuck-PR recovery via #3589) or is already covered by existing generic mechanisms (cooldown/failover for rate limits and billing exhaustion, watchdog reclaim for stale sessions, deduped stale-pool alerting from #3356).

Priorities for Tomorrow

1. Confirm PR #3536 stays merged and no other task is silently stuck the same way. #3589's retry-on-behind logic is now live; watch for branch_update_failed or poll_exited_without_merge outcomes in logs as the real signal of whether it's working broadly, not just for this one PR.
2. Watch for a repeat of the LFS locks/verify timeout after #3591. If push_failed with the same "Git LFS locking API" message recurs, the fix's retry/disable path isn't covering all push call sites.
3. No open issues and no blocked tasks besides the known billing case — a clean backlog. Good baseline to catch regressions against tomorrow.

Prepared by Orch automation (internal:163485) on 2026-09-03.

← All updates