@erclx/canon 5.74.0 → 5.76.0

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # Changelog
 
+## [5.76.0](https://github.com/erclx/canon/compare/v5.75.0...v5.76.0) (2026-10-31)
+
+
+### Features
+
+* **capture:** render light and dark social cards in design-identity ([#2861](https://github.com/erclx/canon/issues/2861)) ([de990f5](https://github.com/erclx/canon/commit/de990f543f7970c04548aa4f793766db5d87b68a))
+* **claude:** allow the exact lease push forms in seeded settings ([#2859](https://github.com/erclx/canon/issues/2859)) ([2f5a6e8](https://github.com/erclx/canon/commit/2f5a6e801e51cefef98f46a7b33b1cd6df7717a3))
+* **orchestrate:** run the review poll in the background until movement ([#2860](https://github.com/erclx/canon/issues/2860)) ([28101da](https://github.com/erclx/canon/commit/28101da96a8ad19e8ded474fad0de15344f4ac41))
+* **skills:** add issue-triage for a repository's open GitHub issues ([#2856](https://github.com/erclx/canon/issues/2856)) ([910372f](https://github.com/erclx/canon/commit/910372fe7026b9e3f5e2b17648a86dd685081acf))
+* **skills:** offer a follow-up on a duplicate issue before filing ([#2857](https://github.com/erclx/canon/issues/2857)) ([ddcbf69](https://github.com/erclx/canon/commit/ddcbf69d5c7cb60242b3d7b0bfb23ffbd4fd858e))
+
+## [5.75.0](https://github.com/erclx/canon/compare/v5.74.0...v5.75.0) (2026-10-29)
+
+
+### Features
+
+* **claude:** audit proposal-critique against its ledger ([#2845](https://github.com/erclx/canon/issues/2845)) ([397699b](https://github.com/erclx/canon/commit/397699bdeb7da47a39fb210d2850e8502d503a1f))
+* **claude:** seed the plan guard and wire installed projects ([#2851](https://github.com/erclx/canon/issues/2851)) ([e312aab](https://github.com/erclx/canon/commit/e312aabaa69941ce01f656a635b98ef9e01680f1))
+* **gov:** check a project's ledgers under canon/ledger/ ([#2848](https://github.com/erclx/canon/issues/2848)) ([65fb0e6](https://github.com/erclx/canon/commit/65fb0e6e60ef22c16a7743964865fc62d6b55ed8))
+* **governance:** route a rule edit to create-rule ([#2847](https://github.com/erclx/canon/issues/2847)) ([010b639](https://github.com/erclx/canon/commit/010b63970a874905ec9ee3db520b7cb5f96db778))
+* **take:** refuse a take past --max-seconds as over-cap ([#2855](https://github.com/erclx/canon/issues/2855)) ([d9d6424](https://github.com/erclx/canon/commit/d9d642434d082f9f7d4b1508723576044e55f6a4))
+
+
+### Bug Fixes
+
+* **take:** cut a screencast clip at the stage clock ([#2853](https://github.com/erclx/canon/issues/2853)) ([3588832](https://github.com/erclx/canon/commit/3588832a8263079ff8340b2cf7af3c492bf4cc66))
+* **take:** hold canon take steady on a page whose frames run slow ([#2852](https://github.com/erclx/canon/issues/2852)) ([f2b55f9](https://github.com/erclx/canon/commit/f2b55f9a2f948c46fb4c84720da7596df31107a5))
+* **take:** scroll a target taller than the window ([#2854](https://github.com/erclx/canon/issues/2854)) ([976b85d](https://github.com/erclx/canon/commit/976b85d27391106d2cb7e03072451de5a128d2fd))
+
 ## [5.74.0](https://github.com/erclx/canon/compare/v5.73.0...v5.74.0) (2026-10-28)
 
 

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

@@ -1,7 +1,7 @@
 {
   "name": "canon",
   "description": "Runs your agent's work and keeps its code good, on one setup for every repo.",
-  "version": "5.74.0",
+  "version": "5.76.0",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/create-rule/SKILL.md

@@ -86,6 +86,10 @@ Read `${CLAUDE_SKILL_DIR}/references/checklist.md` and run every bullet of the w
 
 ## After writing
 
-Emit the full path on its own line: `.claude/rules/project/<subdir>/<slug>.md`. Remind the user that Claude Code loads path-scoped rules when it reads or writes a matching file, and always-on rules every session. When a bullet claims outside practice, tell them to cite its source in the commit that adds the rule.
+Emit the full path on its own line: `.claude/rules/project/<subdir>/<slug>.md`. Remind the user that Claude Code loads path-scoped rules when it reads or writes a matching file, and always-on rules every session. When a bullet claims outside practice, tell them to cite its source, in a ledger or in the commit that adds the rule.
 
 Show the new rule as a diff in chat and commit nothing until the operator says OK.
+
+### When a bullet cites outside practice
+
+Offer to record each source in a ledger at `canon/ledger/rules/<subdir>/<slug>.md`, which `canon gov audit` checks row for bullet. Read `${CLAUDE_SKILL_DIR}/references/ledger.md` for the layout and the row shape before writing one.

package/claude/skills/create-rule/references/ledger.md

@@ -0,0 +1,73 @@
+---
+title: Project ledger reference
+description: Where a project's rule and skill ledgers live under canon/ledger/, and the row shape both audits check, one table per H2 and one row per bullet
+---
+
+# Project ledger reference
+
+## Contents
+
+- [Overview](#overview)
+- [Where it lives](#where-it-lives)
+- [Shape](#shape)
+- [Rows](#rows)
+- [Example](#example)
+
+## Overview
+
+A ledger names what stands behind each bullet of a rule or a skill file, kept beside the file rather than inside it, so the reasoning costs no load. A bullet claiming outside practice names its source, and a bullet recording a project decision names what it prevents.
+
+A project writes a ledger where it wants one and owes none. `canon gov audit` and `canon claude skills audit` check each ledger that exists against its file and report a ledger whose file is gone.
+
+## Where it lives
+
+Every ledger sits under `canon/ledger/`, which Claude Code never loads. A ledger under `.claude/rules/` would load as a rule on every matching read.
+
+- A rule at `.claude/rules/project/<subdir>/<slug>.md` takes `canon/ledger/rules/<subdir>/<slug>.md`
+- A skill body at `.claude/skills/<skill>/SKILL.md` takes `canon/ledger/skills/<skill>/SKILL.md`
+- A skill reference at `.claude/skills/<skill>/references/<file>.md` takes `canon/ledger/skills/<skill>/<file>.md`, dropping the `references/` segment
+- Move or delete a ledger in the change that moves or deletes its file, since the audits report one left behind
+
+## Shape
+
+The audits match rows to bullets by count under a heading of the same name, so the shape is fixed and whether a row supports its bullet is a review judgment.
+
+- Write one `## <heading>` per H2 in the file, spelled as the file spells it
+- Put one table under each heading, with one row per bullet in the file's order
+- Give a file with no H2 one table under the title
+- Write no other table in the ledger, since every table row under a heading counts. A sample table inside a code fence is not counted.
+
+A skill file counts a few lines differently from a rule.
+
+- Give each top-level ordered step a row, the way a bullet takes one
+- Give `## Contents` no table, since it repeats the headings
+- Stop a `SKILL.md` ledger's tables at the body's first closing section, such as `## Excuses and rebuttals` or `## What this delegates`, since a table under one reads as rows with no bullets
+
+## Rows
+
+Each row names the bullet and the one thing behind it.
+
+- **Sourced:** a link to the primary source, with the line it says, such as the framework's own docs or the language spec
+- **House choice:** a cell opening `House choice:` and naming the bug class the bullet prevents, when no outside source takes a side
+- **Decision:** a house choice naming what the bullet prevents and the option it beat, with the date it was decided
+- Cut a bullet that has neither a source nor a bug class behind it, rather than writing a row that says so
+
+## Example
+
+A project React rule in the `framework/` subdir, with two bullets under `## Component patterns`, takes this ledger at `canon/ledger/rules/framework/react.md`:
+
+```markdown
+---
+title: React rule ledger
+description: Sources for the project React rule, one row per bullet
+---
+
+# React rule ledger
+
+## Component patterns
+
+| Bullet                       | Source                                                                                        |
+| ---------------------------- | --------------------------------------------------------------------------------------------- |
+| Stable keys over array index | [Rendering lists](https://react.dev/learn/rendering-lists): index keys cause subtle bugs      |
+| Named exports                | House choice: a default export renamed at import drifts from the component's name in a search |
+```

package/claude/skills/create-rule/references/rule.md

@@ -101,7 +101,7 @@ A bullet claiming outside practice, such as a language idiom or a library's corr
 
 - Cite the source in the commit that adds the rule, naming a primary page or the bug class the bullet prevents
 - Cut a bullet that has neither a source nor a bug class behind it
-- The toolkit holds its outside-practice rules to a source ledger kept outside the installed tree, so the citation costs no load
+- A project can hold its rules to a source ledger kept outside the installed tree, so the citation costs no load, laid out in `${CLAUDE_SKILL_DIR}/references/ledger.md`
 - A bullet resting on how Claude Code behaves ends with a `Revisit when` sentence, per `### Phrasing`
 
 ## Location

package/claude/skills/create-skill/references/skill-practice.md

@@ -73,4 +73,4 @@ The audit counts a few lines in a ledgered file apart from a rule's.
 - It keeps a wider ledger list beside it, adding the skills that teach a craft drawn from outside sources without a practice's closing shape
 - A skill on the wider list alone owes the ledger and none of the three sections
 - Never mark a skill as a practice skill in its own frontmatter, since a self-declared kind lets a skill exempt itself.
-- Both lists name this toolkit's shipped skills alone, so a project's own practice skill takes this shape with no check behind it.
+- Both lists name this toolkit's shipped skills alone. A project's own skill owes no ledger, and one it writes is checked per `${CLAUDE_SKILL_DIR}/../create-rule/references/ledger.md`.

package/claude/skills/design-identity/REQUIREMENT.md

@@ -17,7 +17,7 @@ A session building this alone restates the render-and-pick loop from scratch, wh
 - Every arm is drafted inside the card frame, so one pick settles the mark's shape and its composition together
 - The render, hand-off, pick, and loop follow `design-pick` rather than a copy of it
 - The final mark lands as its own SVG source, not only baked into a raster
-- Every final size and the card render in one capture call, each landing at its literal target size
+- Every final icon size renders in one capture call and the card renders once per theme, each landing at its literal target size
 
 ## Must not
 

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

@@ -65,6 +65,7 @@ Follow `${CLAUDE_SKILL_DIR}/../design-pick/SKILL.md` Step 1, with the decision f
 - Draft each arm inside the 1200x630 card frame, mark and type together, and add it with `frameboard frame add <page>/arm-<id> --width 1200 --height 630`, so one pick settles shape and composition
 - Arm 0 is the current mark when the Step 3 folder already holds a logo file (`favicon.svg`, `favicon.ico`, `logo.svg`, or similar). Arms start at 1 otherwise.
 - Structure every arm as a `.mark` element, the inline SVG alone, nested inside a `.card` element, the full composition, so Step 6 can address either
+- Give every arm a light and a dark set keyed on the `data-theme` attribute, as `design-pick` themes any arm. Step 7 captures the picked card once per theme.
 
 ## Step 5: draft, render, pick, and loop
 
@@ -94,6 +95,11 @@ The card leaves this batch and takes Step 7 instead. An icon is the mark alone a
 
 A card captured from a page this run deletes leaves a PNG and nothing that produced it, so renaming the project means another pick loop to move one string. Write the composition into a route the project keeps, and capture it through a running server so it reads the real stylesheet, tokens, and fonts.
 
+Both paths write two cards, each captured with `--color-scheme` set to its theme. An `og:image` tag names one URL that every viewer sees whatever their own theme, so only one is wired:
+
+- `og-image.png`, the light card, goes into `og:image`, keeping the name an existing tag already points at
+- `og-image-dark.png` stays beside it, so a later switch is a meta tag edit rather than another pick loop
+
 This is Astro-shaped for now, because Astro is the one web stack whose config gives a route a structural build exclusion. A project already holding the card route scaffold takes the route path, and everything else takes the page path. Say which one decided, since the two leave the project different things.
 
 ### The route path
@@ -102,17 +108,18 @@ Read `${CLAUDE_SKILL_DIR}/references/card-route.md` on reaching this path, for t
 
 ### The page path
 
-Where the project holds no route to write into, write `og-image.html` into `<dest>/render/` with its `.render` wrapper sized 600x315, then capture that one page:
+Where the project holds no route to write into, write the picked composition into `<dest>/card/` twice, as `og-image.html` and `og-image-dark.html`, each with its `.render` wrapper sized 600x315. A file source names its PNG after the page, so the two names are what land the two cards. Capture each page in its own theme:
 
 ```bash
-canon capture <dest>/render/og-image.html --selector .render --out <write-folder>
+canon capture <dest>/card/og-image.html --selector .render --color-scheme light --out <write-folder>
+canon capture <dest>/card/og-image-dark.html --selector .render --color-scheme dark --out <write-folder>
 ```
 
-It takes its own call because Step 6's batch is already captured by the time this step picks a path. Say that the card shipped as a PNG with no source, and that the project gains one when it grows a route to hold the composition.
+These take their own calls because Step 6's batch is already captured by the time this step picks a path, and one call renders one scheme. Say that the card shipped as a PNG with no source, and that the project gains one when it grows a route to hold the composition.
 
 ### Closing the scratch folder and the board
 
-Delete `<dest>` once both captures land, then close the board through `design-pick` Step 6 items 3 to 8, which archive every arm and delete the pages the run added. The route is not a leftover variant, since it holds the arm the operator picked.
+Delete `<dest>` once the icon and card captures land, then close the board through `design-pick` Step 6 items 3 to 8, which archive every arm and delete the pages the run added. The route is not a leftover variant, since it holds the arm the operator picked.
 
 A project whose card was generated before this route existed keeps its PNG. Say so rather than regenerating it, since the pick loop spends attention on a file nobody complained about, and the next real edit picks up the route.
 
@@ -123,9 +130,11 @@ A project whose card was generated before this route existed keeps its PNG. Say
 📝 Wrote <write-folder>/icon-16x16.png (16x16)
 📝 Wrote card-src/pages/og-card.astro (route path only)
 📝 Wrote <write-folder>/og-image.png (1200x630)
+📝 Wrote <write-folder>/og-image-dark.png (1200x630)
 
 Write folder: <tier that decided>. Move the files if this project's own convention differs.
 Card source: <the route, captured through the card server|a scratch page, since this project holds no card route>.
+Wire og-image.png into og:image. The dark card stays beside it for a later switch.
 ```
 
 ## What this delegates

package/claude/skills/design-identity/references/card-route.md

@@ -29,16 +29,23 @@ Never run that sync to obtain the route, since it writes the stack's configs bes
 
 ## Writing and capturing the route
 
-1. Write the picked arm's `.card` markup into the route's `.card` element, leaving the marker, the stylesheet import, and the surrounding document alone.
+1. Write the arm's `.card` markup into the route's `.card` and its `[data-theme]` rules into the route's `<style>`, leaving the rest of the route alone.
 2. Keep the element at 600x315, half the 1200x630 target, since the capture's 2x scale factor is fixed and a 1200x630 element captures at 2400x1260.
 3. Start the card server in the background with `bun run card:dev` and read the port off its own output.
-4. Capture the route, naming the destination PNG rather than a directory, which is what a URL source takes for `--out`.
-5. Stop the server. Report the dimensions `canon capture` printed, confirming 1200x630.
+4. Capture the route twice while the server is up, once per theme, naming each destination PNG rather than a directory, which is what a URL source takes for `--out`.
+5. Stop the server. Report the dimensions `canon capture` printed for both cards, confirming 1200x630.
 
 ```bash
-canon capture http://localhost:<port>/og-card --selector .card --out <write-folder>/og-image.png
+canon capture http://localhost:<port>/og-card --selector .card --color-scheme light --out <write-folder>/og-image.png
+canon capture http://localhost:<port>/og-card --selector .card --color-scheme dark --out <write-folder>/og-image-dark.png
 ```
 
+The two captures differ only where something keys a second theme:
+
+- The scaffold's `.card` reads two color properties a stylesheet may set for one theme only, so the arm's rules from step 1 give the dark capture its dark set
+- `--color-scheme` writes the theme onto the route's root after it loads, so rules keyed on `data-theme`, a class, or the media query all answer to it
+- With no second set in the arm or the stylesheet, the PNGs match. Compare the image digests in their `.stamp` files, and on a match say the project got one card twice.
+
 ### Port and font refusals
 
 The card server runs under a strict port, so it refuses rather than walking to the next free one. Where something already holds that port, set `WORKTREE_PORT_OFFSET` by hand and start it again.

package/claude/skills/git-issue/REQUIREMENT.md

@@ -17,16 +17,18 @@ Prose bans hold on files the hook watches and not on text leaving through `gh`,
 - Each issue carries exactly one label mapped from its type, asked once when the type is ambiguous between a bug and a task
 - A remote and an authenticated `gh` are confirmed before any body is composed
 - The body passes through a file that is removed afterward
+- Open issues are searched for the same defect before a body is composed, and a match is offered as a comment in place of a new issue
 
 ## Must not
 
 - Invent an issue from a thin session
 - File anywhere other than the current origin
 - Open a pull request
-- Emit anything after the result line
+- Emit anything after the result lines
+- Comment on an existing issue without a yes given for that issue
 
 ## Out of scope
 
 - Reporting a toolkit defect from a target project, which `canon-feedback` owns
-- Triaging the toolkit's feedback issues, which its maintainers do in its own repository
+- Triaging a repository's open issues, which `issue-triage` owns
 - Opening a pull request, which `git-pr` owns

package/claude/skills/git-issue/SKILL.md

@@ -27,7 +27,34 @@ Then gather repo context in parallel:
 - If nothing in session context describes a concrete bug or task, stop: `❌ No issue in session context. Describe the bug or task, then re-invoke.`
 - If `git remote get-url origin` returns `NO_REMOTE`, stop: `❌ No GitHub remote. gh issue create needs an origin.`
 - If `gh auth status` returns `NO_AUTH`, stop: `❌ gh is not authenticated. Run gh auth login.`
-- If the type is ambiguous between a bug and a task, ask one line before formatting.
+- If the type is ambiguous between a bug and a task, ask one line before formatting, after the duplicate question below.
+
+## Duplicate check
+
+Search the open issues before composing anything, since a duplicate costs the repository's triage a second item and a second answer.
+
+```bash
+gh issue list --state open --search "<keywords> in:title,body" --limit 5 --json number,title,url
+```
+
+- Take keywords from the defect's distinctive terms, such as a command or a path, and quote one holding a colon or a space
+- Keep a candidate only when it describes the same defect, reading its body with `gh issue view <NNN> --json body` when the title leaves it open
+- With none kept, go to the preview and file a new issue
+- With one or more kept, ask once whether to add the findings to one of them as a comment or file a new issue, naming each by number and title
+- With no one to answer, as in a headless run, file nothing and name each kept candidate, since a new issue there is the duplicate this check exists to stop
+
+### Comment on the match
+
+On a yes for an issue, write the comment in the `### Follow-up` shape `${CLAUDE_SKILL_DIR}/references/issue.md` gives, run the pre-publish scan below over it, then post it in place of the final command. Post nothing on any issue the answer did not name.
+
+```bash
+mkdir -p .canon/tmp/issue
+cat <<'BODY' > .canon/tmp/issue/comment.md
+<comment following the Follow-up section>
+BODY
+gh api -X POST 'repos/{owner}/{repo}/issues/<NNN>/comments' -F body=@.canon/tmp/issue/comment.md --jq .html_url
+rm -rf .canon/tmp/issue
+```
 
 ## Response format
 
@@ -63,6 +90,8 @@ rm -rf .canon/tmp/issue
 
 ## After execution
 
-Respond with exactly one line and add no other text:
+Respond with the one line for what was posted:
 
-`✅ Issue: <url>`
+- A new issue: `✅ Issue: <url>`
+- A comment on a match: `✅ Commented: <url>`
+- Nothing, with candidates kept and nobody to ask: `⏸️ Not filed. Possible duplicate:`, then one line per candidate as `#<NNN> <title>`

package/claude/skills/git-issue/references/issue.md

@@ -55,6 +55,13 @@ A bug or task body carries up to four `##` sections, in this order.
 - `## Context`: for a bug, repro steps or commands. For a task, the driving reason, or `none`.
 - `## Proposed` (optional): one line naming a fix or approach. Omit when open.
 
+### Follow-up
+
+A comment on an open issue carries what the session adds and nothing the issue already says.
+
+- `## Follow-up`: one line naming what is new, such as a second instance, a repro, or a narrowed cause.
+- `## Details`: the observed behavior and the command or path that shows it.
+
 ### Feedback
 
 One `## Toolkit feedback` wrapper holds every field as a nested `###` heading. A flat `##` field is not recognized.

package/claude/skills/issue-triage/REQUIREMENT.md

@@ -0,0 +1,35 @@
+---
+name: issue-triage
+description: Why a repository's open issues are filed as measured intake items rather than routed or fixed from the issue text, and why one pass is capped
+---
+
+# Issue triage requirement
+
+## Gap
+
+Without this skill, a repository's issue queue fills and nothing drains it into decisions. An issue reads as a request, so a session routes it straight to a fix from a paragraph and skips the scope argument.
+
+Triage done by hand fails three ways. A self-contradicting report gets a guess instead of a question. The same issue gets filed twice because two passes cannot see the board carries it. A queue of hundreds files in one pass that no answering session can get through.
+
+## Must
+
+- Read the queue through the `gh` CLI, and stop when it is absent, unauthenticated, or the checkout has no GitHub repository
+- File one measured item per kept issue into a folder the CLI claimed, headed so an answer finds its issue, and name each skipped issue with its carrier
+- Measure each claim in an issue's body and comments against the tree rather than carrying the issue's figures forward
+- Cap one pass, oldest first, and name what was left over rather than reading a capped queue as drained
+- Report an empty queue as nothing open rather than widening the label to find work
+
+## Must not
+
+- Post to the remote, whether a comment, a close, or a label
+- Implement a fix or write a plan
+- Fill an answer slot, or read an empty one as agreement
+- Write outside the folder it claimed
+- Carry a step only one repository's queue needs, such as stripping a reporting project's specifics, since a caller wrapping this skill adds those around it
+
+## Out of scope
+
+- Opening a new issue, which `git-issue` owns
+- Answering the filed items, which `plan-intake-answer` owns
+- Writing the plan a plan-worthy item needs, which `plan-feature` owns
+- Pruning the task backlog, which `backlog-triage` owns

package/claude/skills/issue-triage/SKILL.md

@@ -0,0 +1,130 @@
+---
+name: issue-triage
+description: Files the open GitHub issues on the current repository into an intake folder as one measured item each, narrowed by an optional label, capped per pass, and skipping any issue the board already carries. Use when asked to "triage the issues", "work through the open issues", "file the GitHub issues", "triage the bug label", or "what issues are open". Do NOT use to open a new issue, which is `git-issue`, to answer the filed items, which is `plan-intake-answer`, or to triage the task backlog, which is `backlog-triage`.
+metadata:
+  family: decide
+---
+
+# Issue triage
+
+An issue queue only grows while nothing reads it against the tree. This pass measures each open issue and files it as one item for the operator, who answers it before anything is built.
+
+The record is an ordinary intake folder at `.canon/intake/<nn>-<slug>-triage/`. Read `${CLAUDE_SKILL_DIR}/../plan-intake/references/intake.md` before writing any file in it, since it holds the item format, the frontmatter, the index shape, and the answer contract this skill is bound by.
+
+- Read GitHub issues and write only inside the claimed folder, posting no comment, close, or label to GitHub
+- Measure each issue against this repository, since the repository it was filed on is the one its fix lands in
+
+## Arguments
+
+Both are optional and come in either order.
+
+- A label narrows the queue to issues carrying it. With none, every open issue is in the queue and the slug is `issue`.
+- A label sets the slug too, lowercased with each run of other characters made one hyphen, so `good first issue` gives `good-first-issue`. Pass the raw label, quoted, to `--label`.
+- A number sets the cap, the most issues one pass files. With none, the cap is 25, about what one answering session gets through.
+
+## Guards
+
+- Resolve `.canon/tasks/` and `.canon/intake/` at the main worktree root, from `git worktree list --porcelain | grep -m 1 '^worktree ' | cut -d' ' -f2-`, falling back to `pwd` outside git
+- If `gh` is not on PATH, stop: `❌ gh CLI not found. Install it to read the issue queue.`
+- If `gh auth status` fails, stop: `❌ gh is not authenticated. Run gh auth login.`
+- If `gh repo view --json nameWithOwner` fails, stop: `❌ No GitHub repository here. Run from a checkout with a GitHub remote.`
+- If no open issue matches, stop: `✅ No open issues.`
+
+### Slots and records
+
+Two more guards hold through every step.
+
+- Never fill a `You:` slot, and never read an empty one as agreement. Answering runs through `plan-intake-answer` or the operator's own edit.
+- Branch on each `canon` record's `ok` and `reason` rather than on the exit code, which a shell function wrapping `canon` can flatten to zero.
+
+## Step 1: list the queue
+
+```bash
+gh issue list --state open --limit 1000 --search "sort:created-asc" --json number,title
+```
+
+Add `--label "<label>"` when one was given, and name that label in the empty-queue stop. The list carries no bodies, so a large queue costs a line per issue rather than its whole text.
+
+Sorting by creation keeps the oldest issues when the queue passes the limit. When the list returns 1000 rows, the queue may hold more, so Step 3 writes its left-over count as a floor.
+
+## Step 2: drop what the board already carries
+
+An issue is carried when its number appears in a live or archived task's `Issue:` line under `.canon/tasks/`, or in an item heading of an existing `.canon/intake/` folder, written `(#NNN)`. Search both at the main root.
+
+Set each carried issue aside with its carrier, a task path or a folder and item.
+
+- Name every one in the overview, so a re-run while an earlier folder sits unanswered files nothing twice
+- Read its comments with `gh issue view <NNN> --json comments`, and name their count and newest date beside its carrier, so a follow-up posted after the carrier was filed is seen
+- File no item for a comment on a carried issue, since an item would file the issue twice against a live task
+
+When every issue is carried, stop: `✅ Every open issue is already on the board.`
+
+## Step 3: apply the cap
+
+Sort the remaining issues by number, oldest first, and keep the first issues up to the cap, so the reports that waited longest drain first. Count the issues past the cap as left over, and name them in the overview and the output.
+
+- Give the count and the lowest number left over, so a drained queue and a capped one never read the same
+- Write the count as `at least <n>` when Step 1 hit its limit
+
+Then read each kept issue whole, since a follow-up posted as a comment is part of the report:
+
+```bash
+gh issue view <NNN> --json number,title,body,labels,comments
+```
+
+## Step 4: claim the folder
+
+Run `canon records ordinal intake <slug>-triage --claim --json` and take its `name`. The verb creates the folder in the same act, so two sessions opening at once never share one. Where the installed binary carries no such subcommand, report it and stop rather than picking an ordinal by hand.
+
+## Step 5: measure each issue
+
+For each kept issue, measure its claim against the tree during this pass, never carrying a figure from the issue forward, since it states what was true when filed.
+
+Measure each comment's claim the same way, whoever posted it, and fold it into the issue's one item rather than filing a second. When a comment contradicts the body, measure the later claim and name the comment as the source on `Problem:`.
+
+- Grep for the construct its defect names and count the sites
+- Check whether the behavior it asks for exists
+- Search the log for a commit or pull request that shipped it under another task
+- Run the issue's repro in a form that writes nothing when it is one command that works here, and say on `Problem:` what it showed
+- Mark the item `not reproduced here` when the repro needs more, per `## Repro versus groundwork` in the intake standard
+
+Classify each against this repository's own surfaces:
+
+- **Direct fix.** A size, not an answer, so it suggests `plan` and `Fix:` says a short plan covers it. One surface, one file, no architectural choice. A typo, a stale reference, a one-line correction.
+- **Plan-worthy.** Multiple files, a new module or command, a behavior change, or a cross-surface move.
+- **Needs clarification.** The observed and expected behavior conflict or the surface is unnamed. The item asks the operator for the missing detail.
+
+Name the commit the pass measured against in the overview.
+
+## Step 6: write the items
+
+Write one item per issue in the intake item format, one cluster file per domain the fix touches, numbered in read order. Head each item `### N. <defect> (#NNN)` so an answer finds its issue.
+
+- `Problem:` states what this pass measured, with the count, path, or commit behind it
+- `Fix:` states the class from Step 5 and the change it names
+- `Open:` reads `plan, ask, or decline?` on every item
+- `Suggested:` opens with exactly one of those tokens, then the reason
+- `You:` ships empty
+
+Write `00-overview.md` last, per the intake standard. It carries the counts by token, an open-questions list linking each item, the commit measured against, every issue skipped in Step 2 with its carrier, and the left-over count from Step 3. Where the pass runs out of context before the index, write `99-next-session.md` naming the last issue filed.
+
+## Output
+
+```plaintext
+📂 Opened .canon/intake/<nn>-<slug>-triage/
+
+**Filed:** <N> issues across <N> clusters, measured against <sha>
+**Skipped:** <n> already carried
+**Left over:** <n> past the cap of <cap>, from #<lowest>
+**Suggested:** <n> plan, <n> ask, <n> decline
+
+Next: /canon:plan-intake-answer to answer the `You:` slots
+```
+
+Drop the `Left over:` line when nothing was past the cap.
+
+An answered plan item promotes through `task-board` with an `Issue: #NNN` line, and the shipping pull request's `Closes #NNN` drains the queue. This skill still closes nothing. `plan-intake-answer` offers the close of a declined issue when the decline is answered, and the operator's yes posts it.
+
+## Notes
+
+- This skill files and never reimplements. `plan-intake-answer` owns the answers and `task-board` owns the task a plan item becomes.

package/claude/skills/pr-evidence/references/reel.md

@@ -62,23 +62,23 @@ Write one plan entry for each beat chosen, then skip when none was.
 
 The negative test is a judgment over the box's text. A misread box costs a weaker reel and never a wrong pass, since the still check below guards the footage and the UI reviewer drives every box regardless.
 
-Keep the whole reel at or under 12 seconds. Each beat opens and closes on a 0.6 s hold, so give each action's `wait` only what its result needs to settle.
+Keep the whole reel at or under 12 seconds, which the take below enforces. Each beat opens and closes on a 0.6 s hold, so give each action's `wait` only what its result needs to settle.
 
 ## Film the reel
 
 ```bash
-canon take <url> .canon/tmp/pr/reel/<number>/plan.json --out .canon/tmp/pr/reel/<number>/takes --reel .canon/tmp/pr/reel/<number>/reel.webp --json
+canon take <url> .canon/tmp/pr/reel/<number>/plan.json --out .canon/tmp/pr/reel/<number>/takes --reel .canon/tmp/pr/reel/<number>/reel.webp --max-seconds 12 --json
 ```
 
 Branch on the record's `reason`, never on the exit code.
 
-| Record          | Route                                                              |
-| --------------- | ------------------------------------------------------------------ |
-| No `reason`     | Sum the beats' `seconds` and continue to the stills                |
-| `reel-failed`   | Skip as `reel-failed` with the record's `message`                  |
-| Any other value | Skip under that `reason`, such as `target-missing` with its `beat` |
-
-When the beats sum past 12 seconds, drop the last beat from the plan and film once more. A second run past the cap skips as `over-cap`.
+| Record             | Route                                                                                                                                                                                                                                                              |
+| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| No `reason`        | Continue to the stills                                                                                                                                                                                                                                             |
+| `reel-failed`      | Skip as `reel-failed` with the record's `message`                                                                                                                                                                                                                  |
+| `target-offscreen` | Add a setup step that brings the target into the window, being a scroll over an element already inside it, such as a fixed header, with `dy` covering the distance, or a click on a link to it, and film once more. Skip as `target-offscreen` on a second refusal |
+| `over-cap`         | Drop `beat` and each beat after it, then film once more. Skip as `over-cap` if `beat` is first or it refuses again                                                                                                                                                 |
+| Any other value    | Skip under that `reason`, such as `target-missing` with its `beat`                                                                                                                                                                                                 |
 
 ## Check each still
 

package/claude/skills/proposal-critique/references/adopted.md

@@ -0,0 +1,44 @@
+---
+title: Adopted and declined
+description: Which designs this skill considered and dropped, and what would revive each, so a later session extends the position instead of re-deriving it
+---
+
+# Adopted and declined
+
+The skill came out of a groundwork track that measured two shipped fixes against the questions a critique would have asked. This file records the options the track dropped. A later session extending the skill adds to it rather than re-arguing an item settled here.
+
+A bullet's source is linked in its row of the toolkit's per-bullet ledger at `governance/ledger/skills/proposal-critique/`, outside the plugin, and this file links no source a row cites.
+
+## Declined
+
+Each item names the design that stays out, the reason, and what would bring it back.
+
+### A default call from every planning skill
+
+An authoring session questioning its own plan is the weak form Kahneman, Lovallo, and Sibony warn against when they ask for reviewers independent of the team that made the recommendation. The planning skills name the critique in one line for a one-way change or a fix with an unverified cause, and never call it.
+
+Revisit when a replay finds a case where the on-demand form would not have been invoked in time.
+
+### Folding it into `decision-escalate`
+
+That skill batches preference questions. Most critique questions are answered from evidence, and only the remainder goes to the operator.
+
+Revisit when critique passes show every question turning out to be preference.
+
+### Running it as a forked subagent
+
+A fork reads cold, which is the independence Kahneman, Lovallo, and Sibony ask for. It also loses the conversation, and a background fork loses the tools the operator questions need.
+
+Revisit when a critique keeps agreeing with the session that wrote the proposal.
+
+### A written critique section in the plan
+
+A plan already carries `## Risks` and `## Questions`, and its validator owns the sections. The verdict goes to chat, and the operator decides what moves into a record.
+
+Revisit when critiques are lost to compaction before anyone acts on them.
+
+## Revisit the whole design when
+
+- Replaying the chain that shipped two fixes and two or three past plans finds the on-demand form would not have been invoked in time
+- One body cannot hold questions that differ so much per record, whether plan, fix, or triage
+- A replayed case shows a cheap, reversible change still doing real harm

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

@@ -48,7 +48,7 @@ The human asks for each side of a compaction, and this skill reads the runbook.
 
 ### The poll and the parked rows
 
-The review trigger takes the same shape. `references/orchestrator-poll.md` holds the loop prompt and its condition, and `scripts/poll.ts` is what the prompt invokes. No hook starts or cancels that loop, so the condition holds only while whoever holds it applies it.
+The review trigger takes the same shape. `references/orchestrator-poll.md` holds the background start, the routing, and the condition, and `scripts/poll.ts --wait` is the command it runs. No hook starts or stops that poll, so the condition holds only while whoever holds it applies it.
 
 A board that is not moving is a third such moment. On a request to re-test the parked rows, follow `${CLAUDE_SKILL_DIR}/references/orchestrator-parked.md`, which re-tests every blocker and backlog row against the tree and plans what it clears. The refill sweep fires on a merge instead.
 

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

@@ -69,7 +69,7 @@ Settle all three steps below before the door writes, so one write carries the co
 
 Resume by loading the orchestrator skill and asking it to resume after a compaction. This repository spells that `/canon:role-orchestrator` followed by the request. Following <RESUME_RUNBOOK> reaches the same place with no skill loaded at all.
 
-That resume reads the board and stops. It restarts nothing, so the review poll is a second thing owed here, and <POLL_RUNBOOK> holds the prompt and the condition. Do not reach for `session-resume`, which reads tracked work and reports the newest map without restarting this loop.
+That resume reads the board and stops. It restarts nothing, so the review poll is a second thing owed here, and <POLL_RUNBOOK> holds the background start and the condition. Do not reach for `session-resume`, which reads tracked work and reports the newest map without restarting this poll.
 ```
 
 ### What the decisions section leaves out