The headline: one real reliability fix landed, plus a multi-day mystery finally resolved (and it wasn't an orch bug)

One commit shipped today: a genuine correctness fix (#3518 → PR #3519, 9c70ee00) closing a race where tick_recover_stuck_tasks could discard a completed agent run because its tmux session exited before the runner's own completion poll caught up — three real occurrences in three days, each burning a full duplicate agent invocation. Separately, this review chased down the two review agent rebroadcast escalated after repeated retries tasks that have been flagged as "still frozen" in the last five daily reviews, expecting another routing/recovery bug. The actual cause: the owning project is currently commented out in the local project config, so its sync tick — and therefore the rebroadcast-recovery pass — never runs. That's an intentional, operator-controlled state, not an orch defect; the watch item is closed out below rather than carried forward again.

What Shipped (Last 24h)

1 commit landed (window: 2026-08-14T23:05Z → 2026-08-15T23:05Z):

Closed today: #3518 → #3519, filed and merged same-window, root-caused from 3 real occurrences (internal:156414, internal:156454, internal:156489) each showing exit 0 / valid output / committed work recorded as outcome=failed, error="silence detection set task to new".

Still open: #3453 (bug(review-prompt): pending CI status prose still causes review parse errors), now 17 days old, the only open issue in the tracker. Re-checked against HEAD this review — prompts/review_task.md is unchanged in the last 7 days, so the gap described in the issue (no fallback instruction for NOT RUN/PENDING CI status) is still present. Carried forward as the standing priority.

Operational Health

Throughput and Activity

task_activity in the last 24 hours:

Slightly above yesterday's quiet window (77/28/27 → 90/35/29 on comparable event types), still no watchdog stalls or DB-lock errors.

Task Run Outcomes

No parse_error and no timeout rows in the window. Both claude:sonnet failed rows are silence detection set task to new — and both are pre-fix instances of exactly the bug closed by #3518/#3519 today: task 156489 (08:01–08:15 UTC, the same task cited as evidence in #3518 itself) and task 156499 (21:07–21:20 UTC, still 9 minutes before the fix merged at 21:29 UTC). Both self-recovered on the next attempt by reusing the same worktree's already-committed work, consistent with the "incidental safety net" described in the issue. No post-fix occurrences yet — nothing to confirm or refute in this window, next daily review is the first real check.

Multi-day watch item resolved: the two frozen rebroadcast-blocked tasks aren't an orch bug

The last five daily reviews flagged two review_cycles = 1 tasks stuck in blocked with reason review agent rebroadcast escalated after repeated retries, updated_at frozen at 2026-08-09T22:44:38Z — now 6 days — despite two dedicated fixes landing in that window (#3499/#3500 on 08-10 removing the review_cycles > 0 exclusion from auto-recovery, #3505 on 08-12 fixing a silent early-return in the same path).

Traced it this time instead of re-flagging it: auto_recover_rebroadcast_blocked_tasks() runs inside each configured project's sync_tick, which only fires for projects listed in ~/.orch/config.yml. The project that owns these two tasks is currently commented out of that list — zero log lines mention that repo anywhere in the last 24h, not just for this recovery path but for routing, dispatch, or sync generally. The recovery code was never given a chance to run; both #3499 and #3505 are working exactly as designed, they just never got invoked for this project. This is an intentional, operator-controlled config state (config files are off-limits to agents per repo policy), not a bug — closing the watch item rather than carrying it forward again. If the project is re-enabled later, the existing auto-recovery pass should pick these two tasks up on its next tick with no further changes needed.

Routing: cooled-agent LLM proposals continue to surface, safety net still catching them cleanly

Two occurrences tonight (23:00:15Z and 23:00:41Z UTC, both on this review's own dispatch cycles): LLM selected cooled agent/model; rerouting to available agent agent=minimax fallback=claude. minimax:opus remains in a long persisted cooldown (4d22h remaining). Both caught immediately by the existing sanity-check-and-reroute safety net with zero functional impact — same shape as the last several days, expected behavior per repo policy (the classifier proposing a cooled agent isn't itself a bug as long as the net catches it, which it does every time).

opencode/ling-3.0-tiny-free: still no data point

Zero runs on this model in tonight's window, same as yesterday. The 4-of-5 late-night-timeout clustering flagged from 2026-08-10 through 08-13 remains neither confirmed nor resolved — no evidence either way for two nights running.

orch.error.log still empty

0 bytes, unchanged since Aug 9 — stale, unrelated to this window.

Backlog and stuck work

Aside from the two now-explained frozen tasks above, the rest of the blocked backlog is unchanged in shape: several GitHub Actions billing failure blocks at merge time in another tracked project (correct per-task policy, no repo-wide skip), and a handful of long-idle items (46–134 days) with no new activity this window. Nothing new or stuck in this repo's own queue.

Issues Filed Today

None. #3518 was filed and fixed entirely within today's window by an earlier session before this review started — already covered above, not duplicated here. No new issue met the bar to file: zero parse_error/timeout rows in the window, the minimax cooled-agent reroutes are the existing safety net working as designed, the ling-3.0-tiny-free watch item has no new data to act on, and the multi-day rebroadcast-blocked mystery turned out to be operator-controlled config state rather than a code defect.

Priorities for Tomorrow

1. #3453 remains the single open issue, now 17 days old, still unaddressed. Still the fastest path to an empty tracker.
2. Confirm #3518/#3519 holds — check task_runs for any post-08-15T21:29Z occurrence of silence detection set task to new on a long-running task; there should be none going forward.
3. Keep watching opencode/ling-3.0-tiny-free late-night timeouts — two consecutive nights with zero runs, so the earlier clustering is still an open question, not a resolved one.

Prepared by Orch automation (internal:156531) on 2026-08-15.

← All updates