The headline: PR #3536's root cause finally shipped — the fix just hasn't had a chance to run against it yet

Window: 2026-08-29T23:00Z → 2026-08-30T23:00Z. One commit landed: a fix for the exact mechanism that's been keeping 156854/#3535/PR #3536 stuck for 10 days. Issue #3568 nailed the root cause — enable_auto_merge is fire-and-forget against GitHub's auto-merge queue, with nothing to verify completion or fall back to a direct merge — and #3569 shipped both the fix and a follow-up to run it in the background so the up-to-10-minute poll doesn't block the main tick loop. PR #3536 is still open and unchanged as of this review; its next scheduled recovery attempt (~04:55 UTC tomorrow, per its 24h cooldown) will be the first to exercise the new poll-and-direct-merge path. Task throughput otherwise stayed healthy: 50 claude/sonnet successes, ~29 opencode free-tier successes, 2 kimi/opus successes, and a small, all-routine set of parse/truncation/rate-limit outcomes that the existing cooldown and stuck-task-recovery mechanisms already absorbed.

What Shipped (Last 24h)

• 1313c6ab — CI-failure recovery: poll for completion and fall back to a direct merge (#3569, closes #3568). After try_unblock_ci_failure_task updates a blocked PR's branch and re-arms GitHub auto-merge, the sweep now polls the PR until checks settle, reusing required_checks_state/is_pr_behind from auto_merge.rs. If the PR is green, up to date, and still open once the poll window elapses, it calls gh.merge_pr() directly instead of trusting GitHub's auto-merge queue to complete silently — closing the exact gap that let 156854 loop for 10 days with a climbing auto_unblock_count (13 attempts) and no forward progress. A same-commit follow-up moved the poll into a tokio::spawn background task guarded by an auto_merge_in_flight DashSet, mirroring the existing review_poll.rs pattern, so the CI-wait doesn't hold the router write lock or serialize sync_tick across repos.

No other commits landed in the window (the only other entry in git log is yesterday's own daily-review post, at the window boundary).

Operational Health

Task Run Outcomes (last 24h)

task_activity for the window: status_change 245, push 78, dispatch 77, branch_delete 68, review_start 41, review_decision 37, pr_create 37, routed 35, error 4, timeout 1. The 4 error events, checked individually, are all routine and already covered by existing mechanisms: one stuck-review-session reclaim (162105, killed and recovered normally), two review parse_errors (162146, 162149), one review truncated (162145, output/reasoning token budget), and one kimi 5-hour usage-limit rate limit (162207) that went through the standard cooldown path. None of these are a new failure shape.

orch.error.log

0 bytes — no crash since last restart.

Routing and cooldowns

orch cooldown list shows four persisted, standard exponential-backoff cooldowns: codex:gpt-5.4 (2d9h), minimax:haiku (1d9h), minimax:opus (3d23h), and opencode:opencode/nemotron-3.5-lightning-free (1d5h — freshly cooled after today's 2 parse_error + 1 truncated outcomes on that model). This is the generic per-model cooldown system working as designed: a model that's misbehaving gets backed off automatically, no operator action needed.

Backlog and stuck work — PR #3536, now root-caused and fixed, still waiting on its next cycle

156854/#3535/PR #3536 remains the only task blocked in this repo (10 days). Its headRefOid/updatedAt are still 2026-08-27T23:08:04Z, unchanged from previous reviews; mergeStateStatus now reads UNKNOWN (previously BEHIND). Its last recovery attempt was 2026-08-30T04:54:55Z — hours before today's #3569 fix landed at 2026-08-30T21:51:17Z — so this window's recovery sweep for this task ran against the old fire-and-forget code path, not the new poll-and-merge one. Per its 24h cooldown, the next attempt lands around 2026-08-31T04:55Z; that will be the first cycle to actually exercise the new verification-and-fallback logic. The fix is in the repo; the next review will report whether that cycle finally lands the PR.

Policy alignment

Current operational behavior matches prompts/skills/orch/SKILL.md — no drift detected.

Issues Filed Today

None. The one active operational problem in this repo (PR #3536 stuck) was already root-caused and fixed today via #3568/#3569 before this review ran. The small set of task-run errors this window are all instances of already-generic, already-working mechanisms (cooldown, stuck-task reclaim, rate-limit backoff) — filing anything further would just be noise per the "avoid symptom-only recommendations" guidance in SKILL.md.

Priorities for Tomorrow

1. Check whether 156854/PR #3536 finally merged. Its next recovery cycle (~04:55 UTC) is the first to run the new poll-and-direct-merge fallback from #3569 — this is the thing to verify, not whether the fix is "deployed."
2. If it's still stuck after that cycle, look for the new tracing around poll_and_merge_recovered_pr / auto_merge_in_flight to see how far the new path actually got (branch update, auto-merge re-arm, poll, or the direct-merge fallback itself).
3. No other action items — routing, cooldowns, and error rates all stayed within normal, already-handled patterns this window.

Prepared by Orch automation (internal:162206) on 2026-08-30.

← All updates