Add auto-review and auto-drive budget guardrails

[cbusillo]

Objective

Add budget and stop-condition guardrails for auto-review and auto-drive loops so useful automation cannot churn indefinitely or silently burn rate limits.

Finish Line

Auto-review and auto-drive keep their Every Code value, but long-running or stuck loops have visible budgets, progress checks, and safe stop behavior.

Current Status

State: Active. Prerequisite #44 is complete, so this can proceed from scanner evidence rather than waiting on rollout/session token-efficiency instrumentation.
Next action: Inspect auto-review/auto-drive loop control, token accounting, and subprocess lifecycle behavior.
Blocked by: Nothing current.
Last verified: 2026-05-16 during cross-repo issue audit; stale native blocker edge to completed #44 was removed.

Scope

• In: Turn caps, token budgets, progress heuristics, stuck-process detection, subprocess status visibility, and user-facing warnings.
• Out: Disabling auto-review or reducing it to a cheap ineffective reviewer.

Acceptance Criteria

• Auto-review sessions expose current token/turn spend and model role.
• Stuck or non-progressing review loops stop or ask for escalation before large burn.
• Budget thresholds are configurable enough for power users but safe by default.
• The system distinguishes image-history bloat from ordinary review churn.

Relationships

Parent: #43
Completed prerequisite: #44
Related: model-role audit and local LLM sandboxing.

Validation

Reproduce a long-running review scenario and verify budget/stop behavior without losing useful review output.

Decisions

Auto-review is a flagship feature to preserve with guardrails, not remove.

Open Questions

What thresholds should apply by default for Pro/Team/high-budget users?

[cbusillo]

Issue hygiene note: this still appears to be legitimate work, not a stale close candidate, but its dependency/status text needs a refresh before implementation.

The issue currently references #44 and/or #45 as a blocker. Those issues are now closed, so before starting this work, update the Current Status, Blocked by, and validation plan with the evidence/results from the completed scanner/image-history work.

[shiny-code-bot]

Budget/stop-condition evidence from the same 2026-06-01 Launchplane stale Auto Review incident referenced in #76:

• A detached /review subprocess remained active for an older snapshot after the work had already merged/deployed.
• The review output JSON had not been written, but session-log token_count events were still advancing.
• The sampled process was about 56 minutes old, with total token counters above 13M for that review session.
• CPU time was low relative to wall time, which made it look “not busy” from ps, while the session log still showed model activity.

This suggests a useful guardrail should not rely only on process liveness or CPU. It should include age, target snapshot currentness, token/turn budget, output-json absence, and whether the active branch/head has already superseded the review target. The desired outcome is not necessarily killing every long review, but surfacing “long-running superseded review” and stopping/escalating before large token burn continues unnoticed.

[shiny-code-bot]

Status update, 2026-06-01:

PR #305 intentionally stays in the #76 correctness lane: stale, wrong-session, or metadata-free Auto Review completions should not surface as active findings. It does not implement the budget/stop-condition policy from this issue.

The recent stale-review incidents make the #50 scope sharper. The budget guardrail should evaluate more than process liveness or CPU use:

• target snapshot currentness vs active head/review epoch
• review age and last activity
• token/turn count from session logs or agent status
• missing output JSON while token counts continue advancing
• whether a newer/current review supersedes the older run

Recommended next slice after #305: define a review-run currentness/budget policy that can mark a long-running superseded review as historical, stop/cancel it, or escalate visibly without reducing useful current Auto Review coverage.

This should be tested with deterministic lifecycle/replay fixtures first, then optional real-model/exec harness evaluation for model and follow-up settings.