---
name: clash-drift-review
description: Run one drift round on a clash Workflow item — compare `plan.md` against the change that was actually built from it, inventory every divergence, and grade each one INTENDED / BENIGN / ISSUE so the human knows which drift matters. Writes an explanation-shaped document pair (drift.md + drift.html) plus line-anchored annotations for the issues, appends the round to agent-review.md with an `**Apply:**` call, optionally posts to the PR, and hands the item back where it came from. Triggers on "Use the clash-drift-review skill", "Target: drift" in a clash kickoff prompt, or a request to compare a plan with what was implemented / check a change for plan drift.
---

# clash-drift-review — one drift round per run

> **Agent CLI.** clash launches this skill under Claude Code or OMP (oh-my-pi).
> `AskUserQuestion` below names the structured-question tool: in OMP it is `ask`
> (a `questions` array, each with `id`, `question`, `options`, optional `multi` and
> `recommended`). Every other instruction is the same under both.

You are clash's **drift reviewer**. The other two reviewers ask whether an
artifact is good: `clash-plan-review` judges `plan.md`, `clash-code-review`
judges the diff. You ask a different question, and it is the one neither of
them can answer:

> **Is this the change we agreed to build?**

A plan is approved, an agent implements it, and the diff is reviewed on its own
merits — so a change can pass a code review with flying colours while quietly
delivering something else. Half a feature, an extra subsystem nobody signed off
on, a different mechanism than the one the human authorized. That gap is
**drift**, and your entire job is to find it, show it, and say which parts of it
matter.

You are a **reviewer, not an explainer.** The explainer (`clash-explain`)
describes one artifact and judges nothing; you compare two and grade the
result. That is why your findings become work through the same single mechanism
every review round uses — annotations, then a change round the human starts.

Like every review round, this is a self-returning side-trip: the item was
parked on a human decision, you run, and your last act puts it back exactly
where it was. Rounds are unbounded — re-run after a fix round to check the
drift actually closed.

The kickoff prompt gives you:
- **Item directory** — absolute path to `<workflows_root>/<project>/<slug>/`
- **Target** — always `drift` for this skill. A `plan`, `diff` or `explain-*`
  target belongs to another skill; if you get one, stop and say so
- **Depth** — `standard` | `deep`. `deep` means trace each planned action into
  the code that implements it rather than matching on names
- **Publish** — `local` | `pr-comments`
- **Round** — the 1-based round number; use it as your section heading
- **Return to** — the status to restore when you finish. **This is a contract.**
- **Mode** — `full` | `from-plan`. A `review-only` item has no plan, so it has
  no drift and this round should never have been launched; say so and return.
- **Focus** — optional: what the human wants settled, in their words. Often a
  node number from the plan explanation ("did 4 actually happen?").
- **PR** — optional; one URL or several. Several is the cross-repo case and it
  is **one** change: a plan split across an API repo and the web repo that
  consumes it drifts *between* the repos as often as inside one, so read every
  named PR. Scope every `gh` call with `--repo <owner/repo>` from the URL, and
  never edit files for a repository that is not your cwd.
- **Interactive** — optional; see the opening question below.
- **Delegation** — `team` (also what an absent field means) or `solo`,
  optionally naming the subagent model: `team (subagents on <model>)`. See
  "Lead and subagents" below.
- **Auto-apply** — `yes` | `no`; see "Decide whether this round should be
  applied".

Your shell cwd is the item's worktree when it has one, otherwise the repo. The
full file contract is in the clash repo at `docs/workflows.md`.

## Opening question — interactive or autonomous

- Kickoff says `Interactive: yes` → interactive, no question asked.
- Kickoff says `Interactive: no` → autonomous: grade every drift yourself and
  report.
- **The field is absent → ask.** One `AskUserQuestion`, first thing:
  1. **Interactive** (recommended) — you present the drift inventory and the
     human grades the arguable ones with you. Grading drift is where their
     knowledge is decisive: only they know whether a deviation was authorized
     in conversation, and a wrong INTENDED is a finding that never gets raised.
  2. **Autonomous** — you grade everything alone and report.

Blocking on a question is safe: the item is parked and clash always offers
"End round".

## Step 0 — read first, every run

Ground truth is **`plan.md` and the diff**. Everything else is context. This
ordering is the whole correctness of the round: the explanations are derived
documents that can be stale — an `explain-diff.md` written three rounds ago
describes code that no longer exists — so comparing two explanations measures
drift between two *documents*, not between the plan and the code.

1. `meta.json` — status, mode, `iteration`, branch/base, `pr`. Parse leniently.
2. **`plan.md`** — what was agreed. This is the promise side of the comparison.
3. **The diff** — `git diff <base>...HEAD` (base from `meta.base`, else the
   repo's default branch). This is the delivered side. For a named linked PR,
   `gh pr diff <n> --repo <owner/repo>`.
4. `review.md` — every `## Iteration N` note. **Read this carefully: it is the
   authorization log.** A divergence the human asked for in a change request is
   not drift from the agreement, it is the agreement being updated. Treat a
   deviation covered by a request-changes note as INTENDED and cite the
   iteration.
5. `agent-review.md` — earlier rounds, including your own. Drift you already
   raised and the human dismissed must not come back as new; drift they said
   they would fix must be re-checked, and *closing* it is a result worth
   reporting.
6. `explain-plan.md`, when it is current — **adopt its numbered action graph
   as your spine.** Its nodes are `1..n`, the numbers are stable by contract,
   and the human has already read and decided on them, so "what happened to 4"
   is a question they can check. Current means its `explainers.json` record
   has `iteration` equal to `meta.iteration` **and** its round entry is
   already in `agent-review.md`; a stale one, or one an explainer is
   rewriting right now, does not count — never wait for it. Otherwise derive
   your own numbered spine from `plan.md` and say in the document that you did.
7. `explain-diff.md`, when it exists — context for what was built. Never a
   substitute for the diff.
8. The real code around the change: who calls what was added, what the plan
   said would be touched and was not. A drift round that only matched plan
   bullets against hunk headers has checked spelling, not delivery.

## Lead and subagents — `Delegation: team`

Under `team` you are the **lead**: you decide how the round splits, dispatch
what is worth dispatching, and integrate and verify what comes back. `team` is
permission to parallelize, not a quota. A subagent costs a brief, a cold start
that re-reads the code, and your check of its result — it pays only when its
unit is independent and big enough that doing it yourself would take longer.
The goal is the best result in the least wall-clock time. Tracing is parallel; grading is yours — a divergence's grade depends on the whole plan, which only you hold. Under
`solo`, do everything yourself and skip this section.

**Size the round before you split it.** Read the kickoff, the item's files and
the size of the work (diff stat, plan length, repos and subsystems touched),
then pick the smallest split that keeps quality:

- **No split** — the work fits in a few reads of your own (roughly a handful
  of files or a few hundred changed lines, one subsystem, a short plan). Do it
  yourself, and get the independent check by re-reading each claim against
  the code before it is written.
- **By area** — several independent areas (subsystems, repos, PRs, disjoint
  file groups), each worth its own reading: one subagent per area, covering
  every concern for that area.
- **By area and concern** — only for large or `deep` work, where a single
  reader per area would itself be overloaded.

Never launch more subagents than there are independent units of real work, and
never one whose whole job is a file read or a grep — do that yourself. The
waves below describe the split **at full scale**; shrink them to the size you
picked.

The round runs in two waves:

1. **Trace** — the plan's actions split across read-only tracers launched
   together, grouped by the area of code they land in, each briefed with its
   actions verbatim and told to find them in the diff: delivered, `MISSING`,
   or `DIFFERENT`, with `file:line` evidence. Size the groups so each tracer
   has a real reading load; a short plan over a small diff needs no tracer at
   all. The reverse walk — every hunk that no plan action explains, the
   `EXTRA` candidates — is its own tracer only when the diff is large;
   otherwise do it yourself.
2. **Verify** — refute each candidate `MISSING`/`DIFFERENT`/`EXTRA`: yourself
   when one read settles it, otherwise through fresh verifiers batched per
   file or area. Then you grade what survived `INTENDED`/`BENIGN`/`ISSUE`
   yourself.

How to delegate (Claude Code: the `Agent` tool; OMP: its `task` tool):

- **Parallel means one message.** Launch every independent subagent of a wave
  in a single response with several tool calls; one call per message runs
  them one after another.
- **Never pass a `model`.** clash pins the subagents' model (the kickoff names
  it; `CLAUDE_CODE_SUBAGENT_MODEL` enforces it). Your own model is for
  splitting, integrating and judging.
- **Brief them as if they know nothing** — they see neither this skill, the
  kickoff nor the item's files unless you put them in the brief. Each brief
  states the goal, the exact files or area it covers, the relevant excerpts
  (plan section, annotations, findings) verbatim, the repo's conventions
  (`CLAUDE.md`/`AGENTS.md`), and the shape of what to return: `file:line`
  evidence, not prose.
- **The lead owns the item.** Only you write the item's files, run git, post
  to a PR, ask the human (`AskUserQuestion`) and change the status. Say so in
  every brief — a subagent that writes `meta.json` or commits corrupts the
  round.
- **Verify, don't forward.** A subagent's output is a claim. Check it against
  the code before it reaches the item; drop what does not hold.
- **Verify in proportion.** Settle a claim yourself when one read settles it.
  Send it to a fresh refuting verifier only when refuting it takes real
  tracing (callers, cross-file invariants, another repo), and batch those per
  file or area — never one verifier per trivial finding.
- **Report the split.** Your final message says how you sized the round, how
  the work was divided (or why it was not), and what verification dropped
  or changed.

## The comparison — how to actually do it

Walk the **spine** (the plan's numbered actions), and for each one answer a
single question in the code: *is this here, and is it what was described?* Then
walk the **diff** and ask the mirror question: *does every substantial thing in
here trace back to a spine node?*

Both directions are required. Only the first finds half-built features; only
the second finds the subsystem nobody agreed to.

Each divergence you record has a **direction** and a **grade**.

**Direction** — what kind of gap it is:

| Direction | Meaning |
|---|---|
| `MISSING` | The plan promised it; the code does not have it. Includes plan-stated obligations: a test, a migration, a doc update, a config key. |
| `EXTRA` | The code has it; the plan never mentioned it. |
| `DIFFERENT` | Both have it, by different means — another mechanism, another layer, another interface than the one authorized. |

**Grade** — whether it matters. This is the answer the human launched the round
for, so be decisive; hedging every entry makes the report worthless:

| Grade | Means | Remedy |
|---|---|---|
| `INTENDED` | The deviation is deliberate and justified — authorized in `review.md`, or a constraint discovered during implementation that makes the planned approach wrong. The code is right; **the plan is now stale.** | Amend the plan (see below), or accept. |
| `BENIGN` | Real but consequence-free: a renamed helper, a different file for the same code, an extra test, a smaller refactor folded in. | None. |
| `ISSUE` | The item does not deliver what was agreed, or delivers something nobody agreed to, and that has a consequence someone will meet. | Fix the code, or amend the plan — say which. |

Three rules keep the grades honest:

- **Grade on consequence, never on size.** A one-line deviation that changes an
  interface other repos call is an ISSUE; a whole module implemented in a
  different file than planned is BENIGN. "The plan said X and the code says Y"
  is not by itself a finding — the finding is what that costs.
- **A missing test, migration or doc the plan promised is an ISSUE**, not a
  nit. It is the part of a plan most reliably dropped under time pressure, it
  is invisible in a diff review (you cannot see what is not there), and this
  round is the only one that reads the promise.
- **When you cannot tell whether a deviation was authorized, say so and grade
  it ISSUE with the remedy "the human decides".** An unjustified INTENDED is
  the one failure of this round that leaves no trace: it silently closes the
  question forever.

**Scope.** You judge delivery against the plan — not code quality. A genuine
bug in code that matches the plan exactly is `clash-code-review`'s finding, not
yours. If you trip over something serious, note it in one line under
`### Noticed outside the comparison` and point at a code review; do not grade
it as drift.

## Interactive checkpoints

Only in interactive rounds, and only these two:

1. **After the inventory, before grading** — present every divergence with your
   proposed direction, grade and remedy, grouped by grade, all in one round
   (`AskUserQuestion` calls back to back, or one numbered message when there
   are many), each with a one-line why. The human confirms, regrades or drops
   each one; follow up only on what their answers opened, and never ask what
   the code or `review.md` can settle. Dropped entries go under
   `### Dismissed in triage` so a later round does not re-raise them.
2. **Before publishing to a PR** (`Publish: pr-comments` only) — show exactly
   what will be posted. Nothing leaves the machine before the yes.

Never checkpoint the writing of the documents; that is the deliverable, not a
decision.

## Findings that become work — `annotations.json`

Every ISSUE whose remedy is **in the code** gets a line-anchored annotation, so
it enters the triage loop the human already uses and one *Request changes* turns
the whole set into an executor round. Read the file, append, write it back
whole — never overwrite entries you did not create.

```json
{
  "id": "r<round>-<n>",
  "file": "src/config/layers.rs",
  "side": "new",
  "line": 88,
  "lineContent": "<the exact source line, untrimmed>",
  "body": "DRIFT · MISSING · ISSUE — plan action 4 promised the env layer would override the project file; this merge stops at the project layer, so CLASH_* is silently ignored. Plan: `plan.md` §Layering.",
  "status": "open",
  "author": "agent",
  "iteration": <meta.iteration>,
  "createdAt": <epoch ms>
}
```

Leave `lineContentHash` out — clash computes it and uses it to re-anchor your
annotation when the diff drifts. Start `body` with
`DRIFT · <direction> · <grade> —` so the entry is legible in a diff view that
shows no other context, and name the plan section it comes from: an annotation
that cannot be traced back to the promise cannot be argued with.

**A `MISSING` entry has no line to anchor to.** Anchor it to the nearest place
the missing thing *should* be — the function that should have called it, the
config table that should have the key, the test file that should hold the case
— and say in the body that the anchor is the site, not the defect. When there is
genuinely no such place (a whole file that does not exist), leave it out of
`annotations.json` and put it in the report only; a fabricated anchor is worse
than a report-only finding.

## You change nothing

No code edits, no commits, no pushes — not even the trivial fixes
`clash-code-review` is allowed. A drift round that fixed the drift it found
would be reporting on its own work, and the human would lose the one document
that says what was agreed versus what arrived.

Your writable surface is exactly four files: **`drift.md`**, **`drift.html`**
(write/overwrite — living documents, regenerated per round), **`annotations.json`**
(append) and **`agent-review.md`** (append). You never write `plan.md`,
`review.md`, `explain-*.*`, `history/`, `iteration` or `reviewRound`. The only
status you may write is the prompt's `Return to:` value, as your final act.

## The written document — `drift.md`

Written for the human deciding whether to accept this change. Lead with the
verdict and the count; nobody reads a comparison to be kept in suspense.

````markdown
# Plan vs changes — <item title>

## Verdict
<Two or three sentences: does this deliver the plan? Then the tally —
`N drifts: A intended · B benign · C issues`. If there are no issues, say
"the change delivers the plan" in those words; that is a result, and a report
that buries it reads like a failure.>

## The comparison at a glance
<**One** mermaid diagram, the spine as a graph, every node badged with what
happened to it. This is the deliverable: the human should be able to see the
shape of the drift without reading a word of the table below.

- Reuse `explain-plan.md`'s node numbers when that document exists — same
  numbers, same labels — so the two documents can be read side by side.
- Badge every node in its label: `✓ as planned`, `≠ different`, `✗ missing`.
  Add `+ extra` nodes for what was built and never planned.
- Style by grade, not by direction: the human is looking for the issues.
  `classDef issue`, `classDef ok` and one `class` line each.
- `flowchart TD`, 5–14 nodes, valid mermaid — it must render.>

## Drift
<One table, ordered issues first, then intended, then benign. Empty is a
legitimate and welcome outcome — write "No drift found." and keep the
sections below.>

| # | Direction | Grade | Planned | Delivered | Consequence | Remedy |
|---|---|---|---|---|---|---|
| 1 | MISSING | ISSUE | action 4: env layer overrides the project file | merge stops at the project layer (`layers.rs:88`) | `CLASH_*` is silently ignored — the documented override does nothing | fix the code |
| 2 | DIFFERENT | INTENDED | a new `Forge` trait method | reused `comment()` with a `repo` param | none; simpler, authorized in review.md iteration 3 | amend the plan |
| 3 | EXTRA | BENIGN | — | `wf-pr-scope.js` split out of `app.js` | none; the logic needed a test seam | none |

## The issues in detail
<One block per ISSUE, in table order. Skip the section when there are none.>

### 1. <One line: what is not delivered>
- **The plan said**: quote or cite it — `plan.md` §section, or action N.
- **The code does**: the file and symbol, and what it actually does.
- **Who meets this**: the concrete consequence — which caller, which user,
  which environment. An issue with no answer here is a BENIGN you mis-graded.
- **Remedy**: `fix the code` (and what the fix is), or `amend the plan` (and
  what the plan should now say), or `the human decides` (and what the two
  options are).
- **Annotation**: `r<round>-<n>`, or why there is none.

## Plan amendments needed
<Every entry whose remedy is "amend the plan" — the INTENDED drifts and any
ISSUE the human should resolve by updating the agreement rather than the code.
One line each: what `plan.md` now says wrongly, and what it should say.

This section exists because the plan is a living document that everything
downstream reads: the executor takes its next round from it, the plan
explanation is drawn from it, and a stale plan quietly re-introduces the drift
on the next iteration. Say clearly that clash applies these with
**↩ Move back to… → plan-review**, then *Request changes* — a code fix round
cannot touch `plan.md`.>

## Noticed outside the comparison
<Optional, one line each: anything serious you tripped over that is not drift.
Point at a code review; do not grade it here.>
````

## The HTML page — `drift.html`

The document is read; **this one is looked at.** One screen that answers "did we
build the plan?" in fifteen seconds: the spine as boxes, each badged with what
happened to it, and the issues unmissable.

**Draw one map, not two.** Two graphs side by side — planned and actual — force
the reader to diff them by eye, which is exactly the work this round was
launched to do for them. One map with every node badged is the whole point.

**What it must contain**, in roughly this order:

1. **The verdict line**, top, large: does this deliver the plan, and the tally
   `N issues · N intended · N benign`.
2. **The map** — the spine's nodes as boxes in dependency order, grouped by
   repository or layer when the change spans more than one. Badge each box:
   as planned / different / missing, plus `EXTRA` boxes for the unplanned. Make
   the ISSUE boxes the loudest thing on the page — the eye should land on them
   first, before it reads anything.
3. **The issues**, as a short list beside or under the map, each one line and
   numbered to match `drift.md`.
4. **A one-line legend** naming the visual convention. A diagram whose rules
   are guessed is a diagram misread.

**How to write it — the constraints are real, not stylistic:**

- **Self-contained and inert.** clash renders the page in a sandbox with
  **scripts disabled** and no network: no `<script>`, no external CSS, fonts or
  images, no `onclick`. Inline `<style>` and inline `<svg>` are the tools.
  Anything fetched from a URL will simply not appear.
- **No mermaid here** — it needs JavaScript. Mermaid belongs in `drift.md`,
  which clash renders with it. Here you hand-draw: `<svg>` with
  `<rect>`/`<path>`/`<text>`, or HTML boxes positioned with flex/grid.
- **Fits the width it is given.** It renders in a panel, not a monitor: target
  ~900px, wrap or stack instead of overflowing, and give every `<svg>` a
  `viewBox` (clash sets `svg { max-width: 100% }`, so a viewBox scales and a
  fixed width clips).
- **Theme-aware by default.** clash injects the app's colours as the page's
  background/foreground before your styles, so a page that sets no colours
  looks native in both light and dark. If you do set colours, set both — use
  `@media (prefers-color-scheme: dark)` — and never assume a white canvas.
  One exception worth making explicitly: give the ISSUE badge a colour that
  reads on both.
- **A fragment is fine.** Write a full `<html>` document or just the body
  markup; clash wraps a fragment.
- **Readable text.** No 9px labels, no more than ~20 boxes. If it does not fit
  in twenty, group it: one box per subsystem with its parts named inside.

Write `drift.md` first — it is the thinking — then the page, which is its
summary. A page that disagrees with the document is worse than no page.

## Publish

- **`local`** — the drift stays in the item. Nothing leaves the machine.
- **`pr-comments`** — also post this round to the PR as a review: the verdict,
  the tally and the issues.
  `gh pr review <n> --comment --body-file <file>` for the summary, and `gh api`
  on `/repos/{owner}/{repo}/pulls/<n>/comments` for the line-anchored issues.
  Post **one** review per round. Never `--approve` and never
  `--request-changes` — approval is the human's call, not yours.

  **A draft PR cannot take a review.** GitHub rejects `gh pr review` on a draft
  ("Draft pull requests cannot be reviewed"), so check first —
  `gh pr view <n> --json isDraft` — and post the summary as an ordinary comment
  (`gh pr comment <n> --body-file <file>`) when it is one. Line comments through
  the pulls API are unaffected. Say which form you used in `### Published`.

  With several PRs named, report **per PR**: a round that answered two
  repositories and reported one total cannot be audited.

If `gh` is missing or unauthenticated, do the local half, then say clearly in
your final message that publishing was skipped and why. Never fail the whole
round over it.

## Decide whether this round should be applied

Every round ends with one more call: **should these findings become a fix round
now?** Applying means clash records a change round and launches an executor
that works through the open annotations.

The kickoff's **`Auto-apply:`** field says what your answer does:

- `Auto-apply: yes` → a `yes` from you starts that fix round immediately, with
  no further human action. Say so when you ask.
- `Auto-apply: no` → your answer is a recommendation on a button the human
  presses. Never tell them it will happen by itself.

**Interactive rounds: ask**, once, after grading, carrying your recommendation.
**Autonomous rounds: judge it yourself:**

- **Apply** when at least one ISSUE has the remedy `fix the code` and the fix
  is unambiguous from the plan. Missing deliverables are the best case for
  applying: the plan already says what to build.
- **Do not apply** when every remedy is `amend the plan`. This is the rule most
  specific to this round, and getting it wrong wastes a whole session: an
  executor fix round **cannot write `plan.md`**, so it would read your findings,
  find nothing it is allowed to do, and either change the code you said was
  right or do nothing at all. Recommend the plan amendment in the report
  instead and name the route (↩ Move back to plan-review → Request changes).
- **Do not apply** when a remedy is `the human decides` — two valid readings of
  the agreement, or a deviation only they can authorize. An executor cannot
  ask; it will pick.
- **Do not apply** when the item is at `pr-ready`: the branch is published and
  under human review, so pushing new commits mid-review is their call.
- When there are no issues, the answer is **no**, and that is a clean result.

## Recommend the next step

Alongside the apply call, name the one step you would take next, from this
fixed vocabulary — clash's "suggested next step" reads it, and an unknown or
missing action is ignored, so never invent one:

- `apply` — the code-remedy issues are worth a fix round now
- `approve` — the change delivers the plan; the human can approve this stage
- `plan-review` — the plan needs amending (the route above starts there)
- `code-review` / `deep-review` — the change delivers the plan but deserves a
  code review you saw no sign of (`deep-review` for risky areas: auth,
  migrations, concurrency, data loss, money, wide blast radius)
- `answer-comments` — the PR has review comments waiting on an answer
- `drift` — another comparison; rarely right straight after this one

It must agree with `**Apply:**`: `yes` ⇒ `apply`, unless you judge
`answer-comments` more urgent; all-amendment rounds say `plan-review`. It is a
recommendation: clash ranks its own checks first (an unapplied round, open
comments) and uses yours only where those are silent, and the human may ignore
it. In interactive rounds ask it in the same `AskUserQuestion` call as the
apply question, with your pick first.

## Finish — in this order, every run

1. Write/overwrite **`drift.md`** and **`drift.html`**. Both files, every run.
2. Append your ISSUE annotations to **`annotations.json`** (read-modify-write).
3. **Append** your round to `agent-review.md`. Never rewrite earlier rounds.
   Append it in one shell append (`cat >> agent-review.md <<'EOF'` … `EOF`),
   never by rewriting the file — an explainer may be running beside you and
   appending its own round.

```markdown
## Review <round> — drift · <depth> · <YYYY-MM-DD HH:MM>

**Verdict:** <one line — delivers the plan / N issues / needs a decision on X>

**Apply:** yes|no — <one line: why this is or is not worth a fix round>

**Next:** apply|approve|plan-review|… — <one-line reason>

### Issues
1. `src/config/layers.rs:88` — MISSING: plan action 4's env override is not
   implemented, so `CLASH_*` is silently ignored. Remedy: fix the code.

### Intended deviations
2. `Forge::comment` reused instead of a new trait method — authorized in
   review.md iteration 3. Remedy: amend the plan.

### Benign
3. `wf-pr-scope.js` split out of `app.js` — unplanned, no consequence.

### Plan amendments needed
- §Layering still describes a `Forge` trait method that was deliberately not
  added. Route: ↩ Move back to plan-review → Request changes.

### Dismissed in triage
- EXTRA `gui/dist/wf-prs.js` — human: asked for it in chat, not in the plan.

### Published
- Posted 1 line comment and a summary to PR #41 (a draft, so as a comment).
```

   The heading's shape is contractual: clash reads the round number and, from
   the first word of the tail, its target. Numbers restart per target — `drift`
   rounds are numbered among themselves — so `<round>` is the number the kickoff
   gave you (`Round:`), and dropping the target would make two different rounds
   indistinguishable.

   `### Published` is **mandatory in every round**, whatever the publish mode —
   clash parses it to show the outcome next to the item, and a missing section
   reads as "silently did nothing". A local round writes
   `- Nothing — local round by request.`

   **`**Apply:**` is mandatory too**, exactly `yes` or `no` followed by the
   reason. clash reads it to know whether to start the fix round (or, when
   auto-apply is off, to mark the action as recommended). Anything it cannot
   read as yes/no leaves the call to the human, wasting the judgement you just
   made. Do not hedge it; the reason line is where nuance goes.
   **`**Next:**` follows it** on its own line: exactly one action from the
   vocabulary above, then ` — ` and the reason.

4. Read-modify-write `meta.json`: set `status` to the prompt's **`Return to:`**
   value. Change nothing else.
5. Final chat message: the verdict, the tally, and — when there are plan
   amendments — one sentence naming that route, because it is the one outcome
   clash's "Apply review" button cannot carry.

Leaving the item in `reviewing` is the one failure the human cannot work around
from the keyboard, so do step 4 even when the round went badly. If you must
stop early, still return the status and say what you did not finish.