@erclx/canon 5.30.0 → 5.32.0

package/claude/skills/markdown-propose/references/format.md

@@ -1,118 +0,0 @@
-# Proposal format reference
-
-Governs the proposal `markdown-propose` writes before it edits anything. The concern being screened is an input and does not change the format.
-
-## Contents
-
-- [Folder](#folder)
-- [Change format](#change-format)
-- [The answer contract](#the-answer-contract)
-- [Applying](#applying)
-- [After](#after)
-- [Retrieval](#retrieval)
-
-## Folder
-
-- One folder per screening pass at `.canon/proposals/<nn>-<slug>/`, where the slug names the subject rather than the activity
-- One proposal file per source file, named `<nn>-<source filename, its own extension dropped>.md`, so a source already named `CLAUDE.md` becomes `01-CLAUDE.md` rather than `01-CLAUDE.md.md`
-- `00-overview.md` when the pass spans more than two source files, holding the cross-file pattern, the change counts, and the settle order
-- `applied.md` once the first change lands, holding every applied change with its reason and the answer it carried
-
-The folder's own `<nn>` and a proposal file's own `<nn>` are two independent counters. The folder's ordinal records when the pass was opened, counted within `.canon/proposals/` alone rather than shared with `plan-groundwork` or `plan-intake`'s sequence, and a proposal file's ordinal inside it records settle order, the dependency order changes apply in. Reading one as the other gets a pass dated wrong or an apply ordered wrong.
-
-The name carries both structures the folder has. The basename pairs a proposal to its source so a reader opens the two side by side, and the number is the settle order, which is a dependency rather than a preference: a file other files quote is settled first. Do not group proposals by theme.
-
-A proposal opened after the initial pass takes the next free number, and the folder is never renumbered. Its number records when the site was found rather than where it belongs in the dependency order. Renumbering to restore the order would rewrite the names of files already carrying answers, which costs more than the ordering is worth once applying has started.
-
-Settle a late proposal ahead of any unapplied proposal quoting the surface it covers, whatever the two numbers say. A proposal already applied is past the question, since the file it governs is committed.
-
-## Change format
-
-Each proposal file opens with `# Proposal: <source path>`, one line naming the concern, the settle order, and the full surface the pass screened, then one `###` heading per change, ending with a `## Left alone` section. A change never sits at `##`, which the closing section reserves, and a variant never sits at `###`, which the change heading reserves. Skipping from `#` straight to `###` is deliberate: the file has exactly one layer of change between its title and its variants.
-
-Naming the surface on every file, not only the first, is what lets Applying's cross-surface grep run cold. The Propose and Apply invocations are typically separate sessions days apart, so the surface the operator named has to survive on the file rather than in a conversation neither session shares.
-
-A change carries an `###` heading, a fenced `diff` block holding the current text against the proposed, the reason beneath it, and its own answer slot.
-
-- Heading: `### N. The sentence or section it sits in`
-- Body: a `diff` fence, `-` for current and `+` for proposed
-- `- **Why:** the reason, naming what the change fixes`
-- `- **Open:** only where the replacement was drafted rather than corrected`
-- `- **Recommended:** only where a pick is proposed ahead of the answer, directly above the slot`
-- `- **You:**` last on every change, shipped empty
-
-### Variants
-
-A corrected change carries one replacement. A drafted one carries three, because the intent behind invented prose is not recoverable from the source text and a single draft turns the answer slot into a veto.
-
-- Ship three variants on any change carrying `Open:`, labelled `#### A`, `#### B`, `#### C`
-- Make them differ in approach rather than in wording. Three phrasings of one bet are one variant.
-- State the bet each one makes in a line above its block, so the choice is between strategies and not between paragraphs
-- Ship one replacement everywhere else. A word swapped for the recorded fact has no second option worth reading.
-
-Three is the cap as well as the count. A fourth splits attention without widening the space.
-
-### Placement
-
-- Title a change by the section or sentence it sits in, never by its position in the file
-- Quote text from another file in a `markdown` block rather than citing a line number, which goes stale on the first applied change
-- Split a `Why:` into labelled halves when one change fixes two things (`**Why, the date:**`)
-- Carry an `Open:` on any change whose replacement text was written rather than corrected, so a blanket answer cannot swallow it
-
-Close each file with what it leaves alone. A pass reporting only what it would change reads as one that found everything wanting.
-
-## The answer contract
-
-`You:` belongs to the operator and ships empty on every change. Empty means unread and never agreement, matching the intake contract in `${CLAUDE_SKILL_DIR}/../../standards/intake.md` rather than the plan file's, which reads a blank slot as accepting the suggestion above it. State the inversion at the top of `00-overview.md` when the folder spans more than one file, since a contract read from the wrong surface gets applied to the wrong document.
-
-- One `You:` per change, last in its bullet list, so an answer lands where the change is read
-- Never fill a `You:` slot and never infer a disposition from an empty one
-- The slot takes free text, not only `ok`. A rejection, a caveat, or a rewrite of the proposed line are all valid answers and a later pass reads them correctly.
-- A pick made on the operator's behalf goes on a `- **Recommended:**` line directly above the slot, never inside it, and states which variant it takes and why. The slot below it still ships empty, so a count of unread changes still reads the change as unread.
-
-An answer rejecting the draft reopens the change rather than closing it. Move that answer to a `- **Answered:**` line above the variants it produced, and ship a fresh empty `- **You:**` beneath them. The change reads as unread again, which is what it is.
-
-Per-change slots do not license a partial sweep. Answering a change records one decision, and the applying rule below is what holds the set together.
-
-The overview file carries no slot, since it proposes no changes.
-
-## Applying
-
-- Apply one file at a time, in the folder's settle order
-- Apply every change in that file that carries an answer, and nothing that does not
-- Re-grep each change's anchor against its source before applying it, and again after a rebase
-- Grep the other named surfaces for the same claim before committing the file
-- Write every hit that grep returns onto the proposal owning the file it sits in, as a change with its own answer slot, and open a proposal for a surface the pass has none for
-- Commit the file once its own answered changes are applied. A hit in a sibling never holds it.
-- Move an applied change into `applied.md` beside the proposals, carrying its reason and its answer
-
-A partial pass is worse than none, and a file is the unit that can be finished. Settling one claim across every file at once touches all of them and closes none, so each file ends the pass looking reviewed while other changes in it sit answered and unapplied. The surface grep is what covers the cross-file half a per-file pass would otherwise miss.
-
-Recording a hit rather than acting on it is what keeps the grep from rebuilding the whole-set gate. A sibling holding the same claim is a change nobody has answered yet, and holding this file until it is answered makes every file wait on the slowest one, which is the shape the per-file unit replaced.
-
-A proposal outlives its own diff. The source moves under it, so an approved change stops matching while the defect it names survives in fresh wording. The anchor re-grep is the only thing that catches that.
-
-## After
-
-- Strip the `diff` blocks
-- Keep the files, their headings, their reasons, and the answers
-
-What remains is the record of what changed and why, which is the half no commit message holds. The folder stays where it is, beside every earlier pass, so a later one reads what an earlier one settled instead of asking it again.
-
-The folder is gitignored, and backed wherever a records remote is configured. It carries decision state rather than generated data, which is why `src/records/backup.ts` names it in `BACKED_FOLDERS` so `canon records push` and `canon records pull` carry it there, refusing with `no-remote` otherwise, but nothing else about its contents is enforced.
-
-## Retrieval
-
-Count the unread changes per file:
-
-```bash
-grep -c '^- \*\*You:\*\*$' .canon/proposals/<nn>-<slug>/*.md
-```
-
-Report every answer given, against the change it sits under:
-
-```bash
-awk '/^### /{h=FILENAME": "$0} /^- \*\*You:\*\*./{print h; print "   "$0}' .canon/proposals/<nn>-<slug>/*.md
-```
-
-Both walk `###` headings, which is the mechanical reason an answer typed anywhere else is lost.

package/claude/skills/memory-capture/REQUIREMENT.md

@@ -1,50 +0,0 @@
----
-name: memory-capture
-description: Which surface a session fact is owed to, what earns a memory file once routing has run, and why capture never edits a context entry itself
----
-
-# Memory capture requirement
-
-## Gap
-
-Without this skill, what a session learned dies with it, and the correction the user made in message four is re-earned next week. What does get written is a narrative of how the session went wrong rather than a rule that fires again, so a reader gets a story and no instruction. A new file lands beside one already holding the same topic, and the folder grows two entries per subject until nothing in it can be trusted as current.
-
-Writing every fact to one folder is the deeper gap, because the folder has no reader. A fact about a domain has an owning surface already, the context entry the three-tier model loads on demand, and filing it in memory instead puts it where only a deliberate sweep will ever find it. The measured outcome is a store that grows on every ship and is drained by nothing.
-
-The threshold is what the remaining folder lives or dies on. A first-occurrence slip saved as feedback is noise that costs every later session a read, and a fact the repository already records is worse, because it duplicates a source that will be updated without it. From a linked worktree, writes resolved against `pwd` land in a second memory folder nothing else reads.
-
-## Must
-
-- Resolve every read and write at the main worktree root, so parallel worktrees write one folder
-- Classify each candidate as feedback, project, user, or reference before routing or writing
-- Route a project candidate whose subject names an entry in `canon/context/index.md` to that entry, and hand it off as a file rather than an edit
-- Keep a candidate that matches no entry, or two entries with no clear owner, as a memory file
-- Apply the save threshold, firing feedback only on an explicit correction or a pattern that repeated twice
-- Grep the folder for an existing file on the topic and update it in place rather than adding a second
-- Keep a feedback or project body to the rule, one line of why, and one line of when it fires next
-- Write frontmatter the index renderer can read, so the generated catalog stays current
-- Report that nothing was worth capturing rather than manufacturing an entry to show work
-
-## Must not
-
-- Edit a context entry, which `context-fold` owns
-- Route a feedback, user, or reference candidate, since no context entry owns how to work or who to ask
-- Route anything when the caller does not commit, because a context entry is a tracked file
-- Hand-append a row to the memory index, which is generated from sibling frontmatter
-- Write a session narrative or a recovery account in place of the pattern
-- Save a first-occurrence slip as feedback
-- Create a second file on a topic the folder already holds
-- Save what the repository already records in code, git history, or its instruction files
-- Curate, promote, or delete an existing entry
-
-## Guards
-
-- No correction, confirmation, or context disclosure worth persisting: stop with a pass
-- Memory folder absent at the main root: create it rather than stopping
-- Session in the main worktree, or a caller that does not commit: skip routing and write every candidate as a memory file
-
-## Out of scope
-
-- Editing the context entries themselves, which `context-fold` owns on its own pass
-- Curating what is already in the folder, which `memory-review` owns
-- Promoting an entry into an instruction file or a skill body, which mutates how the agent operates and ships as its own change

package/claude/skills/memory-capture/SKILL.md

@@ -1,117 +0,0 @@
----
-name: memory-capture
-description: Extracts durable patterns from the current session, routes a domain fact to the context entry that owns it, and writes the residue to `.canon/memory/` as feedback, project, user, or reference files. Use when asked to "capture memory", "capture lessons", "wrap up the session", "end of session memory", or as a step in autoship. Do NOT use to curate existing memory. Use `memory-review` for that.
-metadata:
-  family: ship
----
-
-# Memory capture
-
-Scan the current session for patterns worth persisting, send each to the surface that owns it, and leave in `.canon/memory/` only what no surface owns. Pair with `memory-review` for later curation.
-
-A fact about a domain belongs in that domain's context entry, which the three-tier model already loads on demand. Writing it to memory instead puts it in a folder nothing opens. Routing is therefore the point of this skill and the memory file is the fallback.
-
-The filename and its type prefix, the frontmatter, the body shape each type carries, and the lifecycle are fixed by `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read it before writing an entry and follow it rather than working the shape from memory.
-
-## Guards
-
-- All `.canon/memory/` reads and writes resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
-- Every path below sits at the main root, so each write in this skill goes out as a heredoc, routed the way `session-worktree` states. A memory entry holds one fact and this session has read it, so an update rewrites the whole file with a heredoc rather than editing a line inside it.
-- If `.canon/memory/` does not exist at the main worktree root, create it, along with an `index.md` carrying `title` and `subtitle` frontmatter. `canon claude init` seeds both, and a project predating that seed has neither. Regeneration errors without the index, so the first write into a bare folder would report a frontmatter failure against a file that is fine.
-- If the session produced no user corrections, confirmations, or context disclosures worth persisting, run Step 6 and stop: `✅ Nothing worth capturing.`, followed by the review line when Step 6 counted one batch due.
-- Routing edits a tracked file, so it runs only where the caller commits. When the session is in the main worktree, or the caller states it does not commit, skip Step 3 and write every candidate as a memory file. `role-orchestrator` is the caller this covers.
-
-## Step 1: read context
-
-Read in parallel, skipping any that do not exist:
-
-- `${CLAUDE_SKILL_DIR}/../../standards/memory.md`: the filename, frontmatter, body shape, and lifecycle every entry follows
-- `CLAUDE.md`: the project's write location and any rule it states over the folder
-- `.canon/memory/index.md`: existing index, to avoid duplicates
-- `canon/context/index.md`: the domain catalog Step 3 routes against, read under `.claude/` instead in a project the surface move has not reached
-- `${CLAUDE_SKILL_DIR}/../../standards/markdown.md`: punctuation and formatting applied to memory file bodies
-- The `write-human` skill: voice, rhythm, and sentence construction applied to memory file bodies
-
-## Step 2: classify candidates
-
-Scan the session and group candidate patterns as `feedback`, `project`, `user`, or `reference`. What each type holds and what makes one fire are the Types table in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read the table and classify against it rather than against a recollection of the four names.
-
-Scan the whole session rather than its last exchange. A rule the user stated early and you followed since reads as settled and is exactly the one no file records.
-
-## Step 3: route what a context entry owns
-
-Only a **project** candidate is routable. Feedback, user, and reference describe how to work or who to ask rather than how a domain behaves, and no context entry owns them.
-
-For each project candidate, match its subject against `canon/context/index.md`. The test is a named entry, not a judgment about fit: the fact names a surface that already has an entry in the catalog. Route it to that entry.
-
-Fail closed. A project candidate matching no entry stays a memory file, and so does one matching two entries where neither is clearly the owner. The residue is what the folder is for, and a fact filed under the wrong entry is worse than one in memory because a context entry is a surface sessions trust.
-
-Do not edit a context entry here. `context-fold` owns those edits and folds the routed facts in on its own pass, or two skills write one file at the same step. Write each routed fact to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root instead, appending when the file exists. Name the heading with the entry's own path from `canon/context/index.md`, flat or the nested `index.md`, since that heading is what tells `context-fold`'s routed-facts fold which file to open. An append is a whole-file operation, so send it as a heredoc:
-
-A flat domain takes:
-
-```markdown
-## canon/context/<domain>.md
-
-<the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
-```
-
-A domain split into a folder takes its own generated index instead:
-
-```markdown
-## canon/context/<domain>/index.md
-
-<the fact in one or two sentences, stated as a fact about the domain rather than as a session narrative>
-```
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
-
-The handoff is a file rather than a spoken result so the routed fact survives a compaction between this step and the `context-fold` pass, and so the standalone caller leaves something behind for a later `/context-fold` to consume.
-
-## Step 4: dedupe
-
-For each remaining candidate, grep the top-level `*.md` files in `.canon/memory/` for an existing file on the same topic, never its `review/` or `archive/` subfolders, since a hit there is a receipt or a retired entry rather than a live one to update. If one exists, update it in place rather than create a new file. Read it first and write the whole file back, since the guard above rules out editing a line inside it. Carry a `reviewed` field through the rewrite untouched, since dropping it sends a kept entry back to the front of the review queue.
-
-## Step 5: write the residue
-
-Write each remaining candidate to `.canon/memory/<type>-<slug>.md`, following the template and the shape rules in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Copy the shape from there rather than from this body, so one edit to the standard moves every entry.
-
-Two of its rules are the ones a capture pass gets wrong under time pressure. State the rule rather than the incident that produced it, since the session ending is the only reader who has the narrative. Write the `title` as the rule itself, never as the filename stem.
-
-Do not edit the index. `.canon/memory/index.md` is generated from sibling frontmatter by a `PostToolUse` hook, the same way the task board's index is, so a hand-appended row is drift the next regeneration discards.
-
-A shell write skips that hook, as `session-worktree` states. Regenerate the index once after the last write when the entries went out through `Bash`:
-
-```bash
-canon indexes regen --no-stage --root <main-root> <main-root>/.canon/memory/index.md
-```
-
-Run `canon records validate memory` when the writes are done and fix what it names. It reads the whole pen rather than this session's writes, so treat a finding on a carried entry as one to fix in place rather than as a reason to stop.
-
-## Step 6: count what review owes
-
-Run `canon records stale memory --json` and count the entries whose `due` is true, and among them the ones carrying a non-empty `unresolved` list. Branch on the record rather than on the exit, which a shell function wrapping `canon` can flatten to zero. When the count reaches 25, one `memory-review` batch, the Output below adds the review line. Below that, add nothing.
-
-Stay silent when the record refuses or the installed binary carries no `records stale` subcommand. This step reports and never stops the capture.
-
-The line fires on a count rather than on every run. An unconditional prompt after each ship was tried and removed, since a review per ship costs more than it drains, and a hook would reach every session including workers that cannot act on it.
-
-## Output
-
-Respond with one line per fact routed, written, or updated:
-
-- `➡️ Routed: <fact subject> → canon/context/<domain>.md` for a flat entry, or `→ canon/context/<domain>/index.md` for a nested one, matching the heading the routing file carries
-- `✅ Wrote: .canon/memory/<file> (<type>)`
-- `✏️ Updated: .canon/memory/<file> (<type>)`
-
-When anything routed, add a line naming the handoff so the caller knows a `context-fold` pass is owed:
-
-`→ Routed facts wait at .canon/tmp/handoff/memory-routing/<slug>.md. Run /context-fold to fold them in.`
-
-Omit that line when the caller runs `context-fold` itself later in its own chain.
-
-When Step 6 counted at least one batch due, add the review line last:
-
-`→ <n> memory entries due for review, <m> citing a moved path. Run /canon:memory-review.`
-
-If nothing was captured, output `✅ Nothing worth capturing.`, followed by the review line when Step 6 counted one batch due.

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

@@ -1,52 +0,0 @@
----
-name: memory-review
-description: What memory review is for, the gaps it closes, and why every action waits on approval
----
-
-# Memory review requirement
-
-## Gap
-
-Without this skill, the memory folder grows and never drains. Entries pile up restating rules a durable surface already carries, nothing decides which memory has earned a place in one, and a rule that does get promoted arrives verbatim in a file whose voice it does not match. The folder then reads as a second source of truth that no surface points at.
-
-A pen too large to review whole is the same gap wearing a different shape. Routing at capture takes the domain facts and whatever the ownership test leaves stays, in whatever mix of types that is, so the folder reaches a size no single pass can read: every entry plus every promotion target runs to hundreds of thousands of tokens before one entry is classified. A review that cannot run drains nothing however often someone asks for it, so the pass takes a bounded batch in the order the stale verb reports and reads targets per entry. An entry leaving the pen is archived rather than deleted, because a folder git does not hold gives a wrong bulk call no undo.
-
-## Must
-
-- Treat the folder as a holding pen, so every entry in scope leaves it as a promotion, a handoff, or an archive, or stays only as a kept entry stamped with the date it was reviewed
-- Take one bounded batch per pass in the order `canon records stale memory` reports, and stop rather than falling back to a full sweep when that verb is absent
-- Stamp `reviewed` on every entry a pass keeps or skips, so the next batch moves on to entries nobody has read
-- Archive an entry out of the pen rather than deleting it, since nothing recovers a file from a gitignored folder
-- Hand a fact a context entry owns to `context-fold` through the routing file, rather than editing the entry here
-- Verify the rule is not already stated or implied in the target before proposing a promotion, by reading the target rather than trusting the memory's claim about it
-- Rewrite a rule into the destination's voice instead of moving it unchanged
-- Write the proposal to a receipt on disk and take no action until the user decides per item
-- Route every decision channel through the receipt, writing a decision given in chat into its item's slot before the parse reads the file, so a channel the skill advertises drains the pen rather than passing over it
-- Keep a promotion on its own commit, since a change to how the agent operates should not ride inside a feature a reviewer is vetting for something else
-- Collect a receipt as soon as its last item resolves, rather than waiting for an operator to ask, since a collection nobody triggers is a folder that only grows
-- Fold each declined item into its memory entry before the receipt goes, because a promoted item survives in its target and in git while a decline is recorded nowhere else
-- Record that decline by rewriting the entry rather than appending to it, so the file states one current claim
-- Confine the pass that runs after application to the one receipt it tested, so tidying up removes a file whose decisions are known to be resolved and leaves every untested receipt alone
-
-## Must not
-
-- Apply anything the user has not approved by item
-- Author a toolkit rule inline. A toolkit rule under `internal/rules/` or `governance/rules/` has an owner and a scaffolding path, `internal-governance`, and a rule written here bypasses it. A project rule under `.claude/rules/project/` is project-owned and takes an `Edit` appending to an existing file, or a handoff to `create-rule` when none fits.
-- Mutate tracked files from the main worktree
-- Answer a question raised in a decision slot while applying. Discussion and application are separate passes so an approval is never inferred from a reply.
-- Delete a memory entry at all. Every exit from the pen is a move into the archive.
-- Move an entry out of the pen outside the approved-per-item pass. The folder is gitignored with no history behind it, so a removal any other phase makes leaves no record of what it took.
-- Edit a context entry, or hand-edit the generated memory index
-
-## Guards
-
-- No memory folder at the main root: stop
-- The folder holds only its index: stop with a pass, not an error
-- Apply invoked from the main worktree: stop and name the worktree command
-- Cleanup invoked with no receipt on disk: stop with a pass, not an error
-
-## Out of scope
-
-- Writing memories, which `memory-capture` owns
-- Judging whether an entry should have been captured. That is a gate at capture time, and re-deciding it here would delete evidence the capture rule is wrong.
-- Editing the governance rules a handoff points at

package/claude/skills/memory-review/SKILL.md

@@ -1,129 +0,0 @@
----
-name: memory-review
-description: Reviews `.canon/memory/` and proposes per-entry actions (promote to an always-loaded rule, move into a skill body, route to a context entry, hand off to governance, or retire as stale). Also runs the discuss, challenge, apply, and cleanup phases on an existing review file. Use when asked to "review memory", "discuss memory questions", "challenge the promotes", "apply memory decisions", "cleanup memory review", "promote memory", or "consolidate memories". Do NOT auto-apply. Output a grouped proposal and wait for block-by-block approval.
-metadata:
-  family: ship
----
-
-# Memory review
-
-This skill drives the full memory review lifecycle in five phases. Pick the phase from what the user said and whether a review receipt already exists at `<main-root>/.canon/memory/review/memory-review-*.md`.
-
-What an entry looks like and why a retired one is moved rather than deleted are fixed by `${CLAUDE_SKILL_DIR}/../../standards/memory.md`. Read it before rewriting an entry, since a promotion rewrites the rule and a rewrite has to leave the entry conforming.
-
-| User intent                                                            | Phase     | Mutates                      |
-| ---------------------------------------------------------------------- | --------- | ---------------------------- |
-| "review memory", "promote memory", "sweep stale memories" (no receipt) | Propose   | review file only             |
-| "challenge the promotes" (receipt exists)                              | Challenge | review file only             |
-| "discuss", "respond to questions"                                      | Discuss   | review file only             |
-| "apply decisions", "commit", "ship the review"                         | Apply     | tracked files + memory files |
-| "cleanup", "delete the receipt"                                        | Cleanup   | one receipt + its skips      |
-
-If the user re-pings the skill with no new phrase and a receipt exists, default to Discuss when any `Decision:` contains `?`, otherwise Apply.
-
-## Guards
-
-- All `.canon/memory/` reads, edits, and archive moves resolve at the main worktree root, not the current worktree. Resolve that root the way `session-worktree` does.
-- If no `.canon/memory/` directory exists at the main worktree root, stop: `❌ No .canon/memory/ directory found.`
-- If `.canon/memory/` contains no top-level `*.md` entries other than `index.md`, stop: `✅ No memory entries to review.` The pen holds two subfolders now, `review/` and `archive/`, and neither is a memory entry, so this count and every entry read below stay at the top level and never recurse into either.
-- Cleanup is exempt from the two stops above. It works on receipts in `.canon/review/`, and a drained pen is the normal state once Apply has run, so a pen-shaped stop would strand the receipt it exists to delete.
-- Resolve the main root via `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`. All review and memory reads anchor here.
-- Every main-root write below goes out as a heredoc, routed the way `session-worktree` states. The receipt and a memory entry are both short and this session has read them whole, so a rewrite replaces the file with a heredoc rather than editing a line inside it. Promotion targets are tracked files at `pwd` and keep taking `Edit`.
-
-## Propose phase
-
-Propose is the entry point for a standalone run. The ship skills stop at capture and never invoke it.
-
-### Scope
-
-- **Batch:** run `canon records stale memory --json` and take the first 25 entries whose `due` is true, in the order the record lists them. When fewer than 25 are due, take all of them and say so. Never pad a batch with an entry that is not due.
-- **Named set:** when the user names entries, a list, or a slug, that set is the scope and overrides the verb's order. Propose nothing outside it.
-
-A whole pen does not fit one pass. Every entry plus every promotion target reads as several hundred thousand tokens on a grown project, so a full sweep fails before it classifies anything. The batch is bounded by the receipt the operator approves, which stays short enough for one pass at 25 items.
-
-Branch on the record rather than on the exit, which a shell function wrapping `canon` can flatten to zero. When the installed binary carries no `records stale` subcommand, or the record comes back with `ok: false`, stop: `❌ canon records stale is missing or refused. Update the canon CLI, since a review without it falls back to a full sweep that cannot run.` Never fall back to reading the whole pen.
-
-### Step 1: read the memory folder
-
-Read in parallel from the project root:
-
-- `.canon/memory/index.md`: the generated index, which is what lets a batch entry find a duplicate outside the batch
-- each entry in the batch, by name, never its `review/` or `archive/` subfolders: individual entries with frontmatter (`title`, `description`, `category`, and `reviewed` when a past pass kept it)
-
-### Step 2: search promotion targets per entry
-
-Do not read every target up front. For each entry in the batch, grep the target set below for the entry's subject, taking two or three keywords from its title and rule, and read the files that hit. Read `canon/context/index.md` once for the **Promote to a context entry** route. Skip any file or folder that does not exist.
-
-- `CLAUDE.md`: project behavior rules and Content ownership section, still a read target for the absorbed-already check even though it takes no new promotion
-- every `SKILL.md` under `.claude/skills/`: domain-scoped internal skill bodies
-- every `SKILL.md` under `claude/skills/`: plugin skill bodies
-- every `*.md` under `${CLAUDE_SKILL_DIR}/../../standards/`: authoring references
-- every `*.md` under `governance/rules/` in the toolkit repo, or `.claude/rules/` in a target project: coding-standards rules
-- every `*.md` under `internal/rules/` in the toolkit repo, or `.claude/rules/project/` in a target project: always-loaded rules a promote lands in
-
-A target the grep missed turns a promote into a retire, and only the operator's pass catches that. Name the targets each item searched in its receipt entry so the miss is visible there.
-
-### Step 3: classify each entry
-
-`.canon/memory/` is a holding pen. Default every entry to promote or retire on review. Keep is the exception, reserved for an entry still true that no surface owns, such as active task overlap or a user-type memory with no in-repo target.
-
-An entry's `unresolved` list in the stale record names paths it cites that the tree no longer holds. Weigh it as evidence for **Retire**, or for a rewrite when the rule survives the move, and never read it as the verdict alone. A rule can outlive the file it happened to name.
-
-`memory-capture` routes a project fact naming a domain with a context entry to that entry, so a pen filled since routing shipped is mostly feedback: rules about how to work, which no context entry owns. Propose against what the pen holds rather than expecting the older mix. An entry carried from before routing may still name a domain that has a context entry, and that entry's action is **Promote to a context entry**, which hands it to `context-fold` the same way capture does rather than editing the entry here.
-
-For each in-scope entry (see Scope), pick one action:
-
-- **Promote to an always-loaded rule**: the rule is cross-domain behavior or a design principle applied across the whole project, passing `592-claude-md.md`'s test (applies every session regardless of what is being edited). Do not author a toolkit rule file inline.
-  - In the toolkit repo, hand off to `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own `internal/rules/` (this repo only, never ships) and the audience group under `governance/rules/` the rule serves (ships to every target that group reaches).
-  - In a target project, append the rule to an existing file under `.claude/rules/project/` with `Edit`, since a project rule is project-owned and sync never overwrites it, or hand off to the `create-rule` skill when no existing file fits.
-- **Promote to a skill body**: the rule fires only when editing a specific path-scoped domain. Name the target skill.
-- **Promote to a standards file**: the rule is an authoring reference that belongs in the project's own standards folder as `<domain>.md`.
-- **Promote to a context entry**: the entry states a fact about a domain carrying an entry in `canon/context/index.md`. Append it to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root, in the format `memory-capture` writes, and tell the user to run `/context-fold` from a branch. Do not edit the context entry here. A project-identity or command fact takes this action when a context entry owns the subject, such as a development entry for commands, and **Retire** otherwise, naming a hand edit to `CLAUDE.md` as the reason. Memory review does not write the root file itself.
-- **Hand off to governance**: the rule is coding-standards class (typescript, testing, naming, error-handling, performance, logging, concurrency, planning), never a cross-domain behavior rule. Do not author the rule file inline. Never edit the synced `.claude/rules/` copies of toolkit rules, because `canon gov sync` overwrites them. Stop at handoff. This and **Promote to an always-loaded rule** never both claim one entry: class names the topic (coding-standards routes here), firing axis names the rest (applies-every-session routes to the rule promote).
-  - In the toolkit repo, point the user at `internal-governance` and `${CLAUDE_SKILL_DIR}/../../standards/rule.md`, which own the source-of-truth rules under `governance/rules/`.
-  - In a target project, point the user at the `create-rule` skill, which scaffolds a project-local rule under `.claude/rules/`.
-- **Retire**: the rule is stale, already absorbed into a durable surface, too vague to phrase as a rule, or a one-time incident narrative. Apply moves the file to `.canon/memory/archive/` rather than deleting it.
-- **Keep**: the rule is still true and no durable surface owns it. The entry stays in the pen, and Apply stamps `reviewed` so the verb does not queue it again until the window lapses.
-
-Retire is an archive, not a deletion, which `${CLAUDE_SKILL_DIR}/../../standards/memory.md` states as the rule and this skill executes. The archive is worth less than a plan's, since a promoted entry survives in its destination and a stale one is discarded on purpose, which is why the move is cheap rather than free.
-
-When two or more memories collapse into one rule on the same target, propose them as a single merged edit under the matching promote category. The consolidate case is a variant of promote, not a separate action.
-
-#### Absorbed-already check
-
-Before proposing promote, grep the target surface for the rule's keywords. If the rule is already stated there, the action is **Retire**, not promote. Do not rely on memory-file claims that a rule is documented elsewhere. Verify.
-
-The check covers implication, not only keyword match. If an adjacent bullet in the target section already implies the rule, merge into that bullet rather than append a second.
-
-#### Crispness check
-
-Rules that resist crisp one-line phrasing default to **Retire** over promote. Never promote a memory unchanged. Rewrite to match the destination surface's tone. Use single-directive rule-bullet phrasing for an always-loaded rule and imperative phrasing for skill bodies.
-
-### Step 4: write the proposal to the review file
-
-Derive `<slug>` per `${CLAUDE_SKILL_DIR}/../../standards/slug.md`. Fall back to `latest` on an empty result.
-
-Write the full proposal to `.canon/memory/review/memory-review-<slug>.md` at the main worktree root. Do not print it inline. Read `${CLAUDE_SKILL_DIR}/references/receipt-format.md` for the file structure, the item template, and how each action type varies the body. The four later phases rewrite items inside an existing receipt rather than authoring one, so none of them opens it.
-
-A phase changing items reads the receipt, applies every change for that phase, and writes the whole file back in one command. Batching is what keeps a per-item rewrite from costing a full read each time, and it is the only route from a linked worktree, where the guard above rules out editing a line in place.
-
-Tell the user `✅ Wrote proposal to .canon/memory/review/memory-review-<slug>.md`. Ask them to fill in `Decision:` per item, then re-ping with "discuss" for question rounds or "apply" to commit.
-
-Rewrite the review file in place whenever the proposal changes mid-review. The file stays the source of truth for the current decisions.
-
-## Challenge, Discuss, Apply, and Cleanup phases
-
-Each later phase runs on its own invocation against a receipt Propose already wrote, picked by the table above. Read `${CLAUDE_SKILL_DIR}/references/later-phases.md` on reaching any of them, for the phase's trigger, what it may mutate, its procedure, and the line it ends on. Challenge and Discuss rewrite the review file only, Apply stops on the main worktree, and Cleanup removes one receipt.
-
-## After completion
-
-Output one line per action taken in the most recent phase:
-
-- `✅ Promoted: .canon/memory/<memory-file> → <target>`
-- `✅ Handed off: .canon/memory/<memory-file> → governance`
-- `📦 Retired: .canon/memory/<memory-file> → .canon/memory/archive/`
-- `🗑  Swept: .canon/review/<review-file>, folded <n> skips`
-- `📌 Kept: .canon/memory/<memory-file>, reviewed <date>`
-- `⏭ Kept: .canon/review/<review-file>, <n> items pending`
-
-If the user accepted nothing, output: `✅ No changes applied.`

package/claude/skills/memory-review/references/later-phases.md

@@ -1,118 +0,0 @@
----
-title: Memory review later phases
-description: The Challenge, Discuss, Apply, and Cleanup phases of memory-review, each run on its own invocation against a receipt the Propose phase already wrote
----
-
-# Memory review later phases
-
-The phases of `memory-review` after Propose. The session reads this file when the phase table in the skill picks Challenge, Discuss, Apply, or Cleanup, and reads only the section for that phase. The skill's Guards still hold for every phase here.
-
-## Contents
-
-- [Challenge phase](#challenge-phase)
-- [Discuss phase](#discuss-phase)
-- [Apply phase](#apply-phase)
-- [Cleanup phase](#cleanup-phase)
-
-## Challenge phase
-
-Trigger: user says "challenge the promotes", "challenge before apply", or asks for a high-bar pass. Run before Apply. No mutations to memory files or promotion targets. Review file only.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root.
-2. For each promote item, apply three tests:
-   - **Absorbed**: grep the target surface for the rule's keywords. If already stated or implied, flip to retire.
-   - **Delta**: if the rule is a nice-to-have next to existing bullets, flip to retire.
-   - **Generality**: if the rule fires only on one literal trigger phrase, rewrite broader or flip to retire.
-3. Rewrite the review file in place with the updated actions and a one-line reason under each flip.
-
-## Discuss phase
-
-Trigger: user says "discuss", "respond to questions", or any `Decision:` value contains `?` or an unrecognized verb. No mutations to memory files or targets. Review file only. Multi-round.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root.
-2. For each item whose `Decision:` contains `?` or any unrecognized verb (anything other than `apply`, `skip`, `defer`):
-   - Write a `Take:` line under `Decision:`, separated by exactly one blank line. If a `Take:` line already exists, overwrite it.
-   - Format: pick + one-line reason. Max 2 sentences. Decision-help style. State the recommendation (`apply` / `skip` / `retire` / specific alternative) first, then the reason. Do not enumerate tradeoffs unless one changes the call.
-   - Leave the H2 emoji as 📝 pending.
-3. Skip items whose `Decision:` is `apply`, `skip`, `defer`, or empty.
-4. End with: `💬 Discussed: <nums> | ⏩ Skipped (committed or empty): <nums>`. Remind the user to refine `Decision:` lines and re-ping with "discuss" for another round, or "apply" when ready to commit.
-
-Do not act on any item. Do not archive memory files. Do not edit promotion targets. Discuss only.
-
-## Apply phase
-
-Trigger: user says "apply", "commit", "ship the review", or re-pings with no question items remaining. Mutates tracked promotion targets and moves memory files into the archive.
-
-Before applying any item, check the worktree state:
-
-```bash
-[ "$(git rev-parse --git-dir 2>/dev/null)" = "$(git rev-parse --git-common-dir 2>/dev/null)" ] && echo "MAIN" || echo "LINKED"
-```
-
-If the result is `MAIN`, stop and tell the user: `❌ Apply phase mutates tracked files. Run /session-worktree first.` Discuss and Challenge phases only touch `.canon/review/` scratch and run from anywhere.
-
-Before applying a promote to an always-loaded rule in the toolkit repo, load `internal-governance`, which owns `internal/rules/` and `governance/rules/` and is the only route that may author into either. In a target project, hand off to `create-rule` with no load, since `internal-governance` is a toolkit-internal skill under `.claude/skills/` that a target project never has. An `Edit` appending to an existing file under `.claude/rules/project/` needs no load either.
-
-Promotions are a separate concern from any feature in flight. Keep the promoted edits on their own commit. Do not fold an always-loaded-rule or skill-body change into a feature's commits, because a feature reviewer should not have to vet a change to how the agent operates.
-
-For each item, parse the `Decision:` line:
-
-- `apply` (or affirmative): run the proposed action, flip emoji to ✅.
-- `skip`: leave the memory in place, stamp it reviewed as below, flip emoji to ⏭.
-- `defer` or empty: leave 📝 pending, take no action.
-- Contains `?` or unrecognized verb: leave 📝 pending, take no action. Do not respond. Discussion is the Discuss phase's job.
-
-Free-form text after the verb is a reason. Capture it in the receipt but do not let it change the action. When committing an item, strip any empty `Take:` line so the receipt stays clean. `Take:` lines with content stay as discussion history.
-
-Action by action type:
-
-- **Promote**: use `Edit` to insert the rewritten rule into the target surface, then archive the memory file. A promote to an always-loaded rule in the toolkit repo never reaches this line: it stops as a handoff to `internal-governance`, the same as **Hand off** below, and archives only on the user's explicit confirmation.
-- **Promote to a context entry**: append the fact to `.canon/tmp/handoff/memory-routing/<slug>.md` at the main worktree root, then archive the memory file. `context-fold` folds it in on its next run from a branch, which is what keeps one skill writing context entries.
-- **Hand off**: do not edit governance. Archive the memory file only if the user confirmed the handoff explicitly. Otherwise leave it in place.
-- **Retire**: archive the memory file.
-- **Keep**: stamp the memory file reviewed as below, and flip the emoji to 📌.
-
-Stamping means writing `reviewed: <today>` as a `YYYY-MM-DD` date into the entry's frontmatter, replacing any earlier value, and changing nothing else in the file. The entry is main-root scratch, so the stamp goes out as the same whole-file heredoc rewrite the Guards state. Stamp only an entry that stays in the pen, being a keep or a skip. A promote or a retire takes no stamp, since the entry leaves for the archive. The stamp is what takes a kept entry off the front of `canon records stale memory`'s queue, so an entry kept without one returns in the next batch.
-
-Archiving means creating `.canon/memory/archive/` at the main worktree root and moving the file there under its original name, overwriting any file already at that name. Send the `mkdir -p` and a plain `mv`, routed the way `session-worktree` states for a main-root move. Never delete a memory entry. Nothing recovers one from a gitignored folder.
-
-Do not hand-edit `.canon/memory/index.md`. Once every archive move and stamp is done, regenerate it instead:
-
-```bash
-canon indexes regen --no-stage --root <main-root> <main-root>/.canon/memory/index.md
-```
-
-An archive move is a shell `mv`, which skips the index hook the way `session-worktree` states. Without this call the index keeps a row per archived entry and drifts exactly the way the hand-appended one did. Run it once after the last move rather than per item.
-
-Apply promotion edits one at a time via `Edit`. Claude Code's tool permission dialog is the confirmation gate per edit. Never rewrite a whole promotion target.
-
-This governs the tracked surfaces a promote lands in, which sit at `pwd` and take `Edit` from anywhere. The receipt and the memory entries are main-root scratch and follow the skill's heredoc guard instead.
-
-As each item resolves, update its status in the review file: flip the H2 emoji from 📝 to ✅ for applied, ⏭ for skipped, 📦 for retired, 📌 for kept, or 🤝 for handed off. Refresh the summary block counts at the top. Do not delete the file here. The sweep below decides whether it goes.
-
-**Chat shortcut:** the user replies with `all`, `none`, a comma-separated list of numbers, or `skip <nums>`. Write the matching verb into the `Decision:` slot of every item the reply names, `apply` for `all` or a bare list and `skip` for a `skip` reply, then run the parse above against the file. A reply of `none` writes nothing. A slot the reply does not name keeps its own value, so the receipt stays the source of truth and an empty slot still means take no action.
-
-### Sweep the receipt
-
-Count the items still pending once the parse above has run. An item is pending when its H2 carries 📝, or when its H2 carries no status emoji and its `Decision:` slot holds nothing the parse above would act on or skip, since a receipt written by hand or by an older binary may lack the marker. Apply leaves one pending on `defer`, on empty, and on any unrecognized verb, so a receipt reaching this point may still be holding decisions.
-
-Leave the receipt in place when any remain. When none do, collect it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, which owns what a fold writes and which entry types take one.
-
-`context-fold` Step 9 sweeps the same folder on the same rule once per shipped branch, and either may reach a receipt first. Whichever does, the other finds no file and moves on.
-
-End with: `✅ Applied: <nums> | ⏭ Skipped: <nums> | 📝 Pending: <nums>`. Omit empty buckets. If anything is pending, remind the user they can refine `Decision:` lines and re-ping, run "discuss" for question items, or commit a skip with `skip <nums>` in chat.
-
-## Cleanup phase
-
-Trigger: user says "cleanup" or "delete the receipt" after Apply has run.
-
-Cleanup folds one receipt's skips and removes that receipt, and does nothing else. It is the fallback route now that Apply and `context-fold` Step 9 each collect a resolved receipt on their own, so it reaches a file those two left behind rather than being the only collector. Apply is still the only phase that moves a memory entry out of the pen, and it does so per approved item into `.canon/memory/archive/`. A user asking to sweep stale memories wants Propose, which classifies entries and writes a decision slot per entry.
-
-If no `.canon/memory/review/memory-review-*.md` exists at the main root, stop: `✅ No review receipt to clean up.` Every other refusal in this skill carries a message, and the phase reads a receipt before it does anything else.
-
-1. Read the latest `.canon/memory/review/memory-review-*.md` at the main root and confirm Apply has run against it. If any item is still pending, by the test the Apply sweep states, stop and name the pending numbers.
-2. Collect it per the collection rule in `${CLAUDE_SKILL_DIR}/../../standards/memory.md`, folding each ⏭ skipped item before the file goes. The fold happens wherever a receipt is collected, so this phase runs the same rule the Apply sweep does.
-3. Delete that one file. Leave every other receipt beside it in place, because the pending test above covers the file it read and nothing has tested the rest.
-4. Leave every memory entry in the pen. A skip records the decline on the entry and keeps the file, and applied promotions, governance handoffs, and user-type memories each stay as the review left them.
-
-Do not promote or archive a memory entry. The skip fold is the one rewrite this phase makes, and it records a decline on an entry that stays in the pen.