@erclx/canon 5.40.0 → 5.42.0

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

@@ -9,27 +9,39 @@ Run the orchestrator's review trigger. The poll reports pull request movement an
 
 ## When to run it
 
-Start the poll on an open pull request and stop it when the last one merges with nothing else out. That is the whole condition and it resolves from the open list without asking the operator. A release pull request alone does not qualify, since its sweep carries no findings.
+Start the poll on an open pull request and stop it when the last one merges with nothing else out. That is the whole condition, and it resolves from the open list without asking the operator. A release pull request alone does not qualify, since its sweep carries no findings.
 
-A dispatch no longer starts it. The script reads pull requests and a building worker has none, so every interval between the launch and the push is a fixed cost returning nothing, measured as five consecutive runs reporting no movement across roughly fifteen minutes while one worker built. What replaces it is the worker announcing its own pull request the moment it opens one, per the `role-worker` skill that session loads, which covers exactly the transition the poll cannot observe.
+### A dispatch no longer starts it
 
-The dispatched-worker condition survives as a fallback rather than as a trigger. Start the poll against any dispatch still out after thirty minutes with no announcement, which is past the upper end of the ten to thirty minutes a row here takes. The announcement is newer than the narrowing it justifies, so a silent failure would otherwise leave a finished worker unnoticed the way one already sat idle for eighteen minutes, and the fallback keeps the cover a straight narrowing would have removed. `${CLAUDE_SKILL_DIR}/scripts/watch.ts` covers the same window at a lower cost, since it reads the roster alongside the pull request list and reports a worker that vanished as well as one that finished. Read `${CLAUDE_SKILL_DIR}/references/orchestrator-watch.md` before starting it, since it carries the stall alarm and the notification each alarm line owes the operator.
+The script reads pull requests and a building worker has none, so every interval between the launch and the push returns nothing. That cost measured as five consecutive runs reporting no movement across roughly fifteen minutes while one worker built.
 
-A session holding a recurring-prompt scheduler starts the loop itself on that condition and cancels it on the same test, without waiting for the operator. Both halves belong to whoever holds the loop, since a session that can start one can stop one, and a runbook stating only the start leaves the always-on failure unaddressed on the side that causes it.
+- The worker announces its own pull request the moment it opens one, per `role-worker`, which covers the transition the poll cannot observe
+- Start the poll against any dispatch still out after thirty minutes with no announcement, past the upper end of the ten to thirty a row takes
+- That fallback keeps the cover against a silent failure, since a finished worker once sat idle for eighteen minutes unnoticed
 
-Nothing enforces this. No hook starts the poll and no check stops it, so the condition holds only while whoever holds the loop applies it. Left always-on it fires into an empty board through every gap between a dispatch and its push.
+`${CLAUDE_SKILL_DIR}/scripts/watch.ts` covers the same window at a lower cost, since it reads the roster beside the pull request list and reports a vanished worker as well as a finished one. Read `${CLAUDE_SKILL_DIR}/references/orchestrator-watch.md` before starting it, for the stall alarm and the notification each alarm line owes the operator.
 
-The poll is session-scoped and dies with the session that started it. Restart it after a compaction, and take the prompt from this file rather than from a transcript, since a running loop holds whatever wording it was started with and a correction here does not reach it.
+### Who starts and stops it
 
-The reverse direction is the one that goes unnoticed. A scheduled prompt cannot be edited, so every routing fix is a cancel and a re-create, and three made inside one session each reached the running loop and none reached this file. Edit the block here first and re-create the loop from what this file then says. Rewriting the block from memory drops what the shipped one covered, which is how a `SEEN` report once fell through to no rule at all.
+A session holding a recurring-prompt scheduler starts the loop on that condition and cancels it on the same test, without waiting for the operator. A runbook stating only the start leaves the always-on failure unaddressed on the side that causes it.
 
-## The prompt
+- Nothing enforces this. No hook starts the poll and no check stops it, so the condition holds only while the loop's holder applies it.
+- Left always-on, it fires into an empty board through every gap between a dispatch and its push
+- The poll is session-scoped and dies with its session, so restart it after a compaction, taking the prompt from this file rather than a transcript
+
+### Editing the prompt
+
+A running loop holds whatever wording it was started with, and a scheduled prompt cannot be edited, so every routing fix is a cancel and a re-create. Three fixes made inside one session once reached the running loop and none reached this file.
 
-The requirement is a recurring prompt at roughly three minutes carrying the block below. `/loop 3m <the block>` is the mechanism this repository uses and one example among the schedulers a client may hold, so a client without that command reaches the same requirement through whatever recurring prompt it can schedule. Naming one vendor's command as the only path dates a file that ships to every target holding the plugin.
+Edit the block here first and re-create the loop from what this file then says. Rewriting the block from memory drops what the shipped one covered, which is how a `SEEN` report once fell through to no rule at all.
+
+## The prompt
 
-The interval belongs to the schedule rather than to the script. One run is a single snapshot returning in about six seconds, so a session that reads `3m` as the script's runtime and relaunches on completion fires every few seconds and never settles, which happened once for 35 minutes.
+The requirement is a recurring prompt at roughly three minutes carrying the block below. `/loop 3m <the block>` is this repository's mechanism and one example among the schedulers a client may hold, so a client without it schedules whatever recurring prompt it can.
 
-Resolve `${CLAUDE_SKILL_DIR}/scripts/poll.ts` to an absolute path and paste that in place of `<POLL_SCRIPT>` below. The variable expands while this runbook renders and not in a standalone loop turn, so a block carrying the variable reaches the session as a literal string and the run improvises a substitute.
+- The interval belongs to the schedule, since one run is a six-second snapshot, and relaunching on completion once fired every few seconds for 35 minutes
+- Paste the absolute path of `${CLAUDE_SKILL_DIR}/scripts/poll.ts` in place of `<POLL_SCRIPT>` below
+- The variable expands while this runbook renders and not in a standalone loop turn, so a block carrying it reaches the session as a literal and the run improvises
 
 ```plaintext
 Poll GitHub for pull request movement by running `bun <POLL_SCRIPT>`, then act on what it reports.
@@ -55,36 +67,78 @@ After a pass that posts a finding, at any severity, and that no live local revie
 
 ## Reading the output
 
-Every classification line names a pull request and a state. A line starting `poll:` is not a classification. It means a query failed and the script declined to guess, so that pull request keeps its last known state and is neither reported as moved nor swept as merged. Treat it as unread and let the next run classify it.
+Every classification line names a pull request and a state. A line starting `poll:` is a failed query rather than a classification, so that pull request keeps its last known state and is neither reported as moved nor swept as merged.
 
-The script exits non-zero and classifies nothing when the open pull request list itself fails to load. That case would otherwise report every tracked pull request as merged, so the baseline is left untouched and the run says so.
+- The script exits non-zero and classifies nothing when the open list itself fails to load, leaving the baseline untouched, since it would report every pull request merged
+- The baseline lives at `.canon/tmp/pr/poll/baseline.txt` under the main worktree root and is per-machine
+- A first run against a board already in flight reports each open pull request once before it settles
 
-The baseline lives at `.canon/tmp/pr/poll/baseline.txt` under the main worktree root and is per-machine. A first run against a board already in flight reports each open pull request once before it settles.
+### Headings the script knows
 
-The eight headings the script knows are written by `review-pr`, `review-address`, `canon pr evidence`, and `review-ui`, and the whole set is stated once in the first. The reply family and the UI family are matched by filters in `poll.ts`, so a project posting either under different headings edits those to match. The review family is matched inside `canon pr review-state` instead, which the script and `review-pr` both read through, so a project renaming either review heading changes the verb rather than the script. Either way, a heading nothing matches reads as a pull request nobody has reviewed. The `UI-` states report the newest UI pass on its transition, and `UI-STALE` fires beside the `MOVED` of a push that left its marker behind. A first sighting reports none, which costs the mark nothing, since `canon pr lift` reads the UI review itself and holds the mark wherever `canon pr evidence <number> --json` carries a `checklist` until a UI close names the head.
+The eight headings the script knows are written by `review-pr`, `review-address`, `canon pr evidence`, and `review-ui`, and the whole set is stated once in the first. A heading nothing matches reads as a pull request nobody has reviewed.
 
-`UNMATCHED` is what a comment reaches under a heading outside the six the comment filters know, a UI heading posted as a comment included, carried the same way `RESPONSE` is: a rising count against the baseline is what is new to this script, and the message names the heading so a person can tell whether to answer it by hand or add it to the set. It fires on a tracked pull request only, since a first sighting reports `SEEN` or `OPENED` and takes whatever count already sits on the thread as its starting baseline rather than flagging history the poll never watched.
+- The reply family matches by a filter in `poll.ts`, so a project posting it under different headings edits that
+- The review and UI families match inside `canon pr review-state`, which the script and `review-pr` both read, so renaming one changes the verb
+- The `UI-` states report the newest UI pass on its transition, and `UI-STALE` fires beside the `MOVED` of a push that left its marker behind
+- A first sighting reports no `UI-` state at no cost to the mark, since `canon pr lift` reads the UI review itself and holds the mark on a `canon pr evidence` checklist until a UI close names the head
 
-`RESPONSE` is qualified by recency as well as by count, so it means a reply the last pass has not already answered rather than one this script has not seen before. A worker answers a finding and the reviewing session posts its close-out seconds later, which is the ordinary handback rather than a race, so a count on its own reported the answered thread on the next run and the re-review it routed to stopped at its own guard. The state now fires when the newest reply is stamped later than the last pass, and on a pull request carrying no pass at all, which is a worker talking to nobody and worth the turn. A reply landing inside the same second as the pass is dropped, matching the comparison `review-pr` makes on the same two fields.
+### UNMATCHED and RESPONSE
 
-`STALLED` is the one state the script derives from a heading rather than from a commit or a count, since `review-pr` posts the open heading exactly when a dispatch is owed, per the threshold that skill states. The heading alone cannot carry it, because an open pass means a dispatch was owed and made, so the ordinary healthy thread is a worker still working. The age of that pass is the third test: the state fires when the open pass covers the head, nothing has followed it, and it is older than the `STALE_AFTER` seconds set at the top of the script. It reports once per entry and fires again after any commit or reply resets the thread. A project whose workers run longer than the default two hours raises that number.
+`UNMATCHED` is a comment under a heading outside the six the comment filters know, a UI heading posted as a comment included. It fires on a rising count against the baseline, and the message names the heading so a person can answer by hand or add it to the set.
 
-The state reaches every stalled dispatch, since one threshold governs the heading and the dispatch alike and a pass carrying anything posts the open heading. A minors-only pass therefore reports here on the same terms as a blocking one, which widens the state from what it caught while the two were split. It stays a heading test rather than a count test, so nothing here pins the summary line, which is a second string this script does not own.
+- It fires on a tracked pull request only, since a first sighting takes the thread's count as its baseline rather than flagging history
+- `RESPONSE` means a reply the last pass has not answered, qualified by recency as well as count, since a close-out seconds after a worker's answer is the ordinary handback
+- It fires when the newest reply is stamped later than the last pass, or on a pull request with no pass, which is a worker talking to nobody
+- A reply landing in the same second as the pass is dropped, matching the comparison `review-pr` makes on the same two fields
+
+### STALLED
+
+`STALLED` is the one state derived from a heading rather than a commit or a count, since `review-pr` posts the open heading exactly when a dispatch is owed. An open pass alone is the ordinary healthy thread, a worker still working, so the age of the pass is the third test.
+
+- It fires when the open pass covers the head, nothing has followed it, and it is older than the `STALE_AFTER` seconds set at the top of the script
+- It reports once per entry and fires again after any commit or reply resets the thread. A project whose workers run past two hours raises the number.
+- One threshold governs the heading and the dispatch, so a minors-only pass reports here on the same terms as a blocking one
+- It stays a heading test, so nothing pins the summary line, a second string this script does not own
 
 ### Base movement
 
-A pull request's run tests the merge with the base as of its last push, so once a sibling merges, that green describes a merge nobody will make. `STALE` closes that gap by hand where a ruleset requiring branches to be current, or a merge queue, would close it on the host. It fires when the base changed a file the pull request writes since the commit it branched from, and names the files. A base that moved only on files the branch does not write reads as nothing, since re-testing after every merge is a merge queue's cost without its batching.
+A pull request's run tests the merge with the base as of its last push, so once a sibling merges, that green describes a merge nobody will make. `STALE` closes that gap by hand where a ruleset requiring current branches, or a merge queue, would close it on the host.
+
+- It fires when the base changed a file the pull request writes since the commit it branched from, and names the files
+- A base moving only on files the branch does not write reads as nothing, since re-testing after every merge is a merge queue's cost without its batching
+- `STALE` and `CONFLICT` report on their transition and on every push leaving the reading standing, then live only in the baseline
 
-`STALE` and `CONFLICT` each report on their transition and again on every push that leaves the reading standing, then live only in the baseline, which is as old as the last run. Read a standing one with `--check <number>`, which fetches the base and reads the head at call time, so a sibling merging after the last run still shows, and prints `CONFLICT`, `STALE`, `CLEAR`, or `UNKNOWN`, writing nothing. It takes the standing `canon pr lift <number> --check --json` reads, so the lift and this check answer from one read, and falls back to its own merge-tree read where the record carries no standing gate, which a binary older than that verb leaves. A pull request whose written set could not be read, being a fork or a deleted head, reads as `UNKNOWN` rather than clear, so its lift waits on a person.
+### Reading a standing state
 
-`OVERLAP` names two open pull requests that conflict with each other, read by merging their heads locally. Only pairs sharing a written path are tried, which keeps a wave of ten to a handful of merges. It reports once per pair, carried in the tenth baseline field, so the merge order is settled before the second branch has to rebase rather than after.
+Read a standing one with `--check <number>`, which fetches the base and reads the head at call time, so a sibling merging after the last run still shows. It prints `CONFLICT`, `STALE`, `CLEAR`, or `UNKNOWN` and writes nothing.
+
+- It takes the standing `canon pr lift <number> --check --json` reads, so the lift and this check answer from one read
+- It falls back to its own merge-tree read where the record carries no standing gate, as a binary older than that verb leaves
+- A pull request whose written set could not be read, being a fork or a deleted head, reads `UNKNOWN`, so its lift waits on a person
+
+### OVERLAP
+
+`OVERLAP` names two open pull requests that conflict with each other, read by merging their heads locally. Only pairs sharing a written path are tried, which keeps a wave of ten to a handful of merges. It reports once per pair, carried in the tenth baseline field, so the merge order is settled before the second branch has to rebase.
 
 ### What a SEEN rests on
 
-`SEEN` used to fire early, on a head nobody had read. A review's `commit.oid` is stamped with the head at submission rather than with the commit the reviewer read, so an author pushing between the diff read and the post left the pass recorded against a commit it never saw, and `SEEN` then fired on a head still awaiting its first look at that delta.
+A review's `commit.oid` is stamped with the head at submission rather than the commit the reviewer read. An author pushing between the diff read and the post would leave the pass recorded against a commit it never saw, and `SEEN` would fire on an unread delta.
+
+The pass carries its own record instead. `review-pr` writes the commit it read and the instant it read it as a marker on the last line of every body, and both this script and that skill resolve the covered state through `canon pr review-state`, the one place the marker is parsed.
+
+- A commit pushed inside a pass's compose window falls outside the marked range, so it reads as `MOVED` rather than `SEEN`
+- A `SEEN` is a claim about what a session read rather than what GitHub stamped, so it wants no second read to be believed
+
+### The source behind a SEEN
+
+Read `source` on the record before trusting a `SEEN` on a thread whose newest pass is old.
+
+- `marker`: the read-time record
+- `fallback`: a pass posted before the marker shipped, or a target whose CLI predates the verb, carrying the defect above, so read the reviews once before believing it
+- `none`: a thread carrying no pass at all
 
-The pass now carries its own record instead. `review-pr` writes the commit it read and the instant it read it as a marker on the last line of every body it posts, and both this script and that skill resolve the covered state through `canon pr review-state`, which is the one place the marker is parsed. A commit pushed inside a pass's compose window falls outside the marked range, so it reads as `MOVED` rather than as `SEEN`. A `SEEN` is a claim about what a session read rather than about what GitHub stamped, so it wants no second read to be believed.
+### The head side of the comparison
 
-Read `source` on the record before trusting a `SEEN` on a thread whose newest pass is old. `marker` is the read-time record. `fallback` is a pass posted before the mechanism shipped, or a target whose CLI predates the verb, and it carries the defect above unchanged, so a `SEEN` under it is worth one read of the pull's reviews before it is believed. `none` is a thread carrying no pass at all.
+The pull read's `head.sha` answers from the pull request object, which trails the branch ref by up to a minute after a push and reports nothing about the trail. A stamp ahead of the commit read, compared against a head behind the real one, made the two errors compound.
 
-The other side of that comparison used to lag as well, which made the two errors compound rather than cancel. The pull read's `head.sha` answers from the pull request object and that object trails the branch ref by up to a minute after a push, reporting nothing about the trail, so a pass stamped ahead of the commit it read was compared against a head stamped behind the commit that exists. The head now comes from `canon pr head`, which resolves the tip through `git ls-remote` and reports which commit each source names, and the object's head stays behind it as the fallback for a target whose CLI predates the verb. Both halves of the comparison now answer about a commit somebody named rather than one GitHub stamped, which is what lets a `SEEN` be read as covered.
+The head now comes from `canon pr head`, which resolves the tip through `git ls-remote` and reports which commit each source names. The object's head stays behind it as the fallback for a target whose CLI predates the verb, so both halves answer about a commit somebody named.

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

@@ -5,22 +5,36 @@ description: The queue-refill procedure run after a merge, on a thin ready list,
 
 Run this when `## Refilling the ready queue` in the skill body names one of its three triggers. `orchestrator-sweep.md` wraps it for a batch of merges and adds the plan re-verification that a merge invalidates.
 
-The third trigger reaches a window the first two cannot. A session with three workers mid-build has merged nothing and has watched its ready list sit still, so both reactive triggers stay silent across the one stretch where planning costs the session nothing, and the wave finishes into an empty `## Run now`. Nothing starts this pass, in the way nothing starts the review poll, so it holds only while the session applies it.
+## The mid-wave trigger
 
-It counts unclaimed plans against workers rather than reading the reserve in step 4, which is sized for one worker finishing and falls short of a wave landing together. A plan a worker has already taken serves nobody who finishes next, so counting it is what lets the queue read full while it is about to empty. How many to write forward past that floor is the parallelism call rather than a count of free slots, and `## Parallelism` in the skill body states what binds it.
+The third trigger reaches a window the first two cannot. A session with three workers mid-build has merged nothing and watched its ready list sit still, so both reactive triggers stay silent across the one stretch where planning costs nothing, and the wave finishes into an empty `## Run now`.
+
+- Nothing starts this pass, as nothing starts the review poll, so it holds only while the session applies it
+- It counts unclaimed plans against workers rather than reading step 4's reserve, which is sized for one worker finishing and falls short of a wave landing together
+- A plan a worker already took serves nobody who finishes next, so counting it lets the queue read full while it is about to empty
+- How many to write past that floor is the parallelism call rather than a count of free slots, and `## Parallelism` in the skill body states what binds it
 
 ## Running the refill
 
 1. Run `gh pr list --state open` and `git log --oneline -8`. Report any pull request whose review has not been posted and stop for that one first.
-2. For each pull request merged since the last sweep, place every finding it produced. Route a finding that changes a rule to the standard or rule that states it, one that changes another task to that task's Findings, and one that overturns a groundwork lean to that folder marked answered. Never leave a finding in a pull request thread alone.
+2. For each pull request merged since the last sweep, place every finding it produced, and never leave one in a pull request thread alone.
+   - A finding that changes a rule goes to the standard or rule that states it
+   - One that changes another task goes to that task's Findings, and one that overturns a groundwork lean to that folder marked answered
 3. Archive what closed.
-   - A task whose outcomes are all `[x]` and whose pull request merged is archived by the `post-merge` hook through `canon tasks archive`, which carries its plans with it. Run `task-complete` to archive one the hook left in place
-   - A task whose outcomes describe standing policy rather than a deliverable never closes on its own, so hand it to a worker to encode the policy where it is enforced, then cut the outcomes with the reason recorded and archive once that branch merges. Encoding it from this session would write a tracked file, which `## Boundaries` in the skill body forbids.
+   - A task whose outcomes are all `[x]` and whose pull request merged is archived by the `post-merge` hook through `canon tasks archive`, plans included
+   - Run `task-complete` to archive one the hook left in place
+   - A task whose outcomes are standing policy never closes, so hand it to a worker to encode the policy where it is enforced, then cut the outcomes with the reason and archive once that branch merges
+   - Encoding it from this session would write a tracked file, which `## Boundaries` in the skill body forbids
 4. Read `.canon/tasks/priority.md` and count entries under its `## Run now` heading that carry a written plan. Keep one in reserve beyond what is running.
-5. Promote from the top of `## Needs a plan`, which is where the last sweep recorded what to plan next. Depart from that order when something has changed under it and say what changed, since a position nobody honors is the ordering going stale on the surface built to hold it. What sets the order in the first place is whether a task establishes functionality rather than how old it is, so prefer a task that adds or proves a mechanism over one that trims, tidies, or audits an existing surface.
-   - Re-take the demotion half of the board-or-backlog call while the file is open. A row that has stopped being near-term moves to `backlog.md`, one line removed from `priority.md` and written there, per the standard's test. The promotion half is `orchestrator-parked.md`'s to run as a full walk over every backlog row, so this step does not repeat it. A row that pass clears already sits at the bottom of `## Needs a plan` before this sweep reads the heading.
-6. Before promoting a candidate, test it against every task already running under the conflict check in `orchestrator-dispatch.md`. Serialize it behind a task only on one of that check's holds, and name the hold. A path the two merely share is promoted beside it, named so the merge order plans the rebase.
-   - A candidate held by something outside the tree stays where it is whatever the check shows. A conflict is one of the reasons a task cannot start, so clearing the check clears that reason alone and leaves an external condition standing.
+5. Promote from the top of `## Needs a plan`, where the last sweep recorded what to plan next.
+   - Depart from that order when something changed under it and say what, since a position nobody honors is the ordering going stale
+   - The order is set by whether a task establishes functionality, so prefer one that adds or proves a mechanism over one that trims, tidies, or audits
+   - Re-take the demotion half of the board-or-backlog call while the file is open, moving a row no longer near-term to `backlog.md` per the standard's test
+   - The promotion half is `orchestrator-parked.md`'s full walk over every backlog row, and a row it clears already sits at the bottom of `## Needs a plan`
+6. Before promoting a candidate, test it against every running task under the conflict check in `orchestrator-dispatch.md`.
+   - Serialize it behind a task only on one of that check's holds, and name the hold
+   - A path the two merely share is promoted beside it, named so the merge order plans the rebase
+   - A candidate held by something outside the tree stays put whatever the check shows, since clearing a conflict leaves an external condition standing
 7. Write a plan for each newly promoted task with `plan-feature`, carrying the in-flight constraint that `## The loop` in the skill body states, then report:
 
 ```plaintext
@@ -34,23 +48,32 @@ Ready now: <tasks with plans, and what each waits on>
 
 That block is the detail. Lead the reply with the three slots under `## Every later turn` in `orchestrator-output.md`, so the human reads what they own before the evidence for it.
 
-A task that edits `canon/context/` entries wholesale is a sweep under the conflict check, and holds every other task, because the root instruction file requires each task to update its own domain entry as it lands.
-
-Do not promote a task to fill the queue when nothing qualifies. A thin queue is a real answer and it beats a plan nobody needed.
+- A task editing `canon/context/` entries wholesale is a sweep under the conflict check and holds every other task, since the root instruction file requires each task to update its own domain entry
+- Do not promote a task to fill the queue when nothing qualifies. A thin queue is a real answer and it beats a plan nobody needed.
 
 ## Writing the board
 
 Promoting, demoting, and archiving a row all write `.canon/tasks/priority.md`, and this session is the only writer apart from `canon tasks archive`. Moving a task between the board and `.canon/tasks/backlog.md` writes both files, and this session is that file's only writer.
 
-- Edit the file with the file-editing tool. A shell stream editor and an inline string replace both exit clean on a non-match, so a promotion that matched nothing leaves the board wrong with nothing reporting it, and the file-editing tool errors instead.
-- Write both halves of a move before reporting it. A row removed from one surface and not written to the other leaves a task file nothing names, and the folder is gitignored with no history to recover the row from. `canon tasks validate` reports that state, so run it after any move.
-- Put the reason a row sits where it does in its Waiting on cell. Position is the ordering and the cell is where the ordering's rationale lives, so a row promoted with the cell left alone carries an order the next sweep cannot check.
+- Edit with the file-editing tool, which errors on a non-match, where a shell stream editor or an inline replace exits clean and leaves the board wrong
+- Write both halves of a move before reporting it, since a row on neither surface leaves a task file nothing names in a gitignored folder with no history
+- `canon tasks validate` reports that state, so run it after any move
+- Put the reason a row sits where it does in its Waiting on cell, since a row promoted with the cell left alone carries an order the next sweep cannot check
 
 ### Columns and read-back
 
-- Put a pointer in the Plan column, never prose. `## Run now` claims a written plan covers every open outcome, and `auto-ship` refuses at its guard when it follows the column and finds no plan, which spends a worker dispatch to learn what the row should have said.
-- Name the file set in the Touches column. It feeds the merge order and the shared paths a dispatch names, and the hold call in step 6 is only checkable later when the sets are written down rather than reasoned once and discarded.
+Each column carries a fact a later reader checks rather than reasons again.
+
+- Put a pointer in the Plan column, never prose, since `auto-ship` refuses at its guard when the column leads to no plan, spending a dispatch
+- `## Run now` claims a written plan covers every open outcome, which is what the pointer backs
+- Name the file set in the Touches column, which feeds the merge order and the shared paths a dispatch names, so step 6's hold call stays checkable later
 - Re-resolve every Plan pointer after anything archives a plan
 - Read the file back after writing it, since the row that lands is the row a worker acts on
 
-A Plan pointer goes stale from a merge this board never sees. The `post-merge` hook moves a plan to `.canon/plans/archive/` through `canon tasks archive` and rewrites the citation in the archived task file alone, so a row for a task still on the board keeps pointing into `.canon/plans/` at a file that has moved. `task-complete` marks outcomes on each worker's branch and moves nothing, so the move lands at the merge, and the board reads as correct until a pointer is followed.
+### Stale plan pointers
+
+A Plan pointer goes stale from a merge this board never sees. The `post-merge` hook moves a plan to `.canon/plans/archive/` through `canon tasks archive` and rewrites the citation in the archived task file alone.
+
+- A row for a task still on the board keeps pointing into `.canon/plans/` at a file that has moved
+- `task-complete` marks outcomes on each worker's branch and moves nothing, so the move lands at the merge
+- The board then reads as correct until a pointer is followed

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

@@ -6,9 +6,13 @@ description: What to read back after a compaction, and how to treat a groundwork
 Resume as orchestrator after a compaction. Read the board and the groundwork behind the live work before answering anything, because a compaction summary keeps conclusions and drops the reasoning that produced them.
 
 1. Resolve the main worktree root with `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd`. Every path below resolves against it.
-2. Read `.canon/tasks/priority.md` for the ordering and what each task waits on. Read the newest `.canon/tasks/session-*.md` when one exists, per `${CLAUDE_SKILL_DIR}/../session-map/references/session.md`, and treat it as the previous session's scratch rather than a source.
+2. Read `.canon/tasks/priority.md` for the ordering and what each task waits on.
+   - Read the newest `.canon/tasks/session-*.md` when one exists, per `${CLAUDE_SKILL_DIR}/../session-map/references/session.md`
+   - Treat it as the previous session's scratch rather than a source
 3. Read the task file for every entry under `## Run now`, plus any entry a live pull request names.
-4. Read the groundwork folder each of those tasks cites. Read `README.md` for the file map, then `06-decision.md` when the track is closed, or `07-next-session.md` and the numbered topic files when it is open. A task's Findings section is a lossy summary of its track, so planning against the summary re-derives what the folder already settled.
+4. Read the groundwork folder each of those tasks cites.
+   - `README.md` for the file map, then `06-decision.md` when the track is closed, or `07-next-session.md` and the topic files when open
+   - A task's Findings section is a lossy summary, so planning against it re-derives what the folder already settled
 5. Run `gh pr list --state open` and `git log --oneline -5` to see what shipped since the folder was written.
 6. Report in this shape and stop:
 
@@ -22,12 +26,20 @@ Held open: <talk sessions from the map's `## Talk sessions held open`, or none>
 
 Read `Held open:` off the newest session map's `## Talk sessions held open`, so a resumed session does not mistake a conversation for a finished delivery. `orchestrator-handoff.md` states what ends one.
 
-Treat a groundwork folder as three kinds of content with different shelf lives. Trust the reasoning and the method, which stay correct. Re-measure every count, size, and cost, because they were true when written. Check every `Leaning:` against what has shipped, because work spawned by a track routinely overturns the lean that spawned it and nothing writes back.
+## Groundwork shelf lives
 
-A plan a live task cites goes stale the same way, and `role-orchestrator` states the check that catches it.
+Treat a groundwork folder as three kinds of content with different shelf lives. A plan a live task cites goes stale the same way, and `role-orchestrator` states the check that catches it.
 
-After each merge, place every finding the work produced before starting anything else. A finding that changes a standard goes to the standard, one that changes another task goes to that task's Findings, and one that overturns a groundwork lean gets marked answered in that folder. Findings recorded in a pull request thread and nowhere else are lost at merge.
+- Trust the reasoning and the method, which stay correct
+- Re-measure every count, size, and cost, because they were true when written
+- Check every `Leaning:` against what has shipped, since a track's spawned work routinely overturns its lean and nothing writes back
+- Cite a file and line for any claim taken from a groundwork folder, so a later reader can tell a read from a recall
+- Read only the folders the live tasks cite, since a speculative sweep of the whole folder is the cost this rule exists to bound
 
-Cite a file and line for any claim taken from a groundwork folder, so a later reader can tell a read from a recall.
+## After each merge
 
-Do not read every groundwork folder. Read the ones the live tasks cite. A speculative sweep of the whole folder is the cost this rule exists to bound.
+Place every finding the work produced before starting anything else, since a finding recorded in a pull request thread and nowhere else is lost at merge.
+
+- A finding that changes a standard goes to the standard
+- One that changes another task goes to that task's Findings
+- One that overturns a groundwork lean gets marked answered in that folder

package/claude/skills/role-orchestrator/references/orchestrator-review-dispatch.md

@@ -9,30 +9,40 @@ Run this on every first pass, from `### The review dispatch` in the skill body.
 
 Dispatch every pull request's review to a reviewer under `role-reviewer`, first pass included, whatever its size or its paths. A release pull request is the one exception, since its sweep carries no findings and owes no pass.
 
-This session reviews nothing in place. A warm pass reads the whole diff into the one context the wave shares, so every pull request reviewed here thins the attention each later one gets, and a cold session pays for its own context instead.
-
-Nothing checks that a first pass was dispatched rather than run here. This is prose this session applies to itself, on the same standing as the poll's own start condition, so a pull request reviewed in place is a rule that went unread rather than a check that failed.
-
-Pick the reviewer's model by `## Pick the model` in `orchestrator-dispatch.md`, which states the test for every role this session launches. Stating the pick here as well would leave two sources for one call.
+- This session reviews nothing in place, since a warm pass reads the whole diff into the wave's one context and thins every later pull request's attention
+- A cold session pays for its own context instead
+- Nothing checks that a first pass was dispatched, so a pull request reviewed in place is a rule that went unread rather than a check that failed
+- Pick the reviewer's model by `## Pick the model` in `orchestrator-dispatch.md`, the one source for every role this session launches
 
 ## The UI reviewer
 
-A pull request whose evidence record carries a checklist takes a second reviewer, a UI reviewer under `review-ui`, dispatched beside the code reviewer so the two passes run at once. Read the record with `canon pr evidence <number> --json` and branch on its `checklist` field rather than on the exit code. A record carrying none dispatches no UI reviewer, since the pass would stop on arrival.
+A pull request whose evidence record carries a checklist takes a second reviewer, a UI reviewer under `review-ui`, dispatched beside the code reviewer so the two passes run at once. Read the record with `canon pr evidence <number> --json` and branch on its `checklist` field rather than on the exit code.
 
-The UI reviewer reads no diff and never hears the code reviewer's verdict, so neither brief carries the other's result. Each posts its own family and runs `canon pr lift` on posting its close, and the verb lifts the draft mark only once both read closed at the head, per the draft-lift boundary in the skill body.
+- A record carrying no checklist dispatches no UI reviewer, since the pass would stop on arrival
+- The UI reviewer reads no diff and never hears the code verdict, so neither brief carries the other's result
+- Each posts its own family and runs `canon pr lift` on its close, and the verb lifts the draft mark only once both read closed at the head
 
 ## The cross-branch pass
 
-This session keeps one pass per wave beside the dispatched reviews. It reads the file sets of every open pull request against each other, the board, and the merge order, and never the diffs themselves. What it looks for is what no single pull request shows: two branches regenerating one asset, several writing one context entry, a figure true only after another branch lands.
+This session keeps one pass per wave beside the dispatched reviews. It reads the file sets of every open pull request against each other, the board, and the merge order, and never the diffs themselves.
 
-Hand what it finds to each reviewer as facts in the brief, per `### What the brief may carry` in `orchestrator-launch.md`, rather than posting a comment of its own, so each pull request keeps one live verdict. A fact surfacing after a reviewer posted goes to that reviewer as a re-review request.
+- It looks for what no single pull request shows, such as two branches regenerating one asset, several writing one context entry, or a figure true only after another lands
+- Hand what it finds to each reviewer as facts in the brief, per `### What the brief may carry` in `orchestrator-launch.md`, so each pull request keeps one live verdict
+- A fact surfacing after a reviewer posted goes to that reviewer as a re-review request
 
 ## Launching the reviewer
 
-Take the reviewer shape in `orchestrator-reviewer-launch.md`, or its UI reviewer shape for a pull request carrying a checklist. Check `canon sessions list --json` for a live `reviewer-<project>-<number>`, or `reviewer-ui-<project>-<number>`, first and message it instead of launching a second, since two reviewers on one pull request post two verdicts. The re-review after a worker's address pass reaches that reviewer from the worker directly, and this session sends it only as the fallback `orchestrator-handback.md` states.
+Take the reviewer shape in `orchestrator-reviewer-launch.md`, or its UI reviewer shape for a pull request carrying a checklist.
+
+- Check `canon sessions list --json` first for a live `reviewer-<project>-<number>` or `reviewer-ui-<project>-<number>`, and message it instead of launching
+- Two reviewers on one pull request post two verdicts
+- The re-review after a worker's address pass reaches the reviewer from the worker, and this session sends it only as the fallback `orchestrator-handback.md` states
 
 ## Local or cloud
 
-A code review goes to a cloud reviewer rather than `claude --bg` only on the operator's explicit pick for that dispatch, the same standing the build shape's pick holds in `orchestrator-dispatch.md`. The cloud session costs no local context and no machine slot, which matters on a wide wave. It also reads nothing this machine holds, so a review that needs the board, a local preview, or a sandbox stays local.
+A code review goes to a cloud reviewer rather than `claude --bg` only on the operator's explicit pick for that dispatch, the same standing the build shape's pick holds in `orchestrator-dispatch.md`. A UI review always stays local.
 
-This session hears a cloud reviewer through `poll.ts` alone, which already lists every open pull request from this machine, so the posted review is the announcement and no message arrives. `orchestrator-cloud-launch.md` carries the shape under `## Dispatch a review to a cloud reviewer`. A UI review always stays local.
+- The cloud session costs no local context and no machine slot, which matters on a wide wave
+- It reads nothing this machine holds, so a review needing the board, a local preview, or a sandbox stays local
+- This session hears a cloud reviewer through `poll.ts` alone, so the posted review is the announcement and no message arrives
+- `orchestrator-cloud-launch.md` carries the shape under `## Dispatch a review to a cloud reviewer`

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

@@ -15,11 +15,15 @@ No branch and no worktree are entered here. The reviewer reads the pull request
 claude --bg --model <model> -n "reviewer-<project>-<number>" "Run /canon:role-reviewer, then /canon:review-pr <number>. 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. When the pass posts under ## Review, message the worker holding the branch to run review-address, carrying your own sessionId, and send it to the controller instead when no worker resolves. When it posts ## Review closed, run canon pr lift <number> --json and message the controller with the heading, the count line, and the reason the verb returned, unless that reason names the UI review as still open or missing. Message the controller again if you stop on a question."
 ```
 
-`<number>` is the pull request's number, and the brief pins no head, since `review-pr` resolves the head itself and stamps the range it covered in its marker. `<model>` comes from `## Pick the model` in `orchestrator-dispatch.md`, which states the test for a reviewer as for every other role. `<dispatcher-id>` and `<project>` resolve the same way they do in `orchestrator-launch.md`.
+- `<number>` is the pull request's number, and the brief pins no head, since `review-pr` resolves it and stamps the covered range in its marker
+- `<model>` comes from `## Pick the model` in `orchestrator-dispatch.md`, which states the test for a reviewer as for every other role
+- `<dispatcher-id>` and `<project>` resolve the same way they do in `orchestrator-launch.md`
+- Append the cross-branch facts after the controller clause, per `### What the brief may carry` in `orchestrator-launch.md`
+- Check `canon sessions list --json` for a live `reviewer-<project>-<number>` before launching, and message it instead when one holds the pull request
 
-The channel clauses restate what `role-reviewer` holds, so a reviewer whose plugin cache predates that body still sends the dispatch itself rather than leaving it to this session. The worker reads the reviewer's sessionId off that message and sends its re-review request back to it, since a reviewer holds the trunk branch and no branch lookup finds it. Append the cross-branch facts after the controller clause, per `### What the brief may carry` in `orchestrator-launch.md`.
+### The channel clauses
 
-Check `canon sessions list --json` for a live `reviewer-<project>-<number>` before launching, and message that session instead when one holds the pull request.
+The channel clauses restate what `role-reviewer` holds, so a reviewer whose plugin cache predates that body still sends the dispatch itself. The worker reads the reviewer's sessionId off that message and sends its re-review request back to it, since a reviewer holds the trunk branch and no branch lookup finds it.
 
 ## Dispatch a review to a cloud reviewer
 
@@ -33,8 +37,13 @@ Read `${CLAUDE_SKILL_DIR}/references/orchestrator-cloud-launch.md` when the oper
 claude --bg --model sonnet -n "reviewer-ui-<project>-<number>" "Run /canon:role-reviewer, then /canon:review-ui <number>. 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. When the pass posts under ## UI review, message the worker holding the branch to run review-address, carrying your own sessionId, and send it to the controller instead when no worker resolves. When it posts ## UI review closed, run canon pr lift <number> --json and message the controller with the heading, the count line, and the reason the verb returned, unless that reason names the code review as still open or missing. Message the controller again if you stop on a question."
 ```
 
-The model is `sonnet`, always, as the UI reviewer line in `## Pick the model` in `orchestrator-dispatch.md` states with its measured reason.
+The model is `sonnet`, always, as the UI reviewer line in `## Pick the model` in `orchestrator-dispatch.md` states with its measured reason. `<number>`, `<dispatcher-id>`, and `<project>` resolve the same way they do in `orchestrator-launch.md`.
 
-Name an address in the brief only when the evidence record carries no `preview` and no `local` field, as `Drive <url>.` after the controller clause. An address the record already holds is the one the pass reads first, and a second in the brief is a second source for one fact. Name a CLI config path the same way when the operator keeps a GPU recipe for this machine, since the pass renders in software otherwise. Carry nothing else: the UI reviewer reads no diff and no code verdict, so the cross-branch facts the code brief carries stay out of this one.
+- The prefix reads `reviewer-ui-` so a roster read for `reviewer-<project>-<number>` never matches it, and the two passes stay two sessions
+- Carry no cross-branch facts, since the UI reviewer reads no diff and no code verdict
 
-`<number>`, `<dispatcher-id>`, and `<project>` resolve the same way they do in `orchestrator-launch.md`. The prefix reads `reviewer-ui-` so a roster read for `reviewer-<project>-<number>` never matches the UI reviewer, and the two passes on one pull request stay two sessions.
+### What the UI brief may carry
+
+Name an address only when the evidence record carries no `preview` and no `local` field, as `Drive <url>.` after the controller clause. An address the record holds is the one the pass reads first, and a second in the brief is a second source for one fact.
+
+Name a CLI config path the same way when the operator keeps a GPU recipe for this machine, since the pass renders in software otherwise.

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

@@ -5,17 +5,35 @@ description: The once-per-batch board sweep, plan re-verification, and where eac
 
 Sweep the board as orchestrator after merging. Run this once per batch of merges, before answering what to do next, because the surfaces that record what shipped are the ones nothing updates on its own.
 
-1. Pull into the main worktree rather than fetching. A fetch leaves the local branch behind, so `git log` reports a state that has not arrived. A repository that adds a post-merge hook to name archive candidates gets it on a pull and never on a fetch.
+1. Pull into the main worktree rather than fetching, since a fetch leaves the local branch behind and `git log` reports a state that has not arrived.
+   - A repository that adds a post-merge hook to name archive candidates gets it on a pull and never on a fetch
 2. Follow `orchestrator-refill.md`, every step in order. It owns the procedure. Do not restate it here and do not run it from memory.
-3. Re-verify every plan already written, not only the ones this sweep writes. A queued plan goes stale from whatever merged while it waited, and the loop's verify step fires at handoff rather than after a merge, so nothing else catches it. Grep each construct the plan names and count the sites against its claim, then open each file rather than trusting its account.
-4. Re-check any precondition a plan states about live state outside the repository. A remote branch, an open issue, or an installed version was true when the plan was written and is not a fact about the tree.
+3. Re-verify every plan already written, not only the ones this sweep writes.
+   - A queued plan goes stale from whatever merged while it waited, and the loop's verify step fires at handoff, so nothing else catches it
+   - Grep each construct the plan names and count the sites against its claim, then open each file rather than trusting its account
+4. Re-check any precondition a plan states about live state outside the repository, such as a remote branch, an open issue, or an installed version.
+   - Each was true when the plan was written and is not a fact about the tree
 
-Run `canon worktrees list` after the pull, which is the first point at which the merges this sweep followed are readable. It owns the reclaim rule and it removes nothing, so read its rows and act on the ones you mean to. Never substitute a git ancestry check for it.
+## Worktrees and the validator
 
-Run `canon tasks validate` once the board is rewritten and before reporting it. It resolves every plan pointer, accounts every task file against the board and the backlog both, reports the paths `## Run now` rows share as a candidate list for the conflict check, and re-takes the two blocker kinds a command can settle. It reports and never writes, so fix each row it names and run it again. A finding it reports is a board defect rather than a task finding, so it goes nowhere but the board.
+Run `canon worktrees list` after the pull, the first point at which the merges this sweep followed are readable. It owns the reclaim rule and removes nothing, so read its rows and act on the ones you mean to. Never substitute a git ancestry check for it.
 
-Then run `orchestrator-parked.md` over the rows the validator listed as untested. Those carry the three blocker kinds no command settles, and the merge this sweep followed changed the tree under every one of them at once while the refill above re-read none. Take the untested rows alone rather than the whole board, since the validator already answered the rest.
+Run `canon tasks validate` once the board is rewritten and before reporting it. It reports and never writes, so fix each row it names and run it again.
 
-Place every finding the merged work produced before promoting anything. A finding that changes a rule goes to the standard or the rule that states it, one that changes another task goes to that task's Findings, and one that overturns a groundwork lean gets marked answered in that folder. A pull request body counts as nowhere, since the thread stops being read the moment it merges.
+- It resolves every plan pointer and accounts every task file against the board and the backlog both
+- It reports the paths `## Run now` rows share as a candidate list for the conflict check, and re-takes the two blocker kinds a command can settle
+- A finding it reports is a board defect rather than a task finding, so it goes nowhere but the board
+
+### Untested rows
+
+Then run `orchestrator-parked.md` over the rows the validator listed as untested. Those carry the three blocker kinds no command settles, and the merge changed the tree under every one at once while the refill re-read none. Take the untested rows alone, since the validator already answered the rest.
+
+## Place the findings
+
+Place every finding the merged work produced before promoting anything. A pull request body counts as nowhere, since the thread stops being read the moment it merges.
+
+- A finding that changes a rule goes to the standard or the rule that states it
+- One that changes another task goes to that task's Findings
+- One that overturns a groundwork lean gets marked answered in that folder
 
 Report what closed, what moved, and what is ready to hand a worker. Name the file set each ready task touches and the hold or shared paths it carries, so the reader can check the conflict call rather than take it.

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

@@ -7,20 +7,46 @@ Run the watch beside the poll when the dispatch fallback in `orchestrator-poll.m
 
 ## The watch beside it
 
-`${CLAUDE_SKILL_DIR}/scripts/watch.ts` is a long-running loop rather than a scheduled prompt, started as `bun <path>`. It reads the open pull request list and the session roster together every sixty seconds and prints one line per new pull request, per worker whose name, branch, or status changed, and per worker that dropped out of the roster. Start it in the background and read what it emits. It writes nothing.
+`${CLAUDE_SKILL_DIR}/scripts/watch.ts` is a long-running loop rather than a scheduled prompt, started as `bun <path>` in the background. It writes nothing. Every sixty seconds it reads the open pull request list and the session roster together and prints one line per event.
 
-Coverage is what it buys over the poll. A worker that finishes goes idle and a worker that crashes disappears, so a trigger reading pull requests alone stays silent through the second, and the roster read is the half `poll.ts` cannot make. It ran a full afternoon over four concurrent workers and caught every transition, while the three-minute poll it replaced reported no movement five times in a row.
+- A new pull request
+- A worker whose name, branch, or status changed
+- A worker that dropped out of the roster
 
-It classifies nothing and routes nothing. A line it prints says a pull request opened or a worker moved, and the routing block in `orchestrator-poll.md` is still what decides whether a review follows, so the two compose rather than replace each other.
+### What it buys over the poll
 
-Every session in the repository holding a branch other than the base one counts as a worker, whoever launched it. The prototype matched the `orchestrator-` prefix instead, which reads a dispatched worker and misses every hand-launched one. A failed read of either source reports itself on a `watch:` line and leaves the baseline untouched, since reading an empty result as current state would report every worker gone on the pass after.
+A worker that finishes goes idle and one that crashes disappears, so a trigger reading pull requests alone stays silent through the second. The roster read is the half `poll.ts` cannot make.
+
+- It ran a full afternoon over four concurrent workers and caught every transition, while the three-minute poll it replaced reported no movement five times running
+- It classifies and routes nothing, so the routing block in `orchestrator-poll.md` still decides whether a review follows and the two compose
+
+### Who counts as a worker
+
+Every session in the repository holding a branch other than the base one counts as a worker, whoever launched it, since matching the `orchestrator-` prefix would miss every hand-launched one.
+
+A failed read of either source reports itself on a `watch:` line and leaves the baseline untouched, since reading an empty result as current state would report every worker gone on the pass after.
 
 ## The stall alarm
 
-`watch.ts` prints `WORKER-STOPPED <name> <branch> <dwell>s` once a `waiting` row crosses `STALL_THRESHOLD_S`, and `WORKER-UNMEASURABLE <name> <branch>` for one whose record carries neither timestamp the dwell falls back to. Both are prints, not alerts, so the operator learns of one only when a session already reading the loop's output relays it further. The toolkit ships no notification verb, since the surface a stall reaches the operator through is a session tool rather than a command a shell loop can call.
+`watch.ts` prints `WORKER-STOPPED <name> <branch> <dwell>s` once a `waiting` row crosses `STALL_THRESHOLD_S`. It prints `WORKER-UNMEASURABLE <name> <branch>` for a row whose record carries neither timestamp the dwell falls back to.
+
+- Both are prints, not alerts, so the operator learns of one only when a session already reading the output relays it
+- The toolkit ships no notification verb, since a stall reaches the operator through a session tool rather than a command a shell loop can call
+
+### Two levels of confidence
+
+The two lines carry different confidence, and the push says so rather than treating them as one signal.
+
+- `WORKER-STOPPED` fires only once the dwell has crossed the threshold, so it reports a wait already confirmed long
+- `WORKER-UNMEASURABLE` has no dwell to threshold on, so it fires on the first pass meeting a stampless `waiting` row, whether it sat five seconds or fifty minutes
+
+### Pushing the notification
+
+On meeting either line, push a notification to the operator through whatever surface the client offers, `PushNotification` in this repository's client and one example among the surfaces a different client exposes.
 
-The two lines carry different confidence and the push has to say so rather than treat them as one signal. `WORKER-STOPPED` fires only once the dwell has already crossed the threshold, so it reports a wait already confirmed long. `WORKER-UNMEASURABLE` has no dwell to threshold on, so it fires on the first pass that meets a `waiting` row carrying neither stamp, whether that row has sat five seconds or fifty minutes.
+- Name the worker, the branch, which line fired, and the dwell where `WORKER-STOPPED` carries one
+- Send it once per stall, as `watch.ts` prints it once, rather than on every interval the row stays stopped
 
-On meeting either line, push a notification to the operator through whatever notification surface the client offers, `PushNotification` in this repository's client and one example among the surfaces a different client exposes. Name the worker, the branch, which of the two lines fired, and the dwell where `WORKER-STOPPED` carries one, and send it once per stall the same way `watch.ts` prints it once, rather than repeating it on every interval the row stays stopped.
+### The open bound
 
-The bound stays open. The alarm reaches the operator only through the controller's own read, so a controller mid-turn does not see the line for as long as the turn runs, and a controller that is itself stopped never does. Neither case closes here, since the watch loop and the notification surface both live inside the same session that has to be free to act on either.
+The alarm reaches the operator only through the controller's own read, so a controller mid-turn misses the line for as long as the turn runs, and a stopped controller never sees it. Neither case closes here, since the loop and the notification surface both live inside the session that has to be free to act.