Operator Tuner Report

Window: last 24h (extended 72h for recurrence). Runs: 41. Total actions: 584. Avg actions/run: 13.0.

Action mix (recent window)

    56  operator_ticket_exists
    47  repo_dirty_observed
    41  run_start
    41  disk_worktree_snapshot
    41  memory_snapshot
    41  done_audit_summary
    41  run_complete
    41  blocked_runtime_failure_reset
    40  blocked_lane_classification_summary
    27  promote_dead_zone_ticket
    25  active_lane_snapshot
    21  recent_task_failure
    19  todo_backlog_observed
    12  operator_dev_loop_throttled
    12  operator_dev_loop_finished
     9  skipped_overlap
     7  memory_pressure_observed
     7  stale_runtime_observed
     7  stale_runtime_summary
     6  repo_dirty_all_known_generated
     6  blocked_lane_completed_marked_done
     6  create_operator_ticket
     6  stale_runtime_marked
     5  pickup_direct_run
     4  active_lane_backlog_observed
     3  terminal_ticket_runtime_closed
     2  chrome_memory_pressure_remediated
     2  operator_dev_loop_failed
     2  attach_operator_context_to_closed_failure_ticket
     1  pickup_direct_run_failed
     1  defer_task_failure_to_watchdog
     1  needs_input_runtime_failure_reset
     1  breakglass_recovery_recorded
     1  breakglass_dev_loop_finished
     1  worktree_reaper_ran
     1  process_kill_intent

Signals worth tuning

Recurring operator-ticket markers (>=3 in 72h): {'[operator:dirty-repo:workspace]': 4, '[operator:ticket-backlog]': 3, '[operator:active-lane-backlog]': 3, '[operator:dirty-repo:mission-control]': 3, '[operator:memory-pressure]': 5}
Weak-done reopens: 0
Stale-runtime marks (extended window): 9
Dev-loop throttle ratio: 0.50 (12 throttled / 12 finished)
Repo-dirty observations: 47 (generated-only noise: 6)

Proposed patches

Operator Tuner Review — 2026-05-20

1. `TODO_BACKLOG_MINUTES_TRIGGER` is half the operator cycle, causing near-permanent escalation

(a) A 15-minute age threshold with a 30-minute operator cycle means any single todo ticket surviving one check will trigger pickup + a [operator:ticket-backlog] ticket on the next run, creating recurring noise (marker recurred 3× in 72h). (b) Constant TODO_BACKLOG_MINUTES_TRIGGER = 15. (c) Raise to 30 (one full cycle). Pickup still runs, but the operator ticket only opens when a ticket has survived a full cycle un-drained. (d) Reduces operator_ticket_exists / create_operator_ticket for the [operator:ticket-backlog] marker from ~3 recurrences toward 0–1, without reducing actual pickup throughput.

2. `blocked_runtime_failure_reset` fires every single run — no circuit breaker

(a) 41 resets in 41 runs (= 1.0 avg/run) means the same blocked ticket(s) cycle through blocked → todo → fail → blocked indefinitely. The operator resets them, pickup re-queues them, they fail the same way, and the operator resets them again next tick. (b) audit_blocked_lane_classification, the blocked_runtime_failure branch (~line 370), calls _transition_ticket_if_status with no reset-count guard. (c) Before resetting, count operator-authored comments on the ticket matching "runtime/worker failure" in the body. If the count ≥ 3, skip the reset and instead record a new action blocked_runtime_failure_circuit_breaker (severity warning), leaving the ticket in blocked for dev-loop / human attention. (d) blocked_runtime_failure_reset drops from 41/run toward 0 for stuck tickets; new blocked_runtime_failure_circuit_breaker action appears at most once per stuck ticket, improving the signal-to-noise ratio of the blocked-lane summary.

3. Dev-loop throttle window (6 h) suppresses half of detected triggers

(a) Throttle ratio 0.50 (12 throttled / 12 finished) means the operator detects actionable anomalies roughly every 3 h but can only launch a dev-loop every 6 h. Meanwhile, recurring markers (memory-pressure 5×, dirty-repo 3–4×) suggest the anomaly window where a dev-loop could act is being missed. (b) _operator_dev_loop_throttled, the two occurrences of timedelta(hours=6). (c) Reduce throttle window from 6 to 4 hours. This allows up to 18 launches per 72 h (vs. 12), aligning better with the observed trigger cadence. (d) Expected throttle ratio drops from 0.50 toward ~0.25. More dev-loop attempts on recurring markers; slight increase in opus spend (estimated +33%).

4. Memory-pressure marker recurs 5× in 72h — signal is too thin to act on

The operator is correctly detecting real memory pressure and auto-remediating chrome (2×). The recurrence reflects an external root cause (chrome RSS regrowth), not an operator defect. The chrome trigger thresholds (CHROME_RSS_MB_TRIGGER = 2048, CHROME_PROCESS_COUNT_TRIGGER = 20) are reactive-only (fire during pressure). A proactive threshold would require architectural changes; skip for now. No change recommended.

5. Repo-dirty known-generated filter only covers workspace — thin signal

repo_dirty_all_known_generated fires 6× (all workspace). Mission-control and PKA have zero noise observations this window, so extending _is_known_generated to other repos has no current effect. Skip — revisit if mission-control generated-artifact noise appears in a future report.

Operator Tuner Report — 2026-05-20