@erclx/canon 4.119.0 → 4.121.0

package/docs/agents/teach.md

@@ -1,6 +1,6 @@
 ---
 title: Teach
-description: Listing learning workspaces with what their records schedule next, opening one with its required files, recording sources and glossary terms, resolving what the next lesson needs before it is written, rewriting the root listing, a contents page, and each lesson's chrome and quiz stepper from its marker regions, the refusal reasons, and why every write here runs through a verb
+description: Listing learning workspaces with what their records schedule next, opening one with its required files, recording sources and glossary terms, where the lesson authoring verbs are described, the refusal reasons, and why every write here runs through a verb
 ---
 
 # Teach
@@ -110,109 +110,9 @@ A term already defined is refused rather than replaced. A definition the subject
 
 The entry lands as the standard's shape, leading with the term as a bolded span. A definition not ending in sentence punctuation is terminated before the citation is appended, so a bare phrase does not run into the sentence naming where the term first appears.
 
-## Lesson
+## Lesson, render, and nav
 
-`canon teach lesson` resolves what the next lesson needs before it is written. It reads and never writes.
-
-```bash
-canon teach lesson regular-expressions \
-  --slug capture-groups \
-  --questions 3 \
-  --options 4
-```
-
-| Option            | Behavior                                                  |
-| ----------------- | --------------------------------------------------------- |
-| `--slug <kebab>`  | The lesson's own topic, required                          |
-| `--questions <n>` | How many questions the quiz carries, required             |
-| `--options <n>`   | How many options each question carries, defaulting to `4` |
-| `--json`          | Emit a machine-readable record on stdout                  |
-| `--root <path>`   | Teach root, defaulting to the main worktree               |
-
-It reports three things. `lesson` is the numbered path the lesson takes, derived from the highest ordinal already in `lessons/` the way an open derives a workspace ordinal. `success` carries the mission's success lines, so a session reports progress against the exit criteria without a second read of `MISSION.md`. `quiz` carries one entry per question.
-
-A lesson written against this record carries its chrome as four empty marker pairs rather than hand-composed markup: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. `canon teach nav`, below, fills them from what the workspace holds on disk.
-
-`canon teach stylesheet <topic>` writes the pair every lesson in the workspace renders through, seeded from the design source so a workspace renders in the system every other surface does. The two halves are written on different terms. `assets/base.css` holds the generated design layer and is rewritten on every run, which is the only way a change to the shared chrome reaches a workspace that already exists. `assets/course.css` is the half a workspace owns, so it refuses to overwrite, reporting `written` as false where the workspace already carries one, and `--force` takes the seed back over it. Each workspace used to carry a hand-authored palette, which is how the course styling forked once per workspace, so a lesson adds its own rules under the seed and reaches a value through its custom property rather than restating the hex.
-
-Each `quiz` entry carries `order`, the authored option indices in presentation order where index `0` is the correct answer, and `answer`, the one-based position that answer lands in. Both travel together because a caller deriving the position itself is a caller that can derive it wrongly.
-
-The order is drawn here rather than instructed, and that is the point of the verb. An author told to vary the position still varies it by judgment, and the judgment settles on the first slot, which is the defect this design departs from. The draw is uniform over the options, so the position carries no information about which answer is correct.
-
-## Render
-
-`canon teach render` renders a lesson body's structural blocks to HTML, through the four lesson components. It takes no topic and no `--root`, since the verb is a stateless transform reading nothing off a workspace on disk.
-
-```bash
-echo '[{"type":"heading","level":1,"text":"Compass bearings"}]' | canon teach render --json
-```
-
-| Option   | Behavior                                 |
-| -------- | ---------------------------------------- |
-| `--json` | Emit a machine-readable record on stdout |
-
-It reads a JSON array of blocks from stdin, each a `heading`, `paragraph`, `list`, `refs`, or `raw` block, and reports `{ ok: true, html }` on `--json` or the bare rendered HTML on stdout otherwise. Content none of the components can express takes a `raw` block, carrying its own HTML verbatim and unescaped, which is the shape the quiz and the teach-back block travel in.
-
-A citation takes two shapes. A `paragraph` carries an optional `cites` array of reference numbers, rendered as `sup.cite` markers after its text. The one `refs` block carries `items` of `{ title, url?, note? }`, rendered as `ol.refs` and numbered from 1, so cite `1` links to the first item.
-
-```json
-[
-  { "type": "paragraph", "text": "North is fixed.", "cites": [1] },
-  {
-    "type": "refs",
-    "items": [{ "title": "Compass manual", "url": "https://example.com" }]
-  }
-]
-```
-
-It refuses `bad-input` on empty stdin, on malformed JSON, on stdin that does not parse to an array, and on a block carrying an unrecognized `type` or a field of the wrong shape for its type, naming the block's index in the message. Citations add four refusals, each naming the offending block: a cite that resolves to no reference, `cites` on a lede paragraph, a second `refs` block, and a reference `url` that is not `http` or `https`.
-
-## Nav
-
-`canon teach nav` rewrites the teach-root listing, a workspace's contents page, and each of its lessons' chrome, from what the workspace holds on disk.
-
-```bash
-canon teach nav
-canon teach nav regular-expressions --json
-```
-
-| Option          | Behavior                                          |
-| --------------- | ------------------------------------------------- |
-| `[topic]`       | Workspace folder or topic, scoping the run to one |
-| `--json`        | Emit a machine-readable record on stdout          |
-| `--root <path>` | Teach root, defaulting to the main worktree       |
-
-With no topic it rewrites every workspace. The teach-root listing is always rewritten regardless, since it reports on every workspace and a scoped run leaving it stale would be a second kind of drift this verb exists to end.
-
-A lesson carries its chrome as four marker pairs the authoring skill writes empty: `canon:teach:style`, `canon:teach:header`, `canon:teach:footnav`, and `canon:teach:scripts`. This verb splices each one from the current workspace state, embedding the toolkit's favicon, the shared stylesheet, and the script that settles the course panel before the page paints, rebuilding the course sidebar, the breadcrumb and jump menus, the prev/next footer nav, and the behavior scripts. It leaves the authored `<h1>`, lede, body, and quiz between the header and the footnav as written, with two exceptions. It wraps them in `<main>` when the lesson holds none, since the column width hangs off that element, and a lesson that already carries a `<main>` keeps its own.
-
-It also links each "lesson NNNN" mention in that region to the lesson file in the same workspace carrying that number, skipping text inside `a`, `code`, `pre`, `script`, `style`, `label`, `summary`, and comments. A link the verb writes carries `data-lesson-ref`, and it is the only kind the verb rewrites: every run points one at the current filename for its number, or unwraps it to plain text once that number names no lesson. A link an author wrote is never touched.
-
-Every workspace label in that chrome, being the breadcrumb, the sidebar heading, the workspace switcher, and the root listing's row, reads the mission's `title` and falls back to the folder topic in sentence case where the mission names none.
-
-It also deletes two links a session used to write by hand into a lesson's `<head>`, each matched as its exact string: the old icon link and `<link rel="stylesheet" href="../assets/course.css" />`. The page keeps only the icon and the stylesheets the `style` region carries. Any other link an author wrote stays.
-
-A workspace carrying no `course.css` gets its stylesheet pair seeded first, so the contents page it links is never unstyled, and an existing `course.css` is never overwritten. The `style` region links `assets/base.css` ahead of an embedded copy of `course.css`, so the workspace's own rules still win the cascade. The embedded copy drops the seed's `@import` line, which resolved against the lesson's own folder and never loaded anything, and the link is what reaches the base sheet in its place. A workspace with no `assets/base.css`, one holding a hand-authored `course.css` from before the seed, gets no link rather than one pointing at a missing file.
-
-That seeding fires on the absent file alone, so a workspace already holding a `course.css` has neither half rewritten here. A change to the shared chrome therefore takes `canon teach stylesheet <topic>` per workspace, which rewrites `assets/base.css`, and every lesson picks it up through its link with no run of this verb. Running this one alone leaves every lesson on the `base.css` the workspace already holds, and nothing reports it. Only an edit to a workspace's own `course.css` needs this verb, since that half is embedded.
-
-A lesson missing one of the four marker pairs is refused by name rather than rewritten, and every other lesson in the run still rewrites. The record's `skipped` list carries the refused files and which marker each is missing.
-
-A mention whose number names no lesson in its workspace stays plain text and lands in the record's `unresolved` list, one `{ file, lesson }` entry per distinct number per lesson, with `file` relative to the root the way a `skipped` entry is. The lesson still rewrites and counts toward `lessons`, and the exit stays 0. A mention of the lesson's own number stays plain and is not reported, and a refused lesson reports nothing.
-
-The `style` region carries the quiz stepper after the workspace stylesheet, for every lesson but the one shape named three paragraphs down, so it wins the cascade at equal specificity and reaches a workspace seeded before it existed. The stepper is CSS over the radio inputs a quiz is written from: it hides every question that follows one holding no checked input, and hides a question's feedback until that question does. The general sibling combinator is what keeps that from depending on the markup contract holding, since it selects the same questions as the adjacent one for a quiz written correctly and goes on gating when anything sits between two of them, where the adjacent one matches nothing and shows them all at once. Gating there rather than in a script is what keeps a later stem from answering an earlier question with nothing to bind, and the whole block sits inside `@supports selector(:has(*))`, so an engine without `:has()` renders every question rather than a stepper showing nothing. Feedback there follows the workspace stylesheet, shown by one that says nothing about `.fb` and hidden by one grown under the retired script.
-
-The block hides and shows and sets nothing else, which leaves a workspace's own layout for a question and its own appearance for an option and a feedback panel. The one value it names is `display: block` on revealed feedback, since every stylesheet grown under the retired script carries `.fb { display: none }` and nothing adds the class that used to reveal it.
-
-One detector decides both regions. A lesson carrying `<button class="opt"`, the shape written before the stepper, takes the feedback script and no stepper, and every other lesson takes the stepper and no script. That is a detector rather than a mode, since a lesson has one shape or the other, and removing the script outright would leave the lessons already written showing no feedback at all.
-
-Splicing the stepper into a lesson of either shape was measured against a browser and reverted. Its rules match a button question, which can never hold a checked radio, so a lesson given both hides every question past the first for good and outranks the class the script reveals feedback with. Nothing else caught that: the markup is valid, the splice succeeds, and the page renders.
-
-### Reference pages
-
-Each reference page is rendered to a `reference/<slug>.html` sibling carrying the same chrome, and the contents page links that sibling rather than the markdown, which `canon serve` hands over as plain text. The render drops the frontmatter, turns tables into `<table>` markup, and escapes raw HTML written in the markdown rather than passing it through. A body with no H1 gets one from the frontmatter `title`. A relative link to another reference page's markdown points at that page's `.html` sibling, and one to the workspace `GLOSSARY.md` points at the glossary on the contents page, `../index.html#gloss`. Every other link, such as `../RESOURCES.md`, stays as written. The markdown file is never touched.
-
-Every rendered page carries a `<meta name="generator" content="canon teach nav">` tag. A `.html` file under `reference/` whose markdown is gone is deleted when it carries that tag, and a hand-written HTML file there, carrying none, is left alone. The record's `reference` field counts the pages rendered. On a Bun with no `Bun.markdown`, each reference page lands in `skipped` with `Bun.markdown` as what is missing, and the rest of the run goes on.
+`canon teach lesson`, `canon teach render`, and `canon teach nav` build and splice a lesson rather than editing a workspace's records. They are in `teach-authoring.md`.
 
 ## Opening a workspace
 

package/docs/target-projects.md

@@ -102,7 +102,7 @@ Run `canon tooling list --json` and `canon gov list --json` to see the current c
 
 `canon init` installs base tooling, Claude workflow, and governance, and scaffolds `.claude/wiki/`. Governance defaults to the `base` stack, so a bare init carries the rules that route a project. Pass `--stack <name>` to install a framework stack instead.
 
-No standard is written into the project. Each governance rule's authority line names `canon standards <name>`, which answers from the corpus inside the CLI's own package, and every toolkit skill names the copy in its own plugin root. `canon markdown audit` needs no standard at all, its ban sets and checkpoints shipping with the package as data.
+No standard is written into the project. Each governance rule's authority line names `canon standards <name>`, which answers from the corpus inside the CLI's own package, and every toolkit skill names the copy in its own plugin root. `canon markdown audit` needs no standard at all, its ban set and checkpoints shipping with the package as data.
 
 No snippet is written into the project either. `claude/snippets` in the plugin cache symlinks to the toolkit's own `snippets/`, so a session reaches one at its `@` reference with no install step, the same live resolution `claude/standards` gives a rule's authority line.
 
@@ -350,5 +350,5 @@ Sync also refuses a target whose working tree is dirty, so commit or stash befor
 
 - [agents](agents/index.md): CLI flags, exit codes, and JSON output shapes
 - [AI workflow](workflow/ai-workflow.md): feature-development loop inside a toolkit-managed project
-- [tooling](../canon/context/tooling.md), [governance](../canon/context/governance/index.md), [claude plugin](../canon/context/claude-plugin/index.md), [indexes](../canon/context/indexes.md), [snippets](../canon/context/snippets.md), [standards](../canon/context/standards/index.md): per-domain mechanics
+- [tooling](../canon/context/tooling/index.md), [governance](../canon/context/governance/index.md), [claude plugin](../canon/context/claude-plugin/index.md), [indexes](../canon/context/indexes.md), [snippets](../canon/context/snippets.md), [standards](../canon/context/standards/index.md): per-domain mechanics
 - [sandbox](../canon/context/sandbox/index.md): scenario catalog for verifying domain flows

package/docs/workflow/ai-workflow.md

@@ -109,7 +109,7 @@ An execution that picks other than the suggestion rewrites the `- Suggested:` li
 
 `canon records push` carries these folders off the disk they live on, and `canon records pull` brings them back. Every top-level entry under `.canon/` is backed except `tmp`, `ordinal-locks`, and `.records.git`, so a folder added later enters the payload on its own rather than waiting on a name written into a list. Push names each folder it carries the first time it sees it, which is what keeps a stray folder visible instead of silently entering the payload. It refuses the whole push, naming each path, when a new or changed file is over 25 MB or carries a credential `canon secrets scan` would report. The history lives in a second git directory at `.canon/.records.git` with `.canon/` as its work tree, so every path a task file cites stays where it is.
 
-A person points it at a private repository once and both verbs refuse until they have, and `push` refuses when that origin is also a remote of the project, since the payload is the memory pen and the groundwork trails. `.husky/post-merge` runs the push after its archive loop, on every merge rather than only on one that closed a task. See [records](../agents/records.md) for the refusal table.
+A person points it at a private repository once and both verbs refuse until they have, and `push` refuses when that origin is also a remote of the project, since the payload is the memory pen and the groundwork trails. `.husky/post-merge` runs the push after its archive loop, on every merge rather than only on one that closed a task. See [records push](../agents/records-push.md) for the refusal table.
 
 `canon records size` reports what each of these folders holds, heaviest first, along with `.canon/tmp`. Each row carries the file count, the bytes, how many files were written in the last 7 and 30 days, and the dates of the least and most recently written one. Nothing fails on a number, because a record folder has no correct size. What the verb replaces is a reading somebody had to remember to take: the memory pen went from 44 entries to 236 between two counts made by hand a fortnight apart, and nothing reported the rate in between.
 
@@ -231,6 +231,7 @@ This section is the corpus the coverage claim is measured against: every name `c
 | `canon:project-commands`     | When the project's own command needs running                                                               |
 | `canon:test-first`           | Before implementing a planned change, to run its test red, green, then refactor                            |
 | `canon:test-craft`           | When writing or changing any test, to pick its layer and filter what it asserts                            |
+| `canon:review-craft`         | When reviewing a change, for what to look for and how much evidence a finding needs                        |
 | `canon:systematic-debugging` | When a test fails or a bug surfaces, to force root cause first                                             |
 | `canon:ui-checklist`         | After a UI change, to write what to look at and name what ships untested                                   |
 

package/docs/workflow/visual-design-workflow.md

@@ -22,7 +22,7 @@ Claude Code reads both and writes the implementation. Works for CLI tools, inter
 
 The toolkit seed in `tooling/claude/seeds/canon/DESIGN.md` ships a token-table template with a starting set of roles, and `standards/design.md` carries the same tables under `## Template` with placeholder rows. The column headers are what the renderer parses, so they stay verbatim in either, while the rows and values are the project's own.
 
-The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `canon/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design.md`.
+The `canon:design-extract` skill drafts the file, sourcing tokens from a project's existing prose and CLI UI surfaces, or proposing them from `canon/REQUIREMENTS.md` and a `## Personality` paragraph when no UI code exists yet. `canon design render` writes an HTML plus CSS preview to `.canon/tmp/render/design/` for eyeballing the current system without leaving Claude Code. See `canon/context/design/index.md`.
 
 A project wanting a neutral starting point to override runs `canon design install`, which copies one stylesheet to `.claude/design/base.css` carrying an achromatic token set as custom properties and two components built on them. Greys run from near-black to near-white and the accent is monochrome, so the only palette the project renders is one it writes itself. That file is toolkit-owned and `canon design sync` refreshes it, so a project overrides a value in `.claude/design/project/` instead, which sync never touches. Nothing arrives without that install, and the two channels are independent: a record drafted by the extract skill is the project's own, and the installed stylesheet is the toolkit's.
 

package/governance/rules/claude/500-prose.md

@@ -12,4 +12,4 @@ paths:
 - Load it before drafting a passage, not after revising one.
 - Report it rather than proceeding silently when the skill does not resolve.
 - Do not work these rules from memory.
-- Banned words, spellings, punctuation, formatting, and file references are a separate topic. `501-markdown` routes them.
+- Punctuation, formatting, and file references are a separate topic. `501-markdown` routes them.

package/governance/rules/claude/501-markdown.md

@@ -1,5 +1,5 @@
 ---
-description: Route markdown edits to the markdown standard for headings, lists, punctuation, banned words, and frontmatter wording
+description: Route markdown edits to the markdown standard for headings, lists, punctuation, and frontmatter wording
 paths:
   - '**/*.md'
 ---
@@ -8,7 +8,7 @@ paths:
 
 ## Authority
 
-- Follow the markdown standard for headings, paragraph and list structure, code spans, punctuation, emphasis, file references, the banned words and spellings, and the wording of a `title` or `description`. It is the single source. Read it with `canon standards markdown`.
-- Read it before a substantial markdown edit. Do not work the banned words or characters from memory.
+- Follow the markdown standard for headings, paragraph and list structure, code spans, punctuation, emphasis, file references, and the wording of a `title` or `description`. It is the single source. Read it with `canon standards markdown`.
+- Read it before a substantial markdown edit. Do not work the banned characters from memory.
 - Run `canon markdown audit <path>` after the edit, and rewrite the sentence carrying a hit rather than swapping the token for a near-synonym.
 - Voice, rhythm, and sentence construction are a separate topic. `500-prose` routes them.

package/governance/rules/claude/570-skill.md

@@ -21,4 +21,5 @@ paths:
 
 ## Authority
 
-- Follow the skill standard for skill structure, frontmatter fields, invocation rules, and the shape a `REQUIREMENT.md` states. It is the single source. Read it with `canon standards skill`.
+- Follow the skill standard for skill structure, frontmatter fields, and invocation rules. It is the single source. Read it with `canon standards skill`.
+- Follow the skill requirement standard for the shape a `REQUIREMENT.md` states. Read it with `canon standards skill-requirement`.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/canon",
   "type": "module",
-  "version": "4.119.0",
+  "version": "4.121.0",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/scripts/core/check-ignore-parity.sh

@@ -19,7 +19,7 @@ SECTION="# Claude"
 # The diagrams divergence is the one that cost something. A target used to track
 # its diagrams and keep the context audit's default coverage of them, and it now
 # ignores them with the rest of its records, so that coverage is gone unless the
-# project names the folder itself. `canon/context/tooling.md` carries the
+# project names the folder itself. `canon/context/tooling/manifests.md` carries the
 # narrative.
 #
 # An exception mechanism is not kept against a future divergence, because an

package/scripts/lib/sandbox-git.sh

@@ -95,7 +95,7 @@ ensure_sandbox_anchor_repo() {
   # nine to a pass against something that is not the anchor. Refusing is the safe
   # default and creating is the opt-in, the shape `canon tooling sync --write`
   # already sets. `canon records push` refuses outright for the reason
-  # `canon/context/development/scratch.md` records, so the two still differ.
+  # `canon/context/development/records.md` records, so the two still differ.
   # The sibling SANDBOX_ flags are presence tests, so any non-empty value turns
   # them on. This one allowlists instead, because a presence test would have
   # SANDBOX_ANCHOR_CREATE=false provisioning a repository. Both spellings are

package/src/autoship/paths.ts

@@ -2,8 +2,9 @@
  * The surfaces where markdown states what an agent does, and the extensions
  * that read as prose, held as data one command parses.
  *
- * Lifted verbatim in content from the list `auto-ship/SKILL.md` Step 5
- * carried, which a session was asked to apply by hand. It failed that
+ * Lifted verbatim in content from the list `auto-ship` Step 6 carried, whose
+ * written fallback copy now sits in `auto-ship/references/verb-absent.md`,
+ * which a session was asked to apply by hand. It failed that
  * application three times, so the set moved here and the body now calls a verb
  * that reads it. Being machine-parsed makes it permanently exempt from any
  * later design that folds a standard back into the surface citing it, per the

package/src/claude/cases/workflow.ts

@@ -99,6 +99,11 @@ export const WORKFLOW_CASES: readonly SkillCase[] = [
       'Look over everything that changed on this branch for bugs and edge cases.',
     expect: 'review-branch',
   },
+  {
+    prompt:
+      'What should a review of a change look for beyond bugs, and how much evidence does a finding need?',
+    expect: 'review-craft',
+  },
   {
     prompt: 'Draft me a script with beats for a screencast recording.',
     expect: 'draft-screencast',

package/src/commands/audits.ts

@@ -76,8 +76,8 @@ export function register(program: Command): void {
         '  3  an audit did not report, so the run measured less than the set',
         '',
         'It gates on exactly what already gates a push and on nothing new:',
-        'an unresolved context citation, a banned character, word, or spelling,',
-        'and a skill folder carrying no REQUIREMENT.md. Every other measure is a',
+        'an unresolved context citation, a banned character, and a skill folder',
+        'carrying no REQUIREMENT.md. Every other measure is a',
         'judgment a reader settles, and failing a push on one teaches',
         'contributors to route around the stage.',
         '',

package/src/commands/markdown.ts

@@ -67,7 +67,7 @@ export function register(program: Command): void {
   markdown
     .command('audit')
     .description(
-      'Fail on a banned character, word, or spelling, and report bullet, paragraph, cadence, depth, and length',
+      'Fail on a banned character, and report bullet, paragraph, cadence, depth, and length',
     )
     .argument(
       '[path...]',
@@ -82,8 +82,8 @@ export function register(program: Command): void {
         'Exit codes:',
         '  0  the audit completed with no gating finding',
         '  1  refused, with the reason on stderr',
-        '  2  a banned character, word, or spelling is present, or a relative',
-        '     link resolves to nothing on disk',
+        '  2  a banned character is present, or a relative link resolves',
+        '     to nothing on disk',
         '  3  a shipped ban set is empty, so the run measured nothing',
         '',
         'A ban hit and a dead link are each a fact and gate unconditionally.',
@@ -192,8 +192,6 @@ async function runAudit(
         unmatchedPaths: scope.unmatched,
         bans: {
           characters: bans.characters,
-          words: bans.words,
-          spellings: bans.spellings,
           emptySets: empty,
         },
         checkpoints: {
@@ -284,19 +282,19 @@ function reportBans(
 
   if (empty.length > 0) {
     logWarn(
-      `Not measured. The shipped set is empty for: ${empty.join(', ')}. The sets ship with the canon package, so an empty one is a defect in the build rather than a missing install.`,
+      `Not measured. The shipped set is empty for: ${empty.join(', ')}. The set ships with the canon package, so an empty set is a defect in the build rather than a missing install.`,
     )
     return
   }
 
   logInfo(
-    `${plural(bans.characters.length, 'character')}, ${plural(bans.words.length, 'word')}, and ${plural(bans.spellings.length, 'spelling')} shipped with the canon package`,
+    `${plural(bans.characters.length, 'character')} shipped with the canon package`,
   )
   logInfo(
     'Frontmatter, fenced blocks, code spans, and link destinations are excluded.',
   )
   logInfo(
-    'Phrase bans and every voice rule are patterns rather than closed sets, and stay a judgment for the reader.',
+    'Word bans, phrase bans, and every voice rule are guidance for the reader',
   )
 
   const carrying = reports
@@ -304,7 +302,7 @@ function reportBans(
     .sort((a, b) => b.bans.length - a.bans.length)
 
   if (carrying.length === 0) {
-    logInfo('No banned character, word, or spelling.')
+    logInfo('No banned character.')
     return
   }