# Feedback-driven Optimizer Attempt Review

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "feedback-driven-optimizer-attempt-review-2026-07-30",
  "problems": [
    {
      "problemId": "optimizer-repeats-horizontal-actions-without-attempt-diagnosis",
      "summary": "A rejected Recent Optimizer candidate can feed only changed paths and a challenger summary into the next patch run, so the next attempt may add more generic rules without distinguishing regressions, unresolved baseline gaps, fixed criteria, or criteria that must be preserved.",
      "status": "optimized_unverified",
      "issueKeys": ["*"],
      "sourceRefs": [],
      "signalTextIncludesAny": [
        "previous attempt review missing",
        "optimizer repeats horizontal prompt expansion",
        "candidate regression not diagnosed before next attempt",
        "rejected action repeated without bounded repair hypothesis"
      ],
      "observedThrough": "2026-07-30",
      "effectiveAt": "2026-07-30T16:02:20.000Z",
      "verifiedAt": null,
      "attemptedAction": "Run an isolated read-only planning session before every patch session; persist a bounded attempt plan and policy-approved candidate diff; classify baseline-to-challenger criteria as regression, preexisting_unresolved, fixed, inconclusive, preserved, or not_applicable in an attempt_review checkpoint; feed the gate delta, must-preserve criteria, and actions not to repeat into the next attempt.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/563"
    }
  ]
}
-->

- Optimization ID: `feedback-driven-optimizer-attempt-review-2026-07-30`
- Owner: auto-oncall-services
- Source: optimizer result review on 2026-07-30
- Implementation status: deployed to staging in revision `3efeb556`
- Effective status: `optimized_unverified`

## Bounded problem

The optimizer currently tells a later patch agent which paths changed and
provides a compact challenger summary, but it does not preserve the candidate
action or diff and does not diagnose the baseline-to-challenger delta. A later
attempt can therefore treat all remaining blocking gaps as newly introduced,
repeat a rejected action, or add another broad prompt rule while regressing a
criterion that already passed in the baseline.

## Candidate change

- Use a separate read-only Codex session to review prior attempts and return one
  structured repair plan before a workspace-write patch session starts.
- Require the plan to name one bounded problem cluster, the prior-attempt
  diagnosis, the attempted action, its repair hypothesis, target criteria,
  baseline criteria to preserve, material differences from rejected actions,
  and explicit non-goals.
- Persist the plan with the candidate. Persist a bounded unified diff only
  after all changed paths pass the existing candidate policy.
- After challenger evaluation, write an `attempt_review` checkpoint that
  classifies every case and criterion as `regression`,
  `preexisting_unresolved`, `fixed`, `inconclusive`, `preserved`, or
  `not_applicable`.
- Feed the structured review, candidate gate evidence, must-preserve criteria,
  candidate action and diff, and ineffective or rejected actions into the next
  planning session.
- Keep candidate-gate semantics, Draft-only behavior, deployment boundaries,
  and external write paths unchanged.

## Current evidence

Contract tests cover the classification boundary, checkpoint compatibility,
and next-attempt packet. The implementation is deployed, but it has not yet
run in a scheduled optimizer attempt or produced a post-change candidate, so
this record remains `optimized_unverified`.

## Unresolved gaps

- No live optimizer attempt has yet demonstrated that the planning session
  prevents a repeated or horizontally expanded action.
- The candidate diff is intentionally truncated and is evidence for review,
  not a replacement for the candidate commit.
- Full evaluation remains the acceptance gate; the attempt review does not
  change criterion meaning or candidate acceptance.

## Next validation action

After normal staging publication, observe the next rejected Focus attempt.
Verify that its `attempt_review` checkpoint distinguishes true regressions from
preexisting gaps and that the following plan targets one failure cluster,
preserves baseline-passing criteria, and does not repeat the rejected action.