@erclx/canon 5.31.0 → 5.32.0

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

@@ -1,6 +1,6 @@
 ---
 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 before moving a session to another machine, 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`.
+description: 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 before moving a session to another machine, 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`.
 metadata:
   family: parallel
 ---
@@ -17,15 +17,7 @@ Write only what a compaction destroys. Everything a later session can read from
 - 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 and send the write out as a heredoc, both the way `session-worktree` states.
 
-## 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
+## Step 1: 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.
 
@@ -33,11 +25,10 @@ Follow `${CLAUDE_SKILL_DIR}/references/handoff-note.md` for what each section ca
 
 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
+## Step 2: report
 
 ```plaintext
 ✅ Handoff written: .canon/compact/<slug>.md
-<the line memory-capture returned, where a fact routed>
 Move: canon records push, then canon sessions export <id>
 ```
 
@@ -59,7 +50,6 @@ A decline reports itself so a caller can tell it from a failure:
 
 ## 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`
 - Packing the session for another machine: `canon sessions export`, with `canon sessions import` and then `/canon:session-resume` on the arriving side

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

@@ -63,6 +63,6 @@ Not general advice. A caution a reader could have guessed is noise around the tw
 
 - 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.
+- The session's narrative. What was tried and abandoned belongs in the record the track keeps, or nowhere.
+- A lesson stated as a lesson. Put it in `## Where to pick up` as the context edit or the task that carries it, since nothing else reads a note once the next session is past 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

@@ -11,13 +11,9 @@ Without this skill, the standard governing the pre-compaction handoff carries a
 
 The only routed writer belongs to the orchestrator role. It disables model invocation, asserts that role on invocation, and adds a section for decisions taken under delegated authority, so a plain feature session that reaches it receives a section it cannot fill and a review poll it does not run.
 
-The nearest description by wording writes a different artifact. Capture routes facts to a context entry and writes memory files, and a request naming the session and the moment matches it, so the map goes unwritten while a session believes it has handed off.
-
 The drift step is the one most specific to session length and the easiest to skip. It reads the commit the session started from, nothing on the machine records that commit, and a route that names the step without naming how to recover the ref ships an instruction nobody can follow.
 
-A step that reads a surface a project may not carry gets skipped on the reasoning that it has nothing to act on. A cold session run against a project with no `.claude/` tree skipped both the capture and the drift step and wrote its own rationale into the map, so the step the route exists to carry did not run on the first test from outside. The skip is worst where it looks most defensible, and a session that takes it quietly leaves a map indistinguishable from a conforming one.
-
-A capture fired the same way for every caller breaks the one caller the split leaves. An orchestrating session may write no tracked file, so its capture has to skip routing, and a route offering no way to say so leaves that reader running capture twice or routing facts the role forbids it to fold.
+A step that reads a surface a project may not carry gets skipped on the reasoning that it has nothing to act on. A cold session run against a project with no `.claude/` tree skipped the drift step and wrote its own rationale into the map, so the step the route exists to carry did not run on the first test from outside. The skip is worst where it looks most defensible, and a session that takes it quietly leaves a map indistinguishable from a conforming one.
 
 A body that restates the sections, the frontmatter, or the numbered steps becomes a second source that drifts from the standard, which is the failure the split between the role writer and the core was made to remove rather than move.
 
@@ -30,15 +26,12 @@ A body that restates the sections, the frontmatter, or the numbered steps become
 - Resolve the folder at the main worktree root, and write the file whole from the shell where the editing tools refuse that root
 - Fall back to the branchless filename on an empty slug rather than stopping
 - Leave model invocation enabled, so a session that has dropped its routing still reaches this by description
-- Take a caller's statement that the session does not commit and pass it to capture, so no fact this route fires is routed into a tracked file
-- Report the map alone, plus the line capture returns when a fact routed, since a fold left unreported is a fold nobody runs
 
 ## Must not
 
 - Restate the standard's sections, frontmatter, or numbered steps
 - Skip a step by predicting what its skill or verb would have answered, rather than running it and recording what came back
 - Assert a role, or add a role's section to a map written by a session holding no such role
-- Fold the capture step's output into this skill's report
 - Take the worktree-local copy the editing tools offer in place of the main-root path
 - Summarize the board, the task files, or the work that shipped, each of which is carried by an artifact a compaction leaves standing
 
@@ -52,7 +45,6 @@ A body that restates the sections, the frontmatter, or the numbered steps become
 
 - 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.
 - Validating a written map against the standard, which no record kind covers, so a conforming shape rests on the standard being followed
 - Firing the write without being asked, which is a question about what the harness supports and is measured on its own track

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

@@ -1,17 +1,17 @@
 ---
 name: session-map
-description: Writes the session map, the board-side handoff at `.canon/tasks/session-<slug>.md`, for an orchestrating session or on a request naming the session map or the task board, running the skill-drift step the write procedure opens with. Use when asked to "write the session map", "write the board handoff", or when a session holding `canon:role-orchestrator` hands off before a compaction. Do NOT use for a plain session about to compact, which is `session-compact` and writes a note outside the board. Do NOT use to route session facts to a context entry or the memory folder, which is `memory-capture` and writes a different artifact, and do NOT use to read a handoff back, which is `session-resume`.
+description: Writes the session map, the board-side handoff at `.canon/tasks/session-<slug>.md`, for an orchestrating session or on a request naming the session map or the task board, running the skill-drift step the write procedure opens with. Use when asked to "write the session map", "write the board handoff", or when a session holding `canon:role-orchestrator` hands off before a compaction. Do NOT use for a plain session about to compact, which is `session-compact` and writes a note outside the board. Do NOT use to read a handoff back, which is `session-resume`.
 metadata:
   family: parallel
 ---
 
 # Session map
 
-Write the pre-compaction handoff for the current session. `${CLAUDE_SKILL_DIR}/../../standards/session.md` fixes the filename, the frontmatter, the three core sections, the numbered write procedure, and the citation rule. Follow that document rather than this body, which states when the procedure runs and what it runs against and leaves the shape where it already lives.
+Write the pre-compaction handoff for the current session. `${CLAUDE_SKILL_DIR}/references/session.md` fixes the filename, the frontmatter, the three core sections, the numbered write procedure, and the citation rule. Follow that document rather than this body, which states when the procedure runs and what it runs against and leaves the shape where it already lives.
 
 Any session writes one. Do not assert a role on invocation, and do not add a role's sections to a map written by a session holding no such role.
 
-Run every step rather than judging in advance that one has nothing to act on. The capture skill and the drift verb each answer for themselves, refusal included, and a refusal recorded is a result where a prediction of one is not. A project carrying none of the scaffolding either step reads is the case this fires on, and it is the case where skipping looks most defensible.
+Run every step rather than judging in advance that one has nothing to act on. The drift verb answers for itself, refusal included, and a refusal recorded is a result where a prediction of one is not. A project carrying none of the scaffolding the step reads is the case this fires on, and it is the case where skipping looks most defensible.
 
 ## What fires this
 
@@ -25,17 +25,9 @@ Decline where the session holds no reasoning a reader could not get faster from
 - Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. An empty result falls back to `latest` rather than stopping, since a handoff is scratch and a stop loses the reasoning the file exists to save.
 - Resolve the containing folder at the main worktree root with `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`. The guard above already stopped where that read has no repository to answer from, so it takes no fallback.
 
-## Step 1: run the capture the procedure opens with
+## Step 1: recover the commit the drift step reads
 
-Item 1 of `## Writing one` is a capture. Invoke `canon:memory-capture` and let it return before writing, so the map cites what was written instead of restating the same lesson in prose.
-
-Pass on the caveat a caller states about committing. A caller that does not commit says so, and capture then skips routing and writes memory files alone, since a routed fact lands in a context entry and that is a tracked file. A caller stating nothing leaves capture to decide for itself, which is the ordinary run.
-
-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. The map is this skill's output.
-
-## Step 2: recover the commit the drift step reads
-
-Item 2 runs `canon claude skills drift <ref>` against the commit this session started from, and nothing on the machine records that commit. Estimate how long the session has run, round the duration up, and read the ref item 3 recovers:
+Item 1 of `## Writing one` runs `canon claude skills drift <ref>` against the commit this session started from, and nothing on the machine records that commit. Estimate how long the session has run, round the duration up, and read the ref item 2 recovers:
 
 ```bash
 git log -1 --format=%H --before='<duration> ago'
@@ -45,13 +37,13 @@ Round up rather than down. A ref older than the oldest load over-reports, and co
 
 Record what the verb names under `## Standing cautions`. A refusal is the boundary of what the verb can read rather than a fault, since it answers where the working directory carries `claude/skills/` with history behind it and refuses in a project consuming the plugin from a cache. Record the boundary the verb reported and keep writing, rather than the one it looked likely to report.
 
-## Step 3: write the map
+## Step 2: write the map
 
-Follow items 4 through 6. Write only what a compaction destroys and no other artifact already carries, and cite a commit, a task, or a file and line for every claim.
+Follow items 3 through 5. Write only what a compaction destroys and no other artifact already carries, and cite a commit, a task, or a file and line for every claim.
 
 The file sits at the main worktree root and is written whole every time, so send it out as a heredoc, routed the way `session-worktree` states.
 
-## Step 4: extend it only where a role is held
+## Step 3: extend it only where a role is held
 
 `## Extending it` governs a section added over the core three. Add one only when this session holds the role and the surface owning that role states the section, since a section the writer cannot fill teaches its reader to skip the file. A session holding no role writes the core three and stops.
 

package/{standards → claude/skills/session-map/references}/session.md

@@ -1,10 +1,6 @@
 ---
 title: Session map reference
 description: Filename and location, the sections a handoff carries, the write and read procedures, and how a role extends it
-paths:
-  - '.canon/tasks/session-*.md'
-rule:
-  - 'Follow this rule rather than the tasks rule for a `session-` file. A handoff is not a task and carries neither `## Outcomes` nor `## Findings`.'
 ---
 
 # Session map reference
@@ -13,6 +9,18 @@ Applies to `.canon/tasks/session-<slug>.md`. A session writes one before a compa
 
 Any session writes one. The role a session holds decides which sections it adds on top of the core, never whether it may write at all.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working session map looks like](#what-a-working-session-map-looks-like)
+- [Filename and location](#filename-and-location)
+- [Frontmatter](#frontmatter)
+- [Sections](#sections)
+- [Writing one](#writing-one)
+- [Reading one back](#reading-one-back)
+- [Extending it](#extending-it)
+- [Template](#template)
+
 ## Scope
 
 Governs the pre-compaction handoff at `.canon/tasks/session-<slug>.md`: its filename, its sections, what a writer puts in each, and how a reader picks one up.
@@ -23,7 +31,6 @@ Does not govern:
 - The transform from a branch name to the slug in the filename: `slug.md`
 - The role-specific sections a caller adds over the core, which belong to that caller
 - The note a plain session writes at `.canon/compact/<slug>.md`, whose shape lives in the `session-compact` skill's own reference
-- Which memories a session captures before writing, which is the capture surface's own subject
 
 ## What a working session map looks like
 
@@ -63,12 +70,11 @@ Add a section only for content that fits none of the three and would otherwise b
 
 The `session-map` skill is the invocable route onto this procedure and holds no role, so a session reaching for a handoff without knowing this document exists still lands here. A session that arrives at this document directly follows the steps below unchanged.
 
-1. Capture what the session learned first, so the map cites what was written instead of restating the same lesson in prose.
-2. Run `canon claude skills drift <the commit this session started from>` and record what it names under `## Standing cautions`. A skill body enters a session once and re-invoking the skill does not re-read the file, so the drift is worst at exactly this moment and a name here is a body the session has been following out of date. Recording a name is not acting on it, and the verb misses a body this session edited and has not committed. This step belongs to session length rather than to any role, so every writer runs it, and a refusal names the boundary of what the verb can read rather than a fault.
-3. Recover that commit from how long the session has been running with `git log -1 --format=%H --before='<duration> ago'`, rounding the duration up rather than down. Nothing on the machine records it. A ref older than the oldest load over-reports, and confirming a name costs one read of the body, so the generous end is the safe one and a guess at the exact commit is not worth making. An empty result means no commit predates the window, so take the oldest commit the history holds and say which of the two the ref came from.
-4. Write only what a compaction destroys and no other artifact already carries. The board holds the ordering and what each task waits on, a task file holds its own findings, and a measurement folder holds its track.
-5. Cite a commit, a task, or a file and line for every claim, so the next session can tell a read from a recall.
-6. Fill a section from reasoning the session actually holds. A session with no cross-feature picture that fills `## State` from what is already in git has written a summary of the tree, which the reader can produce faster than they can read it.
+1. Run `canon claude skills drift <the commit this session started from>` and record what it names under `## Standing cautions`. A skill body enters a session once and re-invoking the skill does not re-read the file, so the drift is worst at exactly this moment and a name here is a body the session has been following out of date. Recording a name is not acting on it, and the verb misses a body this session edited and has not committed. This step belongs to session length rather than to any role, so every writer runs it, and a refusal names the boundary of what the verb can read rather than a fault.
+2. Recover that commit from how long the session has been running with `git log -1 --format=%H --before='<duration> ago'`, rounding the duration up rather than down. Nothing on the machine records it. A ref older than the oldest load over-reports, and confirming a name costs one read of the body, so the generous end is the safe one and a guess at the exact commit is not worth making. An empty result means no commit predates the window, so take the oldest commit the history holds and say which of the two the ref came from.
+3. Write only what a compaction destroys and no other artifact already carries. The board holds the ordering and what each task waits on, a task file holds its own findings, and a measurement folder holds its track.
+4. Cite a commit, a task, or a file and line for every claim, so the next session can tell a read from a recall.
+5. Fill a section from reasoning the session actually holds. A session with no cross-feature picture that fills `## State` from what is already in git has written a summary of the tree, which the reader can produce faster than they can read it.
 
 Do not restate the board, and do not summarize the work that shipped, since version control already carries it.
 

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

@@ -24,7 +24,7 @@ makes the firing survive.
 The first draft of this plan closed the gap with a paragraph drafted inline,
 once inside `role-worker` and once inside `role-planner`. The operator overrode
 that call: two bodies carrying identical protocol text is the shared-surface
-case `canon/ARCHITECTURE.md` already decided against duplicating, since a later
+case, since a later
 fix reaching one copy and not the other diverges silently.
 
 Neither attempt named who the relay is from. A message an operator relays by

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

@@ -9,22 +9,21 @@ description: Why resuming reads the handoff before the board, reads an index bef
 
 Without this skill, a session picking up old work reconstructs state from the git log, which records what shipped and not what is queued, so finished work reads as pending and the actual next item goes unmentioned. The alternative failure is worse for a different reason. A session that reads every task file and every plan to be thorough spends the context the work needs before the work starts, and the summary arrives in a session with no room left to act on it.
 
-A compaction keeps conclusions and drops the reasoning that produced them, and the previous session can write that reasoning to a handoff before it goes. A resume that reads the board, the plans, and the memory index alone walks past that file, so the one artifact written to survive the compaction reaches nobody and the next session re-derives what it holds.
+A compaction keeps conclusions and drops the reasoning that produced them, and the previous session can write that reasoning to a handoff before it goes. A resume that reads the board and the plans alone walks past that file, so the one artifact written to survive the compaction reaches nobody and the next session re-derives what it holds.
 
 The task index is a folder catalog rather than a task filter, so it carries a row for the ordering file and one for every handoff on the board. A session reporting each row as a backlog item queues work nobody filed, and the count grows with every session that ever wrote a handoff.
 
 From a linked worktree the shared scratch folders resolve against the worktree rather than the main root, where they are empty. That reports no tracked work on a repository carrying a full backlog, and the report is indistinguishable from the true empty case.
 
-A resume is a read, and a session that treats it as a cleanup pass offers to archive finished entries or refresh a memory it decided was stale. Both change tracked state on the strength of a summary the user has not confirmed yet.
+A resume is a read, and a session that treats it as a cleanup pass offers to archive finished entries or rewrite a plan it decided was stale. Both change tracked state on the strength of a summary the user has not confirmed yet.
 
 ## Must
 
 - Read the newest handoff before the board, and report what it carries attributed to its writer
-- Resolve the handoff, plans, memory, and tasks folders at the main worktree root
+- Resolve the handoff, plans, and tasks folders at the main worktree root
 - Read the task index before any individual task file, and open only the task files the summary needs
 - Drop the board siblings from the index before reporting it as the backlog, since the catalog filters nothing and carries a row per handoff
 - Preserve the index's order in the report, since the order is the priority
-- Surface only the memory entries that inform the top item
 - Close with one recommendation naming the first item and whether a plan backs it
 
 ## Must not
@@ -33,11 +32,10 @@ A resume is a read, and a session that treats it as a cleanup pass offers to arc
 - Report the absence of a handoff, which is the common case and would train a reader to skip the line on the run where one exists
 - Restate a handoff's counts, sizes, or costs as current. Each was true when written.
 - Offer to remove, archive, or reorder an entry. Resume reports and does not mutate.
-- Update memory, which changes when a recorded fact becomes wrong rather than on a resume
 
 ## Guards
 
-- All four surfaces absent or empty reports no tracked work and stops, rather than inventing a next step from the repository
+- Every surface absent or empty reports no tracked work and stops, rather than inventing a next step from the repository
 - A handoff found beside an empty board recommends what the handoff leaves open, since the guard passes on the handoff alone and the recommendation has no backlog item to name
 
 ## Out of scope

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

@@ -9,18 +9,16 @@ metadata:
 
 ## Step 1: read tracked work
 
-Resolve `.canon/plans/`, `.canon/memory/`, `.canon/compact/`, and `.canon/tasks/` at the main worktree root the way `session-worktree` does.
+Resolve `.canon/plans/`, `.canon/compact/`, and `.canon/tasks/` at the main worktree root the way `session-worktree` does.
 
 Read these in parallel, skipping any that do not exist:
 
-- the newest `.canon/compact/*.md`, then the newest `.canon/tasks/session-*.md`: the handoff a previous session wrote before a compaction. The first is the note `session-compact` writes, and the second is the board-side map per `${CLAUDE_SKILL_DIR}/../../standards/session.md`, which stays readable. Whichever exists leads the report rather than the reads, and both lead it when both exist.
+- the newest `.canon/compact/*.md`, then the newest `.canon/tasks/session-*.md`: the handoff a previous session wrote before a compaction. The first is the note `session-compact` writes, and the second is the board-side map per `${CLAUDE_SKILL_DIR}/../session-map/references/session.md`, which stays readable. Whichever exists leads the report rather than the reads, and both lead it when both exist.
 - `.canon/tasks/index.md`: the folder catalog. Read this before any individual task file, and take the task list from it by dropping the `index`, `priority`, `backlog`, and `session-` rows, which are siblings rather than tasks.
 - `.canon/plans/*.md`: execution detail for in-progress tasks
 
 Then read only the task files the summary needs, typically the top one. Do not read the whole folder.
 
-Once the top task is known, grep `.canon/memory/index.md` for two or three terms from its title and read at most three of the entries whose rows match. Never read the index whole, since a grown pen's index runs to hundreds of rows and the report shows three at most. With no top task, or no row matching, read no memory entry and say nothing about it.
-
 Most projects carry no handoff. Say nothing about its absence, since a line reporting it every run trains a reader to skip the line on the run where a handoff exists.
 
 If the handoff, task, and plan surfaces are all absent or empty, stop: `✅ No tracked work found. Start a new task.`
@@ -35,17 +33,13 @@ Output these sections, omitting the first when no handoff was found:
 
 **Active plans:** one line per file in `.canon/plans/`, linking each to its task file in `.canon/tasks/`. Say "None" if empty.
 
-**Relevant context:** the memory entries Step 1 matched to the top backlog item, three at most. Skip if none matched.
-
 ## Step 3: recommend
 
 End with one line: `Start with: <first Up next item>` and note whether it has a linked plan.
 
 When the board is empty and a handoff was found, name what the handoff leaves open instead: `Start with: <the open thread the handoff names>`. A recommendation slot filled with nothing reads as a failed run, and a handoff on an empty board is the shape a session leaves when it was reasoning rather than shipping.
 
-Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../../standards/plan-lifecycle.md`.
-
-Memory is updated only when a recorded fact becomes wrong, never on resume. A domain fact reaches a session through `canon/context/`, which `memory-capture` routes to and the three-tier model loads on demand, so the memory folder read here is the residue no context entry owns.
+Do not offer to remove entries. A completed task is archived out of `.canon/tasks/` when work ships. The git log is the authoritative record of shipped work. Plan files are archived per the lifecycle rule in `${CLAUDE_SKILL_DIR}/../plan-feature/references/plan-lifecycle.md`.
 
 ## Writing the next one
 

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

@@ -1,6 +1,6 @@
 ---
 name: session-worktree
-description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/plan-feature`. Also use when an `Edit` or `Write` to a main-root file such as a plan, a task, or a memory entry was refused for session isolation. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
+description: Enters a Claude Code worktree at `.claude/worktrees/<name>/` with a name derived from the active plan or branch. Use when asked to "enter a worktree", "start a worktree", "work in a worktree", or at the plan-to-execute boundary after `/plan-feature`. Also use when an `Edit` or `Write` to a main-root file such as a plan, a task, or a review report was refused for session isolation. Do NOT use to list, clean up, or rotate worktrees (use `git-worktree`).
 metadata:
   family: build
 ---

package/claude/skills/session-worktree/references/main-root-writes.md

@@ -3,7 +3,7 @@ title: Main-root write routing
 description: Which tools the isolation refusal covers, the route each kind of main-root write takes, the fallback when a heredoc is refused, and the index cost a shell write carries
 ---
 
-Shared session scratch, being `.canon/plans/`, `.canon/review/`, `.canon/memory/`, and `.canon/tasks/`, lives at the main worktree root. Resolve that root with the first `worktree` entry of `git worktree list --porcelain`, falling back to `pwd` outside a git repository.
+Shared session scratch, being `.canon/plans/`, `.canon/review/`, and `.canon/tasks/`, lives at the main worktree root. Resolve that root with the first `worktree` entry of `git worktree list --porcelain`, falling back to `pwd` outside a git repository.
 
 ## The refusal
 
@@ -21,4 +21,4 @@ Shared session scratch, being `.canon/plans/`, `.canon/review/`, `.canon/memory/
 
 ## The index cost
 
-A shell write skips every `PostToolUse` hook, since those match `Write|Edit|MultiEdit` and never fire on `Bash`. That costs nothing on `.canon/plans/` and `.canon/review/`, which no hook indexes, and costs the generated `index.md` on `.canon/tasks/` and `.canon/memory/`. Regenerate positionally after a shell write there, by an explicit `canon indexes regen` call, unless the verb that made the write already calls it, as `canon tasks archive` does.
+A shell write skips every `PostToolUse` hook, since those match `Write|Edit|MultiEdit` and never fire on `Bash`. That costs nothing on `.canon/plans/` and `.canon/review/`, which no hook indexes, and costs the generated `index.md` on `.canon/tasks/`. Regenerate positionally after a shell write there, by an explicit `canon indexes regen` call, unless the verb that made the write already calls it, as `canon tasks archive` does.

package/claude/skills/systematic-debugging/REQUIREMENT.md

@@ -51,5 +51,4 @@ A stated phase is also one a session can talk itself out of. The reasons it give
 ## Out of scope
 
 - A typo fix and a cause already agreed on, where the phases cost more than they return
-- Reviewing a change for defects it has not yet exhibited: `review-branch`
 - Deciding whether the architecture should change, which the three-attempt stop hands to the user rather than answering

package/claude/skills/target-check/REQUIREMENT.md

@@ -7,7 +7,7 @@ description: What the target check is for, the gap it closes, and the repairing
 
 ## Gap
 
-Without this skill, a session landing in a target project decides for itself what to look at. `canon-rollout` dispatches a worker into each target and gets a pull request out, and nothing told that worker what a target holds against what the toolkit ships, so a wave is only as good as whatever each session happened to examine. Four hand-driven repairs across two waves examined four different sets of surfaces and none of them read the same domain twice.
+Without this skill, a session landing in a target project decides for itself what to look at. An orchestrator dispatches a worker into each target and gets a pull request out, and nothing told that worker what a target holds against what the toolkit ships, so a wave is only as good as whatever each session happened to examine. Four hand-driven repairs across two waves examined four different sets of surfaces and none of them read the same domain twice.
 
 The second half of the gap is silence. A session that runs a verb the target's binary does not carry, or reads a report key that is absent, has no instruction telling it apart from a clean answer, so an unexamined domain reaches the reader as a domain that passed.
 
@@ -32,11 +32,11 @@ The second half of the gap is silence. A session that runs a verb the target's b
 
 - `canon` absent from the path: stop, since no domain can be read
 - No `.claude/` at the working root: stop and name the scaffold command, since nothing is installed to check
-- The working root is the toolkit itself: stop and name `canon-rollout`, since this skill reads what the toolkit installed into rather than the source
+- The working root is the toolkit itself: stop and ask the orchestrator for a worker per repository, since this skill reads what the toolkit installed into rather than the source
 
 ## Out of scope
 
 - Document health, which asks a content question rather than a structural one and takes its own surface
 - Repairing anything a section names. Each routes to the command or skill that owns it.
 - A target's own routes, which `canon inventory` reports as a listing rather than a verdict and which is a fact about the project rather than about what the toolkit ships
-- First-time scaffold, which is `target-setup`, and per-intent routing of a single toolkit operation, which is `canon-operator`
+- First-time scaffold, which is `target-setup`

package/claude/skills/target-check/SKILL.md

@@ -15,7 +15,7 @@ Six domains carry the report. Five answer from a verb that already exists and th
 
 - `canon` absent from the path: stop. `❌ canon is not on PATH, so no domain can be read.`
 - No `.claude/` directory at the working root: stop. `❌ No .claude/ here, so nothing is installed to check. Run canon init first.`
-- A `claude/skills/` folder at the working root, with no leading dot: stop. `❌ This is the toolkit itself rather than a target. canon-rollout takes a change out to the targets.` A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into.
+- A `claude/skills/` folder at the working root, with no leading dot: stop. `❌ This is the toolkit itself rather than a target. Ask the orchestrator for a worker per repository to take a change out to the targets.` A target receives skills at `.claude/skills/` and authors none, so the spelling without the dot separates the source from what it installs into.
 - Run every command under `CANON_NON_INTERACTIVE=1` and prompt at no point. Every caller in the near term is a worker a wave dispatched, with nobody present to answer, so the non-interactive path is the only path rather than a flag a caller remembers.
 - Branch on each record's own fields rather than on an exit status. An operator's shell profile may wrap `canon` in a function whose status comes from a trailing command, which reports every refusal as success.
 

package/claude/skills/target-check/references/domains.md

@@ -77,7 +77,7 @@ Read `seeds.entries` off the report. Each entry is `matching`, `stale`, `drifted
 - Behind: anything else. Report `stale` and `missing` separately from `drifted`, which means the content matches no version the toolkit ever published, so the project wrote it.
 - Unread: `historyUnavailable` set on `seeds`, which leaves every difference unattributed. Say so rather than reporting a file as untouched.
 
-Routes to `seed-sync`, which proposes per-section edits without overwriting a customization. It is a proposal rather than a write, which is why a `drifted` `CLAUDE.md` routes there rather than to a sync.
+Report a `stale` seed as safe to take whole and a `drifted` one as a hand merge against the toolkit copy, since a sync command would overwrite the project's edits.
 
 A seed entry matching says the file's bytes match the shipped seed. It says nothing about whether the harness those files configure is wired, which is the next domain.
 

package/claude/skills/target-setup/REQUIREMENT.md

@@ -36,12 +36,12 @@ two copies could disagree with nothing comparing them.
 
 ## Must not
 
-- Guard against clobbering an existing project's configs, which routes to `canon-operator` instead
+- Guard against clobbering an existing project's configs, which `canon sync` covers on an existing project and `target-check` reports on
 - Author a rule or a stack in the target project on the fly
 - Generate a config the tooling stack ships as a golden file
 - Install Claude Code plugins, which provision a machine rather than a project
 - Fail an unattended scaffold on a server start, which is flaky enough to be a depth the operator asks for
-- Survive as a skill nothing invokes but a person typing its name. `canon-operator` hands first-time scaffold here and the target projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
+- Survive as a skill nothing invokes but a person typing its name. The target projects page names it as the scaffold step, so a later read finding no caller but the author has found a body that should have stayed a verb
 
 ## Guards
 
@@ -51,6 +51,6 @@ two copies could disagree with nothing comparing them.
 
 ## Out of scope
 
-- An existing project's per-domain drift, which `canon-operator` diagnoses and `target-check` reports
-- Reaching a remote or the project's history, which `repo-metadata` and `git-commit` own
+- An existing project's per-domain drift, which `target-check` reports
+- Reaching the project's history, which `git-commit` owns
 - Provisioning Claude Code plugins on a machine, which the `claude plugin` CLI does directly

package/claude/skills/target-setup/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: target-setup
-description: Gets a project onto the toolkit. Detects the stack, resolves per-domain arguments, previews the chain, runs `canon init`, then verifies at a stated depth and bootstraps the `index.md` system. Use when asked to "set up this project", "init this project", "bootstrap the toolkit", "install governance", "install gov rules", "set up indexes", "verify the scaffold", "run the smoke tests", or "one-shot install". Assumes the `canon` CLI is on PATH. Do NOT use on a project that already carries the toolkit, which is `canon-operator`, or to report per-domain drift without repairing it, which is `target-check`.
+description: Gets a project onto the toolkit. Detects the stack, resolves per-domain arguments, previews the chain, runs `canon init`, then verifies at a stated depth and bootstraps the `index.md` system. Use when asked to "set up this project", "init this project", "bootstrap the toolkit", "install governance", "install gov rules", "set up indexes", "verify the scaffold", "run the smoke tests", or "one-shot install". Assumes the `canon` CLI is on PATH. Do NOT use on a project that already carries the toolkit, or to report per-domain drift without repairing it, which is `target-check`.
 metadata:
   family: setup
 ---
@@ -50,14 +50,14 @@ else. Do not pause for a separate confirmation.
 ## Scope
 
 - This skill and `canon init` run once on a fresh scaffold, never on an existing project. They do not guard against clobbering existing configs. When tempted to add guards, mode switches, or an existing-project branch, stop. Extend the per-domain `canon <domain> install` or `canon sync` paths instead.
-- The chain stops at the project edge. `repo-metadata` and `git-commit` also ship, reaching a remote and the project's history respectively, and neither runs here.
+- The chain stops at the project edge. `git-commit` also ships, reaching the project's history, and does not run here.
 - Claude Code plugins are a machine concern rather than a project one, so no phase here installs them. Install them with `claude plugin install <name> --scope user`, which applies in every project on the machine and is copied into none.
 
 ## Declined states
 
 Three states reach this skill that the chain does not serve. Name the destination for each, so the refusal routes rather than ends. The first two stop the chain outright and the third runs it on a default the person may not want.
 
-- **An existing project.** Stop and hand off to `canon-operator`. It reads what the target already carries before it names a command, which this chain never does, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
+- **An existing project.** Stop and hand off to `target-check`, which reports what the target already carries before anything is repaired. This chain never reads that, so any per-domain install picked here is a guess against configs nobody read. The Scope bullet above names the same commands as the authoring alternative, and this is the destination a person takes.
 - **An install wanting the `.claude/` folder alone.** Stop. Run `canon claude init` for the seed docs, then run the `indexes` phase over the project's own documentation folders. Neither needs the tooling sync the `install` phase runs.
 - **A language the toolkit carries no stack for.** The chain still runs, on `base`, with the fallback marked in the preview. A project that wants none of what `base` carries declines there and takes the `gov` phase, which is language-neutral and installs rules without the `base` development dependencies the tooling layer would drop on it. Say so at the preview rather than resolving it here, since the fallback is a working default and only the person can say whether it fits.
 

package/claude/skills/target-setup/references/detect.md

@@ -67,7 +67,7 @@ folder is a Go or PHP root rather than a JavaScript one.
 
 Read these once, from the repository root:
 
-- `canon/REQUIREMENTS.md` and `canon/ARCHITECTURE.md` if present
+- `canon/REQUIREMENTS.md` if present
 - Directory structure via `ls -1` of the project root and `src/` if present
 
 ## Resolve arguments

package/claude/skills/task-board/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 
 Owns the two operations that bring a task file into existence and take it out of the folder. `context-fold` edits the contents of a task that already exists, marking outcomes `[x]`. Do not mark outcomes here, and do not move a plan by hand: the archive carries it.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` before writing any file. It holds the filename convention, the frontmatter contract, and the file format. Do not work them from memory.
+Read `${CLAUDE_SKILL_DIR}/references/tasks.md` before writing any file. It holds the filename convention, the frontmatter contract, and the file format. Do not work them from memory.
 
 ## Guards
 
@@ -43,7 +43,7 @@ Do not derive the label from a version file. `${CLAUDE_SKILL_DIR}/../../standard
 
 ### Step 3: write the file
 
-Write `.canon/tasks/vXX.Y-<slug>.md` under the claimed label, reading the file first if a session ever stubbed it, following the format in `${CLAUDE_SKILL_DIR}/../../standards/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
+Write `.canon/tasks/vXX.Y-<slug>.md` under the claimed label, reading the file first if a session ever stubbed it, following the format in `${CLAUDE_SKILL_DIR}/references/tasks.md`. Include a link line only when the file or folder it names exists. A link to a plan nobody has written yet is the broken pointer the archive rules exist to prevent.
 
 Write `Plan:`, `Groundwork:`, and `Intake:` as markdown links relative to `.canon/tasks/`, as in `Plan: [feature-<slug>](../plans/feature-<slug>.md)`. Leave `Issue:` a bare `#NNN`. A task written in the older bare-path form still parses, so it costs the board a clickable line rather than an archive, but it leaves the board in two shapes for every reader after.
 
@@ -55,7 +55,7 @@ Write it immediately. Claude Code's tool permission dialog is the confirmation g
 
 A task file with no row is a dropped task, so name the surface it lands on in the same pass that creates it. A task that would plausibly be planned within the next few waves takes a row under `## Needs a plan` in `.canon/tasks/priority.md`, positioned by where it sits against the rows already there, with the reason for that position in its `Waiting on` cell. Anything else takes a line in `.canon/tasks/backlog.md`, which is unordered and where in the file it goes means nothing.
 
-The test and both file shapes are in `${CLAUDE_SKILL_DIR}/../../standards/board.md`.
+The test and both file shapes are in `${CLAUDE_SKILL_DIR}/references/board.md`.
 
 Check the roster for a live orchestrator before writing either file. Read `canon sessions list --self --json` for this session's own `sessionId` and `name`, then read `canon sessions list --json` and match a row whose `repository` matches this session's own, whose `sessionId` differs from it, and whose `name` starts with `orchestrator-`. That is the convention every hand-launched controller on this machine currently uses, and it excludes every `worker-` and `planner-` session cleanly. Treat a refusal from either call the same as a roster read that failed.
 
@@ -71,7 +71,7 @@ Scan for work that has been decided and would otherwise be forgotten. Three orig
 
 List `.canon/groundwork/` and run `gh issue list --state open` when a remote is configured, then grep the board for each track name and issue number. Report any with no task, one line each.
 
-Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../../standards/intake.md` fixes. Then grep `.canon/tasks/`, `.canon/tasks/archive/`, and `.canon/tasks/declined/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and either shipped or declined, so a check reading the board by itself reports every settled folder as abandoned.
+Read the dumps through `canon intake list --json`, which reports items, open, unread, and malformed per folder and owns the parse of the answer contract `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` fixes. Then grep `.canon/tasks/`, `.canon/tasks/archive/`, and `.canon/tasks/declined/` for each folder slug. A dump with no live task is the ordinary shape of one already promoted and either shipped or declined, so a check reading the board by itself reports every settled folder as abandoned.
 
 A dump is the stronger case for this scan rather than the weaker one. A track holds one question and stays visible, while a dump holds dozens of items whose verdicts were reached and then left with nothing carrying them forward.
 

package/claude/skills/task-board/references/archive.md

@@ -40,7 +40,7 @@ On success the record carries `from`, `to`, `priorityRowRemoved`, and `indexRege
 Each reason has one resolution and none of them is to archive around it:
 
 - `open-outcomes`: the named outcomes are unmarked or genuinely open. Run `context-fold` when the work shipped and nothing marked it. Leave the task on the board when the outcome is real. When the work is being abandoned, cut it by striking the body, `- ~~<outcome>~~ <why>`, whatever the checkbox holds, so the board records what was dropped rather than meeting this refusal a second time.
-- `ambiguous`: two tasks name one pull request, which is the misfile `${CLAUDE_SKILL_DIR}/../../standards/tasks.md` rules out. Resolve the citation by hand, since no sweep repairs it.
+- `ambiguous`: two tasks name one pull request, which is the misfile `${CLAUDE_SKILL_DIR}/references/tasks.md` rules out. Resolve the citation by hand, since no sweep repairs it.
 - `earlier-slice`: the number is listed on the task but is not the last, so a later slice is still to merge. Leave the task on the board. Its last slice's merge archives it.
 - `pending-branch`: a branch named in `detail` ticked an outcome before its own pull request number was recorded. Leave the task live, since that branch's merge archives it once `git-pr` records the number. When the operator decides a named branch was abandoned, archive by stem, which is the one case for it.
 - `no-match`: the stem or number names nothing on the board. Check the name against the listed stems.

package/{standards → claude/skills/task-board/references}/board.md

@@ -7,6 +7,15 @@ description: Readiness groups, row cells, and ordering for priority.md, the unor
 
 Applies to `.canon/tasks/priority.md`, `.canon/tasks/backlog.md`, and `.canon/tasks/index.md`, the three files beside the tasks that say which one runs next. Update `priority.md` when a task is filed, planned, dispatched, or blocked, and `backlog.md` whenever the board is swept.
 
+## Contents
+
+- [Scope](#scope)
+- [What a working board looks like](#what-a-working-board-looks-like)
+- [The files](#the-files)
+- [Ordering](#ordering)
+- [The backlog](#the-backlog)
+- [Validation](#validation)
+
 ## Scope
 
 Governs the board files under `.canon/tasks/`: the readiness groups and their columns in `priority.md`, row order and the reason each row states, the backlog beside it, and the generated index.

package/claude/skills/task-board/references/decline.md

@@ -7,7 +7,7 @@ description: How task-board gathers the reason a task is decided against, runs c
 
 The Decline mode of `task-board`. The session reads this file when the request names a task decided against.
 
-Read `${CLAUDE_SKILL_DIR}/../../standards/tasks-decline.md` first. It holds the declined folder, the `Declined:` line, and what the move does to a plan and a board row.
+Read `${CLAUDE_SKILL_DIR}/references/tasks-decline.md` first. It holds the declined folder, the `Declined:` line, and what the move does to a plan and a board row.
 
 A task decided against carries no `post-merge` hook of its own, so every decline request arrives here directly rather than through work the hook already did.
 

package/{standards → claude/skills/task-board/references}/tasks.md

@@ -1,12 +1,6 @@
 ---
 title: Tasks reference
 description: Folder layout, filename convention, file format, origin lines, and archiving for task files under .canon/tasks/
-paths:
-  - '.canon/tasks/**'
-rule:
-  - 'Follow the board standard for `priority.md` and `backlog.md`, their readiness groups, and row order. Read it with `canon standards board`.'
-  - 'Never hand-edit `.canon/tasks/index.md`. A hook regenerates it from sibling frontmatter.'
-  - 'Follow the task decline standard for a task decided against. Read it with `canon standards tasks-decline`.'
 ---
 
 # Tasks reference
@@ -17,6 +11,18 @@ Update when a task starts, completes, or changes scope. When to open a task at a
 
 The folder is gitignored. Board state changes when work ships rather than when a branch is written, so committing it would put a claim about the future into the diff of an unrelated pull request. The git log records what shipped.
 
+## Contents
+
+- [Scope](#scope)
+- [Layout](#layout)
+- [Filenames](#filenames)
+- [Frontmatter](#frontmatter)
+- [File format](#file-format)
+- [Origin](#origin)
+- [What goes in](#what-goes-in)
+- [What does not go in](#what-does-not-go-in)
+- [Archiving](#archiving)
+
 ## Scope
 
 Governs the task files under `.canon/tasks/`: folder layout, filenames, frontmatter, file format, origin lines, and archiving.
@@ -27,7 +33,6 @@ Does not govern:
 - Execution order, readiness groups, the backlog, and the generated index beside the tasks: `board.md`
 - The plan file a task cites, its sections, and its answer contract: `plan.md`
 - Phase-label format and which surfaces a label may appear on: `versioning.md`
-- Architectural reasoning that outlives a task: `architecture.md`
 - The pre-compaction handoff sitting in the folder, its filename and its sections: `session.md`
 - When a project opens a task at all, which is project policy rather than a shape rule
 
@@ -154,7 +159,7 @@ The line is what lets a merge close its own task. `canon tasks archive --pull-re
 
 - Class names, file paths, function names, or prop names in any entry or title
 - Code-level steps or implementation detail. Behavioral specifics are fine.
-- Architectural reasoning that outlives the task. A finding explains why this task is shaped as it is. A decision the system keeps after the task closes belongs in `canon/ARCHITECTURE.md`.
+- Architectural reasoning that outlives the task. A finding explains why this task is shaped as it is. A decision the system keeps after the task closes belongs in the context entry of the domain it constrains.
 - Narrative of the session that produced the task. A finding states what constrains the task, so what was probed, what it cost, and who decided belongs in the groundwork folder the `Groundwork:` line names. A task with no groundwork folder cuts the narrative rather than relocating it, since the board is not the fallback destination for it.
 - "In progress" or "Blocked" headings. Note status inline on the outcome instead.
 - Sequencing rationale or which version is active. Why this task is planned before its neighbors goes on its row in `priority.md`, in the cell that already carries what it is waiting on. Rationale wider than one row has no home at all, so cut it rather than filing it here.