@journeykit/canon 0.35.0 → 0.37.0

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

@@ -71,7 +71,8 @@ canon subject new subject-domain-loop \
   subjects at once: `--input` takes inline JSON, a file or `-`; an array (or
   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 `input`: the schema of one document and a complete `example`). Writing an identical subject
+  new --json` shows `input`, its limits and a complete `example`; `canon schema subject new --schemas --json`
+  gives `Input`, the schema of one document). Writing an identical subject
   again is a no-op reported `unchanged` (`data.unchanged`).
 
 ### 2. Retrieve subject-scoped strategy memory BEFORE working
@@ -137,7 +138,7 @@ canon subject move subject-domain-loop --to shipped
 
 On success the status updates in place; `--json` prints the updated
 record. On a gate block it prints violations by failure class to stderr,
-exits 1, and the record is unchanged.
+exits 2 (the code names the condition: `SUBJECT_APPROVAL_REQUIRED`, `EVIDENCE_STALE`, `LAYOUT_MIGRATION_REQUIRED` or `SUBJECT_INVALID`; several causes are `error.details[]`), and the record is unchanged.
 
 **Corpus-wide, the same join:** `canon gate check` with
 `.canon/policy.yaml`'s opt-in `spec_coverage` section generalizes this
@@ -166,7 +167,7 @@ from shipping, until every evidenced scenario has evidence recorded after
 the close or the approval; the refusal names the scenarios and the
 `canon evidence add --all-scenarios` command. Each refusal prints by
 failure class (`uncovered-cell`), carries a `hint`,
-exits 1, and the status stays `verifying`. `retired` is not gated.
+exits 2, and the status stays `verifying`. `retired` is not gated.
 
 **The brief (0.16, 0.17, 0.19):** `verifying → shipped` also refuses where a brief
 exists and is not approved, read exactly as `canon status` reads it (one
@@ -174,7 +175,7 @@ shared check, so status says `ship` only when this passes): the subject's
 scope (every change the subject answers for, see below) has a canon `.canon/changes/<change>/brief.md`
 with no `Approved:` line outside HTML comments and code fences, whose
 `Approved:` line carries a digest the brief's text no longer matches
-(`BRIEF_CHANGED_SINCE_APPROVAL`; the brief was edited after the human
+(`BRIEF_APPROVAL_STALE`; the brief was edited after the human
 answered), or has no canon `brief.md` yet but comes from an external
 openspec plan with a `proposal.md` under the plan sources. It also
 refuses while `canon brief check` has blocker findings for that change,
@@ -184,7 +185,7 @@ a policy. The refusal is an `unreviewed-promotion` naming the subject, and
 says what to do:
 
 ```output
-output: canon subject move: SUBJECT_GATE_VIOLATION — unreviewed-promotion demo-subject — verifying → shipped: brief not approved — .canon/changes/c-demo/brief.md has no `Approved:` line; a human must answer the brief, and only from that answer the agent will record their words with `canon brief approve c-demo --approver <the human> --note "<their words>"`
+output: canon subject move: SUBJECT_INVALID — unreviewed-promotion demo-subject — verifying → shipped: brief not approved — .canon/changes/c-demo/brief.md has no `Approved:` line; a human must answer the brief, and only from that answer the agent will record their words with `canon brief approve c-demo --approver <the human> --note "<their words>"`
 output: canon subject move: refused — get the human's answer to the brief and record it with `canon brief approve`, or pass --override-reason <text> to move anyway; the waiver is recorded on the subject
 ```
 
@@ -211,7 +212,7 @@ This refusal is a backstop, and so is the evidence one: shipping is not
 the first thing an unapproved brief stops. The agent writes the brief,
 runs `canon brief check` until it has no blockers, then shows it to the
 human and asks, and nothing is built or attested for the subject until the human
-answers. `canon evidence add` refuses (exit 1, nothing staged) a
+answers. `canon evidence add` refuses (exit 2, nothing staged) a
 scenario whose `@subject` owner, or a task whose change
 an adopting subject, has an enforced, unapproved brief, through the same
 check; see `canon-gate`.
@@ -223,7 +224,7 @@ check; see `canon-gate`.
 edited since, and even if the tags were removed; or (3) a *chore*, which has
 no scenario to tag and so governs from the moment it is adopted. They pass
 only when every one of them reads as approved now; an unapproved one and one
-edited after its approval (`BRIEF_CHANGED_SINCE_APPROVAL`) are named for
+edited after its approval (`BRIEF_APPROVAL_STALE`) are named for
 different reasons, and the answer does not depend on the order the changes
 were adopted or approved. The ship guard's brief-structure check runs over
 all of them. When several block, the hint is one
@@ -245,7 +246,7 @@ answers only to the changes its tags name (counting only changes the subject
 adopted); another change's edit after its approval never blocks it. An untagged
 scenario (one whose tags were removed reads the same) answers to every adopted
 change with an `Approved:` line, a chore included, so an approved change edited
-since refuses it (`BRIEF_CHANGED_SINCE_APPROVAL`); an unapproved chore blocks
+since refuses it (`BRIEF_APPROVAL_STALE`); an unapproved chore blocks
 reopen and ship, never evidence. When no adopted change has an approved line,
 a scenario with evidence recorded before the subject first adopted a change
 (and without a brief override) needs no brief, and one without answers to the
@@ -270,7 +271,7 @@ A target outside `require_review.scope` prints `skipped
 unreviewed-promotion — `specced` is not in require_review.scope`. A
 transition INTO an in-scope status with gaps — an owned scenario with no
 qualifying review (`unreviewed-promotion`), or an open blocker finding
-on an adopted change (`open-blocker`) — prints the violations, exits 1,
+on an adopted change (`open-blocker`) — prints the violations, exits 2,
 leaves the record unchanged, and names `--override-reason`. `shipped`
 also refuses a `false-success` (a scenario whose latest audit is
 `refuted`) and, when `require_audit.scope` covers `shipped`, an owed
@@ -332,14 +333,14 @@ output: canon subject move: demo-subject → verifying — written directly; not
 - Inside the approved scope it needs no human: every change the subject
   answers for (tagged, approved or chore) has an approved brief, or there
   is no brief to answer.
-  Otherwise it refuses, exit 1, naming the brief to approve, and
+  Otherwise it refuses, exit 2, naming the brief to approve, and
   `--override-reason` does not waive it:
   ``unreviewed-promotion demo-subject — shipped → verifying: reopening needs the approved scope, and the brief is not approved — .canon/changes/c-next/brief.md has no `Approved:` line; …``.
 - The review guard does not run on a reopen (it prints `skipped … — a
   reopen moves the subject back to fix its gaps; shipping again runs
   it`). `verifying → shipped` afterwards runs every guard above again.
-- A policy that fails closed (`POLICY_CHANGED_SINCE_APPROVAL`,
-  `POLICY_APPROVAL_UNREADABLE`: see `canon-policy`) refuses the reopen and
+- A policy that fails closed (`POLICY_APPROVAL_STALE`,
+  `POLICY_APPROVAL_CORRUPT`, `POLICY_APPROVAL_DENIED`: see `canon-policy`) refuses the reopen and
   the ship, and `--override-reason` does not waive it.
 - `canon change new` on a shipped subject prints the reopen command
   (`canon subject move <id> --to verifying --reason "<why it reopens>"`)
@@ -422,7 +423,7 @@ canon subject unadopt <S> --change <change> --json
 
 Removes the link on both records and keeps the change and its brief, so the
 draft can be adopted elsewhere (a `proposed` holding subject, say) while the
-live subject keeps shipping. It is refused with `SUBJECT_UNADOPT_REFUSED`
+live subject keeps shipping. It is refused with `SUBJECT_CONFLICT` (reason `APPROVED_BRIEF` or `FLOW_TAGGED`)
 for a change whose brief carries an `Approved:` line, and while a scenario
 the subject owns carries a `@flow:<change>.*` tag (it would fall back to an
 older approval; remove or retag those scenarios first, the hint names them);
@@ -509,12 +510,12 @@ same answer and one timestamp on every brief and on the policy approval
 (0.31). Every slug is checked before anything is written (a brief that
 exists and reads, no blocker, a one-line name and answer, a body that does not
 end inside an open code fence); one refused slug refuses the call, exit 2
-`BRIEF_APPROVE_REFUSED` naming each refused slug with its own code, and
-nothing is written. A repeated slug counts once. With one slug the output is as
+with the first refused slug's own code (`BRIEF_INVALID`, `BRIEF_NOT_FOUND`) and an
+`error.details` entry for each refused slug, and nothing is written. A repeated slug counts once. With one slug the output is as
 before; with several, `--json` carries one entry per slug (`written`,
 `unchanged`, `failed`, `skipped`). A disk error while writing exits 1 and
 leaves the slugs already written approved. The call is human-only for every
-slug; the `HUMAN_ONLY` hint gives the human one line with all the slugs.
+slug; the `ACTOR_DENIED` hint gives the human one line with all the slugs.
 
 Without the change operand, the repo's only live change is read. The brief is the
 PRD `canon change new` writes; sections are found by their English `##`
@@ -524,7 +525,7 @@ before. A brief with `<!-- canon:… -->` comments or Korean headings is in the
 0.30 format: `brief check` gives it one blocker (`brief.old-format`) and
 `canon migrate` rewrites it; `status`, `gate check`, `context` and `brief show`
 warn, and a command that writes and judges it is refused
-(`OLD_BRIEF_FORMAT`).
+(`BRIEF_MIGRATION_REQUIRED`).
 
 - **Blockers (structure, `brief.*`)**: a missing, duplicated or
   out-of-order section; a flow with no steps or a duplicate step id;
@@ -546,10 +547,11 @@ warn, and a command that writes and judges it is refused
   `reason`), one rule in one section, reason required; add `match` to waive
   only the findings whose matched text contains it. Listed in the output.
 - **`approve`** records the human's answer: it writes
-  `Approved: <who> <when> — "<words>" (brief sha256:<digest>)` into the
-  brief and records the policy approval in the same call. It refuses
+  `Approved: <who> <when> — "<words>" (code tree <id>) (brief sha256:<digest>)`
+  into the brief (the code tree, 0.37, is the work tree's as it is now and is
+  left out outside git or with no commit) and records the policy approval in the same call. It refuses
   (exit 2) while the check has structure blockers. Edit the brief
-  afterwards and every reader says `BRIEF_CHANGED_SINCE_APPROVAL` until a
+  afterwards and every reader says `BRIEF_APPROVAL_STALE` until a
   human answers again and `approve` runs again. Run it only from the
   human's answer, with their words as `--note`.
 
@@ -616,10 +618,10 @@ uses, so status and the gate cannot disagree about a gap:
   something after it, and sits outside HTML comments (`<!-- … -->`,
   multi-line included) and fenced code blocks (```` ``` ```` or `~~~`).
   `canon brief approve` writes it from the human's answer, as
-  `Approved: <who> <when> — "<the human's words>" (brief sha256:<digest>)`,
-  the digest covering the brief without its `Approved:` lines. A brief
+  `Approved: <who> <when> — "<the human's words>" (code tree <id>) (brief sha256:<digest>)`,
+  the digest covering the brief without its `Approved:` lines (the tree marker is outside it; a line without one is read as before). A brief
   edited after that reads `brief: not approved (<brief> changed after its
-  approval (BRIEF_CHANGED_SINCE_APPROVAL))` and names the re-approval
+  approval (BRIEF_APPROVAL_STALE))` and names the re-approval
   command: the changed brief needs a new human answer. A line with no
   digest (written before 0.19) stays approved, with an `advisory:` to
   re-approve so it binds to the text. Fixes and follow-ups

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

@@ -10,7 +10,7 @@ build nothing meanwhile. The only waiver is `--override-reason
 the human's answer: canon records it on the evidence, echoes it in
 `data.overrides[]` and lists it in `status` for the human. Never use it to
 skip the wait yourself. `brief approve`, `policy approve` and `divergence
-accept` are the human's; they refuse you (`HUMAN_ONLY`) unless they record an
+accept` are the human's; they refuse you (`ACTOR_DENIED`) unless they record an
 answer the human gave in the conversation (`--relayed-via`, the planner's
 procedure: `canon skills show role-planner`). You never run them without that
 answer, and never remove or unset your role (`env -u CANON_ROLE`, dropping
@@ -25,7 +25,7 @@ in your ids. Use only the options on a line; never guess one. Ask `canon schema
 <command> --json` only for a leaf this block does not list, or after a `USAGE` refusal.
 
 <!-- canon:generated commands-implementer begin -->
-Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
+Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array; none is the key left out, `[]` is refused), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
 A `usage:` line shows the syntax and is not itself a command to run (the runnable example under it is): `<X>` is a value, `[x]` optional, `a | b` a choice, `(a | b)` exactly one is required, `[--x <V>]*` may repeat, `<X>+` is one or more, `[--a --b <V>]` go together. An option that is not on the line does not exist: it is refused (`USAGE`).
 
 ```text
@@ -177,7 +177,7 @@ canon scenario new auth.login.02 --title "Sign out" --feature .canon/specs/kind=
 ```
 ```text
 # Describe canon's own commands
-usage: canon schema [<PATH>]* [--errors | --error <CODE> | --warning <CODE> | --warnings]
+usage: canon schema [<PATH>]* [--schemas | --error <CODE> | --errors | --warning <CODE> | --warnings]
 ```
 ```bash
 canon schema evidence add --json
@@ -224,7 +224,7 @@ After the first `status`, follow `meta.next` of each write; do not call
 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
-repo with no commits, a write that needs a commit refuses `NO_COMMIT`.
+repo with no commits, a write that needs a commit refuses `COMMIT_REQUIRED`.
 
 The forms you reach for most (the story's ids; swap in yours):
 
@@ -253,7 +253,7 @@ canon evidence add --input '[{"scenario":"auth.login.01","class":"test-run","ref
    keys are the option names in camelCase plus `operands` (the scenario id);
    every element is validated before the first write, so a bad element
    writes nothing and `error.field` names it (`/1/case`).
-   `canon schema scenario new --json` shows `input`: the schema of one document and a complete `example`.
+   `canon schema scenario new --json` shows `input` (its limits and a complete `example`); `canon schema scenario new --schemas --json` gives `Input`, the schema of one document.
    (`scenario new --from` is gone.) When the gate asks for a missing case
    (`require_cases`), add a new scenario; never retag an existing one. Every
    bug fix adds or extends a scenario. Canon indexes added, edited or deleted
@@ -342,7 +342,9 @@ canon evidence add --input '[{"scenario":"auth.login.01","class":"test-run","ref
    latest evidence was recorded on a different `codeTree` than the current
    code (`code.exclude` in `canon.yaml` decides what is not code; the default
    is `docs/**` and `*.md`). A docs-only chore needs its change-level review
-   alone. When code did change, the shipping refusal, `status` and
+   alone, and so does a chore whose approval recorded the code tree that is
+   still the current one (`(code tree <id>)` in its `Approved:` line; `status`
+   says so): it asks for no evidence at all. When code did change, the shipping refusal, `status` and
    `meta.next` lead with one command over every report, with the real paths
    (`--project <id>` is added only with several spec roots):
    `canon evidence add --all-scenarios --report junit:a.xml --report junit:b.xml --role implementer`.

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

@@ -4,7 +4,7 @@ You run the loop across agents and move the subject. You write no brief,
 code or review yourself. Declare the role with `CANON_ROLE=orchestrator` (or
 `--as orchestrator`); your `canon status` also lists the human's steps. The
 human's acts (`brief approve`, `policy approve`, `divergence accept`) refuse
-every agent role, you included (`HUMAN_ONLY`), unless you record the answer the
+every agent role, you included (`ACTOR_DENIED`), unless you record the answer the
 human gave you in the conversation with `--relayed-via <tool>` (below). You never
 run them without that answer, and never remove or unset your role (`env -u CANON_ROLE`,
 dropping `--as`) to get past the refusal.
@@ -18,7 +18,7 @@ in your ids. Use only the options on a line; never guess one. Ask `canon schema
 <command> --json` only for a leaf this block does not list, or after a `USAGE` refusal.
 
 <!-- canon:generated commands-orchestrator begin -->
-Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `regime show`, `schema`, `selftest`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
+Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `regime show`, `schema`, `selftest`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array; none is the key left out, `[]` is refused), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
 A `usage:` line shows the syntax and is not itself a command to run (the runnable example under it is): `<X>` is a value, `[x]` optional, `a | b` a choice, `(a | b)` exactly one is required, `[--x <V>]*` may repeat, `<X>+` is one or more, `[--a --b <V>]` go together. An option that is not on the line does not exist: it is refused (`USAGE`).
 
 ```text
@@ -37,8 +37,8 @@ canon adapter validate --response adapter-response.json --json
 ```
 ```text
 # Move the local artifact blobs to an object-store tier, verify them, and remove the local copies
-usage: canon artifacts move --tier <TIER> [--commit --plan-digest <DIGEST>] [--input]
-# a bare run previews and prints planDigest; `--commit --plan-digest <DIGEST>` with that digest acts
+usage: canon artifacts move --tier <TIER> [--commit --plan-digest <PLAN_DIGEST>] [--input]
+# a bare run previews and prints planDigest; `--commit --plan-digest <PLAN_DIGEST>` with that digest acts
 ```
 ```bash
 canon artifacts move --tier cold --json
@@ -220,16 +220,16 @@ canon inventory sync --json
 ```
 ```text
 # Move superseded versions of every record out of the ledger into the archive
-usage: canon ledger compact [--commit --plan-digest <DIGEST>] [--input]
-# a bare run previews and prints planDigest; `--commit --plan-digest <DIGEST>` with that digest acts
+usage: canon ledger compact [--commit --plan-digest <PLAN_DIGEST>] [--input]
+# a bare run previews and prints planDigest; `--commit --plan-digest <PLAN_DIGEST>` with that digest acts
 ```
 ```bash
 canon ledger compact --json
 ```
 ```text
 # Bring a repo from an earlier canon up to date
-usage: canon migrate [--commit --plan-digest <DIGEST>] [--revert | --relayed-via <NAME>] [--backup <DIR> (with --revert)] [--actor <ACTOR_ID> (with --relayed-via)] [--approver <NAME> (with --relayed-via)] [--note <TEXT> (with --relayed-via)] [--input]
-# a bare run previews and prints planDigest; `--commit --plan-digest <DIGEST>` with that digest acts
+usage: canon migrate [--commit --plan-digest <PLAN_DIGEST>] [--revert | --relayed-via <NAME>] [--backup <DIR> (with --revert)] [--actor <ACTOR_ID> (with --relayed-via)] [--approver <NAME> (with --relayed-via)] [--note <TEXT> (with --relayed-via)] [--input]
+# a bare run previews and prints planDigest; `--commit --plan-digest <PLAN_DIGEST>` with that digest acts
 ```
 ```bash
 canon migrate --json
@@ -264,8 +264,8 @@ canon prompt show reviewer@v1 --json
 ```
 ```text
 # Remove allowlisted records older than a cutoff
-usage: canon purge --kind <session|run|event|trajectory> --before <TIMESTAMP> [--commit --plan-digest <DIGEST>] [--input]
-# a bare run previews and prints planDigest; `--commit --plan-digest <DIGEST>` with that digest acts
+usage: canon purge --kind <session|run|event|trajectory> --before <TIMESTAMP> [--commit --plan-digest <PLAN_DIGEST>] [--input]
+# a bare run previews and prints planDigest; `--commit --plan-digest <PLAN_DIGEST>` with that digest acts
 ```
 ```bash
 canon purge --kind session --before 2020-01-01T00:00:00Z --json
@@ -314,7 +314,7 @@ canon retrieve --for-role reviewer --domain dev --limit 20 --json
 ```
 ```text
 # Describe canon's own commands
-usage: canon schema [<PATH>]* [--errors | --error <CODE> | --warning <CODE> | --warnings]
+usage: canon schema [<PATH>]* [--schemas | --error <CODE> | --errors | --warning <CODE> | --warnings]
 ```
 ```bash
 canon schema evidence add --json
@@ -426,8 +426,8 @@ canon subject unadopt demo --change add-login --json
 ```
 ```text
 # Apply canon.yaml aging rules, moving old records to their destination tier
-usage: canon tier age [--commit --plan-digest <DIGEST>] [--input]
-# a bare run previews and prints planDigest; `--commit --plan-digest <DIGEST>` with that digest acts
+usage: canon tier age [--commit --plan-digest <PLAN_DIGEST>] [--input]
+# a bare run previews and prints planDigest; `--commit --plan-digest <PLAN_DIGEST>` with that digest acts
 ```
 ```bash
 canon tier age --json
@@ -527,16 +527,16 @@ Approve or fill the form. On their approval record it: `canon brief approve
 <ask|AskUserQuestion|chat> --actor <your actor id> --digest <slug>=<the digest
 shown>` (several slugs take one answer, each with its own `--digest`; nothing is written
 if one is refused). The record says you recorded it, with your role, actor and
-tool. `RELAY_DIGEST_MISMATCH` means the brief changed after they saw it: show it
+tool. `RELAY_DIGEST_STALE` means the brief changed after they saw it: show it
 again. When `canon.yaml` has `approval: { relay: deny }` the call is refused
-(`HUMAN_ONLY`, naming the key): report the human's own call and wait for them to
+(`ACTOR_DENIED`, naming the key): report the human's own call and wait for them to
 run it. Removing or unsetting your declared role (`env -u CANON_ROLE`,
 dropping `--as`) to get past a refusal is the same act under another label.
 `canon skills show role-planner` has the full procedure. Do not start the
 implementer before `canon brief show <slug>` reports `state: approved`.
 Never approve it yourself and never edit the policy to pass the gate. A
 policy that no longer matches the approval fails closed
-(`POLICY_CHANGED_SINCE_APPROVAL`, or `POLICY_APPROVAL_UNREADABLE`): the ship
+(`POLICY_APPROVAL_STALE`, or `POLICY_APPROVAL_CORRUPT`): the ship
 guard and the reopen refuse, and `--override-reason` does not waive it. Run
 `canon policy show`, then show the policy to the human, ask them to re-approve
 and record their explicit answer (`canon policy approve --approver <their name>
@@ -576,7 +576,7 @@ its preview, never from an old digest.
 
 | The thought | The reality |
 |---|---|
-| "Edit the policy so the gate passes." | A changed policy fails closed (`POLICY_CHANGED_SINCE_APPROVAL`); ask the human to re-approve or restore it from git. |
+| "Edit the policy so the gate passes." | A changed policy fails closed (`POLICY_APPROVAL_STALE`); ask the human to re-approve or restore it from git. |
 | "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. |
@@ -591,7 +591,8 @@ directly (a transition is a state change, not a destructive act) and is not
 repeatable: a move to the state the subject is already in is refused
 (exit 2), so after a lost response read `subject show` before you retry.
 It refuses a move the policy does not allow (missing evidence or reviews,
-open blockers, an unapproved brief) with `SUBJECT_GATE_VIOLATION` and exit 1,
+open blockers, an unapproved brief) with exit 2 and the code of the condition
+(`SUBJECT_APPROVAL_REQUIRED` for a missing review, evidence or approval, `EVIDENCE_STALE`, `SUBJECT_INVALID` for the rest; several causes are `error.details[]`),
 the record unchanged; fix the gap rather than overriding. Move to `shipped`
 yourself once its guard passes, unless the brief says the human ships. A
 follow-up on a shipped subject goes back to `verifying` with `--reason`,
@@ -614,7 +615,7 @@ red. A bad `--to` fails with `error.field` `--to` and `error.expected`
 listing the states.
 
 **Done when:** `canon subject show demo` (the subject's id) reports the
-state you moved it to and `canon gate check` is clean; when the move exits 1,
+state you moved it to and `canon gate check` is clean; when the move exits 2,
 read the refusal in `error` of `canon subject move demo --to shipped --json`.
 
 ## Destructive commands preview first
@@ -629,7 +630,7 @@ digits, over the effects and what the plan read, so a file or record the plan
 read that changed since is `PLAN_STALE` too, and `meta.next[0]` is the preview
 to run again. A commit holds the repository write lock for its whole run:
 another command that writes waits for it, and one that waited 30 seconds
-answers `REPO_WRITE_BUSY` (exit 2, retryable): run it again. A document passed
+answers `REPO_LOCK_UNAVAILABLE` (exit 2, retryable): run it again. A document passed
 with `--input` never carries `--commit` or `--plan-digest`, and these five
 leaves take one object only (`INPUT_INVALID`).
 
@@ -675,7 +676,7 @@ canon skills install
    moves: commit first. In CI run it with full history (`fetch-depth: 0`).
 3. `canon skills install` refreshes the stub and the scripts for the selected
    harnesses; `canon skills check` reports a skill written by another canon
-   version (exit 1, `SKILLS_DRIFT`), `canon skills doctor` explains it.
+   version (exit 1, `SKILLS_CHECK_FAILED`), `canon skills doctor` explains it.
 
 Commit what it changes, except the backup: `.canon/migrate-backup/` is local and
 git-ignored, and `canon migrate --revert` needs it (keep it until you are sure).

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

@@ -6,7 +6,7 @@ brief the human answers once. You build nothing. Declare the role with
 then show your steps and count the rest under `waitingOn`. The approvals are
 the human's: `brief approve`, `policy approve`, `divergence accept` and the
 `migrate --commit` that re-binds `Approved:` lines refuse every agent role
-(`HUMAN_ONLY`, `retryable: false`) unless you record the answer the human gave
+(`ACTOR_DENIED`, `retryable: false`) unless you record the answer the human gave
 you in the conversation, with `--relayed-via <tool>` (step 4). Without a human's
 explicit answer you never run them, and you never remove or unset your role
 (`env -u CANON_ROLE`, dropping `--as`) to get past the refusal.
@@ -20,7 +20,7 @@ in your ids. Use only the options on a line; never guess one. Ask `canon schema
 <command> --json` only for a leaf this block does not list, or after a `USAGE` refusal.
 
 <!-- canon:generated commands-planner begin -->
-Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
+Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array; none is the key left out, `[]` is refused), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
 A `usage:` line shows the syntax and is not itself a command to run (the runnable example under it is): `<X>` is a value, `[x]` optional, `a | b` a choice, `(a | b)` exactly one is required, `[--x <V>]*` may repeat, `<X>+` is one or more, `[--a --b <V>]` go together. An option that is not on the line does not exist: it is refused (`USAGE`).
 
 ```text
@@ -116,7 +116,7 @@ canon scenario new auth.login.02 --title "Sign out" --feature .canon/specs/kind=
 ```
 ```text
 # Describe canon's own commands
-usage: canon schema [<PATH>]* [--errors | --error <CODE> | --warning <CODE> | --warnings]
+usage: canon schema [<PATH>]* [--schemas | --error <CODE> | --errors | --warning <CODE> | --warnings]
 ```
 ```bash
 canon schema evidence add --json
@@ -183,7 +183,7 @@ lists N blockers`); then, while prose advisories remain, to the polish pass
 (`polish the brief in <path> (canon skills show brief-polish), then run canon
 brief check <slug>`, with the advisory count and the top rule
 ids); the human step comes after it. A policy that no longer matches its approval fails closed
-(`POLICY_CHANGED_SINCE_APPROVAL`): never edit it; the human re-approves.
+(`POLICY_APPROVAL_STALE`): never edit it; the human re-approves.
 
 ## Steps
 
@@ -286,9 +286,9 @@ ids); the human step comes after it. A policy that no longer matches its approva
    show` and the dashboard name it. Never approve in their name without their
    answer, never write the answer for them, and never edit the policy to make
    the gate pass. A digest that differs from the brief now
-   (`RELAY_DIGEST_MISMATCH`) means the brief changed after they saw it: show
+   (`RELAY_DIGEST_STALE`) means the brief changed after they saw it: show
    it again and ask again; nothing was written. Without `--relayed-via` the call is
-   `HUMAN_ONLY`; with it and no role declared, `USAGE`. When `canon.yaml`
+   `ACTOR_DENIED`; with it and no role declared, `USAGE`. When `canon.yaml`
    turns relaying off (`approval: { relay: deny }`), the refusal names that key:
    report the human's call (`canon brief approve add-login --approver <their
    name> --note "<their own words>"`) and wait for them to run it. Never
@@ -300,7 +300,7 @@ ids); the human step comes after it. A policy that no longer matches its approva
    evidence with its reason and tracking reference, the migrate plan), ask,
    count only an explicit approval, then record with the relay option.
    `canon brief show <slug>` then reports `state: approved`. A brief edited
-   after its approval is not approved (`BRIEF_CHANGED_SINCE_APPROVAL`): it
+   after its approval is not approved (`BRIEF_APPROVAL_STALE`): it
    needs a new answer, shown and asked again, and a new `brief approve`. A follow-up that
    adds or changes a step of the brief is a scope change and needs a new
    answer.

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

@@ -3,7 +3,7 @@
 You are the independent second look. Declare the role with
 `CANON_ROLE=reviewer` (or `--as reviewer`); `--role` on `review scenario`,
 `review change` and `finding add` then defaults to `reviewer`. The human's
-acts refuse you (`HUMAN_ONLY`): `brief approve`, `policy approve` and
+acts refuse you (`ACTOR_DENIED`): `brief approve`, `policy approve` and
 `divergence accept`, unless you record the answer the human gave you in the
 conversation with `--relayed-via <tool>` (the divergence acceptance below).
 Name what the human has to decide; never look for another flag that grants it.
@@ -19,7 +19,7 @@ in your ids. Use only the options on a line; never guess one. Ask `canon schema
 <command> --json` only for a leaf this block does not list, or after a `USAGE` refusal.
 
 <!-- canon:generated commands-reviewer begin -->
-Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
+Every leaf takes `--as <ROLE>` and `--json`; `--repo <DIR>` too, except `completion`, `schema`, `skills show`. `--input <JSON|FILE|->` runs a leaf from one JSON document (an array is a batch) and is only on the lines ending `[--input]`. Its document keys are the option names in camelCase, singular even when the option repeats (the value is then an array; none is the key left out, `[]` is refused), and `operands` holds the operands. `--fields <FIELDS>` is a comma list of the paths `canon schema <COMMAND> --json` declares under `outputs[].fields.paths`; a path is the record's own key, spelled as the answer spells it.
 A `usage:` line shows the syntax and is not itself a command to run (the runnable example under it is): `<X>` is a value, `[x]` optional, `a | b` a choice, `(a | b)` exactly one is required, `[--x <V>]*` may repeat, `<X>+` is one or more, `[--a --b <V>]` go together. An option that is not on the line does not exist: it is refused (`USAGE`).
 
 ```text
@@ -87,7 +87,7 @@ canon finding add --change add-login --round 1 --seq 2 --severity should-fix --i
 ```
 ```text
 # Move an already-committed finding's disposition
-usage: canon finding close <CHANGE_ID> --round <N> --seq <N> --disposition <open|fixed|rejected|deferred> [--resolution-rev <REV>] [--reason <TEXT>] [--actor <ACTOR_ID>] [--role <ROLE>] [--session <SESSION_ID>] [--promote | --no-promote] [--input]
+usage: canon finding close <CHANGE_ID> --round <N> --seq <N> --disposition <fixed|rejected|deferred> [--resolution-rev <REV>] [--reason <TEXT>] [--actor <ACTOR_ID>] [--role <ROLE>] [--session <SESSION_ID>] [--promote | --no-promote] [--input]
 ```
 ```bash
 canon finding close add-login --round 1 --seq 1 --disposition rejected --reason "works as designed" --json
@@ -143,7 +143,7 @@ canon review scenario auth.login.01 --actor alice --role reviewer --original-spe
 ```
 ```text
 # Describe canon's own commands
-usage: canon schema [<PATH>]* [--errors | --error <CODE> | --warning <CODE> | --warnings]
+usage: canon schema [<PATH>]* [--schemas | --error <CODE> | --errors | --warning <CODE> | --warnings]
 ```
 ```bash
 canon schema evidence add --json
@@ -288,7 +288,7 @@ sign.
 `divergence accept` is for a scenario whose honest evidence is `divergent`
 and whose gap is limited by something outside this change (an upstream
 limit, a platform bug) and is tracked there. It records a human's decision,
-so it refuses every agent role (`HUMAN_ONLY`), you included, unless it records
+so it refuses every agent role (`ACTOR_DENIED`), you included, unless it records
 the answer the human gave you. What you do: confirm the evidence really is
 divergent and the limit is outside this change, then put to the human the
 scenario ids, the reason, the tracking reference and an expiry when the limit
@@ -297,11 +297,11 @@ Ask with the harness question tool (`ask` in omp, `AskUserQuestion` in Claude
 Code, otherwise in the chat): accept the gap, or not. Only an explicit
 approval counts; a question or a condition is not one, and no answer records
 nothing. Then record it from a session that did not attest the evidence
-(`DIVERGENCE_ACCEPT_REFUSED` otherwise): `canon divergence accept <ids> --actor
+(`DIVERGENCE_DENIED` otherwise): `canon divergence accept <ids> --actor
 <your actor id> --reason "<why>" --tracking <ref> --approver <their name> --note
 "<their answer>" --relayed-via <tool>`; the record carries the relay, the
 approver and their answer. When `canon.yaml` has `approval: { relay: deny }` the
-call is refused (`HUMAN_ONLY`, naming the key) and the human runs it themselves.
+call is refused (`ACTOR_DENIED`, naming the key) and the human runs it themselves.
 You never unset your role to run it. Never suggest it to skip
 a fix the implementer can make in this change. The acceptance pins that
 evidence: new evidence for the scenario, or its expiry, ends it, and the
@@ -358,7 +358,7 @@ implementer owns. Your last write's `meta.next` names the next step.
 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
+(`FINDING_EXISTS`): take the next seq. `finding close` with the same
 disposition is a no-op too.
 
 ## Excuses that fail

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.35.0" 
+.TH canon-adapter-authorize 1  "authorize 0.37.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.35.0
+v0.37.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.35.0" 
+.TH canon-adapter-validate 1  "validate 0.37.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.35.0
+v0.37.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.35.0" 
+.TH canon-adapter 1  "adapter 0.37.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.35.0
+v0.37.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.35.0" 
+.TH canon-artifacts-move 1  "move 0.37.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
@@ -30,10 +30,10 @@ orchestrator
 The tier to move to: the name of an `s3` tier in canon.yaml (for example `cold`)
 .TP
 \fB\-\-commit\fR
-Act on the previewed plan; needs \-\-plan\-digest
+Make the change; without it the command only previews.
 .TP
-\fB\-\-plan\-digest\fR \fI<DIGEST>\fR
-The `planDigest` the preview printed; the run acts only if the plan recomputed now has this digest
+\fB\-\-plan\-digest\fR \fI<PLAN_DIGEST>\fR
+The digest of the preview this commit carries out.
 .TP
 \fB\-\-repo\fR \fI<DIR>\fR
 The repo to act on (default: the nearest ancestor directory holding a canon.yaml)
@@ -52,7 +52,7 @@ Print version
 .SH EXTRA
 Examples:
   canon artifacts move \-\-tier cold
-  canon artifacts move \-\-tier cold \-\-commit \-\-plan\-digest <DIGEST>
+  canon artifacts move \-\-tier cold \-\-commit \-\-plan\-digest <PLAN_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_STALE, exit 2, when it changed since).
 
@@ -60,4 +60,4 @@ The bare run previews: it lists every upload and removal and prints a planDigest
 
 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.35.0
+v0.37.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.35.0" 
+.TH canon-artifacts-store 1  "store 0.37.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.35.0
+v0.37.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.35.0" 
+.TH canon-artifacts-verify 1  "verify 0.37.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.35.0
+v0.37.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.35.0" 
+.TH canon-artifacts 1  "artifacts 0.37.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.35.0
+v0.37.0