@journeykit/canon 0.32.0 → 0.33.0

package/dist/index.js

@@ -3,6 +3,7 @@
 // src/index.ts
 import { spawnSync, execSync } from "node:child_process";
 import { existsSync, readdirSync, realpathSync } from "node:fs";
+import { constants as osConstants } from "node:os";
 import { resolve, join, basename } from "node:path";
 import { fileURLToPath } from "node:url";
 var binaryName = process.platform === "win32" ? "canon.exe" : "canon";
@@ -165,4 +166,7 @@ var result = spawnSync(binary, process.argv.slice(2), {
 if (result.error) {
   console.error(`canon: failed to run ${binary}: ${result.error.message}`);
 }
+if (result.status === null && result.signal) {
+  process.exit(128 + (osConstants.signals[result.signal] ?? 0));
+}
 process.exit(result.status ?? 1);

package/dist/skills/SKILL.src.md

@@ -186,7 +186,7 @@ variable, and an unknown value is refused (`UNKNOWN_ROLE`).
 - **A role is set, or you were spawned as one:** load only
   `canon skills show role-<role>` and do that role's steps. `canon status`
   and `meta.next` then show only your role's steps, and count the others in
-  `waitingOn`; `canon schema --as <role>` lists only your role's commands.
+  `data.waitingOn`; `canon schema --as <role>` lists only your role's commands.
   Do not load another role's guide.
 - **No role (one agent doing everything):** follow `canon status` and load
   each role guide as its phase starts: planner for steps 1–2,
@@ -201,8 +201,11 @@ A role is guidance, not enforcement: `--role` on `evidence add` and
 
 - Start a session with `canon status`: where each subject stands and the next
   commands. After that, do not call it only to learn the next step: every
-  write returns `meta.next` (`[{command, argv, why, actor, role}]`), the same
-  steps `status` would give, narrowed to what the write touched. `actor: human`
+  write returns `meta.next` (`[{command, argv, reason, x-canon: {actor, role}}]`), the same
+  steps `status` would give, narrowed to what the write touched. Each entry is
+  runnable: `argv` is the command without `canon` (with `--json` when you
+  called in JSON mode). Guidance that needs a value you must fill in is not a
+  next entry; it is in the error `hint` or the report text. `x-canon.actor: human`
   marks a step only the human takes.
 - Your role guide's **Commands** block (`canon skills show role-<role>`) is
   your complete command set, every option of every leaf included. Run `canon schema <command> --json` only for a
@@ -211,20 +214,25 @@ A role is guidance, not enforcement: `--role` on `evidence add` and
 - Pass `--json` and read stdout as one document, nothing on stderr. Success is
   `{"ok":true,"data":…,"meta":…}`; failure is
   `{"ok":false,"error":{…},"meta":…}` (a check that fails keeps its report in
-  `data`). `meta` carries `command`, `schemaVersion`, `canonVersion`, `next`,
-  `warnings` and, for a repeated write that changed nothing, `unchanged: true`.
+  `data`). `meta` carries `tool`, `toolVersion`, `contract` (`atip/1`), `schemaVersion`,
+  `command`, and when present `next`, `warnings` (`[{code, message}]`) and
+  `page`; a repeated write that changed nothing reports `data.unchanged: true`.
+  Absent members are omitted, never `null` or `[]`. A paged list puts
+  `meta.page.nextCursor` on the call's `meta.next` as `--cursor <nextCursor>`;
+  no `nextCursor` means no more.
   On failure branch on `error.code`, fix the option `error.field` names
   using the `error.expected` values (`field` is an option name, or a JSON
   pointer such as `/items/2/scenario` into an `--input` document), and
   follow `error.hint`: every refusal carries a working invocation. The codes
   are stable; `canon schema --errors --json` lists them and
   `canon schema --error <CODE>` explains one.
-- **Exit codes:** 0 ok; 1 the command's own finding (a failed check, a
-  violation, or `unverifiable` when nothing was examined); 2 refused (usage,
+- **Exit codes:** only 0, 1 and 2 exist: 0 ok; 1 the command ran and its answer
+  is negative or incomplete (a failed check, a violation, `unverifiable` when
+  nothing was examined, a partly failed batch); 2 refused to run (usage,
   `CONFIG_MISSING`, an id or file that does not exist, an invalid argument).
   A refusal leaves the tree unchanged.
 - Repeating a write is safe: a record that already exists with identical
-  content is reported `unchanged` (`meta.unchanged`), not duplicated.
+  content is reported `unchanged` (`data.unchanged`), not duplicated.
 - An option that takes an id is the bare noun (`--change add-login`,
   `--scenario auth.login.01`, `--actor reviewer-1`, `--project root`,
   `--session s-1`), and an `--input` document key is that name without `Id`
@@ -257,8 +265,8 @@ from a file or stdin) is a batch, run in order and answered with
 `skipped`, and that element's `data` or `error`). A batch is validated whole
 before anything is written: an invalid element writes nothing and exits 2,
 `error.field` pointing at `/items/<i>/<key>`; a write that fails stops there
-(exit 1) and re-running the same batch reports the finished elements
-`unchanged`. A typo in a key is refused (`INPUT_UNKNOWN_FIELD`), never dropped.
+(exit 1, `BATCH_INCOMPLETE`) and re-running the same batch reports the finished elements
+`unchanged`. A typo in a key is refused (`INPUT_INVALID`, `field` naming the key), never dropped.
 `canon schema <command> --json` shows the leaf's input schema and an example.
 
 ```text
@@ -276,7 +284,7 @@ The five commands that delete or rewrite existing data (`canon purge`,
 `canon tier age`, `canon ledger compact`, `canon artifacts move`,
 `canon migrate`) act in two steps. The bare run previews: it writes nothing,
 exits 0 and prints the effects and a `planDigest`. Read the effects, then act
-with `--commit --plan-digest <planDigest>`. It refuses (`PLAN_CHANGED`) when
+with `--commit --plan-digest <planDigest>`. It refuses (`PLAN_STALE`) when
 the plan differs from the one you previewed, so run the preview again. Appends
 and state transitions (`gate promote`, `subject move`) run directly. Where a
 preview helps elsewhere (`init`, `skills install`, `export`, `inventory sync`,

package/dist/skills/reference/canon-context.md

@@ -35,7 +35,7 @@ and what to run next. `--json` prints the `{ok, data, meta}` envelope: the
 header adds no field, and `policy.spec_coverage`/`policy.diagnostics`
 already carry the same fact. `--fields <list>` keeps only the named
 top-level fields (`kinds`, `enums`, `policy`, `review`, …); an unknown name is
-`UNKNOWN_FIELD` (exit 2).
+`USAGE` (exit 2; `field` is `--fields`, `expected` lists the selectable fields).
 
 On a repository that still holds 0.27 canon state, `canon context` warns
 and puts `canon migrate --json` first in `meta.next`: run `canon migrate`

package/dist/skills/reference/canon-gate.md

@@ -347,7 +347,7 @@ brief_override:
 Under `--json` the same waiver is `data.overrides[]` (`code` of the waived
 refusal, `reason` verbatim), so a caller sees what its `--override-reason`
 let through; a repeat of an identical record is `unchanged`
-(`meta.unchanged`) and records no second override. `--override-reason`
+(`data.unchanged`) and records no second override. `--override-reason`
 exists on `subject move` too (see `canon-subject`).
 
 A blank or multi-line reason exits 2; an override when nothing refused is

package/dist/skills/reference/canon-review.md

@@ -122,7 +122,7 @@ Many findings at once: `--input` takes inline JSON, a file or `-`; an array
 (or NDJSON) is a batch validated before any write. Keys are the option
 names in camelCase (`change`, `actor`, `resolutionRev`); `canon schema
 finding add --json` shows the input schema and an example. An identical
-repeat is `unchanged` (`meta.unchanged`) and writes nothing; a different
+repeat is `unchanged` (`data.unchanged`) and writes nothing; a different
 finding under an occupied key is `FINDING_SEQ_OCCUPIED`.
 
 ### A defect the author found in its own work
@@ -198,7 +198,7 @@ allowed, and the commit made from it has the same code tree, so committing it
 afterwards leaves the review as it was: a review is judged by its pins (the
 scenario and what its evidence says), not by the commit. Outside git, or
 with no commit, the write is refused with `NO_COMMIT`. An identical review
-written again is `unchanged` (`meta.unchanged` under `--json`) and adds no
+written again is `unchanged` (`data.unchanged` under `--json`) and adds no
 record.
 
 **Done when:** `canon gate check` reports no `unreviewed-promotion` for the

package/dist/skills/reference/canon-storage.md

@@ -104,7 +104,8 @@ canon query --kind handoff --since 2026-06-01T00:00:00Z
 canon query --kind trajectory --json
 
 # Page a long result and keep only the fields you need; `meta` carries
-# returned, total, hasMore and nextCursor (`--all` returns everything).
+# `page` = {returned, total, nextCursor}; a present `nextCursor` means more, and
+# `meta.next` repeats the call with `--cursor <nextCursor>` (`--all` returns everything).
 canon query --kind trajectory --json --limit 50 --fields at,kind
 canon query --kind trajectory --json --limit 50 --cursor <nextCursor>
 ```
@@ -189,7 +190,7 @@ section listing them and emits a matching stderr `WARN`.
 `canon purge --kind <kind> --before <RFC3339> [--commit --plan-digest <planDigest>] [--repo <dir>] [--json]`
 is the canonical data-lifecycle boundary: the bare run previews: it prints the removal set and
 its `planDigest` and deletes nothing; `--commit --plan-digest <planDigest>` deletes only if
-the plan recomputed now has the same digest (`PLAN_CHANGED`, exit 2, when the
+the plan recomputed now has the same digest (`PLAN_STALE`, exit 2, when the
 data moved). The only purgeable kinds are
 `session`, `run`, `event`, and `trajectory`; the cutoff applies to every
 routed rung and every configured aging destination, including retained
@@ -210,7 +211,7 @@ arguments previews an empty removal set.
 With `--json`, `purge` and `export` answer `{ "data", "meta" }` like every other
 command: `data` is the plan or manifest, `meta.next` the step after (a plan's is the
 human's review and `--commit --plan-digest`), and an export's page state (`total`, `returned`,
-`nextCursor`) sits in `meta`. `export --json --output <file>` writes the manifest to the
+`nextCursor`) sits in `meta.page`. `export --json --output <file>` writes the manifest to the
 file and answers with `data: { output, kind, recordCount }`; `--dry-run`
 answers with what it would write and writes nothing.
 

package/dist/skills/reference/canon-subject.md

@@ -71,7 +71,7 @@ canon subject new subject-domain-loop \
   NDJSON) is a batch validated before any write, with `operands` holding the
   id and the other keys the option names in camelCase (`canon schema subject
   new --json` shows the schema and an example). Writing an identical subject
-  again is a no-op reported `unchanged` (`meta.unchanged`).
+  again is a no-op reported `unchanged` (`data.unchanged`).
 
 ### 2. Retrieve subject-scoped strategy memory BEFORE working
 
@@ -747,21 +747,23 @@ Status fails closed rather than suggest progress the gate would refuse:
 ```
 
 The steps that follow are not in `data`: they are `meta.next`, most useful
-first, with `meta.nextOmitted` counting what was cut and `meta.waitingOn`
+first, with `data.nextOmitted` counting what was cut and `data.waitingOn`
 (with a declared role, `--as`) counting the steps each other owner holds:
 
 ```json
 "next": [
-  { "command": "show the brief in openspec/changes/c-promo/proposal.md; build and attest nothing for promo until the human answers; then record their words with `canon brief approve c-promo --approver <the human> --note \"<their words>\"`", "argv": [], "why": "promo: the brief is not approved", "actor": "human", "role": null },
-  { "command": "canon finding close c-cart --round 1 --seq 1 --disposition fixed --actor <unit> --session <session>", "argv": [], "why": "cart: 1 open blocker finding(s); fix it, commit, then close it", "actor": "agent", "role": "implementer" },
-  { "command": "canon status", "argv": ["canon", "status"], "why": "1 scenario(s) carry no @subject tag (first: cart.promo.01); add `@subject:<id>` above each in its .feature file, then check again", "actor": "agent", "role": "planner" }
+  { "command": "canon brief show c-promo --json", "argv": ["brief", "show", "c-promo", "--json"], "reason": "promo: the brief is not approved; build and attest nothing for promo until the human answers", "x-canon": { "actor": "human" } },
+  { "command": "canon gate check --json", "argv": ["gate", "check", "--json"], "reason": "cart: 1 open blocker finding(s); fix it, commit, then close it with `canon finding close`", "x-canon": { "actor": "agent", "role": "implementer" } },
+  { "command": "canon status --json", "argv": ["status", "--json"], "reason": "1 scenario(s) carry no @subject tag (first: cart.promo.01); add `@subject:<id>` above each in its .feature file, then check again", "x-canon": { "actor": "agent", "role": "planner" } }
 ]
 ```
 
-`argv` is the command split into words, and is empty when the command still
-holds a `<placeholder>` for what only the agent knows (or is not a canon
-command at all). On a repository that still holds 0.27 canon state,
-`canon status` warns (`data.warnings`, `meta.warnings`) and puts `canon
+`argv` is the command without the executable (`canon` + `argv` is the call),
+and carries `--json` when you called in JSON mode. Every next entry is
+runnable as it stands: guidance that needs a value only you know (an actor id,
+a session, the human's words) is not a next entry, it is in the error `hint`
+or the report text. On a repository that still holds 0.27 canon state,
+`canon status` warns (`data.warnings`, `meta.warnings` as `[{code, message}]`) and puts `canon
 migrate --json` first in `meta.next`: run `canon migrate`, then `canon
 migrate --commit --plan-digest <digest from the preview>`, then `canon
 skills install`.
@@ -792,14 +794,14 @@ only the pending drafts, and `flow` lists each flow step of every tagged
 change as `{ "id", "change", "scenarios": [{ id, title, failure, evidenced,
 review }], "gaps" }`.
 
-Each `meta.next` entry's `actor` is `agent` (its `command` is a canon command
-line) or `human` (its `command` says what to get from the human).
+Each `meta.next` entry's `x-canon.actor` is `agent` or `human` (a step only the
+human takes; its `reason` says what to get from them).
 
 `policy.spec_coverage` has the shape `canon context --json` prints
 (`null` when absent, `{"invalid": …}` when unusable). `statusVersion`
 changes only when a field changes meaning or is removed. It became `2`
 in 0.16, when `next[].command` stopped always being a command line
-(`actor` tells which), and `brief` was added alongside. It is `3` since
+(`actor` told which), and `brief` was added alongside. It is `3` since
 0.17, when `brief.proposal` was removed: the canon `brief.md` is
 `brief.brief`, with `briefExists` and `source`. It is `4` since 0.31, when the
 `brief` object became the `briefs` list.

package/dist/skills/reference/role-implementer.md

@@ -220,7 +220,7 @@ canon trace add-login_1_1
 <!-- canon:generated commands-implementer end -->
 
 After the first `status`, follow `meta.next` of each write; do not call
-`canon status` again to learn the next step. Every record you write takes
+`canon status` again to learn the next step. Each `meta.next` entry is runnable: run `canon` + its `argv`; guidance that needs a value you must fill in is in the error `hint` or the report text, not in `meta.next`. Every record you write takes
 the commit it is about from `--rev` (default `HEAD`, any git revision). You
 need not commit first: code that is not committed yet is recorded with its
 `codeTree` and `worktreeDirty: true`, never refused. Outside git, or in a
@@ -371,7 +371,7 @@ not another evidence step.
 ## Retry safety
 
 `evidence add` is content-keyed: repeating it with identical input returns
-the existing record with `meta.unchanged: true` instead of a duplicate (a
+the existing record with `data.unchanged: true` instead of a duplicate (a
 batch reports that element `unchanged`). After a timeout or a lost
 response, run the same command again. `scenario new` is not: an existing
 scenario id is refused (`SCENARIO_TAG_EXISTS`) and nothing changes, so check

package/dist/skills/reference/role-orchestrator.md

@@ -444,10 +444,10 @@ canon trace add-login_1_1
 ## Read the state
 
 `canon status` lists the next steps, each with the `role` that takes it
-(`null` for the human), and `waitingOn` counts the steps held by each other
+(`null` for the human), and `data.waitingOn` counts the steps held by each other
 owner, `human` included. Call it once at the start and when resuming, not
 after a write: after `subject move --to` or a spawned role's write, the
-write's `meta.next` and `meta.waitingOn` are the status for what it touched.
+write's `meta.next` and `data.waitingOn` are the status for what it touched.
 
 ## Spawn each role
 
@@ -510,7 +510,7 @@ not sign off.
 
 ## Relay the human's answer
 
-When `status` or `meta.next` shows a step with `actor: human` (the brief's
+When `status` or `meta.next` shows a step with `x-canon.actor: human` (the brief's
 approval), stop everything for that scope and put the brief in front of the
 human in its language: `canon brief show <slug> --body` prints the brief and,
 last, its digest. Send the output to the human's own view, never retyped (omp:
@@ -563,7 +563,7 @@ holds the next command and the verified claims (`canon skills show canon-vocab`)
 After a timeout or a lost response, repeat the write only when its repeat is
 safe. `evidence add`, `review scenario`, `review change` and `finding add`
 are content-keyed: an identical repeat returns the existing record with
-`meta.unchanged: true` (a batch reports the element `unchanged`).
+`data.unchanged: true` (a batch reports the element `unchanged`).
 `finding close`, `subject adopt`, `inventory sync`, `ingest *`, `gate
 promote` and `task done` are replay-safe the same way. `subject new`,
 `change new`, `feature new`, `scenario new`, `subject move` and `dispatch
@@ -580,7 +580,7 @@ its preview, never from an old digest.
 | "The reviewer can be me under another label." | The reviewer is a separate process with its own real session id (#39). |
 | "Approve the brief; the human said they are busy." | An answer they did not give is not recorded. Show the brief, ask, and record only an explicit approval with `--relayed-via`. |
 | "Override the refusal to ship." | Fix the gap the refusal names; `--override-reason` waives only the `require_review` gaps and the brief gap, is recorded on the subject, and is for the human's call, not a shortcut. |
-| "Run the commit now, the preview looked fine earlier." | A bare run previews; `--commit --plan-digest` acts only on the plan you just previewed (`PLAN_CHANGED` otherwise). Preview again, then act. |
+| "Run the commit now, the preview looked fine earlier." | A bare run previews; `--commit --plan-digest` acts only on the plan you just previewed (`PLAN_STALE` otherwise). Preview again, then act. |
 | "I have corrected this agent before." | A correction repeated across runs belongs in a scenario, the policy or a gate, not more prose. Tell the human. |
 
 ## Move the subject
@@ -623,10 +623,10 @@ read the refusal in `error` of `canon subject move demo --to shipped --json`.
 move` and `canon migrate` delete or rewrite existing data. A bare run only
 previews: exit 0, nothing written, a report with `planDigest` and
 `effects[]`. Read the effects, then act with `--commit --plan-digest
-<planDigest>`; it refuses (`PLAN_CHANGED`, exit 2) when the plan recomputed
+<planDigest>`; it refuses (`PLAN_STALE`, exit 2) when the plan recomputed
 now differs from the one you previewed. A document passed with `--input`
 never carries `--commit` or `--plan-digest`, and these five leaves take one
-object only (`INPUT_BATCH_UNSUPPORTED`).
+object only (`INPUT_INVALID`).
 
 ```bash
 canon purge --kind session --before 2026-01-01
@@ -678,6 +678,6 @@ git-ignored, and `canon migrate --revert` needs it (keep it until you are sure).
 **Done when:** `canon migrate` reports nothing left to move, `canon skills
 check` exits 0, and `canon status` and `canon gate check` no longer warn
 about 0.27 state; read the first in `data` of `canon migrate --json`, the
-others in `meta.warnings`.
+others in `meta.warnings` (`[{code, message}]`).
 
 Reference: `canon skills show canon-subject`.

package/dist/skills/reference/role-planner.md

@@ -172,7 +172,7 @@ canon trace add-login_1_1
 ```
 <!-- canon:generated commands-planner end -->
 
-After the first `status`, follow `meta.next` of each write. `brief check`
+After the first `status`, follow `meta.next` of each write. Each `meta.next` entry is runnable: run `canon` + its `argv`; guidance that needs a value you must fill in is in the error `hint` or the report text, not in `meta.next`. `brief check`
 lists blockers and advisories and exits 1 when it finds blockers; `canon
 brief show --as planner` names the next steps. The change is an optional
 operand of both (`canon brief check add-login`); without it they read the

package/dist/skills/reference/role-reviewer.md

@@ -220,7 +220,7 @@ advisory names it); that is the orchestrator's step, not yours.
 Run `gate check` once, before `review scenario`: its `unreviewed-promotion`
 violations are the subjects and scenarios that need your review. Do not loop
 it. After `review scenario`, read its `meta.next` instead of calling `gate check`
-or `status` again.
+or `status` again. Each `meta.next` entry is runnable: run `canon` + its `argv`; guidance that needs a value you must fill in is in the error `hint` or the report text, not in `meta.next`.
 
 ## Separate session
 
@@ -355,7 +355,7 @@ implementer owns. Your last write's `meta.next` names the next step.
 ## Retry safety
 
 `review scenario`, `review change` and `finding add` are content-keyed: an
-identical repeat is reported `unchanged` (`meta.unchanged: true`, or the
+identical repeat is reported `unchanged` (`data.unchanged: true`, or the
 element's `status` in a batch), so after a timeout run the same command
 again. A different finding under an occupied round and seq is refused
 (`FINDING_SEQ_OCCUPIED`): take the next seq. `finding close` with the same

package/man/canon-adapter-authorize.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-adapter-authorize 1  "authorize 0.32.0" 
+.TH canon-adapter-authorize 1  "authorize 0.33.0" 
 .SH NAME
 canon\-adapter\-authorize \- Authorize declared capabilities against repository policy (preflight only)
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print help
 \fB\-V\fR, \fB\-\-version\fR
 Print version
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-adapter-validate.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-adapter-validate 1  "validate 0.32.0" 
+.TH canon-adapter-validate 1  "validate 0.33.0" 
 .SH NAME
 canon\-adapter\-validate \- Read and validate one provider\-neutral response envelope
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print help
 \fB\-V\fR, \fB\-\-version\fR
 Print version
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-adapter.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-adapter 1  "adapter 0.32.0" 
+.TH canon-adapter 1  "adapter 0.33.0" 
 .SH NAME
 canon\-adapter \- Validate a provider\-neutral adapter response without executing a provider
 .SH SYNOPSIS
@@ -43,4 +43,4 @@ Examples:
   canon adapter validate \-\-response response.json
   canon adapter validate \-\-response response.json \-\-repo . \-\-json
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-artifacts-move.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-artifacts-move 1  "move 0.32.0" 
+.TH canon-artifacts-move 1  "move 0.33.0" 
 .SH NAME
 canon\-artifacts\-move \- Move the local artifact blobs to an object\-store tier, verify them, and remove the local copies
 .SH SYNOPSIS
@@ -54,10 +54,10 @@ Examples:
   canon artifacts move \-\-tier cold
   canon artifacts move \-\-tier cold \-\-commit \-\-plan\-digest <DIGEST>
 
-The bare run previews: it lists every upload and removal and prints a planDigest, and writes nothing. \-\-commit \-\-plan\-digest acts on exactly that plan (PLAN_CHANGED, exit 2, when it changed since).
+The bare run previews: it lists every upload and removal and prints a planDigest, and writes nothing. \-\-commit \-\-plan\-digest acts on exactly that plan (PLAN_STALE, exit 2, when it changed since).
 
 \-\-tier names an `s3` tier of canon.yaml\*(Aqs `tiers:` (for example `cold`; its credentials are the tier\*(Aqs own). Every blob in .canon/artifacts/sha256 is hashed, uploaded under <prefix>sha256/<digest> (prefix artifacts/), and read back; only when all of them verified does canon.yaml gain `artifact_store: { backend: <tier>, prefix: artifacts/ }`, after which the local copies are removed and `.canon/artifacts/` is added to .gitignore. Commit the removal with the ledger.
 
 Idempotent and resumable: a run stopped anywhere leaves a repo the gate still passes, and the next run finishes; a second run finds nothing to do. A blob whose bytes do not match its name is never moved. Moving back to local is refused; `\-\-tier local` on a local repo is a no\-op.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-artifacts-store.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-artifacts-store 1  "store 0.32.0" 
+.TH canon-artifacts-store 1  "store 0.33.0" 
 .SH NAME
 canon\-artifacts\-store \- Store the bound files of existing evidence records and current reviews in the artifact store (.canon/artifacts/sha256/)
 .SH SYNOPSIS
@@ -51,4 +51,4 @@ For records written before canon stored bound bytes (0.11\-0.13), and for any ev
 
 Exit 0 when the pass ran (the gate decides whether an unstored file matters), 2 when the ledger cannot be read or a write fails.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-artifacts-verify.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-artifacts-verify 1  "verify 0.32.0" 
+.TH canon-artifacts-verify 1  "verify 0.33.0" 
 .SH NAME
 canon\-artifacts\-verify \- Check that the artifact store holds every file the latest evidence and current reviews bind (\-\-full re\-hashes the stored bytes)
 .SH SYNOPSIS
@@ -45,4 +45,4 @@ Asks the store canon.yaml\*(Aqs `artifacts:` block selects (default: local, .can
 
 Exit 0 when every file is stored, 1 when one is missing or altered (data.problems names each), 2 when the store cannot be used or reached: an unreachable store is a refusal, never a pass.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-artifacts.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-artifacts 1  "artifacts 0.32.0" 
+.TH canon-artifacts 1  "artifacts 0.33.0" 
 .SH NAME
 canon\-artifacts \- Check or move the evidence artifact store (local, or an object\-store tier)
 .SH SYNOPSIS
@@ -42,4 +42,4 @@ Store the bound files of existing evidence records and current reviews in the ar
 canon\-artifacts\-move(1)
 Move the local artifact blobs to an object\-store tier, verify them, and remove the local copies
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-brief-approve.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-brief-approve 1  "approve 0.32.0" 
+.TH canon-brief-approve 1  "approve 0.33.0" 
 .SH NAME
 canon\-brief\-approve \- Record the human\*(Aqs approval of the brief, bound to its text; refused while `brief check` has blockers
 .SH SYNOPSIS
@@ -71,4 +71,4 @@ brief (the digest covers the brief without its `Approved:` lines) and records
 not approved (BRIEF_CHANGED_SINCE_APPROVAL) until a human answers again and this
 runs again. Run it only from the human\*(Aqs answer, with their words as \-\-note.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-brief-check.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-brief-check 1  "check 0.32.0" 
+.TH canon-brief-check 1  "check 0.33.0" 
 .SH NAME
 canon\-brief\-check \- Read the brief against the rules: blocker and advisory findings (exit 0 clean, 1 blockers, 2 refused)
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print version
 [\fICHANGE_ID\fR]
 The change to read (default: the repo\*(Aqs only live change)
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-brief-show.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-brief-show 1  "show 0.32.0" 
+.TH canon-brief-show 1  "show 0.33.0" 
 .SH NAME
 canon\-brief\-show \- Show where the change stands and the next one to three steps; never edits
 .SH SYNOPSIS
@@ -50,4 +50,4 @@ Examples:
 
 The operand names the change; without it the repo\*(Aqs only live change is read.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-brief.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-brief 1  "brief 0.32.0" 
+.TH canon-brief 1  "brief 0.33.0" 
 .SH NAME
 canon\-brief \- Check a change\*(Aqs brief (PRD format) and see the next steps; never edits
 .SH SYNOPSIS
@@ -61,4 +61,4 @@ gets one blocker, `brief.old\-format`: `canon migrate` rewrites it. A brief
 with fewer than two known headings (written before 0.19) checks as `brief.legacy`, an
 advisory. Without \-\-change, the repo\*(Aqs only live change is checked.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-change-new.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-change-new 1  "new 0.32.0" 
+.TH canon-change-new 1  "new 0.33.0" 
 .SH NAME
 canon\-change\-new \- Write .canon/changes/<slug>/brief.md, import it, and adopt it into a subject
 .SH SYNOPSIS
@@ -63,4 +63,4 @@ Print version
 <\fICHANGE_ID\fR>
 The change\*(Aqs slug (its change_id)
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-change.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-change 1  "change 0.32.0" 
+.TH canon-change 1  "change 0.33.0" 
 .SH NAME
 canon\-change \- Write a plan change (.canon/changes/<slug>/brief.md) and adopt it into a subject
 .SH SYNOPSIS
@@ -39,4 +39,4 @@ Write .canon/changes/<slug>/brief.md, import it, and adopt it into a subject
 Examples:
   canon change new add\-login \-\-subject auth \-\-title \*(AqAdd login\*(Aq
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-completion.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-completion 1  "completion 0.32.0" 
+.TH canon-completion 1  "completion 0.33.0" 
 .SH NAME
 canon\-completion \- Write the shell completion script for canon (bash, zsh or fish)
 .SH SYNOPSIS
@@ -57,4 +57,4 @@ Examples:
 
 The script is generated from the command tree, so it completes exactly what the parser accepts. It needs no repo and no network.
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-context-pack-add.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-context-pack-add 1  "add 0.32.0" 
+.TH canon-context-pack-add 1  "add 0.33.0" 
 .SH NAME
 canon\-context\-pack\-add \- Create an immutable context pack from a repository\-local JSON manifest
 .SH SYNOPSIS
@@ -44,4 +44,4 @@ Print help
 \fB\-V\fR, \fB\-\-version\fR
 Print version
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-context-pack-show.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-context-pack-show 1  "show 0.32.0" 
+.TH canon-context-pack-show 1  "show 0.33.0" 
 .SH NAME
 canon\-context\-pack\-show \- Show a context pack after verifying its manifest and content objects
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print version
 <\fIPACK_ID\fR>
 Context pack id (sha256:<64 hex digits>)
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-context-pack-verify.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-context-pack-verify 1  "verify 0.32.0" 
+.TH canon-context-pack-verify 1  "verify 0.33.0" 
 .SH NAME
 canon\-context\-pack\-verify \- Verify a context pack\*(Aqs manifest and immutable content objects
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print version
 <\fIPACK_ID\fR>
 Context pack id (sha256:<64 hex digits>)
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-context-pack.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-context-pack 1  "context-pack 0.32.0" 
+.TH canon-context-pack 1  "context-pack 0.33.0" 
 .SH NAME
 canon\-context\-pack \- Create, inspect, and verify reproducible context packs
 .SH SYNOPSIS
@@ -47,4 +47,4 @@ Examples:
   canon context\-pack show sha256:<pack\-digest> \-\-repo . \-\-json
   canon context\-pack verify sha256:<pack\-digest>
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-context.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-context 1  "context 0.32.0" 
+.TH canon-context 1  "context 0.33.0" 
 .SH NAME
 canon\-context \- Show what you can author here: record kinds, fields, enums, policies
 .SH SYNOPSIS
@@ -41,4 +41,4 @@ Print help
 \fB\-V\fR, \fB\-\-version\fR
 Print version
 .SH VERSION
-v0.32.0
+v0.33.0

package/man/canon-dashboard.1

@@ -1,6 +1,6 @@
 .ie \n(.g .ds Aq \(aq
 .el .ds Aq '
-.TH canon-dashboard 1  "dashboard 0.32.0" 
+.TH canon-dashboard 1  "dashboard 0.33.0" 
 .SH NAME
 canon\-dashboard \- Serve the local status dashboard
 .SH SYNOPSIS
@@ -47,4 +47,4 @@ Print help
 \fB\-V\fR, \fB\-\-version\fR
 Print version
 .SH VERSION
-v0.32.0
+v0.33.0