@journeykit/canon 0.17.0 → 0.18.0

package/dist/skills/SKILL.src.md

@@ -36,6 +36,14 @@ a feature, a one-line request included. A human is needed once per scope:
   stays in the approved change: add it as tasks in that change's
   `tasks.md`, never with `canon change new`, because a new change is a new
   scope and needs the human's approval.
+- **A follow-up on a shipped subject reopens it.** Reopen it with
+  `canon subject status <id> verifying --reason "<why>" --actor-id <unit>`
+  (no human inside the approved scope; the reason and your id are
+  recorded), add the follow-up as tasks in the approved change's
+  `tasks.md`, then its scenario, evidence and an independent review, and
+  ship again with `canon subject status <id> shipped`, which runs every
+  guard again. `canon status` flags a shipped subject whose gate went red
+  and names the reopen.
 
 When no human can answer one of the brief's questions, write the question
 into the brief, state the assumption you will build on, and say so in your
@@ -59,6 +67,9 @@ work inside an approved scope, never to the approval itself.
    `canon change new <slug> --subject <id> --title "…"`, and put the brief in
    the `.canon/changes/<slug>/brief.md` it writes. For a new subject or a
    scope change, this is where you stop until the human answers (step 1).
+   A change that also serves another subject is adopted there too,
+   `canon subject adopt <slug> --subject <other>`: it then belongs to both,
+   and its open blockers gate both.
 3. **Scenarios.** `canon feature new <area>.<surface> --title "…"`, then one
    `canon scenario new <area>.<surface>.<nn> --subject <id> --case <case> --title "…"`
    per behavior, with failure paths (`--case failure`) as well as `happy`
@@ -88,12 +99,20 @@ work inside an approved scope, never to the approval itself.
    `canon evidence add --project-id <root-id> --scenario-id <id> --kind test-run --role implementer --ref "<command>" --actor-id <unit> --session-id <session>`,
    with `--report junit:<path>` or `--artifact <path>` when files prove it.
    canon stores those bytes in `.canon/artifacts/sha256/` (commit it with the
-   ledger) and `canon gate check` re-checks them. For a scenario about what
+   ledger) and `canon gate check` re-checks them; the bound copy is the one
+   kept, so the working-tree report itself may be gitignored. For a scenario about what
    users see, bind the screenshot or recording that shows it
    (`--artifact <path>`). Under `write: { promote: auto }` (what
    `canon init` writes) the record is final when the command returns; only
    in a repo with `write.promote: manual` (or no `write:` key) follow it
    with `canon gate promote`.
+   One test run that proves several scenarios is bound once:
+   `canon evidence add --project-id <root-id> --all-scenarios --report <junit|cucumber|swift-testing>:<path> --kind test-run --role implementer --ref "<command>" --actor-id <unit> --session-id <session>`
+   writes one record per indexed scenario owning a case, each with the
+   verdict its own cases show; any refusal writes none. When a new record
+   makes a signed review stale, the add prints the reviewer and the
+   `canon review add … --pin <sha>` that re-pins it; the reviewer looks
+   again before running it.
    An external evaluator's audit is recorded with `canon evidence add --kind
    audit`; canon never generates one.
    Evidence for a plan task (`--task <id>`, before `canon gate task`) must
@@ -102,16 +121,24 @@ work inside an approved scope, never to the approval itself.
    change's `tasks.md` as it is now, so a task row you add needs no
    `canon ingest plans` first.
 7. **Independent review.** A different session from the one that wrote the
-   code and evidence reviews the change. The reviewer records every defect
+   code and evidence reviews the change. The review session must be able
+   to run the checks it signs off (the build, the tests, the app); a
+   reviewer that cannot run the tests says so and does not sign off. The
+   reviewer records every defect
    the review finds as a finding:
    `canon finding add --change-id <slug> --round <n> --seq <n> --severity <blocker|should-fix|note> --reviewer <me> --actor-id <me> --session-id <session> --summary "…"`;
+   `canon finding list --change-id <slug> [--open] [--json]` shows the
+   change's findings (round, seq, severity, disposition, reviewer, summary),
+   so the next seq and the open blockers are one command away;
    once fixed,
    `canon finding close --change-id <slug> --round <n> --seq <n> --disposition fixed --resolution-sha <sha>`
    (a short sha is fine; canon resolves it). With `write.promote: manual`,
    follow each with `canon gate promote`. Every bug fix adds or extends a scenario. The
    reviewer signs off each scenario:
    `canon review add --project-id <root-id> --scenario-id <id> --reviewer <who> --actor-id <who> --role reviewer --session-id <review-session> --pin <sha> --upstream-ref <ref>`
-   (written directly; nothing to promote). A reviewer of user-visible
+   (written directly; nothing to promote). Repeat `--scenario-id`, or pass
+   `--scenario-ids-from <file>`, to sign off several scenarios in one
+   call, all or nothing. A reviewer of user-visible
    behavior attaches what it looked at with `--artifact <path>`
    (repeatable); canon stores and re-checks those bytes and never compares
    images.
@@ -133,7 +160,10 @@ work inside an approved scope, never to the approval itself.
    `shipped` yourself once `canon subject status <id> shipped` passes its
    guard, unless the brief says the human ships. `canon status` shows
    whether each subject's brief is approved, by the same check, and names
-   the next step.
+   the next step. `shipped → verifying` reopens a shipped subject for a
+   follow-up (see the working loop above): it needs `--reason`, and it is
+   refused, naming the brief, when the subject's newest change is not
+   approved.
 
 Every write command says whether the record is final (`written directly`,
 or `staged and promoted in this run`) or staged; only a staged record
@@ -151,9 +181,17 @@ canon init --providers=claude,codex          # harnesses for the canon skill; wi
 canon skills install                         # follows canon.yaml skills.providers (else the install lock's, else the detected ones; none detected installs nothing)
 canon skills install --providers=claude,codex,omp,pi   # any subset or none; rewrites skills.providers
 canon skills check                           # read-only drift check
-canon skills doctor                          # diagnostics, incl. a stray canon projection for an unselected provider; never deletes user files
+canon skills doctor                          # diagnostics, incl. a stray canon projection for an unselected provider and a projection a formatter rewrote; never deletes user files
 ```
 
+`install` and `doctor` end with `owned-paths:`, the globs of every path
+canon writes. Add them to the repo's formatter and linter ignore lists; a
+formatter that rewrites a projection or a ledger record makes canon read
+drift. Specs, `policy.yaml` and the changes are written by hand and are not
+on the list. `doctor` reports a projection whose bytes changed
+but whose content did not as `formatter-rewritten` and names the ignore
+entry to add; a changed file stays `stale`.
+
 The harness list lives in `canon.yaml` as `skills: { providers: [...] }`.
 `.agents` alone never selects Codex; `.codex` does. Change the list with
 `canon skills install --providers=<list>`, never by assuming a default.

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 gate task <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"`) or a bare `verified` claim with no attached command result. |
+| `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 (`canon evidence add: refused — fabricated-evidence …`, exit 1). |
 | `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. Subject string `<change_id>#<round>.<seq>`. See `canon-review`. |
 | `false-success` | The latest audit record (`canon evidence add --kind 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. |
 
@@ -391,6 +391,8 @@ canon evidence add --scenario-id cart.add.04 --project-id root \
 # a JUnit XML or Cucumber JSON report: also records the matched case + outcome
 canon evidence add ... --report junit:target/nextest/default/junit.xml
 canon evidence add ... --report cucumber:reports/cucumber.json
+# a Swift Testing event stream (swift test --experimental-event-stream-output <path>)
+canon evidence add ... --report swift-testing:.build/events.jsonl
 ```
 
 A case is bound when the scenario id is its OWN: the first
@@ -408,6 +410,12 @@ verdict when ANY bound case failed or was skipped refuses (exit 1). Files
 must be inside the repository, are recorded by relative path, and are
 stored (see Bound evidence stays provable).
 
+A Swift Testing case is named by its display name (`@Test("cart.add.04
+refuses an out-of-stock item")`), else its function name
+(`cart_add_04_refuses()`). A test with a failing issue failed, a skipped
+test was skipped, a test that started and ended without one passed, and
+a test that started and never ended failed.
+
 Strength, weakest first: `attested` (no attachment) < `artifact` (any
 bound file) < `report` (a parsed report whose case passed). The policy
 decides whether the gate cares:
@@ -431,6 +439,55 @@ violation in every mode. Canon still cannot know whether the bound test
 actually exercises the scenario — binding narrows the trust gap, it does
 not close it.
 
+### One report, many scenarios (0.18)
+
+One test run proves many scenarios. Bind it once:
+
+```bash
+canon evidence add --project-id root --all-scenarios \
+  --report junit:target/nextest/default/junit.xml \
+  --kind test-run --ref "cargo nextest run" --role implementer
+```
+
+Each indexed scenario of `--project-id` that owns a case (the rule above)
+gets its own record, with only its own cases. Its verdict comes from
+them: `faithful` when every case passed, `divergent` when one failed,
+`not-applicable` when one was skipped and none failed. `--verdict <v>`
+claims the same verdict for every record instead. A case whose id is not
+indexed is named and skipped (`skipped <id> — not an indexed scenario`);
+a report no indexed scenario owns is refused (exit 2). The records share
+the stored report and every `--artifact`, and the output lists each
+scenario with its verdict on its own line.
+
+It is all or nothing: a claimed `faithful` verdict over a failed case,
+a fabrication marker in `--summary`, an unapproved brief for any
+scenario's subject, or a scenario whose latest record binds a file the
+batch does not refuses the whole batch, and nothing is written.
+`--scenario-id`, `--task`, `--report-case`, `--kind audit`,
+`--drop-attachment` and the approval flags name one subject and are
+refused with `--all-scenarios`.
+
+A task's evidence with `--report` and no `--scenario-id` binds EVERY case
+in the report, so a `faithful` verdict needs all of them to pass.
+
+### A write that makes a review stale says so (0.18)
+
+When new evidence (one record or a batch) supersedes the evidence a
+current pinned review saw, `canon evidence add` prints one line per
+review it makes stale, with the command that re-pins it:
+
+```
+canon evidence add: review by `reviewer-2` of cart.add.01 is now stale (it pinned the evidence this record supersedes); re-pin it: canon review add --project-id root --scenario-id cart.add.01 --reviewer reviewer-2 --actor-id reviewer-2 --role reviewer --pin <HEAD sha> --original-spec-ref specs/kind=feature/area=cart/add.feature
+```
+
+The decision is the gate's own (the same stale-review rule `canon gate
+check` reports). The command repeats the review's reviewer, actor, role,
+session, provenance ref, runtime labels and artifacts, pinned at `HEAD` (`<sha>`
+when the repository has no commit). A record that is only staged says
+the review "goes stale once this evidence is promoted": promote first,
+then re-pin. The reviewer re-reviews before re-pinning; several
+scenarios re-pin in one `canon review add` (see `canon-review`).
+
 ## Bound evidence stays provable (the artifact store)
 
 `canon evidence add --artifact/--report` copies each bound file into
@@ -468,20 +525,29 @@ have its bindings checked. A superseded record is not checked —
 re-attesting is the fix.
 
 Files bound to a review (`canon review add --artifact`, see
-`canon-review`) are checked the same way for every in-effect review (the
-latest per `(project_id, scenario_id, reviewer)`), with one difference:
-they were stored when the review was written, so only an intact blob is
-clean. A missing or altered blob is `stale-evidence` on the review's
-scenario, and the detail names the review: ``review by `<reviewer>`
-(actor `<id>`, <time>)``. The working-tree file is reported but never
-vouches for it.
+`canon-review`) are checked by the same rule for every CURRENT in-effect
+review: the latest per `(project_id, scenario_id, reviewer)`, less any
+that went stale against its scenario (its spec or evidence pin moved, or
+a review from before pinning is stale at its commit). A stale review is
+superseded — the gate reads the newer review, or reports the missing
+one as `unreviewed-promotion` — so its files are not re-checked, as a
+superseded evidence record's are not. A missing blob whose working-tree
+file still matches is an advisory, listed with the reviewer:
+
+```
+  unstored cart.add.01 reports/cart-badge.png (sha256 9848…, review by `reviewer-2`) is verified against the working tree only
+```
+
+Anything else is `stale-evidence` on the review's scenario, and the
+detail names the review: ``review by `<reviewer>` (actor `<id>`,
+<time>)``.
 
 `canon evidence vault [--max-artifact-mib <N>]` stores the bytes for
-existing records: every attachment whose working-tree file still matches
-its digest is copied in, and everything else is listed as not stored,
-with both digests. It exits `0` whenever it ran (the gate decides whether
-an unstored file matters), `2` when the ledger cannot be read or a write
-fails.
+existing evidence records and current reviews (a superseded review's files are not vaulted): every attachment whose
+working-tree file still matches its digest is copied in, and everything
+else is listed as not stored, with both digests. It exits `0` whenever it
+ran (the gate decides whether an unstored file matters), `2` when the
+ledger cannot be read or a write fails.
 
 ## Effect-aware risk approvals (`risk_tiers`)
 

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

@@ -135,7 +135,8 @@ fixed finding reopened with `--disposition open` counts as open again.
 ## `canon review add`
 
 ```bash
-canon review add --project-id <root-id> --scenario-id <id> \
+canon review add --project-id <root-id> --scenario-id <id> [--scenario-id <id>]... \
+  [--scenario-ids-from <file|->] \
   --reviewer <who> --pin <sha-or-ref> --role <role> \
   (--upstream-ref <ref> | --original-spec-ref <ref>) [--actor-id <id>] [--session-id <id>] \
   [--outcome signed|indeterminate|unavailable] \
@@ -143,7 +144,7 @@ canon review add --project-id <root-id> --scenario-id <id> \
   [--artifact <path>]... [--max-artifact-mib <MiB>]
 ```
 
-One attributed Review record for one scenario, joined on
+One attributed Review record per scenario, joined on
 `(project_id, scenario_id)` — both are required because two spec roots
 may carry the same scenario id. Exactly one provenance ref is required.
 `--actor-id` defaults to `canon`; `--session-id` fills `actor.session_id`.
@@ -153,6 +154,18 @@ own. It is written directly to the ledger, with no staging step, and says
 so: `canon review add: wrote <path> (new) — written directly; nothing to
 promote`.
 
+### Several scenarios in one call (0.18)
+
+`--scenario-id` is repeatable, and `--scenario-ids-from <file>` (`-` reads
+stdin) adds one id per line; `#` starts a comment and blank lines are
+skipped. One reviewer, pin, provenance ref and set of artifacts cover
+every review; each review pins its own scenario and evidence, and each
+gets its own `pinned` and `wrote` line. The artifacts are stored once.
+It is all or nothing: a scenario with no record, or a line in the file
+that is not a scenario id, refuses the call (exit 2) and writes no review.
+This is also the batch re-pin after `canon evidence add` reports reviews
+it made stale (see `canon-gate`).
+
 ### What the reviewer looked at (artifacts)
 
 `--artifact <path>` (repeatable) binds a file the reviewer looked at — a
@@ -173,19 +186,25 @@ The field is absent when no `--artifact` is given. `review add` prints
 .canon/artifacts/sha256/ (<k> newly stored) — commit them with the
 ledger`.
 
-`canon gate check` re-hashes the stored blob of every file bound to an
-in-effect review (the latest per `(project_id, scenario_id, reviewer)`).
-A missing or altered blob is `stale-evidence` on the review's scenario,
-naming the review, even when the working-tree file still matches (see
-`canon-gate`, "Bound evidence stays provable"):
+`canon gate check` re-checks every file bound to a current in-effect
+review (the latest per `(project_id, scenario_id, reviewer)`, unless it
+went stale against its scenario) by the evidence rule (see `canon-gate`,
+"Bound evidence stays provable"). A missing blob whose working-tree file
+still matches is an advisory naming `canon evidence vault`, which stores
+it back. A missing blob with a changed or missing working-tree file, or
+an altered blob, is `stale-evidence` on the review's scenario, naming
+the review:
 
 ```
-stale-evidence world.demo.01 — review by `reviewer-2` (actor `reviewer-2`, 2026-10-11T09:00:00Z) bound file `reports/title.png` recorded sha256 <hex>; stored blob .canon/artifacts/sha256/<hex>: missing; working tree: <hex> — the bound bytes are gone, look again and re-record the review with `canon review add --artifact <path>`
+stale-evidence world.demo.01 — review by `reviewer-2` (actor `reviewer-2`, 2026-10-11T09:00:00Z) bound file `reports/title.png` recorded sha256 <hex>; stored blob .canon/artifacts/sha256/<hex>: missing; working tree: <other hex> — the bound bytes are gone, look again and re-record the review with `canon review add --artifact <path>`
 ```
 
 The reviewer's later review replaces the earlier one, so its files are
-the ones checked. Canon binds and re-checks bytes only; it never compares
-images or judges what a screenshot shows.
+the ones checked. A review that went stale (its scenario's spec or
+evidence moved since) is not checked either: it no longer counts, and the
+scenario's newer review is the one whose files are checked. Canon binds
+and re-checks bytes only; it never compares images or judges what a
+screenshot shows.
 
 ### What the review saw (pins)
 

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

@@ -104,11 +104,12 @@ canon query --kind trajectory --json
 
 canon exposes layered `stg_`/`int_`/`mart_` query views; `canon report`
 builds its numbers from the `mart_` views. Those read ONLY local roots
-— the git ledger and a LOCAL `.canon/r2` parquet mirror. `canon report`
+— the git ledger, the sqlite `hot` db file (local, no credential; read
+since 0.18) and a LOCAL `.canon/r2` parquet mirror. `canon report`
 never opens a live DB connection or the live bucket, so:
 
-- Kinds routed to `hot` (sqlite/postgres) do NOT appear in `canon
-  report`.
+- Kinds routed to a postgres `hot` rung do NOT appear in `canon
+  report`; kinds routed to `canon init`'s default sqlite `hot` rung do.
 - Kinds routed to `cold` (s3) appear only if a local `.canon/r2` mirror
   has been separately materialized — there is no automatic sync.
 

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

@@ -103,7 +103,7 @@ this subject and domain — the exact memory step 2 retrieves next time.
 
 ## Status lifecycle + the shipped evidence gate
 
-`canon subject status <id> <state> [--override-reason <text>] [--actor-id <id>]`
+`canon subject status <id> <state> [--override-reason <text>] [--reason <text>] [--actor-id <id>]`
 performs a policy-gated transition.
 The legal chain:
 
@@ -111,9 +111,10 @@ The legal chain:
 proposed → specced → building → verifying → shipped
 ```
 
-plus **any state → retired** (a subject can be retired from anywhere).
-Any other transition is rejected by failure class, exits 1, and leaves
-the record UNCHANGED (fail closed).
+plus **shipped → verifying** to reopen a shipped subject (with
+`--reason`, below) and **any state → retired** (a subject can be retired
+from anywhere). Any other transition is rejected by failure class, exits
+1, and leaves the record UNCHANGED (fail closed).
 
 ```bash
 canon subject status subject-domain-loop specced
@@ -242,6 +243,39 @@ raised later, a scenario tagged later) still fails the gate. Without
 `require_review`, nothing is printed and nothing changes, except that
 `shipped` still runs the brief check above.
 
+### Reopening a shipped subject (0.18)
+
+A follow-up on a shipped subject (a fix, a review round, a scenario its
+gate now misses) reopens it: reopen, add tasks to the approved change,
+scenario, evidence, review, ship.
+
+```bash
+canon subject status demo-subject verifying \
+  --reason "follow-up: the retry path leaks a file handle" --actor-id impl
+```
+
+```
+canon subject status: reopened `demo-subject` from shipped, recorded by `impl`: follow-up: the retry path leaks a file handle; add the follow-up as tasks in its approved change `c-demo`, then scenario, evidence and review; shipping again runs every guard
+canon subject status: demo-subject → verifying — written directly; nothing to promote
+```
+
+- `--reason "<one line>"` is required for `shipped → verifying` and
+  refused on any other transition (exit 2, as is a blank one). The new
+  record carries it with the actor and the change the work goes into:
+  `reopen: { reason: …, change: c-demo, actor: { agent_id: impl } }`. The
+  next status write clears it, as it clears a waiver.
+- Inside the approved scope it needs no human: the subject's newest
+  adopted change's brief is approved, or there is no brief to answer.
+  Otherwise it refuses, exit 1, 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.
+- `canon status` flags a shipped subject whose gate went red (whatever
+  `verifying → shipped` would now refuse it on) and its only step is
+  this reopen.
+
 ## Adopt flow
 
 Planning docs written outside canon become change/task records via
@@ -261,19 +295,33 @@ and a flip re-imports that change itself. Run `canon ingest plans` for a
 plan written outside canon, or when `canon query --kind task` must list
 rows nobody has flipped yet.
 
-`adopt` stamps the change's `subject_id` and adds it to the Subject's
-`change_ids`, so `canon query --kind change --change-id …` and `canon
-query --kind subject` agree on the link from both ends. It writes only
-the side that lacks the link, so rerunning it on a linked pair writes
-nothing and exits `0`.
+`adopt` adds the subject to the change's `subject_ids` and the change to
+the Subject's `change_ids`, so `canon query --kind change --change-id …`
+and `canon query --kind subject` agree on the link from both ends. It
+writes only the side that lacks the link, so rerunning it on a linked
+pair writes nothing and exits `0`.
+
+A change may belong to several subjects (0.18). Adopting it under a
+second subject adds that subject, never re-points the change, and says
+so:
+
+```
+canon subject adopt: linked change `refactor-core` to subject `editing` as well; the change now belongs to `perception` and `editing` — written directly; nothing to promote
+```
+
+Every reader joins a subject to its changes from both sides (the
+subject's `change_ids`, and every change whose `subject_ids` names it):
+the open-blocker rule, the status guard, `canon status`, the brief and
+the evidence refusal. An open blocker on a shared change gates each
+subject it belongs to. A change written before 0.18 names one subject as
+`subject_id`; it reads, and `canon query --kind change --json` shows it,
+as a one-element `subject_ids`.
 
 The two records cannot be written atomically, so the subject is written
-first: its `change_ids` is what the gate reads a subject's adopted
-changes from (`open-blocker`, the status guard), so a half-done adoption
-still has that change's open blockers counted. If the change write then
-fails, `adopt` exits `2`, names the subject that now lists the change,
-and prints `canon subject adopt <change_id> --subject <id>` to complete
-it.
+first: a half-done adoption still has that change's open blockers
+counted. If the change write then fails, `adopt` exits `2`, names the
+subject that now lists the change, and prints `canon subject adopt
+<change_id> --subject <id>` to complete it.
 
 ### Starting a new change: `canon change new`
 
@@ -393,6 +441,14 @@ uses, so status and the gate cannot disagree about a gap:
   canon brief and no line it reads
   ``brief: not approved (<brief> has no `Approved:` line)``.
   There is no record kind for it; the file is the record.
+- **Red shipped subject** (0.18) — a `shipped` subject that the
+  `verifying → shipped` guard would now refuse, by the guard's own checks
+  (owned scenarios, verdicts, required cases, audits, and, where
+  `require_review` covers `shipped`, reviews and open blockers under
+  `block_on_findings`; a gap its waiver recorded is not counted), prints
+  ``gate: red — <n> <class> (first: <subject>), …; reopen with `canon subject status <id> verifying --reason "<why it reopens>" --actor-id <unit>` ``,
+  carries `red: [...]` in `--json`, and that reopen is its only `next:`
+  step. Open blockers count against every subject a change belongs to.
 - **Unowned** — scenarios with no `@subject:` tag.
 - **Audits** — how many scenarios are sampled for
   `spec_coverage.require_audit`, confirmed, owed (no audit or

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@journeykit/canon",
-  "version": "0.17.0",
+  "version": "0.18.0",
   "description": "canon — harness knowledge substrate. JS launcher: platform detection + native binary resolution.",
   "license": "MIT",
   "type": "module",
@@ -30,9 +30,9 @@
   },
   "dependencies": {},
   "optionalDependencies": {
-    "@journeykit/canon-core-darwin-arm64": "0.17.0",
-    "@journeykit/canon-core-linux-x64": "0.17.0",
-    "@journeykit/canon-core-win32-x64": "0.17.0"
+    "@journeykit/canon-core-darwin-arm64": "0.18.0",
+    "@journeykit/canon-core-linux-x64": "0.18.0",
+    "@journeykit/canon-core-win32-x64": "0.18.0"
   },
   "devDependencies": {
     "@types/node": "^20.0.0",