⌂ Home ☷ Board

Operator Tuner Report — 2026-05-12

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

Action mix (recent window)

    63  recent_task_failure
    48  run_start
    48  disk_worktree_snapshot
    48  memory_snapshot
    48  done_audit_summary
    48  run_complete
    44  blocked_lane_classification_summary
    15  create_operator_ticket
    14  repo_dirty_observed
    10  operator_dev_loop_throttled
     8  operator_dev_loop_finished
     8  needs_input_runtime_failure_reset
     7  active_lane_snapshot
     4  promote_dead_zone_ticket
     3  todo_backlog_observed
     2  terminal_ticket_runtime_closed
     1  worktree_reaper_ran
     1  blocked_lane_completed_marked_done
     1  needs_input_reclassified_in_review
     1  repo_dirty_all_known_generated
     1  reopen_weak_done_ticket
     1  stale_runtime_observed
     1  stale_runtime_marked
     1  stale_runtime_summary

Signals worth tuning

Reopened-ticket outcomes (current MC state)

Proposed patches

Operator Tuner Review — 2026-05-12

1. _should_retry_misrouted_needs_input unconditionally returns True

Problem: The method's final return True (line ~610) makes it always return True regardless of whether failure evidence was found. Every needs_input ticket without an unanswered question gets reset to todo — 8 resets in 24h, likely feeding the active-lane congestion that produces 6 [operator:active-lane-backlog] markers.

Location: _should_retry_misrouted_needs_input, the last line return True.

Change: Replace return True with return False. Only tickets whose haystack matches the crash/runtime-failure regex should be retried.

Expected effect: needs_input_runtime_failure_reset count drops to only genuinely failed sessions; active-lane backlog signal should soften.

2. Dev-loop throttle window too short

Problem: Throttle is 2 hours (timedelta(hours=2) in _operator_dev_loop_throttled, ~line 465). With the operator running every 30 min, the loop can only fire once every 4 runs, producing a throttle ratio of 0.56 (10 throttled vs 8 finished). Most non-critical triggers are being suppressed.

Location: timedelta(hours=2) inside _operator_dev_loop_throttled.

Change: Increase to timedelta(hours=4).

Expected effect: Throttle ratio drops; dev loops finish before being re-throttled, reducing stale re-trigger cycles.

3. \blog\b in STRONG_EVIDENCE_PATTERNS is too broad

Problem: The pattern re.compile(r"\b(screenshot|artifact|report|document|dashboard|log)\b", re.I) matches "log" in any context (e.g., "checked the log," "saw nothing in the log"). This falsely classifies weak completions as strongly evidenced, suppressing valid reopens. Combined with only 1 reopen in 24h and 500 audited done tickets, the operator may be missing weak completions.

Location: STRONG_EVIDENCE_PATTERNS, the tuple entry containing "log".

Change: Remove \blog\b from the alternation, or narrow to \blog\s*(file|entry|line|output|stream)\b.

Expected effect: Slight increase in legitimate reopen_weak_done_ticket actions; fewer false-strong classifications.

4. [operator:dirty-repo:workspace] re-created cyclically (41 markers / 72h)

Problem: _ensure_operator_ticket only checks for open (non-terminal) tickets. A dev loop or manual action resolves the ticket → next operator run sees the still-dirty repo → creates a new ticket. This cycle accounts for 41 markers in 72h and is pure noise for a persistent condition the system already knows about.

Location: _ensure_operator_ticket → the SELECT query checking status NOT IN ('done', 'cancelled').

Change: Extend the query to also match tickets resolved in the last 4 hours (e.g., OR (status IN ('done','cancelled') AND updated_at >= datetime('now','-4 hours'))). If a recently-resolved match exists, record operator_ticket_recently_resolved and return without creating a new ticket.

Expected effect: create_operator_ticket count for dirty-repo:workspace drops from ~15/day to near-zero until the dirty file set actually changes; reduces MC ticket churn significantly.

Skipped (too thin to act on)