# Daily Recent Optimizer

> Superseded by `2026-07-15-focus-issue-resumable-optimizer.md`. The checked-in
> Active Focus and daily optimization Issue contracts below are historical.

## Current Design

- The daily quality report and GitHub issue already surface recent bad-case
  signals. They remain observation outputs, not a second evaluation source.
- `evaluation/recent/active-focus.json` is the canonical single Active Focus.
- `npm run evaluate:recent` can replay and judge that focus, but a person still
  has to inspect the failure, edit the repository, rerun it, and open a PR.
- Staging already has the Jira, diagnostic-provider, Codex, and GitHub
  credentials and skills needed by the evaluation path.

## Risks

- Letting the support worker edit its own checkout would mix online serving and
  optimization state.
- Giving the patch Agent Jira, provider, or GitHub credentials would broaden a
  code-generation task into an external-action task.
- A candidate could make the evaluator easier instead of fixing the support
  capability.
- Repeated schedules could create duplicate branches or PRs for one focus.
- Automatically selecting a new direction after one pass would lose focus and
  make the business priority implicit.

## Target Contract

One staging-only Kubernetes CronJob runs after the daily report window:

```text
Active Focus
  -> baseline Recent Evaluation (read-only external access)
  -> if pass/inconclusive: stop
  -> sanitized failure packet
  -> isolated Codex patch Agent (workspace write, no network or service secrets)
  -> deterministic changed-file policy + full tests
  -> challenger Recent Evaluation (read-only external access)
  -> only if pass: push branch and open Draft PR
```

- The task keeps retrying the same Active Focus until it passes or a Draft PR
  already exists. It does not choose the next focus.
- Baseline and challenger use the same manifest and current Recent Evaluation
  contract.
- The patch Agent receives only the bounded evaluation packet. Jira, provider,
  and GitHub credentials are removed from its process environment.
- Evaluation harness, deployment, credentials, Jira write paths, and GitHub
  write paths cannot be changed by a generated candidate.
- The controller owns git push and Draft PR creation after all gates pass.
- No automatic merge, deployment, customer-visible reply, Jira write, or
  production operation is allowed.

## Implementation Steps

1. Let `evaluate:recent` atomically persist its structured report.
2. Add a daily optimizer controller that clones `main` into an isolated temp
   directory, runs baseline, prepares the sanitized packet, invokes Codex,
   validates changed files, runs tests, and runs challenger.
3. Add idempotent Draft PR discovery and creation for one Active Focus.
4. Add a staging-only CronJob scheduled after the 18:00 Asia/Shanghai report.
5. Keep the feature disabled unless the CronJob explicitly sets the optimizer
   role; do not add it to prod.

## Verification Checklist

- Report output is written atomically and is valid JSON on pass, fail, and
  inconclusive results.
- A baseline pass or inconclusive result does not invoke the patch Agent.
- The patch Agent environment contains no Jira, provider, database, Lark, or
  GitHub credentials.
- Forbidden or excessive file changes stop before tests, push, or PR creation.
- Failed tests or a non-pass challenger produce no branch or PR.
- An existing open Draft PR for the focus makes the run idempotently stop.
- A passing challenger creates one Draft PR with baseline/challenger evidence.
- The CronJob cannot overlap with itself and is absent from prod.

## Non-Goals

- Do not fix the current Investibook routing defect by hand in this change.
- Do not automatically replace the Active Focus.
- Do not create Regression Evaluation yet.
- Do not auto-merge, deploy, or change customer-visible automation.