@erclx/canon 4.104.0 → 4.106.0

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

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "4.104.0",
+  "version": "4.106.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

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

@@ -38,7 +38,24 @@ Announce which of the two decided the sequence.
 
 ## Step 3: detect the write folder
 
-Check for `public/`, `static/`, or a stack-declared asset folder, taking the first that exists. Fall back to the project root when none is detected, mirroring `design-extract`'s own source-versus-greenfield split. Announce the folder so the operator can move the files if the project's own convention differs.
+A root-only check finds a project's assets only where the project keeps them at the root. A repository holding its site in a subfolder keeps them a level down, and a Next project keeps its favicon under the App Router convention with no `public/` at all, so both fall through to the root fallback while the announcement reads as a detected folder. Walk one level down and know that convention rather than falling through.
+
+Read both, from the project root:
+
+```bash
+find . -maxdepth 3 \( -name node_modules -o -name .git -o -name dist -o -name .astro \) -prune -o -type d \( -name public -o -name static \) -print | sort
+find . -maxdepth 4 \( -name node_modules -o -name .git \) -prune -o -type d -path '*/src/app' -print | sort
+```
+
+Take the first tier that answers:
+
+1. A root `public/` or `static/`.
+2. A `public/` or `static/` one level down, such as `web/public/`. Where the first read returns more than one, take the shallowest, and the one whose parent holds the project's own framework config where two sit at the same depth.
+3. A `src/app/` folder, at the root or one level down, which is the Next App Router convention and where that framework's own favicon and card files sit. Take the folder itself, not a `public/` beside it.
+4. A stack-declared asset folder, where the project's own config names one.
+5. The project root, which is the fallback rather than a detection.
+
+Announce which tier decided, naming the tier rather than the path alone. On tier 5 say the detection found nothing and the root is a fallback, since a folder reported without that word reads as a folder the project declared. Announce it either way so the operator can move the files where the project's own convention differs.
 
 ## Step 4: name the decision and the arms
 
@@ -50,14 +67,12 @@ Structure every arm as a `.mark` element, the inline SVG alone, nested inside a
 
 Follow `${CLAUDE_SKILL_DIR}/../draft-and-pick/SKILL.md` Steps 2 through 5 against the arms from Step 4: author the page, render and hand off, take the pick, and loop on it.
 
-## Step 6: finalize
+## Step 6: finalize the mark and the icons
 
-This step replaces `draft-and-pick`'s own Step 6, since the pick here produces several final files rather than one applied surface.
+This step and Step 7 replace `draft-and-pick`'s own Step 6, since the pick here produces several final files rather than one applied surface.
 
 1. Extract the picked arm's `.mark` markup as the final vector source. Write it to `<write-folder>/favicon.svg`.
-2. Under `<dest>/render/`, write one page per Step 2 size plus one for the card. Give every page's captured element the shared class `.render`, so one capture call renders the whole batch regardless of the size spread. `canon capture` opens every page at a fixed 2x device scale factor and screenshots the element at that scale, so declare each `.render` element at half its target dimension, `<w>/2` by `<h>/2`, to land the captured PNG on the literal target size rather than double it. Declare a machine-resolved font stack (`system-ui` behind a generic fallback) on each, since `canon capture` refuses a page naming no font at all.
-   - `icon-<w>x<h>.html`: the picked `.mark` markup, its `.render` wrapper sized `<w>/2` by `<h>/2`
-   - `og-image.html`: the picked `.card` markup, its `.render` wrapper sized 600x315 to capture at the native 1200x630
+2. Under `<dest>/render/`, write one `icon-<w>x<h>.html` page per Step 2 size, carrying the picked `.mark` markup. Give every page's captured element the shared class `.render`, so one capture call renders the whole batch regardless of the size spread. `canon capture` opens every page at a fixed 2x device scale factor and screenshots the element at that scale, so declare each `.render` element at half its target dimension, `<w>/2` by `<h>/2`, to land the captured PNG on the literal target size rather than double it. Declare a machine-resolved font stack (`system-ui` behind a generic fallback) on each, since `canon capture` refuses a page naming no font at all.
 3. Render the batch:
 
    ```bash
@@ -65,16 +80,75 @@ This step replaces `draft-and-pick`'s own Step 6, since the pick here produces s
    ```
 
 4. Report each written file's path and the dimensions `canon capture` printed for it, confirming each equals its Step 2 target rather than half of it.
-5. Delete `<dest>`, per `draft-and-pick`'s own scratch-folder rule.
+
+The card leaves this batch and takes Step 7 instead. An icon is the mark alone at a fixed size and a scratch page renders it faithfully, where the card is a composition of the mark with the project's own type and color and a scratch page can only carry typed copies of both.
+
+## Step 7: write the card as a route and capture it through the server
+
+A card captured from a page this run deletes leaves the project a PNG and nothing that produced it, so renaming the project means another pass through the pick loop with an operator in it to move one string. Write the composition into a route the project keeps, and capture that route through a running server so it reads the project's real stylesheet, tokens and fonts.
+
+This is Astro-shaped in v1, because Astro is the one web stack whose config gives a route a structural build exclusion. A project already holding the card route scaffold takes the route path, and everything else falls to the page path below. Say which one decided, since the two leave the project different things.
+
+### The route path
+
+1. Check that the project already holds the scaffold, being a `card.config.mjs` with a `card-src/pages/og-card.astro` beside it. Take the page path below where either is missing, and leave the install to the operator:
+
+   ```plaintext
+   No card route installed, so the card shipped as a PNG this run.
+   `canon tooling sync astro . --write` installs the route, and it replaces every other
+   golden config in the astro stack, so run it when you mean to sync the stack.
+   ```
+
+   Never run that sync to obtain the route. It copies the whole stack over the project's own framework, lint, typescript, and test configs, which is a cost nobody asking for a logo agreed to. Hand-writing the scaffold instead is the other wrong answer, since a copy written here drifts from the one the stack maintains.
+
+   The scaffold is a second framework config pointing `srcDir` at a folder beside `src/`, the route inside that folder importing the project's global stylesheet and carrying a fixed `<meta>` marker, and a shell check failing a build that carries the marker. Of the route's three consumers, the published build is the only one a check reaches. Read the shape with `canon tooling reference astro`.
+
+2. Write the picked arm's `.card` markup into the route's `.card` element, leaving the marker, the stylesheet import and the surrounding document alone. Keep the element at 600x315, half of the 1200x630 target, since the capture's 2x scale factor is fixed and a 1200x630 element captures at 2400x1260.
+
+3. Start the card server in the background and read the port off its own output:
+
+   ```bash
+   bun run card:dev
+   ```
+
+   It serves under a strict port, so it refuses rather than walking to the next free one. Set `WORKTREE_PORT_OFFSET` by hand and start it again where something already holds that port.
+
+4. Capture the route to the write folder, naming the destination PNG rather than a directory, which is what a URL source takes for `--out`:
+
+   ```bash
+   canon capture http://localhost:<port>/og-card --selector .card --out <write-folder>/og-image.png
+   ```
+
+5. Stop the server. Report the dimensions `canon capture` printed, confirming 1200x630.
+
+A refusal naming a font here is the mechanism working rather than a failure to route around. It says the route asked for a family the machine cannot resolve, which is the same rewrap a published card would have shipped silently.
+
+### The page path
+
+Where the project holds no route to write into, write `og-image.html` into `<dest>/render/` with its `.render` wrapper sized 600x315, then capture that one page:
+
+```bash
+canon capture <dest>/render/og-image.html --selector .render --out <write-folder>
+```
+
+It takes its own call rather than riding Step 6's batch, since Step 6 runs before this step chooses a path and the batch is already captured by the time the choice is made. Say that the card shipped as a PNG with no source, and that the project gains one when it grows a route to hold the composition.
+
+### Closing the scratch folder
+
+Delete `<dest>` per `draft-and-pick`'s own scratch-folder rule. The route is not a leftover variant that rule forbids: a variant is one of several candidates none of which was chosen, and the route holds the arm the operator picked. The losing arms are what that rule is about, and they are already archived and deleted by the step it belongs to.
+
+A project whose card was generated before this route existed keeps its PNG. Say so rather than regenerating it, since re-running the pick loop spends an operator's attention on a file nobody complained about, and the next real edit to the card picks up the route.
 
 ## Response format
 
 ```plaintext
 📝 Wrote <write-folder>/favicon.svg
 📝 Wrote <write-folder>/icon-16x16.png (16x16)
+📝 Wrote card-src/pages/og-card.astro (route path only)
 📝 Wrote <write-folder>/og-image.png (1200x630)
 
-Write folder: <detected <path>|defaulted to project root>. Move the files if this project's own convention differs.
+Write folder: <tier that decided>. Move the files if this project's own convention differs.
+Card source: <the route, captured through the card server|a scratch page, since this project holds no card route>.
 ```
 
 ## What this delegates
@@ -83,4 +157,5 @@ Cite these rather than restating them.
 
 - `draft-and-pick` owns Steps 1 through 5 of the render-and-pick loop, cited above
 - `design-extract` owns building `canon/DESIGN.md`. This skill only reads it.
-- `canon capture` owns the render mechanics, its font refusal, and its reported dimensions
+- `canon capture` owns the render mechanics, its font refusal, its fixed 2x scale factor, and its reported dimensions. It already reads an `http(s)://` source, where `--out` names the destination PNG rather than a directory, so the route capture needs nothing added to it.
+- The `astro` tooling stack owns the card route's scaffold, its second config, and the exclusion check, read with `canon tooling reference astro`. This skill writes into the route and never reshapes it.

package/claude/skills/role-planner/REQUIREMENT.md

@@ -1,6 +1,6 @@
 ---
 name: role-planner
-description: What a planning session is, how it reads what is in flight, the surfaces it may not write, and what it hands back to whoever dispatched it
+description: What a thinking session is across planning, groundwork, and intake, how it reads what is in flight, the writes-records-never-source boundary, and what it hands back to whoever dispatched it
 ---
 
 # Role planner requirement
@@ -49,25 +49,30 @@ four carried at least one, caught only because the planner ran
 
 ## Must
 
-- Assert what a planning session is, what it may not write, and how long the role lasts, since `plan-feature` carries the procedure and no body carries the role
+- Assert what a thinking session is, what it may not write, and how long the role lasts, since `plan-feature`, `plan-groundwork`, and `plan-intake` each carry their own procedure and no body carries the role the three share
+- Cover all three of those skills rather than `plan-feature` alone, since a groundwork or intake session took no role at all while the body was written for one plan under one task
+- State the writes-records-never-source boundary once, and name the three folders in one line while deferring each scope's exceptions to the skill that owns it, so a change to one scope edits one body
+- Carry `plan-groundwork`'s close-time task file as an exception to the board ban, since widening the role without it makes the role forbid what that skill requires
 - State the in-flight read as a command composing the session roster with open pull requests, and say that a branch and a worktree are not evidence, since a count of either reported merged work as live
 - Run that read once per task rather than once per batch, since a reused session ages its picture of the tree while it works
 - Name every read a plan needed and a launch string did not carry, the task file's findings and the source files among them, since a count quoted from a row was wrong or stale in ten places across four plans
 - Name the validate and audit calls the written plan passes through, since nothing else opens a plan and the audit caught ban hits in three of four trial plans
 - State the shared board as read-only and name the cross-feature call as the controller's, since a planner reading blockers and file sets can write a merge order off a partial picture and will not notice that it has
-- Owe an announcement when the plan lands, carrying the path and what the row got wrong, since the controller cannot watch the read happen
+- Owe an announcement when the record lands, carrying the path and what the row got wrong, since the controller cannot watch the read happen
 - Owe a message before a block becomes an interactive prompt, since a session already waiting on input never reaches the tool round an inbound message drains at
 - Keep correcting the dispatcher a first-class move carrying its evidence, since a trial corrected a brief's premise, planned every row anyway, and carried the consequence into a plan question
-- Point at `plan-feature` for the plan's shape and the steps that write it
+- Point at each of the three skills for its record's shape and the steps that write it
+- Defer the addressee resolution to `session-relay` and keep only the last-rung inference, which discriminates differently here than it does for a worker because a session in this role holds no feature branch either
 
 ## Must not
 
-- Restate the plan's sections, its suggested-and-answer contract, or the steps `plan-feature` carries, since thinness is what keeps one body correct for a dispatched planner reading it as its whole contract
+- Restate a record's sections, its suggested-and-answer contract, or the steps the running skill carries, since thinness is what keeps one body correct for a dispatched session reading it as its whole contract
+- Restate the write-scope exceptions each of the three skills states about its own folder
 - Restate a boundary `role-orchestrator` or `role-worker` states about itself
 - Tell a planner to halt on a plan question, which the suggested line already answers, rather than on what blocks writing the plan at all
 - Tell a planner to report the path with no account of what the row got wrong. That instruction came from a trial condition holding a blind comparison intact, and it is not a durable obligation.
 - Report progress through the channel, which rebuilds on the sender's side the poll the announcement exists to retire
-- Write the priority board, the backlog, or the task file, at any size
+- Write the priority board or the backlog, at any size, or the task file outside `plan-groundwork`'s close-time exception
 - Be a skill nothing invokes but its author typing the name. `orchestrator-dispatch.md` names it on the planning launch the way it names `role-worker` on a build, so a stretch where only a typed invocation reaches it is the signal that the role never took.
 
 ## Guards
@@ -79,7 +84,9 @@ four carried at least one, caught only because the planner ran
 
 ## Out of scope
 
-- The plan's sections and its answer contract, which `standards/plan.md` fixes, and the steps that write the file, which `plan-feature` owns
+- Each record's sections and its answer contract, which the standard behind it fixes, and the steps that write the file, which `plan-feature`, `plan-groundwork`, and `plan-intake` each own for their own
+- The write-scope exceptions, which stay in the three skills: groundwork's close-time task file, its fixture and evidence paths, and intake's statement that it has none
+- The mechanical addressee resolution, which `session-relay` owns for every session with or without a role
 - The branch, the build, and the pull request, which `role-worker` and `auto-ship` own
 - Deciding which rows run and in what order, which is the controlling session's call and stated in `role-orchestrator`
 - The dispatch itself, its collision check, and its disjointness gate, which `orchestrator-dispatch.md` holds

package/claude/skills/role-planner/SKILL.md

@@ -1,54 +1,71 @@
 ---
 name: role-planner
-description: Asserts the planner role for a session writing one plan under one task, holding what it reads before deciding, the surfaces it may not write, and what it hands back. Use when asked to "be the planner", "you are a planner session", at the start of a dispatched or hand-launched planning run, or when a planning session needs to know what it may not write. Do NOT use to write the plan itself, which is `plan-feature`, to make the cross-feature merge call, or to implement.
+description: Asserts the planner role for a session writing one plan, groundwork track, or intake pass under one row, holding what it reads before deciding, what may be written and where, how to read what is already in flight, and what it hands back. Use when asked to "be the planner", "you are a planner session", at the start of a dispatched or hand-launched planning, groundwork, or intake run, or when a planning session needs to know what it may not write. Do NOT use to write the record itself, which is `plan-feature`, `plan-groundwork`, or `plan-intake`, to make the cross-feature merge call, or to implement.
 ---
 
 # Role planner
 
-This session is a planner: one session writing one plan for one task. It reads
-the row, measures what the row claims against the tree, writes the plan, and
-hands back the path.
+This session thinks rather than builds. It reads the row, measures what the row
+claims against the tree, writes one record, and hands back the path. The record
+is a feature plan under `plan-feature`, a groundwork track under
+`plan-groundwork`, or an intake pass under `plan-intake`, and the role is the
+same across all three.
 
 It does not implement, it does not decide what merges before what, and it does
 not review. Those belong to a worker, to the controlling session, and to the
 human.
 
 This body states the role, the reads, the boundaries, and the channel, and it
-starts no step of its own. `plan-feature` owns the steps that write the plan
-and cites the standard fixing its sections and its suggested-and-answer
-contract, so read the procedure there and reach it from the launch rather than
-from here.
+starts no step of its own. Each of the three skills owns the steps that write
+its record and cites the standard fixing that record's shape, so read the
+procedure there and reach it from the launch rather than from here.
+
+"Planner" stretches to cover measuring and triage. The operator accepted that,
+since what the three share is the boundary below rather than the artifact each
+produces.
 
 ## Where the session stands
 
-- Write one file, the plan, at `.canon/plans/feature-<slug>.md` on the main worktree root. Everything else this session touches is a read. This session holds no worktree, so send the file as a plain `Bash` heredoc past the same main-root refusal a linked worktree meets. The route skips the write-matched hooks, and they are no-ops on a plan file.
-- Never enter a worktree, never create a branch, and never write a tracked file. A planner that builds has stopped being one, and the row loses the independent read the worker's own session was going to bring to it.
-- Resolve `.canon/plans/`, `.canon/tasks/`, and `.canon/review/` at the main worktree root. Those folders are gitignored, so a copy beside a linked worktree is absent rather than empty.
-- Plan the row the launch named. Report a second row met while reading rather than planning it, since which rows run is the controller's call.
+- Write records, never source. A tracked file under `src/`, a standard, a rule, a reference doc, and a seed all sit outside what this session may touch, whichever of the three skills it is running.
+- Write only into the folder the running skill names: `plan-feature` at `.canon/plans/`, `plan-groundwork` at `.canon/groundwork/<nn>-<slug>/`, and `plan-intake` at `.canon/intake/<nn>-<slug>/`. Each skill's own `## Write scope` carries its exceptions, which is why they are not listed here. A change to one scope then edits one body.
+- Resolve every one of those folders, and `.canon/tasks/` and `.canon/review/` beside them, at the main worktree root. They are gitignored, so a copy beside a linked worktree is absent rather than empty and reads as a folder nobody has written yet.
+- Never enter a worktree, never create a branch, and never write a tracked file. A thinking session that builds has stopped being one, and the row loses the independent read the worker's own session was going to bring to it.
+- This session holds no worktree, so send each record out as a plain `Bash` heredoc past the same main-root refusal a linked worktree meets. That route skips the write-matched hooks, which are no-ops on a record file.
+- Work the row the launch named. Report a second row met while reading rather than taking it on, since which rows run is the controller's call.
 
 ## What to read before deciding
 
-Each item below is something a plan needed and a launch string did not carry.
+Each item below is something a record needed and a launch string did not carry.
 
 - The task file, and its `## Findings` before deciding anything. A row can carry its own disproof under a title that still states the original claim, which is how one trial nearly planned against a premise the file had already recorded as dead.
 - The source files themselves, opened rather than summarized. Never a count quoted from the task file, which was wrong or stale in ten places across four plans.
 - `CLAUDE.md` and `canon/ARCHITECTURE.md`, for the decision and the alternative it was taken against rather than for the decision alone.
-- The plan of any row this one is sequenced behind, including one already moved to `.canon/plans/archive/`. Reading a shipped plan produced the strongest constraint in the first trial and no brief asked for it.
 - `.canon/tasks/priority.md` for the row's Touches column and its stated blocker. That column is the file set the dispatch disjointness gate already reads.
+
+Two reads belong to the `plan-feature` path alone, since neither a groundwork
+track nor an intake pass is sequenced behind another row or validated as a plan:
+
+- The plan of any row this one is sequenced behind, including one already moved to `.canon/plans/archive/`. Reading a shipped plan produced the strongest constraint in the first trial and no brief asked for it.
 - `${CLAUDE_SKILL_DIR}/../../standards/plan.md` for the shape, then `canon records validate plans` and `canon markdown audit <the plan file>` on the file once it is written. Nothing else opens a plan, since `.canon/plans/` is gitignored and the audit's default path set is what git lists.
 
+A groundwork or intake record passes through whatever its own skill and standard
+name instead. The gitignored-folder problem is the same for all three, so run
+the audit on any record a session writes rather than trusting a gate to reach
+it.
+
 ## Read what is in flight rather than inferring it
 
 - Run `canon sessions list --json`, take the `branch` field of every session whose `repository` matches this one and whose branch is neither null nor the trunk branch, union that with every `headRefName` from `gh pr list --json number,headRefName`, dedupe by branch name, then diff each with `git diff --name-only main...<branch>` for its file set. That resolves locally whether or not a pull request exists, since every track in this repository shares one git directory across its worktrees.
 - A bare branch or worktree with neither a live session nor a pull request behind it is still not evidence, since this repository squash-merges and leaves both behind. The roster read is already filtered to live sessions, so what changed is the second source composed with it rather than a raw count. It still misses a live session that reached its worktree through the direct-path fallback rather than `EnterWorktree`, since that session's registered branch never moves off the trunk.
-- Run the read once per task rather than once per batch. A session planning several rows ages its picture of the tree while it works, and this read is what dates it.
-- Name each in-flight set as a constraint, say which act it forbids, and stamp the block with the commit the tree was read at, per Constraints in the plan standard. A bare path list leaves the worker guessing.
+- Run the read once per row rather than once per batch. A session working several rows ages its picture of the tree while it goes, and this read is what dates it.
+- Name each in-flight set as a constraint, say which act it forbids, and stamp the block with the commit the tree was read at. A bare path list leaves the reader guessing. The plan standard fixes that block for a feature plan, and a groundwork or intake record carries the same three parts in whatever shape its own standard states.
 
 ## The board is read-only
 
 - Never write `.canon/tasks/priority.md` or `.canon/tasks/backlog.md`. Both are gitignored, so an overwrite drops a row with no history to recover it from.
-- Never write the task file either. The plan is the whole output, and a row edited from here changes what the controller reads back as the state of the board.
-- Report what the row got wrong rather than repairing it. A stale count, a moved line, or a path that no longer resolves goes into the plan and into the handback, and the controller decides which of the two carries the correction.
+- Never write the task file. The record is the whole output, and a row edited from here changes what the controller reads back as the state of the board.
+- One exception, and it belongs to `plan-groundwork` alone: that skill writes a single task file at close, recording what the track concluded. Its own `## Write scope` states the exception, and this line exists so the rule above does not forbid what that skill requires.
+- Report what the row got wrong rather than repairing it. A stale count, a moved line, or a path that no longer resolves goes into the record and into the handback, and the controller decides which of the two carries the correction.
 - Leave the cross-feature call alone. Which rows collide, what merges before what, and whether a row should run at all stay with the controller. `priority.md` shows blockers and file sets and is enough to write a confident merge order off a partial picture, which is the failure this boundary exists to prevent.
 
 ## The channel
@@ -56,47 +73,33 @@ Each item below is something a plan needed and a launch string did not carry.
 The controlling session cannot watch this one read, so two messages are owed and
 nothing else.
 
-- Announce the plan as the file lands, carrying its path and what the task file got wrong. Write no summary of the plan beside it, which is a second account of a document the reader is about to open.
-- Send a block out as a message before it becomes an interactive prompt. A session already waiting on input never reaches the tool round that drains an inbound message, so a relayed answer arrives under the open question and changes nothing.
-- Send nothing on progress. A planner reporting progress rebuilds, on this side of the channel, the poll the announcement retires on the other.
-
-Address the session the launch named. It names a `sessionId` rather than a name,
-so read `canon sessions list --json`, find the row carrying that id, and send to
-the `name` on it. Resolve that name at the moment of sending rather than at
-launch, since a name is derived from what a session turned out to be doing and
-goes stale inside the window a plan takes to write.
-
-Check that name against the agent listing before sending it. A name is not
-unique and the roster carries no field separating two live sessions holding one,
-so send it bare where the listing shows a single row under it and complete it
-with the `[ref]` that listing prints beside each row where it shows more.
-
-Ask the operator when the launch named nobody and a person is there to answer,
-putting the candidate rows through the structured question surface so they pick a
-row rather than recall a name. Never filter that roster by name prefix, which
-returns a sibling or this session itself.
-
-Inferring is the last rung and it discriminates less here than it does for a
-worker. That read takes the sessions holding no feature branch, which separates a
-controller from a worker because a worker holds one, and a planner holds none
-either, so every sibling planner comes back beside the controller. Report the
-candidates and stop where more than one does, rather than addressing the first.
-Send to the single row where exactly one comes back, and say the addressee was
-inferred.
-
-Compose the relay through `canon:session-relay` when this section finds no
-message-sending tool to send through, rather than leaving a resolved addressee
-with nothing to reach it. It runs the same ladder above and carries the
-message already owed, so nothing here is stated twice.
+- Announce the record as the file lands, carrying its path and what the task file got wrong. Write no summary beside it, which is a second account of a document the reader is about to open.
+- Send a block out as a message before it becomes an interactive prompt.
+- Send nothing on progress. A thinking session reporting progress rebuilds, on this side of the channel, the poll the announcement retires on the other.
+
+Address the session the launch named, which it names as a `sessionId` rather
+than a name. `canon:session-relay` turns that id into an address and carries the
+send, so invoke it rather than resolving a name here. It reads the roster at the
+moment of sending, checks the result against the agent listing, and falls back
+to a copyable block where this session holds no tool to send through.
+
+One rung stays here, because it is the rung that differs between roles.
+Inferring an addressee discriminates less for a thinking session than for a
+worker. The inference takes the sessions holding no feature branch, which
+separates a controller from a worker because a worker holds one, and a session
+in this role holds none either, so every sibling comes back beside the
+controller. Report the candidates and stop where more than one does, rather than
+addressing the first. Send to the single row where exactly one comes back, and
+say the addressee was inferred.
 
 ## Refusing is part of the job
 
 - Refuse an instruction the tree contradicts, and carry the evidence with it. Name the commands read and what complying would produce, rather than reporting reluctance.
 - Correct a premise the brief carried when the tree disagrees with it. One trial was told two rows were free of a renamed token and found they carried it as command names rather than path segments, planned all three rows anyway, and put the consequence into a plan question. Correct, continue, and record what the correction changed.
-- Answer a plan question rather than halting on it. Every question carries a `- Suggested:` line the operator accepts or overrules, so a judgment written down is the deliverable. Halt only on what blocks writing the plan at all, and send that out as a message before it becomes a prompt.
+- Answer a plan question rather than halting on it. Every question carries a `- Suggested:` line the operator accepts or overrules, so a judgment written down is the deliverable. Halt only on what blocks writing the record at all, and send that out as a message before it becomes a prompt.
 
 ## Lifetime
 
-- The role runs from the launch to the plan landing, and one plan closes it. A planner handed a second row plans it under the same role and reads the tree again for that row.
-- A reused session pays the context load once and stales differently. Its picture of the tree ages while it works, which is why the in-flight read runs per task, and it accumulates toward a compaction that drops the reasoning behind its earlier plans with nothing reporting it. Cap a reused session rather than letting it run the board.
+- The role runs from the launch to the record landing, and one record closes it. A session handed a second row works it under the same role and reads the tree again for that row.
+- A reused session pays the context load once and stales differently. Its picture of the tree ages while it works, which is why the in-flight read runs per row, and it accumulates toward a compaction that drops the reasoning behind its earlier records with nothing reporting it. Cap a reused session rather than letting it run the board.
 - Treat this body as possibly older than the branch under it. A plugin skill loads from the marketplace cache rather than from the working tree.

package/claude/skills/role-worker/SKILL.md

@@ -89,10 +89,18 @@ with no roster row at all. Those nine were driving through Remote Control, which
 writes no local process record, so a controller working from a phone is exactly
 the case this read answers nothing for.
 
-Compose the relay through `canon:session-relay` when this section finds no
-message-sending tool to send through, rather than leaving a resolved addressee
-with nothing to reach it. It runs the same ladder above and carries the
-message already owed, so nothing here is stated twice.
+Send through `canon:session-relay`. It holds the mechanical half of the send,
+turning the `sessionId` the launch named into an address at the moment of
+sending, checking the result against the agent listing, and falling back to a
+copyable block where this session holds no tool to send through. The message
+owed stays in its own bullet above.
+
+The rungs above restate the resolution the relay also carries. What is a
+worker's own is the last of them, the inference over sessions holding no feature
+branch, which discriminates here because a worker holds one and a controller
+does not. The rest is duplicated deliberately, so this body still reads whole
+for a session that reaches it with the relay unresolved, which is the ordinary
+case in a target that installed governance without the plugin.
 
 ## Refusing is part of the job
 

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

@@ -1,43 +1,70 @@
 ---
 name: session-relay
-description: Why a standalone skill with no firing condition never fired, why the first inline draft repeated the same protocol in two bodies, and why the missing sender identity sat unaddressed through both attempts
+description: Why a standalone skill with no firing condition never fired, why the first inline draft repeated the same protocol in two bodies, why the missing sender identity sat unaddressed through both attempts, and why the two guards that scoped it to a session holding a role and no send tool came off
 ---
 
 # Session relay requirement
 
 ## Gap
 
-Without this skill, `role-worker` and `role-planner` state three and two messages respectively that a session owes its controller, and both assume a tool to send them through. A session holding none has no route to compose or hand off what it owes, and neither body says what to do about that.
+Without this skill, every session that owes another session a message resolves
+the addressee itself. `role-worker` and `role-planner` each state the messages
+owed and each carried the resolution inline, and a session holding neither role
+carried it nowhere, so the mechanical half of the send existed in two copies
+plus however many a roleless caller improvised.
 
-A standalone skill was proposed for the gap and declined the same day. It fired on no condition of its own, since nothing routes a session to a skill matching no request and reaching for no artifact, so a skill built to close the gap never closed it.
+A standalone skill was proposed for the gap and declined the same day. It fired
+on no condition of its own, since nothing routes a session to a skill matching
+no request and reaching for no artifact, so a skill built to close the gap never
+closed it. That history is why the pointer inside each role's
+`## The channel` section still matters: it is a section both bodies read at
+session start rather than one reached by request match alone, and it is what
+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 fix reaching one copy and not the other diverges silently.
+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
+fix reaching one copy and not the other diverges silently.
 
-Neither attempt named who the relay is from. A message an operator relays by hand needs a sender as much as an addressee, and the standalone draft and the inline draft both composed a body and an addressee with no line stating whose turn produced it.
+Neither attempt named who the relay is from. A message an operator relays by
+hand needs a sender as much as an addressee, and the standalone draft and the
+inline draft both composed a body and an addressee with no line stating whose
+turn produced it.
+
+Scoping the skill to a session holding a role and no send tool left two holes
+rather than one. A session holding neither role had no `## The channel` section
+to carry the pointer and was refused outright on arrival. A session that held a
+role and a send tool was refused too, which left the resolution ladder
+duplicated in both role bodies for the ordinary case. Both guards came off
+together, since the mechanics are the same whichever route carries the text.
 
 ## Must
 
-- Fire from inside `role-worker` or `role-planner`'s own `## The channel` section, at the point that section finds no message-sending tool
-- Refuse a caller holding neither role, checked ahead of the tool-availability guard
+- Fire for any session sending to another session, with or without a role and with or without a message-sending tool
 - Read the sender's own name off `canon sessions list --self --json` before composing anything, and degrade to naming itself from the environment when the installed CLI answers `--self` with an unknown option rather than a refusal carrying a reason
-- Resolve the addressee by running the calling role's own ladder rather than a second one
-- Carry the message body the calling role's bullet already names, verbatim
+- Resolve the addressee from a `sessionId` or a branch at the moment of sending, never by a name prefix
+- Check the resolved name against the agent listing, sending it bare under a single row and completing it with the `[ref]` under more than one
+- Send through a message-sending tool where one exists, and compose the copyable block where none does or where the listing carries no row to address
+- State block-before-prompt, since the shipped channel rule carrying it for a session holding neither role reaches only a target that installed governance
+- Carry the message body verbatim from whatever names it
 - Open the composed text with a header naming the sender, the addressee, and what the message is
 - State the header as a default a session may write around, rather than a fixed vocabulary
 
 ## Must not
 
-- Restate the addressee ladder `role-worker` or `role-planner` already states
-- Draft a message body of its own. The text it composes belongs to the calling role's bullet.
-- Fire when a message-sending tool exists
+- Draft a message body of its own. The text it composes belongs to the calling role's bullet or to the dispatch.
+- Decide who the message goes to. The caller names an id or a branch and this body turns it into an address.
+- Restate the last-rung inference `role-worker` and `role-planner` each carry, which differs between them
 
 ## Guards
 
-- The calling session holds neither role: refuse, and state the addressing and timing it owes instead, since the plugin skill it would otherwise defer to reaches a target the moment it merges while a governance rule reaches one only through a separate install. Checked first, since the tool guard read alone let the incident behind this row stop at "you have a tool" without ever learning steps 2 and 3 were unreachable regardless.
-- A message-sending tool is available: refuse, name it, and send through it instead
+- The roster cannot name the sender: report the refusal and its reason in place of a name
+- The resolution returns no row: report it rather than guessing, since the roster and the send channel enumerate different populations in both directions
+- The caller named no addressee at all: defer to the calling role's own last rung, and ask the operator where one is present
 
 ## Out of scope
 
-- The addressee resolution ladder itself, which stays in `role-worker` and `role-planner`
-- The content of each owed message, which stays in the calling role's own bullet
-- Inbound reach: a controller relaying back to a worker or planner holding no tool. The gap this closes is the outbound leg alone, since a controller can already reach either side directly.
+- Which messages are owed and when, which stays in the calling role's own bullet or in the dispatch
+- The last-rung inference, which stays in `role-worker` and `role-planner` because a worker holds a feature branch and a planner does not, so the two discriminate differently
+- Inbound reach as a distinct case. A relay in either direction is one session sending to another, which is what this body now covers.