Operator Tuner Report — 2026-05-10

Window: last 24h (extended 72h for recurrence). Runs: 50. Total actions: 392. Avg actions/run: 6.8.

Action mix (recent window)

    50  run_start
    50  disk_worktree_snapshot
    50  blocked_lane_classification_summary
    50  done_audit_summary
    50  run_complete
    25  memory_snapshot
    20  create_operator_ticket
    19  repo_dirty_observed
    11  operator_dev_loop_finished
     9  reopen_weak_done_ticket
     8  operator_dev_loop_throttled
     8  recent_task_failure
     7  needs_input_runtime_failure_reset
     6  promote_dead_zone_ticket
     5  repo_dirty_all_known_generated
     3  active_lane_snapshot
     3  todo_backlog_observed
     3  stale_runtime_observed
     3  stale_runtime_marked
     3  terminal_ticket_runtime_closed
     2  stale_runtime_summary
     2  blocked_lane_completed_marked_done
     1  pickup_direct_run
     1  worktree_reaper_ran
     1  in_review_stale_failure_state_cleared
     1  chrome_memory_pressure_remediated
     1  operator_ticket_exists

Signals worth tuning

• Recurring operator-ticket markers (>=3 in 72h): {'[operator:active-lane-backlog]': 6, '[operator:dirty-repo:workspace]': 27, '[operator:dirty-repo:PKA]': 3, '[operator:dirty-repo:mission-control]': 9}
• Weak-done reopens: 9
• Stale-runtime marks (extended window): 54
• Dev-loop throttle ratio: 0.42 (8 throttled / 11 finished)
• Repo-dirty observations: 19 (generated-only noise: 5)

Reopened-ticket outcomes (current MC state)

• MC-3073: status=done updated=2026-05-10T11:04:02.393093+02:00 failure=—
• MC-3074: status=done updated=2026-05-09T22:35:03.348938+02:00 failure=—
• MC-3075: status=done updated=2026-05-09T23:03:34.524669+02:00 failure=—
• MC-3076: status=done updated=2026-05-09T23:02:56.559324+02:00 failure=—
• MC-3078: status=done updated=2026-05-09T22:32:42.657027+02:00 failure=—
• MC-3089: status=done updated=2026-05-10T05:06:42.783210+02:00 failure=—
• MC-3090: status=done updated=2026-05-10T05:06:23.924419+02:00 failure=—
• MC-3097: status=done updated=2026-05-10T06:04:49.490971+02:00 failure=—
• MC-3099: status=done updated=2026-05-10T06:04:49.182361+02:00 failure=—

Proposed patches

Operator Tuner Review — 2026-05-10

Signals explicitly skipped (too thin)

• Weak-done reopens (9/9 back to done) — All nine were cleanly recompleted; this looks like the system working as designed, not a false-positive pattern.
• Stale-runtime marks (54 in 72 h) — Likely genuine cleanup of dead sessions; no clear sign the 6 h cutoff is wrong.
• [operator:dirty-repo:workspace] recurring 27× — Persistent genuine dirty state, not a tuning problem.
• [operator:active-lane-backlog] recurring 6× — Could be threshold flapping or a real backlog; can't distinguish from this data alone.

Recommended improvements

1. _should_retry_misrouted_needs_input unconditional fallthrough recycles every needs_input ticket

2. Location: Last line of _should_retry_misrouted_needs_input (~line 607): return True

3. Problem: After ruling out unanswered questions, done evidence, and review-ready evidence, any needs_input ticket assigned to a runnable worker with no human comment is unconditionally reset to todo — even when there's zero crash/error signal. This produced the 7 needs_input_runtime_failure_reset actions.
4. Change: return True → return False. The regex above already catches specific failure modes (crashed, timeout, harvest_timeout, etc.); without those keywords the ticket should stay put.

5. Expected effect: Reduces needs_input_runtime_failure_reset to only tickets with explicit error signatures; eliminates false resets.

6. repo_dirty_observed in the dev-loop trigger set fires on 38% of runs

7. Location: maybe_launch_operator_dev_loop, the trigger_actions set (~line 375)

8. Problem: repo_dirty_observed fires 19 times per 50 runs. The operator already creates/escalates a dirty-repo ticket for this; launching a full Claude dev loop on every dirty observation is disproportionate and is the primary driver of the 0.42 throttle ratio.
9. Change: Remove "repo_dirty_observed" from trigger_actions.

10. Expected effect: Dev-loop attempts drop sharply; throttle ratio falls well below 0.42.

11. worktree_reaper_ran is informational but triggers a dev loop

12. Location: Same trigger_actions set in maybe_launch_operator_dev_loop

13. Problem: The reaper already ran and reported its result; no anomaly needs investigation. Including it in triggers inflates the launch count.
14. Change: Remove "worktree_reaper_ran" from trigger_actions.

15. Expected effect: Further reduces unnecessary dev-loop launch attempts; marginal but clean.

16. Dev-loop throttle window (2 h) is too tight given the 30-min operator cadence

17. Location: _operator_dev_loop_throttled, timedelta(hours=2) (~line 401)

18. Problem: A 2-hour window allows at most one dev loop every four operator runs. Combined with the over-broad trigger set (fixed above), this produces 8 throttled attempts out of 19 triggers — nearly half the runs waste time hitting the throttle check and recording a no-op.
19. Change: timedelta(hours=2) → timedelta(hours=3).
20. Expected effect: After the trigger-set fix, this is a safety margin; it gives previous loops' fixes more time to take effect before re-triggering.