@rig-c/create 0.0.0-stage → 1.0.1

package/docs/PROJECT.md

@@ -0,0 +1,2657 @@
+# A project
+
+One painting in, one rig (and the takes made from it) out. Each rig is a
+**project**: a folder of its own that holds the painting, the user's direction,
+the plan the user signed, every version shown and every verdict given. Without
+it, the story of a rig is split across a chat thread, a scratch folder and
+someone's memory, and every resume re-reads context and re-guesses.
+
+A project's `project.json` is **the only place a decision is recorded**. Chat
+is not a record: a decision made in chat is copied here, verbatim, with who said
+it and when.
+
+The field set is **v0** — `"schema": "rig-create/project@0"` — and is expected
+to change while the structure is piloted by hand. The `@0` is there so a reader
+of a record can tell which shape it follows once the shape moves; a validator
+and a migration come with the first shape change, not before. The empty
+skeleton is [../templates/project.json](../templates/project.json); a filled
+record is [../templates/example-project.json](../templates/example-project.json).
+Its sign-offs are fixture sign-offs, not a person's approval; see
+[../templates/example-draft/README.md](../templates/example-draft/README.md).
+
+## Layout
+
+```
+<project>/
+  project.json         the decision record: interview, plan, split, stage, sign-offs, versions
+  AGENTS.md            the agent guide: the order, and which installed docs to read; CLAUDE.md imports it
+  inputs/              immutable: the painting, the user's references
+    references/
+  evidence/v<N>/       what a verdict rested on: crops, sheets, check tables
+  derived/             regenerable intermediates (ignored by git)
+  outputs/v<N>/        skeleton, atlas, takes (ignored by git)
+  scratch/             anything; deletable any time (ignored by git)
+```
+
+A project is its own git repository, so the history of its decisions is its
+`git log`. A collection member is the exception: it lives in its collection's
+repository, which holds its history ([COLLECTIONS.md § Making one](COLLECTIONS.md#making-one)). `rig-create init <dir>` writes the layout above, a `.gitignore`
+for the untracked folders, a `package.json` pinning the rig-c packages, and a
+first commit.
+
+## Data is split by lifetime
+
+Rigging derives far more data than it ships. Sorting every file by how long it
+must live keeps the record small and makes "can I delete this?" a question the
+folder answers.
+
+| Folder | Lifetime | Tracked | Rule |
+| --- | --- | --- | --- |
+| `project.json` | forever | yes | The only place a decision is recorded. |
+| `inputs/` | forever, never edited | yes | Every file has its sha256 in `project.json` `inputs[]`. A changed input is a new file with a new name, not an edit — otherwise a verdict given on the old file cannot be re-read. |
+| `evidence/v<N>/` | forever | yes | The crop, sheet or table a bounce or an acceptance rested on, for the version it judged. If it is not here, the verdict cannot be re-read later. Keep each file small; a larger review image stays where it is and is listed in `versions[].evidence` with its path and sha256. |
+| `derived/` | until regenerated | no | Depth maps, masks, layers, configs, frames. Every file (or folder) is listed in `derived[]` with the command and the input hashes that made it. Something that cannot be listed that way is either an input or scratch. |
+| `outputs/v<N>/` | until discarded | no | One folder per version that was shown to anyone, frozen when shown. Hashes go into `versions[].outputs`. If the user keeps finals elsewhere, `archive` records where. |
+| `scratch/` | none | no | Anything. Deleting it must never lose information; if it would, the file belongs in `evidence/` or `derived/`. |
+
+## Stages
+
+`interview` → `plan-approved` → `parts` → `parts-review` → `rigging-interview` → `rigging` →
+`rig-review` → `post-interview` → `post` → `direction-review` → `accepted`,
+plus `paused`.
+
+**A stage moves only on a human `signoffs[]` entry**: the stage it closes, who,
+when, and the words used. A plan checkpoint is signed the same way, with
+`checkpoint` naming the plan step. An agent may draft, propose, build and
+measure in any stage; it may not move `stage` forward or pass a checkpoint by
+itself. Reason: the stages exist to put a person's eyes before each piece of
+work that is expensive to redo; an agent that could advance them would be
+grading its own work.
+
+A project is *in* a stage while that stage's work happens; the sign-off named
+in the last column ends it and moves the project to the next. The order and
+which stages end on a sign-off are written once, in `src/stages.ts`;
+`rig-create interview --check` refuses a stage moved past a missing sign-off
+([CHECKS.md](CHECKS.md)).
+
+| Stage | User step | What happens | Ends with |
+| --- | --- | --- | --- |
+| `interview` | 1 | Framing and source/parts guides (the later rig guides wait for rigging-interview) ([INTERVIEW.md](INTERVIEW.md)): the user's sentences, a delegation ("auto"), or not applicable — never left for the agent to fill. | The user signs `{ "stage": "interview" }`. |
+| `plan-approved` | 1 | The parts steps (`phase: "rig"`) are drafted from the guides, with the agent's decision written on every delegated item. The user sets each step's checkpoint and signs. | `{ "stage": "plan-approved" }`. |
+| `parts` | 1 | The rig steps that make the parts run: `seethrough` and `assemble`. At a step whose checkpoint is on, work stops until `{ "stage": "parts", "checkpoint": "<step id>" }` is signed (the split, [below](#split-approval-is-a-plan-checkpoint)). Only a labelled draft may contain proposed bones/weights for mesh/chest inspection; production rigging remains forbidden. | Every step it runs is `done`, `assemble`'s bar including the parts check passing on the assembled parts. |
+| `parts-review` | 1 | **The parts are reviewed before any production rig is built** ([below](#the-parts-are-reviewed-before-rigging)): the user looks at the assembled parts in rig-review's parts view. A bounce is fixed here, in `parts`. | `{ "stage": "parts-review" }`, signed by a person, carrying the approved parts verdict as `evidence`. |
+| `rigging-interview` | 2 | Ask bones, meshes, constraints and motion while viewing the approved parts and structure; draft their rigging plan. | The human signs `rigging-interview`, binding accepted parts and structure. |
+| `rigging` | 3 | The remaining rig steps run in order (`bones`, `meshes`, `constraints`, `motion`); each config section cites its guide (`versions[].provenance`). At a step whose checkpoint is on, work stops until `{ "stage": "rigging", "checkpoint": "<step id>" }` is signed. It does not start without the `parts-review` sign-off (`PARTS_REVIEW_UNSIGNED`), nor on a verdict that is missing, not approved or no longer the parts on disk (`PARTS_VERDICT_*`). | The last rig step's bar is met. |
+| `rig-review` | 1 → 3 | **First review, on a still frame**: the rig alone, fixed camera, no post-production — seams, cuts, physics and motion played in place. Feedback is recorded verbatim with `on_items`; a bounce makes a new rig version. | The user accepts one rig version: an `accepted` verdict with `review: "rig-review"` on it, resting on its still frame, and `{ "stage": "rig-review" }` signed ([below](#the-rig-review-rests-on-a-still-frame)). |
+| `post-interview` | 2 | The post items (camera and 2.5D, timing, composition) are asked, and the post steps (`phase: "post"`) drafted from them. | The user signs `{ "stage": "post-interview" }` — guides and post steps together. |
+| `post` | 2 | Post-production on the accepted rig version (`versions[].kind: "post"`, `rig_version` naming it); post tooling asks `rig-create handoff` first ([below](#the-hand-off-to-post-production)). | The last post step's bar is met. |
+| `direction-review` | 2 → 3 | **Second review, direction**: camera, depth, timing, framing. Same feedback rule. | The user accepts one post version. |
+| `accepted` | — | Done. If finals go somewhere else, `archive` says where. | — |
+| `paused` | — | Work stopped by a human sign-off, entered and left through `pause` and `resume` ([below](#pausing-and-resuming)). While paused it is checked as the first stage whose sign-off is missing; `resume` returns it to the stage it was paused from. | — |
+
+**Why two reviews.** The rig is reviewed first on a still frame with a fixed
+camera — the rig alone — so a seam cannot hide behind a camera move, and a
+depth complaint cannot bounce a correct rig. `post-interview` mirrors
+`interview`: post guides are asked only once the rig they apply to is accepted,
+so they are not asked about a rig that may still change. A rig change after
+`rig-review` means a new rig version and a new first review, and the post
+version built on the old rig is redone on the new one.
+
+### Refusals a record already carries
+
+A writer validates its whole candidate with `checkProject` and refuses only a
+refusal the record as read did not already carry. The baseline is that check at
+write time and is never stored. Findings match by code and path with
+multiplicity, so a carried code at a new path is new, and the refusal names only
+the new code. `reopen`, `signoff`, `step-status`, `pause`, `resume`, `amend` and
+`draft-rig` and `review` follow this rule; the interview, plan, scene, direction, correction,
+`rig-version`, `version config-lost` and `version outputs-lost` writers already did. Each writer's own
+pre-checks are unchanged (`signoff` still refuses a carried lag, and a carried
+`GUIDE_CHANGED_UNSIGNED` on a step it covers), and `check` still reports every
+carried refusal.
+`advance` still needs 0 refusals: it is the stage boundary. A check that stops
+early (an unreadable record, `SCHEMA_UNKNOWN`, `STAGE_UNKNOWN`) read nothing
+after that point, so it gives no baseline to any writer above: each one refuses
+on such a record, and a pending answer's stored `refusal_baseline` does not
+stand in for it.
+
+### Recording forward progress
+
+```sh
+rig-create advance <stage> [<project dir>] [--json]
+rig-create advance parts-review --parts-check evidence/parts-check.json --parts <assembled dir>
+rig-create step-status <step> <status> --by <who> [<project dir>] [--note-file <path>] [--json]
+```
+
+`signoff` records approval, then `advance` records the move that approval
+authorizes. The move's authority is the person's stage-level signature, so
+`advance` takes no `--by` or words of its own (`ADVANCE_WORDS_REMOVED`): its
+entry names the signature it rests on. The stage level signature closes its
+named stage. `plan-approved` authorizes `parts`
+for both the split-interview order and the legacy order that includes parts.
+Only an already-passed pre-parts project keeps the historical route to rigging.
+The legacy order omits `rigging-interview`; explicit adoption adds it.
+A bar stage advances once every step it runs is done, using the preceding
+stage-level signature as authority. All post items marked not applicable
+allow `post-interview` to advance directly to `accepted`.
+
+Arrival at `rigging-interview` or `post-interview` permits only the target
+interview's silent-item `INTERVIEW_INCOMPLETE` findings, counted by code and
+item path, so its answers can be recorded there. The ordinary check still
+reports them, and approval or departure requires the answers.
+
+The move from `parts` to `parts-review` also takes `--parts-check <report>
+--parts <assembled dir>`, both project-relative: the `parts-check.json` that
+`rig-parts check-parts` wrote for the assembled parts, retained in the project
+the way the parts verdict is, and the root it was run on. Both are required on
+that move and refused on any other. The report must pass (`exit_code` 0, no
+`refusals`) and match the parts on disk at the move. Its HOLE rows, defect
+classes parts cannot measure yet, are printed one named line each and stored;
+a HOLE is not a pass and does not block (CHECKS.md § Parts-stage check at the
+parts → parts-review move).
+
+`advances[]` retains `{ stage, from_stage, at, source?,
+steps_before, signoff, signoffs_before, order, post_not_passed, parts_check? }`,
+with `parts_check { path, sha256, spec, parts, exit_code, holes, reported }` on
+a `parts` → `parts-review` move, copied from the report and bound by its sha256. The clock supplies `at`,
+and `signoff` is the stable `{ stage, checkpoint, at }` identity of the human approval the move rests on.
+Entries written before advance stopped taking words also carry the mover's `by` and UTF-8 `verbatim`;
+they stay valid when both are strings and `by` is not `agent`.
+`steps_before` retains each step id, required phase and original status so a historical bar exit still requires completed work after replanning.
+`signoffs_before` preserves the approval identities present at the move,
+including tied timestamps. Reordering signatures preserves these references. `order` retains `legacy`, `split` or `pre-parts` so later
+adoption preserves historical moves. `post_not_passed` captures whether every
+post item was not applicable at the move. A historical post-interview to
+accepted skip reads this boolean snapshot, so reopening and later applicable
+post answers preserve the earlier authorized move. The current frontier still
+uses current post answers. Forward history grants no reopen cutoff.
+Earlier plan re-signatures do not revoke later approvals. Among live approvals,
+the furthest closing stage supplies the frontier, using its latest signature
+by time and then array position. Reopen and amendment rules still invalidate
+approvals. An earlier re-signature leaves the later live stage target unchanged.
+
+From `STAGE_PROGRESS_SINCE`, stage must match the latest stage-changing advance or reopen (or the initial stage without either). A mismatch is dated by the later of that move and the latest live signature at the furthest stage before the current one, so a hand move made before the contract stays a WARN after later sign-offs. An advance retains the stable signature that authorized it at that time, so later same-stage re-signatures preserve that move.
+
+The checker pins both lag and skip from `STAGE_PROGRESS_SINCE`, dated by the
+authorizing stage-level signature. Earlier readable dates WARN with the same codes. An unreadable frontier
+date refuses with `STAGE_SIGNOFF_DATE_INVALID`. New advance writes enforce
+lag and skip independently of signature age. Signoff retains its existing conditional, scoped candidate checks.
+Its additional progress guard rejects a pre-existing refusal-level lag and
+new candidate progress refusals. It permits only the lag introduced by its own
+new frontier signature, awaiting the separate advance writer. Legacy WARN lag
+remains permitted at signoff. A target can move only one ordered stage at a
+time, including a permitted bar exit or the declared no-post route.
+
+`step-status` runs in the step's execution stage and records one transition
+through `pending` (also the absent status), `in-progress`, `at-checkpoint`,
+then `done`. On an amended project the execution stage may also be the check's
+`effective_stage` (Forward amendments), so the reset steps can be redone while
+the stored stage is retained. On a legacy-order project whose plan was approved before
+`PARTS_REVIEW_SINCE`, rig steps also run in `rigging`. That route grants no
+authority of its own: the writer's candidate check still refuses a started
+step without a live covering stage-level approval (`STEP_RUN_UNAPPROVED`), and
+a `plan-approved` checkpoint signature is refused (`SIGNOFF_UNKNOWN_CHECKPOINT`). Each step's `status_history[]` retains
+`{ from_status, status, by, at, checkpoint_required, signoff }`.
+`--note-file <path>` optionally retains verbatim UTF-8 text as `note` and its byte
+sha256 as `note_sha256`. The readable file must contain 1–1,000 bytes and no
+control characters except newline. Both keys are absent without the flag; the
+check refuses incomplete pairs or mismatched hashes. Notes do not change signed
+step content.
+`checkpoint_required` snapshots the resolved boolean requirement at that event.
+History validates that snapshot when checking a done entry. Reopening and
+replanning a checkpoint preserve earlier completion history. The current
+writer still requires a live checkpoint signature whenever the current
+checkpoint is enabled. Its `signoff` uses the same stable
+identity object or null. A checkpointed `done` references
+the latest matching live human checkpoint signature. Other transitions have
+`signoff` null. Existing status-only history remains readable. Status and its
+history stay outside the signed plan hash. Reopen continues to reset steps.
+History must link: each advance or reopen leaves from the stage the previous
+move reached (starting at `interview`), and each status entry starts from the
+previous entry's status, or `pending` first and after a reopen or amendment
+reset; the last entry matches `status`. A reopen's `steps_before` holds each
+step's chained status at the reopen. Breaks are `STAGE_MOVE_UNLINKED`,
+`STEP_STATUS_UNLINKED` and `REOPEN_STEP_UNLINKED`, dated by
+`PROGRESS_HISTORY_SINCE` (CHECKS.md).
+Both writers reconcile `stage_values` with the applicable order and run the
+same complete `checkProject` candidate validation before writing. Refused
+writes leave `project.json` byte-identical. Neither writer runs a producer.
+
+### Pausing and resuming
+
+```sh
+rig-create signoff paused --by <who> --verbatim-file words.txt [<project dir>]
+rig-create pause --by <who> [--verbatim-file <file>] [--source <text>] [<project dir>] [--json]
+rig-create resume <stage> --by <who> [--verbatim-file <file>] [--source <text>] [<project dir>] [--json]
+```
+
+A person stops the work by signing `paused`; `pause` then sets `stage` to
+`paused`. It needs a human `{ "stage": "paused" }` sign-off dated at or after
+the latest recorded move, so a second pause needs a new signature. `resume`
+sets `stage` back to the stage the project was paused from, and refuses any
+other target (`RESUME_STAGE_MISMATCH`). A project paused by hand before the
+writer existed resumes at the stage its latest recorded move reached. Pausing
+a paused project, resuming one that is not paused, and pausing at `accepted`
+are refused by name. A reopen may also leave `paused`, as before.
+
+Both append to `pauses[]`: `{ from_stage, stage: "paused", by, at, verbatim,
+source?, signoff }` for a pause, with `signoff` the stable `{ stage,
+checkpoint, at }` identity of the paused sign-off, and `{ from_stage:
+"paused", stage, by, at, verbatim, source? }` for a resume. The clock
+supplies `at`. The history is kept apart from `advances[]` and `reopens[]`,
+so their linkage (`STAGE_MOVE_UNLINKED`) and the rule that `stage` equals the
+latest recorded move read the same records as before: after a resume the
+latest advance or reopen still names the stage, and a hand move to any other
+stage is still `STAGE_SKIPPED`. The check validates the shape of each entry
+(`PAUSE_MALFORMED`). Both writers run the complete `checkProject` candidate
+validation before writing and replace `project.json` in one rename; refused
+writes leave it byte-identical.
+
+### Reopening a passed stage
+
+```sh
+rig-create reopen <stage> --by <who> [--verbatim-file <file>] [--source <text>] [<project dir>] [--json]
+```
+
+A human may return to a previously reached stage without deleting signatures.
+`reopen` appends `reopens[]` and sets `stage` to its target in the same validated
+write. This backward move is the exception to `signoff`'s record-only writer:
+leaving the old forward stage would require signatures the reopen supersedes.
+The target is in the stage order, excluding `paused` and `accepted`, and no
+later than the furthest stage evidenced by the current stage, historical human
+sign-offs or dated rig/post versions. No producer is run.
+
+Each entry is `{ stage, from_stage, by, at, verbatim, source?, steps_before }`. `at` comes
+from the clock; words come unchanged from UTF-8 file or stdin (omitted or `-`).
+`--source` separately records where the words came from. `from_stage` records
+where the project stood when the reopen was written. Each entry's eligibility
+uses its own `from_stage` and historical evidence dated no later than that entry,
+so later backward moves neither erase nor manufacture its reach. An agent cannot sign.
+`steps_before` snapshots `{ id, status }` for every plan step running in the
+target stage or later, preserving an absent status by omitting it. Those steps
+are reset to `pending`; their other fields stay unchanged. Status is outside
+`step_hashes`, so existing plan hashes still verify. The append, resets and
+stage move happen together, or the file is unchanged on refusal. Before writing,
+the command runs the complete project check against the candidate record and
+the existing project files; any refusal leaves the original bytes unchanged.
+
+For each stage, a sign-off is live only if dated strictly after every reopen
+whose target is that stage or earlier. Checkpoints follow the same rule;
+undated entries cannot outrank a reopen. A second reopen advances that cutoff
+without restoring signatures invalidated by an earlier, wider reopen. All
+signatures remain in place, structurally checked as history. Advancing again
+requires live signatures under the existing stage/checkpoint rules. A newly
+run step without them is still refused; there is no execution exemption.
+
+Accepted historical rig versions remain accepted as history. If the reopen
+covers rig-review, a live hand-off requires a rig version built after it;
+a new verdict on an old build cannot revive that build. Historical post
+versions keep their original basis; new post work requires the live rig.
+Reopening only post work preserves the unaffected rig acceptance.
+
+### Forward amendments
+
+Raise a correction against an artifact and its owning stage with the public
+writer. The stage is chosen explicitly by the person recording the correction.
+
+```sh
+rig-create amend parts --kind part --target panel --change inputs/replacement.svg \
+  --by owner --verbatim-file correction.txt
+```
+
+`amendments[]` retains `{ target, by, at, verbatim, source?, changes }`.
+`target` contains `{ stage, kind, id }`, where `kind` is `part`, `config-field`,
+`motion-track` or `interview-answer`. `id` names the artifact, config pointer,
+track or answer path. Any ordered non-terminal stage may own a target.
+`changes` contains `{ path, sha256 }` for every repeated `--change` file.
+The writer reads and hashes those files under the project. These are declared
+new inputs retained as historical byte identities. Checking history validates
+their shape and does not require the mutable working files to retain those
+bytes forever. `at` comes from the clock, and UTF-8 words are retained unchanged.
+An agent signer is refused. Optional `--source` records the origin separately.
+
+An amendment invalidates every approval at its owning stage or later, using
+the same stage/time cutoff as `reopen`. The reason for each is exactly
+`no binding proves independence`, with the fixed gap row below. Upstream means
+every ordered stage preceding the amended stage. Its live approvals remain
+live and its plan-step states are preserved. There is no additional unrelated
+category. A downstream approval cannot stay live on this contract.
+
+| Approval kind | Missing proof from the step-0 census |
+| --- | --- |
+| `interview` | G1, approved answer and input set |
+| `plan-approved` | G2, answer contents and consumed inputs |
+| `parts` checkpoint | G3, executed inputs and checked outputs |
+| `parts-review` | G5, comparison inputs and rendered-stack input binding |
+| `rigging-interview` | G2, answer contents and consumed inputs |
+| `rigging` checkpoint | G3, executed inputs and checked outputs |
+| `rig-review` signature or accepted verdict | G7, review target and evidence |
+| `post-interview` | G2, answer contents and consumed inputs |
+| `post` checkpoint | G3, executed inputs and checked outputs |
+| `direction-review` signature or accepted verdict | G7, review target and evidence |
+| An explicitly recorded `accepted` stage signature | G9, acceptance input closure |
+
+The fixed table is `AMENDMENT_APPROVAL_GAPS` in `src/amend.ts`. The remaining
+census rows cover producer derivation (G4), approval granularity (G6), field
+consumption (G8), build closure (G9) and opaque producer resolvers (G10).
+This table identifies missing proof for the approval kind. It does not assert
+that one gap alone suffices to prove independence.
+
+The extension point is `keepByBinding()` and the report field is
+`keep_by_binding`. It ships as an empty list. Later binding cards may place an
+approval there with the binding that proves its independence. Until then the
+amendment's stage and downstream approvals all lapse.
+
+`interview --check` adds `amendments[]` only on amended records. Each entry
+names the target, every invalidated signature and accepted verdict by record
+path, its stage/checkpoint, reason and gap, the still-live upstream approvals,
+and the empty keep-by-binding list. A new signature remains a separate act
+from the lapsed historical one. Multiple amendments and reopens accumulate
+cutoffs, so a narrower amendment cannot revive an earlier invalidation.
+
+The writer leaves `project.stage` in place, sets plan steps running at or after
+the amended stage to `pending`, and retains all previous approvals and versions.
+The check's `effective_stage` is the first unfinished stage while re-approval
+is pending, bounded by the stored stage. While it differs from the stored
+stage, the check still refuses a stage that differs from its latest recorded
+move (`STAGE_SKIPPED`, same dating), but skips the signature window
+(`STAGE_LAGGING` and the window's `STAGE_SKIPPED`). The stored stage stays
+while its approvals lapse, so the window would refuse every amended record,
+the amend writer's own candidate included. Judging the window against
+`effective_stage` instead fails too: that stage passes unfinished bars before
+the amended stage, which the window stops at. Re-sign the lapsed approvals and meet
+the affected steps' bars in order. `step-status` runs a reset step when its
+execution stage is the stored stage or the `effective_stage`, which it reads from
+the same complete check, so the bars are met in order without moving `stage`.
+`effective_stage` comes from the recorded signatures and step statuses; it is not
+stored, because each re-signature or finished bar moves it. Once every lapsed
+approval is re-signed and every bar is met, `effective_stage` equals the stored
+stage again and the signature window applies as before; no `advance` is needed
+when the stored stage was already reached. Existing upstream approvals need no re-sign.
+A rig covered by the cutoff needs a new build and acceptance before handoff.
+The writer runs the same complete candidate check before writing. Any refusal
+leaves `project.json` byte-identical. Existing records and `reopen` output retain
+their existing shape when no amendment is present.
+
+### The parts are reviewed before rigging
+
+`parts-review [<project>] --draft <id> --from-review-cli --by <name>
+[--json] -- <rig-review parts arguments>` records an independent parts verdict
+through `rig-review parts <arguments> --format json`. Put create's flags before
+`--`. The remaining arguments, including `--verdict`, are opaque strings passed
+to review in the project directory. They must be project-relative and stay
+inside the project. create reads only stdout and never opens the saved verdict
+named by those arguments. A failed CLI call refuses with its diagnostic.
+
+Exact stdout bytes are retained at `evidence/review-reads/<sha256>.json`.
+The ordered `review_acts` list holds both routes. A CLI receipt uses schema
+`rig-create/parts-verdict-cli@1`, `kind: "parts-verdict"`, `route: "cli"`,
+`draft_id`, `argv`, `evidence: {path, sha256}`, `tool: {name, version}`,
+`status`, `flagged`, `noted`, `by` and `at`. Names retain their response order
+and spelling. Notes remain verbatim in the retained response. `--by` identifies
+the human because the CLI response supplies no reviewer. Approved, pending and
+changes-requested responses can all be recorded. Recording identical bytes
+for the same draft again preserves the record byte for byte. Different bytes
+append, and the last receipt for that draft is current across both routes.
+A current changes-requested receipt refuses `signoff --draft` until a newer
+approved receipt exists. This does not itself sign or move a stage.
+
+The writer and check compare the CLI source hash multiset with the draft's
+recorded parts and output hashes. Every reviewed hash must be recorded and
+every part must be reviewed. Outputs absent from the response are optional.
+The painting declared by the draft's hash-bound `parts.json` is excluded on
+both sides, including repeated occurrences of its hash. Response paths are
+never resolved. Check reads the retained stdout, verifies its hash and copied
+receipt fields, and repeats this draft binding without querying the saved
+verdict. Signatures before `PARTS_VERDICT_LATEST_SINCE` warn for a current
+changes-requested receipt, while signatures from that date refuse.
+
+
+A defect in the parts — a part with nothing painted under its occluder, a
+boundary between two parts nobody composed — is cheapest to fix before a bone
+is placed on it. Found at `rig-review`, every build in between was spent on
+parts that were already wrong, and the fix goes back through the split and
+every step after it. So the steps that make the parts (`seethrough`,
+`assemble`) run in their own stage, `parts`, and a person looks at the
+assembled parts before `rigging` starts.
+
+- **`parts` ends on its bar**: the parts check's gates pass on the assembled
+  parts, recorded as `assemble`'s bar met (`status: "done"`). Coverage under
+  occluders joins this bar from rig-c/parts#998 once it ships; until then the
+  bar is the parts check as it is. A project past `parts` with one of its steps
+  not `done` is refused (`PARTS_BAR_UNMET`). The move to `parts-review` binds
+  the passing `rig-parts check-parts` report for the assembled parts
+  (`advances[].parts_check`, § Recording forward progress); its HOLE lines
+  reach the person at `parts-review` and are recorded on the move.
+- **`parts-review` ends on a human sign-off**, `{ "stage": "parts-review",
+  "checkpoint": null }`, given in rig-review's parts view. Without it the stage
+  does not move to `rigging`, and no `rigging` step runs
+  (`PARTS_REVIEW_UNSIGNED`). An agent's entry does not count.
+- **The sign-off carries the verdict it rests on**: `"evidence": { "kind":
+  "parts-verdict", "path": "<the file>", "sha256": "<its sha256>" }`, where
+  `path` is relative to the project and names the file rig-review's parts view
+  wrote (`rig-review parts`; by default `parts-review.json` beside
+  `parts.json`, or wherever `--verdict` put it). Write it to a tracked path,
+  `--verdict evidence/parts-review.json`, so the sign-off's evidence survives a
+  clone: `derived/`, where the parts are assembled, is not in git. The check
+  reads exactly that file, never a default location. Rigging is refused, each case by name
+  ([CHECKS.md § Refusals](CHECKS.md#refusals)), unless the verdict is the
+  `rig-review-parts-verdict/1` or `rig-review-parts-verdict/2` schema in `parts` mode (an `atlas` verdict is
+  informational and never gates), its `status` is `approved`, and every file
+  in its `source.files[]` is on disk with the bytes and sha256 it was reviewed
+  with. A part added, removed or repainted after the sign-off is a new review:
+  the user reviews again and signs again, with the new verdict as evidence.
+  The latest `parts-review` sign-off is the one read. **The parts themselves
+  must be on disk to rig**: on a fresh clone, re-assemble them before rigging
+  continues. The verdict gates rigging only until a rig version is accepted at
+  `rig-review`: from then on it is not read, and a part changed after that is a
+  new rig version, refused as `RIG_VERSION_UNACCEPTED` until it is reviewed.
+
+  Both schemas take the same approval, mode, evidence SHA-256, source path,
+  byte-count and source SHA-256 checks. The schema allowlist is closed: `/3`
+  and any other value refuse `PARTS_VERDICT_SCHEMA_UNKNOWN`. The signoff writer
+  calls this reader before writing; the difference-map reader receives only
+  its successfully checked `parts.json` path. These readers do not need new
+  fields (`tests/parts-verdict-v2.test.ts`).
+
+  **Fields added by `/2`.** The schema-final review writer at
+  [`07c07d254725c97cfc63aa7b028cb8ef8ccf9045`](https://github.com/rig-c/review/blob/07c07d254725c97cfc63aa7b028cb8ef8ccf9045/src/parts-view.ts)
+  adds `comments[]`; its complete nested shape comes from
+  [`PartsComment`](https://github.com/rig-c/review/blob/07c07d254725c97cfc63aa7b028cb8ef8ccf9045/src/parts-comment.ts).
+  All fields below are explicitly ignored **for create's gate**, retained
+  unchanged in the verdict file and covered by `evidence.sha256`. create
+  neither copies nor rewrites them into `project.json`, and does not open crop
+  paths or require the review machine's crop state. Review owns comment
+  validation and crop generation; an approved verdict may include comments.
+
+  | New field paths | Why create does not interpret them |
+  | --- | --- |
+  | `comments` (including an empty list), `comments[].schema`, `.id`, `.summary` | Reviewer annotations, not a second approval status. The gate reads the producer's top-level `status`. |
+  | `comments[].part`, `.imageHash`, `.sourceHash` | Comment-specific identities owned by review. The gate binds all original source bytes through `source.files[]` and `source.sha256`, regardless of comments. |
+  | `comments[].imageRegion.{x,y,width,height}`, `.rigRegion.{x,y,width,height}` | Native and placed annotation coordinates; create consumes no region measurement and must not rederive it. |
+  | `comments[].view.camera.zoom`, `.camera.center.{x,y}`, `.camera.viewport.{width,height}` | Primary viewport camera, used to replay the review view, not to approve parts. All camera paths in this row are under `comments[].view`. |
+  | `comments[].view.cameraSync`, `.referenceCamera` (nullable), `.referenceCamera.zoom`, `.referenceCamera.center.{x,y}`, `.referenceCamera.viewport.{width,height}` | Reference viewport replay and synchronization; no camera consumer in this gate. |
+  | `comments[].view.{background,alpha,footprints,mesh}` | Display toggles, not part outcomes or producer measurements. |
+  | `comments[].crop.{path,sha256,width,height,png}` | Viewport crop metadata and inline PNG, owned by review; not the assembly source inventory. |
+  | `comments[].nativeCrop` (nullable in the type), `.nativeCrop.{path,sha256,width,height}` | Review-generated native crop evidence, not a replacement for the original part image. create binds the original bytes without regenerating a crop. |
+
+  `tests/fixtures/rig-review-parts-verdict-2/README.md` records the exact producer
+  head and reproducible command. Its empty-comment and pointed-comment verdicts
+  are unedited writer output. `tests/parts-verdict-v2.test.ts` exercises both
+  through `signoffCommand` then `checkProject`, tests comment-byte binding and
+  operation without external crop state, and applies source/mode refusal
+  controls to both schema versions. Existing `/1` fixture bytes are unchanged.
+
+- **The project record carries an agent-authored whole-figure difference map**
+  at `project.json.diff_map`, while the `parts-review` sign-off records only the
+  person's approval (`draft_id`, `evidence`, `structure`, `verbatim`).
+  Generate the report with the installed `rig-parts diff-components --out` on
+  the assembled stack and the painting in the same native canvas, then record
+  the agent's component classifications with `rig-create diff-classes`. create
+  reads the report and binds its exact bytes by SHA-256.
+
+  ```json
+  "diff_map": {
+    "by": "agent",
+    "at": "2026-11-09T00:00:50.000Z",
+    "report": { "path": "evidence/diff-components.json", "sha256": "<report sha256>" },
+    "components": [ { "id": "<report component id>", "status": "in-painting", "why": "<what was observed>" } ]
+  }
+  ```
+
+  ```sh
+  rig-create diff-classes --diff-report evidence/diff-components.json --component 'p10-n3=in-painting:the painting contains this edge' --by agent
+  rig-create signoff parts-review --by user --draft <id> --structure-file evidence/structure-decisions.json --verbatim-file approval.txt
+  ```
+
+  The `diff-classes` writer hashes the report and validates the entire map
+  before recording anything (`by` must be `agent`, refused otherwise with
+  `DIFF_MAP_NOT_AGENT`). Repeat `--component <id>=<status>:<why>` for every
+  component. The first `=` and first following `:` separate fields, so `why` may
+  contain colons. Every report id must appear exactly once, with no extra ids.
+  Status is `in-painting`, `fixed` or `left`, and every status requires a
+  nonempty `why`. For a large report, run `rig-create diff-classes --diff-report <path>`
+  without `--triage-file`, `--component` or `--by` first: in read-only mode it
+  prints JSON rows with deterministic ids, derived keys, member ids and counts,
+  pixel-count ranges and uncovered-fraction ranges. Keys use the exact sorted
+  border-part set and coverage band. Covered and uncovered bands have fractions
+  0 and 1; mixed bands are [0,0.25), [0.25,0.50), [0.50,0.75), [0.75,1).
+  This caps mixed spread below 0.25 without combining different border sets.
+  create groups producer fields; it never measures image pixels.
+
+  Supply `--triage-file triage.json` to `diff-classes --diff-report <path> --by agent`
+  instead of component flags:
+  `{"classes":{"<derived id>":{"status":"left","why":"covered edge observed in the painting"}},"components":{}}`.
+  Each decision contains only status and why; the writer derives the key and full
+  member list. A class reason must name at least one exact border part or its
+  coverage band (for example `mixed:0.25-0.50`). Inspect the images before deciding.
+  Components needing individual judgment can instead use the `components` map,
+  keyed by report id with the same status/why fields. Do not overlap decisions.
+  The file cannot be combined with component flags and requires a diff report.
+
+  The optional `diff_map.classes` list retains `{id, key, status, why, members}`;
+  each expanded component also retains `class_id`. Check re-derives each full
+  class and requires disjoint members and identical expanded status and why.
+  Per-component records remain compatible and do not acquire class requirements.
+
+  A report with no components needs only `--diff-report <path> --by agent`. Its spec must be
+  `rig-parts-diff-components/1`, `definition.floor_px` at most 2 and
+  `definition.threshold` at most 40. The stack is derived from the verdict's
+  covered `parts.json`, resolved relative to that verdict (or the latest draft
+  before sign-off). For its directory D, build writes `D/recomposite_rig.png`,
+  while standalone assemble writes `D/../render/recomposite_rig.png` only when D
+  is named `rig`. Exactly one candidate must exist and hash to the report's
+  `stack.sha256`. Neither or both candidates refuse rigging. create never
+  computes the map or runs the producer's `--verify`. This uses the latest
+  sign-off and the same rigging gate and acceptance boundary as the parts
+  verdict above. From `DIFF_MAP_SINCE` (2026-11-06T00:00:00Z), a missing map
+  refuses writing the sign-off and rigging. An earlier sign-off without one gets
+  only `DIFF_MAP_PREDATES`. From `DIFF_MAP_AGENT_SINCE` (2026-11-09T00:00:00Z),
+  `signoff parts-review` refuses `--diff-report`, `--triage-file` and
+  `--component` (`SIGNOFF_DIFF_MAP_REMOVED`), and a `parts-review` sign-off dated
+  from that boundary carrying `diff_map` is refused (`SIGNOFF_DIFF_MAP_REMOVED`);
+  an earlier `parts-review` sign-off carrying `diff_map` emits a
+  `DIFF_MAP_ON_SIGNOFF_LEGACY` warning and its map is still checked in full.
+
+  The filled example's report and stack are synthetic, with two listed
+  components. `bun scripts/generate-example-diff.ts <fresh scratch directory>`
+  regenerates them through the installed parts CLI and the `diff-classes` and
+  `signoff` writers. Add `--check` to reproduce the shipped report, stack and
+  inline record bytes.
+- **A project that passed `plan-approved` before these two stages existed**
+  (its first `plan-approved` sign-off is dated before 2026-11-04, the
+  `PARTS_REVIEW_SINCE` in `src/stages.ts`) is not given a sign-off nobody made.
+  The check reports it as a warning naming the project
+  (`PARTS_REVIEW_PREDATES_STAGE`): its parts were not reviewed before rigging.
+  Its `assemble` checkpoint, signed then as `rigging`, still counts. The date
+  is read from that sign-off because signing `plan-approved` is the dated,
+  human act that moved the project past where the two stages now stand.
+
+### The rig review rests on a still frame
+
+The rig is accepted at `rig-review` by **one verdict on one version**: a
+human `verdicts[]` entry with `"review": "rig-review"` and `"verdict":
+"accepted"` on a `kind: "rig"` version. The `{ "stage": "rig-review" }`
+sign-off moves the stage; the verdict names the version. They are the same
+act and are written in the same turn (the sign-off has no version field
+because the verdict already carries `by`, `at` and `verbatim` on the version
+it is about — a second copy would be a second place for one decision).
+
+That acceptance rests on a **still-frame record** in the same version's
+`evidence[]`:
+
+```json
+{ "kind": "still", "path": "evidence/v2/still-frame.png", "sha256": "…", "camera": "fixed", "frame": 2, "what": "the rig at the fixed camera, posed 2 s into the loop" }
+```
+
+| Field | Holds |
+| --- | --- |
+| `kind` | `"still"` — what marks this entry as the rig review's frame; other evidence entries may leave `kind` out |
+| `path`, `sha256` | the image under `evidence/v<N>/` and its 64-hex sha256 |
+| `camera` | `"fixed"`: no camera move, no parallax, no post-production; any other value is not a still frame |
+| `frame` | `"setup"` for the renderer's setup pose, or the time in seconds into the motion the rig is posed at. `0` is the motion's start, which is not the setup pose when the idle rests off it (a breath track whose `base` equals its `amp` passes through setup mid-loop) |
+| `what` | what it shows, in words |
+
+This repository does not render the still: rig-c/core and rig-c/review render,
+the `review <version> --from-review <actId>` writer fetches the
+raw act bytes and PNG through the live job API. The writer preserves the act bytes under
+`evidence/v<N>/`, binds them in `review_acts` by sha256 and verifies the PNG
+before recording it. Missing or mismatched PNGs refuse without changing
+`project.json`. Numeric frames record the animation name in `what`;
+no new record field or dated contract is introduced. An acceptance with no such record is refused
+(`RIG_ACCEPTED_WITHOUT_STILL`, [CHECKS.md](CHECKS.md)); a bounce needs none to
+be recorded, though what it rested on still goes in `evidence/`.
+
+**A rig changed after `rig-review`** is a new rig version, and the project is
+back at `rig-review` for it: past that stage, the latest rig version must carry
+its own acceptance (`RIG_VERSION_UNACCEPTED`). Once it is accepted, the post
+version built on the old rig is redone on the new one — the current (latest)
+post version naming an older accepted rig is refused (`POST_ON_SUPERSEDED_RIG`);
+earlier post versions are history and are left as they are. This is a refusal,
+not a warning: a direction review of a take built on a rig the user has since
+replaced would accept something that no longer matches the rig.
+
+### The hand-off to post-production
+
+```
+rig-create handoff [<project dir>] [--rig <n>] [--json]
+```
+
+Post-production tooling runs this before it runs. It exits `0` and prints the
+one rig version post work may run on — the latest accepted rig version, with
+its acceptance and its still frame — and exits `1` with a named refusal when
+there is none: no `rig-review` sign-off (`RIG_REVIEW_UNSIGNED`), no accepted
+rig version or a newer rig version not yet reviewed (`RIG_VERSION_UNACCEPTED`),
+an acceptance with no still frame (`RIG_ACCEPTED_WITHOUT_STILL`). With
+`--rig <n>` it also refuses when `<n>` is not that version
+(`POST_ON_UNACCEPTED_RIG`, `POST_ON_SUPERSEDED_RIG`). The `n` it prints is what
+the post version's `rig_version` holds. It reads the record and writes nothing.
+
+**When post is not passed.** If every post item is answered *not applicable* in
+`post-interview` (a collection member whose composition belongs to the
+collection, for example), the sign-off of `post-interview` says so and the
+project moves from there to `accepted`.
+
+### Split approval is a plan checkpoint
+
+The split — which parts the painting becomes — is the decision most often sent
+back, so it is shown to the user as a labelled image before the rest of the rig
+is built. It is a **checkpoint on the `assemble` step**, not a stage of its own:
+a stage and a checkpoint are the same act (a human signature before the next
+piece of work runs), so keeping both would record one approval in two places,
+and the plan lets the user stop at any waypoint, not only the split. The split's
+data (proposal image under `evidence/split/`, parts, labels) lives in `split`;
+its approval is the `signoffs[]` entry with `"stage": "parts", "checkpoint": "assemble"`. This checkpoint has no
+default: the user turns it on or off, or delegates it, like every other.
+
+### Generated split captions
+
+```sh
+rig-create split-captions [<project dir|project.json>] [--config <file>]
+```
+
+The command prints `rig-create/split-captions@0` JSON to stdout. A directory
+uses its `project.json`, and the default is the current directory. Config
+paths are relative to the project record's directory, defaulting to
+`config.json`. Redirect the result into the proposal's evidence directory.
+
+`inputs` records the project and config paths and SHA-256 of their exact bytes.
+`config[]` carries each top-level setting's `path`, structured `value` and
+machine-generated `text` (`path = JSON(value)`), including the assembly scale,
+plan, limb routes and bone bindings. `parts[]` preserves `split.parts` order
+and carries each `name`, `label` and generated `text` (`JSON(name) = JSON(label)`).
+A sheet renderer can use those strings directly. Every caption comes from the
+input data. Config annotations (`note`, `*_note`, `x-*`) are omitted, preserving
+exact-name map keys, including limb names, turn depth part names and depth
+source-layer names. `split.parts.note` is excluded.
+
+The installed parts parser validates complete rig configs through its full
+config door, and incomplete configs through its early `assemble` door, which
+checks the split's settings and reads bones with declared limbs. The output
+records declarations. Pixel assembly, rendered scale and motion acceptance
+require their own evidence. Exit 1 names an unreadable or malformed input,
+unknown project schema, malformed or duplicate split name, invalid label, or
+parts config refusal. Usage errors exit 2. Refusals produce no caption stdout.
+
+The worked list is [example-split/captions.json](../templates/example-split/captions.json),
+generated with the existing filled record and a synthetic config. Regenerate it
+from the repository root with
+
+```sh
+bun src/cli.ts split-captions templates/example-project.json --config example-split/config.json > templates/example-split/captions.json
+```
+
+[example-split/config.json](../templates/example-split/config.json) supplies
+synthetic config bytes because the filled record's historical config paths
+have no corresponding files. Its scale, coordinates, source tags, bindings and
+empty motion tracks are test inputs. The painting, split layers and rig output
+remain unverified by this caption fixture.
+
+## The plan
+
+The plan lives in `project.json` `plan`, not in a separate file: `project.json`
+is already the only place a decision is recorded and the first thing a resuming
+agent reads, and a second file is one a resume can skip.
+
+```json
+"plan": {
+  "drafted_by": "agent",
+  "drafted_at": "2026-11-10T15:30:00Z",
+  "steps": [
+    {
+      "id": "assemble",
+      "phase": "rig",
+      "order": 2,
+      "does": "Turn layers into parts, in draw order; propose the split as an image, one label per part",
+      "produces": "config assemble; split.proposal_image, split.parts[]",
+      "rests_on": ["assemble", "constraints"],
+      "bar": "Every part the assemble guide names exists; every part has one label; the setup-pose recomposite matches the painting",
+      "checkpoint_proposed": true,
+      "checkpoint": { "delegated": false, "by": "user", "at": "2026-11-10T16:00:00Z", "verbatim": "yes, show me", "value": true },
+      "status": "pending"
+    }
+  ],
+  "replaced": [
+    {
+      "step": {
+        "id": "camera",
+        "phase": "post",
+        "order": 1,
+        "does": "Keep a fixed frame.",
+        "produces": "A fixed camera track.",
+        "rests_on": ["camera_depth"],
+        "bar": "The approved rig stays within the frame.",
+        "checkpoint_proposed": false,
+        "checkpoint": null,
+        "status": "pending"
+      },
+      "sha256": "1f42b6a62120e479ea30aeb08244d5c35b8b4c3ec803f079489047d9e8f4bd61",
+      "action": "removed",
+      "at": "2026-11-10T15:30:00Z",
+      "by": "agent"
+    }
+  ]
+}
+```
+
+Draft steps with `rig-create plan add|revise|remove <id> [<project dir>]
+--by <drafter>`. Its `--help` lists their field flags. Draft dates follow the
+existing [phase-date contract](#explicit-adoption-of-the-split-interview),
+using both previous and resulting approval ownership on revision, with
+`drafted_by` updated only alongside `drafted_at`. Every write refuses
+additional checker findings counted by code and path before changing the file. Reopen live covering plan
+approvals first. Completed work, including completion retained by reopen,
+requires removal and a new id. Revise/remove append the full previous step
+to optional `replaced[]`, with its existing `stepHash`, action, ISO date and
+drafter. Entries retain write order, nondecreasing dates and unique
+`step.id` / `at` identities. Reopened signatures may resolve hashes and
+checkpoints against history. Live approvals bind current steps.
+
+- **Rig steps follow the waypoints**: one step per waypoint the plan passes, in
+  pipeline order, with the step's `id` equal to the waypoint's. The last rig
+  step also renders the still-frame check for `rig-review`. **Post steps**
+  (`phase: "post"`) are added in `post-interview`, one per post item passed.
+- **`rests_on` names the answers a step is built on** — waypoint ids, framing
+  ids (`rig_type`, `reference`) or post item ids; at least one. A step no answer
+  covers is not allowed: ask for the sentence first
+  ([INTERVIEW.md § Questions outside this set](INTERVIEW.md#questions-outside-this-set)).
+  A step resting on a delegation is legal; the delegation is read from the
+  guide, not restated here.
+- **`checkpoint`** takes the answer shape from INTERVIEW.md: the user's `true` /
+  `false` as `value`, or delegated. The drafter may fill `checkpoint_proposed`;
+  only the user (or a delegation) fills `checkpoint`.
+- **`bar`** is what *done* is measured by for that step, written before the
+  step runs. A sentence that names a part, effect or extent is a bar line
+  ([INTERVIEW.md § Direction is taken in sentences](INTERVIEW.md#direction-is-taken-in-sentences)).
+- **`status`**: `pending` → `in-progress` → `at-checkpoint` (waiting for a
+  sign-off) → `done`.
+- A changed guide — including one added from polish feedback — sends every step
+  that rests on it back for a new sign-off by its step-specific approval stage before it runs.
+- **Provenance**: each version built from a config records, per config
+  section, the guide sentence or delegation each entry follows
+  (`versions[].provenance`, [INTERVIEW.md § Provenance](INTERVIEW.md#provenance-every-config-section-cites-its-guide)).
+  An entry with no citation is removed or cited before the version is shown.
+
+## Recording a sign-off
+
+```sh
+rig-create signoff <stage> --from-review <actId> [<project dir>] [--json]
+rig-create signoff <stage> --by <who> [--steps <id,id,...>] [--verbatim-file <file>] [<project dir>] [--json]
+```
+
+The `signoff` command appends `signoffs[]` and leaves `project.stage` unchanged. `at`
+comes from the clock. There is no `--at` option. The user's UTF-8 words come
+from the file, or stdin when omitted or `-`, preserving BOM, spaces, CRLFs and
+final newlines. Invalid UTF-8 is refused because a JSON string cannot retain
+its original bytes.
+
+`--from-review <actId>` without `--checkpoint` is the review tool's stage
+sign-off route (with `--checkpoint <id>` it records a passed checkpoint act
+instead; see CHECKS.md). It fetches the person's
+finalized `signoff` act through the live job writer binding, the way
+`review --from-review` and `interview-answer --from-review` do, and validates
+it with the same decoder the check runs on the retained act bytes. The act
+supplies the stage (it must be the one named), the words, the person (`by` is
+`user` for the job owner, `delegate` otherwise) and `at`; `--by`,
+`--verbatim-file` and `--steps` are refused with it on both routes
+(`SIGNOFF_OPTION_INVALID`). For `plan-approved`, `rigging-interview` and
+`post-interview` the act's `source.plan` must list the current `plan.steps`
+ids and step hashes in order, or the write refuses `REVIEW_ACT_SOURCE_STALE`;
+coverage and `step_hashes` then follow the writer's usual rules. For
+`rig-review` and `direction-review` the act's `source.selector` names the
+version the person was shown (a `rig` version, or a `post` version), and that
+version is the signature's `target`; `--version` may only repeat it. A missing
+or other-kind selector, or a different `--version`, refuses
+`REVIEW_ACT_TARGET_MISMATCH`. The signature
+names its act in `source` (`review act <jobId>/<actId>`), and `review_acts[]`
+retains `{ kind: "signoff", jobId, actId, stage, bytes, sha256, version_hash }`.
+Replaying the same act returns the recorded signature unchanged.
+
+For new-order `plan-approved`, coverage is the parts steps; `rigging-interview` covers the remaining rig steps. Legacy `plan-approved` covers every rig step. For `post-interview`, it is
+every post step. `--steps` narrows coverage within that phase and stores the
+covered ids in `steps[]`. Execution stages accept `--checkpoint <step id>`
+when that step runs in the
+named stage and its recorded checkpoint is enabled. This records
+`checkpoint: <step id>`, without `steps` or `step_hashes`. It cannot be combined
+with `--steps`.
+
+`parts-review` requires `--evidence <verdict path>`. The command stores
+`{ kind: "parts-verdict", path, sha256 }`, resolving filesystem links,
+normalising the path to project-relative POSIX form and hashing the file. The existing parts-verdict reader validates
+approval, shape and source freshness before anything is written. Other stages
+refuse `--evidence`.
+
+Only `plan-approved`, `rigging-interview` and `post-interview` accept `--steps`. Stage movement
+remains a separate act read by the check.
+
+Each covered step needs a boolean `checkpoint_proposed`. A null checkpoint
+becomes `{ delegated: false, by, at, verbatim, value: checkpoint_proposed }`.
+Existing user answers and decided delegations stay as recorded. An undecided
+delegation, malformed checkpoint or unknown step refuses the whole command
+before the file is written.
+
+Each plan signature also records `step_hashes`, mapping covered step ids to
+SHA-256 of UTF-8 JSON with object keys recursively sorted and array order
+preserved. The fields are `id`, `phase`, `order`, `does`, `produces`,
+`rests_on`, `bar`, `checkpoint_proposed` and `checkpoint`, after filling the
+checkpoint. Absent fields are omitted. `status` and other fields are excluded.
+The shared implementation is `src/step-hash.ts`.
+
+The four answer approvals (`interview`, `plan-approved`, `rigging-interview`,
+`post-interview`) also record `answer_hashes`, mapping item ids to SHA-256 of
+UTF-8 `JSON.stringify(sorted({ raw, resolved }))`: the local answer object
+and the answer resolved through collection inheritance (or null). Object keys
+are recursively sorted; array order is preserved. Both objects exclude
+`history`, `prompts`, `config`, `text`, `source` and `required_for`.
+The interview approves answers and delegations without `agent_decision`; plan
+approvals also bind the decisions their covered steps rest on.
+The writer captures every currently answered interview item, or the union of
+`rests_on` in its covered steps; an unanswered step basis refuses the write.
+An honestly empty set records `{}`. When every post item is N/A and there are
+no post steps, the user still signs post-interview with `steps: []` and bindings
+for every N/A post answer. Interview completeness requires a map,
+without comparing its keys to today's answered items or their dates.
+The latest live interview signature replaces the whole earlier interview map,
+so omitted unanswered items lose approval and earlier interview bindings are superseded.
+Plan-stage signatures supersede earlier bindings per item within the same stage,
+while completeness still follows each signature's own covered steps.
+Only live approvals are checked, using the same reopen and amendment liveness
+as other approvals. A changed or removed bound item refuses
+`SIGNOFF_ANSWERS_STALE`; an absent or incomplete map refuses
+`SIGNOFF_ANSWERS_MISSING` from `SIGNOFF_ANSWERS_SINCE = 2026-11-06T00:00:00Z`,
+and earlier signatures receive one `SIGNOFF_ANSWERS_MISSING_LEGACY` warning.
+These bindings do not preserve approvals during amendments: G2 lapse behavior
+and `keep_by_binding: []` remain unchanged until G8 is implemented.
+
+
+`review` accepts `--verbatim-file <file>` (or `-` for stdin) instead of
+`--verbatim`, and `--at <timestamp>` instead of the clock. Repeatable
+`--answers-feedback <version>:<verdict-index>` appends references to the
+reviewed version's `answers_feedback`. Each reference must identify an
+existing verdict of an earlier version and must not duplicate an existing or
+new reference. Both writers refuse `by: agent` case-insensitively.
+
+## Versions
+
+A reopen preserves every version and verdict; a rebuild is a new numbered
+version, never an overwrite of an accepted historical build.
+
+After a human bounce, `next` reads check's `FEEDBACK_OPEN` finding and names
+the agent rebuild instead of asking for another verdict or sign-off on the
+bounced version. `rig-version` and `direction write` / `direction patch`
+accept repeatable `--answers <version>:<verdict-index>` options, recording
+those entries in the new version's `answers_feedback`. Each entry must name
+an earlier human bounced verdict and must occur only once. Without the needed
+entries the writer refuses `FEEDBACK_UNANSWERED`, leaving `project.json`
+byte-identical. Existing historical references and `review --answers-feedback`
+keep their earlier target rules: any existing verdict on an earlier version.
+After rebuilding, `next` requests the new version's review; no stage or
+human approval is supplied by answering feedback.
+
+A rig version's provenance config, review package and accepted parts must identify the same build.
+
+Every build shown to anyone is a `versions[]` entry, numbered in order across
+both kinds:
+
+| Field | Holds |
+| --- | --- |
+| `n` | the version number, `1, 2, …` |
+| `original_n` | on pre-interview versions only, the unchanged source id as a number, string or `null`; non-null ids are unique |
+| `config_lost` | on pre-interview versions only, `{ note, source }` with nonempty strings when the build config did not survive; cannot accompany `provenance.config` or authorize post work |
+| `outputs_lost` | on pre-interview versions only, `{ note, source, recorded? }` with nonempty strings and missing `recorded: [{ path, sha256 }]` bindings disjoint from surviving `outputs` (or `{ note, source }` beside `outputs: []`) when frozen outputs did not survive; cannot authorize post work |
+| `kind` | `rig` or `post` |
+| `rig_version` | for a post version, the `n` of the accepted rig it is built on (accepted before the post version's `at`); `null` for a rig version |
+| `at`, `built_by`, `built_with` | when, which agent or tool, and the package versions used (`{ "@rig-c/parts": "…", "@rig-c/core": "…" }`) |
+| `review_origin` | null for a build made without review feedback, otherwise the applied-round record below |
+| `answers_feedback` | the verdicts this version answers: `[{ "version", "verdict" }]` (version number and index into its `verdicts[]`); empty for a first version |
+| `changed` | what changed from the previous version of the same kind, in a sentence |
+| `outputs` | `outputs/v<N>/` files with sha256 and size, frozen when shown |
+| `evidence` | `evidence/v<N>/` files with sha256 and what each shows; on a rig version accepted at `rig-review`, one is the still-frame record (`kind: "still"`, `camera: "fixed"`, `frame`) |
+| `provenance` | the config this version was built from and, per section, its citations |
+| `verdicts` | what people said: `by`, `at`, `review`, `verdict` (`accepted`, `bounced`, `provisional`), `verbatim`, `source`, `on_items[]` |
+
+A provenance citation may add `asks: ["<ask id>", …]`, naming the
+canonical asks its guide records in `answer.asks`. For example,
+`{ "entry": "torso", "guide": "meshes", "asks": ["bend"], "quote": "The coat is one piece" }`
+cites the user-answered bend ask. A delegated density citation uses
+`{ "entry": "density", "guide": "meshes", "asks": ["density"], "delegated": true }`
+and needs that answer's decided `agent_decision`. Each named ask's coverage
+and supporting quote or decision must come from the same answer, including
+answers preserved in history. A user ask requires a quote and cannot be
+claimed as delegated. Missing ids on a guide with per-ask coverage warn.
+
+A verdict item with `answer_was: "delegated"` may add `ask: "<ask id>"`.
+The ask must be recorded as delegated in a current or historical answer.
+`rig-create review … --item meshes:delegated --ask meshes=density` writes
+that field. `--ask` is optional, accepts one ask per named item, and is for
+delegated feedback. Missing it on a guide with per-ask coverage warns.
+Guides without per-ask coverage gain no finding when these fields are absent.
+
+`provisional` is a verdict given before the person has seen everything they
+want to see — it holds a place and is replaced, never a basis for moving a
+stage.
+
+### Registering a frozen rig build
+
+Use `rig-version` to bring separately located frozen producer outputs into one
+numbered version. This is a registration operation. Build, registration and
+acceptance have separate dates and writers.
+
+```sh
+rig-create rig-version 3 . \
+  --parts frozen/assembly/rig --rig frozen/out/rig --build frozen/out/build \
+  --idle frozen/render --config frozen/config.json \
+  --path-adapter frozen/path-adapter.json --compile-report frozen/build-report.json \
+  --toolchain-lock frozen/package-lock.json \
+  --at-source frozen/dated-record.json --at-pointer /finished_at --by agent \
+  --citations frozen/section-citations.json
+```
+
+Source arguments resolve against the project directory. Absolute arguments may
+name external frozen inputs. The writer retains copies under
+`evidence/v<N>/registration/` and binds their exact bytes by SHA-256. The project
+record refers to those retained paths, including the lock and cited date record.
+
+`built_with` comes from the declared npm v3 lock's
+`packages["node_modules/@rig-c/parts"].version` and corresponding core entry.
+`registration.toolchain` is `{kind:"npm-lock-v3",source:{path,sha256,bytes}}`.
+The `--toolchain-lock` argument explicitly declares the run-to-toolchain
+association. This declaration establishes which frozen lock the registrant
+selected. Producer-owned run attestation, including versions, start/finish and
+output hashes, is tracked in parts#1165 and core#1718. A future source kind can
+be added when that producer interface lands. Current readers support
+`npm-lock-v3` only. Wrapper receipts and toolchain summary files supply no
+registration contract.
+
+Repeatable `--run-record <file>` binds at most one producer `run.json` per
+spec beside `--toolchain-lock`, recorded in the order given as
+`registration.runs: [{spec,source:{path,sha256,bytes}}]`. The dispatcher in
+`src/run-record.ts` accepts `rig-run/1` (`@rig-c/parts` `rig` or `assemble`) and
+`rigc-run/1` (`@rig-c/core` or its `rig-c` alias, `build`, with required `rig` and `motion` input roles and
+optional `manifest` and `cuts` sorted in that role order and UTF-16 code-unit
+path order), validating only the published keys, key order and types without
+re-running or recomputing producer measurements. `interview --check` re-reads
+each bound record and refuses a byte/SHA-256 mismatch
+(`RUN_RECORD_HASH_MISMATCH`), an unknown spec (`RUN_RECORD_SPEC_UNKNOWN`), a
+missing or malformed input role (`RUN_RECORD_ROLE_INVALID`) or a malformed
+shape (`RUN_RECORD_MALFORMED`). Lock-only `frozen-rig/1` versions without
+`registration.runs` WARN before `RUN_RECORD_SINCE = 2026-11-08T00:00:00Z` (by
+`registration.at`) and refuse from `RUN_RECORD_SINCE` onward under
+`RUN_RECORD_REQUIRED`.
+
+`at_source` is `{path,sha256,bytes,pointer}`. The nonempty RFC 6901 JSON pointer
+selects an explicit UTC ISO timestamp ending `Z` or `+00:00`, including fractional
+seconds. `at` preserves that exact string and `at_basis` is `"not-after"`.
+The registrant declares that the build had finished by that cited instant.
+The clock supplies `registration.at`. A cited bound at or before a reopen
+covering `rig-review`, as of registration, refuses the write. A later bound is
+admitted with its retained citation for review. A reopen after registration
+preserves the historical record and the existing liveness rules supersede it.
+Acceptance dates remain on verdicts written through the review and signoff flow.
+
+The copied rig, motion and model use producer specs `rigc-rig/1`,
+`rigc-motion/1` and `rigc-compiled/3`. The producer's compile document must
+be a successful `build-report/1`. Idle
+evidence is a public `rigc render` directory with `frames.json`, spec
+`rigc-frames/1`, and an `idle` set. The writer binds that manifest and every
+copied frame and diagnostic file. It preserves the producer's fps, viewport,
+skin and preroll declarations, including optional-field absence. A directory
+containing only images and a wrapper receipt needs a public producer re-render.
+
+The copied output layout is `outputs/v<N>/out/parts.json`, `out/parts/`,
+`out/rig/`, `out/check/build/` and `outputs/v<N>/idle/`. Every copied output
+gets its actual `path`, `sha256` and `bytes` in `versions[].outputs`.
+`registration.copied` records file and byte totals. Sources are rechecked after
+copying, and the copy is byte-verified before registration. The normal
+`review-package` materializer then creates `derived/review/v<N>/`, using the
+same accepted-parts and config identity checks as its standalone command.
+
+The retained original config and adapter are bound as `registration.config_source`
+and `registration.path_adapter`. Registrations using pointer adaptation declare
+`registration.path_adapter.format` as `json-pointer/1`. Removing an adapter row
+keeps that contract active. These registrations also bind the original
+and runtime requirements as `registration.requirements_source` and
+`registration.requirements`. Each absolute config value requires an exact
+adapter row `{at:".section.field",before,after}` matching its runtime `after`
+value, and relative `config` or `requirements` asset references use explicit
+`{doc:"config"|"requirements",pointer,before,after}` rows (recorded in the
+retained `path-adapter.json`). The writer retains the original `config` and
+`requirements` byte-identical, copies every referenced asset (`assemble.take`,
+`assemble.editor_receipts`, `assemble.cuts`, `limbs`, `depth`,
+`setup_painting.figure_mask` and `setup_painting.backdrop`) to literal
+in-package paths (`no ..`, `no :`), verifies declared `sha256` digests before
+copying, and checks that the runtime `config.json` and `requirements.json`
+equal the retained sources after applying only the declared `path_adapter`
+substitutions. Registrations without pointer adaptation retain their original
+implicit take and editor-receipt relocation, permit unused legacy adapter rows
+and do not require source-only relative assets or a backdrop that their writer
+did not retain. Missing mappings, unlisted runtime differences, escaping
+references, symlinks, hash mismatches and incompatible file or directory
+collisions refuse. Identical file bytes may share a target, including an
+explicit image inside a named plate directory. Producer
+outputs retain their original bytes. Packaging relocates the config's and
+requirements' named inputs without rerunning producer measurements.
+
+Optional `--citations` reads an agent-authored map of the existing
+`provenance.sections` shape. The writer retains that map and binds the adapted
+config under `provenance.config`. Omission records an empty section map. The
+writer runs the full check on the candidate record and refuses any refusal it
+adds, so every applicable config section needs its citation at registration.
+
+`registration.kind` is `"frozen-rig/1"`. The registration validator is shared
+with `interview --check` and opts in only versions carrying `registration`.
+Existing versions keep their contract, so this additive writer adds no SINCE
+constant. When `n > maxRegistered + 1`, every skipped number `K` between the
+previous highest registered version and `n` must already have at least one
+unregistered destination directory (`outputs/v<K>`,
+`evidence/v<K>/registration` or `derived/review/v<K>`) present on disk at
+registration (re-verified before rename); the writer records the admission
+receipt `registration.skipped` as `[{n:K,destinations}]`, and `interview --check`
+validates that receipt (`prevMax + 1 .. n - 1`, unregistered numbers and
+nonempty canonical destination paths) without re-statting historical directories
+after archival or in retained closures. Unexplained empty gaps, occupied
+destinations on `n` itself, registered numbers in `skipped` and non-directory or
+symlinked destination paths at registration refuse. Versions that advance by one
+(`n === maxRegistered + 1`) omit `registration.skipped`. The writer validates
+its registration and normal
+package identity,
+checks that project bytes are unchanged during copying, then atomically records
+the new version. A refused write preserves project bytes and removes its newly
+created outputs, retained inputs and review package. Retry uses the same next
+number after a refusal. A successful version remains frozen.
+
+Registration leaves stage, signoffs and verdicts intact. The human review uses
+the emitted review package, existing review/signoff writers record the result,
+and `advance` performs the authorized forward move. The synthetic public-render
+fixture and its producer commands are documented in
+[tests/fixtures/rig-registration](../tests/fixtures/rig-registration/README.md).
+
+### Migrating work done before the interview
+
+Keep `kind: "rig"` or `"post"` and add `pre_interview: true`. The flag records
+when the work was made while preserving which review judges it and which rig
+post work rests on. These versions need no `provenance`. Create-built versions
+continue to cite their interview and retain the user's words in verdicts.
+
+A pre-interview verdict has create's `by`, valid `at`, `review`, `verdict`,
+`source` and `on_items[]`. When the words survive, keep them in `verbatim`.
+When only someone's record of the user survives, set `verbatim: null`, state
+that it is a record in `note`, put the record there and name its `source`.
+The check requires the note and source. A summary never becomes an interview
+quotation. Historical `not-asked` items remain in the verdict without invented
+`additions[]` in today's guide. Current answers and sign-offs are still checked.
+
+Keep the complete original verdict array unchanged in `original_verdicts` on
+the version. Its entries occupy the same indices in `verdicts[]`, each copied
+unchanged into `as_recorded` beside the converted fields. The check compares
+all fields and the array order, including repeated verdicts. Further reviews
+may be appended without `as_recorded`. The original `verdict` string maps by
+this exact table, also exported as `PRE_INTERVIEW_VERDICTS`.
+
+| Original `verdict` | Create `verdict` |
+| --- | --- |
+| `accepted`, `Accepted` | `accepted` |
+| `accepted (sent to owner)`, `Accepted (sent to owner)` | `accepted` |
+| `bounced`, `Bounced` | `bounced` |
+| `provisional`, `Provisional` | `provisional` |
+| `accepted (HQ-provisional, sent to owner)` | `provisional` — the reviewer marked “HQ-provisional”, org HQ ruling 2026-11-06 |
+| `accepted-provisional` | `provisional` — the reviewer marked “provisional”, org HQ ruling 2026-11-06 |
+| `ok for now, polish wanted` | `accepted`, polish in `on_items[]` — owner 2026-11-03, “`<pilot>`도 여기까지 OK” and “일단 여기까지는 OK”; org HQ ruling 2026-11-06 |
+| `close, polish wanted` | `provisional`, polish as its open item — owner 2026-11-03, “`<pilot>` 많이 좋아졌다. 조금만 더 다듬으면 되겠어”; org HQ ruling 2026-11-06 |
+
+An unlisted string is refused as `PRE_INTERVIEW_VERDICT_UNKNOWN`. Preserve it
+and obtain an explicit mapping before extending the table. A converted value
+that disagrees with the table is `PRE_INTERVIEW_VERDICT_MISMATCH`.
+
+Every historical version lists its frozen `outputs[]` with project-relative
+`path`, `sha256` and `bytes`. The check reads every file and compares its hash
+and size. If frozen outputs did not survive, declare
+`outputs_lost: { note, source, recorded }` via
+`rig-create version outputs-lost <n> --note <text> --source <text>`, keeping any
+outputs still readable with their recorded sha256 in `outputs` (`outputs: []` when
+none survived) and moving the missing ones into `recorded: [{ path, sha256 }]`
+alongside what was lost and the source record that says so. Both
+`note` and `source` must be nonempty strings. Earlier `{ note, source }`
+declarations beside `outputs: []` without `recorded` remain valid, so no contract
+date is added. A loss declaration without `recorded` beside nonempty `outputs`,
+a `recorded` entry overlapping `outputs` or readable on disk, or `outputs_lost`
+on a create-built version is refused (`PRE_INTERVIEW_OUTPUTS_LOST_MALFORMED`). If
+no output is lost (every recorded output is readable on disk with its sha256),
+the writer refuses (`OUTPUTS_LOST_HAS_OUTPUTS`) and names the readable outputs.
+Handoff refuses a selected rig with `outputs_lost`
+as `PRE_INTERVIEW_OUTPUTS_LOST`, and post records cannot use it as their rig
+basis (`POST_ON_UNACCEPTED_RIG`). All
+pre-interview versions precede the first create-built version, with positive,
+strictly increasing `n` across the combined history.
+
+For a lost build config, first recover the producer version from that version's
+own source record and put it in `built_with["@rig-c/parts"]`. A version's
+producer is recorded from its own source record, never inferred from neighbours.
+A producer older than 2.4.0 receives `CG_GATES_PREDATE` on a CG rig.
+If the config did not survive, declare `config_lost: { note, source }` with
+nonempty strings explaining the loss and naming its source. This requires
+`pre_interview: true` and absent or null `provenance.config`. A CG rig receives
+`CG_GATES_CONFIG_LOST` instead of `CG_GATES_UNREAD`, preserving the check exit
+when the rest of the record passes. A known old producer and a declared config
+loss receive both warnings. The declaration is also available when the source
+names no producer version. Handoff refuses a selected rig with this declaration
+as `PRE_INTERVIEW_CONFIG_LOST`; post records cannot use it as their rig basis.
+Build and accept a new rig with its retained config before post work.
+
+An accepted pre-interview rig with surviving outputs and no config loss still
+authorizes post work. Its human
+`rig-review` verdict, valid acceptance time, still-frame record and
+`rig-review` sign-off remain required. `handoff` reports `pre_interview` in
+JSON and prints that status and the verdict's source in text. It also lists
+the note and source of historical output losses, and refuses a selected rig
+whose outputs were lost. A later rig
+requires its own acceptance and supersedes the older rig in the usual way.
+Other checks, including the CG gates where applicable, continue to run.
+
+For an in-flight consumer project keeping history under `x-pre_create.versions`,
+perform the following migration on its own decision record.
+
+1. Preserve the original array and frozen outputs before editing. For each
+   version, recover its complete original verdict array from the existing
+   `as_recorded` entries or the source record. Keep that array in
+   `original_verdicts` and retain each full entry as `as_recorded` at the same
+   index. Do not replace a missing original with a reconstructed quote.
+2. Move the historical entries into `versions[]`, keeping `kind` and adding
+   `pre_interview: true`. Put them before the create-built entries, preserve
+   a copy of the source id in `original_n` (number, string or `null`). Assign
+   positive, strictly increasing `n` in record order. Non-null `original_n`
+   values must be unique; multiple nulls are allowed. Rewrite `answers_feedback`
+   version references and post `rig_version` references to the new `n`.
+   Create-built versions carry no `original_n`.
+   Every migrated rig version must retain a readable `at` from its build record;
+   if no date can be recovered, stop the migration rather than inventing one
+   (`RIG_VERSION_AT_INVALID`).
+   Remove the moved `x-pre_create.versions` array. A nonempty array left there
+   produces the `PRE_INTERVIEW_UNMIGRATED` warning while migration is pending.
+   It preserves the existing check exit code. Migrated records are checked
+   with the refusals described above.
+3. Fill create-shaped verdict fields from known records, using the mapping
+   table, stating their source and recording summaries as `verbatim: null`
+   with `note`. Preserve carried `on_items[]` and map them to the interview's
+   item ids. Recover dates from dated evidence without inventing them.
+4. First record any producer version named by each version's own source in
+   `built_with`; never infer it from neighbouring versions. Restore the build
+   config and its provenance binding if it survived. Otherwise declare
+   `config_lost: { note, source }` explaining the loss and its source; this
+   version cannot authorize post work. `rig-create version config-lost <n> --note <text> --source <text>`
+   writes this declaration.
+   Restore each frozen output and record its actual `path`, `sha256` and
+   `bytes`. When some or all frozen outputs did not survive, declare `outputs_lost`
+   with the known loss in `note` and its record in `source`;
+   `rig-create version outputs-lost <n> --note <text> --source <text>` keeps
+   any readable outputs in `outputs` (`outputs: []` when none survived) and
+   moves the missing `{ path, sha256 }` bindings into
+   `outputs_lost.recorded`. Check that all
+   `answers_feedback` and `rig_version` references use the new `n`, including
+   references from create-built entries. Retain acceptance stills and genuine
+   stage sign-offs. The flag
+   supplies no missing review evidence or sign-off.
+5. On the first create-built version, list the earlier feedback it answers in
+   `answers_feedback`, including carried items where relevant. The existing
+   `review --answers-feedback <version>:<verdict-index>` writer can append
+   these references. Keep that version's provenance and interview words.
+6. Run `rig-create interview --check <project dir> --json`, resolve the named
+   refusals and inspect `rig-create handoff <project dir> --json` before post
+   work. The synthetic [migration fixture](../tests/data/pre-interview.json)
+   contains one bounced rig and one accepted rig carrying a timing item.
+
+## The record, field by field
+
+Top-level fields of `project.json`:
+
+| Field | Holds |
+| --- | --- |
+| `schema` | `rig-create/project@0` |
+| `name` | the folder name; a short identifier |
+| `title` | the human title of the painting or rig |
+| `stage`, `stage_values` | the current stage and the list it comes from |
+| `signoffs[]` | every human signature: `stage`, `checkpoint` (step id or `null`), `by`, `at`, `verbatim`; plan signatures add `steps[]` naming covered steps and `step_hashes` binding their approval fields. `by` names whose decision is recorded, including their delegated instruction written by an agent, and `by: "agent"` remains refused (`SIGNOFF_NOT_HUMAN`). |
+| `interview` | `question_set` (the prompt set and package version the waypoints were read from), `held`, `date`, `interviewer`, `respondent`, `framing[]` (`id`, `text`, `source`, `required_for`, `answer`, `history[]`), `waypoints[]` (`id`, `config[]`, `prompts[]` of `id`/`text`/`source`/`required_for`, `guide`, `history[]`), `post` (`held`, `date`, `items[]` shaped like waypoints with `guide`) — answer shapes in [INTERVIEW.md](INTERVIEW.md) |
+| `plan` | `drafted_by`, `drafted_at`, current unique `steps[]`, optional append-only `replaced[]` — above |
+| `plan.replaced[]` | full previous `step`, `sha256` from `stepHash(step)`, `action` (`revised` or `removed`), ISO `at`, drafter `by`, identified by `step.id` plus `at`, in nondecreasing date and write order |
+| `split` | the `assemble` checkpoint's data: `label_values`, `proposal_image`, `proposed_by`, `proposed_at`, `parts[]` (`name`, `label`, `note`) |
+| `inputs[]` | `path`, `sha256`, `bytes`, `origin` (where the file came from, in words), `at` (writer timestamp) |
+| `derived[]` | `path`, `what`, `command`, `inputs[]` (`path`, `sha256`), `bytes` |
+| `versions[]` | above |
+| `archive` | `null`, or `{ "where", "at", "by" }` if the finals were moved out of the project |
+| `collection_binding` | optional on collection members: `{ "path", "sha256", "spec": "rig-create/collection-binding@1", "collection_sha256" }` binding a project-relative snapshot of `../../collection.json` so retained checks and model-free record publication run without reading outside the member root |
+| `notes[]` | free text that is not a decision; anything that is one goes in the field it belongs to |
+
+## How an agent resumes a project
+
+1. Read `project.json` — nothing else first. `stage`, the last `signoffs[]`
+   entry, the first `plan.steps[]` entry not `done` and the last `versions[]`
+   entry say where it stands. For a collection member, read the collection's
+   `collection.json` next ([COLLECTIONS.md](COLLECTIONS.md)): its stage and
+   `plan.order` say whether this member may run now, and its interview holds
+   every answer marked `inherited`.
+2. If the interview has a `null` answer or the plan is unsigned, that is the
+   next work, and it is the user's to answer; do not fill it from the image.
+3. If the last version was bounced, its verdict's `verbatim`, its `on_items`
+   and the files in its `evidence` are the brief. Open the evidence; do not
+   reconstruct the reason from chat. Feedback with `answer_was: "not-asked"`
+   becomes a guide sentence at its waypoint before the next version is built.
+4. Check `inputs[]` hashes against `inputs/` before using them.
+5. Reuse `derived/` only through `derived[]`: an entry whose input hashes no
+   longer match is stale — regenerate it with its recorded command.
+6. When a new version is shown to anyone: freeze `outputs/v<N>/`, hash it, add
+   the `versions[]` entry and its evidence in the same turn.
+
+### Registering immutable inputs
+
+```sh
+rig-create input add inputs/source.png [<project dir>] --origin "synthetic source exported by the painting tool" [--painting [--projects-root <dir>] [--same-artwork-reason <file>]] [--json]
+```
+
+Run from the project, or pass its directory after the source path. The writer
+appends `{path, sha256, bytes, origin, at}` using the file's raw bytes and the
+current UTC timestamp. `--json` prints that record. It refuses an escaping or
+missing source, an already registered path, and changed bytes under a
+registered name. Add `--painting` to declare this registered input's path as
+`project.painting`. Each project has one declaration. A second declaration
+refuses with `INPUT_PAINTING_EXISTS`, preserving the original painting and reason.
+Only `init --painting` and `input add --painting` compare the declared file
+against sibling inputs. They refuse with `INIT_ARTWORK_EXISTS` when a
+`project.json` directly under `--projects-root` (default the project's parent
+folder) has an input with the same sha256, unless `--same-artwork-reason <file>`
+is given. This records `same_artwork: { reason, at, projects }`, preserving any
+previously recorded reason. Both artwork options require `--painting`.
+Plain `input add` accepts identical inputs across sibling projects. Older
+records may omit `painting`. Position, name and file type never declare it.
+The shared checker refuses `INPUT_PAINTING_INVALID` when a declaration is not
+the path of a registered input. Restart validates and preserves the declaration.
+A changed source needs a new file with a new name. A refused write leaves
+`project.json` byte-identical. The shared checker checks complete records against their retained files. Incomplete
+writer metadata is `INPUT_WRITER_MISSING`, dated by `inputs[].at` from
+`INPUT_WRITER_SINCE`. Earlier or unreadably dated entries WARN and retain their
+original history.
+
+## Prepared inputs and agent-found bounces
+
+`rig-create derived add [<project dir>] --source inputs/source.svg --file derived/prepared.svg --operation "external scale and white composite"`
+records work already performed by another tool. It appends one `derived[]`
+entry; it transforms no pixels and changes no sign-off or stage. `derived add`
+is used instead of `prepare` because the operation has already run elsewhere.
+Both files must exist, have distinct project-relative paths, and be readable.
+Neither may be `project.json`: appending the record would change its own hash.
+The command measures both sha256s before writing anything:
+
+```json
+{
+  "kind": "prepared-input",
+  "source": { "path": "inputs/source.svg", "sha256": "<64 hex digits>" },
+  "path": "derived/prepared.svg",
+  "sha256": "<64 hex digits>",
+  "operation": "external scale and white composite"
+}
+```
+
+`interview --check` requires the source and verifies its hash. A missing source
+or changed bytes in either present file are refused by name. A missing result
+warns with its file name and recorded operation, so a fresh clone passes while
+regenerable intermediates are absent. Only entries tagged `kind: "prepared-input"` use this contract; older
+untagged intermediates and projects with no `derived[]` entries keep passing.
+Restore derived files with the recorded operation when needed. The recorded
+hashes describe the bytes that must return.
+For a producer plate, supply `--source` for both its painting and uploaded mask,
+`--file` for its output, and `--receipt` for its `rig-parts-plate-receipt/1` JSON.
+The optional `receipt` records `{ path, sha256, spec }` from raw bytes. Its file
+must stay inside the project with no symlink components. Receipt paths resolve
+relative to the receipt directory. The checker compares declared paths and hashes
+to the derived sources and output, without repeating producer measurements.
+A retained scene registration identifies a derived plate. Its earliest scene
+`at` dates missing-receipt warnings or refusals under `PLATE_RECEIPT_SINCE`.
+
+The filled example ships synthetic SVG bytes under
+[example-prepared](../templates/example-prepared/); copy `source.svg` to
+`inputs/preparation-source.svg` and `prepared.svg` to `derived/prepared.svg`
+when materializing its prepared-input record. These fixtures demonstrate
+recording, not a claim that the tool performed or verified pixel processing.
+
+Busy-ground figure masks have a coverage gap: foreground subtraction excludes
+character pixels under that plane, so `SETUP_MATCHES_PAINTING` can pass with
+parts missing there. Keep the [default recipe](CHECKS.md#busy-ground-figure-masks).
+A character-plate matte can include inpaint fill as figure;
+[#113](https://github.com/rig-c/create/issues/113) tracks that upstream plate-making
+problem.
+
+An agent rejecting its own route mid-step records it in that guide's
+`history[]`, separately from human `versions[].verdicts[]`:
+
+```json
+{
+  "at": "2026-11-11T08:00:00Z",
+  "bounce": {
+    "cause": "agent",
+    "failed": "The first split merged the eyelids into the face",
+    "bar": "Blink needs the eyelids as their own layers",
+    "replacement": "Run a head pass as well as the full pass"
+  }
+}
+```
+
+`failed`, `bar`, and `replacement` are non-empty text: what failed, against
+which bar, and what replaced it. This record does not grant a new user choice
+or sign-off and does not create a human review verdict. The check reads local
+histories and the collection histories an inherited answer cites. Compatibility
+is per history entry's own `at`, not the project's age: malformed bounces before
+`AGENT_BOUNCE_SINCE` (`2026-11-05T00:00:00Z`), or with no readable date, warn
+with the new shape. Malformed bounces on or after it are refused.
+
+### The package handed to rig review
+
+Before showing a create-built rig version, run from the project directory:
+
+```sh
+rig-create review-package 1 --config evidence/v1/config.json --from outputs/v1/out
+```
+
+The source paths are explicit, project-relative inputs. The command copies the
+config unchanged and the build's `parts.json`, `parts/`, `rig/`, and
+`check/build/` into `derived/review/v1/`, with the config at `config.json` and
+the build files under `out/`. Every config-relative file named by the installed loader is copied at its relative path and included in the frozen inventory, including nested requirements, animations and a file-based control skeleton. The source build must include `rig/rig.json`,
+`rig/motion.json`, `rig/mesh_report.json` and
+`check/build/skeleton.model.json`. Copies preserve the package when the build
+directory is cleaned. The packager also retains `setup_painting.figure_mask.path` from the frozen requirements at its requirements-relative path, verifies its declared SHA-256, and records its package binding. Each copied file is hashed. The command writes no new
+build and moves no stage.
+
+A config's named files are bound build inputs in versions and drafts, with draft inputs recorded separately as optional `config_inputs` path/raw-sha256 bindings while `files` remains outputs. A draft's named input binds at its project path wherever it sits inside the project, and is not copied into `derived/drafts/<id>`; only the draft's config, parts and outputs live under that root. A named input outside the root is a project input, not a regenerable draft artifact, so its absence refuses rather than warning `DRAFT_RIG_UNAVAILABLE`. A named input that is a directory, such as a See-through occluder plate named by `assemble.occluders[i].plate`, binds its producer's `receipt.json` — as `{path: <dir>/receipt.json, sha256, directory: <dir>, spec}` in a draft's `config_inputs`, and by copying and hashing `<dir>/receipt.json` in `review-package` — where `spec` is the installed parts' `PLATE_RECEIPT_SPEC` and the receipt must declare it; the receipt binds the plate's unreferenced sibling images, which create does not copy, hash or re-verify (any sibling explicitly declared as its own config input, such as `assemble.occluders[i].image`, is copied and hashed as that independent input).
+
+The version's `review_package` field records `config` (`path`, `sha256`),
+`from` (the declared build directory), `files` (sorted package-relative
+`{path, sha256}` entries, including the copied config), and `open`:
+
+```json
+{"open":"rig-review open 'derived/review/v1/out'"}
+```
+
+Run that open command from the project directory. Review recognizes `out/`
+as a build root, opens its `check/` package and discovers the config beside
+the build root. The installed review package documents this discovery under
+*Producer handoff* in `docs/REVIEW_PACKAGE.md`. Its handoff hash identifies
+the exact copied config. The hash check binds the copies to this version's
+recorded input snapshot. The producer baseline in review determines whether
+those inputs reproduce the inspected rig.
+
+`interview --check` warns with the package command when a rig version has no
+recorded package or when a recorded package is absent after a fresh clone.
+A present package must match the complete recorded file list and hashes.
+Regenerate a missing package from its recorded sources. If an existing
+package differs, the writer refuses replacement so the frozen copy can be
+inspected. A new build shown to the user gets a new version and package.
+Post versions go to direction review, outside this package contract.
+Pre-interview versions retain their existing history and output checks and
+are exempt from review-package warnings.
+
+The filled example ships synthetic producer bytes under
+`templates/example-review/`. Its two `review_package` records are generated
+by `bun scripts/generate-example-review.ts <fresh scratch project>`. Add
+`--check` to verify that generation reproduces the shipped record bytes.
+The script runs the public `review-package` command for both rig versions.
+`reviewExampleFiles()` in `tests/review-fixture.ts` maps those bytes to the
+declared sources and package destinations, and both example fixture helpers
+materialize them. The regression test generates two fresh projects and
+compares every record and file byte before checking the filled example with
+zero refusals and zero warnings.
+
+Apply results return in review feedback as `feedback[].context.applied`.
+Keep the JSON written by `rig-review feedback` in the project and record one
+applied round on the next version as `review_origin`:
+
+```json
+{
+  "feedback": { "path": "evidence/review-feedback.json", "sha256": "<file SHA-256>" },
+  "source_version": 1,
+  "feedback_id": "<feedback item id>",
+  "applied": { "schema": "rig-review-applied/1", "...": "complete context.applied object" }
+}
+```
+
+The containing version is the next-version link. `source_version` names the
+immediately preceding version of the same kind. Copy the selected item's
+complete non-null `context.applied` into `applied`, preserving every field.
+A build made without feedback records `review_origin: null`, including the
+filled example. This declaration is independent of human `answers_feedback`.
+
+The check binds the feedback's bytes, selected item and applied result to the
+source package's config, handoff files and inspected compiled model. In the
+released folder adapter, `reviewedSource.rig` identifies that compiled model
+and `motion` is null; producer rig and motion hashes live in `handoff.files`.
+The retained feedback is a single-build `rig-review-session/1` export.
+Record the resulting version's outputs, hashes and provenance and write its
+review package as usual. This chain records the applied result and the next
+build's declared origin. Create does not execute the Apply or build.
+
+A missing declaration on a version dated before
+`APPLIED_REVIEW_SINCE = 2026-11-06T00:00:00Z`, or without a readable date,
+warns to preserve in-flight history. From that boundary it is refused.
+Pre-interview versions retain their historical contract.
+
+## Per-ask guide coverage
+
+Rig waypoint guides carry `asks: [{ "id": "tracks", "state": "user" },
+{ "id": "extent", "state": "delegated" }, …]`, naming each applicable ask
+in `src/waypoints.ts`. A user entry points to the guide's existing `verbatim`
+and `value`; it is a recorded interpretation, not automatic proof that prose
+answers a question. A delegated entry records an explicit hand-off in those
+words and uses the guide's `agent_decision`. Its free-text `covers` still names
+the delegated remainder; its `value` and `reasoning` are written before approval.
+Whole-guide delegations list every ask as delegated. Not-applicable waypoints
+need no coverage. `states` and `transitions` apply only to `fullscreen.game_logic`; `tracks`
+and `blink` apply to other rig types. Post items are outside this contract.
+
+The independent `ASK_COVERAGE_SINCE = 2026-11-05T00:00:00Z` boundary reads the
+resolved guide's own `at`, including inherited guides. An older or undated guide
+with no `asks` is warned about, preserving its exit code. An explicitly recorded
+list is checked regardless of age. Missing, unknown, duplicate or invalid entries
+must be fixed; free-text `agent_decision.covers` alone is not per-ask coverage.
+
+
+## Explicit adoption of the split interview
+
+`interview.order: { "spec": "rig-create/stage-order@1", "adopted_at": "<clock ISO date>" }`
+is the only order switch. A date does not establish which contract was used.
+`init` writes this metadata. An old record keeps its old checks and gets one
+`STAGE_ORDER_LEGACY` warning: its old rig guides are historical answers, never
+certification that they were asked after parts. No signature, checkpoint hash
+or old version is rewritten. To adopt, preserve the old rig guides whole in
+that question's `history[]`, ask fresh answers against accepted parts, re-sign
+`interview` after adopting to approve the changed interview, and record the first
+human `signoff rigging-interview`. That writer records adoption
+and the live parts/structure context. Stage movement remains a separate human
+act, as for existing forward sign-offs. The filled legacy example is frozen in
+`templates/legacy-example-project.json`. Read under the current 2.16.0 pin it warns with that order warning plus
+`QUESTION_SET_STALE`, because its frozen question set remains at 2.14.1, and it is refused by the build-identity gate
+(`REVIEW_PACKAGE_CONFIG_MISMATCH` and `REVIEW_PACKAGE_PARTS_MISMATCH` on v1 and v2, plus
+`REVIEW_PACKAGE_PART_FILE_MISMATCH` for each of three approved part images missing per version), because its versions, dated after
+`BUILD_IDENTITY_SINCE`, claim configs and parts their review packages do not carry. Its rig-review and direction-review signatures also postdate `SIGNOFF_TARGET_SINCE` and lack targets, so each refuses `SIGNOFF_TARGET_MISSING`. Its interview, two plan-approved and post-interview signatures also lack answer bindings and each refuses `SIGNOFF_ANSWERS_MISSING`. Its bytes stay frozen.
+The new `example-project.json` is a synthetic new-order narrative at 0/0.
+
+Framing and source (`seethrough`, `assemble`) are the first interview. A
+`plan-approved` signature covers only those parts steps in new-order records.
+The later `rigging-interview` covers `bones`, `meshes`, `constraints`, `motion`.
+Keep `phase: "rig"`; approval is resolved by step, not phase alone. Legacy
+`plan-approved` retains its old all-rig-step coverage. Post approval is unchanged.
+`plan.drafted_at` dates the parts plan; `plan.rigging_drafted_at` dates the later
+rigging plan, so drafting it does not invalidate the earlier parts signature.
+Each plan signature hashes only its covered steps. `--steps` cannot cross
+approval ownership. Pending later steps/answers may remain unfilled before their
+interview; production execution still requires its proper human approval.
+
+The hand pass is the correction loop of `rig-review`, including rig and
+animation inspection, described corrections and direct edits. It adds no stage
+or acceptance authority. Existing `review_origin`/applied-review chains retain
+producer feedback; `review_origin: null` remains legal for a first rig. A
+separate choice-answer schema and correction-path union are subsequent cards.
+
+## Labelled draft rigs and structure decisions
+
+After assemble, `parts`/`parts-review` may use a proposed draft to inspect meshes
+and refine chest structure before asking the production rigging plan. The
+draft's proposed bones and weights are not the person's rigging answers.
+
+```sh
+rig-create draft-rig <id> [<dir>] --config <path> --from <output dir> [--parts <dir>] [--json]
+rig-create structure-snapshot [<dir>] --draft <id> --verdict <path> --out <path>
+rig-create signoff parts-review --by <who> --evidence <path> --diff-report <path> --component '<id>=<status>:<why>' --draft <id> --structure-file <path> --verbatim-file <file>
+```
+
+The recorder reads existing output; it runs no producer or review command.
+It appends `drafts[]` with `{ id, kind: "draft-rig", at, producer: {name,version},
+config: {path,sha256}, parts: {path,files:[{path,sha256}]}, files:[{path,sha256}] }`.
+`parts.files` binds `parts.json`, `parts/*` and the raster `parts.json` itself
+declares under `painting_in_rig`; an undeclared file is not bound, and a draft
+recorded before the declared raster was bound warns `DRAFT_DECLARED_FILE_UNBOUND`.
+`producer` is the `package` of the `rig-run/1` `run.json` parts writes beside
+`rig.json` (`<out>/run.json`, or `<root>/rig/run.json` in a build root), which
+`files` already binds; a malformed or other-spec stamp refuses under its
+`RUN_RECORD_*` code. Without one, `producer` is the installed `@rig-c/parts` and
+the check warns `DRAFT_PRODUCER_ASSUMED`; a recorded producer that disagrees with
+its bound stamp warns `DRAFT_PRODUCER_MISMATCH`.
+All files must resolve under `derived/drafts/<id>/`. Standalone `rig --out`
+requires explicit `--parts`; only an unambiguous build root containing
+`parts.json`, `parts/` and `rig/` supplies those inputs implicitly. Ambiguous
+layouts refuse, and new registrations require exactly one stack candidate at
+`D/recomposite_rig.png` or, when the recorded parts directory D is named `rig`,
+`D/../render/recomposite_rig.png`; missing or ambiguous candidates refuse with
+`DRAFT_RIG_STACK`, remedied by re-running `rig-parts build` into the draft output
+or keeping assemble's `render/` beside `rig/`. Symlinks out of the root and changes to present recorded input bytes refuse.
+Absent ignored draft files warn as `DRAFT_RIG_UNAVAILABLE`, including after a
+clone; they do not invalidate an accepted record. Present files still verify
+even when another file is absent.
+These are **create-owned artifact identities**. The config/output association
+is a declaration, not measured reproducibility or producer provenance. There
+is no retained producer handoff file here: review constructs its own live
+handoff when it opens the draft.
+
+Drafts allocate no production version number. A declared draft, reserved draft
+path or registered draft artifact cannot be reviewed, packaged or handed off
+as a `versions[]` rig. A separately authorised production build gets its own
+output root and numbered version. This checks declared artifact identity;
+it does not claim to recognise untracked byte copies after their identity is
+stripped. Identical model hashes alone are not blacklisted.
+
+`--structure-file` retains a declaration snapshot approved by the human parts
+sign-off, not a fabricated review export. `structure-snapshot` writes it:
+
+```json
+{
+  "schema": "rig-create/structure-decisions@0",
+  "draft_id": "sample",
+  "config": { "path": "derived/drafts/sample/config.json", "sha256": "<config hash>" },
+  "entries": [ { "path": "/meshes/torso", "value": { "contour": { "regions": [] } } } ]
+}
+```
+
+Each entry is the complete exact `meshes.<part>` declaration, including
+`contour.bust` or `contour.regions` where present. Paths use JSON Pointer
+escaping. Explicit `entries: []` is legal when no declarations are carried.
+
+A production config may differ from this snapshot only when a live (not
+reopened) `rigging-interview` sign-off with `checkpoint: null` follows that
+parts-review sign-off, and `interview.waypoints[meshes].guide.at` is strictly
+after parts-review and no later than the rigging-interview sign-off. The
+interview approval must already exist at the version's build time. Otherwise,
+answer the rigging meshes guide, or renew parts-review.
+
+`rig-version` computes `versions[n].provenance.structure_delta` from the
+retained snapshot and config: an ordered list of `{entry, snapshot, version}`,
+where `entry` is the snapshot JSON Pointer and the other fields are complete
+declarations (`version: null` means absent). It omits the field when unchanged.
+The check recomputes it and refuses `STRUCTURE_DELTA_MISMATCH` on disagreement.
+`interview --check` and `next` WARN `STRUCTURE_DELTA_REVIEW` with the entry count;
+the rig-review verdict and sign-off cover changed structure. No producer
+measurement or new review act is introduced.
+
+
+The parts verdict names no per-declaration approval: an approved verdict
+approves the reviewed draft. So `structure-snapshot` copies `draft_id` and the
+draft's own `config: {path, sha256}` binding, and writes one entry per key of
+that config's `meshes`, in the config's key order, each value copied exactly.
+A config without `meshes` gives `entries: []`. It computes no mesh. It reads
+`--verdict` with the parts-review sign-off's own reader, so a verdict that is
+not approved refuses `PARTS_VERDICT_NOT_APPROVED`, and a changes-requested
+review gives no snapshot. The verdict must also review that draft's parts: both
+writers and the check match its `source.files[]` against the draft's
+`parts.files[]` and `files[]` by sha256, never by path, leaving out only the
+declared `painting_in_rig` raster. Every verdict file must be one of the
+draft's, and every `parts.files[]` entry must be in the verdict; any other
+difference is refused as `PARTS_VERDICT_DRAFT_MISMATCH`. A parts view that
+shows meshes also lists `rig.json`, `mesh_report.json` and the mesh rasters,
+which the draft binds in `files[]`; an output the verdict does not list is not
+missing, since a parts-only view lists none. It refuses an unknown draft
+(`STRUCTURE_SNAPSHOT_DRAFT_UNKNOWN`), a draft config whose bytes changed since
+the draft was recorded (`STRUCTURE_SNAPSHOT_CONFIG_CHANGED`), and an `--out`
+that is not a literal project path (`STRUCTURE_SNAPSHOT_OUT_INVALID`), is under
+an ignored root (`STRUCTURE_SNAPSHOT_OUT_IGNORED`) or already holds different
+bytes (`STRUCTURE_SNAPSHOT_OUT_EXISTS`). The candidate is validated with the
+rules the check applies to a signed snapshot before any byte is written, and a
+refusal leaves no new or changed file. An `--out` that already holds the same
+bytes is left as it is and the command succeeds. It writes only `--out`, never
+`project.json`; `signoff parts-review --draft <id> --structure-file <path>`
+then binds the file.
+The snapshot must live outside ignored roots, such as `evidence/`; the writer
+refuses paths or aliases into ignored storage. The writer hashes the retained
+file and checks its config/declaration identity when the draft config is
+available. A clone still checks the snapshot hash/schema and its recorded
+config identity, without requiring absent regenerable draft artifacts. It
+stores `draft_id` and `structure:{path,sha256}` on the parts-review sign-off.
+It does not apply patches or measure geometry. The later interview reads this
+human-approved snapshot instead of re-asking its structure as a guess.
+`signoff rigging-interview` resolves its `accepted_parts:{signoff_at,evidence}`
+and `structure` from the live human parts review and stores a shared
+`interview.rigging_context`, outside the answer union. Fresh rig guides must
+follow that approval and precede their rigging signature. Contradictory retained
+production config declarations require renewed approval rather than a silent
+override. Each production version uses the latest structure approval live at
+its build date, with reopen supersession evaluated at that same date; a later
+approval does not impose its declarations on old versions. Both new-order writers validate the full candidate before writing.
+
+Mesh sign-off UI evidence from review#365 is optional in this contract, not a
+shipped-capability claim or mandatory gate. Review/producer owners validate the
+actual editors and mesh rendering. Create's synthetic tests prove record
+binding and refusals, not the physical correctness of a chest rebuild.
+
+The synthetic new-order record and draft declaration files reproduce with
+`bun scripts/generate-example-order.ts <fresh scratch dir> --check`. The frozen
+legacy record is byte-preserved; generated evidence is never hand-written.
+
+The [synthetic bound chain](../templates/example-chain/README.md) carries one
+project from its labelled draft and approved parts through a packaged rig,
+rig-review, signed post interview, authored direction and direction-review.
+`bun scripts/generate-example-chain.ts <fresh scratch dir> --check` reproduces
+it. The public writers record signoffs, rig/post review verdicts, the review
+package, immutable input inventory and authored direction. The parts verdict
+is a synthetic review-tool export from `tests/parts-package.ts`, recorded as a producer step.
+`chain.json` names seed declarations covering forward stage movement,
+`plan.steps (setup and status progress)` with `split.parts`, the rig-version
+declaration. Its source inventory is written by `input add`. Each seed
+declares its consuming command and records that command's step index. Status progress is forward-only,
+and signed plan fields stay bound. Post steps are added after rig-review,
+before the post-interview options.
+The direction binds that package's compiled model, built from the approved
+parts. Its comparison report records the identical painting and assembly.
+The retained setup still is the assembly recomposite. Rendered motion and
+camera behaviour require separate producer validation.
+
+## Correction paths: described and made
+
+A correction lives in project-level `corrections[]`, including at `parts-review`
+before a production version exists. Adopt explicitly with `correction --adopt`;
+this writes `corrections_contract: {schema: "rig-create/corrections@1", adopted_at}`.
+No stage or interview-order schema changes. New projects and the filled example
+adopt it with an empty list. Older records get `CORRECTION_PATH_LEGACY` without
+inventing corrections, rewriting dates, or changing their existing origins.
+
+Every record has `schema: "rig-create/correction@1"` (or `@2` for authored
+direction descriptions and made direction patches), `id`, `path`, `by`, `at`,
+`verbatim`, optional text `source`, `stage`, `on`, `artifact`, `outcome` and
+`resolves`. `path` is `described` or `made`. The stage is `parts-review`,
+`rig-review` or `direction-review`. `on` is the source identity; `outcome:null`
+means open. A closure sets outcome once and adds `closure:{by:"agent",at,reasoning}`
+with create's clock. That note is an agent declaration, never a human quote or
+acceptance. `resolves:null` or an earlier correction id records an append-only
+replacement; the predecessor remains history and is discharged only by a
+completed valid replacement.
+
+- `described` uses `artifact:{kind:"description"}` and unchanged human words.
+- A made preview uses `artifact:{kind:"config-patch",patch:{path,sha256},
+  state:"preview/pending",feedback:null}`. Its raw file hash is its own identity;
+  it makes no claim about review's `patchSha256`.
+- A made session uses `artifact:{kind:"config-patch",state:"preview/pending",
+  feedback:{file:{path,sha256},item_id}}`. The patch is the selected session
+  item's `context.applied.patch`. With a bound result and passing producer
+  summary, closure changes state to `applied-and-checked`. An optional retained
+  preview `patch` must be parsed-deep-equal to the embedded patch. Create retains
+  `applied.patchSha256` as review's claim and never recomputes it.
+- Other made operations use `{kind:"unsupported",operation,reason,files,
+  producer_schema}`. `operation` is `mesh-delta`, `retarget`, `keyed-animation`
+  or `other`. For example, `rig-review-applied/3` is a mesh delta, not a config
+  patch. Its opaque producer evidence is retained; completion stays pending.
+
+The pinned patch is exactly `rig-review-config-patch/1` with the five keys
+`schema`, `config_sha256`, `ops`, `producer:{name,version}`, `op:{cmd,args}`.
+`ops` contains 1–256 add/replace `{op,path,value,name?}` or remove `{op,path,name?}`
+operations, with nonempty RFC 6901 pointers and the published non-path flag
+allowlist. The session is `rig-review-session/1`, the checked patch Apply is
+`rig-review-applied/2` and its summary is `rig-review-check-summary/1`. Source
+config, inspected model and handoff input hashes bind to the source. Summary
+`pass:true`, `exitCode:0`, `gate:true`, a nonempty line and at least one `PASS`
+bar are required. A named `FAIL` or a status outside parts 2.16.0's
+`PASS | FAIL | SKIP | WARN | CLEAR | REPORTED | UNCLASSIFIED` set refuses.
+A bar named skipped by the producer line cannot be `PASS` in the map.
+Report-only SKIPs may be absent from that line. All accepted statuses remain
+verbatim by name. Resolution reasoning and text output state the PASS count,
+every non-PASS name/status and the retained producer line. The
+outcome's retained compiled-model SHA must equal `applied.modelHash`. A built
+preview or unknown/failed check cannot claim checked completion. Optional
+published route/files/environment context is retained. Optional `stageInputHash`
+must be a 64-lowercase-hex SHA-256, accepted as recorded; create cannot re-derive it from the package.
+Summary `source` may be absent or `remesh`, `retune`, or `check`, under the same producer-summary gates. No patch application,
+producer measurement, build or diff is recomputed by create.
+
+@1 identities are `{kind:"rig"|"post",n,config:{path,sha256},model:{path,sha256}}`,
+`{kind:"parts",manifest:{path,sha256},files:[{path,sha256}]}`, or
+`{kind:"draft",id,config,parts,model}` (parts is `{manifest,files}`).
+A rig binds to its version's provenance config and frozen review package model.
+An @1 post binds config to `provenance.config`, and model to one declared retained
+output explicitly selected by `--model-file`; it is output identity only,
+without a parts, rig or CG claim. `config-patch/1` is rig/draft-only: a direct
+post edit is unsupported. A described post closure requires changed output bytes
+under @1, or a different bound direction document hash under @2.
+Parts identities retain a complete sorted parts.json + parts/ file inventory.
+Draft identities match the labelled draft inventory, including a retained
+compiled model when that reviewed identity is selected. Missing regenerable
+files never count as correction completion: retain source and result bytes.
+Paths must be literal project-relative regular files without symlink traversal;
+patch/session evidence belongs in tracked evidence. Outputs and draft files
+must survive handoff/clone when used to close a correction.
+
+An ordinary correction may name the historical version actually inspected.
+An explicit `resolves` replacement must name the latest source at its capture
+time; a future source timestamp always refuses.
+
+A result must be distinct, later and changed. Version and draft times bind the
+ordering; for raw parts, create's later closure records the declared response
+and changed inventory without inventing a producer timestamp. A rig-version
+made result retains the existing matching `review_origin` chain, including its
+immediate-predecessor constraint. A first rig may still have `review_origin:null`;
+no fake preceding rig is made for stage-1 corrections. `on_items` still names
+interview answers and `answers_feedback` still links verdicts; neither is an
+operation inventory. A correction does not supply a missing guide citation.
+
+```sh
+rig-create correction --adopt <dir>
+rig-create correction record <dir> --id refine --path described --stage rig-review \
+  --version 1 --by reviewer --verbatim-file words.txt
+rig-create correction record <dir> --id tune --path made --stage rig-review \
+  --version 1 --by user --patch-file evidence/patch.json --verbatim-file words.txt
+rig-create correction record <dir> --id applied --path made --stage rig-review \
+  --version 1 --by user --feedback-file evidence/session.json --item change-1
+rig-create correction resolve tune <dir> --version 2 --by agent --reasoning-file reasoning.txt \
+  --applied-feedback evidence/session.json --feedback-id change-1
+```
+
+Use `--draft <id>` or `--parts-file <retained parts identity JSON>` instead of
+`--version`; post versions require `--model-file`. `--resolves <id>` appends a
+replacement. A made record requires `--by user`; its clock is create's ingest
+time. A session item supplies its exact summary as verbatim, otherwise use
+`--verbatim-file`. Review does not invoke create or write project.json. There
+is no new review correction-export schema and no `--correction-file`.
+Record, resolve and check share validation; writes use a same-directory temporary
+file and atomic rename. Refusals leave project.json byte-identical. Unrelated
+pre-existing interview holes do not prevent capture, but a writer cannot add a
+new refusal or bypass correction validation.
+
+Stage-1 corrections use parts/drafts outside versions. The parts-review signoff
+must approve the corrected draft and structure snapshot (or a draft using the
+corrected parts inventory). Production versions still compare mesh declarations
+to that snapshot. Structure changes after approval require the existing reopen
+and fresh snapshot, never a correction override.
+
+A valid reopen supersedes the same stage suffix as signoffs: entries at or
+before its epoch remain history. A narrower later reopen cannot resurrect an
+earlier suffix. Recording under a live scoped approval requires reopening first;
+corrections do not move stages or sign plan steps themselves.
+
+| State | check | approval / handoff | reopen | provenance | structure | CG |
+| --- | --- | --- | --- | --- | --- | --- |
+| described-open | pending/WARN | pending; attempted approval refuses | pass history | pending response, no citation authority | pass existing checks | pass existing checks |
+| described-linked | pass declared linkage | pass correction gate only | pass history | pass linkage, citations still required | pass if snapshot matches, else refuse | pass if ordinary gates pass, else refuse |
+| made preview/pending | pending/WARN | pending; attempted approval refuses | pass history | pending | pass current snapshot only | pass current config only |
+| made applied-and-checked | pass exact result binding | pass correction gate only | pass history | pass linkage, not a replacement citation | pass if snapshot matches | pass if ordinary gates pass |
+| invalid checked claim | refuse | refuse | no authority | refuse claimed linkage | mismatch refuses | no fabricated gate pass |
+| unsupported | pending/WARN | pending; attempted approval refuses | pass history | pending opaque evidence | pass existing checks | pass existing checks |
+| stage-1 parts/draft overlay | pass retained identity; absent closure bytes refuse | pending until corrected draft/parts is approved | parts-review suffix | identity only | pass approved corrected snapshot | pass / not applicable to parts |
+| rig-version overlay | pass source/result hashes | pending until correction and normal review complete | rig-review suffix | existing citations required | existing snapshot comparison | normal gates required |
+| direction-review post overlay | pass retained declared output | pending until changed output and normal review complete | direction-review suffix | post citations still required | no new rig claim | no new CG claim |
+| validly superseded overlay | pass history validation | pass exclusion from current obligations | pass only for valid human reopen | historical only | historical context | existing historical gates remain |
+
+The overlays combine with path state; refuse overrides pending, which overrides
+pass. A pass never waives existing gates or manufactures acceptance.
+
+The small consumer fixture is `tests/fixtures/correction-path/`, generated through
+writers by `scripts/generate-correction-fixture.ts <fresh dir> [--check]` before
+full-example integration. Its checked positive is explicitly **synthetic
+shape-only**, not a measured producer-gate result; see its README. Every retained
+file uses its real byte hash. The frozen legacy example's exact warning set is
+`QUESTION_SET_STALE`, `STAGE_ORDER_LEGACY`, `CHOICE_ANSWERS_LEGACY`,
+`CORRECTION_PATH_LEGACY`, and it is refused by the build-identity gate and by
+`SIGNOFF_TARGET_MISSING` twice and `SIGNOFF_ANSWERS_MISSING` four times as described above; the current filled example stays at 0/0.
+
+### Masked part-image repaints
+
+When `assemble` levers are exhausted and one part image needs a bounded hand pass
+before `parts rig`, record the edit as a `made` correction at `parts-review` on
+the parent draft before registering the rebuilt draft:
+
+```sh
+rig-create correction record <dir> --id repaint-topwear --path made --stage parts-review \
+  --draft <parent-id> --part topwear --part-image-file evidence/topwear-after.png \
+  --mask-file evidence/topwear-mask.png --tool "gemini-image-probe r5 + mask composite with tone match"
+```
+
+The record carries `by: "agent"`, `verbatim: null`, and
+`artifact: { kind: "part-image", draft, part, before, after, mask, tool }`, where
+`before`, `after` and `mask` are `{ path, sha256 }` bindings and `tool` is free
+text naming the lever used. Its `on` (and an explicit `outcome`) is the draft
+identity `{ kind: "draft", id, config, parts, model: null }`: a part-image edit
+changes one part file, so it binds the draft's parts manifest and parts files and
+no compiled model, and the parent draft may be one recorded from a standalone
+`parts rig` output with no `skeleton.model.json`. Whether a later draft changed
+is read from its parts inventory. A part-image record that bound a model is
+still read, and its model must match the draft. Other draft corrections (`described`, a config
+patch Apply) still bind the draft's one retained compiled model. Both the writer and `check` decode the PNGs and
+refuse when `before` is not the parent draft's bound `<parts.path>/parts/<part>.png`
+or `after` makes no change (`CORRECTION_PART_IMAGE_BEFORE`), when `mask` or
+`after` dimensions differ from `before` (`CORRECTION_PART_IMAGE_MASK_SIZE`), when
+`after` differs from `before` outside `mask` (`CORRECTION_PART_IMAGE_OUTSIDE_MASK`),
+or when `after` increases alpha at any pixel (`CORRECTION_PART_IMAGE_ADDED_ALPHA`).
+A later `draft-rig` (new id) whose bound `<parts.path>/parts/<part>.png` matches
+`after.sha256` resolves the correction automatically (or explicitly via
+`correction resolve --draft <new-id> --by agent --reasoning-file <file>`). A draft
+whose bound `parts/<part>.png` matches a `part-image` correction's `after.sha256`
+whose correction is withdrawn, superseded, dated after the draft, or on another
+part/draft refuses as `DRAFT_PART_REPAINT_UNRECORDED`.
+
+### Authored camera direction (create#92)
+
+Create owns the authored camera and timing document, not depth or `config.turn`.
+Review previews through the published `@rig-c/play` runtime (review README,
+*delivery flow*); create renders nothing. A document is authored data, not proof
+of a rendered take, seamless looping, source-animation extent, or a parts gate.
+
+Adopt with `rig-create direction --adopt <dir>`. It writes
+`direction_contract:{schema:"rig-create/direction-contract@1",adopted_at,
+grandfathered_posts}`. The sorted, unique post numbers are existing posts at
+adoption. They remain exempt from a missing direction document; explicit
+bindings are always checked. There is no date switch and no new legacy warning.
+Do not change that list to exempt new work. Existing correction@1 records are
+not migrated or rewritten.
+
+```sh
+rig-create direction write 5 <dir> --file evidence/authored-direction.json --rig 2
+rig-create direction check 5 <dir> --json
+```
+
+The writer registers a new post version and never overwrites a previous one.
+The exact input bytes become `evidence/direction/v5.json`, schema
+`rig-create/direction@1`. `provenance.config`, `provenance.direction`, and one
+`outputs[]` entry all bind that same `{path,sha256}`. It is a direction output,
+not a compiled model or movie. `provenance.sections.camera` and `.timing` carry
+the same citations as the document. Metadata, rig bindings and citations are
+not additional executable config sections. Setup-painting requirements apply
+to existing build configs as before, not to this camera document.
+
+The closed document has precisely:
+
+| Field | Closed contents |
+| --- | --- |
+| `schema` | `rig-create/direction@1` |
+| `rig` | `{version,model:{path,sha256}}`; accepted rig's review-package compiled model, never config-only identity |
+| `take` | `{duration,loop}`; positive finite seconds and boolean |
+| `camera` | `{space:"rig-world-y-up",keys:[{time,box:{x,y,width,height},easing}]}` |
+| `timing` | `{keys:[{time,source_time,easing}]}` |
+| `citations` | `{camera,timing}`; each `{guide,asks,quote}` or `{guide,asks,delegated:true}` |
+
+The model path is
+`derived/review/v<R>/out/check/build/skeleton.model.json`; its exact bytes must
+match the corresponding review-package inventory SHA. A new write needs the
+latest live accepted rig and existing handoff still/signature gates. Missing
+model bytes refuse; create never regenerates them. A post's `rig_version` must
+match `rig.version`. Historical documents may retain their historical rig;
+current authoring and direction approval cannot use a superseded rig.
+
+Boxes describe the visible rectangle in rig world coordinates, Y up. Coordinates
+are finite and sizes positive. A preview contains the box at its aspect ratio
+(letterbox; do not silently crop). Camera keys number 1–256, start at zero,
+strictly increase and stay in `[0,duration]`; the final box holds through the
+end. Timing keys number 2–256, start at zero and end at `duration`; their take
+times strictly increase, while finite nonnegative `source_time` is nondecreasing
+and permits holds. It maps take seconds to source-animation seconds, without
+FPS inference or a source-clip-duration claim. `loop` repeats the take clock.
+
+Easing is exactly `linear`, `hold`, or `smoothstep`, attached to the segment
+starting at the key. `smoothstep(u)=u*u*(3-2*u)` with normalized segment time;
+interpolate box components/source time with that factor. The final key's easing
+has no effect. No arbitrary easing, pan/zoom alternative, audio, depth, tilt,
+turn, frame-index inference or extension fields exist in @1.
+
+Citations name the actual questions `camera_depth` and `post_timing`, each with
+`asks:[guide]`. `camera` and `timing` are executable plan step ids, not question
+ids. Quotes are exact stored verbatim/additions fragments, including historical
+or inherited answers; delegation uses the existing decided-delegation rules.
+A new write additionally requires a live post-interview approval covering both
+steps with matching `step_hashes`, and resolved current per-ask selections.
+Pending auto/Other responses cannot produce a document. A camera marked not
+applicable can supply a single fixed-box key only when its retained verbatim
+is cited and the approved post plan still supplies camera/timing; timing must
+be applicable. All-post-not-applicable skips post entirely. Prose is never
+parsed into authored key values.
+
+Writers validate the prospective record and every owned finding before writing,
+retain unrelated pre-existing holes by code/path multiset, and reject concurrent
+source changes. Documents are immutable; `project.json` is the commit point.
+A lock, staged files, snapshot rechecks and rollback protect a failed publish.
+This is not an atomic multi-file filesystem transaction. A refused write leaves
+the record and previously published artifacts byte-identical. Source documents
+and patches are literal retained POSIX paths below the selected project, without
+symlinks, traversal or ignored roots. Only the explicitly bound compiled-model
+path above is allowed in regenerable `derived/`. Clone it when using this gate.
+The scene's idle frames are the one path admitted under `outputs/`: a post on
+rig `vN` reads `outputs/vN/idle/frames.json` only with the path and sha256 of
+`versions[vN].registration.idle`, and any other file under `outputs/vN/idle/`
+only with a `versions[vN].outputs` binding. The bytes stay where `rig-version`
+froze them; no second copy is retained. Present bytes are verified on every
+write and check. Absent bytes refuse, as the registration check refuses absent
+frozen outputs, so restore `outputs/vN/` before writing or checking the post.
+
+### Review reads; create ingests direction patches
+
+Review receives a user-designated project root and post number `N`. It reads
+that version's `provenance.direction`, then exactly
+`evidence/direction/v<N>.json` as `rig-create/direction@1`, validating raw SHA,
+version/path binding and rig model SHA. `readDirection(dir,project,N)` is the
+create reader; `direction check N --json` exposes a checked read. Review never
+writes `project.json` or invokes create. Review 1.6.0 has no authored camera
+consumer; review#373 consumes this contract after it lands. No camera Apply
+capability is claimed for that installation.
+
+This is a planned contract. No review version produces it today: the direction
+producer is review#373, which is parked, and its result will arrive as a job act
+(create#271). The planned patch is a closed `rig-review-direction-patch/1` with exactly
+`{schema,source_post,rig_model_sha256,direction_sha256,replace}`. `replace` holds
+one or more of `camera`, `timing`, `take`, replacing whole typed sections only.
+The source is the current post, and both base hashes must match. Unknown keys,
+arbitrary pointers and a semantic no-op refuse. Binding/citation changes need
+new answer/authoring work, not a patch. The patch's own identity is the raw hash
+of its retained bytes, not a review canonicalization claim.
+
+```sh
+rig-create correction record <dir> --id framing --path made --stage direction-review \
+  --version 5 --direction-patch-file evidence/direction-patch.json \
+  --by user --verbatim-file correction-words.txt
+rig-create direction patch 6 <dir> --patch-file evidence/direction-patch.json
+rig-create correction resolve framing <dir> --version 6 --by agent \
+  --reasoning-file resolution.txt
+```
+
+The patch writer creates a later immutable document/post and records
+`direction_origin:{source_post,patch:{path,sha256},result:{path,sha256}}` on the
+version. Capture retains the human words separately; no words are invented from
+the patch. Review may label export plus create ingestion “Apply”, but cannot
+claim ingestion or checked completion itself. `rig-review-applied/2` is never
+used as a direction result or proof.
+
+Authored-direction descriptions and `direction-patch` use
+`rig-create/correction@2`. Other correction records remain
+`rig-create/correction@1`, with existing config-patch and unsupported behavior.
+The made patch artifact is
+`{kind:"direction-patch",patch:{path,sha256},state:"preview/pending"|
+"applied-and-checked",result:null|{path,sha256}}`. Its exact post source/outcome
+identity is `{kind:"post",n,config,model,direction:{path,sha256}}`; config binds
+the direction file, model binds the source rig's compiled model, and direction
+matches `provenance.direction`. This identity is not accepted by @1.
+
+A pending record has no outcome/result and cannot approve. On agent resolution,
+create checks its own patch/base/result and `direction_origin`, not an external
+producer report. The outcome is a later post on exactly the same rig model,
+with changed direction bytes and the typed replacements actually present.
+Same-document, cross-kind, changed-rig or unrelated authored output pairs
+refuse for made patches.
+
+A described request at direction-review on a post with authored direction
+also binds this exact identity, using `artifact:{kind:"description"}`. Record it
+with `--version`; an optional `--model-file` must name the source rig's compiled
+model. Selecting the direction JSON as model refuses before writing. Resolve
+it to a later authored post with a different bound direction document hash
+through `correction resolve --version`. This includes a later accepted rig
+because direction@1 embeds `rig.model`. The agent's closure reasoning carries
+the semantic claim that the request was met. No patch or `direction_origin`
+is required for a described request. Both source and outcome use
+`validateDirectionIdentity`. An existing @1 description cannot resolve with
+the direction document named as model. Capture a new @2 described record to
+close that legacy request.
+
+`DESCRIBED_DIRECTION_SINCE = 2026-11-06T00:00:00Z` dates existing @1 authored
+direction descriptions by their original `at`. Earlier records receive
+`DESCRIBED_DIRECTION_LEGACY`; contemporary records receive
+`DESCRIBED_DIRECTION_REQUIRED`. Preserve history and capture the next request
+through the writer. Posts without authored `provenance.direction` keep their
+existing @1 declared-output identity. Rig, draft and parts identities are
+unchanged. Unsupported operations remain pending.
+
+`checkProject`, direction signoff and the acceptance writer all check the
+relevant document. Handoff stays rig-only to bootstrap authoring. Review-package
+stays rig-only and cannot rebind a model already cited by a direction document.
+Reopen rules, historical evidence, human signoff and agent closure remain
+separate gates.
+
+The generated geometric example is `templates/example-direction/`, including a
+small staged project, exact input/result documents, a review-format patch and
+@2 correction. It uses invented sentences shaped like a pilot interview, not
+pilot words or assets. Reproduce with
+`bun scripts/generate-direction-fixture.ts <fresh-dir> --check`. It demonstrates
+writer/contract behavior with a real installed `rigc build` of a public rectangle
+probe. Its compiled local yaw slider is readable by review's `discoverTurnDials`
+(`src/turn-pad.ts`, revision `c3e571db1878093b183c282b56f5eb846c1d742b`),
+using core 3.2.1's `RigSliderConstraint` (`src/rig.ts`). The compiled model has
+no authored camera capability; camera requests in the direction documents are
+unsupported playback requests, not evidence of camera rendering or Apply.
+The installed core-only build reports `A00_ROUNDTRIP_PARSE` as SKIP; this is
+not a spine-core round-trip or a rendered-take claim. Recompute every recorded
+file hash with `bun scripts/check-direction-fixture-hashes.ts`; entries of a
+producer run stamp (`rigc-run/1`, `rig-run/1`) resolve against the stamp's own
+directory.
+The main filled project remains the separate zero-refusal/zero-warning example.
+
+## Advisory intake reports
+
+`project.intake` is optional (`spec: "rig-create/intake@1"`). In `parts`, after
+a full run exists, retain the parts `head-crop-preflight` JSON and record it:
+
+```sh
+rig-create intake-report . --id crop-1 --report evidence/preflight.json --sha256 <raw-sha256> --parts-version 2.16.0 --by agent
+rig-create intake .
+```
+
+This reads producer bytes and never runs a producer or verifies its pixels.
+`reports[]` is append-only. Each entry keeps its id, by/at, a report binding
+(path, raw sha256, spec, head_box, source_canvas, run_canvas), `measurement`
+(the report's own fields copied exactly), `prediction` (`hit` or `no-hit`),
+and the declared `parts_version`. Version is outside the authenticated v1
+report, which does not emit a version. Correct a report with a new retained
+path/id and `--supersedes <earlier-id>`; do not replace its bytes or history.
+The writer validates before writing and leaves project bytes unchanged on
+invalid input. Copied fields are checked against the bound report, never
+against a fresh computation.
+
+A HIT is any reported `layers[].sides.top_px`, `left_px` or `right_px` > 0.
+Keep the per-tag counts, including zero rows and separate `bottom_px`.
+Corners count on two sides; summed edges are incidences, not unique pixels.
+Preflight counts native full-run alpha > 8 **before ghost cleanup** and
+retains registration and canvas identity. `ASSEMBLE_CROP_CLIPPED` counts
+alpha ≥ 128 **after ghost cleanup**; it is a separate instrument. Never
+compare or substitute their numbers. Intake only stores the preflight
+instrument; downstream outcome labels stay in evidence receipts, not an
+in-project label ledger. Missing labels remain unknown, never negative.
+
+Everything about persisted intake is advisory: HIT, absent choice, malformed
+record or unavailable report bytes cannot refuse signoff, acceptance or
+handoff. A retrospective over three pilots fired on all three; only one had
+a labelled positive and none a labelled negative. This shows firing, not
+ability to discriminate. The threshold stays > 0; it is not an approval gate.
+The filled example does not adopt intake and keeps zero warnings.
+
+Colour-adjacent ground and ground enclosed between strands are
+**known-not-predicted** notes in the guide/intake output only (two rounds of
+a model sweep on a pilot did not separate them), with no threshold or warning.
+Silhouette stepping, source-vs-final alpha classes, patchwork runs and
+versioned dark retention need post-assemble outputs and are excluded.
+
+### Targets of review signatures
+
+`signoff rig-review` and `signoff direction-review` accept `--version <n>`.
+Without it, exactly one candidate must exist. Candidates are versions of the
+review's kind with an accepted verdict and no live same-stage signature
+already targeting them. A refusal lists candidates without a recency preference.
+An explicit version must exist with the right kind and an accepted verdict.
+A rig version that a reopen or amendment of `rig-review` or an earlier stage
+made history is no candidate. When that leaves no live rig version accepted,
+`signoff rig-review` refuses before it writes (`RIG_VERSION_UNACCEPTED`),
+naming the lapsed acceptance and its `reopens[]` or `amendments[]` entry;
+register a new rig version and accept it first. A signature recorded before
+this refusal existed is not refused at `rig-review`: `advance` and `handoff`
+stop on it with the same code.
+
+Each signature records `target.version` and `target.verdict`, the literal
+`versions[i].verdicts[j]` path of the accepted verdict. A rig review adds
+`target.review_package = {path: "versions[i].review_package", sha256}`. Its hash
+is SHA-256 of UTF-8 `JSON.stringify(sorted({config, files}))` from the inline
+package record. Keys sort recursively, arrays retain order, and `from` and
+`open` are excluded. Package checks still resolve the retained files on disk.
+
+An adopted authored direction adds `target.direction = {path, sha256}` from
+the version's `provenance.direction` and the retained document bytes. A post
+without an adopted document instead adds `target.post_config`, copied from
+`provenance.config`. Exactly one is present. The latter is compared with the
+version's current binding, while existing provenance checks own file reads.
+Writers validate targets before writing. Refusals leave project.json identical.
+
+From `SIGNOFF_TARGET_SINCE = 2026-11-06T00:00:00Z`, missing and stale targets
+refuse as `SIGNOFF_TARGET_MISSING` and `SIGNOFF_TARGET_STALE`. Earlier signatures
+receive one corresponding `_LEGACY` warning each. Amendment lapse rules continue
+to apply to these approvals.
+
+Pre-interview rig versions bind `target.outputs = {path: "versions[i].outputs",
+sha256}` using SHA-256 of UTF-8 `JSON.stringify(sorted(outputs))`. A declared
+`outputs_lost` refuses signing because nothing survives to bind. Any target has
+exactly one of `review_package`, `outputs`, `direction` or `post_config`.
+The operative verdict is the last human, non-provisional verdict for that
+review stage. It must be accepted, and the target must name that exact verdict.
+A later human bounce makes the earlier bound acceptance stale.
+
+
+## Scene composition and direction@2
+
+`scene write --rig <R> --background <path> [--foreground <path>]
+[--background-rect x,y,w,h] [--foreground-rect x,y,w,h]
+--citations-file <file> [<dir>]` derives the latest accepted rig,
+live rig-review signoff target, compiled model and stage. It appends
+`scenes[]` entries `{n,path,sha256,at,by}` and immutable
+`evidence/scene/s<N>.json` documents with schema `rig-create/scene@1`.
+New entries record `by:"agent"`. A typed `--by` is refused: human authority
+comes from the current ingested `post_composition` Review choice or its decided
+delegation. Earlier human-authored scenes retain their existing validation;
+no contract date or additional historical warning is introduced.
+The project append commits the scene. Unreferenced files are ignored.
+The latest entry is current. Existing documents stay byte-identical.
+
+The closed document contains `schema`, `n`, `rig`, `frame`, `plates`, `layers`.
+`rig` contains `version`, `acceptance`, `model` and `animation`.
+`acceptance` retains `signoff:{stage:"rig-review",checkpoint:null,at}`,
+`verdict` and `review_package:{path,sha256}` from the live signoff target.
+`model` is the accepted package's compiled `{path,sha256}` binding.
+The writer selects `animation.name:"idle"`. `animation.frames` is present
+exactly when the version declares `registration.idle`, and equals that binding.
+Each SHA-256 binds raw file bytes.
+
+`frame.space` is `rig-world-y-up`. `frame.stage` copies the compiled model's
+stage field for field. Plate `rect:{x,y,width,height}` uses rig world units
+and its bottom-left corner. The selected `value` (or delegated decision value)
+must contain `scene:{background:{path,rect},foreground?:{path,rect}}`. The writer
+derives omitted rect flags from that exact map; supplied roles, paths and rects
+must match it exactly. It never infers placement from prose, a singleton input
+or the stage. Rects may extend past the stage and require uniform scale within
+relative 1e-9. Exact choice equality applies even within that scaling tolerance. Plate `width` and `height`
+come from PNG IHDR. Declare one background and at most one foreground, with
+distinct paths and hashes. `layers` is `["background","rig"]` or
+`["background","rig","foreground"]` accordingly. A declared foreground
+is validated fully.
+
+The citations file is a map of the declared roles to
+`{guide:"post_composition",asks:["post_composition"],quote:"recorded words"}`
+or the same citation with `delegated:true` replacing `quote`.
+Each plate stores this human designation, its path, sha256, pixel size, rect,
+and `registered:{kind:"input"|"derived",ref:"inputs[i]"|"derived[i]"}`.
+Inputs must match by path and hash. A derived registration requires every
+`prepared-input` source/sources hop to match by path and hash and terminate
+in registered inputs. Missing result hashes and cycles refuse.
+Register a plate with `input add` before `scene write` names it. New agent
+scenes require input-writer metadata `{path,sha256,bytes,origin,at}` for raw input
+candidates, or a bound `rig-parts-plate-receipt/1` for derived candidates. A
+legacy input must be registered under a new source name with
+`input add <path> --origin …`, then selected through Review. Missing, stale or
+mismatched authority refuses before the project append. Quotes must cite the
+current ingested answer; historical answers remain available to historical
+scene readers. Composite preview presentation remains tracked in
+[Review #482](https://github.com/rig-c/review/issues/482); writer/checker success
+is not visual acceptance.
+
+`rig-create/direction@2` keeps @1's camera, timing, take and citations and adds
+required `scene:{n,path,sha256}` equal to a committed scene entry. Its rig and
+model equal the scene's. Camera boxes and plates share rig-world-y-up units.
+Current authoring and the current live post must cite the latest scene.
+With no live post, no scene is current.
+SCENE_RIG_STALE, lapsed-signoff SCENE_ACCEPTANCE_STALE and
+DIRECTION_SCENE_STALE share one currentness gate. Every committed scene
+retains its historical human acceptance and matching review-package identity,
+plus all schema, file, model, animation, frame, plate, registration and citation
+checks. Reopening preserves these historical records. The next accepted rig
+gets a new scene number.
+Post identity gains `scene:{path,sha256}`. Patches retain their existing
+whole-section schema, so a scene change is a new post.
+
+Existing direction-contract@1 adoption is preserved. Grandfathered posts
+need no document and bypass both direction schemas. Historical @1 documents
+remain readable. Earlier @1 posts warn with DIRECTION_SCENE_REQUIRED.
+Posts from DIRECTION_SCENE_SINCE require @2. The parent finalizes the one
+exported cutoff to the implementation's UTC landing day before merge and
+checks every live pilot for new same-day refusals.
+
+### Scene option context
+
+A post option set takes one of two contexts: the rig kind
+(docs/INTERVIEW.md) or the scene kind. This section is the scene kind's
+contract.
+
+1. **Entries.** `project.scenes[]` is append-only. Each entry is exactly
+   `{n,path,sha256,at,by}`: `n` counts from 1 in array order, `path` is
+   `evidence/scene/s<n>.json`, `sha256` is the SHA-256 of the file's raw bytes
+   in lowercase hex, `at` is a UTC ISO time ending in `Z`, and `by` is `agent`
+   for new scenes or a retained human identifier for historical scenes. The documents are immutable `rig-create/scene@1`.
+2. **Reference.** The context is `{kind:"scene",scene:{n,path,sha256}}`: the
+   entry without `at` and `by`.
+3. **Selection.** At an instant *t*, the candidate is the last `scenes[]`
+   entry whose `at` ≤ *t*. Earlier entries are never selected.
+4. **Currentness.** The candidate applies only if it is current at *t*.
+   Its document must match `sha256`, carry the entry's `n` and have the closed
+   scene@1 shape. Then the scene currentness gate (`SCENE_RIG_STALE`,
+   `SCENE_ACCEPTANCE_STALE`) runs on the records dated at or before *t*:
+   `signoffs[]`, `versions[]` and their `verdicts[]`, `reopens[]` and
+   `amendments[]`. Undated entries are left out.
+   - `rig.version` is the latest live accepted rig, and no live rig version
+     has a higher `n`.
+   - `rig.acceptance` equals the latest live rig-review signoff
+     (`checkpoint:null`) whose target names that version: its
+     `{stage,checkpoint,at}`, `verdict` and `review_package`.
+
+   No live post is needed. When the gate fails, the set takes the rig kind
+   exactly as if no scene existed, so a scene built on an earlier rig never
+   anchors a post set. The rig kind keeps its own refusals: with no live
+   accepted rig and live rig-review signoff at *t*, for example after a
+   rig-review reopen, it refuses `INTERVIEW_OPTIONS_STALE`. An unreadable,
+   changed or malformed candidate refuses `INTERVIEW_OPTIONS_STALE` instead
+   of falling back.
+
+   The closed scene@1 shape in this rule is exactly the structure below.
+   "Closed" means the listed keys must be present, optional keys may be
+   present, and no other key is allowed. A text value is a string with
+   non-blank content. A count is a positive safe integer. A hash is 64
+   lowercase hex digits. A path is a relative `/`-separated text with no empty,
+   `.` or `..` segment, no leading `/`, no backslash and no drive prefix. A box is
+   closed `{x,y,width,height}` with number values. A binding is closed
+   `{path,sha256}`.
+
+   | Object | Keys (optional in brackets) | Values |
+   | --- | --- | --- |
+   | document | `schema`, `n`, `rig`, `frame`, `plates`, `layers` | `schema` is `rig-create/scene@1`; `n` is a count; `plates` is a list; `layers` is a list of strings |
+   | `rig` | `version`, `acceptance`, `model`, `animation` | `version` is a count; `model` is a binding |
+   | `rig.animation` | `name`, [`frames`] | `name` is text; `frames` is a binding |
+   | `rig.acceptance` | `signoff`, `verdict`, `review_package` | `verdict` matches `versions[<i>].verdicts[<j>]`; `review_package` is a closed `{path,sha256}` with text path and a hash |
+   | `rig.acceptance.signoff` | `stage`, `checkpoint`, `at` | `rig-review`, `null`, and a readable date text |
+   | `frame` | `space`, `stage` | `space` is `rig-world-y-up`; `stage` is a box |
+   | each plate | `role`, `path`, `sha256`, `width`, `height`, `rect`, `registered`, [`citation`] | `role` is `background` or `foreground`; `path` is a path; `sha256` is a hash; `width` and `height` are counts; `rect` is a box; `registered` is closed `{kind,ref}` with `kind` `input` or `derived` and text `ref` |
+   | `citation` | any of `guide`, `asks`, `quote`, `delegated` | a string, a list of strings, a string, and a boolean |
+
+   A plate's file bytes, PNG size, registration chain, rect scale and
+   citation wording, the layer order and the role count are validated when
+   the scene is written and in the full scene check above. They are not part of
+   this option-context gate, so a reader of option contexts doesn't have to
+   reproduce them.
+5. **Freshness.** These rules apply to the rig and scene kinds alike.
+   - The context is recomputed at `drafted_at` and again at the selection or
+     decision time, and both must equal `set.context` exactly. A writer uses
+     now. `check` uses the answer's or decision's `at`, and `drafted_at` for a
+     pending set. A later scene, or a later live rig version, makes a
+     scene-kind set `INTERVIEW_OPTIONS_STALE`.
+   - A rig-kind set is recomputed with `scenes[]` ignored, so no scene makes
+     it stale.
+   - A reopen or amendment of a stage at or before the set's stage, dated
+     after `drafted_at` and at or before that time, refuses
+     `INTERVIEW_OPTIONS_STALE`.
+   - The file at `scene.path` must be a literal project-relative regular file
+     whose raw bytes match `scene.sha256`.
+6. **Contract date.** A scene-kind set drafted before
+   `SCENE_CONTEXT_SINCE = 2026-11-08T00:00:00Z` that is stale only under
+   rule 4 is checked under the rule of its day, where the latest scene
+   applied whether current or not. It warns `INTERVIEW_OPTIONS_SCENE_LEGACY`.
+
+### Publication and review read boundary
+
+Publication (#184) retains and raw-byte-seals the scene document, its model,
+plates and optional frames as `files[]` rows using the scene's hashes.
+Every texture page needed by the model is retained and sealed through the
+existing review-package inventory or published files[]. The scene adds no
+page field or second hash domain. Parts keep their manifest and image seals.
+`projectHash` seals raw project.json bytes in rig-review-job-source/2.
+
+Review selects the scene from the retained project, an option context or
+direction document and resolves it against that publication's retained
+project root. Every dependency is read from that same snapshot.
+The files[] inventory does not select a scene.
+
+For viewport `(vx,vy,vw,vh)` and scale `s`, Canvas projects a plate by its top
+edge. Destination left is `(rect.x-vx)*s`, top is
+`(vy+vh-rect.y-rect.height)*s`, width is `rect.width*s`, height is
+`rect.height*s`. Foreground is optional. Review #482 owns that consumer
+change and the inspection camera default. Create performs no rendering.
+
+## Corrections through Review feedback
+
+For config corrections, `--feedback-file`, `--applied-feedback` and
+`--patch-file` now take the Review package argument to `rig-review feedback`,
+with `--item` or `--feedback-id` selecting the saved item. create passes that
+argument unchanged from the project directory and records the CLI argv.
+`--patch-file` selects the patch embedded in that applied item. A downloaded
+preview patch that Review has never applied has no API source. For example,
+a proposed config-patch JSON with no saved applied item must first be applied
+and submitted through Review before create can record it.
+
+create stores the exact stdout at `evidence/review-reads/<sha256>.json`.
+The correction artifact's `review_read` contains `route: "cli"`, `argv`,
+`stdout: {path, sha256}` and `tool: {name, version}`. The `feedback.file`
+binding names those same stdout bytes. A version's `review_origin` uses
+`review_read` and `feedback` with the same bindings. `check` consumes these
+stored responses and does not invoke Review. Records before
+`REVIEW_READ_SINCE` without a receipt get `REVIEW_READ_LEGACY` and preserve
+their history without opening producer-saved session or patch files.
+
+The field inventory used synthetic declared applied/2 through Review's
+browserless session PUT. Producer Apply was outside this inventory. The inventory confirmed
+`patch`, `patchSha256`, `configHash`, `modelHash`, `check` and `files` survive
+`feedback --format json`.
+
+### Recording interview picks from a standing job
+
+Use `interview-answer <question> [<project>] --from-review <actId>` after the
+human finalizes an `interview-picks` act in the standing Review job. The writer
+fetches through its private sibling capability, binds the displayed option set
+by ID and SHA-256, and retains the immutable API act bytes in `review_acts`.
+An identical act can be replayed without adding a second answer. A changed act
+with the same identity refuses. `--why-file` still supplies the exact reason
+for a member override. The removed `--picks-file` flag refuses with
+`INTERVIEW_PICKS_FILE_REMOVED`. Earlier answers remain valid.
+
+## Model-free record publication
+
+`readRecordPublished({root, record, result, phase})` in `job-publication.ts`
+implements create's local boundary for review#561 CP1. `record` binds the
+literal `project.json` path and its raw-byte `sha256`. `result` is either
+`{kind: 'option-set', questionId, setId}` or `{kind: 'plan'}`. Reader `phase`
+is `'inventory' | 'retained'`. A retained request also passes `parts`, the
+identity the inventory phase returned. The optional second argument is the check
+instant in epoch milliseconds, defaulting to the current clock.
+
+The return value has exactly `{label, parts, inputs, files, plan, subjects}`. An
+option context has `plan: null` and exactly the requested
+`{kind: 'interview-picks', questionId, setId}` subject. A plan context has
+ordered `{id, hash}` step identities and eligible
+`{kind: 'checkpoint', checkpointId}` or `{kind: 'signoff', stage}` subjects.
+Subject key order follows these declarations. Identifiers must fit the
+review record-id domain of 1–128 ASCII letters, digits, dots, underscores
+and hyphens, starting with a letter or digit. The reader identity is
+`rig-create/publication-reader/2`. Create's current live host stays in
+`package-only` mode while installed Review 2.8.0 exports the public
+record-mode V3 symbols and types.
+
+Eligibility comes from the one `checkProject` call with `readOnly: true`.
+Its effective stage must match the requested option set's stage. Plan
+signoffs are offered only for an unsigned effective `plan-approved`,
+`rigging-interview` or `post-interview` stage that closes by signoff.
+Checkpoint subjects require an enabled at-checkpoint step in the effective
+execution stage. An empty subject list permits plan inspection. Warnings
+remain eligible, and publication HOLEs refuse publication.
+
+`inputs` projects every declared input to `{path, sha256}` in project-input
+order and rehashes its bytes. `files` seals the record, inputs and selected
+option/context evidence, and every project file the check read. Plans include
+current answer evidence for every displayed step's declared basis and retained
+parts/structure approval evidence. Signoff eligibility uses the existing answer-selection and
+rigging-context readers. Plan step hashes use `stepHash`.
+
+Every path is literal and project-relative. Duplicate declarations within
+a list and conflicting hashes for a path refuse. Identical references share
+one file row. The file list is unique by path and sorted by JavaScript
+string comparison. Both phases verify closure bytes before the official
+check and write nothing, create no lock and perform no intent recovery.
+Default `checkProject` calls keep their existing recovery behavior.
+
+The check's reads come from `checkProject(..., { recordReads: true })`: the
+check modules read project files only through the recorded reader in
+`src/check-reads.ts`, which returns each file the check opened, stat'ed,
+resolved or listed as `{path, sha256}`. The job's private outbox and
+`node_modules/` are not record files and are not recorded. A retained root
+holding exactly `files` therefore gives the check the same bytes, and the
+retained phase returns the inventory phase's context. A test-only strict mode
+(`tests/strict-reads.ts`) throws `CHECK_READ_UNRECORDED` when a check module
+reads a project file around the recorder; every committed example runs
+through it.
+
+The check's waypoints come from the `@rig-c/parts` it loads, which no
+project file seals. `parts` is that package's `{name, version, integrity}`:
+the installed version and the integrity that `bun.lock` and
+`package-lock.json` beside the install record for it, each lockfile that
+exists. Only the parts entry is read, never a whole-lockfile hash, so an
+unrelated dependency bump leaves the closure valid. A missing or
+disagreeing entry refuses `JOB_RECORD_PARTS_LOCK_MISSING`. In the retained
+phase the reader compares the sealed identity with the host's parts, the
+ones the retained check loads, before it seals the closure files. A difference refuses
+`JOB_RECORD_PARTS_MISMATCH`, naming both versions; the remedy is to rebuild
+the project on the host's parts or to run the check where the sealed
+version is installed.
+
+After its seals pass, a retained-root check refusal produces
+`JOB_RECORD_CLOSURE_INCOMPLETE`, carrying structured `details` containing
+only the check's finding codes and record paths. It fires only when the
+retained root lacks or changed a closure file. An option-set request for a
+question with no pending set refuses `JOB_RECORD_SUBJECT_INVALID` in both
+phases.
+Collection members bind their collection interview closure into a
+project-relative artifact with
+`rig-create collection-binding [<member dir>] [--out <path>]` (default
+`evidence/collection-binding.json`) and record `collection_binding` in
+`project.json` (`{ path, sha256, spec: "rig-create/collection-binding@1", collection_sha256 }`).
+The binding file seals the raw `../../collection.json` `sha256`, the full
+collection `interview` (`questions`, `framing`, `waypoints` and `post.items`,
+preserving `history[]` so `basis: "overridden"` checks verify
+`collection_answer_at` in isolated retained roots), and the member's resolved
+`inherited_answers`. A member without a valid, up-to-date `collection_binding`
+refuses with `JOB_RECORD_COLLECTION_EXTERNAL`.
+
+
+## Parts-review receipt selection (create#267)
+
+This section supersedes earlier saved-verdict command examples and evidence
+requirements in this document.
+
+`signoff parts-review --draft <id>` and `structure-snapshot --draft <id>`
+select the latest parts-verdict receipt for that draft in `review_acts` ledger
+order. Both CLI-read and act receipts participate. The response retained by
+`parts-review` is hash-bound and validated through the same reader in the
+writers and check. The signoff retains its selected response binding and spec.
+A later response does not replace that historical binding. The existing latest
+changes-requested gate still applies. The removed `--evidence` and `--verdict`
+flags exit 2 with `PARTS_VERDICT_FILE_ROUTE_REMOVED` before writing.
+
+Signatures before `PARTS_VERDICT_RECEIPT_SINCE` retain their legacy file
+bindings and WARN with `PARTS_VERDICT_FILE_LEGACY`. Check never opens their
+review-saved files. New signatures require a recorded API receipt.
+
+The downstream review-package identity gate uses the selected draft's manifest
+and image bindings. Opaque CLI source paths cannot suppress this comparison.
+A mismatched accepted image retains `REVIEW_PACKAGE_PART_FILE_MISMATCH`.
+Historical saved-file approvals WARN and skip this unavailable comparison.
+
+Historical response checks keep the existing `DRAFT_RIG_UNAVAILABLE` warning
+when ignored draft artifacts cannot be read. The retained API response remains
+hash- and spec-checked. New writers require the source bytes before recording.
+The examples query the pinned Review CLI, so a Review pin bump regenerates
+these responses and their dependent example bindings.
+
+## One artwork, one project, and the fix ledger (create#285)
+
+One artwork is one project for its whole life. A new project is for a different
+painting or a different rig kind. A redo, a new source ladder, new seeds, a new
+tool version or a new parts route is a new version in the same project. Only
+recorded drafts and versions count as versions; any other build is an
+experiment.
+
+`rig-create init <dir> --painting <file> --origin <words>` copies the painting
+into `inputs/`, registers it as the first input and declares its path in
+`project.painting`. It refuses with
+`INIT_ARTWORK_EXISTS` when a `project.json` directly under `--projects-root`
+(default: the new project's parent folder) has an input with the same sha256.
+`--same-artwork-reason <file>` allows it, and the new record keeps
+`same_artwork: { reason, at, projects }`. init without `--painting` is unchanged.
+
+The fix ledger lives in `project.json.fix_ledger`, so a restart or a new build
+cannot drop an accepted fix unnoticed. `ledger add <id> --by <who> --check <check
+id> --bar <text> --note <ref> --verbatim-file <file>` records one owner fix:
+the note it answers (`corrections[<id>]` or `versions[v<n>].verdicts[<i>]`),
+the owner's words quoted from it, an opaque check id and the bar.
+`ledger retire <id> --by <who> --reason-file <file>` retires it with a reason.
+A retired row stays in the ledger.
+
+The pixel checks are the project's own script. create binds its report and does
+not run or reproduce a check. A draft is recorded with
+`draft-rig ... --ledger-report <file>`, a `rig-create/fix-ledger-report@1`
+report:
+
+```
+{"schema": "rig-create/fix-ledger-report@1",
+ "build": {"dir": "<as given>", "manifest_sha256": "<sha256 of the build's parts.json>"},
+ "script_sha256": "<sha256 of the check script>",
+ "rows": [{"id": "T1", "result": "pass|fail|unmeasurable", "measured": 3, "bar": "<text>", "reason": null}]}
+```
+
+The report stays under the project outside ignored roots, for example
+`evidence/fix-ledger/`. Build identity is `build.manifest_sha256` against the
+draft's bound `parts.json`; `build.dir` is not identity. Extra keys in a row
+are allowed. The draft records `ledger_report { path, sha256, spec }`,
+`fixes_against`, `fixes` and, when given, `known_regressions [{ id, reason }]`:
+
+- The report must cover every live row (`DRAFT_LEDGER_INCOMPLETE`).
+- A row the previous draft passed must pass again. `fail`, `unmeasurable` or a
+  missing row is a regression (`DRAFT_LEDGER_REGRESSION`), unless
+  `--known-regression <row id>=<reason file>` names it. A known regression
+  stays owed: the next draft passes that row or records it as a known
+  regression again, with its own reason.
+- `fixes` lists the live rows this report passes that the last draft a person
+  saw did not. That draft is the latest earlier one with a parts-review
+  receipt, else the previous draft.
+
+The filled example records the v1 bounce's lantern fix as row `T1` and a later
+draft, `lantern`, with a synthetic passing report
+(`templates/example-draft/evidence/fix-ledger/lantern.json`, written by
+`scripts/example-ledger.ts` through `generate-example-order.ts`).
+
+`rig-create restart [<dir>] --by <human> --reason-file <file>` starts the record
+again at v1 when the owner orders it. It writes the record `init` writes, with
+no versions, drafts, signoffs, plan, answers or review acts. It keeps the name,
+title, `painting`, `same_artwork`, `inputs[]` and `fix_ledger` with every row, and appends
+`restarts[] { at, by, reason, previous_record_sha256 }`. create does not keep
+the earlier `project.json`; git history holds it, so restart refuses before it
+writes unless `project.json` is committed: tracked and byte-identical to its
+version at HEAD. create's writers don't commit, so commit `project.json`, then
+restart. Before writing, restart also re-validates every input with the input writer's checks. A kept part set
+(inputs under `<set>/parts/*.png` or `<set>/parts.json`) must keep its
+`parts.json`, its PNGs and its rig (`rig.json` and `mesh_report.json`). The
+first draft after a restart has no predecessor, but it covers the whole
+ledger, so the inherited fixes are checked on day one. A restarted record
+checks the same as a fresh `init` record: the same codes, which include the
+open interview's `INTERVIEW_INCOMPLETE` refusals, and 0 warnings. Codes are in
+[CHECKS.md § Fix ledger, ledger reports and restarts](CHECKS.md#fix-ledger-ledger-reports-and-restarts-create285).
+
+## Deriving the next moves: `rig-create next` (create#329)
+
+`rig-create next [<project dir>] [--json]` is a read-only command that derives
+the project's next moves and whose they are from `project.json`:
+
+- **Derived, never guessed.** Each item comes from a record field: `stage` and
+  its exit requirement, open `plan.steps[]` and their `status`, lapsed
+  approvals (`reopens[]` and `amendments[]` lapse lists), pending review jobs
+  and `review_acts[]`, bound inputs and drafts, and the current `check`
+  findings. Each item names the `field` it came from and what the record
+  `awaits`. When required authored input is not yet in `project.json`, the item
+  names the missing record field in `unanswered_by_record` and does not guess.
+- **Role ownership.** Every move names `role`:
+  - `agent`: a complete, runnable `rig-create` command the agent may run now.
+  - `producer`: a command of a pinned package (`rig-parts`, `rigc`).
+  - `human`: a person's act collected through the review tool (`review_act`),
+    with `command: null` and never a `--by user` writer.
+- **Refusals come first.** When `check` reports refusals (or publication holes),
+  `next` lists each in `refusals[]` with its `CHECKS.md` remedy (`fix`) before
+  any forward move. A project with a blocking refusal has `moves: []` and
+  `awaits: []`.
+- **Rigging plan before sign-off.** At `rigging-interview`, when no rig step
+  belongs to that approval stage, `next` lists `plan add <id> <dir> --by agent
+  --phase rig …` for each answered guide without a step (bones, meshes,
+  constraints, motion). The agent supplies the authored plan fields; these
+  steps must be approved at `rigging-interview`. The human sign-off stays
+  unanswered by record until the plan steps exist.
+- **Read-only and deterministic.** `project.json` and the project tree remain
+  byte-identical. An `accepted` project with no lapsed approvals reports
+  `accepted: true`, `moves: []` and exits `0`.
+
+`--json` emits a `rig-create/next@1` document:
+
+```json
+{
+  "schema": "rig-create/next@1",
+  "project_id": "<project.name>",
+  "stage": "<project.stage>",
+  "effective_stage": "<check effective_stage>",
+  "accepted": false,
+  "refusals": [
+    {
+      "code": "<CHECK_CODE>",
+      "field": "<record path>",
+      "message": "<finding message>",
+      "fix": "<CHECKS.md remedy>"
+    }
+  ],
+  "awaits": ["<awaited record target>"],
+  "moves": [
+    {
+      "role": "agent|producer|human",
+      "field": "<source record field>",
+      "awaits": "<awaited record target>",
+      "command": "<complete runnable command or null>",
+      "act": "<description of the move or review-tool act>",
+      "review_act": {
+        "kind": "parts-verdict|interview-picks|review-verdict|signoff|signoff-checkpoint",
+        "stage": "<stage>"
+      },
+      "lapse": {
+        "code": "REOPEN_SIGNOFF_LAPSED|REOPEN_VERDICT_LAPSED|AMENDED_STEP",
+        "source_field": "reopens[0]",
+        "target_field": "signoffs[2]",
+        "message": "<warning message>"
+      },
+      "unanswered_by_record": "<missing record field when not derivable>"
+    }
+  ]
+}
+```
+
+
+### Operator withdrawal of an execution checkpoint
+
+`plan checkpoint-withdraw <id> [<project dir>] --by <operator>
+--reason-file <file> --quote-file <file>` appends one optional
+`plan.checkpoint_withdrawals[]` entry. Each entry has schema
+`rig-create/checkpoint-withdrawal@1`, the complete original `step`, its `sha256`
+from stepHash, its per-id replacement `generation`, `by`, `at`, `reason` and
+`verbatim`. Both input files are strict UTF-8 and retain their exact text.
+The operation requires an enabled unfinished checkpoint in the current execution
+stage. Identical retry inputs preserve project bytes. Conflicting retries refuse.
+
+The original step, checkpoint decision, proposal, approval hashes and signatures
+remain unchanged. A withdrawal supplies operator policy without creating a human
+act or signature. Only an exact step hash and replacement generation match makes
+the effective requirement false. A later revision or re-enabled decision needs
+its own policy. Old journal entries and event-time status snapshots remain
+history. Absence of the optional journal preserves existing behavior.
+
+
+### Operator amendment of an execution bar
+
+`plan bar-amend <id> [<project dir>] --by <operator> --reason-file <file>
+--quote-file <file> --bar-file <file>` appends an optional
+`plan.bar_amendments[]` entry with exactly these fields:
+
+```json
+{
+  "schema": "rig-create/bar-amendment@1",
+  "step": { "id": "geometry", "phase": "rig", "bar": "Original source-bound bar.", "status": "pending" },
+  "sha256": "<original stepHash>",
+  "generation": 0,
+  "amended_bar": "<exact bar-file text>",
+  "by": "<operator>",
+  "at": "<ISO timestamp>",
+  "reason": "<exact reason-file text>",
+  "verbatim": "<exact quote-file text>"
+}
+```
+
+`step` retains the complete original object; the shape above abbreviates its fields.
+`generation` counts retained replacements for that step id. The amendment applies
+only to the exact current original hash and generation. A later revision does
+not inherit it, even when the original text is restored. Historical amendments
+remain bound to their retained original version. A malformed journal grants no
+partial policy and refuses check; a future entry is invalid at check's instant.
+Absence of this optional journal preserves existing behavior.
+
+This operation requires one unfinished step in its current execution stage and
+nonempty strict UTF-8 input files. The files retain BOMs, whitespace and final
+newlines. Their contents are checked before and within the bound-job and plan
+locks and again before commit. Identical retry inputs preserve project bytes,
+inode and modification times; changed inputs for an already-bound amendment
+refuse. The original step, every approval hash and signature, checkpoint policy,
+and historical act receipt remain unchanged. Normal signed-step revision guards
+still apply.
+
+The operator records an explicitly authorized quoted policy here, without a new
+human act or signature. This authority is specific to bar amendment; it does not
+permit other human decisions outside Review. The effective bar supplies the
+existing warning-only appearance wording lint. Create does not interpret English
+bar text as an automatic producer measurement or proof of completion. Normal
+done, next and advance retain their existing checks and producer-report contracts.
+
+## Updating a project's release pins
+
+Run `rig-create packages upgrade [dir] --by <operator>` before opening a record
+ask on a host whose parts release differs from the project's. The writer moves
+`dependencies` for core, parts and review to Create's release pins, using a
+staged `bun install --ignore-scripts`. No manual `bun add` is needed. The
+record publication contract compares parts only; core and review still move
+with Create's complete release pin set. Missing pins are recorded as `null`.
+
+The writer appends `package_upgrades[]`, with `by`, `at`, `packages` (each entry
+has `name`, `from`, `to`) and `lock_sha256` (the installed lockfile's sha256).
+It preserves literal manifest and record bytes outside those fields. The
+lockfile and install are regenerated; lifecycle scripts are not executed.
+It never downgrades, and refuses an already-current manifest. Local and
+workspace dependencies are refused because staging would change their base.
+
+The same project check runs in fresh processes before and after the install
+swap, avoiding cached parts modules. Added or changed refusals abort the move;
+the record, manifest, lockfile and original install are restored. Complete
+this command before another process reads or writes the project. This is an
+operator pin migration, not a review verdict or stage transition.