Operator Tuner Report — 2026-05-14

Window: last 24h (extended 72h for recurrence). Runs: 49. Total actions: 358. Avg actions/run: 6.31.

Action mix (recent window)

    49  run_start
    49  disk_worktree_snapshot
    49  memory_snapshot
    49  done_audit_summary
    49  run_complete
    22  blocked_lane_classification_summary
    12  active_lane_snapshot
    10  repo_dirty_observed
     9  operator_ticket_exists
     9  operator_dev_loop_throttled
     9  repo_dirty_all_known_generated
     7  todo_backlog_observed
     6  promote_dead_zone_ticket
     5  operator_dev_loop_finished
     5  create_operator_ticket
     3  blocked_lane_completed_marked_done
     2  stale_runtime_observed
     2  stale_runtime_marked
     2  stale_runtime_summary
     2  needs_input_reclassified_in_review
     2  worktree_reaper_ran
     2  terminal_ticket_runtime_closed
     1  operator_ticket_resolved
     1  active_lane_backlog_observed
     1  breakglass_recovery_recorded
     1  breakglass_dev_loop_finished

Signals worth tuning

• Recurring operator-ticket markers (>=3 in 72h): {'[operator:dirty-repo:workspace]': 14, '[operator:worktree-manual-review]': 3, '[operator:dirty-repo:mission-control]': 3, '[operator:dirty-repo:PKA]': 3}
• Weak-done reopens: 0
• Stale-runtime marks (extended window): 5
• Dev-loop throttle ratio: 0.64 (9 throttled / 5 finished)
• Repo-dirty observations: 10 (generated-only noise: 9)

Proposed patches

Operator Tuning Recommendations

1. Remove repo_dirty_observed from dev-loop trigger_actions

• Problem: The persistent workspace dirty-repo marker (14 recurrences in 72 h) is the dominant source of dev-loop triggers, but 5 launched loops over 24 h failed to resolve it — the dev loop can't fix what is likely an intentionally uncommitted or human-pending state.
• Location: maybe_launch_operator_dev_loop → trigger_actions set (the literal "repo_dirty_observed" member).
• Change: Delete "repo_dirty_observed" from the set. The dev-loop prompt already instructs the agent to inspect git state; an explicit trigger is redundant and circular.
• Expected effect: Eliminates ~10 spurious trigger attempts/day, cutting the throttle ratio roughly in half (0.64 → ~0.25). Only genuinely novel triggers (failures, backlog) remain.

2. Remove worktree_reaper_ran from dev-loop trigger_actions

• Problem: A successful reaper run (worktree_reaper_ran, 2 events) is not an anomaly — the reaper already handled it. Triggering a full dev loop is wasted effort; only the failure path (worktree_reaper_failed) is actionable.
• Location: Same trigger_actions set.
• Change: Delete "worktree_reaper_ran" from the set. Keep "worktree_reaper_failed".
• Expected effect: Removes ~2 unnecessary trigger evaluations/day. Modest but zero-risk reduction in dev-loop pressure.

3. Clear throttle state on dev-loop launch failure

• Problem: _operator_dev_loop_throttled writes the last_started_at timestamp before the subprocess is launched. If subprocess.run raises (timeout, binary missing, OOM kill), the 4-hour throttle is already persisted, blocking retries until it expires.
• Location: _operator_dev_loop_throttled (state file write at bottom of method) and _launch_operator_dev_loop (except block).
• Change: In the except block of _launch_operator_dev_loop, delete or overwrite state/luci_operator_dev_loop.json with a timestamp 4 hours ago (or remove it). This lets the very next operator run retry the launch. (The single-flight lock already prevents concurrent runs, so there is no race.)
• Expected effect: Failed dev-loop launches (e.g. operator_dev_loop_failed severity=critical) become self-healing within 30 minutes instead of being silenced for 4 hours.

4. (Too thin to act on) _GIT_KNOWN_GENERATED_PREFIXES may be incomplete

• Observation: 10 repo_dirty_observed + 9 repo_dirty_all_known_generated = 19 dirty checks that found changes. The 10 non-generated observations drive the noisy [operator:dirty-repo:workspace] recurrence. However, the actual filtered dirty paths are not visible in the report, so I cannot propose specific prefix additions.
• Recommendation: In the next operator revision, log the filtered sample (already collected in audit_git_state) into a dedicated lightweight sidecar or include it in the repo_dirty_observed action payload at higher verbosity. Re-evaluate once the actual paths are known.

Summary of expected signal impact: