@journeykit/canon 0.35.0 → 0.36.0

package/dist/skills/SKILL.src.md

@@ -49,15 +49,15 @@ a feature, a one-line request included. A human is needed once per scope:
      `canon brief approve <slug> <slug> --approver <their name> --note "<their words>" --relayed-via <ask|AskUserQuestion|chat> --actor <your actor id> --digest <slug>=<digest shown>`
      (one or more slugs, each with its own `--digest`, one answer for all, nothing written if any is refused).
      The `Approved:` line then carries `(relayed by <role> <actor> via <tool>)`.
-     A digest that no longer matches the brief is `RELAY_DIGEST_MISMATCH`: show
-     it again. Without `--relayed-via` an agent role gets `HUMAN_ONLY`, and so
+     A digest that no longer matches the brief is `RELAY_DIGEST_STALE`: show
+     it again. Without `--relayed-via` an agent role gets `ACTOR_DENIED`, and so
      does a repo whose `canon.yaml` says `approval: { relay: deny }`: then the
      human runs the call themselves. Never remove or unset your role
      (`env -u CANON_ROLE`, dropping `--as`) to run it yourself.
   Never edit the policy to make the gate pass: a policy that differs from
-  the approved one fails closed (`POLICY_CHANGED_SINCE_APPROVAL`, not
+  the approved one fails closed (`POLICY_APPROVAL_STALE`, not
   waivable); stop and ask the human. A brief edited after its
-  approval is not approved (`BRIEF_CHANGED_SINCE_APPROVAL`): it needs a new
+  approval is not approved (`BRIEF_APPROVAL_STALE`): it needs a new
   answer. The ship guard and `canon evidence add` refuse an unapproved or
   edited brief, but those are backstops: the stop itself is at step 1.
 - **Approval is scoped.** Evidence for a scenario tagged `@flow:<change>.<F-id>`
@@ -120,7 +120,7 @@ the record carries, so a review of a working tree survives the commit made
 from it; a review is judged by what it pins (the scenario and what its
 evidence says), never by the commit or the code tree. Outside a git work
 tree, or in a repo with no commits, a command that needs a commit refuses
-`NO_COMMIT`.
+`COMMIT_REQUIRED`.
 
 ### Evidence follows the code
 
@@ -181,7 +181,7 @@ names the stores not read.
 
 canon cannot detect a role; you declare it. Pass `--as <role>` or set
 `CANON_ROLE=planner|implementer|reviewer|orchestrator`; a flag wins over the
-variable, and an unknown value is refused (`UNKNOWN_ROLE`).
+variable, and an unknown value is refused (`ROLE_INVALID`).
 
 - **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`
@@ -211,17 +211,27 @@ A role is guidance, not enforcement: `--role` on `evidence add` and
   your complete command set, every option of every leaf included. Run `canon schema <command> --json` only for a
   command it does not list, or after a `USAGE` refusal (read `error.field`
   and `error.expected` first). `canon schema --json` is the tree of every group and command
-  with its `effect` and `x-canon.roles` (`--as <role>` lists one role's, and `x-canon.as` names it); `canon schema <group> --json` lists a group's
-  commands; `canon schema <command> --json` is one command in full: `options` (each with
-  `valueType`, a typed `default`, `possibleValues`, `env`, `flagOnly`), `errors`, `outputs`
-  with the JSON Schema of each report in `schemas`, `input` (the schema of one `--input`
-  document and a complete `example`) and `examples`. The first line of every `--help`
-  points at it.
+  with its `effect` and `x-canon.roles` (`--as <role>` lists one role's, and `x-canon.as` names it);
+  its `options` define once the options that two or more commands share (`--repo`, `--as`, `--actor`, …)
+  and a command names them. `canon schema <group> --json` lists a group's
+  commands; `canon schema <command> --json` is the call surface of one command and nothing
+  else: `options` (each name of a tree option, or an object with `valueType`, a typed
+  `default`, `possibleValues`, `env`, `flagOnly`), `operands`, `constraints`, `validators`, `errors`,
+  `outputs`, `input` (what one `--input` document is and a complete `example`) and `examples`.
+  A member at its default is absent. `--json` is always accepted, `--input` when the command
+  has `input`, `--fields` when an output has `fields`, and the codes `USAGE` (with canon's
+  finer `*_INVALID`/`*_REQUIRED` argument codes), `INTERNAL`, `INPUT_*`, `BATCH_INCOMPLETE`,
+  `PLAN_STALE` (with `--commit`) and `CURSOR_INVALID` (with `--cursor`) can come without
+  being listed. `--commit` and `--plan-digest` are listed on exactly the commands that offer
+  them: a command that lists `commit` previews on a bare run. `canon schema <command> --schemas --json`
+  gives the JSON Schema of each report in `schemas`, `Input` (the schema of one `--input`
+  document) and `rejects` (what each validator refuses, in order); `#/schemas/<Name>` in
+  the command document resolves there. The first line of every `--help` points at it.
 - 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 `tool`, `toolVersion`, `contract` (`atip/1`),
-  `contractVersion` (`1.2`), `schemaVersion`,
+  `contractVersion` (`1.4`), `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 value you sent empty comes back as `received: ""`).
@@ -243,7 +253,7 @@ A role is guidance, not enforcement: `--role` on `evidence add` and
 - **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).
+  `CONFIG_REQUIRED`, 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` (`data.unchanged`), not duplicated.
@@ -258,13 +268,13 @@ A role is guidance, not enforcement: `--role` on `evidence add` and
   has blockers; the approval step appears only when the brief is clean and
   unapproved.
 - Page long lists with `--limit <n>` and `--cursor <nextCursor>` (`--all`
-  for everything); a cursor holds only for the call that issued it, so change nothing but `--limit`, `--all`, `--fields` and `--json`, and keep `CANON_ROLE` as it was (`CURSOR_INVALID` with `error.reason` `ARGUMENTS_CHANGED` otherwise; `FOREIGN` for a cursor of another command or another canon version: start again from the first page). `--limit`, `--cursor`, `--all` and `--fields` are flags: an `--input` document key of that name is `INPUT_INVALID` with `reason` `FLAG_ONLY_KEY`. Project fields with `--fields a,b`
+  for everything); a cursor holds only for the call that issued it, so change nothing but `--limit`, `--all`, `--fields` and `--json`, and keep `CANON_ROLE` as it was; the next call is `meta.next[0].argv` as it stands (the arguments you gave and the cursor, never a default). An argument you add is a change even when it states the default (`--repo .`): canon binds an explicit default to the cursor (`CURSOR_INVALID` with `error.reason` `ARGUMENTS_CHANGED`, `error.field` `--cursor`; `FOREIGN` for a cursor of another command or another canon version: start again from the first page). `--limit`, `--cursor`, `--all` and `--fields` are flags: an `--input` document key of that name is `INPUT_INVALID` with `reason` `FLAG_ONLY_KEY`. Project fields with `--fields a,b`
   (`status`, `export`, `query`, `finding list`, `divergence list`, `context`): the paths `canon schema <command> --json` lists under `outputs[].fields`, spelled as the answer spells them; `meta.fields` lists what was kept.
 - `--override-reason <text>` is the only way to proceed past a waivable
   refusal; it is recorded, echoed in `data.overrides[]` and listed by `status`
   for the human. There is no `--force`. `brief approve`, `policy approve`,
   `divergence accept` and the `migrate --commit` that re-binds `Approved:`
-  lines record a human's decision and refuse every agent role (`HUMAN_ONLY`)
+  lines record a human's decision and refuse every agent role (`ACTOR_DENIED`)
   unless they record the explicit answer the human gave you, with
   `--relayed-via <tool>` (show, ask, record, as for the brief; `canon skills
   show role-planner`); never unset your role to run one.
@@ -281,8 +291,8 @@ before anything is written, and that check reads no state: an invalid element wr
 its own code, `error.field` pointing at `/<i>/<key>` and no `data`. An element that fails when it runs (the object
 it names does not exist) stops the batch: exit 1, `BATCH_INCOMPLETE`, `error.field` exactly `/<i>`, the element
 `failed` with its own `error` (no `data`), the later ones `skipped`, and the earlier ones done (not undone). 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; a document with several problems reports them all, the first as the error and every one in `error.details` in the order the document wrote its keys, and a value outside a closed set is `INPUT_INVALID` too (`reason` `INVALID_VALUE`, `field` the key), not `USAGE`. Every non-empty line of an NDJSON file is a document (a `#` line is not a comment). Integers compare by number: `1`, `"1"` and `--round +1` are one value, and `"+1"`, `"0x1"` and `1.0` in a document are `INVALID_VALUE`.
-`canon schema <command> --json` shows the leaf's `input`: the schema of one document and a complete `example`.
+`unchanged`. A typo in a key is refused (`INPUT_INVALID`, `field` naming the key), never dropped; a document with several problems reports them all, the first as the error (`field` is the first `error.details` entry's) and every one in `error.details` in the order the document wrote its keys, and a value outside a closed set is `INPUT_INVALID` too (`reason` `INVALID_VALUE`, `field` the key), not `USAGE`. Every non-empty line of an NDJSON file is a document (a `#` line is not a comment). Integers compare by number: `1`, `"1"` and `--round +1` are one value, `"+1"`, `"0x1"` and `1.0` in a document are `INVALID_VALUE`, and an integer beyond ±9007199254740991 is refused as a number and as a string, in a document (`INVALID_VALUE`, `field` its pointer) and on the command line (`USAGE`). `--input` may give a required option and the command line only the operand; an option given in both with different values is `INPUT_CONFLICT` at the key's pointer. A repeatable option's none is the key left out: `[]` is refused (`INPUT_INVALID`, `reason` `INVALID_VALUE`, `field` the key's pointer), as is `[]` for any other option and for `operands`.
+`canon schema <command> --json` shows the leaf's `input` (what one document is, and a complete `example`); `canon schema <command> --schemas --json` gives `Input`, the JSON Schema of one document.
 
 ```text
 canon scenario new --input '[{"operands":["auth.login.01"],"title":"Logs in","case":"happy"},{"operands":["auth.login.02"],"title":"Wrong password","case":"failure"}]'
@@ -338,7 +348,7 @@ canon init --providers=claude,codex
 canon skills install
 # any subset or none; rewrites skills.providers
 canon skills install --providers=claude,codex,omp,pi
-# read-only drift check; exit 1 (SKILLS_DRIFT) names each orphan, a projected file the bundle no longer ships
+# read-only drift check; exit 1 (SKILLS_CHECK_FAILED) names each orphan, a projected file the bundle no longer ships
 canon skills check
 # diagnostics, incl. a stray canon projection for an unselected provider and a projection a formatter rewrote, and `orphan:` lines for projected files the bundle no longer ships; never deletes user files
 canon skills doctor

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

@@ -114,8 +114,9 @@ Fix it and the next command indexes the files (see `canon-inventory`).
 Many scenarios at once: `--input` takes inline JSON, a file or `-`. An
 array (or NDJSON) is a batch, validated whole before anything is written;
 each element holds `operands` (the scenario tag) and the other options as
-camelCase keys. `canon schema scenario new --json` shows `input`: the schema of one document
-and a complete `example`. There is no `--from`.
+camelCase keys. `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. There is no `--from`.
 
 ```text
 canon scenario new --input '[{"operands":["checkout.cart.01"],"title":"Adding an item raises the count","subject":"checkout-core","lane":"behavior","case":"happy"},{"operands":["checkout.cart.04"],"title":"Adding an out-of-stock item is refused","subject":"checkout-core","lane":"behavior","case":"failure"}]'

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

@@ -28,7 +28,7 @@ Every violation carries one of these stable, grep-able strings:
 | `malformed-evidence` | A candidate record doesn't parse, is misfiled, or carries an unparseable interim tag. Malformed evidence is no evidence. |
 | `flagged` | The human-only `flagged` overlay is set — never green regardless of passing evidence. |
 | `unevidenced-flip` | `canon task done <task_id>` was asked to flip a checkbox with no matching, non-`Divergent` evidence record. |
-| `fabricated-evidence` | An evidence note contains a blocklisted marker (`"would pass"`, `"TBD"`, `"n/a"`) standing as a whole word — never inside a path, a file name, a URL or a longer word, so `pack.json/atlas` is not `n/a` — or a bare `verified` claim with no attached command result. `canon evidence add` refuses such a note before writing (refused with `fabricated-evidence`, exit 1). |
+| `fabricated-evidence` | An evidence note contains a blocklisted marker (`"would pass"`, `"TBD"`, `"n/a"`) standing as a whole word — never inside a path, a file name, a URL or a longer word, so `pack.json/atlas` is not `n/a` — or a bare `verified` claim with no attached command result. `canon evidence add` refuses such a note before writing (refused with `fabricated-evidence`, `EVIDENCE_NOTE_INVALID`, exit 2). |
 | `open-blocker` | With `spec_coverage.require_review` set (and `block_on_findings`, the default), a Finding whose latest version is severity `blocker`, disposition `open`, on a change an in-scope subject adopted — or closed `fixed` while an evidenced scenario of the subject has no evidence recorded after the close (re-verification). Subject string `<change_id>#<round>.<seq>`. See `canon-review`. |
 | `false-success` | The latest audit record (`canon evidence audit`) of a scenario says `refuted`: an external evaluator found a counterexample to the claimed success. Always on, regardless of policy or sampling, and takes precedence over any declared faithful verdict; only a newer audit (`confirmed` or `indeterminate`) clears it. The detail names the evaluator, its version, its sha256 and the counterexample paths. |
 
@@ -225,9 +225,9 @@ canon divergence accept cart.add.01 --project root --reason "known gap" --tracki
 
 Accepting a scenario whose latest evidence is `divergent` as a known gap
 limited by something outside the change is a human-only act: with a role
-declared (`--as`, `CANON_ROLE`) the leaf is refused with `HUMAN_ONLY`. It is
+declared (`--as`, `CANON_ROLE`) the leaf is refused with `ACTOR_DENIED`. It is
 never a way to skip a fix.
-Refused (`DIVERGENCE_ACCEPT_REFUSED`) unless the latest verdict is
+Refused (`DIVERGENCE_CONFLICT` when the evidence is not divergent, `DIVERGENCE_DENIED` when the actor or session attested it) unless the latest verdict is
 divergent and the session and actor differ from the evidence's. The record
 pins that evidence: new evidence for the scenario, or `--expiry` passing,
 ends it. While it holds, the ship guard counts the cell covered and
@@ -304,10 +304,10 @@ never rides along into a confirming audit. `--drop-attachment` and
 The approval is never assumed: the agent writes the brief, shows it to the
 human and asks, and builds nothing for that scope until the human answers.
 `canon evidence add` is the backstop for that rule (0.16 M7). It
-refuses (exit `1`, nothing staged or stored) while a subject the record
+refuses (exit `2`, nothing staged or stored) while a subject the record
 attests for has an enforced, unapproved brief: a change the record
 answers to (below) has a canon `.canon/changes/<change>/brief.md` with no `Approved:`
-line, was edited after its approval (`BRIEF_CHANGED_SINCE_APPROVAL`), or
+line, was edited after its approval (`BRIEF_APPROVAL_STALE`), or
 there is no canon `brief.md` yet but the change comes from an
 external openspec plan with a `proposal.md` under the plan sources (the
 check `canon status` and the ship guard use; see
@@ -461,7 +461,7 @@ mentions. Each bound case is its own attachment with its name and
 outcome. `--report-case <name>` (repeatable; a Rust test by its
 function name) ADDS cases; it never hides the scenario's own. No match,
 or a `--report-case` naming no case, refuses (exit 2); a `faithful`
-verdict when ANY bound case failed or was skipped refuses (exit 1). Files
+verdict when ANY bound case failed or was skipped refuses (exit 2). Files
 must be inside the repository, are recorded by relative path, and are
 stored (see Bound evidence stays provable).
 
@@ -517,8 +517,9 @@ report (a JUnit test case's `[[ATTACHMENT|path]]` lines, which Playwright's
 JUnit reporter writes; a Cucumber JSON embedding), so a test's screenshot
 stays with its scenario. A file the report does not name goes with
 `--artifact <scenario-id>=<path>`; a bare `--artifact <path>` in a batch is
-refused (`EVIDENCE_INVALID_ARGUMENT`). A report attachment that is missing,
-outside the repo or oversized is refused.
+refused (`EVIDENCE_ARGUMENT_CONFLICT`). A report attachment that is missing,
+outside the repo or oversized is refused (`EVIDENCE_BINDING_NOT_FOUND`,
+`EVIDENCE_BINDING_DENIED`, `EVIDENCE_BINDING_INVALID`).
 
 It is all or nothing: a claimed `faithful` verdict over a failed case,
 a fabrication marker in `--summary`, an unapproved brief for any
@@ -536,13 +537,14 @@ or `-`; an array (or NDJSON) is a batch, validated element by element before
 the first write (a refusal writes nothing, exit 2). Keys are the option
 names in camelCase plus `operands`: one object per scenario, with
 `scenario`, `class`, `ref` and `role`. `canon schema evidence add --json`
-shows `input`: the schema of one document and a complete `example`. Each element reports `written`,
+shows `input` (its limits and a complete `example`) and `canon schema evidence add --schemas --json`
+gives `Input`, the schema of one document. Each element reports `written`,
 `unchanged` or `failed` in `data.items[]`.
 
 `--rev <rev>` names the commit the evidence ran against (default `HEAD`).
 Evidence for uncommitted code is recorded with its `codeTree` and
 `worktreeDirty`; outside git, or with no commit, the add is refused with
-`NO_COMMIT`.
+`COMMIT_REQUIRED`.
 
 **Done when:** `canon gate check` shows no violation for the scenarios you
 recorded evidence for; each record's own output line says whether it was
@@ -697,7 +699,7 @@ aggregates every record bound to the task, on one line:
 (the latest `--summary`, or a default naming the latest passing record).
 Every other path — missing evidence, a `Divergent` verdict, a fabricated
 note on any of the task's records — leaves the row byte-unchanged and
-exits `1` with the blocking violation on stderr. After a flip, the plan
+exits `2` with the blocking violation on stderr. After a flip, the plan
 source is re-ingested so the record store's task status agrees with the
 checkbox (`canon query --kind task` reads `done`); a failed re-ingest is
 a stderr warning naming `canon ingest plans`, never a failed flip.
@@ -734,7 +736,7 @@ Staging → committed: every well-formed record under
 applies, assigned a monotonic per-(role, surface) `run_seq` (gap-free
 within one invocation, continuing from the committed max), and moved into
 the committed ledger. A malformed or unpartitionable candidate is refused
-— exit `1`, no `run_seq` consumed, the file left in place. `--dry-run`
+— exit `2` (`PROMOTION_INVALID`; several are `error.details[]`), no `run_seq` consumed, the file left in place. A refusal carries no `data`. `--dry-run`
 prints the plan (target path + assigned `run_seq` per candidate) without
 writing or deleting.
 
@@ -789,8 +791,10 @@ It installs no git hook: copy the script into git's `pre-commit` hook
 agent hook files and the script, also under `--dry-run`. In `--json`,
 `installed` is true when an agent hook file changed and
 `preCommitScriptWritten` when the script was written. A `--repo` that is not an
-existing directory exits 2 with `HOOKS_INSTALL_FAILED` (also under `--dry-run`)
-and creates nothing.
+existing directory exits 2 with `HOOKS_REPO_INVALID` (also under `--dry-run`)
+and creates nothing. When the install writes the first hook file and then cannot
+write the second, it exits 1 with `HOOKS_INSTALL_INCOMPLETE`: the first file
+stays, `meta.next` leads with `canon status`, then run the install again.
 
 Prefer this over hand-editing `settings.json`/`hooks.json`.
 

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

@@ -164,7 +164,9 @@ specs:
   whole root aborts, 0 writes, violations reported.
 - **A root on the pre-0.17 layout** (a `.feature` file under
   `<root>/features/`) → a `layout-grammar` violation at path `features`;
-  the root aborts, 0 writes, exit 1. Run `canon migrate`. An empty
+  the root aborts, 0 writes, exit 2 (`INVENTORY_INVALID`, each violation in
+  `error.details`; exit 1 `INVENTORY_INCOMPLETE` when an earlier root was
+  indexed first). Run `canon migrate`. An empty
   leftover `features/` directory is not a refusal.
 - **A duplicate `scenario_id`** within one root → that root aborts, 0
   writes, reported as a sync error (a distinct lane from fmt violations).

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

@@ -76,7 +76,7 @@ A human approves the policy after reviewing `.canon/policy.yaml`, in the
 same answer that approves a subject's brief (0.16; see the skill's working
 loop). `canon brief approve` records both in one call. `canon policy
 approve` is a human's decision: with a role declared (`--as` or `CANON_ROLE`)
-it is refused with `HUMAN_ONLY` (exit 2, not retryable) unless it records the
+it is refused with `ACTOR_DENIED` (exit 2, not retryable) unless it records the
 answer the human gave in the conversation: show them `.canon/policy.yaml`, ask,
 and on an explicit approval run it (the steps are in `canon skills show role-planner`) with `--relayed-via <tool>`, `--actor`,
 `--approver` and `--note` (their name and words); the file then carries `relay`
@@ -117,8 +117,8 @@ unreviewed-promotion policy — policy changed since approval: .canon/policy.yam
 ```
 
 `canon gate check` exits `1`; `canon subject move` (the ship guard and
-the reopen) refuses with `POLICY_CHANGED_SINCE_APPROVAL`, or
-`POLICY_APPROVAL_UNREADABLE` for an unreadable approval, and
+the reopen) refuses with `POLICY_APPROVAL_STALE`, or
+`POLICY_APPROVAL_CORRUPT` (or `POLICY_APPROVAL_DENIED` when the file may not be read) for a broken approval, and
 `--override-reason` does not waive either. A policy never approved stays
 an advisory. `canon status` prints the same text as a `warning:` line (and
 in `--json` `warnings`). The record names who approved which bytes and

package/dist/skills/reference/canon-report-dashboard.md

@@ -143,7 +143,7 @@ canon dashboard --snapshot /tmp/canon-snap --port 8080
 - Runs in any repo: the released binary carries the app (in canon's own
   checkout a built `packages/dashboard/dist` is used instead). It prints the
   panels URL and a briefs URL (`/briefs.html`), then serves until Ctrl-C.
-  A taken port fails with `DASHBOARD_PORT_IN_USE`: pass `--port <n>` or
+  A taken port fails with `DASHBOARD_PORT_UNAVAILABLE`: pass `--port <n>` or
   `--port 0`.
 - Without the `duckdb` CLI on `PATH` the server still runs; the panels page
   says why there is no snapshot and how to get one (it never shows demo
@@ -160,11 +160,11 @@ answer once and clicks Approve: one request carries every selected brief with
 the sha256 of the file the page read, and records exactly what `canon brief
 approve <id>+ --approver <name> --note <text>` records, the `Approved:` line
 bound to the brief digest and the policy approval, for each. A brief that
-changed after the page loaded (`BRIEF_CHANGED_SINCE_PAGE_LOAD`) or that has
-blockers refuses the whole request (409 `BRIEF_APPROVE_REFUSED`, naming each
-refused brief): nothing is written and the page says to read it again. A request
+changed after the page loaded (`BRIEF_PAGE_STALE`) or that has
+blockers refuses the whole request (409, the first refused brief's own code such as `BRIEF_INVALID`, with an
+`error.details` entry for each refused brief): nothing is written and the page says to read it again. A request
 naming one brief the old way (`changeId`, `sha256`) is still accepted. The server is localhost only and
-refuses requests from other origins (`DASHBOARD_ORIGIN_REFUSED`).
+refuses requests from other origins (`DASHBOARD_REQUEST_DENIED`).
 
 For an agent: when clean briefs are waiting, show them (`canon brief show
 <slug> --body`), ask with the harness question tool, and tell the human they

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

@@ -89,7 +89,7 @@ in the JSON. Give the reason when you reject or defer: it is the only record
 of why the finding was not fixed.
 
 `--scenario` (repeatable, each a scenario the index knows; refused with
-`FINDING_UNKNOWN_SCENARIO` otherwise) names the scenarios the finding is
+`SCENARIO_NOT_FOUND` otherwise) names the scenarios the finding is
 about. After a `fixed` close, fresh evidence for those scenarios alone
 re-verifies the fix; a finding naming none asks every evidenced scenario of
 the subject, as before. `finding close` copies the list.
@@ -116,14 +116,15 @@ needs it or `--introduced-unknown` (never both). A revision that names no
 commit is refused (exit `2`). A finding recorded against uncommitted code
 is allowed: the record carries the `codeTree` it saw and `worktreeDirty`.
 Outside git, or in a repository with no commit, the write is refused with
-`NO_COMMIT`.
+`COMMIT_REQUIRED`.
 
 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 `input`: the schema of one document and a complete `example`. An identical
+finding add --json` shows `input` (its limits and a complete `example`) and `canon schema finding add
+--schemas --json` gives `Input`, the schema of one document. An identical
 repeat is `unchanged` (`data.unchanged`) and writes nothing; a different
-finding under an occupied key is `FINDING_SEQ_OCCUPIED`.
+finding under an occupied key is `FINDING_EXISTS`.
 
 ### A defect the author found in its own work
 
@@ -197,7 +198,7 @@ saw (the tree with `.canon/`, the spec roots and `code.exclude` removed), and
 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
+with no commit, the write is refused with `COMMIT_REQUIRED`. An identical review
 written again is `unchanged` (`data.unchanged` under `--json`) and adds no
 record.
 
@@ -475,7 +476,7 @@ stderr: canon subject move: review guard for building → verifying (spec_covera
 
 A target status outside the scope prints `skipped unreviewed-promotion —
 `specced` is not in require_review.scope`. A transition into an in-scope
-status with gaps prints the violations, exits 1, leaves the record
+status with gaps prints the violations, exits 2, leaves the record
 unchanged, and names `--override-reason`.
 
 `--override-reason "<one line>"` waives ONLY `unreviewed-promotion` and

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

@@ -295,7 +295,7 @@ answer; without it init takes the harnesses whose
 `.claude`, `.codex`, `.omp` or `.pi` directory exists, and with none detected
 it writes only a commented example
 and installs nothing. `.agents` alone never selects Codex. `canon skills
-install|check|doctor` follow the section; `install` prunes projected files the bundle no longer ships when their bytes match the lock (a modified one stays, reported as `kept:`), `check` exits 1 (`SKILLS_DRIFT`) naming each orphan and `doctor` prints `orphan:` lines; `canon skills install
+install|check|doctor` follow the section; `install` prunes projected files the bundle no longer ships when their bytes match the lock (a modified one stays, reported as `kept:`), `check` exits 1 (`SKILLS_CHECK_FAILED`) naming each orphan and `doctor` prints `orphan:` lines; `canon skills install
 --providers=<list>` rewrites it in place. Without the section they use the
 install lock's providers, then the detected ones; nothing undetected is ever
 added. A present section that is not this shape, or names another harness,
@@ -395,7 +395,7 @@ so a killed commit never leaves it held, and the file is removed only by a
 call that made it to take the lock and then ended refused (a refusal leaves
 no file and no `.git/info/exclude` line behind). A
 command that waited 30 s for it starts nothing: it exits `2` with
-`REPO_WRITE_BUSY` (retryable; run it again in a moment). The first
+`REPO_LOCK_UNAVAILABLE` (retryable; run it again in a moment). The first
 call that needs the lock makes the file, in any repository.
 
 ## What `canon init` keeps out of git

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;
@@ -549,7 +550,7 @@ warn, and a command that writes and judges it is refused
   `Approved: <who> <when> — "<words>" (brief sha256:<digest>)` into the
   brief 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`.
 
@@ -619,7 +620,7 @@ uses, so status and the gate cannot disagree about a gap:
   `Approved: <who> <when> — "<the human's words>" (brief sha256:<digest>)`,
   the digest covering the brief without its `Approved:` lines. 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