# plan-review-update

A checked build-review loop: one `plan` codon writes `plan.md`, then a three-iteration `blind-reviews` loop pairs a fresh haiku reviewer with a fresh haiku updater. Blindness is mechanized by `continuationMode: "fresh"` — the handoff travels through files in the workspace, never conversation history. This is the fixture behind `examples/plan-review-update` and the `blind-reviews` loop object quoted by `author/patterns/reliability`.

## Tree

```
hank.json                          plan codon → blind-reviews loop (review + update)
hank.break-continue-previous.json  break: update flipped to continue-previous + sonnet
hank.break-allowfailure.json       break: update rig fails without allowFailure
prompts/plan.md                    haiku — writes plan.md from the seed brief
prompts/review.md                  haiku — blind review, writes review-notes.md
prompts/update.md                  haiku — applies review, appends a changelog line
prompts/system-broad.md            shared appendSystemPromptFile for all three codons
data/seed.md                       fictional two-paragraph project brief
expected/                          captured validate + break-failure outputs, MANIFEST.md
```

## Per-codon rationale

- `plan` (haiku, fresh) — establishes the artifact under review. `checkpointedFiles: ["plan.md"]` so the revised plan is sealed after every codon.
- `review` (haiku, fresh) — the skeptical blind reviewer. It sees only `plan.md`, never the seed brief or a prior review; `fresh` gives it a new session each iteration. `onFailure: "retry"` keeps a transient provider blip from killing the loop.
- `update` (haiku, fresh) — the updater. Its `rigSetup` runs *before* the codon starts, between review and update: it copies the just-written `review-notes.md` into `notes/review-notes-<n>.md` (0-indexed, matching the runtime's `review#n` iteration suffixes). `allowFailure: true` is set so a missing note on an early iteration can't fail the codon. It then reads both files, rewrites `plan.md`, and appends one line to `plan-changelog.md`.
- The loop carries `terminateOn: {type:"iterationLimit", limit:3}` (runs iterations 0, 1, 2), a `budget` scoped to the loop, and `archiveOnSuccess: ["notes/"]` so the whole note series is preserved when the loop terminates.

## Run + validate

```sh
bunx hankweave@0.10.0 hank.json data/ --validate     # prints the GOOD TO RUN! box
bunx hankweave@0.10.0 hank.json data/ --headless --start-new -o out
```

Expected: 7 codon completions (1 plan + 6 loop codons) then `RunCompleted`, exit 0. See `expected/MANIFEST.md` for the full on-disk shape.

## Break it on purpose

Both break variants are separate files; validate/run each the same way.

- `hank.break-continue-previous.json` — flips `update` to `continuationMode: "continue-previous"` and changes its model to `sonnet` (differs from the preceding haiku `review`). Validation fails with `Different models cannot share the same session ID.` (captured in `expected/break-continue-previous.txt`).
- `hank.break-allowfailure.json` — replaces the update rig with `echo '…' >&2; exit 1` and drops `allowFailure`. The run fails in the `preparing` phase before the update codon starts (captured in `expected/break-allowfailure.txt`).

## Tension note (brief vs this fixture)

The page brief's OQ1 spec named `plan`/`update` as opus and `review` as haiku; this fixture uses haiku for all three, per the fixture-build spec, so a full run stays cheap and a `continue-previous` break can be shown by changing only `update`. The blind-review loop shape, fresh modes, rig, budget, shared system prompt, and `archiveOnSuccess` all match the brief facts.