Fix stale auto-review scope and baseline reuse

[shiny-code-bot]

Finish Line

Background auto-review never reviews or retries a stale, wrong-worktree, wrong-branch, or giant unrelated scope. Scope failures become cheap, terminal, diagnosable events instead of possible launch/retry loops.

Current Status

State: Active candidate under #50.

Evidence from 2026-06-06:

• Auto-review run 398c40ae-0323-4e2b-9e01-46fbb80e8d01 failed in under a minute with: diff is 1479472 chars (limit 120000).
• The run record had branch=unknown, snapshot=unknown, changed_path_count=0, and a stale-looking base_commit recorded as an auto-review baseline snapshot.
• Local inspection showed the visible branch/worktree was small, while the review scope was broad enough to trip the raw diff guard.
• The failed run itself was cheap (~11.8k tokens), but this bug class can cause expensive background reviews if the stale/wrong diff is below the launch limit.

Acceptance Criteria

• Auto-review run records persist worktree path, branch, head, base, snapshot, changed path count, diff size, and a cheap scope fingerprint before scope-size validation can fail.
• review_scope_too_large is non-retryable for the same base/head/scope fingerprint and does not queue another pending review range automatically.
• Pending auto-review baselines are discarded when their commit is not appropriate for the current branch/worktree lineage.
• Auto-review baseline markers are keyed strongly enough by repo/worktree/branch or validated before reuse so a stale TUI session cannot review unrelated historical artifacts.
• Duplicate suppression works for too-large scopes as well as successful scopes.
• Tests cover stale baseline, branch/worktree mismatch, too-large scope metadata, and no retry after terminal scope failure.

Relationships

Parent: #50
Related: #92 for prompt/token/context visibility and #43 for the broader token-efficiency workstream.

[cbusillo]

Triage note after #399/#425: I inspected a fresh worktree at current origin/main (0b780ae30c) before starting a fix.

Mainline evidence:

• code-rs/core/src/review_store.rs, code-rs/core/src/review_coord.rs, AutoReviewRun, BackgroundReviewFinished, persist_auto_review_scope_metadata, and run_background_review are not present on origin/main.
• Current mainline review support is the Codex-shaped review/guardian surface documented in docs/auto-review-proof-metrics-parity.md and implemented through review/start, code-rs/core/src/session/review.rs, code-rs/core/src/tasks/review.rs, guardian assessment events, and TUI auto-review denial UI.
• Map Auto Review proof metrics onto Codex review primitives #400 already classified the deleted proof store/background reviewer as a rewrite/defer area rather than something to restore wholesale.

Conclusion for Codex alignment: the concrete stale-scope bug described here appears to belong to the old/deleted background review coordinator or a non-main branch, not the current mainline Codex-aligned review surface. I am not porting review_store.rs/review_coord.rs onto main just to fix that old implementation bug. A future slice should only add mainline proof fixtures around current review/guardian events, or reopen this as an implementation task if a background review coordinator is reintroduced deliberately.

[shiny-code-bot]

Rollout-friction audit follow-up from cbusillo/codex-skills #339 found another concrete stale auto-review surfacing case.

Evidence, 2026-06-14:

• Every Code repeatedly surfaced an auto-review ledger run as freshness=Current target=matching_head.
• The surfaced run was for detached proposal branch auto-review-628291b6, snapshot 628291b61b7d, with finding locations under /Users/cbusillo/.code/working/codex-skills/branches/auto-review-628291b6/....
• The active codex-skills checkout had already moved to origin/main after Require explicit worktree decisions before concurrent writes #357/fix(core): harden worktree decision gate #359/Expect worktree decision tool in OpenAI tool tests #360; the detached proposal was not the current work target.
• The codex-skills rollout classifier added in Expect worktree decision tool in OpenAI tool tests #360 classified the same ledger entry as detached_auto_review, actionable_by_default=false, recommended_action=ignore_or_summarize_as_stale_detached_noise, snapshot_matches_head=false, snapshot_matches_origin_default=false.

This seems related to the stale baseline/scope class here, but the user-visible friction is specifically ledger surfacing: stale detached proposal diagnostics can keep reappearing as if they apply to the active checkout. Acceptance criteria here should probably include that completed detached auto-review diagnostics whose snapshot/worktree no longer match the active target are suppressed, demoted, or explicitly labeled stale instead of shown as active matching_head findings.