Operator Tuner Report — 2026-05-18

Window: last 24h (extended 72h for recurrence). Runs: 48. Total actions: 474. Avg actions/run: 8.83.

Action mix (recent window)

    48  run_start
    48  disk_worktree_snapshot
    48  memory_snapshot
    48  done_audit_summary
    48  run_complete
    41  blocked_lane_classification_summary
    35  repo_dirty_observed
    34  operator_ticket_exists
    16  active_lane_snapshot
    13  promote_dead_zone_ticket
    12  terminal_ticket_runtime_closed
    11  todo_backlog_observed
    10  blocked_runtime_failure_reset
     9  operator_dev_loop_finished
     7  create_operator_ticket
     6  operator_dev_loop_throttled
     6  blocked_lane_completed_marked_done
     5  recent_task_failure
     4  active_lane_backlog_observed
     4  needs_input_runtime_failure_reset
     3  repo_dirty_all_known_generated
     3  memory_pressure_observed
     2  breakglass_noop_healthy
     2  worktree_reaper_ran
     2  stale_runtime_observed
     2  stale_runtime_marked
     2  stale_runtime_summary
     2  skipped_overlap
     1  pickup_direct_run
     1  operator_dev_loop_failed
     1  needs_input_runtime_reattached

Signals worth tuning

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

Proposed patches

Operator Tuner Recommendations (2026-05-18)

1. Remove active_lane_backlog_observed from the dev-loop critical bypass

• Problem: Any active_lane_backlog_observed action makes the next dev-loop launch unthrottled. Operator-created tickets (assigned to luci, status todo) inflate the active-lane count, so the operator's own escalation tickets can create a feedback loop that bypasses the 4-hour cooldown entirely.
• Location: maybe_launch_operator_dev_loop, the critical = (… or any(a.get("action") == "active_lane_backlog_observed" for a in self.actions)) clause.
• Change: Remove that or branch (or gate it on backlog_count >= ACTIVE_LANE_COUNT_TRIGGER * 2 to preserve escalation only for extreme cases).
• Expected effect: Active-lane-backlog triggers still fire the dev loop but respect the 4-hour throttle. Reduces launches from ~9/day toward the throttle ceiling of ~6/day. The [operator:active-lane-backlog] recurrence (5 in 72 h) should drop.

2. Add a reset-count guard to runtime-failure → todo resets

• Problem: blocked_runtime_failure_reset fired 10 times in 24 h. The operator has no cap on how many times the same ticket can be cycled blocked → todo → pickup → fail → blocked. The done-audit path already has _steward_reopen_count to prevent infinite reopens, but the runtime-failure reset path has no equivalent guard.
• Location: audit_blocked_lane_classification, the if needs_input_runtime_failure or blocked_runtime_failure: block (the self.record("blocked_runtime_failure_reset", …) / "needs_input_runtime_failure_reset" branches).
• Change: Before resetting to todo, count prior operator reset comments on the ticket (e.g. WHERE author = 'luci-operator' AND body LIKE '%runtime/worker failure%'). If count ≥ 2, skip the reset, record a new action (blocked_runtime_reset_cap_reached), and leave the ticket in blocked for human inspection.
• Expected effect: Prevents silent infinite reset loops on persistently-failing tickets. Caps the blocked_runtime_failure_reset and needs_input_runtime_failure_reset counts; persistently broken tickets surface as blocked instead of cycling invisibly.

3. Increase the dev-loop throttle window from 4 h to 6 h

• Problem: 9 finished + 6 throttled = 15 dev-loop attempts in 24 h. Each launch is an Opus session (timeout 3600 s). At 9 launches/day this is ≈ 1.5–9 hours of Opus compute daily. The 4-hour throttle was set before the critical-bypass paths existed; now that critical conditions (disk, memory) already bypass the throttle, the non-critical window can be more conservative.
• Location: _operator_dev_loop_throttled, timedelta(hours=4).
• Change: timedelta(hours=4) → timedelta(hours=6).
• Expected effect: Non-critical dev-loop launches drop from ≤6/day to ≤4/day. Combined with fix 1, total launches fall to roughly 4–5/day. Critical bypasses (disk/memory) are unaffected.

Signals explicitly too thin to act on

• [operator:memory-pressure] recurrence (3 in 72 h): Chrome remediation did not fire in the window, so pressure is from non-Chrome sources. The dev loop appears to be handling it. No operator-logic fix warranted without identifying the root process.
• [operator:dirty-repo:mission-control] recurrence (3 in 72 h): _is_known_generated only filters the workspace repo. Mission-control may have generated artifacts, but without a listing of what's dirty there, adding prefix entries would be guesswork. Needs one-shot investigation, not a blind code change.
• todo_backlog_observed (11) vs pickup_direct_run (1): The gap is explained by the backlog being below the TODO_BACKLOG_COUNT_TRIGGER=5 threshold on most runs — the observation fires on any non-empty backlog. Threshold is appropriate; no change needed.
• promote_dead_zone_ticket (13): Indicates a steady inbox→todo pipeline, likely from scheduled-task ticket creation. Fix would be upstream (create in todo directly), not an operator change.