# Auto mode — complete process

Use this process for `/affinage --auto --stake <floor>`.
Also use it for `--plate`, which adds `--stake medium+ --open-pr`.
`SKILL.md` defines the decisions.
This file defines each step.

- Skip the selection gate.
- Send merge conflicts to `/melt` before `/cure`.
- Stop with `status: halt: merge-conflicts-need-human` when `/melt` cannot resolve them.
- Run the fresh review in standalone mode unless the user passes `--no-age`.
- Add `[from-age:…]` findings to the automatic selection.
- Select every finding that meets the floor.
- Include cheap, contained low findings when the floor is `medium+`.
- Send `/cure --auto --stake <floor>`.
- Wait for `/cure` and its `/age --scope --auto` chain to stop.
- Post replies only for the original graded claims.
- Do not grade findings from `/age --scope` again.
- Post the prepared push-back for each `Reviewer-rejected` claim.
- Post a specific follow-up note for each `Needs-investigation` claim.
- Name the test, prototype, or evidence that can confirm the claim.
- Use `Needs <evidence> to confirm — will follow up with the result.`
- Do not run the investigation in auto mode.
- Post all replies before terminal `/plate` publishes fixes.
- Send terminal `/plate --open-pr [--hard]` only when the working tree has a change.
- Treat a merge conflict that `/melt` resolved as such a change.

Keep the complete cure chain in the parent affinage context.
The parent must retain finding slugs, comment identifiers, tags, and reply text.
A child agent cannot post these replies reliably.

If no finding meets the floor, skip `/cure`.
Post only rejection and investigation replies.
Exit with `status: ok / next: done`.

# `/affinage` bundle commands

`scripts/render_generated_regions.py` generates this file from the static `COMMANDS` manifest in `src/easy_cheese/skills/affinage/commands.py`. Do not edit this file. Run each command as `python3 skills/affinage/scripts/affinage.pyz <command> [args...]`. Each command returns an integer exit status. Pass `--help` to a command for its arguments and output format. Keep worked examples in the skill instructions.

| Command | Purpose | Subcommands |
| --- | --- | --- |
| `age-route` | Size an /age review into single-pass or fan-out lanes (JSON in, JSON out) |  |
| `post-reply` | Post a PR reply carrying the mandatory agent attribution |  |
| `pr-status` | Fetch a PR's build and merge status for grading |  |
| `review-surface` | Score the reviewable git surface that routing sizes against (JSON out) |  |
| `wheypoint-resolve` | Resolve a phase slug through the shared Wheypoint kernel (JSON out) |  |

# Flow command and reason details

Use this file for `## Flow` steps 2, 3, 6, and 9.
It gives exact commands, exit codes, and grading rules.

## Step 2 — Fetch PR status

Run `python3 skills/affinage/scripts/affinage.pyz pr-status <pr>`.
The command returns JSON with build status, failed check summaries, failed test names, and merge state.
Each failed check summary includes approximately 10 final log lines.

- **Exit 3** means `logs-expired`.
  CI fails, but no failed check has usable logs.
  Write `status: halt: pr-status-logs-expired` and stop.
  Tell the user to rerun failed jobs with `gh run rerun <run-id> --failed`.
  Read `<run-id>` from the `/actions/runs/<id>/` URL segment or `gh pr checks`.
  Then tell the user to run `/affinage` again.
- **Any other nonzero exit** means the PR or GitHub status is unavailable.
  Exit 1 identifies a PR or API error.
  Exit 2 identifies a missing `gh` binary.
  Write `status: halt: pr-status-unavailable` and stop.

## Step 3 — Fresh review

Score the PR diff with the `review-surface` command.
Run `python3 skills/affinage/scripts/affinage.pyz review-surface --repo . <base>...HEAD`.
Use the complete PR range against its base branch.
After checkout, use `origin/<base>...HEAD`.
Do not use the bare `HEAD` default because it scores only uncommitted changes.

Build the evidence-bearing review context described in `../../age/references/fan-out.md`.
Include all changed paths, even when their workload weight is zero.
Use `entry="affinage"`, `comments=<unresolved-thread-count>`, and `ci_class=<"passing"|"failing"|"red"|"flaky"|null>` alongside `context`.
The router preserves comment-count and CI workload escalation.
Use normal review effort unless the user explicitly selects quick or deep.

Run `python3 skills/affinage/scripts/affinage.pyz age-route <request.json>`.
The command reads the contextual request and emits a deterministic subject plan.
Pass the complete plan and its evidence to `/age`, not the old dimension-lens tuple.
Then treat each `/age` finding as an additional claim.

## Step 6 — Grading rules

- Grade every failed check, including build, compile, lint, type, and test failures.
- Send failed checks to `/cure` like test failures.
- Tag each CI finding with `[from-check:<job>]`.
- Keep the existing dimension and severity for each fresh review finding.
- Tag each fresh review finding with `[from-age:<dimension>]`.
- Remove a duplicate fresh review finding when a reviewer reports the same defect.
- Keep the reviewer claim because it requires a reply.
- Record `CHANGES_REQUESTED` as `reviewer-asserted:` metadata.
- Do not use reviewer urgency to calculate severity.

Use these report sections:

- Put grounded claims with contained fixes in `## Blocker`, `## High`, `## Medium`, or `## Low`.
  Add a `[<dimension>:<severity>]` tag to each claim.
  Map style and quality claims to `deslop`.
  Add a `source: from-comment:<id>` line so `/cure` can reply.
  Prefer a cheap fix to push-back.
- Put plausible claims that need outside evidence in `## Needs-investigation`.
- Put wrong or unsupported claims in `## Reviewer-rejected`.
- Also put valid but large claims in `## Reviewer-rejected`.
  Large claims have `fix-cost-now: moderate` or `sprawling`.
  Structural later work is also large.
  Reject a wrong claim.
  Defer a large claim.

## Step 9 — Reply rules

Post approved replies with `python3 skills/affinage/scripts/affinage.pyz post-reply`.
Do not post with `gh api` because it omits the required attribution.

- Post the prepared push-back for `Reviewer-rejected` claims.
- Do not post a general acknowledgement for `Needs-investigation` claims.
- Name the exact evidence that can confirm each investigation claim.
- State that a follow-up will report the result.
- Offer to run the investigation before you post.
- Use `/pasteurize` for a regression test.
- Use `/briesearch` for evidence outside the diff.
- Post the actual result when the user accepts the investigation.
- Post the explicit follow-up note when the user declines.
- Do not reply to `[from-check:<job>]` or `[from-age:<dimension>]` findings.

# Handoff gate templates

Read this when rendering either handoff gate from `SKILL.md`.
Use the exact option text below.

## Cure selection gate

Show the recommended composite first.
Then show all five floor options in this order:

1. `all-medium, cheap`
2. `all`
3. `all-medium`
4. `all-high`
5. `all-blocker`

Use the labels and rules from [`../../age/references/handoff-detail.md`](../../age/references/handoff-detail.md).
Then show these options:

- **Pick findings to fix** — Accept `1,3,5`, floor names, `cheap`, `all`, `none`, or `skip N`.
- **Resolve merge conflicts** — Show this option only when the PR has conflicts.
  Check out the PR.
  Run `/melt`.
  Then show the gate again.
- **Stop — leave the report for later** — Treat this option as `none`.

Show all five floor options on every run.
Treat an empty selection as `none`.

## Reply approval gate

Show one batch gate before every `post-reply` call.
Show the gate after `/cure` returns.
Include every drafted reply in the gate.
A drafted reply is an applied reply, a deferred reply, a push-back draft, or an investigation note.
Read the applied and deferred replies from `.cheese/cure/pr-<n>.md`.

- **Post push-back drafts only** *(recommended)* — Post rejected drafts and hold every other reply.
- **Investigate now, then post** — Investigate each claim and post its actual result.
  Use `/pasteurize` for a regression test.
  Use `/briesearch` for evidence outside the diff.
- **Post all** — Post every applied reply, every deferred reply, and every push-back draft.
  Also post each specific investigation note without prior investigation.
- **Skip posting** — Post nothing and leave the report for later.
- **Per-finding** — Let the user select any drafted reply to post.
  Let the user also select a claim to investigate.

## Cure dispatch context

When the selection is not empty, send `/cure <slug> [--safe] [--open-pr] [--hard]` immediately.
Include this locked context:

```yaml
handoff_context:
  source_skill: /affinage
  source_report: .cheese/affinage/pr-<n>.md
  selection: "<verb or explicit ids>"
  resolved_ids: [<expanded ids>]
```

`/cure` confirms each selected identifier and applies the fixes.
It runs its `/age --scope` loop but does not run terminal `/plate`.
Affinage owns publication because `source_skill` is `/affinage`.
Pass `--safe`, `--open-pr`, and `--hard` to `/cure` when they apply.

# Merge conflict resolution

A PR cannot merge when `pr-status` reports `merge.mergeable: CONFLICTING` or `merge.state: DIRTY`.
Send conflicts to `/melt`.
Do not resolve them by hand.
`/melt` runs mergiraf, rerere, and kdiff3.

1. Run `gh pr checkout <pr>`.
2. Run `git merge origin/<base>` to create the local conflicts.
3. Send the conflicts to `/melt`.
4. Show any squash residue remedy from `/melt` without changes.
5. Keep the resolved merge in the local working tree.
6. Let `/plate` own the resolution commit and the PR update.

In default and `--auto` modes, run checkout and `/melt` before `/cure`.
`/melt` leaves the resolution uncommitted.
Treat a resolved merge as a publishable change.
If `/melt` cannot resolve the conflicts, write `status: halt: merge-conflicts-need-human` and stop.
Run terminal `/plate` after every approved reply posts.
Then run `python3 skills/affinage/scripts/affinage.pyz pr-status` again to confirm that the conflicts are gone.

In `--safe` mode, require approval before checkout and `/melt`.
Include `Resolve merge conflicts` in the cure selection options.

# Affinage report template

Use this example for `.cheese/affinage/pr-<n>.md`.
Keep the four-line handoff slug from `SKILL.md` before these sections.
Downstream skills parse that slug.

Each severity bullet uses the shared finding grammar.
The bullet holds one `[<dimension>:<severity>]` tag, then the location in backticks, then the summary.
`/cure` parses that grammar with `findings`.
Put the provenance tag on an indented `source:` line under the bullet.
The `## Needs-investigation` and `## Reviewer-rejected` sections do not use this grammar.
`/cure` does not parse those two sections.

```markdown
# Affinage Report — PR #<n>

## Orientation
<one or two facts about the PR and the graded claims>

## PR status
- Build: passing | failing (N jobs)
- Merge: clean | conflicts (resolved via /melt | needs human)
- Comments: K unresolved (M skipped as outdated)
- Fresh review: ran /age (N findings) | skipped (chained) | skipped (--no-age)

## Blocker
- **[security:blocker]** `src/auth.ts:42` — The code parses a token without validation.
  - source: from-comment:<id> · author: alice
  - location: contract · fix-cost-now: contained · fix-cost-later: structural · confidence: certain
  - reviewer-asserted: changes-requested
  - recommendation: Validate `authorization`. Return 401 when the header is absent.
- **[correctness:blocker]** `tests/auth.test.ts` — Three tests fail in CI job `test-suite`.
  - source: from-check:test-suite
  - location: contract · fix-cost-now: contained · fix-cost-later: structural · confidence: certain
  - recommendation: Add the absent null check. Then run the tests again.
- **[correctness:blocker]** `src/auth.ts:42` — `tsc` reports `'token' is possibly undefined` in CI job `build`.
  - source: from-check:build
  - location: contract · fix-cost-now: contained · fix-cost-later: structural · confidence: certain
  - recommendation: Narrow `token` before use. The build cannot pass until this compiles.
- **[efficiency:high]** `src/api/users.ts:88` — The fresh review found a user fetch in each loop iteration on the hot path.
  - source: from-age:efficiency
  - location: module · fix-cost-now: contained · fix-cost-later: contained · confidence: speculating
  - recommendation: Move the fetch before the loop.

## High
... (use the same format)

## Medium
... (use the same format)

## Low
- **[deslop:low]** `src/utils/format.ts:18` — The name `data` does not state what the value holds.
  - source: from-comment:<id> · author: copilot
  - location: class · fix-cost-now: contained · fix-cost-later: contained · confidence: certain
  - recommendation: Rename `data` to `lineItems`. Send this cheap fix to `/cure`.
... (use the same format; collapse it by the --full rules)

## Needs-investigation
- **[from-comment:<id>]** bob on `src/api/users.ts:108` — "This might break the analytics pipeline."
  - reason: The claim is plausible. The pipeline is in another repository.
  - suggested action: Read `analytics-svc/consumers/users.ts`.

## Reviewer-rejected
- **[from-comment:<id>]** copilot on `src/auth.ts:30` — "This needs `await`."
  - reason: `parseToken` returns `string`, not `Promise`. See `src/auth.ts:12`.
  - draft reply: "`parseToken` returns `string` here. No promise exists, so I will keep the current code."
- **[from-comment:<id>]** dana on `src/api/users.ts:60` — "Extract a generic repository layer."
  - reason: The change needs six files in two slices. It exceeds this PR scope.
  - draft reply: "This cross-slice refactor exceeds this PR scope. I will record it as follow-up work."

## Confidence
<certain | speculating | don't know> — <one reason for the confidence>

## Next step
Send the recommended findings to `/cure`.
Hold prepared replies for the reply approval gate.
Post directly only in `--auto` mode.
Post replies before terminal `/plate` publishes fixes.
Show the cure selection gate when `--safe` is active or an ask reason exists.
```

Omit empty severity sections.
Omit `## Needs-investigation` and `## Reviewer-rejected` when they are empty.

Use the confidence scale from `../../age/references/voice.md`.
Use `certain` when direct evidence confirms the defect.
Use `speculating` when indirect evidence supports the defect.
Put a `don't know` claim in `## Needs-investigation`, not a severity section.

Use only `class`, `module`, `cross-module`, or `contract` for `location:`.
See [`../../age/references/dimensions.md`](../../age/references/dimensions.md).