runcastle 1.3.6 → 1.3.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "runcastle",
-  "version": "1.3.6",
+  "version": "1.3.10",
   "description": "Burn tickets into shipped features with Claude Code.",
   "license": "FSL-1.1-ALv2",
   "type": "module",
@@ -29,6 +29,7 @@
     "sandcastle-template"
   ],
   "dependencies": {
+    "@anthropic-ai/claude-agent-sdk": "^0.3.281",
     "@clack/prompts": "^1.1.0",
     "@hono/mcp": "0.3.1",
     "@hono/trpc-server": "0.4.2",

package/sandcastle-template/Containerfile

@@ -18,7 +18,12 @@ RUN curl -fsSL https://bun.sh/install | bash
 # Codex CLI (the second agent runtime) — authenticated at runtime via CODEX_API_KEY.
 # Installed as root, before the user switch, so it lands in the system-wide npm
 # prefix: after `USER` a global install has nowhere writable to go.
-RUN npm install -g @openai/codex
+# Pinned to the host's `codex --version`, passed in by Rebuild. The ARG sits
+# directly above its RUN on purpose: a changed version busts the cache for this
+# layer and the ones after it, and nothing before it. Empty installs latest.
+ARG CODEX_VERSION
+RUN npm install -g @openai/codex@${CODEX_VERSION:-latest} \
+  || { echo "runcastle: Codex CLI ${CODEX_VERSION:-latest} install failed — is that version published?" >&2; exit 1; }
 
 # Rootless-podman invariant (research #32): the in-container agent user MUST be at
 # UID/GID 1000 so bind-mounted host files share an owner. Sandcastle passes the host
@@ -32,8 +37,12 @@ USER ${AGENT_UID}:${AGENT_GID}
 # Claude Code CLI (the other agent runtime) — authenticated at runtime via
 # CLAUDE_CODE_OAUTH_TOKEN. Installed per-user, so it must follow the switch.
 # One image serves both runtimes: which CLI a burn invokes is decided by the
-# resolved model's runtime, not by the image.
-RUN curl -fsSL https://claude.ai/install.sh | bash
+# resolved model's runtime, not by the image. Pinned to the host's
+# `claude --version` the same way as Codex above; `install.sh` takes the version
+# as its first argument, and none installs latest.
+ARG CLAUDE_CODE_VERSION
+RUN curl -fsSL https://claude.ai/install.sh | bash -s ${CLAUDE_CODE_VERSION} \
+  || { echo "runcastle: Claude Code CLI ${CLAUDE_CODE_VERSION:-latest} install failed — is that version published?" >&2; exit 1; }
 ENV PATH="/home/agent/.local/bin:$PATH"
 
 # Sandcastle bind-mounts the git worktree here and runs the agent in it.

package/sandcastle-template/Dockerfile

@@ -18,7 +18,12 @@ RUN curl -fsSL https://bun.sh/install | bash
 # Codex CLI (the second agent runtime) — authenticated at runtime via CODEX_API_KEY.
 # Installed as root, before the user switch, so it lands in the system-wide npm
 # prefix: after `USER` a global install has nowhere writable to go.
-RUN npm install -g @openai/codex
+# Pinned to the host's `codex --version`, passed in by Rebuild. The ARG sits
+# directly above its RUN on purpose: a changed version busts the cache for this
+# layer and the ones after it, and nothing before it. Empty installs latest.
+ARG CODEX_VERSION
+RUN npm install -g @openai/codex@${CODEX_VERSION:-latest} \
+  || { echo "runcastle: Codex CLI ${CODEX_VERSION:-latest} install failed — is that version published?" >&2; exit 1; }
 
 # Rootless-podman invariant (research #32): the in-container agent user MUST be at
 # UID/GID 1000 so bind-mounted host files share an owner. Sandcastle passes the host
@@ -32,8 +37,12 @@ USER ${AGENT_UID}:${AGENT_GID}
 # Claude Code CLI (the other agent runtime) — authenticated at runtime via
 # CLAUDE_CODE_OAUTH_TOKEN. Installed per-user, so it must follow the switch.
 # One image serves both runtimes: which CLI a burn invokes is decided by the
-# resolved model's runtime, not by the image.
-RUN curl -fsSL https://claude.ai/install.sh | bash
+# resolved model's runtime, not by the image. Pinned to the host's
+# `claude --version` the same way as Codex above; `install.sh` takes the version
+# as its first argument, and none installs latest.
+ARG CLAUDE_CODE_VERSION
+RUN curl -fsSL https://claude.ai/install.sh | bash -s ${CLAUDE_CODE_VERSION} \
+  || { echo "runcastle: Claude Code CLI ${CLAUDE_CODE_VERSION:-latest} install failed — is that version published?" >&2; exit 1; }
 ENV PATH="/home/agent/.local/bin:$PATH"
 
 # Sandcastle bind-mounts the git worktree here and runs the agent in it.

package/skills/burner/implement-ticket.md

@@ -12,6 +12,7 @@ You run **non-interactively** — your agent CLI in print/exec mode, no terminal
 - **Ending your turn ends your process.** There are no background-task completion notifications in print mode — a "the notification will re-invoke me" plan never fires. Never end your turn to wait on a background command; run long commands (dependency installs, full test suites) in the foreground with a generous timeout, or poll a backgrounded command to completion *within* the same turn. **If you catch yourself writing "while that runs", "meanwhile", or "I'll check back on" — stop. That sentence is how iterations die**: in real burns it is the single most common last line before the process exits with the work unfinished and uncommitted.
 - **A next iteration is not a free retry.** It is a brand-new container: your process dies, the sandbox is rebuilt, dependencies reinstall from scratch (1–8 minutes), and a fresh agent with none of your context re-reads every file you just read. Budget roughly ten wasted minutes per iteration you burn. Finishing in one is worth real effort.
 - **You may not be the first iteration.** Earlier iterations' **commits** are on your branch; their uncommitted edits are not, and depending on how this sandbox is configured the next iteration may work in a freshly cloned checkout. So: run `git log --oneline -15` and `git status` before starting, and continue that work rather than redoing it. Only commits carry across.
+- **Amending is allowed on your private attempt branch.** The sync hook safely force-pushes amended commits back to the mounted mirror. Never merge a branch into itself to recover from a rejected push; fix or retry the push instead.
 - **Signal completion.** When the ticket is fully done — every acceptance criterion verified, self-review finished, all work committed — print exactly `<promise>COMPLETE</promise>` as the last line of your final message. Do the same after writing `BLOCKED.md` (see hard rules). Without the signal, the harness assumes you were cut off and spends another iteration.
 - **Run the repo's test command as the repo defines it.** Do not add `--maxWorkers`, `--pool`, `--shard`, `--runInBand`, or hand-split the suite into halves. The repo's test config is already tuned, and serialising it is not the cheap safety move it looks like: measured in this sandbox, a suite that runs in ~55s at its configured concurrency takes **10–20 minutes** at `--maxWorkers=1`. If a suite is killed for memory (exit 137), that is an environment fault — say so plainly in your final message and fall back to running the *narrower set of test files your change actually touches*, never the same full suite serialised.
 
@@ -48,9 +49,11 @@ If you catch yourself writing a heredoc to edit a file, stop and use `Edit`.
 
 Whatever the commands are, spend them well — a full suite on a monorepo is minutes of your budget, and in real burns re-running one was the largest single waste:
 
+- **Report a gate that cannot run.** If a configured verify command cannot run at all because its command or required runtime is missing, write `GATE_UNRUNNABLE.md` at the sandbox root as JSON with the exact strings `{"command":"<exact command>","error":"<exact error>"}` (or a JSON array of those objects for multiple gates). Continue every other gate you can run. This is an environment report, never your ticket's failure, and it does not replace `BLOCKED.md` or `DIGEST.md`.
+
 - **Capture, then read.** Redirect a full run to a file (`<command> > /tmp/test-run.log 2>&1`), check the exit code, then read that file with `Read`/`Grep` as many times as you like. Never re-run a suite to re-read, re-filter, or re-format its output — the same command has been observed re-run five, six, and seven times inside a single ticket.
 - **Run the whole thing rarely.** Targeted runs (single file, single pattern) while you work; the full suite once before your final commit, plus once more only if that run found something you then fixed.
-- **Never `git stash` to get a clean-tree comparison.** It puts every uncommitted change you have into a place the orchestrator cannot see or recover if your process dies mid-window. If you need to compare against the pre-change state, use the baseline above, `git worktree add` a scratch checkout, or read the file at `HEAD` with `git show`.
+- **Never `git stash` to get a clean-tree comparison.** It puts every uncommitted change you have into a place the orchestrator cannot see or recover if your process dies mid-window. If you need to compare against the pre-change state, use the baseline above, read the file at `HEAD` with `git show`, or — only if you genuinely need the old tree on disk — `git worktree add --detach <path> <sha>` a **detached** scratch checkout and `git worktree remove` it when done. Never `git worktree add <path> <branch>`: that checks the branch out, and a worktree left holding a branch is one nobody else can check it out in.
 
 ## How to work
 

package/skills/burner/review-ticket.md

@@ -9,7 +9,7 @@ You review it in **exactly one of two modes**, and you pick which before you do
 1. **Drive** — walk the running app in a browser against the ticket's `acceptanceCriteria`. For a lap with a surface a human could operate, when a drive is available.
 2. **Gates** — run the repo's verify gates, then read the branch's diff along two axes. For every other lap: prompt contracts, docs, an internal refactor, a backend-only change — and for any lap where a drive is not available.
 
-**One mode, never both.** This is measured, not a preference: the reviews that did exactly one delivered in around half an hour, and every review that tried both either ran long or died having delivered neither. Whichever mode you are in is the *whole* review, and it is a complete one — a lap reviewed in Gates mode is not half-reviewed, and neither is a lap reviewed in Drive mode.
+**One mode, never both — except the explicit drive-failure fallback below.** This is measured, not a preference: the reviews that did exactly one delivered in around half an hour, and every review that tried both either ran long or died having delivered neither. Whichever mode you are in is the *whole* review, and it is a complete one — a lap reviewed in Gates mode is not half-reviewed, and neither is a lap reviewed in Drive mode.
 
 You leave two deliverables behind: the **findings** (one report per finding, typed) and the **digest** (the lap's account — see step 5; it is not an afterthought). Its first line is a standalone one-liner naming the lap, what landed, the counts and the mode you ran: that line is the one the review page renders on arrival, and the account behind it is what the human opens when they want more.
 
@@ -79,7 +79,7 @@ The URL is **not** ready when `start` returns — the dev server has to print it
 - **`deniedCode: "slot_held"` (`retriable: true`)** — somebody else holds the machine-wide drive slot: the human's own drive, another review's, or a preparation dry run. It frees itself when they finish, so wait it out. Call `start` again **about ten times, roughly thirty seconds apart** — count the attempts, do not watch the clock, and do nothing else in between. If one of them takes, you are driving; carry on. If the tenth is still refused, the slot is not coming, so put the words `could not drive: slot never freed after ~5 minutes` in your digest and **switch to Gates mode**, step 2b.
 - **`deniedCode: "dirty"` (`retriable: false`)** — the human's own uncommitted files block the checkout switch, and no amount of waiting clears them. Do not call `start` a second time. Put `could not drive: dirty tree (<files>)` in your digest, naming the paths the refusal handed you in `dirtyFiles`, and **switch to Gates mode**, step 2b, straight away.
 
-Either way: report an observation saying the drive could not start and which of the two it was, run the step 4 cleanup for whatever you got as far as starting, and spend the whole review in Gates mode. That is a complete review too. A `devUrl` that never appears goes the same way — `could not drive: no dev URL`, then Gates mode.
+Either way: report an observation saying the drive could not start and which of the two it was, run the step 4 cleanup for whatever you got as far as starting, and spend the whole review in Gates mode. That is a complete review too. A `devUrl` that never appears goes the same way — `could not drive: no dev URL`, then Gates mode. If the dev URL answers but `agent-browser` cannot attach, that is a drive failure: record that failure in the declaration block below, then run Gates mode **in full**. This is the one explicit exception to the never-run-both-modes rule.
 
 **Never build your own environment to drive in.** When `review_drive` refuses for good, or never yields a URL, the drive is over — an app you reached some other way is not the app the human runs, so what it shows you is not evidence about their machine. Do not create a worktree, do not install dependencies, do not run a build, a codegen or a migration to conjure one. One review that improvised exactly that — a worktree, a full dependency install, three rounds of codegen, and a five-command fight to delete the directory afterwards — spent more than any other single act in any review, and still left four of its six acceptance criteria unverifiable. Gates mode is what is left to you, and it is enough: run the verify commands as the repo's own manifest defines them, read the diff along both axes, and report every criterion the drive would have covered as an observation saying it is unverified.
 
@@ -128,6 +128,15 @@ git diff {{BASE_BRANCH}}...{{FEATURE_BRANCH}}             # the diff both axes r
 
 Confirm both refs resolve and the diff is non-empty **before** spawning anything. An empty diff there — where the empty-`HEAD` trap cannot explain it — is a real finding worth reporting.
 
+**Read the branch; never check it out, and never leave a worktree holding it.** Both commands above read `{{FEATURE_BRANCH}}` from where you already stand, and `git show {{FEATURE_BRANCH}}:<path>` gives you any whole file at that ref — so staying on `{{BASE_BRANCH}}` costs you nothing. Do not `git checkout {{FEATURE_BRANCH}}`, and do not add a scratch worktree to browse it in. If you truly cannot answer a question without the files on disk, there is exactly one acceptable shape:
+
+```
+git worktree add --detach <path> <sha>   # DETACHED — never `git worktree add <path> <branch>`
+git worktree remove <path>               # before you finish, on every path out
+```
+
+`git worktree add <path> <branch>` **checks that branch out**, which makes your scratch directory the branch's one holder — and this is the human's real machine, where runcastle's talk worktree has to hold `{{FEATURE_BRANCH}}` to open the next session on it. A review that left `<repo>/.occ-review` behind exactly this way — branch checked out, never removed — is why this paragraph exists.
+
 **Gather the standards.** `CLAUDE.md` (the repo's own agent-facing conventions, and the highest authority), `CONTEXT.md` (the charter), live ADRs under `docs/adr/`, and anything else the repo keeps for the purpose. These are the same files the implementers were pointed at, so a violation here is one they were told about and missed. On top of them the Standards axis carries the **smell baseline** below, so it has a floor on a repo that documents nothing. The repo always overrides: where a documented standard endorses what the baseline would flag, the smell is suppressed. Every smell is a judgement call, never a hard violation, and anything tooling already enforces is skipped — the linter ran, and it is not why a human is reading you.
 
 Mysterious Name · Duplicated Code · Feature Envy · Data Clumps · Primitive Obsession · Repeated Switches · Shotgun Surgery · Divergent Change · Speculative Generality · Message Chains · Middle Man · Refused Bequest.
@@ -206,6 +215,14 @@ Findings belong in `report_finding`, not here — your observations sit inside t
 
 Write it at that path and nowhere else — **never inside the repo**, which is the human's real working tree. This is the last thing you do before signalling COMPLETE.
 
+End `DIGEST.md` with exactly this machine-readable declaration block. Name the mode you actually completed. The reason must be one line and is required for an unverified pass (and should record a failed Drive fallback even when the full Gates run verified the pass):
+
+```
+REVIEW-MODE: drive|gates
+REVIEW-VERDICT: verified|unverified
+REVIEW-REASON: <one line; required when unverified>
+```
+
 ## Could not review
 
 The bar is high, because Gates mode needs almost nothing: no app, no browser, no drive slot. Finding bugs is not failure, and **neither is a drive that would not start** — that is an observation, a switch to Gates mode, and a line in the digest saying which refusal it was: a slot that never freed after your ten attempts, or a dirty tree you were never going to be able to wait out.
@@ -219,12 +236,13 @@ When that happens: run the step 4 cleanup for whatever you got as far as startin
 
 ## Hard rules
 
-- **Never run both modes.** Not the diff review "while the dev server boots", not a quick walk "since the app is already up". One mode, chosen in step 1, for the whole review — the reviews that broke this rule are why it exists.
+- **Never run both modes, except for the explicit drive-failure fallback above.** Not the diff review "while the dev server boots", not a quick walk "since the app is already up". One mode, chosen in step 1, for the whole review — unless the dev URL answers but no browser attaches, in which case record the drive failure and run Gates mode in full.
 - **Never skip the review.** Every lap gets one of the two modes, whatever the ticket asks for and whether or not the app can be driven. A lap nobody reviewed is the silence this ticket exists to end.
 - **Never edit the repo.** No source changes, no commits, no new files anywhere under the checkout — your two output files live at the paths above, outside it. The one exception is nothing: if the ticket seems to ask you to fix something, it does not.
 - **Never merge or re-rank the two review axes**, and never report a finding without its citation.
 - **Never let a sub-agent spawn more agents.** The guard line goes in both briefs, every time.
 - **Never leave the drive — or the recorder — running.** Stop both on every path, including the one where you gave up on the drive.
+- **Never leave a worktree holding `{{FEATURE_BRANCH}}`.** Read the branch with `git diff`/`git show` instead; a scratch worktree you cannot avoid is `--detach`ed at a sha and `git worktree remove`d before you finish, never a branch checkout.
 - **Never build your own environment.** No worktrees, no dependency installs, no builds, no generated artifacts. If `review_drive` did not hand you the app, the drive did not happen: say `could not drive:` and which refusal it was, run Gates mode — the repo's verify commands and the diff — and leave it there.
 - **Never wait out a refusal that will not clear.** The ten polls are for `retriable: true` — a held slot — and nothing else. Re-calling `start` on a dirty tree spends five minutes to be told the same thing ten times.
 - **Never report a finding you did not observe.** Every finding traces to something you saw in a snapshot, a response body, a gate's output, or a hunk you opened and confirmed. A plausible-sounding bug that is really a stale ref — or an unverified sub-agent claim — spends a fix ticket on working code.

package/skills/burner/verify-fixes.md

@@ -34,14 +34,22 @@ Run digests:
 
 ## Tour and verify
 
-In **Drive mode**, call `mcp__runcastle__review_drive({ action: "start" })`, start the recorder at `{{WALKTHROUGH_PATH}}`, and walk every acceptance criterion's user-facing surface once at pace. Keep the recorder running for the whole tour. Scrutinise only the landed fixes: check whether each listed repro step still reproduces and inspect the surfaces those fixes touched. Report anything plainly broken during the tour, but do not hunt for unrelated defects. Stop the recorder and drive when finished.
+In **Drive mode**, call `mcp__runcastle__review_drive({ action: "start" })`, start the recorder at `{{WALKTHROUGH_PATH}}`, and walk every acceptance criterion's user-facing surface once at pace. Keep the recorder running for the whole tour. Scrutinise only the landed fixes: check whether each listed repro step still reproduces and inspect the surfaces those fixes touched. Report anything plainly broken during the tour, but do not hunt for unrelated defects. Stop the recorder and drive when finished. If the dev URL answers but no browser attaches, record that drive failure, clean up, and run Gates mode in full; this is the explicit exception to the one-mode rule.
 
 {{DRIVE_INSTRUCTIONS}}
 
-In **Gates mode**, read each fix diff against its finding and run the configured gates exactly once. Do not perform a second two-axis review of the whole branch.
+In **Gates mode**, read each fix diff against its finding and run the configured gates exactly once. Do not perform a second two-axis review of the whole branch. Read the branch from where you stand — `git diff {{BASE_BRANCH}}...{{FEATURE_BRANCH}}`, and `git show {{FEATURE_BRANCH}}:<path>` for a whole file: never check `{{FEATURE_BRANCH}}` out, and never leave a worktree holding it. A scratch worktree you cannot avoid is `git worktree add --detach <path> <sha>`, removed with `git worktree remove <path>` before you finish — never `git worktree add <path> <branch>`, which checks the branch out and leaves your directory holding it against the next session's launch.
 
 {{GATE_NOTES}}
 
-Report findings through `mcp__runcastle__report_finding` as usual. Verification findings remain open for the human and never mint fix tickets. The ordinary review auto-fix cap is {{AUTO_FIX_CAP}}.
+Report findings through `mcp__runcastle__report_finding` as usual. Verification findings never mint fix tickets: a confirmed defect stays open for the human, carried under the existing carry/link/close rules. The ordinary review auto-fix cap is {{AUTO_FIX_CAP}}.
 
 Write `{{DIGEST_PATH}}`. Its first line must name the inherited mode and say "verification pass" (for example, `Drive verification pass`). Summarise which fixes held, which did not, and anything plainly broken on the tour. No `<promise>` markers inside the digest — the completion signal is a line in your message, never a line in this file. If the pass cannot run at all, write `{{BLOCKED_PATH}}` with the precise reason instead. Either way, the file you write is the last thing you do before signalling COMPLETE.
+
+End the digest with exactly this machine-readable block. Name the mode actually completed; after a Drive failure followed by full Gates use `gates` and keep the drive failure in the one-line reason:
+
+```
+REVIEW-MODE: drive|gates
+REVIEW-VERDICT: verified|unverified
+REVIEW-REASON: <one line; required when unverified>
+```

package/skills/packs/README.md

@@ -15,7 +15,7 @@ Scope-specific skills, each namespaced `/runcastle:<skill>`:
 | `/runcastle:project` | entry for `kind=project` | project scope, not feature scope: consults the portfolio, advises on how a lump of intent should be cut into N features and creates them, routes, answers portfolio questions, curates advisory-only, and owns `CONTEXT.md` |
 | `/runcastle:waypoint` | entry for `kind=waypoint` | *original* — works ONE waypoint on a mapped feature, writes its decision prose, resolves the waypoint |
 | `/runcastle:converge` | entry for `kind=converge` | closes a mapped feature: reads the compressed knowledge — `map.md`, `decisions.md`, and the `research/*.md` deliverables the research waypoints produced — then drives spec + tickets from it |
-| `/runcastle:revisit` | entry for `kind=revisit` | *original* — folds late information into a finished feature; on a Rethink, runs the whole front half of a lap |
+| `/runcastle:revisit` | entry for `kind=revisit` | *original* — folds late information into a finished feature; on an Iterate from review, runs the whole front half of a lap |
 | `/runcastle:code-review` | by description, or by name | two-axis review (Standards + Spec) of a feature branch's diff against its base, run as parallel sub-agents and reported unmerged; never edits |
 
 Layout (the verified plugin format — only `plugin.json` lives inside `.claude-plugin/`; `skills/` is a sibling at the plugin root):
@@ -73,36 +73,50 @@ claude ... --plugin-dir "<abs path>/packages/skills/packs/runcastle" ...
 
 The `name` field in `plugin.json` becomes the invocation namespace, so the skills resolve as `/runcastle:ideate` and friends. The injected system prompt tells each session which entry skill to invoke for its kind (`/runcastle:ideate` for ideation, `/runcastle:qa` for Q&A).
 
-### `disable-model-invocation` — session entries off, chained and reached ones on
+### Entry-skill isolation — settings deny rules, not `disable-model-invocation`
 
 Every skill's `description` is loaded into every session in the pack, whether or
 not that session can use it. That is cheap for a skill the model might genuinely
-need and actively harmful for one it must not run: a `qa` session was carrying
-the descriptions of `ideate`, `spec`, `tickets`, `converge`, `revisit`,
-`waypoint` and `project` (~582 tokens), every one of them advertising a procedure
-`qa/SKILL.md` forbids. Sharper still, `project/SKILL.md` says "**Never run an
-ideation grilling**" while `ideate`'s description sat in the same list offering
-exactly that.
-
-So the six **session-entry** skills — `ideate`, `qa`, `converge`, `revisit`,
-`waypoint`, `project` — carry `disable-model-invocation: true`. They are never
-model-chosen: the kickoff line the launcher injects names the one skill for that
-kind explicitly, by name, and explicit invocation works fine for a skill with
-model invocation disabled. Nothing else should ever reach them, because reaching
-one means a session running another session's procedure.
-
-The remaining three stay `false`, each for a reason:
-
-- `spec` and `tickets` are **chained**, invoked by name from inside `ideate`
-  and `converge` mid-conversation.
-- `code-review` is the one skill that is not a session entry point at all — being
-  reached by description is the only way it is reached.
-
-The rule, for anything added later: **a session-entry skill disables model
-invocation; a chained or genuinely description-reached one does not.** The
-question is not "might this be useful?" but "is there a session whose *whole job*
-is something else that could pick this up by mistake?" If yes, disable it and
-invoke it by name.
+need and risky for one it must not run: a session carrying the descriptions of
+every other kind's entry skill is one description-match away from running
+another session's procedure — `project/SKILL.md` says "**Never run an ideation
+grilling**" while `ideate`'s description sits in the same list offering exactly
+that.
+
+The seven **session-entry** skills — `ideate`, `qa`, `converge`, `revisit`,
+`waypoint`, `project`, `prepare` — used to carry `disable-model-invocation:
+true` for that reason, on the build-era understanding that explicit invocation
+kept working (CC-INTEGRATION-NOTES §1). It no longer does: Claude Code now
+hard-blocks the **Skill tool** for such a skill even when the prompt names it,
+and only a *user-typed* `/runcastle:<skill>` gets through. The launcher's
+kickoff lines are prose ("Proceed with your task: invoke the /runcastle:project
+skill…"), so every fresh session was directed to do the one thing its skill's
+frontmatter forbade — and a `/clear` left the session with no path back to its
+own entry skill at all (recorded in `docs/research/CORRECTIONS.md`).
+
+So all skills in the pack are now `disable-model-invocation: false`, and the
+cross-kind prohibition moved to where the other standing prohibitions already
+live: **per-session settings**. The launcher launches each session with
+`permissions.deny` rules — `Skill(runcastle:<x>)` plus `Skill(runcastle:<x> *)`
+— for every entry skill that is not that kind's own (`entrySkillsFor` /
+`entrySkillDenyRules` in `packages/server/src/launcher`), and each injected
+prompt states the policy in one line. Same layering as the edit guard: the
+prompt says it, the harness enforces it. `chat` keeps both of its openings
+(`ideate` + `revisit`); `qa` — whose session kind was retired — is denied
+everywhere; `drive-fix` has no entry skill and denies all seven.
+
+The chained/reached skills — `spec` and `tickets` (invoked by name from inside
+`ideate` and `converge`) and `code-review` (reached by description) — are in no
+deny list.
+
+The rule, for anything added later: **a session-entry skill goes into
+`ENTRY_SKILLS` and the per-kind table in
+`packages/server/src/launcher/runtimes/skills.ts`; a chained or genuinely
+description-reached one does not.** The question is not "might this be useful?"
+but "is there a session whose *whole job* is something else that could pick this
+up by mistake?" If yes, it is an entry skill and every other kind denies it.
+`disable-model-invocation` stays `false` across the pack — setting it `true`
+breaks the prose kickoff.
 
 ## Layering: prompt, skill, hook — one home each
 

package/skills/packs/runcastle/skills/code-review/SKILL.md

@@ -44,6 +44,15 @@ git diff <base>...HEAD                     # the diff both axes read
 
 Three-dot excludes uncommitted work. If something is sitting in the working tree, it is invisible to this review — say so rather than reviewing what you can see with your file tools instead.
 
+**Read the branch; never check it out, and never leave a worktree holding it.** The commands above reach any commit from wherever you already are — three-dot diff for the change, `git show <ref>:<path>` for a whole file at that ref — so there is nothing to switch to and nothing to clone. Do not `git checkout` the branch under review, and do not conjure a scratch worktree to browse it in. If you truly cannot answer a question without the files on disk, there is exactly one acceptable shape:
+
+```
+git worktree add --detach <path> <sha>   # DETACHED — never `git worktree add <path> <branch>`
+git worktree remove <path>               # before the session finishes, on every path out
+```
+
+`git worktree add <path> <branch>` **checks that branch out**, which makes your scratch directory the branch's one holder. runcastle's own talk worktree has to hold `feature/<slug>` to open the next session on it, so a scratch directory left sitting on that branch is something the next launch has to fight its way past. A review session that left `<repo>/.occ-review` behind exactly this way — branch checked out, never removed — is why this paragraph exists.
+
 ## 2. Find the spec
 
 runcastle features always have one, so there is no "no spec available" path to reach for first:
@@ -125,6 +134,7 @@ Either way: **finding problems is a successful review.** The report is the deliv
 ## Do NOT
 
 - **Never edit the diff you are reviewing.** No fixes, no commits, no "while I was in there".
+- **Never leave a scratch worktree holding the branch.** Detached at a sha, removed before you finish, or never created at all — see §1.
 - **Never merge or re-rank the two axes**, and never pick an overall winner.
 - **Never report a finding without its citation**, and never restate what tooling already enforces.
 - **Never let a sub-agent spawn more agents.** The guard line goes in both briefs, every time.

package/skills/packs/runcastle/skills/converge/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: converge
 description: Close a mapped feature. Read the compressed knowledge — map.md, decisions.md and the research deliverables — never the waypoint transcripts, then drive spec and tickets out of that one unbroken window. Entry skill for kind=converge sessions.
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 <!-- Forked from Matt Pocock's grilling/to-spec/to-tickets discipline, via https://github.com/mattpocock/skills, 2026-07-15, adapted for runcastle mapped ideation -->
 
 # Converge — close a mapped feature
 
-A mapped feature was too big for one window, so it was charted into a map and its waypoints were worked in their own sessions. Every waypoint is now terminal, the human clicked **Converge**, and the feature has already crossed G1 into the `spec` phase. Your job: turn the compressed knowledge into a spec and tickets — the exact output an unbroken ideation session produces.
+A mapped feature was too big for one window, so it was charted into a map and its waypoints were worked in their own sessions. Every waypoint is now terminal and the human clicked **Converge**; the feature stays in **Planning** throughout — converging is not a state change, it is the rest of Planning done in one window. Your job: turn the compressed knowledge into a spec and tickets — the exact output an unbroken ideation session produces.
 
 ## Context hygiene is the whole game
 
@@ -15,7 +15,7 @@ Everything happens in this one window. **Never compact. Never `/clear`. Never su
 
 ## 0. Read the compressed knowledge — and only that
 
-Call `mcp__runcastle__get_feature_context`. The injected system prompt carries the slug and the paths; trust `get_feature_context` for the live state. It returns the feature, the current `phase`, the map, the tickets, and its docs in two parts — `docs[]`, inlined in full, and `moreDocs[]`, an index of everything else with a `relPath` and a byte count. Read, in this order:
+Call `mcp__runcastle__get_feature_context`. The injected system prompt carries the slug and the paths; trust `get_feature_context` for the live state. It returns the feature, the current `phase`, the map, the tickets as summary rows (`seq`, `title`, `status`, `goal`; `mcp__runcastle__get_ticket({ seq })` has a ticket's context, acceptance criteria and digest), and its docs in two parts — `docs[]`, inlined in full, and `moreDocs[]`, an index of everything else with a `relPath` and a byte count. A canonical doc too large to inline is listed in `notInlined` instead of `docs[]`: read it with `mcp__runcastle__read_feature_doc({ relPath })` or off disk before acting. Read, in this order:
 
 1. **`map.md`** (inlined in `docs[]`) — the destination, the notes, and what was ruled out of scope.
 2. **`decisions.md`** (inlined in `docs[]`) — every decision the waypoint sessions locked. This is the spine of the spec.
@@ -33,9 +33,11 @@ Invoke `/runcastle:spec` (it writes `spec.md` and completes the `spec` phase); w
 
 Do not open a new session for these. They run here, on top of the compressed knowledge you just read.
 
-**Re-convergence.** You may be a fresh session continuing a converge that crashed or was closed mid-way — the feature is past G1 but has no tickets. Do not start over; pick up from whatever is already on disk:
+A converged batch is burned exactly like an ideated one, so the two batch-wide rules `/runcastle:tickets` carries bind here unchanged: the batch closes with **one review ticket**, and before you emit you state the **critical path and the width it leaves against `burnConcurrency`**, reslicing when the chain is longer than roughly total / concurrency. A map that was worked waypoint by waypoint makes the second one easy to get wrong — the waypoints were sequenced for a reason, and their tickets usually are not. Chain two only where the later one reads the earlier one's output.
 
-- **`spec.md` already exists** (it is in `docs[]`): read it, do **not** rewrite it, and go straight to `/runcastle:tickets`. **If the current `phase` is still `spec`, call `mcp__runcastle__complete_phase({ phase: "spec" })` first** — the spec work is done, the phase just never got closed, and `/runcastle:tickets` cannot complete a phase it is not standing in.
+**Re-convergence.** You may be a fresh session continuing a converge that crashed or was closed mid-way — the map is charted but there are no tickets. Do not start over; pick up from whatever is already on disk, which is the only thing that says how far the last session got:
+
+- **`spec.md` already exists** (it is in `docs[]`): read it, do **not** rewrite it, and go straight to `/runcastle:tickets`. There is no step to re-close first — `complete_phase` records a milestone rather than moving anything, so a spec that was written but never reported costs nothing.
 - **`spec.md` does not exist**: run `/runcastle:spec` then `/runcastle:tickets` as normal.
 - **Tickets already exist** for this lap: reconcile rather than duplicate — this is the one case where `update_ticket` / `cancel_ticket` beat a second `emit_tickets`.
 
@@ -49,4 +51,4 @@ If something surfaces that is plainly its own feature rather than part of this o
 
 > Converged. Tickets are in the runcastle UI — review the ticket cards and click **Burn** to start the AFK agents. I'll stop here.
 
-Do **not** start burning. The two human clicks (Burn, then Merge after test-drive) are the only gates left, and they belong to the human. (You do not write code here either — that rule is in your injected prompt and enforced by the edit guard, not restated as advice.)
+Do **not** start burning. Burn and Merge are the only two clicks in the whole pipeline, and both belong to the human. (You do not write code here either — that rule is in your injected prompt and enforced by the edit guard, not restated as advice.)

package/skills/packs/runcastle/skills/ideate/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ideate
 description: The runcastle ideation session. Grill the human relentlessly about a feature, lock decisions incrementally into decisions.md, then drive spec and tickets out of the same unbroken context. Entry skill for kind=ideation sessions.
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 <!-- Forked from Matt Pocock's grilling + grill-with-docs skills, via https://github.com/mattpocock/skills, 2026-07-14, adapted for runcastle -->
 
@@ -15,12 +15,12 @@ Everything happens in this one window. **Never compact. Never `/clear`. Never su
 
 ## 0. Orient
 
-1. Call `mcp__runcastle__get_feature_context`. It returns the feature (`slug`, `title`, `oneLiner`), current `phase` and `lap`, the canonical docs inlined in `docs[]` (`brief.md`, and any `decisions.md` — **this may be a resumed session; read what is already locked and do not re-ask it**), an index of every other doc in `moreDocs[]` (fetch one with `mcp__runcastle__read_feature_doc({ relPath })`), and any tickets.
+1. Call `mcp__runcastle__get_feature_context`. It opens with a header — the feature (`slug`, `title`, `oneLiner`), current `phase` and `lap`, `annotatedModels`, `burnConcurrency` — then any tickets as summary rows (`seq`, `title`, `status`, `goal`, …; a ticket's context, acceptance criteria and digest come from `mcp__runcastle__get_ticket({ seq })`), then the canonical docs inlined in `docs[]` (`brief.md`, and any `decisions.md` — **this may be a resumed session; read what is already locked and do not re-ask it**), and an index of every other doc in `moreDocs[]` (fetch one with `mcp__runcastle__read_feature_doc({ relPath })`). A canonical doc too large to inline is listed in `notInlined` with its `relPath` and `absPath` instead — **read it before acting**, with `read_feature_doc` or off disk.
 2. Decisions live at `docs/features/<slug>/decisions.md` in this worktree. The injected system prompt carries the slug and paths; trust `get_feature_context` for the live state.
 
 **Your tools**, and there are not many — this session's real work is the conversation:
 
-- `mcp__runcastle__get_feature_context` / `mcp__runcastle__read_feature_doc` / `mcp__runcastle__list_tickets` — the record.
+- `mcp__runcastle__get_feature_context` / `mcp__runcastle__read_feature_doc` / `mcp__runcastle__list_tickets` / `mcp__runcastle__get_ticket` — the record.
 - `mcp__runcastle__create_feature({ title, oneLiner, brief, draft: true })` — park scope creep as a draft feature (§1). `draft: true` is the only door open to you; a full create belongs to the project session.
 - `mcp__runcastle__escalate_to_map` + `mcp__runcastle__emit_waypoints` — the escalation branch (§3). This is the entire entry point into mapped ideation: no other surface charts a map from a linear feature.
 - `mcp__runcastle__complete_phase` — the phase boundaries (§4), and the ones `/runcastle:spec` and `/runcastle:tickets` cross after you.
@@ -73,7 +73,7 @@ Some features are too big for one unbroken context. The tells: you are rabbit-ho
 
 When the human confirms shared understanding and the open questions are answered or explicitly deferred:
 
-`mcp__runcastle__complete_phase({ phase: "ideation" })` → returns `{ ok, nextPhase }`. If `ok: false`, it names what the gate wants (e.g. `decisions.md` missing) — fix it and retry. It logs its own timeline event; do not add one.
+`mcp__runcastle__complete_phase({ phase: "ideation" })` → returns `{ ok: true, nextPhase, nextStep }`. It does not refuse and it does not move the feature: ideation, spec and tickets are three steps inside **Planning**, and this records the milestone on the timeline. `nextStep` is the next step still missing its artifact, read off disk rather than stored — so if `decisions.md` is not written yet it comes back as `"ideation"` again, which is your cue to write it. It logs its own timeline event; do not add one.
 
 ## 5. Spec → tickets — stay in this window
 
@@ -87,4 +87,4 @@ Do not open a new session for these. They run here, on top of everything you jus
 
 > Tickets are in the runcastle UI. Review the ticket cards and click **Burn** to start the AFK agents. That is the next step — I will stop here.
 
-Do **not** start burning. The two human clicks (Burn, then Merge after test-drive) are the only gates left, and they belong to the human. (You do not write code here either — that rule is in your injected prompt and enforced by the edit guard, not restated as advice.)
+Do **not** start burning. Burn and Merge are the only two clicks in the whole pipeline, and both belong to the human. (You do not write code here either — that rule is in your injected prompt and enforced by the edit guard, not restated as advice.)

package/skills/packs/runcastle/skills/prepare/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: prepare
 description: Establish a project's host settings with evidence — the dev command, the drive setup/stop scripts, the dev-database reset — by running them on the developer's own machine rather than guessing them from config. Covers the drive contract, discovering a project's shape, and the closing dry-run drive. Entry skill for kind=prepare sessions.
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Prepare — establish this project's host settings

package/skills/packs/runcastle/skills/project/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: project
 description: The runcastle project session. Take a lump of raw intent, consult the portfolio first, advise on how it should be cut, and create the features with real briefs — plus portfolio Q&A, routing to one of five destinations, advisory-only curation, and the charter (CONTEXT.md), which this is the only session allowed to write. Entry skill for kind=project sessions.
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 <!-- Forked from Matt Pocock's grilling + domain-modeling skills, via https://github.com/mattpocock/skills, 2026-07-14, adapted for runcastle's project-level session -->
 
 # Project session
 
-You belong to the **project**, not to any feature. There is no phase to advance and no gate to cross here.
+You belong to the **project**, not to any feature. There is no feature state to move and no planning step to report here.
 
 Your defining job is the one no other surface in runcastle can do: **intake and decomposition terminating in feature creation**. Every other door into the pipeline demands a title and a one-liner up front, which means it demands the human has already cut their thought into a feature. You are where they don't have to — and, because you are the only session that can see the *whole portfolio*, you are the only one that can tell them their thought is really two features, or one they already shipped.
 
@@ -17,17 +17,21 @@ Everything else you do — portfolio Q&A, routing, curation, the charter — is
 
 ## Your tools
 
-Five, and deliberately none of the feature pipeline's. A session with no feature has no business advancing one through a gate — `complete_phase`, `emit_tickets` and the ticket-surgery tools are not registered for this kind at all.
+Nine, and deliberately none of the feature pipeline's. A session with no feature has no business moving one through it — `complete_phase`, `emit_tickets` and the ticket-surgery tools are not registered for this kind at all. The three project-notes tools run the other way: they are registered for **this kind only**, because the project session is the only surface that marks a note triaged.
 
-- `mcp__runcastle__get_project_context()` — the project row, the charter (`CONTEXT.md`) in full, an **index** of every live ADR (superseded ones omitted), a one-line index of every feature, and `baseBranches`: the checkout's `current` branch, whether it is a selectable base (`currentIsSelectable`), every `selectable` base, and the `detectedMain` line. ADR bodies are *not* inlined.
+- `mcp__runcastle__get_project_context()` — the project row, the charter (`CONTEXT.md`) in full, an **index** of every live ADR (superseded ones omitted), `baseBranches` (the checkout's `current` branch, whether it is a selectable base (`currentIsSelectable`), every `selectable` base, and the `detectedMain` line), and a feature index of one `<slug> — <title> [state]` line per feature: every in-flight feature and draft, then the 50 most recently shipped. Older shipped and archived features collapse into one closing line that counts them and says how to reach them. ADR bodies and one-liners are *not* inlined.
 - `mcp__runcastle__read_adr({ relPath })` — one ADR in full, from the index. This is how you read the decisions that bind the idea in front of you, one at a time, instead of swallowing them all.
-- `mcp__runcastle__get_work_record({ featureSlug? , seam? })` — what features actually **did**: tickets by status, seams, commits, errors, run summaries, and each burner's digest of what it actually did, what surprised it and what it left undone. Facts, never intent. Send exactly one of the two arguments.
+- `mcp__runcastle__read_feature_brief({ slug })` — one feature's title, one-liner, status/phase/lap and brief: off disk for a shipped feature, from the database for an in-flight or draft one. This is how you go from "that title sounds related" to what the feature is for.
+- `mcp__runcastle__get_work_record({ featureSlug? , seam? , seq? })` — what features actually **did**. Send exactly one of `featureSlug` or `seam`. The **seam** form lists matching tickets as rows — feature slug, `seq`, title, status, seams, commits, error — with no digests. The **featureSlug** form tells the whole story: tickets by status, seams, commits, errors, run summaries, and each burner's digest of what it actually did, what surprised it and what it left undone; a digest too large to fit is moved out and its ticket marked `digestNotInlined: true`. **`featureSlug` + `seq`** returns that one ticket with its digest. Facts, never intent.
 - `mcp__runcastle__create_feature({ title, oneLiner, baseBranch?, brief?, draft?, tickets? })` — the end of intake.
 - `mcp__runcastle__record_event({ type, message })` — a note on the project timeline.
+- `mcp__runcastle__list_project_notes()` — the project's **open notes**, oldest first: id, text, createdAt, and for a note with a screenshot its absolute host path (`Read` it) plus a ready-made attachment sentence to paste into a ticket string. A note taken during a project test drive also carries `driveBranch` and `driveCommit`: it was noted while driving `<driveBranch>` @ `<driveCommit>`, which tells you whether it predates a fix.
+- `mcp__runcastle__triage_project_note({ noteIds, outcome, featureId? })` — marks one or several notes triaged, with the one-line outcome they are frozen with.
+- `mcp__runcastle__update_project_note({ noteId, text })` — rewrites an open note's text.
 
-**What the feature index makes readable.** A **merged** feature carries its docs path, and those docs are on disk here — read `docs/features/<slug>/` with ordinary `Read`/`Grep`. An **in-flight** one has no docs path (its docs are on an unmerged branch) but its index line is `<slug> — <title> [in flight: <phase>, lap N, X pending, Y burning, mapped]`. **That slug is the handle**: `get_work_record({ featureSlug })` works on in-flight features too. So "it's in flight, I can't see it" is not an answer — you can always see what it is *doing*, just not what it *argued*.
+**What the feature index makes readable.** A **shipped** feature's docs are on disk here at `docs/features/<slug>/` — read them with ordinary `Read`/`Grep`, and grep `docs/features/*/brief.md` for the older ones the index collapsed into its closing line. An **in-flight** one's docs are on an unmerged branch, but its index line is `<slug> — <title> [in flight: <phase>, lap N, X pending, Y burning, mapped]` and `read_feature_brief({ slug })` returns its brief. **That slug is the handle**: `get_work_record({ featureSlug })` works on in-flight features too. So "it's in flight, I can't see it" is not an answer — you can always see what it is *doing*, just not what it *argued*.
 
-**Two procedures load on demand**, beside this file — read one only when that job actually arrives: `./references/charter.md` (writing or amending `CONTEXT.md` and project ADRs — §5) and `./references/health-sweeps.md` (running a sweep — §6).
+**Three procedures load on demand**, beside this file — read one only when that job actually arrives: `./references/charter.md` (writing or amending `CONTEXT.md` and project ADRs — §5), `./references/health-sweeps.md` (running a sweep — §6) and `./references/triage.md` (triaging the project's jotted notes — **Notes triage**).
 
 ## 0. Open by asking
 
@@ -35,6 +39,11 @@ Your first visible move is a **question**, not a lookup. Greet them and put it:
 
 > What are we cutting into features today?
 
+**Two things displace that question**, and both come from what you were launched with:
+
+- **A briefing that says to triage the open project notes.** Then triage is why this terminal exists: read `./references/triage.md` and start its first movement instead of asking the opening question.
+- **A prompt line saying "This project has N open notes."** The count was taken at launch and the notes are still waiting. Offer triage in your opening line — *"What are we cutting into features today? (There are 7 open notes waiting to be triaged, if you'd rather start there.)"* — and if they take it, read `./references/triage.md` then.
+
 Then orient **lazily**: reach for context when intake, routing, or a portfolio question actually needs it, never as an opening ritual. The human is waiting on that first line, and context fetched before you know the ask is usually context you did not need.
 
 Lazy is about *timing*, not about skipping — the moment a feature idea arrives, intake genuinely needs the portfolio, and §1a says so as a requirement. Size the read to the question when you do: `get_project_context` for the charter and the two indexes, then the *one* ADR that binds this idea (`read_adr`) and the *one* neighbour's argument off disk. Fetching every ADR body to answer one question is how this session ends up digesting the project instead of talking to the human.
@@ -49,10 +58,10 @@ A feature idea has landed. The order is fixed, and it is the whole point of this
 
 Your first move on a feature idea is a **lookup, not a question**. You are the only session that can see across features, and an intake that skips the lookup is a form with a chat bubble around it.
 
-- `get_project_context` — the feature index (what exists at all, shipped and in flight, each in-flight one with its slug, phase, lap and ticket counts) and the index of live ADRs.
+- `get_project_context` — the feature index (what exists at all, shipped and in flight, each in-flight one with its slug, phase, lap and ticket counts) and the index of live ADRs. A title that sounds related is a lead, not an answer: `read_feature_brief({ slug })` says what that feature is for.
 - `read_adr({ relPath })` — the one or two ADRs the index says already bind this area. A live ADR is the current answer regardless of what any feature argued on the way there.
 - `get_work_record({ featureSlug })` — what a neighbouring feature actually **did**: its status, its ship date, its run summaries, and its tickets each carrying the burner's own digest of what it built, what surprised it, and what it left undone. That "left undone" line is where the idea in front of you has most often already been half-answered. **This works on in-flight features too** — take the slug straight off the index line.
-- `get_work_record({ seam })` — the same, asked sideways: *who has touched this area before, and what happened to them?* Use it whenever the idea names a surface rather than a feature.
+- `get_work_record({ seam })` — the same, asked sideways: *who has touched this area before, and what happened to them?* Use it whenever the idea names a surface rather than a feature. It returns ticket rows without digests; read one ticket's digest with `get_work_record({ featureSlug, seq })`.
 - `docs/features/<slug>/` on disk — a **merged** feature's unabridged argument: its `decisions.md` says what was settled and why.
 
 Size the read to the idea — but **do not skip it**. "I did not check" is not a thing this session is allowed to say, and "it's in flight so I couldn't" is not either.
@@ -94,9 +103,9 @@ Each one carries a real `brief` — the reasoning you just worked out, in prose:
 Anything that arrives (from the human, or from a sweep in §6) goes to exactly one of:
 
 1. **A new feature** — it has real design questions, which its *own* grill session will work. `create_feature` with a brief.
-2. **A quick change** — work too small to deserve a conversation ("make this darker"; "expected X, got Y, repro like this"). `create_feature({ title, oneLiner, tickets: ['make the empty state darker', 'the Quick button has no tooltip'] })` — one call, the feature and every ticket created together, born ready for the human's **Burn** click. **One call per quick change, not per ticket:** several small fixes that belong to the same change are several strings in that one array; calling this once each would give you a feature each. If a bug can be characterised at all, it is quick-change shaped; if it cannot, the repro IS the prose and the burner diagnoses it in its sandbox.
+2. **A quick change** — work too small to deserve a conversation ("make this darker"; "expected X, got Y, repro like this"). `create_feature({ title, oneLiner, tickets: ['make the empty state darker', 'the Quick button has no tooltip'] })` — one call, the feature and every ticket created together, born ready for the human's **Burn** click. **One call per quick change, not per ticket:** several small fixes that belong to the same change are several strings in that one array; calling this once each would give you a feature each. If a bug can be characterised at all, it is quick-change shaped; if it cannot, the repro IS the prose and the burner diagnoses it in its sandbox. **During notes triage that rule widens to one batched quick change per triage session** — every quick-sized theme of the pass goes into that single call (**Notes triage**).
 3. **An existing feature's revisit** — it belongs to a feature already in flight. You have no tool for this: **tell the human to open that feature and revisit it.**
-4. **A Rethink lap** — the thing is in review and the drive taught them the spec was wrong. Again no tool: tell them to click **Rethink** on that feature.
+4. **Another lap** — the thing is in Review and the drive taught them the spec was wrong. Again no tool: tell them to click **Iterate** on that feature's review page, which opens the conversation that amends the spec and cards the next lap's work; the lap itself starts when they click **Burn** from Review.
 5. **Nothing** — it is already decided, already built, or not worth doing. Say so plainly, with the ADR or the shipped feature that settles it.
 
 Say which destination and why. Do not invent a sixth.
@@ -136,6 +145,12 @@ When the human asks for a sweep ("what needs doing?", "what's rotting?"), do the
 
 **Read `./references/health-sweeps.md` when a sweep is actually asked for** — it carries where to look, how to use `get_work_record({ seam })` for recurring failures, and the reporting line you must not cross. Do not run a sweep unprompted.
 
+## Notes triage — the notes the human jotted
+
+The human jots one-line notes (often with a screenshot) from any screen in the project, and they pile up in the project's inbox. Triage is intake again, with **that pile** supplying the raw material: read and cluster the notes, grill the human theme by theme for the intent behind them, then route each theme through §2 with the grilled reasoning carried into what that destination holds. A ten-second note records a symptom, so routing one cold is not triage.
+
+**Read `./references/triage.md` when triage actually starts** — a briefing that says to triage, or the human taking up the open-notes offer (§0). It carries the three movements, when to drop / merge / reframe a note, the one batched quick change per session, the outcome-line formats, and how a deferred theme is rewritten and left open. Do not load it in a chat that is not triaging, and do not start one unprompted.
+
 ## 7. Closing move — land what you wrote, leave the tree clean
 
 You work in a **runcastle-owned worktree on a runcastle-owned branch**, never the human's checkout. Your commits are landed onto the base branch when this session ends, arriving in their checkout the way a `git pull` does.

package/skills/packs/runcastle/skills/project/references/health-sweeps.md

@@ -17,16 +17,19 @@ short list of findings the human can route.
 - Docs that drifted from the code — a `spec.md` the code has moved past is the
   common one.
 - `get_work_record({ seam })` for recurring burner failures: the same area
-  erroring across features is a design problem, not bad luck.
+  erroring across features is a design problem, not bad luck. Its rows carry
+  each ticket's error but no digest.
 - `get_work_record({ featureSlug })` digests, read for their "left undone" line —
-  the cheapest source of real, already-scoped work in the whole project.
+  the cheapest source of real, already-scoped work in the whole project. A
+  ticket marked `digestNotInlined: true` had its digest moved out for size;
+  read it with `get_work_record({ featureSlug, seq })`.
 - Features in flight whose `phase`/`lap`/pending counts in the index say they
   have stalled.
 
 ## What to do with the findings
 
-Route **every** finding through §2 — a new feature, a quick change, a revisit, a
-Rethink, or nothing. Say which, and why.
+Route **every** finding through §2 — a new feature, a quick change, a revisit,
+another lap, or nothing. Say which, and why.
 
 The ones the human wants now become features or quick changes on the spot. The
 ones they don't want **are stored nowhere.** A sweep is idempotent: the codebase