@erclx/canon 5.41.0 → 5.42.0

package/claude/skills/role-orchestrator/references/orchestrator-handoff.md

@@ -7,45 +7,59 @@ description: Retirement act the wind-down owes the fleet it dispatched, the talk
 
 Settle this act before writing the map. A session retired afterwards is one the map already listed as running, and the map is what the next session reads the fleet off.
 
-The act reaches every session this one dispatched that no verb can decide. `canon worktrees reclaim` refuses a directory on any of seven conditions and reclaims one that trips none, and three of the seven are what this act turns on: a merged pull request, a clean tree, and no live session holding the directory. A running session trips the third whatever its branch did, and retiring it is what clears that one, which is why the retirement runs ahead of the reclaim rather than after it.
+The act reaches every session this one dispatched that no verb can decide. `canon worktrees reclaim` refuses a directory on any of seven conditions, and three are what this act turns on, being a merged pull request, a clean tree, and no live session holding the directory.
 
-Two cases stay undecided even once the session is gone. A worker whose branch has not merged is refused on `no-merged-pull-request`, and a planner is refused as `main-worktree` and handed a null removal route, since it never enters a worktree and registers against the tree it was launched from.
-
-Name the planner as the case always in this set, and scope the act no narrower. A rule covering planners alone leaves the unmerged worker unreached while reading as complete.
+- A running session trips the third whatever its branch did, and retiring it clears that one, so the retirement runs ahead of the reclaim
+- A worker whose branch has not merged stays undecided once gone, refused on `no-merged-pull-request`
+- A planner stays undecided too, refused as `main-worktree` with a null removal route, since it registers against the tree it was launched from
+- Name the planner as the case always in this set, and scope the act no narrower, since a rule for planners alone leaves the unmerged worker unreached
 
 ### Which sessions this session may retire unasked
 
-Retire what this session dispatched. Report a hand-launched session and leave the act to the operator, since the knowledge making the act safe is a delivery this session received and it received nothing from a session it never launched. The `worker-` and `planner-` name prefixes separate the two populations, per `orchestrator-launch.md`.
+Retire what this session dispatched. Report a hand-launched session and leave the act to the operator, since what makes the act safe is a delivery this session received, and it received nothing from a session it never launched.
 
-A talk session is the exception inside the dispatched population. Retire it only on the operator's word, given here or carried in the session's own close message, and never on its delivery, at wind-down or at any other point. Its plan landing or its pull request opening tells this session nothing about whether the conversation is over. Until the word arrives, report it as held open next to the hand-launched read. A talk session is found by the `sessionId` the prior map records or this session's own launch output carries, since the client can rename it and drop the `-talk` suffix `orchestrator-launch.md` gives it.
+- The `worker-` and `planner-` name prefixes separate the two populations, per `orchestrator-launch.md`
+- A capability gap sits beside that knowledge gap. A hand-launched session is often interactive, and `claude rm <id>` has no id to take for one.
 
-A capability gap sits beside the knowledge gap, and it holds even where delivery is somehow known. A hand-launched session is as often interactive as background, and `claude rm <id>` has no id to take for an interactive one at all, so the command cannot reach it whatever this session learned about its delivery.
+### Talk sessions
 
-### Telling a delivered session from a blocked one
+A talk session is the exception inside the dispatched population. Retire it only on the operator's word, given here or carried in the session's own close message, and never on its delivery, at wind-down or any other point.
 
-No status field carries the difference. `status` reads `busy` or `waiting` straight off the client record, and both describe the last turn rather than the work, so `waiting` is the ordinary answer for a session that reported and stopped, which is what a correct delivery looks like. The `statusDwellMs` beside it separates a long idle from a short one and separates nothing else.
+- Its plan landing or its pull request opening tells this session nothing about whether the conversation is over
+- Until the word arrives, report it as held open next to the hand-launched read
+- Find it by the `sessionId` the prior map records or this session's launch output carries, since the client can rename it and drop the `-talk` suffix
 
-The read is the report this session is holding. Retire a session whose delivery arrived here, and leave every other one. A plan sitting at `.canon/plans/feature-<slug>.md` corroborates that report and never stands in for it, because a planner writes the file and can then stop on a follow-up question with the file already landed. Retiring a blocked session destroys the context it held and nothing on disk records what it had read, so the act runs in the keeping direction the reclaim reading already takes: retire what is recorded as delivered, and leave the rest for the operator.
+### Telling a delivered session from a blocked one
 
-### The act, and the order it runs in
+No status field carries the difference. `status` reads `busy` or `waiting` off the client record, both describing the last turn rather than the work, so `waiting` is the ordinary answer for a session that reported and stopped. `statusDwellMs` separates a long idle from a short one and nothing else.
 
-`claude rm <id>` is meant to remove a background session and its worktree together, though its own report is not reliable, so `canon worktrees list` is the reading to trust afterward. It takes one target per call, so a wave costs one call per session. The argument is the id rather than the name, which `claude agents --json` carries beside the name on every row, so a session read off a roster by name is matched to its id there before the call. The name form answers `No job matching`.
+The read is the report this session is holding. Retire a session whose delivery arrived here, and leave every other one for the operator.
 
-The command belongs to the client rather than to this toolkit, so a target running another client performs whatever removal that client offers.
+- A plan at `.canon/plans/feature-<slug>.md` corroborates that report and never stands in for it, since a planner can stop on a question after writing it
+- Retiring a blocked session destroys its context and nothing on disk records what it had read, so the act keeps, as the reclaim reading does
 
-Run `canon worktrees reclaim` after the retirements rather than before them. `held-by-session` is one of the conditions that reading refuses on, so a reclaim taken first refuses the directories the retirement is about to free and reports a board with nothing left to do.
+### The act, and the order it runs in
+
+`claude rm <id>` is meant to remove a background session and its worktree together, though its own report is not reliable, so trust `canon worktrees list` afterward. It takes one target per call, so a wave costs one call per session.
 
-Report the retired sessions as a list, the hand-launched ones under it as a read rather than an act, and what the reclaim removed below both.
+- The argument is the id, which `claude agents --json` carries beside the name on every row, and the name form answers `No job matching`
+- The command belongs to the client, so a target running another client performs whatever removal that client offers
+- Run `canon worktrees reclaim` after the retirements, since it refuses on `held-by-session` and a reclaim taken first finds nothing left to do
+- Report the retired sessions as a list, the hand-launched ones under it as a read rather than an act, and what the reclaim removed below both
 
 ## Write the map
 
-Write the pre-compaction handoff as orchestrator. Invoke `canon:session-map` for the generic half, which is the filename, the three core sections, the write procedure, the drift step and the ref it reads, and the citation rule. Everything in this section is the extension this role adds over that core, and none of it belongs to a session holding no delegated authority.
+Write the pre-compaction handoff as orchestrator. Invoke `canon:session-map` for the generic half, being the filename, the three core sections, the write procedure, the drift step and the ref it reads, and the citation rule. Everything in this section is the extension this role adds.
 
-Settle all three steps below before the door writes, so one write carries the core and the extension together. The door reports the map as written and knows nothing of this role, so its success line ends the generic half rather than this runbook, and a session that stops there ships a map missing everything this section adds to it.
+Settle all three steps below before the door writes, so one write carries the core and the extension together. The door's success line ends the generic half rather than this runbook, so a session stopping there ships a map missing everything this section adds.
 
-1. Add `## Decisions taken under delegated authority` directly after `## State`, holding each decision and why it went that way, so nobody re-proposes it. It sits there rather than after the core because a decision is read against the state it was taken in.
-2. Add `## Talk sessions held open` directly after that section, with one line per open talk session giving its name, its `sessionId`, and its row, or `None.` when there are none. The next session reads it to know which sessions it must not retire on a delivery.
-3. Close the file with the block below, resolving `${CLAUDE_SKILL_DIR}/references/orchestrator-resume.md` and `${CLAUDE_SKILL_DIR}/references/orchestrator-poll.md` to absolute paths as you write it and pasting each in place of `<RESUME_RUNBOOK>` and `<POLL_RUNBOOK>`:
+1. Add `## Decisions taken under delegated authority` directly after `## State`, holding each decision and why it went that way, so nobody re-proposes it.
+   - It sits there because a decision is read against the state it was taken in
+2. Add `## Talk sessions held open` directly after that, one line per open talk session giving its name, its `sessionId`, and its row, or `None.`.
+   - The next session reads it to know which sessions it must not retire on a delivery
+3. Close the file with the block below, resolving each runbook path to an absolute one as you write it.
+   - Paste `${CLAUDE_SKILL_DIR}/references/orchestrator-resume.md` resolved in place of `<RESUME_RUNBOOK>`
+   - Paste `${CLAUDE_SKILL_DIR}/references/orchestrator-poll.md` resolved in place of `<POLL_RUNBOOK>`
 
 ```markdown
 Resume by loading the orchestrator skill and asking it to resume after a compaction. This repository spells that `/canon:role-orchestrator` followed by the request. Following <RESUME_RUNBOOK> reaches the same place with no skill loaded at all.
@@ -53,14 +67,22 @@ Resume by loading the orchestrator skill and asking it to resume after a compact
 That resume reads the board and stops. It restarts nothing, so the review poll is a second thing owed here, and <POLL_RUNBOOK> holds the prompt and the condition. Do not reach for `session-resume`, which reads tracked work and reports the newest map without restarting this loop.
 ```
 
-The delegated-authority section is the orchestrator's alone because a worker holds no delegation to have exercised, and a section a session cannot fill teaches its reader to skip the file. The closing block is the orchestrator's for the same reason from the other direction: it restarts a review poll no other role runs.
+### Why these sections are the orchestrator's
+
+The delegated-authority section is the orchestrator's alone because a worker holds no delegation to have exercised, and a section a session cannot fill teaches its reader to skip the file. The closing block is the orchestrator's because it restarts a review poll no other role runs.
+
+- The substitution sits in step 3 because that step ends the write
+- The variable expands while this runbook renders, never when the handoff is read back
+- A path left unresolved reaches a session holding no skill as a string matching nothing. `orchestrator-poll.md` resolves its script at the same point.
 
-The substitution belongs in step 3 because that step ends the write. A reader who treats the list as finished elsewhere ships the literal placeholders, and the variable expands while this runbook renders rather than in the turn that reads the handoff back, so a path left unresolved reaches a session holding no skill as a string matching nothing. `orchestrator-poll.md` resolves its script at the same point and for the same reason.
+### Why the block appears twice
 
-That block sits in this runbook and again in the file this runbook writes, which is the fix rather than a copy for a later pass to collapse. A session has to already be holding this runbook to read it, and a compaction that took the skill body took the routing to it too, so the session that most needs the resume is the one that can no longer find it. The map survives that, so it carries the invocation itself. Each of the two reaches a reader the other cannot.
+That block sits here and again in the file this runbook writes, which is the fix rather than a copy to collapse. A compaction that took the skill body took the routing to this runbook too, so the map carries the invocation itself, and each copy reaches a reader the other cannot.
 
-The requirement is a resume request to the orchestrator skill with that skill loaded first. The command the block carries is this repository's spelling rather than the only one, since the skill ships to every target holding the plugin and each runs whatever client it runs. The poll restart is named beside it because the resume performs none.
+- The requirement is a resume request to the orchestrator skill with it loaded first, and the command shown is this repository's spelling, not the only one
+- The poll restart is named beside it because the resume performs none
+- This runbook varies the door rather than replacing it, stating only what differs, so the two cannot disagree
 
-This runbook varies the door rather than replacing it, which is why the door is invoked first and this runbook states only what differs. The generic half moved out whole, the drift step and its ref recovery with it, so nothing here restates a step the door already carries and the two cannot disagree.
+## Where a lesson goes
 
-This session commits nothing, and the orchestrator's boundaries forbid writing a context entry from it. A domain fact belongs to the task that owns the surface and goes in that task's Findings, and so does a lesson about how to work, since nothing reads a lesson left only in the map once the session after it is past it.
+This session commits nothing, and the orchestrator's boundaries forbid writing a context entry from it. A domain fact goes in the Findings of the task owning the surface, and so does a lesson about how to work, since nothing reads a lesson left only in the map once the next session is past it.

package/claude/skills/role-orchestrator/references/orchestrator-inbound.md

@@ -7,17 +7,16 @@ description: What each message from another session costs the orchestrator's con
 
 Part of `role-orchestrator`'s `## Parallelism`. The session reads this file before widening a wave, since review attention is what binds the track count and this is what it costs.
 
-Inbound turns are the third input to that judgment. Claude Code delivers a
-message from another session as a new turn whenever this one sits idle, and the
-turn carries the whole accumulated context rather than the few lines the worker
-sent, so one handback from a wide wave costs more than the same handback from a
-narrow one. A recurring review poll bills that window again on every interval it
-fires. Weigh the spend before widening, since it lands on this session's context
-and never on the worker's.
+Inbound turns are the third input to that judgment. Claude Code delivers a message from another session as a new turn whenever this one sits idle, and the turn carries the whole accumulated context rather than the few lines the worker sent.
 
-`crossSessionInbound` is the control, on an `accept`, `hold`, `refuse` ladder,
-and it is recorded here as deliberately not pulled. `hold` and `refuse` are the
-two values that bound the cost, and both break the handback this loop runs on,
-since a held message reaches nobody until a later `accept` applies and a refused
-one is dropped outright. `accept` bounds nothing. Read the ladder before turning
-concurrency up rather than after, and leave it unset.
+- One handback from a wide wave therefore costs more than the same handback from a narrow one
+- A recurring review poll bills that window again on every interval it fires
+- Weigh the spend before widening, since it lands on this session's context and never on the worker's
+
+## The control left unset
+
+`crossSessionInbound` is the control, on an `accept`, `hold`, `refuse` ladder, and it is deliberately not pulled. Read the ladder before turning concurrency up rather than after, and leave it unset.
+
+- `hold` and `refuse` are the two values that bound the cost, and both break the handback this loop runs on
+- A held message reaches nobody until a later `accept` applies, and a refused one is dropped outright
+- `accept` bounds nothing

package/claude/skills/role-orchestrator/references/orchestrator-launch.md

@@ -21,42 +21,62 @@ claude --bg --model <model> -n "worker-<project>-<slug>" "/canon:auto-ship <plan
 Your controller is the session whose sessionId is <dispatcher-id>. Resolve its current name from that id through canon sessions list --json, which carries sessionId per row, at the moment you send, and never resolve an addressee by name prefix. Message it when the pull request opens, carrying the number, the branch, the head sha, the CI state, and every point you departed from the plan on, and message it again if you stop on a question."
 ```
 
-`--bg, --background` starts the session as a background agent and returns immediately, `-n, --name` sets the display name that tells a self-dispatched worker from an operator's own launch in `canon sessions list`, and `--model` overrides the inheritance `## Pick the model` states. Pass `-n` on every dispatch rather than letting the client derive one. A launch that omits it leaves the session named for a fragment of its own identifier, which is both its address on the send channel and the whole of what the operator sees for it in agent view.
+`--bg, --background` starts the session as a background agent and returns immediately, and `--model` overrides the inheritance `## Pick the model` states. `-n, --name` sets the display name that tells a self-dispatched worker from an operator's own launch in `canon sessions list`.
 
-The prefix reads `worker-` because that is the role it marks. A prefix naming a role the session does not hold sends a worker filtering the roster for that string to a sibling or itself on every row. Nothing matches the prefix programmatically, which keeps a rename down to three strings.
+- Pass `-n` on every dispatch, since a launch omitting it names the session for a fragment of its identifier, its send address and all the operator sees
+- The prefix reads `worker-` because that is the role it marks, since a prefix naming another role sends a worker filtering the roster to a sibling or itself
+- Nothing matches the prefix programmatically, which keeps a rename down to three strings
 
-`<project>` is the basename of the main worktree root, not of wherever the dispatcher happens to be running. Resolve the main root first, the way `session-worktree` Step 1 does, since a bare `git rev-parse --show-toplevel` inside a linked worktree returns the worktree path rather than the project's. `claude agents` lists every session on the machine with no path column and no per-project filter, so `<project>` in the name is the only thing left telling two fleets apart.
+### The project and the controller id
 
-Read `<dispatcher-id>` with `canon sessions list --self --json` and interpolate the `sessionId` that row carries. Carry the id rather than the name. A name is derived from whatever the session turned out to be doing and can be renamed minutes after launch, inside the window a worker announces its pull request in, so a name written into the prompt is aimed at a send that happens after it goes stale.
+`<project>` is the basename of the main worktree root, resolved the way `session-worktree` Step 1 does, since `git rev-parse --show-toplevel` inside a linked worktree returns the worktree path. `claude agents` lists every session on the machine with no path column, so `<project>` is all that tells two fleets apart.
 
-Where the installed CLI answers `--self` with an unknown option, that flag is newer than the release the target holds. Read the `sessionId` from the record the client writes for this session under its configuration directory, and say which route answered so the reader knows whether the id was read or inferred.
+Read `<dispatcher-id>` with `canon sessions list --self --json` and interpolate the row's `sessionId`. Carry the id rather than the name, since a name can be renamed minutes after launch, inside the window a worker announces its pull request in.
 
-The worker resolves that id back to a name through `canon sessions list --json`, which carries `sessionId` per row, rather than through the agent listing, which prints a name and a short ref and no id at all. A worker reaching for the listing first therefore finds no lookup and can conclude there is none. That failure is silent in both directions: the session has nothing useful to do with the message it owes and goes idle holding it, and nothing on this side reports the quiet, so the loss surfaces as a missing worktree or a pull request that never opens rather than as anything watching for it.
+- Where the installed CLI answers `--self` with an unknown option, read the `sessionId` from the record the client writes under its configuration directory
+- Say which route answered, so the reader knows whether the id was read or inferred
 
-The template carries no worktree call. `auto-ship` Step 0 invokes `canon:role-worker` and then `canon:session-worktree` itself, and neither carries the flag, so both are reachable through the `Skill` tool regardless of where a call to them would sit in a prompt. The autoship call carries `<plan>`, the same file `orchestrator-dispatch.md` read to derive the branch, so its Step 1 takes it as the caller-supplied plan rather than re-deriving one from the slug the worker's branch happens to carry.
+### How the worker resolves the id
 
-The template names no branch, and it does not need to. `auto-ship` Step 0 runs `canon tasks plan-branch <plan>` on the same file the candidate was derived from, and hands the `<type>/<slug>` it reports to `session-worktree` as its tier 0 argument, so the two sides agree by calling one derivation rather than by a string copied between them. What still travels on judgment is the fallback: a worker whose installed binary carries no `plan-branch` derives by prose.
+The worker resolves that id back to a name through `canon sessions list --json`, which carries `sessionId` per row. The agent listing prints a name and a short ref and no id, so a worker reaching for it first finds no lookup and can conclude there is none.
+
+That failure is silent in both directions. The worker goes idle holding the message it owes, and nothing on this side reports the quiet, so the loss surfaces as a missing worktree or a pull request that never opens.
+
+### No worktree call and no branch
+
+The template carries no worktree call. `auto-ship` Step 0 invokes `canon:role-worker` and then `canon:session-worktree` itself, and neither carries the flag, so both are reachable through the `Skill` tool wherever a call sits in a prompt.
+
+- The autoship call carries `<plan>`, the file `orchestrator-dispatch.md` read to derive the branch, so Step 1 takes it as the caller-supplied plan
+- Step 0 runs `canon tasks plan-branch <plan>` on that file and hands the `<type>/<slug>` to `session-worktree` as its tier 0 argument
+- The two sides agree by calling one derivation rather than copying a string, and only a binary lacking `plan-branch` derives by prose
 
 ### Position zero
 
-Put a command whose skill carries `disable-model-invocation: true` at position zero of the launch prompt, followed by a space and its argument, with nothing before it. The client expands a slash command there as a user invocation, which is the route the flag permits. Anything reaching the session as prose falls to the model, which invokes it through the `Skill` tool, and that route answers a flagged skill inconsistently. `auto-ship` carries the flag. A comma or other punctuation glued to the command name at position zero has failed to expand, so treat the space as part of the rule until a dispatch shows otherwise.
+Put a command whose skill carries `disable-model-invocation: true` at position zero of the launch prompt, followed by a space and its argument, with nothing before it. The client expands a slash command there as a user invocation, which is the route the flag permits.
 
-Never depend on the `Skill` tool route for a flagged skill. A refusal there tells the session not to replicate the workflow by other means, so a refused worker stops with a clean worktree, which is the correct outcome. The refusal is sticky inside a session, so recovery belongs to whoever writes the next prompt: re-dispatch onto the same branch with the build template above.
+- Anything reaching the session as prose falls to the model, which invokes it through the `Skill` tool, a route that answers a flagged skill inconsistently
+- `auto-ship` carries the flag
+- A comma or other punctuation glued to the command name at position zero has failed to expand, so treat the space as part of the rule
 
-The review-address and planning shapes below, and the reviewer shapes in `orchestrator-reviewer-launch.md`, depend on no expansion at all. None of `role-worker`, `review-address`, `role-planner`, `plan-feature`, `role-reviewer`, or `review-pr` carries the flag, so all three correctly keep their leading word regardless of the delimiter or the position it sits at.
+Never depend on the `Skill` tool route for a flagged skill. A refusal there tells the session not to replicate the workflow by other means, so a refused worker stops with a clean worktree, the correct outcome. The refusal is sticky inside a session, so recover by re-dispatching onto the same branch with the build template above.
 
-The same rule reaches a human relay. Hand an operator one message carrying one command at position zero, since two chained blocks pasted as separate messages can land as one, where everything after the first command's name reads as that command's argument and the second never fires.
+### Shapes needing no expansion
+
+The review-address and planning shapes below, and the reviewer shapes in `orchestrator-reviewer-launch.md`, depend on no expansion. None of `role-worker`, `review-address`, `role-planner`, `plan-feature`, `role-reviewer`, or `review-pr` carries the flag, so each keeps its leading word whatever the delimiter or position.
+
+The same rule reaches a human relay. Hand an operator one message carrying one command at position zero, since two blocks pasted as separate messages can land as one, where the second never fires.
 
 ### What the brief may carry
 
 The prompt carries pointers and standing context, and stops there. The branch and the plan stay arguments, because a skill resolves an argument through a documented ladder and reads no prose at all. What the prose reaches is the worker's judgment, so it holds only what a session has to weigh:
 
 - Name the addressee and what it is owed, which the two message clauses above already do.
-- Carry standing context this session holds that a cold one cannot derive, such as a constraint settled in conversation that never reached the plan.
-- Leave out anything scope-shaped. A file list, a naming convention, or a check to run belongs in the plan, where the review reads it back against the diff. Scope that arrives as prose is scope nothing verifies afterward.
-- On a reviewer launch, carry the sibling pull requests in flight, the files each shares with this one, the merge order, and a constraint settled in conversation, all as facts. Leave out this session's own read of the change, the author's argument for it, and any list of what to look for, since the first two cost the independence the dispatch pays for and the third is `review-craft`'s.
+- Carry standing context a cold session cannot derive, such as a constraint settled in conversation that never reached the plan
+- Leave out anything scope-shaped, such as a file list, a naming convention, or a check, which belongs in the plan the review reads back against the diff
+- On a reviewer launch, carry the sibling pull requests in flight, the files each shares with this one, the merge order, and a settled constraint, all as facts
+- Leave out this session's read of the change and the author's argument, which cost the dispatch its independence, and any list of what to look for, which is `review-craft`'s
 
-Report the dispatch as loudly as the human-launch line it replaces: name the branch, the model, the task, and the session name, so a person reading the transcript can follow what fired without watching it happen.
+Report the dispatch as loudly as the human-launch line it replaces, naming the branch, the model, the task, and the session name, so a person reading the transcript can follow what fired without watching it happen.
 
 ## Dispatch to a cloud worker
 
@@ -64,45 +84,59 @@ Read `${CLAUDE_SKILL_DIR}/references/orchestrator-cloud-launch.md` when `orchest
 
 ## Dispatch to address a review
 
-`review-address` is a single pass, not a chain, so a launch naming it alone reaches no `role-worker` and takes no role, which owes no message either. Reach the role directly on this launch instead of wrapping a second chain around one skill that has none of its own.
+`review-address` is a single pass, not a chain, so a launch naming it alone reaches no `role-worker` and owes no message. Reach the role directly on this launch instead of wrapping a second chain around one skill.
 
-The branch already exists here, opened by whatever built it, so this shape skips the plan-derived name the build shape resolves above. Take `<branch>` off the pull request's own head ref. Enter the worktree the original build left on disk, `.claude/worktrees/<slug>/`, with `EnterWorktree`'s `path` form when it is still there, or `git worktree add .claude/worktrees/<slug>/ <branch>` when it was cleaned up, so `<slug>` is that directory name either way.
+The branch already exists, so this shape skips the plan-derived name and takes `<branch>` off the pull request's own head ref. `<slug>` is the directory name of the original build's worktree, `.claude/worktrees/<slug>/`.
 
-`EnterWorktree` refuses that path in the ordinary case, because the original build session stays registered against its own worktree after going idle and holds a harness-level lock the roster does not report. Work in the folder directly with `Bash`, `Read`, and `Edit` instead of retrying the tool.
+- Enter it with `EnterWorktree`'s `path` form when it is still there, or `git worktree add .claude/worktrees/<slug>/ <branch>` when it was cleaned up
+- `EnterWorktree` refuses that path in the ordinary case, since the idle build session holds a harness-level lock the roster does not report
+- Work in the folder directly with `Bash`, `Read`, and `Edit` instead of retrying the tool
 
 ```bash
 claude --bg --model <model> -n "worker-<project>-<slug>" "Enter the worktree for <branch> at .claude/worktrees/<slug>/, creating it from that branch if the folder is gone. Run /canon:role-worker, then /canon:review-address. Your controller is the session whose sessionId is <dispatcher-id>, and your reviewer is the session whose sessionId is <reviewer-id>. Resolve each current name from its id through canon sessions list --json, which carries sessionId per row, at the moment you send, and never resolve an addressee by name prefix. Message the reviewer when the address pass finishes, asking it to re-review and carrying what was addressed and the PR's CI state, and send that to the controller instead when the reviewer's id resolves to no live session. Message the controller if you stop on a question."
 ```
 
-`<dispatcher-id>`, `<model>`, and `<project>` resolve the same way the build shape resolves them above. `<reviewer-id>` is the sessionId the reviewer's own message carried, so a worker launched fresh answers the reviewer directly. Where no local reviewer is live, which a cloud reviewer always leaves, drop the reviewer clause and send the finished message to the controller, which launches the re-review itself.
-
-Take this shape wherever a review needs answering and no live session already holds the branch. Where one does, message it to run `review-address` instead, per the loop's own step 6, since a session already there needs no second one dispatched onto the same branch.
+`<dispatcher-id>`, `<model>`, and `<project>` resolve the same way the build shape resolves them above. `<reviewer-id>` is the sessionId the reviewer's own message carried, so a worker launched fresh answers the reviewer directly.
 
-That check is blind to a session working through the direct-path fallback above, since a session that never runs `EnterWorktree` never moves its registered branch off `main`, so `canon sessions list --branch` reports nothing holding it. A dispatch landing on a branch worked that way collides with nothing the check can see.
+- Where no local reviewer is live, as a cloud reviewer always leaves, drop the reviewer clause and send the finished message to the controller
+- Take this shape wherever a review needs answering and no live session holds the branch. Where one does, message it per the loop's step 6.
+- That check is blind to a session working through the direct-path fallback, since it never moves its registered branch off `main`
+- `canon sessions list --branch` then reports nothing holding the branch, so a dispatch landing there collides with nothing the check can see
 
 ## Dispatch to plan a row
 
-`plan-feature` is a procedure rather than a role, so a launch naming it alone reaches no `role-planner` and takes no role, which owes no message either. Reach the role directly on this launch, the way the build shape above reaches `role-worker`, rather than retyping the role's obligations as prose into each launch.
+`plan-feature` is a procedure rather than a role, so a launch naming it alone reaches no `role-planner` and owes no message. Reach the role directly, the way the build shape reaches `role-worker`, rather than retyping its obligations as prose.
 
-No branch and no worktree exist here and none is created. A planner writes one gitignored file at the main worktree root, so this shape names the row's task file rather than a branch and opens with the role instead of a worktree call. That write meets the isolation guard the same way a linked worktree's main-root write does, with no worktree here to redirect it to, so `role-planner` sends it as a `Bash` heredoc rather than through `Write`.
+No branch and no worktree exist here and none is created. A planner writes one gitignored file at the main worktree root, so this shape names the row's task file and opens with the role.
+
+- That write meets the isolation guard as a linked worktree's main-root write does, with no worktree to redirect it to
+- `role-planner` therefore sends it as a `Bash` heredoc rather than through `Write`
 
 ```bash
 claude --bg --model <model> -n "planner-<project>-<slug>" "Run /canon:role-planner, then /canon:plan-feature <task>. Your controller is the session whose sessionId is <dispatcher-id>. Resolve its current name from that id through canon sessions list --json, which carries sessionId per row, at the moment you send, and never resolve an addressee by name prefix. Message it when the plan lands, carrying the path and what the task file got wrong, and message it again if you stop on a question."
 ```
 
-`<task>` is the row's task file path and `<slug>` the slug its plan will take, resolved off the row the way the build shape resolves one off a plan. `<dispatcher-id>`, `<model>`, and `<project>` resolve the same way they do above. The prefix reads `planner-` for the reason the worker's reads `worker-`, which is that it marks the role of the session it names rather than the one that launched it.
+`<task>` is the row's task file path and `<slug>` the slug its plan will take, resolved off the row. `<dispatcher-id>`, `<model>`, and `<project>` resolve as above, and the prefix reads `planner-` because it marks the role of the session it names.
 
-None of the three checks in `orchestrator-dispatch.md` binds this shape. The branch check has no candidate to read, and the conflict check has nothing to compare, since a planner writes one file no track in flight can hold. The plan-answer gate reaches no plan at all, because the planner is dispatched to write the file a build would later read, so running it here would refuse every planning dispatch over a plan nobody has written yet.
+### Which checks bind
 
-What a planning dispatch owes instead is the reverse reading, because the plan it produces carries a constraint per track in flight and a row planned during a wave is planned against a tree that wave is changing. `role-planner` composes the session roster with the pull request list for that read rather than reading pull requests alone, which is why the brief carries no branch list for it: the planner takes this reading itself either way.
+None of the three checks in `orchestrator-dispatch.md` binds this shape.
 
-One row per dispatch. A session reused across a batch pays the context load once and ages its picture of the tree while it works, which is what puts the in-flight read on the task rather than on the batch, and one that compacts mid-batch loses the reasoning behind its earlier plans with nothing reporting it. Cap a reused session where the saving is worth it and say what the cap was.
+- The branch check has no candidate to read
+- The conflict check has nothing to compare, since a planner writes one file no track in flight can hold
+- The plan-answer gate reaches no plan, since the planner writes the file a build later reads, so running it would refuse every planning dispatch
 
-## Dispatch a talk session
+What a planning dispatch owes instead is the reverse reading, since a row planned during a wave is planned against a tree that wave is changing. `role-planner` composes the session roster with the pull request list itself, which is why the brief carries no branch list.
+
+### One row per dispatch
 
-A planner or worker the operator will talk with takes the same launch as its cold shape above, with two changes. It carries a `-talk` suffix on its name, and its brief gains one sentence. A cold session works alone and reports back, and a talk session stays open after its plan or pull request lands so the operator can keep shaping the row with it.
+A session reused across a batch pays the context load once and ages its picture of the tree while it works, which is why the in-flight read sits on the task rather than the batch. One that compacts mid-batch loses the reasoning behind its earlier plans with nothing reporting it.
+
+Cap a reused session where the saving is worth it and say what the cap was.
+
+## Dispatch a talk session
 
-Take the planning shape or the build shape and change those two things:
+A planner or worker the operator will talk with takes the same launch as its cold shape above, with a `-talk` suffix on its name and one sentence added to its brief. A cold session works alone and reports back, and a talk session stays open after its plan or pull request lands so the operator can keep shaping the row.
 
 ```bash
 claude --bg --model <model> -n "planner-<project>-<slug>-talk" "Run /canon:role-planner, then /canon:plan-feature <task>. This is a talk session: the operator will talk with you here, so run your role's talk clause, and message your controller when the operator ends the conversation. Your controller is the session whose sessionId is <dispatcher-id>. ..."
@@ -112,13 +146,15 @@ This is a talk session: the operator will talk with you here, so run your role's
 
 The ellipsis stands for the rest of the cold template's message clauses, unchanged. The build variant keeps `/canon:auto-ship <plan>` at position zero with nothing before it, per the rule above.
 
-Keep the role prefix and add the suffix rather than inventing a prefix. `orchestrator-handoff.md` separates dispatched sessions from hand-launched ones by `worker-` and `planner-`, so a new prefix would read as a hand launch and fall outside the retirement act.
+- Keep the role prefix and add the suffix, since `orchestrator-handoff.md` separates dispatched sessions by `worker-` and `planner-` and a new prefix reads as a hand launch
+- A talk session is retired only on the operator's word, stated once in `orchestrator-handoff.md`, so do not restate it in a launch report
+- Reviewers get no talk shape, since a reviewer's pass holds no operator dialogue
 
-Read the session's `sessionId` off the launch output and carry it in this session's own context, then write it into the map's `## Talk sessions held open` section at the next handoff. The map exists only once the handoff writes it, so the launches this session made, read from its own context with the prior map, are the source the first wind-down reads talk sessions from. The client can rename a session after launch and drop the suffix, so the id is the durable marker and the suffix is only for display.
+### Recording the talk session
 
-A talk session is retired only on the operator's word, which `orchestrator-handoff.md` states under the retirement act. That runbook is the one place the rule lives, so do not restate it in a launch report.
+Read the session's `sessionId` off the launch output, carry it in this session's own context, and write it into the map's `## Talk sessions held open` at the next handoff. The client can rename a session and drop the suffix, so the id is the durable marker and the suffix is only for display.
 
-Reviewers get no talk shape, since a reviewer's pass holds no operator dialogue.
+The map exists only once the handoff writes it, so this session's own launches, read with the prior map, are what the first wind-down reads talk sessions from.
 
 ## Dispatch a reviewer
 

package/claude/skills/role-orchestrator/references/orchestrator-output.md

@@ -37,11 +37,16 @@ Next: <the single most useful action>
 
 Omit any section with nothing in it. Recommend a handoff only for a plan the conflict check in `orchestrator-dispatch.md` holds behind no track already in flight, and name any paths it shares with one.
 
-`In flight` covers the state between the other two, which lasts ten to thirty minutes and is most of what an operator sees once this session dispatches its own workers. Read the progress figures off each worker's worktree rather than from the worker, since a busy status says a session is alive and nothing about whether it is moving, and name the model because a dispatcher now picks one per row.
+- The block opens on the board rather than a version, since no committed file states one and a version line would restate the rows, dated by nothing
+- Leave a plan out of `Ready to build` once a row in flight names it, since its file stays in `.canon/plans/` for the whole build
+- Listing it would recommend handing off work underway, and the conflict check withdraws that only for a reader who knows what is running
 
-Leave a plan out of `Ready to build` once a row in flight names it. The plan file stays in `.canon/plans/` for the whole build, so listing it there recommends handing off work already underway, and the conflict check withdraws the recommendation only for a reader who already knows what is running.
+### In flight
 
-The block opens on the board rather than on a version, because no committed file states one, and a version line would restate what a reader can already see on the rows, dated by nothing.
+`In flight` covers the state between the other two, which lasts ten to thirty minutes and is most of what an operator sees once this session dispatches its own workers.
+
+- Read the progress figures off each worker's worktree, since a busy status says a session is alive and nothing about whether it is moving
+- Name the model, because a dispatcher now picks one per row
 
 ## Every later turn
 
@@ -56,6 +61,9 @@ Decisions:
 Next: <the single most useful action>
 ```
 
-Keep the detail below the block and keep it skippable. A decision reached at the bottom of three paragraphs has been buried, which is the failure this shape exists to prevent. Reuse the vocabulary above rather than inventing a second one, and keep a file set on the row claiming it so the reader can check a hold or a shared-path claim instead of taking it.
+Keep the detail below the block and keep it skippable. A decision reached at the bottom of three paragraphs has been buried, which is the failure this shape exists to prevent.
+
+- Reuse the vocabulary above rather than inventing a second one
+- Keep a file set on the row claiming it, so the reader can check a hold or a shared-path claim instead of taking it
 
 Write no shape for a correction. A correction is a sentence, and a format for admitting error invites ceremony where plainness is the whole value.

package/claude/skills/role-orchestrator/references/orchestrator-parked.md

@@ -5,69 +5,109 @@ description: Re-testing every parked blocker against the current tree, the two t
 
 Re-test every parked row as orchestrator. A blocker cell is a measurement taken the day the row was parked and nothing re-takes it, so a row can wait on a condition that stopped holding weeks earlier with no surface reporting the gap.
 
-Two triggers start this pass. `orchestrator-sweep.md` ends by sending the rows `canon tasks validate` listed as untested here, because a merge changes the tree under every parked row at once rather than under the rows naming it. The other is an idle session: nothing merged, workers are building, no pull request is waiting on a first pass, and the board is not moving.
+## Triggers
 
-The two differ in scope rather than in procedure. A merge sends the untested rows, since the validator already re-took the two kinds it can settle. An idle session walks every parked row, because no event narrowed which of them to look at, and it alone also walks `backlog.md`: a merge names no backlog row as untested, since `canon tasks validate` re-tests blocker cells and a backlog row carries none.
+Two triggers start this pass, and they differ in scope rather than in procedure.
 
-Neither trigger is a scheduler. `orchestrator-poll.md` owns the one recurring trigger this skill has, and a second loop firing into a static board is the always-on failure that file already warns about.
+| Trigger                                                                                           | Scope                                                                                                                                |
+| ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `orchestrator-sweep.md` sends the rows `canon tasks validate` listed untested                     | Those rows alone, since a merge changes the tree under every parked row and the validator already re-took the two kinds it settles   |
+| An idle session, with nothing merged, workers building, and no pull request awaiting a first pass | Every parked row, since no event narrowed them, plus every `backlog.md` row, which carries no blocker cell for the validator to name |
 
-The sweep's own question stays distinct from this one. It asks which parked row to promote next, taking the blocker cell as read, and this pass asks whether that cell is still true. A session collapsing them runs whichever it remembers and re-tests nothing.
+- Neither trigger is a scheduler. `orchestrator-poll.md` owns the one recurring trigger, and a second loop firing into a static board is the always-on failure it warns about.
+- The sweep asks which parked row to promote next, taking the blocker cell as read, and this pass asks whether the cell is still true
+- A session collapsing the two runs whichever it remembers and re-tests nothing
 
 ## Scope
 
-Every row under `## Up next` and `## Needs a plan` in `.canon/tasks/priority.md`. A `## Run now` row carries no blocker by definition, so the pass skips it. On the idle trigger, also every row in `.canon/tasks/backlog.md` when the file exists, per the trigger split above. Resolve the board, the backlog, and each task file at the main worktree root, the way `session-worktree` does.
+Every row under `## Up next` and `## Needs a plan` in `.canon/tasks/priority.md`, plus every row in `.canon/tasks/backlog.md` on the idle trigger when the file exists. A `## Run now` row carries no blocker, so the pass skips it. Resolve the board, the backlog, and each task file at the main worktree root, the way `session-worktree` does.
 
-Take the board rows in board order and finish one before opening the next. Clearing a row changes what the next row holds behind, so a pass that measures every row first and writes afterwards writes against a board it has already invalidated. On the idle trigger, walk the backlog after the board, in the file's own filename order, since `${CLAUDE_SKILL_DIR}/../task-board/references/board.md` fixes that file as unordered and nothing about a row's position there means anything to preserve mid-pass.
+- Take the board rows in board order and finish one before opening the next, since clearing a row changes what the next row holds behind
+- A pass that measures every row first and writes afterwards writes against a board it has already invalidated
+- On the idle trigger, walk the backlog after the board in filename order, since `${CLAUDE_SKILL_DIR}/../task-board/references/board.md` fixes it as unordered
 
 ## Re-testing a row
 
 The blocker cell states what the row waits on, and each kind is tested differently. `canon tasks validate` already re-takes the first two and reports the rest as untested, so run it first and re-take by hand only what it names.
 
-- A hold behind a track in flight: the validator tests the file the cell cites against the Touches column of every `## Run now` row. A track that merged since the row was parked is no longer in flight, whatever the sets still share. Re-test the cell under the conflict check in `orchestrator-dispatch.md` too, since a row parked on a shared file alone holds on nothing and moves up. A cell naming the file in prose rather than in backticks cites nothing, so write the hold the way the board format spells it and the check picks the row up on the next run.
-- A dependency on another task: the validator opens the task a link in the cell names. One whose outcomes are all `[x]`, one already archived, or one already declined, holds nothing. A cell naming the task in prose resolves to no file, so open it by hand and rewrite the cell as a link.
+### A hold behind a track in flight
+
+The validator tests the file the cell cites against the Touches column of every `## Run now` row. A track that merged since the row was parked is no longer in flight, whatever the sets still share.
+
+- Re-test the cell under the conflict check in `orchestrator-dispatch.md` too, since a row parked on a shared file alone holds on nothing and moves up
+- A cell naming the file in prose rather than backticks cites nothing, so rewrite the hold in the board's spelling and the next run picks it up
+
+### A dependency on another task
+
+The validator opens the task a link in the cell names. One whose outcomes are all `[x]`, one already archived, or one already declined holds nothing. A cell naming the task in prose resolves to no file, so open it by hand and rewrite the cell as a link.
+
+### The other three kinds
+
+These the validator reports untested, and each takes its own handling.
+
 - A condition about the tree, such as a count of some shape or the presence of a construct: measure it again, per Two ways a re-test goes wrong below.
 - Waiting on a plan: nothing external holds the row, so the pass writes the plan rather than testing anything. See The plan half below.
-- Waiting on an operator action, such as a run that happens from a shell: record it as untestable this pass and name what the operator has to do. A session cannot clear it, and re-measuring it every pass is waste.
+- Waiting on an operator action, such as a run from a shell: record it as untestable this pass and name what the operator has to do, since re-measuring it is waste
 
-Every measurement this pass takes is a blocker re-test on a row already filed, and it decides whether that row can start rather than how big it is. Sizing a row is the filing boundary `role-orchestrator` states under `## Boundaries`, which leaves the extent and the cause to whoever plans the row.
+### Writing the result
 
-Write the result into the row. A re-test reported in chat is lost at the next compaction and the next pass measures the same thing again. Rewrite a blocker cell whose test no longer holds, move the row to the group its new state puts it in, and record the measurement in that task's `## Findings` as a line labeled with this session and the date it was taken, per `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`. `### Writing the board` in `role-orchestrator` owns the method, and `canon tasks validate` runs once the board is rewritten and before the report.
+Every measurement this pass takes decides whether a row can start rather than how big it is. Sizing a row is the filing boundary `role-orchestrator` states under `## Boundaries`, which leaves the extent and the cause to whoever plans it.
+
+Write the result into the row, since a re-test reported in chat is lost at the next compaction and measured again.
+
+- Rewrite a blocker cell whose test no longer holds, and move the row to the group its new state puts it in
+- Record the measurement in the task's `## Findings` as a line labeled with this session and the date, per `${CLAUDE_SKILL_DIR}/../task-board/references/tasks.md`
+- `### Writing the board` in `role-orchestrator` owns the method, and `canon tasks validate` runs once the board is rewritten and before the report
 
 ## Re-testing a backlog row
 
-A backlog row carries no blocker cell, since `${CLAUDE_SKILL_DIR}/../task-board/references/board.md` fixes `backlog.md` as a flat list of links with no state of its own. The five kinds above test what a blocker names, and a backlog row names none, so this pass asks the board-or-backlog question the standard already states instead: has the work in front of the row landed, or has the world changed under it. Read the answer from the task file's own `## Findings` and its origin line (`Plan:`, `Groundwork:`, `Intake:`, or `Issue:`), which name what the row was filed against and whether the fact behind it still holds.
+A backlog row carries no blocker cell, since `${CLAUDE_SKILL_DIR}/../task-board/references/board.md` fixes `backlog.md` as a flat list of links with no state of its own. This pass asks the standard's board-or-backlog question instead, whether the work in front of the row landed or the world changed under it.
+
+- Read the answer from the task file's `## Findings` and its origin line, `Plan:`, `Groundwork:`, `Intake:`, or `Issue:`
+- Clearing a row answers yes, never a count of how long it waited, since age is refused as evidence here on the same ground as for a board row
+- This pass only clears a row upward. Declining or archiving a backlog row is `backlog-triage`.
 
-Clearing a row answers yes to that question. It is not a count of how long the row has waited: `## Two results that are not a re-test` below refuses age as evidence for a board row, and it refuses it here on the same ground, since a row untouched for weeks is not more clearable than one added yesterday.
+### Moving a cleared row
 
-A row this test clears moves out of `backlog.md` and onto the bottom of `## Needs a plan`, carrying a `Waiting on` cell that states what changed and ends with the word `last`. `canon tasks validate`'s ordering check reads `last` as the ordinal bottom placement already claims, and a cell stating only what changed matches neither that check's ordinal reading nor its rank reading, which raises the finding this pass would then have written against its own row. The next refill sweep's promotion step still orders the row against the rest of that heading the way it orders every other row there, per step 5 under `## Refilling the ready queue` in `role-orchestrator`.
+A cleared row moves out of `backlog.md` onto the bottom of `## Needs a plan`, with a `Waiting on` cell stating what changed and ending with the word `last`.
 
-This pass only clears a row upward. Declining or archiving a backlog row is `backlog-triage`, which files a verdict for every row and applies the ones the operator approved.
+- `canon tasks validate`'s ordering check reads `last` as the ordinal the bottom placement claims
+- A cell stating only what changed matches neither the ordinal nor the rank reading, raising a finding against the pass's own row
+- The next refill sweep's promotion step still orders the row against the rest of that heading, per step 5 under `## Refilling the ready queue` in `role-orchestrator`
 
 ## Two ways a re-test goes wrong
 
 Both return a confident wrong answer rather than an error, which is why each gets a step of its own.
 
-The first is reading the condition looser than the code defines it. A row parked on a count of some shape names a shape its consumer defines precisely, and a count taken by eye or by a pattern that approximates it lands somewhere else. The row that motivated this runbook counted 19 instances of a shape whose real count under the consumer's definition was zero.
+### Reading the condition looser than the code
+
+A row parked on a count of some shape names a shape its consumer defines precisely, and a count by eye or by an approximate pattern lands elsewhere. The row that motivated this runbook counted 19 instances of a shape whose real count under the consumer's definition was zero.
 
 Find the code that consumes the shape, read the definition off it, and measure with that. A count taken any other way is not evidence about the blocker.
 
-The second is measuring against the wrong tree. A command that ships to targets is at risk in corpora this repository never formats, so a condition measured here reads as unreachable while it stays live where the command runs. Ask which tree the condition is about before asking what the count is. A local formatter removing the shape on contact says nothing about a target running no such formatter.
+### Measuring against the wrong tree
 
-## The plan half
+A command that ships to targets is at risk in corpora this repository never formats, so a condition measured here reads as unreachable while it stays live where the command runs. Ask which tree the condition is about before asking what the count is.
 
-Plan what the pass clears, and plan any `## Needs a plan` row whose only blocker is the missing plan. The window is the argument: this pass runs while workers build and the session is otherwise idle, which is when planning costs the critical path nothing, and a row cleared with no plan is a row the next pass looks at again.
+A local formatter removing the shape on contact says nothing about a target running no such formatter.
 
-Run `plan-feature` for each, carrying the constraint per in-flight track that `## The loop` in `role-orchestrator` requires. Verify each plan against the tree the way that step does, since a plan written now is written against a tree several branches are already changing.
+## The plan half
 
-Stop where `## Parallelism` stops rather than planning every row the pass cleared. A plan the conflict check holds behind every track in flight is one nobody can dispatch.
+Plan what the pass clears, and any `## Needs a plan` row whose only blocker is the missing plan. This pass runs while workers build and the session is idle, when planning costs the critical path nothing, and a row cleared with no plan is looked at again next pass.
 
-Do not restate the refill procedure. `orchestrator-refill.md` owns it and `orchestrator-sweep.md` wraps it for a batch of merges, so this pass promotes through that method rather than a second one.
+- Run `plan-feature` for each, carrying the constraint per in-flight track that `## The loop` in `role-orchestrator` requires
+- Verify each plan against the tree the way that step does, since several branches are already changing it
+- Stop where `## Parallelism` stops, since a plan the conflict check holds behind every track in flight is one nobody can dispatch
+- Do not restate the refill procedure. `orchestrator-refill.md` owns it, so this pass promotes through that method.
 
 ## Two results that are not a re-test
 
-Age is not evidence. A row untouched for weeks invites promotion, and the waiting is not an argument for it. `role-orchestrator` refuses to promote a task to fill the queue and this pass inherits that refusal, so a row whose blocker still holds stays where it is. Reporting it as still parked, against a measurement taken this pass, is a result.
+Neither result below justifies moving a row.
 
-A scoping defect can wear a blocker. A task conflicting with every other by construction, through a contract everything consumes or a sweep over everything, is oversized rather than blocked, and planning it again produces the same plan nobody can dispatch. Split it so each piece holds behind fewer tracks, and the board stops carrying a row that re-measures the same way every pass. A task that merely shares files with everything is not this case.
+- Age is not evidence. `role-orchestrator` refuses to promote a task to fill the queue, so a row whose blocker still holds stays, reported as still parked against this pass's measurement.
+- A scoping defect can wear a blocker. A task conflicting with every other through a contract everything consumes or a sweep over everything is oversized, not blocked.
+- Split such a task so each piece holds behind fewer tracks, since planning it again produces the same undispatchable plan
+- A task that merely shares files with everything is not this case
 
 ## Output