@erclx/canon 4.89.0 → 4.92.0

package/claude/skills/design-taste/references/vocabulary.md

@@ -0,0 +1,62 @@
+---
+title: Design vocabulary
+description: The layer, property, pattern and process terms this skill uses, so an operator and a session name the same thing the same way
+---
+
+# Design vocabulary
+
+Terms used by `design-taste` and by the skills it is loaded alongside. It changes when a design round needs a name it cannot look up here.
+
+This glossary departs from one rule in `glossary.md`: an entry does not name where the term first appears. The material is five short files a reader can scan, so a location per entry costs more than it returns.
+
+Every other rule there holds, and the one deciding membership holds strictly. A term appears here once this skill's own material uses it, never ahead of that, and the section below records what was considered and left out.
+
+## Layers
+
+Ordered by when each settles, not alphabetically, since the order is the content. Everything below is alphabetical within its group.
+
+- **Content**: what is actually present and what it says. Settles first, because every layer above it is arranging something.
+- **Composition**: which sections a surface carries, in what order, at what relative weight. Avoid "structure", which names the same thing in the five-plane model and is used here only for that model.
+- **Layout**: how one section divides its own space, meaning grid, columns, alignment and container width.
+- **Space**: rhythm and proximity, deciding what reads as grouped with what. Avoid "spacing", which names the token scale rather than the decision.
+- **Typography**: scale, weight, measure, casing and pairing.
+- **Surface**: elevation, border, radius and fill. The same word commonly names a place content is published to, so say "the surface layer" wherever both readings are in reach.
+- **Palette**: ground, accent, saturation and contrast. The values themselves live in the project's design document, never here.
+- **Imagery**: what a picture carries and where it sits.
+- **Motion**: what moves, why, and how far.
+
+## Properties
+
+- **Casing**: whether text is set upper, lower, title or sentence case, treated as a hierarchy decision rather than a typing one.
+- **Density**: how much information a given area carries. High density is correct in an application surface and reads as clutter on a marketing one, which is why it belongs to the kind rather than to taste.
+- **Hierarchy**: the order a reader takes things in, produced by weight, color, space and position together rather than by size alone.
+- **Ground**: the surface a thing sits on, whether the page behind everything or the fill behind one element. Named apart from "background" because the relationship that matters is what sits against it.
+- **Line height**: the vertical distance from one baseline to the next, set against size rather than fixed across a scale. Avoid "leading", which names the same thing.
+- **Measure**: the length of a line of text, capped so the eye finds the next line.
+- **Orphan**: a single word left alone on the last line of a heading or paragraph.
+- **Scale**: the fixed set of sizes a surface draws from, for type or space.
+- **Tabular figures**: numerals drawn to one shared width, so a column of changing numbers does not shift as it updates.
+- **Tracking**: the letter spacing applied across a run of text, set by size rather than by taste.
+
+## Patterns
+
+Named compositions, carried so an operator can ask for one by name instead of describing it. A pattern earns an entry once this skill's own material names it, never ahead of that.
+
+- **Chrome**: the persistent frame around content, being navigation, status and context, which is read constantly and looked at rarely.
+- **Eyebrow**: the small wide-tracked label sitting above a heading, usually uppercase. The term matters because the budget is countable: no more than one per three sections.
+- **Hairline**: a rule thin enough to separate without dividing, used where a border would read as a box.
+- **Marquee**: a strip of content sliding horizontally on a loop, independent of the reader's scroll.
+- **Scrollspy**: a persistent index marking which section the reader is currently in as they scroll.
+
+## Process terms
+
+How a draft is staged while unfinished.
+
+- **FPO**: a placeholder held at the true final size and marked as a placeholder, from print production where it abbreviates "for position only". Marking it is the point, since an unmarked stand-in gets read as a decision.
+- **Greeking**: standing text in for copy that does not exist yet, of which lorem ipsum is the common form. Correct while judging space and wrong once an arm is judged on content.
+- **Grey-box**: drawing every element as a flat neutral block so the layers above the one under judgment are removed from view. Avoid "wireframe", which names a committed document governed by `${CLAUDE_SKILL_DIR}/../../standards/wireframes.md` rather than a drafting stage.
+
+## Terms this vocabulary deliberately does not carry
+
+- **Magic number**: an unexplained hardcoded value. The term already means that in code, so it is not redefined here as a design term.
+- **Glyph**: a single rendered character. A typographic unit rather than a pattern, and nothing here needs the word.

package/claude/skills/docs-fold/REQUIREMENT.md

@@ -28,6 +28,8 @@ This skill writes canonical docs at the end of a long build and never reviews wh
 - Write tracked docs at the current worktree root and the task board at the main root, since only the first commits with the branch
 - Count every other citation before archiving a plan, comparing resolved targets rather than raw strings or bare filenames
 - Retarget a closed task at the archived plan, so the reasoning behind finished work stays reachable
+- Write a decision to the domain context entry it constrains unless it fills an architecture slot, since reach admits nearly every decision to an always-loaded file
+- Merge or retire an architecture entry before adding one at the record's stated cap, and name which in the report, so the cap never turns into compressed prose or two decisions packed under one heading
 - Anchor a decision entry this run writes or amends whose reasoning cites a measured number, re-reading the number against the tree before writing the marker
 - Report an anchored decision whose cited path the diff touched, since the number was read before the branch moved what it counted
 - Scan every memory-review receipt rather than the one matching this slug, since the skill that writes them runs after this one in the ship chain and a slug is unique per feature

package/claude/skills/docs-fold/SKILL.md

@@ -110,6 +110,8 @@ Read `ok` and `reason` out of that record rather than the exit. An operator's sh
 - Do not rewrite sections unrelated to what changed.
 - Rewrite a restated or superseded statement in place rather than appending the replacement beside it. State the fact that stands and keep the earlier reasoning only where it is the alternative that lost, per `${CLAUDE_SKILL_DIR}/../../standards/context.md` and `${CLAUDE_SKILL_DIR}/../../standards/architecture.md`.
 - Follow `${CLAUDE_SKILL_DIR}/../../standards/markdown.md` and the `write-human` skill for all edits.
+- Write a session decision into the `canon/context/` entry for the domain it constrains, under that entry's `## Decisions`, by default. Touch `canon/ARCHITECTURE.md` only for a decision that fills one of the slots `${CLAUDE_SKILL_DIR}/../../standards/architecture.md` names, however many domains its reasoning reaches.
+- Read the entry cap the record states before adding a decision to it. At the cap, merge two decisions or retire one to the domain entry it constrains, and name which in the report. Never compress a decision's prose to fit, and never pack two decisions under one heading.
 - Close a decision entry in `canon/ARCHITECTURE.md` with its verification anchor whenever this run writes that entry or amends its reasoning and that reasoning cites a measured number. Re-read the number against the tree first, since the marker records the read rather than the edit. `${CLAUDE_SKILL_DIR}/../../standards/architecture.md` fixes the sentence.
 - Leave every decision entry this run did not write alone, anchored or not. The rule is scoped forward, so an entry written before it is dated by blame rather than by a read. Step 5 reports a stale anchor and no step writes one on an entry it did not amend.
 
@@ -269,6 +271,10 @@ Output one line per file updated:
 
 `✅ Updated: .claude/<filename>`
 
+When Step 3 met the architecture record's cap, add one line naming what it did there:
+
+`↪ Architecture at cap: merged <heading> into <heading>` or `↪ Architecture at cap: retired <heading> to <context entry>`
+
 Step 10 adds its own lines when it applied or reported a finding, in the exact shape `${CLAUDE_SKILL_DIR}/references/classify.md` gives them under its own Report section. Do not shorten or paraphrase those lines here or in the reply, since the quote and the reason are what a reader checks the finding against.
 
 If no files were updated and nothing was swept, output:

package/claude/skills/draft-and-pick/REQUIREMENT.md

@@ -25,13 +25,19 @@ Without this skill, a session facing a decision nobody can settle from a diff:
 - Looks at a render to confirm it came out rather than to judge whether it is worth showing, which satisfies the rule against reporting an unseen result and still hands over weak work.
 - Writes the run's renders to a scratch path outside the record that cites them, leaving the folder holding source markup and none of the images, so the judgment is unreachable to everyone except the session that made it.
 - Narrows the page onto the picked arm in place on each iteration, so every earlier round is overwritten and a later pass cannot see what was already rejected.
+- Names no layer at all, since the instruction to name one carries no catalog to name from and nothing reports the omission. Four consecutive rounds against one page each varied a property at the top layer while the defect sat two below it, and three of the four changed nothing the operator could see.
+- Judges a lower layer through a finished higher one, so an operator asked about composition looks at the palette instead and answers about that.
+- Hands over the combined page alone for a decision about layout, where every arm sits in a column while the media queries answer to the whole window, so no arm is ever seen at its own viewport and a fault that appears only narrower survives the pick.
+- Sets the theme on an arm that persists its own and reads it back on load, so the control reports one theme while the arm renders the other and the set is compared across two.
 
 ## Must
 
 - Produce three to five arms with the shipping state among them, each carrying an id, a label, and what the arm costs.
 - Author the whole candidate set as one self-contained page and render it once, so the comparison arrives as one image, except where the surface under decision is a running app: there the page links a copy of the built stylesheet rather than inlining it, per `references/live-arms.md`.
-- Name the layer the decision lives at before drafting, and vary the arms at that layer alone, so the answer names the difference that decided it rather than the cheapest one to change.
-- Render every arm in one theme at a time, with a control that sets the whole set, so the comparison holds still while the operator reads it.
+- Emit the layer in the run's own output, drawn from the catalog `design-taste` fixes rather than from a word invented per run, and vary the arms at that layer alone. A layer held privately is one nothing can report missing, which is how the instruction went unfollowed while every round passed its own rules.
+- Grey-box the set when the declared layer sits below typography, and say the set is grey-boxed when handing it over, so the operator reads a flat page as the question rather than as unfinished work.
+- Render every arm in one theme at a time, with a control that sets the whole set, so the comparison holds still while the operator reads it, and set the theme in a way that survives an arm reading its own stored preference back on load.
+- Hand over the per-arm file addresses beside the combined page where the declared layer is composition, layout or space, since only a whole-page file at a real viewport answers how an arm behaves at a width, and the browser's own device toolbar is the control.
 - Judge each render against a stated bar before handing it over, name the weakest thing on the page, and fix it where that sentence would embarrass the work.
 - Write each iteration to its own folder rather than narrowing the previous one in place, so every earlier round stays openable.
 - Write the run's renders inside the record that cites them wherever one exists, and reserve the scratch path for inputs that are re-runnable and cited by nothing.

package/claude/skills/draft-and-pick/SKILL.md

@@ -15,11 +15,12 @@ Some decisions are settled by looking rather than by reasoning, and no draft is
 
 ## Step 1: name the decision and the arms
 
-1. State the decision in one sentence, naming what changes between arms and what stays fixed. Name the layer that sentence puts the decision at, and check that the arms will differ there rather than somewhere cheaper to change.
-2. Derive a kebab slug from that sentence. Call the folder every file this run writes to `<dest>` below. `<dest>` is `.canon/tmp/<slug>/`, a nested `<slug>/` folder rather than a flat `<slug>-<file>.md`, which is the shape every temporary write in this project takes. Running inside a live `plan-groundwork` track is the one exception: `<dest>` is the track's own `evidence/<slug>/` instead, since a candidate render is evidence the track's decision file cites rather than spike input.
-3. Write one arm per candidate, each carrying an id, a label, and what the arm costs. An arm with no stated cost is not an option.
-4. Make the current state arm `0`, so the baseline is a candidate rather than an absence. A decision with nothing shipped yet says so and starts at arm `1`.
-5. Stop at three to five arms. Two is a comparison the operator can hold in prose, and past five the pick stops being a look and becomes a sort.
+1. State the decision in one sentence, naming what changes between arms and what stays fixed.
+2. Emit the design read in the run's own output, in the form `design-taste` fixes. The layer comes from that skill's ordered catalog rather than from a word invented here, and the arms differ at it rather than somewhere cheaper to change. A run emitting no read has not decided what it is drafting, and a missing line is visible where an unstated layer is not.
+3. Derive a kebab slug from that sentence. Call the folder every file this run writes to `<dest>` below. `<dest>` is `.canon/tmp/<slug>/`, a nested `<slug>/` folder rather than a flat `<slug>-<file>.md`, which is the shape every temporary write in this project takes. Running inside a live `plan-groundwork` track is the one exception: `<dest>` is the track's own `evidence/<slug>/` instead, since a candidate render is evidence the track's decision file cites rather than spike input.
+4. Write one arm per candidate, each carrying an id, a label, and what the arm costs. An arm with no stated cost is not an option.
+5. Make the current state arm `0`, so the baseline is a candidate rather than an absence. A decision with nothing shipped yet says so and starts at arm `1`.
+6. Stop at three to five arms. Two is a comparison the operator can hold in prose, and past five the pick stops being a look and becomes a sort.
 
 ## Step 2: author the candidate set as one page
 
@@ -29,10 +30,16 @@ Write every arm side by side on one self-contained HTML page at `<dest>/candidat
 - Wrap each arm's markup in the same class on both files, chosen once per run and reused everywhere, so one selector addresses an arm on the combined page and on its own standalone file alike.
 - Label each arm on the page with its id and its cost, so the render carries what the question will ask about.
 - Give the combined page one control that sets every arm's theme at once, beside whatever per-arm control the arms carry. A set spanning both themes cannot be compared, since the operator has to toggle each arm and hold the earlier ones in memory, which is the failure the single-page rule exists to prevent.
+- Set that theme so it survives the arm reading its own preference back. An arm that stores a theme and applies it on load will overwrite whatever the control set, which shows the control in one state and the arm in the other, and it passes a fresh browser profile because the stored value is not there yet.
+- Hand over the per-arm file addresses beside the combined page where the declared layer is composition, layout or space, and say that an arm is judged at a width by opening its own file in the browser's device toolbar. The combined page cannot answer that question at all: every arm sits in a column there while the media queries answer to the whole window, so each one renders its widest layout in a narrow space no matter how the window is sized. Build no width control of your own, since the browser already has one.
 - Take the live-app branch instead when the surface under decision is a running app: lift the rendered markup and link a copy of the built stylesheet rather than inlining, per `${CLAUDE_SKILL_DIR}/references/live-arms.md`.
 - On the default path, inline every style, script, and asset the page needs. The render reads the file off disk, so a page reaching for a build step or a network font renders without it and the arms differ by something nobody chose.
 - On the default path, declare a font stack the machine resolves, such as `system-ui` behind a generic fallback. The render refuses a page that would rewrap against a substitute rather than shipping a false comparison, so a page naming no font at all is refused on whatever the default resolves to.
+
+### What varies
+
 - Vary one property across the arms. A page whose arms differ in three ways answers no question, since the pick cannot say which difference decided it.
+- Grey-box the arms when the declared layer sits below typography, per `design-taste`. A set judged at composition that carries a finished palette is not grey-boxed, and the higher layers are what the operator will look at instead of the question. Say the set is grey-boxed when handing it over.
 - Vary the property the decision is about, which the rule above is satisfiable without. Holding composition fixed and varying color obeys it exactly and produces five skins of one design, because a set differing in the layer a reader notices least answers nothing. A palette is chosen to serve a composition, so it cannot be picked ahead of one.
 
 ## Step 3: render and hand off
@@ -96,6 +103,7 @@ Three rules no probe reaches:
 Cite these rather than restating them. A step reimplemented here rots against the skill that owns it.
 
 - `plan-feature` plans the work once the pick is made, and declares the pull request boundary that plan carries
+- `design-taste` carries the layer catalog, the ordering, grey-boxing, and the defaults an arm should reach past
 - `write-human` carries the voice for any copy an arm puts in front of a reader
 - `git-stage`, `git-pr`, and `git-followup` carry the commits and the pull request
 - `review-branch` and `review-address` run the review pass

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

@@ -0,0 +1,53 @@
+---
+name: draft-ready
+description: Why writing a ready folder, its overview, the thin plan, and the task row is one invocation rather than four hand writes, and where the boundary against the planning and shipping skills falls
+---
+
+# Draft ready requirement
+
+## Gap
+
+Without this skill, a session holding finished files that hands them to a worker:
+
+- Writes the folder, the overview, the plan, and the task row as four separate hand writes, and the four drift from each other because nothing compares them.
+- Lists a destination in the overview that the plan's `**Files to touch:**` omits, or the reverse. The omitted path is invisible to `plan-reach`, so a second track writes the same file and neither side finds out.
+- Picks the next ordinal by reading only the live folder, and reuses a number an archived folder already spent, which the pull request that shipped it cites by name.
+- Picks a phase label by scanning the live board alone, which is the scan that let two sessions hand out one label within minutes of each other.
+- Leaves the plan's `**Constraints:**` without a line naming the folder as the verbatim source, so the worker reads the files as inspiration and writes its own version.
+- Leaves a note, an alternate, or a draft passage in the folder beside the real files, so the worker guesses which one is the source.
+- Writes into the main worktree root from a linked worktree with `Edit` or `Write`, which the isolation guard refuses, and takes the refusal's redirect into a second gitignored copy no later session reads.
+- Reports the handoff as done while the archive move at the end, which no verb performs, is left for someone to remember.
+
+## Must
+
+- Refuse before writing when the operator has named no finished file, since a folder assembled from a description is a plan with extra steps.
+- Read the ordinal from the live folder and its archive together, so a spent number is never reused.
+- Take the phase label from `canon tasks next-label` rather than from a scan of its own.
+- Derive the overview's `destinations` and the plan's `**Files to touch:**` from one list, and compare the two before reporting, so neither can name a path the other lacks.
+- Write the plan's `**Constraints:**` line naming the folder as the verbatim source.
+- Copy each finished file whole to its destination path inside the folder, and carry nothing else into it.
+- Write the plan and the task through `canon tasks plan-link`, `canon records validate plans`, and `canon markdown audit` rather than by restating what those verbs check.
+- Place the task's row by the three branches `task-board` Step 4 states, so a solo project never ends with a task file on no surface.
+- Route a write at the main root from a linked worktree through `Bash`, per `085-worktrees.md`.
+- Name the archive move in the closing report, since the skill writes a folder that stays live until someone moves it.
+
+## Must not
+
+- Edit a finished file. The worker copies verbatim, so a change made here is a change the warm session should have made before invoking the skill.
+- Hardcode a branch type, which `branch.md` owns, or restate the folder shape, which `ready.md` owns.
+- Write `priority.md` or `backlog.md` where an orchestrator is on the roster or the session is a worker or planner, since one board writer at a time is what keeps a gitignored board safe. Those two cases report the row instead.
+- Automate the archive move. No verb owns the relocation, and a skill doing it by hand would be the second copy of a step the standard already states.
+- Dispatch or start the worker, which belongs to whoever runs the board.
+
+## Guards
+
+- No finished file named, stop: `❌ No finished file named. A ready folder carries text that already exists, so write the files first or use /canon:plan-feature.`
+- A named file that does not resolve, stop: `❌ <path> does not exist. Name a file that is already written.`
+
+## Out of scope
+
+- `plan-feature` writes a plan describing a change nobody has written yet. This begins from text already written and writes a plan thin enough to point at it.
+- `role-worker` copies the folder into a worktree and ships it. This stops once the three artifacts exist.
+- `task-board` creates a task file for a row with no ready folder. This writes the row it needs beside the folder and calls the same verbs.
+- `git-ship` ships a branch, and a ready folder never reaches one.
+- `standards/ready.md` owns the folder's shape and lifecycle, and this skill owns the procedure that produces it, the way `write-human` and `500-prose` split.

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

@@ -0,0 +1,118 @@
+---
+name: draft-ready
+description: Writes a ready folder for finished files, its `00-overview.md`, the thin plan that points at it, and the task with a board row placed, reported to an orchestrator, or left to the operator, in one invocation. Use when asked to "write a ready folder", "hand these files to a worker", "package these finished files for a worker", "make a ready handoff", or when a session already holds the exact text of a skill, rule, or doc and a worker should copy it rather than author it. Do NOT use to plan a change nobody has written yet, which is `plan-feature`, to copy a folder into a worktree and ship it, which is `role-worker`, or to file a task with no finished files behind it, which is `task-board`.
+---
+
+# Draft ready
+
+A warm session that has already written a change hands the exact text to the worker that ships it. This skill writes the three artifacts that handoff needs and stops before anyone is dispatched.
+
+Read these in parallel before writing:
+
+- `${CLAUDE_SKILL_DIR}/../../standards/ready.md`: the folder layout, the overview frontmatter, the mirrored tree, and the thin-plan contract
+- `${CLAUDE_SKILL_DIR}/../../standards/plan.md`: the plan's sections and its answer contract
+- `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`: the task file's shape and origin lines
+- `${CLAUDE_SKILL_DIR}/references/assembly.md`: the overview and thin-plan templates and the destination match check
+
+## Guards
+
+- If the operator named no finished file, stop: `❌ No finished file named. A ready folder carries text that already exists, so write the files first or use /canon:plan-feature.`
+- If a named file does not resolve, stop: `❌ <path> does not exist. Name a file that is already written.`
+- Resolve `<main-root>` as `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. The folder, the plan, and the task all live there.
+
+## Step 1: read the finished files
+
+1. Take each finished file with the destination path the operator gave it. A file arriving with no destination is asked for once, since the mirrored tree cannot place it.
+2. Read every file whole. The overview states what the worker still owns beyond copying, and that comes off the files, not off the operator's description of them.
+3. Take the branch type from `${CLAUDE_SKILL_DIR}/../../standards/branch.md`, never from a list carried here.
+4. Derive one kebab slug for the change. The folder, the plan, and the task all carry it.
+
+## Step 2: allocate the ordinal and the label
+
+Read `<main-root>/.canon/ready/` and `<main-root>/.canon/ready/archive/` together and take the highest `<nn>` across both, plus one. A folder set with no entry takes `01`. Keep this skill-local. No verb allocates a ready ordinal, and two writers running at once can claim one number, so re-read the folder immediately before Step 3 writes.
+
+Take the label from the verb rather than from a scan:
+
+```bash
+canon tasks next-label --json
+```
+
+Branch on the record's `label` rather than on the exit code. Report the verb as unavailable and stop when the installed binary carries no `next-label` subcommand, since a label picked by hand is the collision the verb exists to prevent.
+
+## Step 3: write the overview
+
+Write `<main-root>/.canon/ready/<nn>-<slug>/00-overview.md` from the template in `${CLAUDE_SKILL_DIR}/references/assembly.md`. Set `destinations` from the Step 1 list and nothing else, and state in prose what the worker still owns, or `nothing further` where the files are the whole change.
+
+## Step 4: mirror the tree
+
+Copy each finished file to `<main-root>/.canon/ready/<nn>-<slug>/<destination path>`, one command per file, so the tree mirrors the destinations exactly.
+
+```bash
+install -D -m 0644 <source> <main-root>/.canon/ready/<nn>-<slug>/<destination path>
+```
+
+- Copy whole and edit nothing. A change wanted now is made in the source file first and copied after.
+- Carry no notes, alternates, or drafts into the folder. Anything else belongs in the plan or the pull request body.
+- Write each of these at the main root through `Bash`, one plain command apiece. From a linked worktree `Edit` and `Write` are refused there, and the refusal's redirect names a second gitignored copy no later session reads, per `085-worktrees.md`. Create a whole new file with a heredoc.
+
+## Step 5: write the thin plan
+
+Write `<main-root>/.canon/plans/feature-<slug>.md` from the template, by heredoc, per `${CLAUDE_SKILL_DIR}/../../standards/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.
+
+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.
+
+## Step 6: write the task
+
+Write `<main-root>/.canon/tasks/<label>-<slug>.md` by heredoc, from the label Step 2 read. Its frontmatter, H1, and `## Outcomes` follow `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Write a `Ready:` line beside the `Plan:` line pointing at the folder, then point the task at the plan through the verb:
+
+```bash
+canon tasks plan-link <task-stem> .canon/plans/feature-<slug>.md --json
+```
+
+Branch on the record rather than on the exit. `Ready:` is defined nowhere yet, so the line orients a worker reading the task and no check reads it.
+
+A task file with no row is a dropped task, so place the row in the same pass. The plan exists, so the row takes `## Run now` when `canon tasks plan-reach` reports nothing claimed and `## Up next` otherwise, with the held path in its `Waiting on` cell, per the tests in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Check the roster the way `canon:task-board` Step 4 does, reading `canon sessions list --self --json` for this session and `canon sessions list --json` for a row from the same repository, under another `sessionId`, whose `name` starts with `orchestrator-`. Treat a refused read as a roster read that failed.
+
+- **Orchestrator found.** Write neither file. Message that session with the row's title, the plan link, and the group with its reason, so it places the row itself rather than two sessions writing the board at once.
+- **Not found, and this session's name starts with `worker-` or `planner-`.** Write neither file, since both role bodies ban a board write with no exception. Report the row and its group in Step 8.
+- **Not found otherwise, or the roster read fails.** Write the row into `priority.md` through the same `Bash` route the task file took. A failed read looks like a solo project, and stopping would strand the task on the one path with nobody to place it.
+
+Say which branch fired in Step 8.
+
+Regenerate the task index after writing, since a hook on `Write|Edit` never fires on `Bash`:
+
+```bash
+canon indexes regen .canon/tasks
+```
+
+## Step 7: validate
+
+```bash
+canon records validate plans --json
+canon markdown audit <main-root>/.canon/ready/<nn>-<slug>/00-overview.md
+canon markdown audit <main-root>/.canon/plans/feature-<slug>.md
+```
+
+Fix what the records name in the files this run wrote and re-run once. Report a finding on a file it did not write, such as a neighbor folder missing its overview, without repairing it.
+
+## Step 8: report
+
+```plaintext
+✅ Ready folder written: .canon/ready/<nn>-<slug>/
+   Plan: .canon/plans/feature-<slug>.md
+   Task: .canon/tasks/<label>-<slug>.md
+   Row: <label> <title>, <written under ## Run now | reported to <orchestrator name> | left for the operator to place>, <reason>
+   Archive on ship: move the folder to .canon/ready/archive/<nn>-<slug>/ by hand, then retarget the task's Ready: line
+```
+
+Name the archive move every time. `canon tasks archive` moves the task and its plan and leaves the folder live, so the move is the one step this run leaves for whoever ships.
+
+## Rules
+
+- Edit no finished file. The worker copies verbatim, so a change belongs in the source before this runs.
+- Restate nothing the standards own. A shape question is answered by `ready.md` and a plan question by `plan.md`.
+- Dispatch nothing. Starting the worker belongs to whoever runs the board.

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

@@ -0,0 +1,67 @@
+---
+name: assembly
+description: The overview and thin-plan templates for a ready folder, and the match check between the two lists of destinations
+---
+
+# Assembly
+
+Loaded from Step 3 and Step 5 of `draft-ready`. The shape rules live in `${CLAUDE_SKILL_DIR}/../../standards/ready.md` and `${CLAUDE_SKILL_DIR}/../../standards/plan.md`, so this file holds the fill-in forms and the one check that compares them.
+
+## The overview
+
+```markdown
+---
+title: <Change in sentence case>
+description: <one line naming what the handoff carries>
+type: <branch type from branch.md>
+destinations:
+  - <path/to/file>
+---
+
+<What the files carry, one bullet each where a file's purpose is not its name.>
+
+<What the worker still owns beyond copying, or "nothing further".>
+```
+
+- Write `destinations` from the Step 1 list in the order the plan will list them.
+- Keep the prose to what the files cannot say themselves, such as a docs sync, a sandbox scenario, a test the folder does not carry, or the order a change lands in.
+
+## The thin plan
+
+```markdown
+# Feature: <short title>
+
+<Two or three sentences on why this ships as a copy rather than as an authoring job.>
+
+## Summary
+
+- <what the change does, one bullet per file group>
+- <branch type and what the worker still owns>
+
+**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:**
+
+- `<path/to/file>`: copy from the ready folder, <one clause on what it changes>
+
+**Risks:**
+
+- <what could go wrong, or "None identified.">
+
+**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:
+
+- 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.
+- A path in either list with no file at that relative path inside the folder is a broken mirror. Report it and stop rather than writing a plan around a hole.
+
+Report the sets as equal, or name each path that differs and on which side. Do not report the check as passed without having read both lists.

package/claude/skills/session-compact/REQUIREMENT.md

@@ -0,0 +1,44 @@
+---
+name: session-compact
+description: Why a plain session needs a handoff surface that is not the task board
+---
+
+# Session compact requirement
+
+## Gap
+
+Without this skill, a session facing a compaction reaches for `session-map`, which writes `.canon/tasks/session-<slug>.md`. The board carries four such files today, and `session-resume` drops them by name prefix to read the real rows, so a reader works around a misplacement on every run.
+
+`session-map` also carries the orchestrator's shape: a drift check against a start commit nothing records, a step for role sections, and a `## State` section. A session that shipped nothing pays all three to leave one note behind, and `standards/session.md` already names a `## State` filled from the tree as non-conforming, which is the failure that shape invites.
+
+Sessions also write the wrong thing into a handoff. They restate the tree, which survives a compaction, and omit what each decision beat, which does not.
+
+## Must
+
+- Write to `.canon/compact/`, outside the task board and outside scratch.
+- Invoke `canon:memory-capture` before writing, so the note cites entries rather than repeating them.
+- Carry a stated shape for the note, so what belongs in it is not re-derived per session.
+- Require a citation for every claim, and a rejected alternative beside every decision.
+- Decline in one line where the session holds nothing a compaction would destroy.
+
+## Must not
+
+- Write a task row, a plan, or anything under `.canon/tasks/`.
+- Write a `## State` section, or any section a reader could fill from `git status`.
+- Run a drift check or recover a start commit. Both belong to the role that ships code.
+- Restate a memory entry the capture pass wrote.
+- Lose its caller. The `PreCompact` hook names this skill on a manual compaction, and that hook plus an operator typing it are the two callers the third creation question asks for. A hook edit that names another skill leaves one caller, which is a reason to revisit this skill rather than to keep it.
+
+## Guards
+
+- No repository is required. The slug comes from the work, so a session outside git still writes a note.
+- `.canon/` resolves at the main worktree root. From a linked worktree the write goes through the shell, since the file-editing tools refuse that path.
+- Decline rather than pad. A note a reader finds is a note a reader trusts.
+- The note is backed up by `canon records push`, which carries every top-level `.canon/` folder, and the push is a run someone makes. Until it runs, or where no remote is configured, the note sits on one disk. The skill's report does not say so, since it would restate a run the operator owns on every note.
+
+## Out of scope
+
+- The orchestrator's handoff, which carries a drift check and a board row: `canon:session-map`. The two skills are held apart by role, so a plain session belongs here and a session holding `canon:role-orchestrator` belongs there.
+- Reading a handoff back: `canon:session-resume`, which reads `.canon/compact/` ahead of the older task-board form.
+- The memory pen, its routing and its shape: `canon:memory-capture` and `standards/memory.md`.
+- A decision a groundwork track owns, which belongs in that track's `06-decision.md`: `canon:plan-groundwork`.

package/claude/skills/session-compact/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: session-compact
+description: Captures a session's memory, then writes one handoff note to .canon/compact/ so the session after a compaction picks up where this one stopped. Use before running /compact, when asked to "write a handoff", "prepare for compaction", "save where we got to", or when a PreCompact hook blocks and names this skill. Do NOT use for a session holding the orchestrator role, whose board handoff is `session-map`. Do NOT use to record a decision a groundwork track owns, which is `plan-groundwork`.
+---
+
+# Session compact
+
+A compaction keeps conclusions and drops the reasoning that produced them. This writes the reasoning down first, in one file, outside the task board.
+
+Write only what a compaction destroys. Everything a later session can read from git, from the tree, or from a durable record is already safe, and restating it is what makes a handoff untrustworthy rather than long.
+
+## Guards
+
+- If `git rev-parse --git-dir` does not resolve, the note still writes. The filename comes from the work rather than from the branch, so nothing here needs a repository.
+- Decline where the session holds no reasoning a reader could not get faster from git or from a record already written. Say so in one line and write nothing. A padded note is worse than an absent one, because a reader who finds a note trusts it.
+- Resolve `.canon/` at the main worktree root, the way `session-worktree` does. From a linked worktree the file-editing tools refuse that path, so the write goes out through `Bash` as one plain command carrying a heredoc.
+
+## Step 1: capture memory
+
+Invoke `canon:memory-capture` and let it return before writing. The note then cites what was written rather than restating the same lesson in prose.
+
+State the caveat the caller gives about committing. A caller that does not commit says so, and capture skips routing and writes memory files alone.
+
+Carry through the line capture returns when a fact routed, so the session knows a fold is still owed. Report nothing else about what it wrote.
+
+## Step 2: write the note
+
+Write one file to `.canon/compact/<slug>.md`. Name `<slug>` for the work as a short kebab-case phrase, taken from what the session did rather than from the branch, so a session that ran on `main` still gets a name a reader recognizes. Use `latest` when nothing in the session names the work.
+
+Follow `${CLAUDE_SKILL_DIR}/references/handoff-note.md` for what each section carries and what stays out. Read it before drafting rather than working the shape from memory.
+
+Overwrite a note of the same name. One session's work has one note, and a second file for the same work splits the handoff.
+
+## Step 3: report
+
+```plaintext
+✅ Handoff written: .canon/compact/<slug>.md
+<the line memory-capture returned, where a fact routed>
+```
+
+A decline reports itself so a caller can tell it from a failure:
+
+```plaintext
+✅ No handoff. <what the session holds that git does not, and why it is nothing>
+```
+
+## Rules
+
+- Cite a file, a commit, or a record for every claim. A handoff no reader can check is a story.
+- Name what was decided together with what it beat. A decision with no rejected alternative reads as arbitrary and gets reopened.
+- Write `## Where to pick up` as one instruction, not a menu. A reader who has to choose has not been handed off to.
+- Leave the task board alone. A task is work somebody filed, and a handoff is context for one reader.
+- Do not write a `## State` section. A session that committed nothing has no state a reader could not get from `git status` faster, and one that did has it in the log.
+
+## What this delegates
+
+- The memory pass, its routing, and the pen's shape: `canon:memory-capture`
+- The orchestrator's handoff, which carries a drift check and writes a task row: `canon:session-map`
+- Reading a handoff back at the start of the next session: `canon:session-resume`
+- A decision a groundwork track owns, which belongs in its own `06-decision.md`: `canon:plan-groundwork`

package/claude/skills/session-compact/references/handoff-note.md

@@ -0,0 +1,68 @@
+---
+title: Handoff note
+description: What each section of a compact handoff carries, what stays out, and the test every line passes
+---
+
+# Handoff note
+
+The shape `session-compact` writes. It lives here rather than in `standards/` because one skill reads it and a standard nothing else cites has no second reader to correct it.
+
+## The test every line passes
+
+Would a compaction destroy this, and can no other artifact give it back?
+
+A line failing either half comes out. The tree, the git log, a groundwork record and the task board all survive a compaction, so restating any of them spends the reader's trust on something they already had.
+
+## Frontmatter
+
+```markdown
+---
+title: <what the session settled, as a sentence>
+description: <what it decided, what it measured, what it left open, and the date>
+category: Compact
+---
+```
+
+## The sections
+
+### The opening line
+
+One sentence naming this as throwaway and pointing at whatever durable record holds the detail. A reader who knows the note is disposable reads it differently from one who thinks it is the record.
+
+### `## Where the work is`
+
+The paths, and how to run what is there. A later session's first cost is finding the thing, and a wrong guess about which folder is current wastes more than this section costs.
+
+Name what was not touched too. A session that changed no source says so, since a reader otherwise opens `git status` expecting a diff.
+
+### `## What was decided`
+
+One bullet per decision, each naming what it beat. A decision with no rejected alternative reads as arbitrary and gets reopened by the next session that dislikes it.
+
+Where a decision rests on a measurement, give the number rather than the conclusion. `27 spacing values became 7` survives a reader disagreeing with it, where `the spacing was tidied` does not.
+
+### `## What is open`
+
+Numbered, because a reader picks one. Each carries what is unresolved and what would settle it.
+
+A thing deliberately not done belongs here, marked as such. An open question and a declined option look identical to a later session unless the note separates them.
+
+### `## Where to pick up`
+
+One instruction. Not a list, not a menu, not a recommendation with alternatives.
+
+Where the next move is a measurement rather than a decision, say so, since a session handed an open question reaches for a pick by default and spends a round on a question nobody needed answered.
+
+### `## Cautions`
+
+Only what cost this session time and would cost the next one the same. A command whose output goes to stderr, a tool reading something other than what its name suggests, a generator that deletes more than it wrote.
+
+Not general advice. A caution a reader could have guessed is noise around the two that matter.
+
+## What stays out
+
+- A `## State` section. A session that committed nothing has no state, and one that did has it in the log.
+- The tree, the file counts, and the folder listing. All survive a compaction.
+- The session's narrative. What was tried and abandoned belongs in the record the track keeps, or in memory if it generalizes, or nowhere.
+- A lesson already written to `.canon/memory/`. Cite the entry by name rather than restating it.
+- Anything the reader would have to take on trust. Every claim carries a file, a commit, or a record.

package/claude/skills/session-map/REQUIREMENT.md

@@ -1,6 +1,6 @@
 ---
 name: session-map
-description: Why the write procedure needs a route any session can take, why the door carries the drift step and its ref recovery, and why it states none of the shape the standard already fixes
+description: Why the write procedure needs a board-side route for the orchestrator and for a request naming the map, why the door carries the drift step and its ref recovery, and why it states none of the shape the standard already fixes
 ---
 
 # Session map requirement
@@ -23,7 +23,7 @@ A body that restates the sections, the frontmatter, or the numbered steps become
 
 ## Must
 
-- Write from any session whatever role it holds, without asserting one
+- Write for an orchestrating session, or on a request naming the session map or the board, without asserting a role the session does not hold
 - Cite the standard for the filename, the frontmatter, the sections, the numbered procedure, and the citation rule rather than restating any of them
 - Run the drift step and state how to recover the ref it reads from how long the session has run
 - Record what the drift verb names, and read a refusal as the boundary of what the verb can read
@@ -50,6 +50,7 @@ A body that restates the sections, the frontmatter, or the numbered steps become
 
 ## Out of scope
 
+- The handoff a plain session writes before a compaction, which is a note outside the board with no drift step and no `## State`: `session-compact`. Both skills once claimed the phrases "write the handoff" and "about to compact", so this description narrows to the orchestrator and to a request naming the map or the board, and a plain session belongs to `session-compact`.
 - Reading a handoff back at the start of the next session: `session-resume`
 - Routing a session fact to the context entry that owns it, and writing what no entry owns to the memory folder: `memory-capture`
 - The sections a role adds over the core three, which belong to that role's own surface. `role-orchestrator` owns the orchestrator's and cites this route for the generic half.