@erclx/canon 5.47.0 → 5.49.0

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
-  "version": "5.47.0",
+  "version": "5.49.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/auto-ship/SKILL.md

@@ -124,7 +124,7 @@ This chain adds one thing. Mark the pull request as a draft as soon as `git-ship
 
 ## Step 7: wait for the reviews
 
-Run this step only when the launch named a controlling session, since only a controller dispatches the reviewers. A hand-launched run has nobody reviewing, so it emits the Output block on the CI wake instead of waiting on a pass that cannot arrive.
+Run this step only when the launch named a controlling session, since only a controller dispatches the reviewers. A launch naming no controller has nobody reviewing, so it emits the Output block on the CI wake instead of waiting on a pass that cannot arrive. A `Controller: <sessionId>` line names one, whether the launch was by hand or not.
 
 Read review state through `canon pr review-state` alone, since both families post as pull request reviews, and a worker polling issue comments instead stalled with both reviewers idle. Run it in the background with the number Step 6 returned, since the wait outlasts a foreground shell call, and act on the wake.
 

package/claude/skills/git-pr/references/closing-issues.md

@@ -24,6 +24,8 @@ The verb reads the current branch itself and counts the names it carried before
 | `ok: false`, `no-board`, `no-match`, or `ambiguous` | Write nothing and run the scan without `--closes`                                  |
 | Any other refusal                                   | Report it rather than swallowing it                                                |
 
+The record also carries `operatorChecks`, the unticked `Operator check:` outcomes. They hold nothing open, so a task with only those left still reads `closing: true`. An operator outcome nobody marked reads as `open-outcomes`, so the mark has to land before `git-pr` runs.
+
 The three skipped refusals are the ones `task-number.md` skips, and for the same reason. A guessed task would close the wrong issue.
 
 ## The line

package/claude/skills/plan-feature/SKILL.md

@@ -17,8 +17,8 @@ metadata:
 
 Before Step 3, name the next three questions you would ask about what the ask must achieve, and predict the operator's answer to each. The test reads the ask's success criteria, never the plan's open questions.
 
-- A predictable answer settles its criterion, which Step 3 writes as a `**Verification:**` bullet rather than a question
-- Only a prediction still open goes under `**Questions:**` with a `- Suggested:` line, so a fully specified ask carries none and Small mode stays reachable
+- A predictable answer settles its criterion, which Step 3 writes as a `## Verification` bullet rather than a question
+- Only a prediction still open goes under `## Questions` with a `- Suggested:` line, so a fully specified ask carries none and Small mode stays reachable
 - When you can predict none of the three, ask before Step 3 through whatever route reaches the operator, including a message to a dispatching session
 
 ## Step 1: read the Claude setup
@@ -59,7 +59,7 @@ The section list, what each section holds, and the suggested-and-answer contract
 
 What this skill adds on top of the standard:
 
-- Reframe a vague ask as success criteria before `**Files to touch:**`, each an observable result and its check, which becomes one `**Verification:**` bullet. "Make it faster" names none.
+- Reframe a vague ask as success criteria before `## Files to touch`, each an observable result and its check, which becomes one `## Verification` bullet. "Make it faster" names none.
 - Confirm a concrete project or use case drives the feature, and lift patterns from it where precedent exists. A feature with no named user is a guess.
 - Prefer one layout that serves both a new and a grown project over a dual-mode toggle or a migration shim. Two modes double what every later change has to hold.
 
@@ -68,16 +68,16 @@ What this skill adds on top of the standard:
 Every `- Suggested:` line takes senior judgment, picking the best option in one line with its reason or main tradeoff, and naming alternatives only when they change the pick.
 
 - Suggest a real default when best practice, the codebase, or prior context points to one
-- Load `canon:codebase-layout` before `**Files to touch:**` when an entry names a path that does not exist yet, and give each new path its placement reason. Report it if it does not resolve.
-- Fill `**Design references:**` with the `canon/design/<surface>/` folder for each surface a UI file in `**Files to touch:**` renders, and write `None identified.` in a project with no folder
-- Write `**Verification:**` as one bullet per outcome naming the test or command that proves it
-- Write `**Review focus:**` as the inputs or states that would break the change, carrying the risk you understood to the executor and the reviewer
+- Load `canon:codebase-layout` before `## Files to touch` when an entry names a path that does not exist yet, and give each new path its placement reason. Report it if it does not resolve.
+- Fill `## Design references` with the `canon/design/<surface>/` folder for each surface a UI file in `## Files to touch` renders, and write `None identified.` in a project with no folder
+- Write `## Verification` as one bullet per outcome naming the test or command that proves it
+- Write `## Review focus` as the inputs or states that would break the change, carrying the risk you understood to the executor and the reviewer
 
 ### Sources and size
 
 A small feature produces a short plan, not a padded one.
 
-- Cite the `**Sources:**` entry for every decision Step 2 sourced, each with its quoted passage or the word `unverified`
+- Cite the `## Sources` entry for every decision Step 2 sourced, each with its quoted passage or the word `unverified`
 - Prefer `None identified.` over low-signal fillers
 - When three or more questions remain, keep chat output to the file pointer plus a short summary. Inline chat is fine when two or fewer remain.
 
@@ -99,21 +99,21 @@ A consumer list is a `Risks` entry, which already forces Full. A resource with m
 Output the plan to chat and write no plan file. The markers match the standard's, so a plan that later grows into a file keeps its shape.
 
 ```markdown
-**Files to touch:**
+## Files to touch
 
 - `path/to/file`: reason
 
-**Verification:**
+## Verification
 
 - <outcome>: `<test or command that proves it>`
 ```
 
-Small mode carries no `**Review focus:**`, since its Risks already came out `None identified.` and the reviewer has no breaking input to name.
+Small mode carries no `## Review focus`, since its Risks already came out `None identified.` and the reviewer has no breaking input to name.
 
-If real questions exist, include a numbered `**Questions:**` section below, each with a `- Suggested:` line and an `- Answer:` slot:
+If real questions exist, include a numbered `## Questions` section below, each with a `- Suggested:` line and an `- Answer:` slot:
 
 ```markdown
-**Questions:**
+## Questions
 
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>
@@ -132,7 +132,10 @@ The plan is a main-root write, from a linked worktree and from a background sess
 
 Two commands check the file once it lands, and both write nothing.
 
-- Run `canon records validate plans` when the CLI is on PATH. It reports a section, a filename, or an answer slot that does not hold.
+- Run `canon records validate plans feature-<slug>` when the CLI is on PATH. Its `findings` name a section, a filename, or an answer slot that does not hold.
+- Fix each entry its `structure` array names before reporting, against `### Structure` in `${CLAUDE_SKILL_DIR}/references/plan.md`
+- Read that array rather than the exit code, since a structure entry never sets the exit
+- Say the check did not run when the binary refuses the plan argument or carries no `structure` key, rather than reporting the plan clean
 - Run `canon markdown audit .canon/plans/feature-<slug>.md`, naming the file, since the gitignored plan reaches no other gate. Rewrite a hit's sentence rather than swapping the token.
 
 When Step 1 resolved an existing task, run `canon tasks plan-link <task> .canon/plans/feature-<slug>.md` right after the file lands, naming the stem Step 1 read. Skip it when Step 1 found no task, and report a refusal rather than stopping, since `canon tasks validate` still catches an unlinked task through `plan-uncited`.
@@ -144,7 +147,7 @@ Then output in chat:
 ```markdown
 📝 Wrote .canon/plans/feature-<slug>.md
 
-**Questions:**
+## Questions
 
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>

package/claude/skills/plan-feature/references/batches.md

@@ -11,18 +11,18 @@ Applies to a feature plan that sequences its work into more than one batch. A de
 
 One batch is one pull request, and one pull request is one plan file, named for its own concern rather than a numeric suffix. `canon tasks plan-branch` derives one branch from one plan filename. A fan-in member is the exception, keeping its own file and branch and opening no pull request, per `## Fan-in`.
 
-- A `**Batch N**` sub-heading inside one file's `**Files to touch:**` shares that branch across every batch, so the first merge strands the rest
+- A `**Batch N**` sub-heading inside one file's `## Files to touch` shares that branch across every batch, so the first merge strands the rest
 - Write a plan opening five batches as five files before the first line of any of them
 
 ## Dependent batches
 
-State a dependent batch's dependency on the ones before it in its own `**Constraints:**`, naming the earlier batch's slug and stacking rather than merging into it.
+State a dependent batch's dependency on the ones before it in its own `## Constraints`, naming the earlier batch's slug and stacking rather than merging into it.
 
 A batch that builds after another and shares most of its files folds into that batch as contiguous commits on one branch. Each pull request pays a fixed cost a same-file slice cannot earn back, and the rebases between stacked slices land on the same files.
 
 ### Judged apart
 
-Keep a batch apart only where a reviewer or the operator would judge it apart. Write that reason as ``Judged apart from `feature-<parent>`: <reason>`` in the batch's `**Constraints:**`.
+Keep a batch apart only where a reviewer or the operator would judge it apart. Write that reason as ``Judged apart from `feature-<parent>`: <reason>`` in the batch's `## Constraints`.
 
 - A contract a later batch is built against
 - A taste call the operator judges in its own sitting
@@ -61,12 +61,12 @@ Keep separate pull requests when the pieces are independent features, when one n
 
 ### Declaring the set
 
-Each side names the other in its `**Constraints:**`, and `canon records validate plans` reports `fan-in-unmatched` wherever the two disagree.
+Each side names the other in its `## Constraints`, and `canon records validate plans` reports `fan-in-unmatched` wherever the two disagree.
 
 - A member writes ``Fan-in member of `feature-<integrator>` ``, naming one integrator
 - The integrator writes ``Fans in `feature-<a>`, `feature-<b>`, and `feature-<c>` ``, in the order it merges them
 - The task's `Plan:` line cites every member and the integrator, since the merge archives only the plans that line cites and a live integrator listing archived members reports `fan-in-unmatched`
-- The integrator is its own plan, since its writes, being the shared lists, the citer repoints, and the index regeneration, need a `**Files to touch:**` of their own
+- The integrator is its own plan, since its writes, being the shared lists, the citer repoints, and the index regeneration, need a `## Files to touch` of their own
 
 `canon tasks plan-answers` holds a member whose integrator is missing or does not list it with a `Fan-in set` entry. It holds the integrator with a `Fan-in pending` entry until every member branch is on origin.
 

package/claude/skills/plan-feature/references/plan.md

@@ -58,9 +58,9 @@ A plan carries no frontmatter. Its filename is the whole of its identity, so a f
 
 ### Staged batches
 
-A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `**Files to touch:**`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges.
+A staged batch is a concern of its own and takes its own file rather than a `**Batch N**` sub-heading inside one plan's `## Files to touch`. One plan filename derives one branch, so batches sharing a file have nothing to open a pull request against once the first merges.
 
-- State a batch's dependency on the ones before it in its own `**Constraints:**`
+- State a batch's dependency on the ones before it in its own `## Constraints`
 - A batch stacking on another and sharing most of its files folds into that batch as contiguous commits on one branch, rather than taking a file
 - It takes a file anyway when its constraints carry ``Judged apart from `feature-<parent>`: <reason>`` with a reason after the colon
 - `canon records validate plans` reports `stack-foldable` for a stacked batch that has neither
@@ -69,27 +69,46 @@ A staged batch is a concern of its own and takes its own file rather than a `**B
 
 The document opens with `# Feature: <short title>` and one paragraph stating what is being built and why now. The sections below follow in this order.
 
-| Section                  | Holds                                                                       | Required                                          |
-| ------------------------ | --------------------------------------------------------------------------- | ------------------------------------------------- |
-| `## Summary`             | three to five one-line bullets: the goal, the deliverables, the trade-off   | Always                                            |
-| `**Constraints:**`       | durable rules the work must respect                                         | When supplied                                     |
-| `**Files to touch:**`    | each file with a one-line reason                                            | Always                                            |
-| `**Design references:**` | the tracked design folders the change builds against, each with its surface | When Files to touch names a rendered-surface file |
-| `**Verification:**`      | the test or command that proves each outcome                                | Always                                            |
-| `**Risks:**`             | conflicts, coupling, and the tricky spots                                   | Always                                            |
-| `**Review focus:**`      | the inputs or states that would break the change, for the reviewer          | Always                                            |
-| `**Questions:**`         | numbered open decisions, each with a suggestion and an answer slot          | Always                                            |
-| `**Sources:**`           | the outside sources a decision rests on, each with its quoted passage       | When a decision rests on an outside source        |
-
-- Write each marker as the table gives it. `Summary` opens the prose a reader scans, so it takes an H2, and the others are labels over lists rather than sections of prose.
-- A section in the other spelling is still that section, since `## Risks` and `**Risks:**` name one thing, and either spelling breaks a depth run
-- Write the table's form in a new plan and leave an existing plan's spelling alone
+| Section                | Holds                                                                       | Required                                          |
+| ---------------------- | --------------------------------------------------------------------------- | ------------------------------------------------- |
+| `## Summary`           | three to five one-line bullets: the goal, the deliverables, the trade-off   | Always                                            |
+| `## Constraints`       | durable rules the work must respect                                         | When supplied                                     |
+| `## Files to touch`    | each file with a one-line reason                                            | Always                                            |
+| `## Design references` | the tracked design folders the change builds against, each with its surface | When Files to touch names a rendered-surface file |
+| `## Verification`      | the test or command that proves each outcome                                | Always                                            |
+| `## Risks`             | conflicts, coupling, and the tricky spots                                   | Always                                            |
+| `## Review focus`      | the inputs or states that would break the change, for the reviewer          | Always                                            |
+| `## Questions`         | numbered open decisions, each with a suggestion and an answer slot          | Always                                            |
+| `## Sources`           | the outside sources a decision rests on, each with its quoted passage       | When a decision rests on an outside source        |
+
+- Write each section as the H2 the table gives, so a reader scans the plan by its outline
+- A section written as a bold label, the spelling before this one, is still that section to every parser. Leave an existing plan's spelling alone.
 - Write `None identified.` under a required section with nothing to report rather than dropping the marker. A dropped section and an unconsidered one read identically.
 - Aim `## Summary` at a person scanning the plan, not at the session executing it. The other sections carry what execution needs.
 
+### Structure
+
+Every hand-written record under `.canon/` holds to six criteria, being a plan, a groundwork file, an intake item, a task, a session map, and a compact note. None caps length, since a record follows the change it describes and is disposable once it ships.
+
+| ID   | Criterion                                                                    |
+| ---- | ---------------------------------------------------------------------------- |
+| `S1` | An H2 per section, never a bold label standing alone as a section marker     |
+| `S2` | A section past 5 plain bullets groups them under H3s                         |
+| `S3` | An H3 opens with a lead sentence carrying what its bullets share             |
+| `S4` | A bullet past 200 characters becomes a short paragraph or splits             |
+| `S5` | No H4                                                                        |
+| `S6` | A section a parser reads names every path in full, whatever H3 it sits under |
+
+A run of labeled field bullets, each opening on a bold label, is exempt from `S2`, as `markdown.md` exempts it. An intake item's fields are also exempt from `S4`, and its numbered H3 from `S3`, since the item template fixes both.
+
+- `canon records validate <kind> <record>` reports `S1` to `S5` under `structure`, and never in the exit, since every record written before the criteria misses `S1`
+- `canon tasks plan-reach` reports an `S6` miss as an unclaimed bare filename
+- A writing skill reads the report for the one record it wrote and fixes each entry before it stops
+- An existing record takes the shape on its next rewrite, never in a sweep
+
 ### Files to touch entries
 
-Give every `**Files to touch:**` entry a backticked path and something said about it. A bare path states scope and not intent, and the reason is what an executing session checks its edit against.
+Give every `## Files to touch` entry a backticked path and something said about it. A bare path states scope and not intent, and the reason is what an executing session checks its edit against.
 
 - Lead with the path or with a label carrying the path, whichever reads better for the entry
 - Separate the two halves with a colon, and keep every path the entry declares ahead of it, since what sits before the colon reads as a target
@@ -97,6 +116,8 @@ Give every `**Files to touch:**` entry a backticked path and something said abou
 - Read the list as what the branch sets out to write rather than a bound, since the doc syncs at ship write past it on nearly every branch
 - `canon tasks plan-reach <plan>` reads the branch back against this list and every other live plan
 
+Group the entries by area under H3s once they pass 5, each H3 opening on the reason its files share. Every entry still names its full path, since the parsers read the bullet and never the heading above it.
+
 ### Measured claims
 
 State every count and every claim about the tree as measured during the pass that wrote the plan. A figure carried in from a summary or an earlier session is the most common way a plan ships the wrong scope.
@@ -114,11 +135,13 @@ Write a hold only for a dependency, a contract the other track consumes, a reloc
 - Decide both acts for every surface a hold names, not for one file among its siblings.
 - Write a shared path as the track, the path, and the branch that rebases, being the one merging second. The executing session edits the file and keeps both sides on the rebase.
 
+Open the section on the stamp line, then group the constraints under an H3 per kind once they pass 5, such as In flight, Contracts, Shared paths, and Durable.
+
 ### Stamping a constraint
 
 A constraint measured against work in flight expires when that work merges, as a shared-path line does, so stamp the block with what it was measured against.
 
-- Give the stamp its own leading bullet, written as Measured against `<commit>` on <YYYY-MM-DD>. One stamp covers the whole block.
+- Give the stamp its own leading line, written as Measured against `<commit>` on <YYYY-MM-DD>. One stamp covers the whole section.
 - Stamp the commit rather than the track names or a date alone, since a date does not separate two plans written either side of a merge
 - Read an unstamped constraint as unverified rather than as live, and confirm it against the open pull request list for the named paths.
 
@@ -132,11 +155,11 @@ git fetch origin main --quiet && git log <commit>..origin/main --oneline -- <the
 
 A batch in a fan-in set declares its side in a constraint bullet, ``Fan-in member of `feature-<integrator>` `` on a member and ``Fans in `feature-<a>`, `feature-<b>` `` on the integrator. `batches.md` holds when to fan in, and `canon records validate plans` reports `fan-in-unmatched` for a set whose two sides disagree.
 
-A constraint naming a `.canon/ready/` folder is a third shape beside the hold and the shared path. It makes that folder's files the verbatim source for the paths this plan's `**Files to touch:**` lists, per `ready.md`, so the executing session copies those paths rather than authoring them.
+A constraint naming a `.canon/ready/` folder is a third shape beside the hold and the shared path. It makes that folder's files the verbatim source for the paths this plan's `## Files to touch` lists, per `ready.md`, so the executing session copies those paths rather than authoring them.
 
 ### Design references
 
-A plan whose `**Files to touch:**` names a rendered-surface file (`.tsx`, `.jsx`, `.astro`, `.vue`, `.svelte`, `.html`, or `.css`) carries this section. It tells the building session which accepted design to open before it writes a line.
+A plan whose `## Files to touch` names a rendered-surface file (`.tsx`, `.jsx`, `.astro`, `.vue`, `.svelte`, `.html`, or `.css`) carries this section. It tells the building session which accepted design to open before it writes a line.
 
 - Give each entry a folder path under `canon/design/` and the surface it governs, as one bullet
 - Write `None identified.` when the project has no `canon/design/` folder or no folder governs the change, so the section reads as considered
@@ -153,7 +176,7 @@ Every outcome reaches the review with its proof named.
 
 ### Risks
 
-Name the collision rather than the category, since a risk a reader cannot act on is padding.
+Name the collision rather than the category, since a risk a reader cannot act on is padding. Give each risk its own H3 and a short paragraph, so the outline lists every collision by name.
 
 - For a resource with more than one consumer, list the consumers and mark each read or write, so a policy over it holds for every writer
 - For a changed contract another track consumes, such as an exported signature, a verb's flags or record, or a config key, name it and list each consumer
@@ -165,7 +188,7 @@ This section is where the planner's understanding of the risk reaches the review
 
 - Name each input or state that would break the change if the implementation got it wrong, one bullet each, with what the change must do there.
 - Write it for the reviewer rather than the builder
-- Keep it apart from `**Risks:**`. A risk is something the work might collide with, and a focus item is something the finished diff must be shown to handle.
+- Keep it apart from `## Risks`. A risk is something the work might collide with, and a focus item is something the finished diff must be shown to handle.
 
 ### Sources
 
@@ -221,6 +244,8 @@ This contract inverts the one an intake folder keeps, where an empty slot means
 
 ## Template
 
+Each H3 below shows where a section groups once it passes 5 bullets. A section of 5 or fewer drops its H3s and keeps its bullets flat, except `## Risks`, which takes an H3 per risk at any count.
+
 ```markdown
 # Feature: <short title>
 
@@ -232,40 +257,64 @@ This contract inverts the one an intake folder keeps, where an empty slot means
 - <one-line bullet covering the main deliverables>
 - <one-line bullet covering the key decision or trade-off>
 
-**Constraints:**
+## Constraints
+
+Measured against `<commit>` on <YYYY-MM-DD>.
+
+### In flight
+
+This plan shares <what> with the work in flight.
 
-- Measured against `<commit>` on <YYYY-MM-DD>
 - <a hold: the work in flight, its file set, and which of the two acts the constraint forbids>
 - <a shared path: the work in flight, the path, and which branch rebases>
+
+### Durable
+
+The rules below protect <what>.
+
 - <durable rule the work must respect>
 
-**Files to touch:**
+## Files to touch
+
+### <Area>
+
+The files below share <the reason>.
 
 - `<path/to/file>`: <reason>
 
-**Design references:**
+## Design references
 
 - `canon/design/<surface>/`: <the surface it governs>
 
-**Verification:**
+## Verification
+
+### <Outcome group>
+
+The checks below prove <what> together.
 
 - <outcome>: `<test or command that proves it>`
 
-**Risks:**
+## Risks
+
+### <The collision, named>
 
-- <conflict, coupling, or tricky spot>
+The collision is <what>, read or written by <each consumer>, and the work <does what about it>.
 
-**Review focus:**
+## Review focus
 
 - <input or state that would break the change>: <what the change must do there>
 
-**Questions:**
+## Questions
+
+### <Topic>
+
+The questions below decide <what>, numbered across the whole section.
 
 1. <question>
    - Suggested: <pick>, <reason or tradeoff>
    - Answer:
 
-**Sources:**
+## Sources
 
 - [<title>](url), backing <decision>: "<passage relied on>"
 ```

package/claude/skills/plan-groundwork/SKILL.md

@@ -134,6 +134,14 @@ The standard sets the open question format inside a topic file and in `00-scope.
 
 Aside from an experiment fixture, Steps 4 and 5 are the only ways close mode reaches outside the folder. Do not close while an open question quietly fails an outcome. Resolve it, or record it in `06-decision.md` as knowingly accepted.
 
+## Check the folder
+
+Run `canon records validate groundwork <nn>-<slug>` on the folder this run wrote, in every mode, before reporting. Fix each entry its `structure` array names, against `### Structure` in `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`.
+
+- Pass the slug every time, since the bare kind reads every old track and buries this one under their entries
+- Read the array rather than the exit, which a structure entry never sets
+- Say the check did not run when the binary carries no `structure` key, rather than reporting the folder clean
+
 ## Output
 
 Emit the full relative path from the project root for every file written or updated, since a bare filename names a file the reader cannot open. Read `${CLAUDE_SKILL_DIR}/references/output.md` on reaching this step for the open and resume template, the retell, and the close template. A run that stops on a guard skips it.

package/claude/skills/plan-groundwork/references/groundwork.md

@@ -107,6 +107,7 @@ Facts before opinion. Verified measurement only, taken during this pass.
 - Never carry a figure from a previous session without re-measuring, since every number built on a stale one is quietly wrong.
 - Mark an inference as an inference where one is unavoidable.
 - Measure only what an open question needs. A number with no question attached is how the groundwork becomes the work.
+- Give each measurement an H3, as a topic file gives each question one
 
 ## 00-scope.md
 
@@ -154,7 +155,7 @@ A lean is weaker than a plan's suggestion: it records the current read on an ope
 
 ## Template
 
-The orienting README comes first, then the closing decision, with an H3 per dropped alternative.
+The orienting README comes first, then the closing decision.
 
 **`README.md`**
 

package/claude/skills/plan-intake/SKILL.md

@@ -91,6 +91,14 @@ Write `00-overview.md` last, once the clusters are filed and the counts are real
 - Add `99-next-session.md` only where the pass ends holding context no cluster file carries, such as a dump half filed or a measurement to redo
 - Write that file self-contained, since a compaction drops the conversation behind it whether or not the folder is backed
 
+## Step 7: check the folder
+
+Run `canon records validate intake <nn>-<slug>` on the folder this pass wrote, and fix each entry its `structure` array names before reporting. An `intake-spill` entry is content under a field that `canon intake list` never shows the operator, so move it onto the field's line or split the item.
+
+- Pass the slug every time, since the bare kind reads every old dump and buries this one under their entries
+- Read the array rather than the exit, which a structure entry never sets
+- Say the check did not run when the binary carries no `structure` key, rather than reporting the folder clean
+
 ## Output
 
 Emit the full relative path of every file written, with the heading and the act beside it. A bare path cannot tell three new items from one reworded sentence in a long-lived file, so the reader would diff against memory.

package/claude/skills/plan-intake/references/intake.md

@@ -119,7 +119,15 @@ Where an item touches a task already on the board, say so in the index rather th
 - Where the answer is the operator's preference rather than a technical call, say so in that form rather than inventing a default
 - `Overlaps:` never replaces `Worth it:`, since an item a live board task might have wrong is the one whose verdict matters most
 
-Two heading levels is the right depth inside a cluster file. A third means the cluster should have been its own file. An item may carry a rare bolded standalone line between the bullets where a finding needs a name of its own, and everything fitting the four bullets belongs in them.
+### One line per field
+
+A field keeps all its content on its own line, with no nested list, paragraph, or standalone line under it or after the last field. `canon intake list` reads a field's line and nothing below it, so a nested line never reaches the operator answering in chat.
+
+- Write a list the Problem needs inline, separated by commas, rather than as nested bullets under a line ending on a colon
+- Split an item too big for its fields into two, numbered as `3a` and `3b`, rather than stretching one field across lines
+- `canon records validate intake <slug>` reports each block sitting under a field as `intake-spill` under `structure`
+
+Two heading levels is the right depth inside a cluster file. A third means the cluster should have been its own file. A cluster file otherwise holds to the six structure criteria under `### Structure` in `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`, with an item's fields exempt from `S4` and its numbered heading from `S3`.
 
 ## The answer contract
 

package/claude/skills/plan-ready/REQUIREMENT.md

@@ -7,7 +7,7 @@ description: Why writing a ready folder, its overview, the thin plan, and the ta
 
 ## Gap
 
-A session handing finished files to a worker writes the folder, the overview, the plan, and the task row by hand, and the four drift. A destination missing from the plan's `**Files to touch:**` is invisible to `plan-reach`, so a second track writes the same file.
+A session handing finished files to a worker writes the folder, the overview, the plan, and the task row by hand, and the four drift. A destination missing from the plan's `## Files to touch` is invisible to `plan-reach`, so a second track writes the same file.
 
 Numbering scans one place, so an ordinal can reuse a number an archive already spent, and a bare phase label reserves nothing. A draft beside the real files, or no verbatim-source line, sends the worker off to write its own version. A main-root write from a worktree lands in a copy nobody reads, and the archive move goes unreported.
 
@@ -15,8 +15,8 @@ Numbering scans one place, so an ordinal can reuse a number an archive already s
 
 - Refuse before writing when the operator named no finished file or a named file does not resolve
 - Read the ordinal from the live folder and the archive together, and take the label from `canon tasks next-label --claim`, stopping on a binary that predates the flag
-- Derive the overview's `destinations` and the plan's `**Files to touch:**` from one list and compare them before reporting
-- Copy each finished file whole into the folder with nothing else, and write the plan's `**Constraints:**` line naming the folder as the verbatim source
+- Derive the overview's `destinations` and the plan's `## Files to touch` from one list and compare them before reporting
+- Copy each finished file whole into the folder with nothing else, and write the plan's `## Constraints` line naming the folder as the verbatim source
 - Place the task's row by the branches `task-board` states, route main-root writes through `Bash`, and name the archive move in the closing report
 
 ## Must not

package/claude/skills/plan-ready/SKILL.md

@@ -67,9 +67,9 @@ install -D -m 0644 <source> <main-root>/.canon/ready/<nn>-<slug>/<destination pa
 
 Write `<main-root>/.canon/plans/feature-<slug>.md` from the template, by heredoc, per `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`.
 
-- List every Step 1 destination under `**Files to touch:**`, each with one clause on why it changes, pointing at the folder's copy rather than restating it.
-- Add a `**Constraints:**` line naming the ready folder as the verbatim source for those paths.
-- Name the branch type from Step 1 in `## Summary`. Write `None identified.` under `**Questions:**` unless a call is genuinely the operator's.
+- List every Step 1 destination under `## Files to touch`, each with one clause on why it changes, pointing at the folder's copy rather than restating it.
+- Add a `## Constraints` line naming the ready folder as the verbatim source for those paths.
+- Name the branch type from Step 1 in `## Summary`. Write `None identified.` under `## Questions` unless a call is genuinely the operator's.
 
 Run the match check in `${CLAUDE_SKILL_DIR}/references/assembly.md` before going further. The two lists are one list, and a path in either without the other stops the run.
 

package/claude/skills/plan-ready/references/assembly.md

@@ -38,35 +38,35 @@ destinations:
 - <what the change does, one bullet per file group>
 - <branch type and what the worker still owns>
 
-**Constraints:**
+## Constraints
 
 - `.canon/ready/<nn>-<slug>/` holds the verbatim source for every path below. Copy each file whole rather than reading it as a description and writing a version.
 - <a live plan or run row holding a path, when one exists>
 
-**Files to touch:**
+## Files to touch
 
 - `<path/to/file>`: copy from the ready folder, <one clause on what it changes>
 
-**Verification:**
+## Verification
 
 - <the command that proves the copy landed, or "None identified.">
 
-**Risks:**
+## Risks
 
 - <what could go wrong, or "None identified.">
 
-**Review focus:**
+## Review focus
 
 - <an input the copied files must handle, or "None identified.">
 
-**Questions:**
+## Questions
 
 None identified.
 ```
 
 ## The destination match check
 
-Read the overview's `destinations` and the plan's `**Files to touch:**` paths, then compare the two sets:
+Read the overview's `destinations` and the plan's `## Files to touch` paths, then compare the two sets:
 
 - A path in `destinations` and not in the plan is invisible to `plan-reach`, so the plan gains the line.
 - A path in the plan and not in `destinations` names a file the folder does not carry, so either the folder gains the file or the plan loses the line.

package/claude/skills/plan-ready/references/ready.md

@@ -44,7 +44,7 @@ A ready folder works when a worker that has never seen the warm session's conver
 - Which destination path does each file land at, and does the folder hold nothing else?
 - What is the worker still responsible for that the files themselves do not carry, such as a docs sync, a sandbox scenario, or a test?
 - What branch type does the change take?
-- Is every path the folder mirrors also declared in the thin plan's `**Files to touch:**`?
+- Is every path the folder mirrors also declared in the thin plan's `## Files to touch`?
 
 A ready folder failing these is non-conforming even when it satisfies every shape rule below.
 
@@ -63,7 +63,7 @@ Every ready folder carries `00-overview.md` at its root, beside the mirrored tre
 - `title` (required): the change in sentence case
 - `description` (required): one line naming what the handoff carries
 - `type` (required): the branch type the plan should take, one of the types `branch.md` fixes
-- `destinations` (required): the list of destination paths the folder mirrors, matching the thin plan's `**Files to touch:**` exactly
+- `destinations` (required): the list of destination paths the folder mirrors, matching the thin plan's `## Files to touch` exactly
 
 ```yaml
 ---
@@ -77,6 +77,8 @@ destinations:
 
 Below the frontmatter, state in prose what the worker still owns beyond copying the files: a docs sync, a sandbox scenario update, a test the files do not include, or "nothing further" where the files are the whole of the change.
 
+The overview body and the thin plan both hold to the six structure criteria under `### Structure` in `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan.md`. The mirrored files are exempt, since each lands as its destination's own standard fixes.
+
 ## The mirrored tree
 
 Every other file in the folder sits at the same relative path its destination has in the project.
@@ -88,10 +90,10 @@ Every other file in the folder sits at the same relative path its destination ha
 ## The thin-plan contract
 
 - A ready folder ships through an ordinary task row and a plan at `.canon/plans/feature-<slug>.md`, per `plan.md`. No new plan shape exists for it.
-- Name the ready folder in the plan's `**Constraints:**`, stating that the folder's files are the verbatim source for the paths the plan's `**Files to touch:**` lists.
-- List every destination path in `**Files to touch:**`, matching `00-overview.md`'s `destinations` field
+- Name the ready folder in the plan's `## Constraints`, stating that the folder's files are the verbatim source for the paths the plan's `## Files to touch` lists.
+- List every destination path in `## Files to touch`, matching `00-overview.md`'s `destinations` field
 - A path the plan omits is invisible to `plan-reach`'s collision check, so a mismatch between the two lists is a defect in the plan, not a variant
-- Keep the plan thin. Its `**Files to touch:**` entries may point at the folder's copy for the reason behind each file, since the overview and the files carry that detail.
+- Keep the plan thin. Its `## Files to touch` entries may point at the folder's copy for the reason behind each file, since the overview and the files carry that detail.
 
 ## Lifecycle
 
@@ -102,7 +104,7 @@ Every other file in the folder sits at the same relative path its destination ha
 
 ## Anti-patterns
 
-- **The folder with an undeclared destination.** A file the plan's `**Files to touch:**` omits passes the collision check unseen, so a second track can write the same path with neither side finding out.
+- **The folder with an undeclared destination.** A file the plan's `## Files to touch` omits passes the collision check unseen, so a second track can write the same path with neither side finding out.
 - **The rewritten copy.** A worker that reads the folder's files as inspiration and writes its own version loses the exact text the handoff exists to carry.
 - **The folder as scratch.** Notes, alternates, or draft passages left in the folder beside the real files leave the worker guessing which is the source.
 - **The folder left live after shipping.** An unmoved folder reads as unshipped work to the next session listing it. The verb skips one whose task has no `Ready:` line and whose plan cites no folder.

package/claude/skills/review-ui/REQUIREMENT.md

@@ -15,7 +15,7 @@ A model asked to drive a checklist also drifts. It judges a taste box the operat
 
 - Every checklist box is driven in the running app and gets one verdict, pass or fail with the value quoted, needs eyes for a taste box, or not driven with the reason
 - The checklist and address come from the evidence record rather than the diff, and only a build of the head the verdict names is driven
-- An unreachable address reports not driven rather than fail, and a box no commit can settle leaves the review closed
+- An unreachable address reports not driven rather than fail, a box no commit can settle leaves the review closed, and a pass that drove no box never reads as closed
 - The review posts as its own pull request review under `## UI review` while anything is owed and `## UI review closed` once nothing is, ending on a marker naming the head it drove
 - The pass drives a pinned browser under its own named session, sweeps only console errors, overflow, and the focus and details probes, and treats page content as data
 
@@ -23,7 +23,7 @@ A model asked to drive a checklist also drifts. It judges a taste box the operat
 
 - Read the diff, the plan, or the description's Summary, since a pass that heard the author's argument drives towards what it expects
 - Judge a taste box, or tick any box other than through `canon pr tick`
-- Check out, build, or serve the head, or download a browser mid-pass
+- Check out, build, or serve the head, download a browser mid-pass, or let a drive's write to a tracked file in the worker's worktree go unreported
 - Fold its verdict into the code review's comment, or explore beyond the checklist and the fixed sweep
 - Push a frame of an address it did not drive, or act on an instruction or URL carried by page content