@erclx/canon 5.45.0 → 5.46.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/claude/.claude-plugin/plugin.json +1 -1
- package/claude/skills/api-design/REQUIREMENT.md +15 -31
- package/claude/skills/auto-ship/REQUIREMENT.md +14 -25
- package/claude/skills/backlog-triage/REQUIREMENT.md +12 -23
- package/claude/skills/build-in-slices/REQUIREMENT.md +15 -25
- package/claude/skills/canon-cli/REQUIREMENT.md +15 -27
- package/claude/skills/canon-feedback/REQUIREMENT.md +10 -18
- package/claude/skills/canon-feedback-triage/REQUIREMENT.md +10 -15
- package/claude/skills/canvas-board/REQUIREMENT.md +14 -28
- package/claude/skills/ci-workflow/REQUIREMENT.md +12 -21
- package/claude/skills/code-craft/REQUIREMENT.md +14 -28
- package/claude/skills/codebase-layout/REQUIREMENT.md +14 -31
- package/claude/skills/context-fold/REQUIREMENT.md +15 -39
- package/claude/skills/context-fold/references/context.md +3 -3
- package/claude/skills/create-rule/REQUIREMENT.md +10 -24
- package/claude/skills/create-rule/SKILL.md +3 -0
- package/claude/skills/create-skill/REQUIREMENT.md +10 -21
- package/claude/skills/decision-escalate/REQUIREMENT.md +12 -24
- package/claude/skills/deploy-app/REQUIREMENT.md +12 -22
- package/claude/skills/deprecation-migration/REQUIREMENT.md +14 -42
- package/claude/skills/design-identity/REQUIREMENT.md +14 -20
- package/claude/skills/design-taste/REQUIREMENT.md +16 -57
- package/claude/skills/docs-sync/REQUIREMENT.md +14 -23
- package/claude/skills/document-health/REQUIREMENT.md +15 -29
- package/claude/skills/document-health/SKILL.md +2 -2
- package/claude/skills/document-repair/REQUIREMENT.md +32 -0
- package/claude/skills/document-repair/SKILL.md +76 -0
- package/claude/skills/document-repair/references/batches.md +44 -0
- package/claude/skills/draft-and-pick/REQUIREMENT.md +4 -3
- package/claude/skills/draft-doc/REQUIREMENT.md +4 -3
- package/claude/skills/draft-figure/REQUIREMENT.md +4 -3
- package/claude/skills/draft-identity/REQUIREMENT.md +4 -3
- package/claude/skills/draft-ready/REQUIREMENT.md +4 -3
- package/claude/skills/draft-screencast/REQUIREMENT.md +4 -3
- package/claude/skills/draft-slides/REQUIREMENT.md +4 -3
- package/claude/skills/draw-figure/REQUIREMENT.md +15 -39
- package/claude/skills/git-branch/REQUIREMENT.md +12 -26
- package/claude/skills/git-commit/REQUIREMENT.md +11 -15
- package/claude/skills/git-followup/REQUIREMENT.md +11 -22
- package/claude/skills/git-issue/REQUIREMENT.md +9 -15
- package/claude/skills/git-pr/REQUIREMENT.md +13 -32
- package/claude/skills/git-pr/SKILL.md +10 -2
- package/claude/skills/git-pr/references/closing-issues.md +47 -0
- package/claude/skills/git-pr/references/pr.md +4 -0
- package/claude/skills/git-ship/REQUIREMENT.md +13 -26
- package/claude/skills/git-split/REQUIREMENT.md +10 -17
- package/claude/skills/git-stage/REQUIREMENT.md +12 -18
- package/claude/skills/git-worktree/REQUIREMENT.md +15 -19
- package/claude/skills/make-deck/REQUIREMENT.md +13 -21
- package/claude/skills/markdown-craft/REQUIREMENT.md +9 -3
- package/claude/skills/plan-feature/REQUIREMENT.md +15 -24
- package/claude/skills/plan-groundwork/REQUIREMENT.md +12 -28
- package/claude/skills/plan-groundwork/SKILL.md +5 -2
- package/claude/skills/plan-groundwork/references/output.md +47 -1
- package/claude/skills/plan-intake/REQUIREMENT.md +11 -26
- package/claude/skills/plan-intake/references/intake.md +2 -2
- package/claude/skills/plan-intake-answer/REQUIREMENT.md +14 -29
- package/claude/skills/plan-intake-answer/SKILL.md +7 -1
- package/claude/skills/plan-ready/REQUIREMENT.md +17 -36
- package/claude/skills/pr-evidence/REQUIREMENT.md +11 -17
- package/claude/skills/read-frames/REQUIREMENT.md +3 -8
- package/claude/skills/record-screencast/REQUIREMENT.md +14 -17
- package/claude/skills/review-address/REQUIREMENT.md +14 -38
- package/claude/skills/review-craft/REQUIREMENT.md +14 -32
- package/claude/skills/review-pr/REQUIREMENT.md +15 -34
- package/claude/skills/review-ui/REQUIREMENT.md +14 -39
- package/claude/skills/role-orchestrator/REQUIREMENT.md +2 -2
- package/claude/skills/role-orchestrator/references/orchestrator-refill.md +5 -0
- package/claude/skills/role-orchestrator/references/orchestrator-review-dispatch.md +9 -0
- package/claude/skills/role-reviewer/REQUIREMENT.md +15 -65
- package/claude/skills/role-reviewer/SKILL.md +5 -1
- package/claude/skills/role-worker/REQUIREMENT.md +1 -1
- package/claude/skills/role-worker/SKILL.md +2 -0
- package/claude/skills/script-screencast/REQUIREMENT.md +10 -16
- package/claude/skills/search-craft/REQUIREMENT.md +12 -36
- package/claude/skills/search-craft/SKILL.md +1 -1
- package/claude/skills/search-craft/references/adopted.md +2 -2
- package/claude/skills/session-compact/REQUIREMENT.md +13 -23
- package/claude/skills/session-map/REQUIREMENT.md +13 -29
- package/claude/skills/session-relay/REQUIREMENT.md +14 -58
- package/claude/skills/session-relay/SKILL.md +6 -0
- package/claude/skills/session-resume/REQUIREMENT.md +13 -27
- package/claude/skills/session-worktree/REQUIREMENT.md +14 -43
- package/claude/skills/systematic-debugging/REQUIREMENT.md +13 -34
- package/claude/skills/target-check/REQUIREMENT.md +16 -23
- package/claude/skills/target-setup/REQUIREMENT.md +11 -34
- package/claude/skills/task-board/REQUIREMENT.md +13 -22
- package/claude/skills/task-board/SKILL.md +7 -0
- package/claude/skills/task-board/references/tasks.md +1 -1
- package/claude/skills/task-complete/REQUIREMENT.md +11 -24
- package/claude/skills/task-complete/references/archive.md +1 -0
- package/claude/skills/teach-workspace/REQUIREMENT.md +14 -45
- package/claude/skills/test-craft/REQUIREMENT.md +15 -46
- package/claude/skills/test-first/REQUIREMENT.md +14 -20
- package/claude/skills/ui-checklist/REQUIREMENT.md +14 -29
- package/claude/skills/ux-audit/REQUIREMENT.md +3 -7
- package/claude/skills/ux-measure/REQUIREMENT.md +14 -28
- package/claude/skills/video-craft/REQUIREMENT.md +14 -27
- package/claude/skills/write-doc/REQUIREMENT.md +14 -24
- package/claude/skills/write-human/REQUIREMENT.md +15 -27
- package/claude/skills/youtube-transcripts/REQUIREMENT.md +9 -15
- package/docs/agents/context-audit.md +19 -12
- package/docs/agents/markdown-audit.md +15 -10
- package/docs/target/projects.md +2 -0
- package/docs/workflow/skill-map.md +6 -5
- package/governance/renames.toml +0 -2
- package/governance/rules/claude/output.md +5 -1
- package/governance/rules/code/routing.md +5 -1
- package/governance/stacks/base.toml +0 -1
- package/package.json +1 -1
- package/src/claude/cases/workflow.ts +12 -0
- package/src/commands/context.ts +57 -3
- package/src/commands/labels.ts +83 -3
- package/src/commands/markdown.ts +188 -21
- package/src/commands/sessions.ts +36 -3
- package/src/commands/tasks.ts +180 -0
- package/src/commands/worktrees.ts +2 -0
- package/src/context/coverage.ts +210 -0
- package/src/context/gate.ts +12 -3
- package/src/gate/stages.ts +1 -1
- package/src/init/steps.ts +45 -0
- package/src/intake/items.ts +14 -0
- package/src/labels/closing.ts +46 -0
- package/src/markdown/gated.ts +250 -0
- package/src/markdown/scope.ts +115 -2
- package/src/migrate/rename.ts +6 -0
- package/src/sessions/claim.ts +7 -0
- package/src/sessions/live.ts +53 -6
- package/src/sessions/registry.ts +11 -0
- package/src/sessions/resolve.ts +32 -5
- package/src/tasks/closes.ts +136 -0
- package/src/tasks/record.ts +1 -1
- package/src/worktrees/reclaim.ts +16 -1
- package/tooling/base/configs/scripts/verify.ts +1 -1
- package/tooling/claude/seeds/.claude/hooks/board-validate.sh +1 -1
- package/tooling/claude/seeds/CLAUDE.md +2 -2
- package/governance/rules/canon/task-scope.md +0 -12
|
@@ -7,79 +7,29 @@ description: What a dispatched reviewing session is, what it writes and reads, t
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, review is the one stage
|
|
11
|
-
Planning goes to `role-planner` sessions and building to `role-worker` sessions,
|
|
12
|
-
while every first pass still runs inside the controlling session with several
|
|
13
|
-
pull requests held in one context. A loop is as parallel as its narrowest stage,
|
|
14
|
-
so a wave of planners and workers ends in a queue at review however wide the
|
|
15
|
-
first two stages run.
|
|
10
|
+
Without this skill, review is the one stage that does not fan out. Every first pass runs inside the controlling session with several pull requests in one context, and that session skims the docs a branch touches. A cold session reviewing one pull request finds what it missed.
|
|
16
11
|
|
|
17
|
-
|
|
18
|
-
a blind trial on 2026-09-25, a cold session reviewing one pull request found two
|
|
19
|
-
real stale-count findings on a branch the controlling session had closed clean
|
|
20
|
-
while holding eight, because that session read the source diff closely and
|
|
21
|
-
skimmed the docs the branch touched. A live trial the same day dispatched three
|
|
22
|
-
first passes to cold sessions, and on the one pull request both sides read, the
|
|
23
|
-
cold pass found a finding the warm pass missed and showed one of the warm pass's
|
|
24
|
-
own findings wrong.
|
|
25
|
-
|
|
26
|
-
Every one of those launches restated the reviewer's bounds by hand: write the
|
|
27
|
-
comment alone, no worktree, no branch, no board write, no fix, no direct draft
|
|
28
|
-
lift.
|
|
29
|
-
Each is a property of the role rather than of the pull request, so each dispatch
|
|
30
|
-
reproduced them from memory, the shape `role-planner` was written to retire on
|
|
31
|
-
the planning side.
|
|
32
|
-
|
|
33
|
-
Three bounds matter more than the rest. A reviewer asked to fix what it found
|
|
34
|
-
has reviewed its own change afterwards, and nothing recovers the independent
|
|
35
|
-
read. A reviewer posting `## Review closed` is one step from readying the pull
|
|
36
|
-
request by hand, which skips the gates `canon pr lift` reads, and `review-pr`
|
|
37
|
-
Step 5 reports a merge recommendation that reads as permission when the body is
|
|
38
|
-
silent. A reviewer with no checkout reading a file
|
|
39
|
-
off the main worktree reads the trunk, so every finding it files there is about
|
|
40
|
-
a tree the pull request never changed.
|
|
41
|
-
|
|
42
|
-
Routing through the controlling session costs that session the most. Until
|
|
43
|
-
2026-10-12 each review round passed through it four times: the pass announced to
|
|
44
|
-
it, the dispatch to the worker, the worker's answer, and the re-review request.
|
|
45
|
-
Every one of those is a turn that reads the whole wave's context, and the
|
|
46
|
-
reviewer and the worker each already knew what the other needed next.
|
|
12
|
+
Each launch also restates the reviewer's bounds, though they belong to the role. A reviewer asked to fix has reviewed its own change, and one posting a close is a step from readying the pull request, skipping the gates `canon pr lift` reads. One with no checkout reads the trunk, so its findings describe a tree the pull request never changed.
|
|
47
13
|
|
|
48
14
|
## Must
|
|
49
15
|
|
|
50
|
-
-
|
|
51
|
-
-
|
|
52
|
-
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
- Refuse the fix, a draft lift by any route but `canon pr lift`, and the merge, whoever asks, and name who owns each, since each has a sender who will ask
|
|
56
|
-
- Run `canon pr lift` after posting a close, since the verb reads every gate itself and a reviewer's close is the moment the last of them can turn clear
|
|
57
|
-
- Send the `review-address` dispatch to the worker on an open pass, carrying the number, the heading, `review-pr` Step 5's count line, and this session's sessionId, and fall back to the controller when no worker resolves, since every hop through the controller costs it a turn that reads the whole wave's context
|
|
58
|
-
- Message the controller on a close with the reason `canon pr lift` returned, unless the reason names the other review as still open, since that refusal needs nothing from anyone
|
|
59
|
-
- Owe a message before a block becomes an interactive prompt, since a session already waiting on input never reaches the tool round an inbound message drains at
|
|
60
|
-
- Keep a re-review with the reviewer that took the first pass while it is live, so the second pass keeps the read the first paid for
|
|
61
|
-
- Defer the addressee resolution to `session-relay` and keep only the last-rung inference, which discriminates as it does for a planner because a reviewer holds no feature branch either
|
|
16
|
+
- The role is asserted, with writes bounded to the comment and body file the pass posts, and the tracked file, branch, worktree, board, and commit named as outside them
|
|
17
|
+
- Every file read a finding rests on goes through `git show <head>:<path>` at the resolved head, and launch-carried cross-branch facts are inputs
|
|
18
|
+
- The fix, a draft lift by any route but `canon pr lift`, and the merge are refused whoever asks, naming each owner, and the lift runs after a close is posted
|
|
19
|
+
- An open pass sends the worker the `review-address` dispatch and this session's id, else the controller the cause, and a close sends the lift's reason unless the other review is open or missing
|
|
20
|
+
- A re-review stays with the reviewer that took the first pass while it is live, and a block is messaged before it becomes an interactive prompt
|
|
62
21
|
|
|
63
22
|
## Must not
|
|
64
23
|
|
|
65
|
-
- Restate `review-pr`'s steps
|
|
66
|
-
-
|
|
67
|
-
-
|
|
68
|
-
-
|
|
69
|
-
- Post outside `review-pr` and `review-ui`, since every reader of the review headings breaks at once when one pass invents its own
|
|
70
|
-
- Be a skill nothing invokes but its author typing the name. `orchestrator-reviewer-launch.md` names it on the reviewer launch the way `orchestrator-launch.md` names `role-planner` on a planning one, so a stretch where only a typed invocation reaches it is the signal that the role never took.
|
|
71
|
-
|
|
72
|
-
## Guards
|
|
73
|
-
|
|
74
|
-
- Plan or task does not resolve from where the session stands: report it unreadable and name the main-root path, rather than reviewing as though the branch had no plan
|
|
75
|
-
- Asked by anyone to fix, ready the pull request directly, or merge: refuse, name who owns the act, and file the defect in the comment when the ask was a fix
|
|
76
|
-
- Launch named no controlling session and an operator is present: ask which row to address rather than inferring
|
|
77
|
-
- Launch named no controlling session and nobody is present: infer from the sessions holding no feature branch, report the candidates when more than one comes back, and say the addressee was inferred
|
|
24
|
+
- Restate `review-pr`'s steps and headings, `review-craft`'s criteria, or a boundary another role states about itself
|
|
25
|
+
- Report progress through the channel, or post outside `review-pr` and `review-ui`
|
|
26
|
+
- Review as though the branch had no plan when it does not resolve, and instead report it unreadable naming the main-root path
|
|
27
|
+
- Exist for the author to type its name, since a stretch where only a typed invocation reaches it signals the role never took
|
|
78
28
|
|
|
79
29
|
## Out of scope
|
|
80
30
|
|
|
81
|
-
- The pass itself, its
|
|
82
|
-
- What a review looks for
|
|
83
|
-
- The cross-branch pass per wave and
|
|
84
|
-
- Answering the review, which `review-address` owns
|
|
31
|
+
- The pass itself, its scope, body, and post, which `review-pr` owns
|
|
32
|
+
- What a review looks for, which `review-craft` owns
|
|
33
|
+
- The cross-branch pass per wave and which pull requests take a reviewer, which `role-orchestrator` owns
|
|
34
|
+
- Answering the review, which `review-address` owns
|
|
85
35
|
- The mechanical addressee resolution, which `session-relay` owns
|
|
@@ -59,7 +59,11 @@ Send it to the worker holding the branch as `review-pr` Step 5 returns an open `
|
|
|
59
59
|
- Carry the pull request number, the heading, that step's count line verbatim, and this session's own sessionId for the worker's reply
|
|
60
60
|
- Resolve the worker with `canon sessions list --branch <branch> --json`, where `<branch>` is the pull request's head branch
|
|
61
61
|
- Send to it only when exactly one session comes back with its confidence reading `confirmed`
|
|
62
|
-
- On zero, on any other count or confidence, or on a refusal, send the same message to the controller,
|
|
62
|
+
- On zero, on any other count or confidence, or on a refusal, send the same message to the controller, naming the cause the roster read gives
|
|
63
|
+
- Say the roster rests on sockets from another pid namespace, so the worker may be live and unconfirmed, when a row reads `via: "socket"` or an empty roster carries a `foreignDead` count above zero
|
|
64
|
+
- Say the roster rests on a pid answering alone, since start times could not be read, when the confidence reads `unverified` and no row reads `via: "socket"`
|
|
65
|
+
- Say no worker resolved only for a `confirmed` roster of zero rows, and name the count and confidence for any other
|
|
66
|
+
- Name the refusal and what the verb returned when `canon sessions list` refused, since a refusal has no roster to read
|
|
63
67
|
|
|
64
68
|
### The close
|
|
65
69
|
|
|
@@ -14,7 +14,7 @@ The channel fails on the worker's side. Blocks open prompts nobody is attached t
|
|
|
14
14
|
## Must
|
|
15
15
|
|
|
16
16
|
- Session scratch resolves at the main worktree root, and a plan that fails to resolve is reported unreadable from there rather than absent
|
|
17
|
-
- The
|
|
17
|
+
- The announcement carries the number, branch, task, reach, any uncleared spend, and any row the build turned up, and a painted diff has its preview server running before the pull request opens
|
|
18
18
|
- A block goes out as a message before it becomes a prompt, a fan-in member's done message carries its branch and head commit, and a review wait that times out reaches the controller
|
|
19
19
|
- The plan's scope freezes at dispatch, and a late ask is sorted into a defect, a follow-up row, or an addition on the operator's word
|
|
20
20
|
- A refusal of an instruction the tree contradicts carries its evidence, and a talk launch puts its judgment calls to the operator in the session
|
|
@@ -93,6 +93,8 @@ Announce the pull request as the ship chain's pull request step returns, carryin
|
|
|
93
93
|
- Say the reach was unread rather than clear when the installed binary carries no such subcommand, and leave the undeclared list to the pull request
|
|
94
94
|
- Carry a row this build turned up with its title, origin, and surface. Send it alone only when the session ends before a pull request opens.
|
|
95
95
|
|
|
96
|
+
Name any billed run the Testing section needs that the operator has not cleared, so the controller asks before the first review. Leave it out when no spend is owed or it is cleared, and send no second message for it.
|
|
97
|
+
|
|
96
98
|
### A fan-in member
|
|
97
99
|
|
|
98
100
|
A member of a fan-in set opens no pull request, so its done message stands in for the announcement. `auto-ship` sends it after the push.
|
|
@@ -7,34 +7,28 @@ description: Why a recording script ships pre-seeded rather than blank, what the
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, a recording plan arrives as
|
|
10
|
+
Without this skill, a recording plan arrives as blank fields, so the user fills a template instead of editing a draft. The opposite failure costs more. A session skipping discovery guesses the audience, the length, and the hero moment, and writes beats that get thrown away. What surrounds the take surfaces only at compose time.
|
|
11
11
|
|
|
12
|
-
A draft
|
|
12
|
+
A draft naming the recording software, the editing software, or the window manager pins the script to one person's setup. Re-invoking to refine silently overwrites the edits the user made in the file, which destroys work rather than wasting it.
|
|
13
13
|
|
|
14
14
|
## Must
|
|
15
15
|
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
19
|
-
-
|
|
20
|
-
-
|
|
21
|
-
- Write to `demos/<slug>/beats.md` at the project root, the committed folder the rest of the demo lives in, and print that path on its own line
|
|
22
|
-
- Seed a wrap section naming intro, outro, and music with a default each, so the choice of what surrounds the take is made at draft time rather than discovered at compose time
|
|
16
|
+
- Project context and recent commits are read before proposing, and exactly four discovery questions each carry a default derived from them
|
|
17
|
+
- The run waits for answers rather than reading silence as acceptance
|
|
18
|
+
- Every section is pre-seeded with concrete content, so the draft ships as written and the user edits down
|
|
19
|
+
- The draft lands at `demos/<slug>/beats.md` at the project root, with the slug derived from the topic and the answers, and its path printed on its own line
|
|
20
|
+
- A wrap section names intro, outro, and music with a default each
|
|
23
21
|
|
|
24
22
|
## Must not
|
|
25
23
|
|
|
26
24
|
- Name recording software, editing software, fonts, or window managers
|
|
27
25
|
- Record, edit video, or generate captions
|
|
28
26
|
- Re-run against an existing draft to refine it, since re-running overwrites
|
|
29
|
-
- Infer the hero moment without asking,
|
|
30
|
-
|
|
31
|
-
## Guards
|
|
32
|
-
|
|
33
|
-
- No topic provided: stop rather than guessing what is being recorded
|
|
27
|
+
- Infer the hero moment without asking, or guess the topic when none is given
|
|
34
28
|
|
|
35
29
|
## Out of scope
|
|
36
30
|
|
|
37
31
|
- Producing the recording, which `record-screencast` owns
|
|
38
|
-
- Refining an existing draft, which is a direct edit of the file
|
|
39
32
|
- Slide decks, which `make-deck` owns
|
|
40
|
-
-
|
|
33
|
+
- Refining an existing draft, which a direct edit of the file owns
|
|
34
|
+
- Where the recording ships, which the user owns
|
|
@@ -7,51 +7,27 @@ description: Why a session needs a thinking step before an outside search, deriv
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
A session reaching outside the project runs one generic `WebSearch` and takes what ranks highest. Open results skew to third-party pages, two summaries of the same query can disagree on a fact, and an advocacy source can lean the answer. Scoped to authorities the session names itself, the same query returns primary sources.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
- `css container queries browser support`: 1 of 9 open results came from MDN, and that one was a blog post rather than the reference page. The rest were third-party pages, three of them thin guides. Scoped to MDN, web.dev, and caniuse, 10 of 10 results were primary sources.
|
|
15
|
-
- The two summaries disagreed on a fact. The open one said Firefox shipped style queries in version 128, and the scoped one, reading caniuse, said 151. A direct fetch of the caniuse table returned 151, so a session that searched once would have reported the wrong version.
|
|
16
|
-
- `effect of minimum wage increase on employment evidence`: the open set mixed journals with advocacy groups and its summary leaned one way. Scoped to five authorities the session named, being a research bureau's working papers, the economists' professional association, a working-paper index, a policy institute, and a legislature's budget office, 7 of 9 results were working papers or official analysis, and the summary carried both the near-zero and the negative estimates.
|
|
17
|
-
- 2 of the 9 scoped economics results came from a domain outside the allow list, so the filter is not strict.
|
|
18
|
-
|
|
19
|
-
The authorities in both pairs were named by the session unprompted once it was asked to, which is the argument for a method over a list. Two queries at one run each show the effect exists and do not size it.
|
|
20
|
-
|
|
21
|
-
Access is a second gap a session cannot derive. Probed on 2026-10-02, Reddit refused its JSON search with a 403 and refused `WebFetch`, while its RSS feed answered 200. X redirected `curl` to a login page and returned 402 to `WebFetch`, so no free route reaches it. Re-probed on 2026-10-04, Reddit's RSS feed, its search feed, and its JSON listing and search all answered 403, so the feed that answered two days earlier no longer does.
|
|
12
|
+
Access is a second gap a session cannot derive. Some sites refuse a fetch, a feed that answered once stops answering, and a free route to others does not exist. `plan-groundwork` and `write-doc` require an outside source and give no route to one.
|
|
22
13
|
|
|
23
14
|
## Must
|
|
24
15
|
|
|
25
|
-
- Name the field
|
|
26
|
-
-
|
|
27
|
-
-
|
|
28
|
-
-
|
|
29
|
-
-
|
|
30
|
-
- Prefer a public API over a fetched and summarized page where one exists, since the API returns the dates, authors, and identifiers a citation needs
|
|
31
|
-
- Carry a dated access note grown only from a failure a session hit, and stop to ask the operator before any paid or logged-in route
|
|
32
|
-
- Close with the practice skill's excuses, red flags, and closing checklist, answering "the model already knows the good sites" and "one search was enough"
|
|
33
|
-
- Be loaded from the sourcing steps of `plan-groundwork` and `write-doc`'s wiki kind, each reporting when the skill does not resolve
|
|
16
|
+
- Name the field before a query is written, and derive its authorities from the kind of body the field trusts
|
|
17
|
+
- Run the query scoped to those authorities and open beside it, prefer the scoped result on a conflict, and say the two disagreed
|
|
18
|
+
- Check a scoped result's domain before citing it, since the filter is not strict
|
|
19
|
+
- Prefer a public API over a fetched page where one exists, and keep an access note grown from failures a session hit, dated by the commit that adds each line
|
|
20
|
+
- Stop for the operator before a paid or logged-in route, and close with the practice skill's excuses, red flags, checklist, and the sources adopted and declined with the reason for each
|
|
34
21
|
|
|
35
22
|
## Must not
|
|
36
23
|
|
|
37
|
-
- Name a site as the destination for a category of question
|
|
38
|
-
- Ship code
|
|
39
|
-
- Restate citation format, which belongs to the surface writing the citation
|
|
24
|
+
- Name a site as the destination for a category of question, outside an example marked as an illustration of deriving one
|
|
25
|
+
- Ship code, since access code a session needs repeatedly becomes a `canon` verb
|
|
40
26
|
- Suggest scraping behind a login or a paywall
|
|
41
27
|
|
|
42
28
|
## Out of scope
|
|
43
29
|
|
|
44
|
-
- The form a citation takes
|
|
45
|
-
-
|
|
30
|
+
- The form a citation takes, which the procedure writing it owns
|
|
31
|
+
- Sourcing a Claude Code subject, which `write-doc` owns through its wiki sourcing step
|
|
46
32
|
- Image generation, which makes a picture rather than finding a source
|
|
47
|
-
- Loading on every web search rather than
|
|
48
|
-
- Whether a session already scopes searches without the skill, which only a run on a fresh research request without it would show
|
|
49
|
-
|
|
50
|
-
## Measured
|
|
51
|
-
|
|
52
|
-
2026-10-03, one Sonnet run of the toolkit's own sandbox scenario for this skill, a housing brief asking for linked notes and a prompt for the strongest evidence on whether rent control reduces housing supply. The skill sat in the project's skill folder and the run was allowed the skill, search, and fetch tools.
|
|
53
|
-
|
|
54
|
-
- No `Skill` call fired, so the description did not route a plain research request to the body.
|
|
55
|
-
- The run searched four times with no domain filter, naming authors and journals from recall, then fetched the papers' own pages. It never named the field, so the scenario's field pattern failed and the arm went red on one of its assertions.
|
|
56
|
-
|
|
57
|
-
The arm shows the trigger is the gap rather than the body: a session that never loads the skill cannot follow it. The pointers from `plan-groundwork` and `write-doc`'s wiki kind reach only those procedures, and the hook matching `WebSearch` is the route for every other search. One run on one model shows the miss exists and does not size it.
|
|
33
|
+
- Loading on every web search rather than a research-shaped request, which a hook matching `WebSearch` owns
|
|
@@ -44,7 +44,7 @@ This skill carries the step before the search. Work out where the field's author
|
|
|
44
44
|
|
|
45
45
|
## Access note
|
|
46
46
|
|
|
47
|
-
Each line is a claim measured once, and
|
|
47
|
+
Each line is a claim measured once, and the commit that adds it carries the date. Sites change their blocking without notice, so re-check a line before relying on it. Add a line only for a failure a session actually hit.
|
|
48
48
|
|
|
49
49
|
- Reddit refuses its RSS feed and its JSON search alike with a 403. `WebFetch` is refused for the site, so no keyless route reaches it.
|
|
50
50
|
- X answers nothing without paying or a login. `curl` redirects to a login page and `WebFetch` returns 402.
|
|
@@ -5,7 +5,7 @@ description: Which comparable research skills this skill was read against, what
|
|
|
5
5
|
|
|
6
6
|
# Adopted and declined
|
|
7
7
|
|
|
8
|
-
Three third-party research skills were read before this one was written. None of them was imported, and most of the body rests on paired searches
|
|
8
|
+
Three third-party research skills were read before this one was written. None of them was imported, and most of the body rests on paired open and scoped searches run against this skill's own question rather than on any of them. A later session extending the skill adds to this file rather than re-arguing an item settled here.
|
|
9
9
|
|
|
10
10
|
## Adopted
|
|
11
11
|
|
|
@@ -37,6 +37,6 @@ None of the three is one, and each earns its keep on access and cost instead. A
|
|
|
37
37
|
|
|
38
38
|
## Stated by no source
|
|
39
39
|
|
|
40
|
-
**Naming the field and deriving its authorities.** No comparable skill takes a thinking step before searching. The step rests on
|
|
40
|
+
**Naming the field and deriving its authorities.** No comparable skill takes a thinking step before searching. The step rests on paired open and scoped searches, where the scoped run returned primary sources and caught a wrong version number the open run carried.
|
|
41
41
|
|
|
42
42
|
**Preferring a public API over a fetched page.** It rests on the same probes, where the scholarly and reference APIs returned the dates, authors, and identifiers a citation needs and a fetched page returned a summary.
|
|
@@ -7,36 +7,26 @@ description: Why a plain session needs a handoff surface that is not the task bo
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, a session facing a compaction reaches for `session-map`, which writes
|
|
10
|
+
Without this skill, a session facing a compaction reaches for `session-map`, which writes onto the task board in the orchestrator's shape. That shape runs a drift check against a start commit nothing records and fills a `## State` section, so a session that shipped nothing pays for both and leaves a file every board reader filters out.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
Sessions also write the wrong thing into a handoff. They restate the tree, which survives a compaction, and omit what each decision beat, which does not.
|
|
12
|
+
Sessions also write the wrong thing into a handoff. They restate the tree, which survives a compaction, and omit what each decision beat, which does not. A session about to move machines finds no surface naming the push and export it needs first.
|
|
15
13
|
|
|
16
14
|
## Must
|
|
17
15
|
|
|
18
|
-
-
|
|
19
|
-
-
|
|
20
|
-
-
|
|
21
|
-
-
|
|
22
|
-
-
|
|
16
|
+
- The note lands in `.canon/compact/`, outside the task board and outside scratch, and in a stated shape
|
|
17
|
+
- Every claim carries a citation, and every decision carries the alternative it rejected
|
|
18
|
+
- A session holding nothing a compaction would destroy gets a one-line decline rather than a padded note
|
|
19
|
+
- A caller who asked to move the session gets `canon records push` then `canon sessions export` named in the report
|
|
20
|
+
- The skill keeps a caller of its own beyond an operator typing it, being the `PreCompact` hook naming it on a manual compaction
|
|
23
21
|
|
|
24
22
|
## Must not
|
|
25
23
|
|
|
26
|
-
- Write a task row, a plan, or anything under `.canon/tasks
|
|
27
|
-
- Write a `## State` section, or any section a reader could fill from `git status
|
|
28
|
-
- Run a drift check or recover a start commit
|
|
29
|
-
- Lose its caller. The `PreCompact` hook names this skill on a manual compaction, and that hook plus an operator typing it are the two callers the third creation question asks for. A hook edit that names another skill leaves one caller, which is a reason to revisit this skill rather than to keep it.
|
|
30
|
-
|
|
31
|
-
## Guards
|
|
32
|
-
|
|
33
|
-
- No repository is required. The slug comes from the work, so a session outside git still writes a note.
|
|
34
|
-
- `.canon/` resolves at the main worktree root. From a linked worktree the write goes through the shell, since the file-editing tools refuse that path.
|
|
35
|
-
- Decline rather than pad. A note a reader finds is a note a reader trusts.
|
|
36
|
-
- The note is backed up by `canon records push`, which carries every top-level `.canon/` folder, and the push is a run someone makes. Until it runs, or where no remote is configured, the note sits on one disk. The skill's report does not say so on an ordinary note, since it would restate a run the operator owns on every note. A caller who named a move is the exception, because the push is then the step the move depends on rather than a reminder, and the line prints on that report alone.
|
|
24
|
+
- Write a task row, a plan, or anything under `.canon/tasks/`
|
|
25
|
+
- Write a `## State` section, or any section a reader could fill from `git status`
|
|
26
|
+
- Run a drift check or recover a start commit, which belong to the role that ships code
|
|
37
27
|
|
|
38
28
|
## Out of scope
|
|
39
29
|
|
|
40
|
-
- The orchestrator's handoff
|
|
41
|
-
- Reading a handoff back
|
|
42
|
-
- A decision a groundwork track owns, which
|
|
30
|
+
- The orchestrator's handoff with its drift check and board row, which `session-map` owns
|
|
31
|
+
- Reading a handoff back, which `session-resume` owns
|
|
32
|
+
- A decision a groundwork track owns, which `plan-groundwork` owns in that track's decision file
|
|
@@ -7,44 +7,28 @@ description: Why the write procedure needs a board-side route for the orchestrat
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, the standard
|
|
10
|
+
Without this skill, the standard for the board-side handoff carries a full write procedure and nothing routes a session to it, though the resume path reads the newest map first. The only other routed writer is the orchestrator role, which hands a plain session a section it cannot fill.
|
|
11
11
|
|
|
12
|
-
The
|
|
13
|
-
|
|
14
|
-
The drift step is the one most specific to session length and the easiest to skip. It reads the commit the session started from, nothing on the machine records that commit, and a route that names the step without naming how to recover the ref ships an instruction nobody can follow.
|
|
15
|
-
|
|
16
|
-
A step that reads a surface a project may not carry gets skipped on the reasoning that it has nothing to act on. A cold session run against a project with no `.claude/` tree skipped the drift step and wrote its own rationale into the map, so the step the route exists to carry did not run on the first test from outside. The skip is worst where it looks most defensible, and a session that takes it quietly leaves a map indistinguishable from a conforming one.
|
|
17
|
-
|
|
18
|
-
A body that restates the sections, the frontmatter, or the numbered steps becomes a second source that drifts from the standard, which is the failure the split between the role writer and the core was made to remove rather than move.
|
|
12
|
+
The drift step reads a start commit nothing on the machine records, so naming the step without its recovery ships an instruction nobody can follow. Where the step's surface is missing, a session skips it as having nothing to act on and leaves a map that looks conforming. A body restating the standard drifts from it.
|
|
19
13
|
|
|
20
14
|
## Must
|
|
21
15
|
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
- Fall back to the branchless filename on an empty slug rather than stopping
|
|
28
|
-
- Leave model invocation enabled, so a session that has dropped its routing still reaches this by description
|
|
16
|
+
- An orchestrating session, or a request naming the session map or the board, reaches the write without the skill asserting a role the session does not hold
|
|
17
|
+
- The filename, frontmatter, sections, numbered steps, and citation rule come from the standard by citation, never restated
|
|
18
|
+
- The drift step runs, its start ref is recovered from how long the session has run, and what the verb names or refuses is recorded as the boundary of what it read
|
|
19
|
+
- The file lands whole at the main worktree root, through the shell where the editing tools refuse that root, under the branchless filename when the slug is empty
|
|
20
|
+
- Model invocation stays enabled, so a session that has dropped its routing still reaches the write by description
|
|
29
21
|
|
|
30
22
|
## Must not
|
|
31
23
|
|
|
32
|
-
- Restate the standard's sections, frontmatter, or numbered steps
|
|
33
24
|
- Skip a step by predicting what its skill or verb would have answered, rather than running it and recording what came back
|
|
34
|
-
-
|
|
25
|
+
- Add a role's section to a map written by a session holding no such role
|
|
35
26
|
- Take the worktree-local copy the editing tools offer in place of the main-root path
|
|
36
|
-
- Summarize the board, the task files, or the work
|
|
37
|
-
|
|
38
|
-
## Guards
|
|
39
|
-
|
|
40
|
-
- Not a git repository: stop, since the filename comes from the branch
|
|
41
|
-
- Empty slug: fall back rather than stop, since the reasoning is worth more than the name
|
|
42
|
-
- The drift verb refusing: record the boundary under standing cautions and keep writing
|
|
27
|
+
- Summarize the board, the task files, or the shipped work, each of which survives a compaction on its own
|
|
28
|
+
- Write a map outside a git repository, since the filename comes from the branch
|
|
43
29
|
|
|
44
30
|
## Out of scope
|
|
45
31
|
|
|
46
|
-
- The
|
|
47
|
-
- Reading a handoff back at the start of the next session
|
|
48
|
-
- The sections
|
|
49
|
-
- Validating a written map against the standard, which no record kind covers, so a conforming shape rests on the standard being followed
|
|
50
|
-
- Firing the write without being asked, which is a question about what the harness supports and is measured on its own track
|
|
32
|
+
- The note a plain session writes before a compaction, outside the board and with no drift step, which `session-compact` owns
|
|
33
|
+
- Reading a handoff back at the start of the next session, which `session-resume` owns
|
|
34
|
+
- The orchestrator's sections over the core three, which `role-orchestrator` owns
|
|
@@ -1,76 +1,32 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: session-relay
|
|
3
|
-
description: Why
|
|
3
|
+
description: Why sending to another session is one skill any session reaches, why it resolves the address and names the sender, and why the message body and the addressee stay with the caller
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Session relay requirement
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, every session that owes another session a
|
|
11
|
-
the addressee itself. `role-worker` and `role-planner` each state the messages
|
|
12
|
-
owed and each carried the resolution inline, and a session holding neither role
|
|
13
|
-
carried it nowhere, so the mechanical half of the send existed in two copies
|
|
14
|
-
plus however many a roleless caller improvised.
|
|
10
|
+
Without this skill, every session that owes another a message resolves the addressee itself, so one protocol lives in each role body and in whatever a roleless session improvises, and a fix reaching one copy misses the rest. A skill matched only by request never fires, so firing rests on the pointer in each role's channel section.
|
|
15
11
|
|
|
16
|
-
A
|
|
17
|
-
on no condition of its own, since nothing routes a session to a skill matching
|
|
18
|
-
no request and reaching for no artifact, so a skill built to close the gap never
|
|
19
|
-
closed it. That history is why the pointer inside each role's
|
|
20
|
-
`## The channel` section still matters: it is a section both bodies read at
|
|
21
|
-
session start rather than one reached by request match alone, and it is what
|
|
22
|
-
makes the firing survive.
|
|
23
|
-
|
|
24
|
-
The first draft of this plan closed the gap with a paragraph drafted inline,
|
|
25
|
-
once inside `role-worker` and once inside `role-planner`. The operator overrode
|
|
26
|
-
that call: two bodies carrying identical protocol text is the shared-surface
|
|
27
|
-
case, since a later
|
|
28
|
-
fix reaching one copy and not the other diverges silently.
|
|
29
|
-
|
|
30
|
-
Neither attempt named who the relay is from. A message an operator relays by
|
|
31
|
-
hand needs a sender as much as an addressee, and the standalone draft and the
|
|
32
|
-
inline draft both composed a body and an addressee with no line stating whose
|
|
33
|
-
turn produced it.
|
|
34
|
-
|
|
35
|
-
Scoping the skill to a session holding a role and no send tool left two holes
|
|
36
|
-
rather than one. A session holding neither role had no `## The channel` section
|
|
37
|
-
to carry the pointer and was refused outright on arrival. A session that held a
|
|
38
|
-
role and a send tool was refused too, which left the resolution ladder
|
|
39
|
-
duplicated in both role bodies for the ordinary case. Both guards came off
|
|
40
|
-
together, since the mechanics are the same whichever route carries the text.
|
|
41
|
-
|
|
42
|
-
No governance rule carries the addressing or the reason for the order, so this
|
|
43
|
-
body is the only surface stating either for a session holding neither role. A
|
|
44
|
-
project that installs governance without the plugin therefore gets no surface
|
|
45
|
-
telling a roleless session to send before it prompts, a cost the operator
|
|
46
|
-
accepted over a rule loading into every session of every governed target.
|
|
12
|
+
A relayed message carries no sender, so an operator cannot say whose turn produced it. A name prefix can resolve to the wrong session and still report success. A send to another repository's session, or from a sender with no roster row, lands where nobody asked for it. Nothing else tells a roleless session why a block goes before a prompt.
|
|
47
13
|
|
|
48
14
|
## Must
|
|
49
15
|
|
|
50
|
-
-
|
|
51
|
-
-
|
|
52
|
-
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
- State why a block goes out before a prompt as the only surface carrying that reason, since no rule carries it and a caller restating the reason drifts from this body with nothing comparing them, while each caller still states that the message is owed
|
|
56
|
-
- Carry the message body verbatim from whatever names it
|
|
57
|
-
- Open the composed text with a header naming the sender, the addressee, and what the message is
|
|
58
|
-
- State the header as a default a session may write around, rather than a fixed vocabulary
|
|
16
|
+
- Any session sending to another reaches the skill, with or without a role or a send tool, and a send to a row in another repository is refused unless the caller names the operator's ask
|
|
17
|
+
- The sender's name comes from `canon sessions list --self --json`, degrading to a name from the environment when the installed CLI lacks `--self`, and a sender with no roster row reads as unread
|
|
18
|
+
- The addressee resolves from a `sessionId` or a branch at the moment of sending, never by name prefix, and is checked against the agent listing with its `[ref]` added under more than one row
|
|
19
|
+
- The send goes through a message-sending tool where one exists, and a copyable block opening on a sender, addressee, and purpose header is composed where none does or the listing has no row
|
|
20
|
+
- The body carries the message verbatim from its caller, and states why a block goes out before a prompt as the one surface holding that reason
|
|
59
21
|
|
|
60
22
|
## Must not
|
|
61
23
|
|
|
62
|
-
- Draft a message body of its own
|
|
63
|
-
- Decide who the message goes to
|
|
64
|
-
- Restate the last-rung inference
|
|
65
|
-
|
|
66
|
-
## Guards
|
|
67
|
-
|
|
68
|
-
- The roster cannot name the sender: report the refusal and its reason in place of a name
|
|
69
|
-
- The resolution returns no row: report it rather than guessing, since the roster and the send channel enumerate different populations in both directions
|
|
70
|
-
- The caller named no addressee at all: defer to the calling role's own last rung, and ask the operator where one is present
|
|
24
|
+
- Draft a message body of its own
|
|
25
|
+
- Decide who the message goes to, or guess an addressee when the resolution returns no row
|
|
26
|
+
- Restate the last-rung inference the role bodies each carry
|
|
71
27
|
|
|
72
28
|
## Out of scope
|
|
73
29
|
|
|
74
|
-
- Which messages are owed and when, which
|
|
75
|
-
- The last-rung inference, which
|
|
76
|
-
-
|
|
30
|
+
- Which messages are owed and when, which the calling role or the dispatch owns
|
|
31
|
+
- The last-rung inference for a worker, which `role-worker` owns because a worker holds a feature branch
|
|
32
|
+
- The last-rung inference for a planner, which `role-planner` owns because a planner holds none
|
|
@@ -34,6 +34,12 @@ The caller names the addressee as a `sessionId` or a branch, never as a name. A
|
|
|
34
34
|
- From a `sessionId`: run `canon sessions list --json`, find the row carrying that id, and take the `name` on it
|
|
35
35
|
- From a branch: take the row whose `branch` matches. Nothing renames a session when it takes a role, so an id is the stronger key and a branch the fallback.
|
|
36
36
|
|
|
37
|
+
### Refuse another repository
|
|
38
|
+
|
|
39
|
+
Refuse a send to a row whose `repository` differs from the sender's own, unless the caller names the operator's ask. Read the sender's repository from the Step 1 row and report the refusal with both paths.
|
|
40
|
+
|
|
41
|
+
When Step 1 returned no row, the sender's repository is unread, so the comparison cannot run. Report it as unread and send only when the caller names the operator's ask.
|
|
42
|
+
|
|
37
43
|
### Check the name against the agent listing
|
|
38
44
|
|
|
39
45
|
A name is not unique, and the roster carries no field separating two live sessions holding one. Check the name against the agent listing before sending.
|
|
@@ -7,41 +7,27 @@ description: Why resuming reads the handoff before the board, reads an index bef
|
|
|
7
7
|
|
|
8
8
|
## Gap
|
|
9
9
|
|
|
10
|
-
Without this skill, a session picking up old work
|
|
10
|
+
Without this skill, a session picking up old work rebuilds state from the git log, which records what shipped rather than what is queued. Reading every task file spends the context the work needs before it starts. A resume reading only the board walks past the handoff written to survive the compaction.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
The task index is a folder catalog rather than a task filter, so it carries a row for the ordering file and one for every handoff on the board. A session reporting each row as a backlog item queues work nobody filed, and the count grows with every session that ever wrote a handoff.
|
|
15
|
-
|
|
16
|
-
From a linked worktree the shared scratch folders resolve against the worktree rather than the main root, where they are empty. That reports no tracked work on a repository carrying a full backlog, and the report is indistinguishable from the true empty case.
|
|
17
|
-
|
|
18
|
-
A resume is a read, and a session that treats it as a cleanup pass offers to archive finished entries or rewrite a plan it decided was stale. Both change tracked state on the strength of a summary the user has not confirmed yet.
|
|
12
|
+
The task index catalogs the folder rather than filtering it, so its rows include the ordering file and every handoff. From a linked worktree the scratch folders resolve empty, which reads as no tracked work. A resume treated as cleanup offers to archive entries on a summary nobody confirmed.
|
|
19
13
|
|
|
20
14
|
## Must
|
|
21
15
|
|
|
22
|
-
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
- Close with one recommendation naming the first item and whether a plan backs it
|
|
16
|
+
- The newest handoff is read before the board and reported under its writer's name, its counts and sizes framed as true when written
|
|
17
|
+
- The handoff, plans, and tasks folders resolve at the main worktree root
|
|
18
|
+
- The index is read before any task file, its board siblings dropped, its order kept as the priority, and only the task files the summary needs opened
|
|
19
|
+
- The report closes on one recommendation naming the first item and whether a plan backs it, or what a handoff leaves open beside an empty board
|
|
20
|
+
- Every surface absent or empty reports no tracked work and stops
|
|
28
21
|
|
|
29
22
|
## Must not
|
|
30
23
|
|
|
31
24
|
- Read the whole tasks folder to build a summary
|
|
32
|
-
- Report
|
|
33
|
-
-
|
|
34
|
-
-
|
|
35
|
-
|
|
36
|
-
## Guards
|
|
37
|
-
|
|
38
|
-
- Every surface absent or empty reports no tracked work and stops, rather than inventing a next step from the repository
|
|
39
|
-
- A handoff found beside an empty board recommends what the handoff leaves open, since the guard passes on the handoff alone and the recommendation has no backlog item to name
|
|
25
|
+
- Report that no handoff exists, which is the common case and trains a reader to skip the line
|
|
26
|
+
- Offer to remove, archive, or reorder an entry, since a resume reports and does not mutate
|
|
27
|
+
- Invent a next step from the repository when the board is empty
|
|
40
28
|
|
|
41
29
|
## Out of scope
|
|
42
30
|
|
|
43
|
-
- Writing a handoff, which
|
|
44
|
-
-
|
|
45
|
-
-
|
|
46
|
-
- Marking an outcome, which `task-complete` does when the work ships, and archiving a plan, which the merge does
|
|
47
|
-
- Implementing the item it recommends, which is the next request rather than part of this one
|
|
31
|
+
- Writing a plain session's handoff, which `session-compact` owns
|
|
32
|
+
- Writing the board-side map, which `session-map` owns
|
|
33
|
+
- Marking an outcome or archiving a shipped task, which `task-complete` owns
|