@joshuafolkken/kit 1.1455.0 → 1.1514.0

package/.claude/skills/workflow-commands/split-assessment.md

@@ -1,52 +1,41 @@
 # The split assessment — one definition, every entry point
 
-Before any entry point starts work on an Issue, decide whether the request is really **one**
-deliverable or several. This file is the single definition; every command applies it identically.
+Before any entry point starts work on an Issue, decide whether the request is **one** deliverable or
+several. Every command applies it identically.
 
 ## The question
 
-**The default is not to split.** Two questions have to answer yes **together**; either one alone
-leaves the work as one Issue:
+**The default is not to split.** Two questions have to answer yes **together**:
 
 1. **Does the request contain two or more deliverables that could each be merged separately?**
 2. **Does the whole of it clearly exceed what one verification gate can confirm in one pass?** The
    guide is **about 10 changed files and about 400 changed lines** (test files excluded).
    Under that, it is one Issue however many separable pieces a reader can name inside it.
 
-Separately mergeable is still the first test, and it is unchanged: a change that must land in one
-commit to be correct is one deliverable however big it is. What changed is that **separability alone
-no longer splits anything** — it is now a necessary condition rather than a sufficient one.
-
-**The guide is a guide, and "clearly" is the operative word.** A run that has to argue itself past the
-numbers has already answered no. They are read against the whole request's estimate, not against the
-diff a first pass happens to produce, and a request that lands at 11 files is not thereby a split.
+A change that must land in one commit to be correct is one deliverable however big it is; **separability
+alone no longer splits anything**. **"Clearly" is the operative word** — a run that has to argue past
+the numbers has answered no. They are read against the whole request's estimate, and 11 files is not
+thereby a split.
 
 ## The same two questions decide the filing-time fold
 
 **The entry's split decision and the filing-time fold decision are the same two conditions, stated
-here once.** This assessment asks whether *one request* is several deliverables; the fold decision asks
-whether *several findings from one session* are one Issue — and reads the **same two questions in the
-same conjunction**: separability, and whether the whole clearly exceeds one gate.
-`pnpm josh issue:fold "<title>" …` answers `fold` / `separate` / `no-fold-needed`; its size half is
-`pnpm josh split:assess`, called not recomputed, and `separate` needs both halves exactly as `split`
-does. A diff with no non-test file, or none readable, answers `undetermined`: the size is then the
-whole request's estimate above. **There is no second criterion.** `observation-filing.md`'s observation, the review round cap's branch 2 and `prerequisite.md`'s
+here once** — the fold asks whether *several findings from one session* are one Issue, with the same
+conjunction. `pnpm josh issue:fold "<title>" …` answers `fold` / `separate` / `no-fold-needed`; its size
+half is `pnpm josh split:assess`, called not recomputed. A diff with no readable non-test file answers
+`undetermined`, and the size is the request's estimate. **There is no second criterion.**
+`observation-filing.md`'s observation, the review round cap's branch 2 and `prerequisite.md`'s
 prerequisite each route a second filing through it — `pnpm josh issue:file` asks it itself at the
 run's second filing, never the first, and holds only a `fold`.
 
 ## Diff size is not a reason to split, and that is measured
 
-**Size is a bar a split has to clear; it is never a reason to split.** Question 2 is a *minimum* — below
-it the work stays whole — and nothing makes a large diff a reason to divide one. **A proposal to add a
-size threshold that splits more is required to say why the round-1 measurement does not reach it.**
-Rationale: `docs/maintainers/split-assessment-rationale.md` → "Why the default is not to split" and
-`docs/maintainers/split-assessment-rationale.md` → "Why diff size is not a reason to split".
+**Size is a bar a split has to clear; it is never a reason to split.** **A proposal to add a size
+threshold that splits more is required to say why the round-1 measurement does not reach it.**
 
-**The size half is measured, not eyeballed — `pnpm josh split:assess`.** It counts the branch's
-changed files and changed lines with test files excluded and answers `split` / `single` on size
-alone, so the guide can be checked against real diffs after the fact rather than trusted from an
-estimate. It answers the **size** question only; separability (question 1) stays a judgement, which is
-why a `split` from this command is the size condition met, not a decision to divide the Issue.
+**The size half is measured, not eyeballed — `pnpm josh split:assess`** counts the branch's changed
+files and lines, test files excluded, and answers `split` / `single` on size alone. Separability stays
+a judgement, so its `split` is the size condition met, not a decision to divide.
 
 ## What each entry point does with the answer
 
@@ -59,26 +48,19 @@ why a `split` from this command is the size condition met, not a decision to div
 
 ## A prerequisite is not a split
 
-"This needs something else done first" is a different answer from "this is really several things". A
-split means the request in hand contains two or more deliverables; a prerequisite means it is still
-**one** deliverable that has another one in front of it. The prerequisite rule is `prerequisite.md`, its
-single source; each entry's own branch is in `backlogrun-park.md` → "A prerequisite discovered mid-run" and, for
-the stopping entry points, in `fullrun.md` / `halfrun.md`.
+A split means the request contains several deliverables; a prerequisite means it is **one** deliverable
+with another in front of it. `prerequisite.md` is the single source; each entry's branch is in
+`backlogrun-park.md` → "A prerequisite discovered mid-run" and `fullrun.md` / `halfrun.md`.
 
 ## Two or more always means an epic
 
 **Splitting into two or more Issues always creates an epic. There is no count threshold and no ordering
-condition to evaluate.** This is about what follows a split, never about whether to make one — the bar
-for that is "The question" above. **An entry point that applies a different condition is a defect** —
-the whole point of one definition is that where the split was noticed cannot change what happens next.
-
-The epic is the non-closing home for the split rationale. A comment on the first child is buried the
-moment that child merges and closes.
+condition to evaluate.** **An entry point that applies a different condition is a defect.** The epic
+is the non-closing home for the split rationale.
 
 **Each split child is filed with the `route:split` label** —
-`pnpm josh issue:file "<sub-title>" --body-file <body-file> --depth <n> --route split` — so the
-backlog's composition stays countable by filing route rather than by grepping issue bodies. Each child
-is judged for `auto-ok` like any filing (`kickoff.md` → "Words typed after `new`").
+`pnpm josh issue:file "<sub-title>" --body-file <body-file> --depth <n> --route split` — and judged for
+`auto-ok` like any filing (`kickoff.md` → "Words typed after `new`").
 
 ## Promote, or create a new epic
 
@@ -87,33 +69,25 @@ on the Issue, without asking.
 
 - **`#N` is a request, a discussion, or a container → promote it.**
   `pnpm josh epic --promote <N> <N1> <N2> ... [--ordered]`. The body is appended to, never replaced.
-- **`#N` is itself one of the deliverables → keep `#N` as a child and create a new epic.** A bug report
-  that turns out to need three fixes is the case: promoting the report would leave the report itself
-  with nowhere to live.
+- **`#N` is itself one of the deliverables → keep `#N` as a child and create a new epic** — e.g. a bug
+  report that needs three fixes.
 
 ## `backlogrun` is the one entry that does not stop
 
-`backlogrun` asked for the batch's authorization, so a split found under it is filed and continued through
-rather than stopped — including when the `backlogrun` was given a bare, non-epic Issue, where the split is
-what creates the epic (`backlogrun-child.md` → "When `#N` is not an epic"). The assessment itself is identical;
-only what follows the answer differs.
+A split found under `backlogrun` is filed and continued through — including from a bare, non-epic
+Issue, where the split creates the epic (`backlogrun-child.md` → "When `#N` is not an epic").
 
 ## Finding a split mid-run stops the run
 
-`fullrun` and `halfrun` **stop** after filing the children and the epic. They do not continue into
-implementation, and they do not silently become a `backlogrun`. Typing `fullrun` approved implementing and
-merging **one** Issue; a batch of N is a different authorization. Report what was filed and end with:
+`fullrun` and `halfrun` **stop** after filing the children and the epic — typing `fullrun` approved
+**one** Issue. Report what was filed and end with:
 
 > Please run `backlogrun #<E> --only` to execute this epic.
 
 ## There is no `kickoff epic`
 
-A separate keyword for "split this conversation into an epic" would duplicate `kickoff new` exactly,
-leaving a person to decide which of two commands to type for one job. The assessment above is how a
-split is reached from every entry.
+It would duplicate `kickoff new`; the assessment above reaches a split from every entry.
 
 ## Issues filed separately, found related later
 
-Issues that were filed at different times and turn out to be related afterwards are **not** a split — a
-split is about one request in hand containing several deliverables. That case is outside this
-assessment, and `pnpm josh epic --promote` is what handles it.
+Not a split — `pnpm josh epic --promote` handles it.

package/.claude/skills/workflow-commands/target-repository.md

@@ -2,8 +2,7 @@
 
 **This file is the prefix's single source, read at its point of use — the moment an entry is typed with an
 `owner/repo#` prefix (or a short `repo#` name), not at any entry.** A run given a bare `#N` or `new`
-targets the session's own repository and never reaches it. `SKILL.md` → §2's table keeps the trigger and
-points here. Rationale: `docs/maintainers/target-repository-rationale.md` → "Why the prefix reads as it does".
+targets the session's own repository and never reaches it.
 
 Every entry point takes the target repository in front of the Issue reference. Without it the target
 is the repository the session runs in.

package/.claude/skills/workflow-commands/working-tree-hold.md

@@ -1,12 +1,10 @@
 # The working-tree hold — one run per tree
 
-**The single source of the hold**, read at its point of use — the moment a run is about to claim or
-release the tree. History: `docs/maintainers/working-tree-hold-rationale.md` → "Where each rule came from".
+Read the moment a run is about to claim or release the tree.
 
-**Ask `pnpm josh run:hold` before anything else, and obey what it answers.** It is the first call of
-`fullrun` and `halfrun` alike — before the title is normalized, before `pnpm josh ms`, and **before
-a `new` entry files its Issue**, because a run stopped after the filing has already left behind the
-artifact it should not have created.
+**Ask `pnpm josh run:hold` before anything else, and obey what it answers** — the first call of
+`fullrun` and `halfrun`, before the title, before `pnpm josh ms`, and **before a `new` entry files its
+Issue**.
 
 ```bash
 pnpm josh run:hold <N>        # a `#N` entry point
@@ -17,81 +15,64 @@ pnpm josh run:release --force # a record left behind by a run that has ended
 ```
 
 - **`hold` — this run now holds the tree. Continue.**
-- **`busy` — another run holds it. Stop.** Send a `confirmation` Telegram carrying what the command
-  printed on stderr (the holder, when the record was written, and the release command) and stop.
-  **File nothing, create no branch, edit nothing.**
+- **`busy` — another run holds it. Stop.** Send a `confirmation` Telegram carrying its stderr (the
+  holder, when the record was written, the release command). **File nothing, create no branch, edit
+  nothing.**
 - **`unknown` — nothing was established. Stop the same way.** It is not "the tree is free".
 
 **The unit is the working tree** — one branch, one index and one uncommitted diff, and a linked work
-tree has its own three. **`backlogrun`'s per-repository guard (`epic-busy.ts`) is a separate layer and is
-unchanged.**
-
-**`kickoff` does not claim it** — it touches GitHub, never the branch, index or diff. Rationale for both:
-`docs/maintainers/working-tree-hold-rationale.md` → "Why the unit is the working tree".
-
-**Claim it in the checkout the run will edit.** The record is keyed to the work tree the command runs
-in, so a cross-repository `fullrun owner/repo#N` resolves that repository's checkout from `pnpm josh
-doctor` **first** — that resolution is a read and writes nothing — and claims there.
-
-**A release names the run it belongs to.** `pnpm josh run:release <N>` removes the record only where the
-record names `<N>`, the bare form only the unnumbered run's, and a record belonging to anything else
-answers **`held`** and is left standing. **`pnpm josh run:release --force` is the one spelling that
-removes a record this run did not write**, and the `busy` stop message names it rather than the
-ordinary one.
-
-**Release what the claim recorded, which is not always the Issue number.** A `#N` entry claimed `<N>`
-and releases `<N>`; a **`new` entry claimed before its Issue existed**, so it releases with the
-**bare** form however many numbers the run has acquired since — so a `fullrun new` that stops on a
-split types `pnpm josh run:release`, not `pnpm josh run:release <N>`. The bare form removes no
-label, so every `new` stop that releases — a split, a prerequisite or a third-party target — also runs `gh api -X DELETE repos/{owner}/{repo}/issues/<N>/labels/in-progress
-2>/dev/null || true`.
-
-**Releasing is the run's, not a person's memory.** `pnpm josh followup` releases the hold on a merged
-run, and a record abandoned by a crashed session expires after 8 hours. **A stop that leaves the tree
-clean releases it explicitly**: a `fullrun` / `halfrun` that stops on a split, a prerequisite or a
-third-party target ends with `pnpm josh run:release <N>` (bare where that run entered as `new`, followed by the label DELETE above).
-**`halfrun`'s stop before commit keeps the hold**, and so does a `needs-human-review` stop: the
-uncommitted work still in the tree is exactly what a second run would trample, so the release command
-goes in the stop report and the Telegram for the person to type. **`fullrun #<N>` of the same issue
-adopts a `halfrun`'s kept hold** rather than being refused `busy` by it — "The halfrun resume" below. **An expired record over a tree that
-still has uncommitted changes does not free it**: the command answers `busy` and says to commit, stash,
-or release once the work is done; only an expired record over a clean tree is replaced.
-
-**The batch entry points claim per child, not per batch.** `backlogrun` never
-call it themselves; each child runs the `fullrun` procedure, so it claims on entry and `pnpm josh
-followup` releases it at that child's merge. The command's behavior and the answer table are
-`docs/josh-commands-run.md` → "`josh run:hold` / `josh run:release`"; this file is the single source of
-the procedure.
+tree has its own three. **`backlogrun`'s per-repository guard (`epic-busy.ts`) is a separate layer.** **`kickoff`
+does not claim it.**
+
+**Claim it in the checkout the run will edit** — a cross-repository `fullrun owner/repo#N` resolves
+that checkout from `pnpm josh doctor` **first** (a read) and claims there.
+
+**A release names the run it belongs to.** `pnpm josh run:release <N>` removes only a record naming
+`<N>`, the bare form only the unnumbered run's; anything else answers **`held`** and stands. **`pnpm
+josh run:release --force` is the one spelling that removes a record this run did not write**, and the
+`busy` message names it.
+
+**Release what the claim recorded.** A `#N` entry releases `<N>`; a **`new` entry claimed before its
+Issue existed**, so it releases with the **bare** form — a `fullrun new` that stops on a split types
+`pnpm josh run:release`. The bare form removes no label, so every `new` stop that releases also runs
+`gh api -X DELETE repos/{owner}/{repo}/issues/<N>/labels/in-progress 2>/dev/null || true`.
+
+**Releasing is the run's, not a person's memory.** `pnpm josh followup` releases on a merged run; an
+abandoned record expires after 8 hours. **A stop that leaves the tree clean releases it explicitly** —
+a split, a prerequisite or a third-party target ends with `pnpm josh run:release <N>` (bare for a `new`
+entry, plus the label DELETE). **`halfrun`'s stop before commit keeps the hold**, as does a
+`needs-human-review` stop: the release command goes in the stop report and the Telegram for the person
+to type. **`fullrun #<N>` of the same issue adopts a `halfrun`'s kept hold** — "The halfrun resume"
+below. **An expired record over a tree that still has uncommitted changes does not free it** — it
+answers `busy`; only an expired record over a clean tree is replaced.
+
+**The batch entry points claim per child, not per batch** — each `backlogrun` child claims on entry and
+`pnpm josh followup` releases at its merge. The answer table is `docs/josh-commands-run.md` → "`josh
+run:hold` / `josh run:release`".
 
 ## The halfrun resume
 
-**`fullrun #<N>` or `prrun #<N>` after a `halfrun` stop resumes it instead of claiming.** The
-stop is **recorded, never inferred**: the `halfrun` ends with `pnpm josh run:hold <N> --halfrun-stop`,
-which marks its own record (re-keying a `halfrun new`'s unnumbered one to the filed issue) — a
-`halfrun` still implementing or a `backlogrun` child leaves the same hold over the same dirty tree, and
-must not be adopted. On a marked hold for `#<N>` over a dirty tree, `run:entry` asks the session budget
-(`over` stops as usual), adopts the hold with the `fullrun` mark and prints `entry #<N> — resume:
-halfrun`. **Skip the title, the plan, the split assessment, `pnpm josh ms`,
-`latest:scope` and the implementation**: the diff in the tree is what the person verified. Re-read the
-issue (`pnpm josh issue:read <N>`), then run the gate **in full** from the refactor (`chain-rule.md` →
-"Run the review-to-merge chain") — a fix made during the manual check has had no gate — and ship as
-any `fullrun` does.
+**`fullrun #<N>` or `prrun #<N>` after a `halfrun` stop resumes it instead of claiming.** The stop is
+**recorded, never inferred**: the `halfrun` ends with `pnpm josh run:hold <N> --halfrun-stop`, marking
+its record (re-keying a `halfrun new`'s unnumbered one) — a `halfrun` still implementing or a
+`backlogrun` child leaves the same dirty tree and is not adopted. On a marked hold for `#<N>`,
+`run:entry` asks the session budget, adopts the hold and prints `entry #<N> — resume: halfrun`. **Skip
+the title, the plan, the split assessment, `pnpm josh ms`, `latest:scope` and the implementation**;
+re-read the issue (`pnpm josh issue:read <N>`), run the gate **in full** from the refactor
+(`chain-rule.md` → "Run the review-to-merge chain"), and ship as any `fullrun` does.
 
 ## The prrun resume
 
-**`fullrun #<N>` after a `prrun` stop resumes it the same way.** The `prrun`
-ends with `pnpm josh run:hold <N> --prrun-stop`, which writes the commit its pull request is on into its
-own record; only a record carrying that commit is adopted. `run:entry` asks the session budget, adopts
-the hold with the `fullrun` mark and prints one of three tokens — read, never inferred:
-
-- **`resume: prrun-merged`** — a person merged the pull request. Run `pnpm josh followup "<title>
-  #<N>"` alone: it detects the merge and runs only the post-merge tail.
-- **`resume: prrun-merge`** — the branch is still on the stop's commit, both here and on the pull
-  request, and the tree is clean, so what was verified is what would merge. Skip the gate and the
-  review; run `pnpm josh followup` to merge.
-- **`resume: prrun-gate`** — the branch moved (locally, or by a push made on GitHub), its pull request
-  could not be read, or the tree is dirty: a person changed something. Run the
-  gate **in full** and the review (`chain-rule.md` → "Run the review-to-merge chain"), then ship as any
-  `fullrun` does.
+**`fullrun #<N>` after a `prrun` stop resumes it the same way.** The `prrun` ends with `pnpm josh
+run:hold <N> --prrun-stop`, which records its pull request's commit; only a record carrying it is
+adopted. `run:entry` prints one of three tokens — read, never inferred:
+
+- **`resume: prrun-merged`** — a person merged it. Run `pnpm josh followup "<title> #<N>"` alone; it
+  runs only the post-merge tail.
+- **`resume: prrun-merge`** — branch and pull request still on the stop's commit, tree clean. Skip the
+  gate and the review; run `pnpm josh followup` to merge.
+- **`resume: prrun-gate`** — the branch moved, its pull request could not be read, or the tree is
+  dirty. Run the gate **in full** and the review (`chain-rule.md` → "Run the review-to-merge chain"),
+  then ship.
 
 All three skip the title, the plan, the split assessment and the implementation.

package/.codex/hooks.json

@@ -6,7 +6,7 @@
 				"hooks": [
 					{
 						"type": "command",
-						"command": "project_root=\"$(env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_NAMESPACE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE git rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)\" && cd \"$project_root\" && sh scripts/hooks/run-hook.sh audit-provision",
+						"command": "if project_root=\"$(unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; git rev-parse --show-toplevel 2>/dev/null)\"; then unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; else project_root=\"$(git rev-parse --show-toplevel)\"; fi && cd \"$project_root\" && sh scripts/hooks/run-hook.sh audit-provision",
 						"timeout": 180
 					}
 				]
@@ -17,7 +17,7 @@
 				"hooks": [
 					{
 						"type": "command",
-						"command": "project_root=\"$(env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_NAMESPACE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE git rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)\" && cd \"$project_root\" && sh scripts/hooks/run-hook.sh session-lang",
+						"command": "if project_root=\"$(unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; git rev-parse --show-toplevel 2>/dev/null)\"; then unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; else project_root=\"$(git rev-parse --show-toplevel)\"; fi && cd \"$project_root\" && sh scripts/hooks/run-hook.sh session-lang",
 						"timeout": 10
 					}
 				]
@@ -25,11 +25,11 @@
 		],
 		"PreToolUse": [
 			{
-				"matcher": "Bash|Edit|Read|Write|AskUserQuestion|apply_patch",
+				"matcher": "Bash|Edit|Read|Write|AskUserQuestion|Agent|Task|apply_patch",
 				"hooks": [
 					{
 						"type": "command",
-						"command": "project_root=\"$(env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_NAMESPACE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE git rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)\" && cd \"$project_root\" && sh scripts/hooks/run-hook.sh codex-hook-adapter pretool",
+						"command": "if project_root=\"$(unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; git rev-parse --show-toplevel 2>/dev/null)\"; then unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; else project_root=\"$(git rev-parse --show-toplevel)\"; fi && cd \"$project_root\" && sh scripts/hooks/run-hook.sh codex-hook-adapter pretool",
 						"timeout": 20
 					}
 				]
@@ -41,7 +41,7 @@
 				"hooks": [
 					{
 						"type": "command",
-						"command": "project_root=\"$(env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_NAMESPACE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE git rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)\" && cd \"$project_root\" && sh scripts/hooks/run-hook.sh codex-hook-adapter posttool",
+						"command": "if project_root=\"$(unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; git rev-parse --show-toplevel 2>/dev/null)\"; then unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; else project_root=\"$(git rev-parse --show-toplevel)\"; fi && cd \"$project_root\" && sh scripts/hooks/run-hook.sh codex-hook-adapter posttool",
 						"timeout": 90
 					}
 				]
@@ -53,7 +53,7 @@
 				"hooks": [
 					{
 						"type": "command",
-						"command": "project_root=\"$(env -u GIT_ALTERNATE_OBJECT_DIRECTORIES -u GIT_COMMON_DIR -u GIT_DIR -u GIT_INDEX_FILE -u GIT_NAMESPACE -u GIT_OBJECT_DIRECTORY -u GIT_WORK_TREE git rev-parse --show-toplevel 2>/dev/null || git rev-parse --show-toplevel)\" && cd \"$project_root\" && sh scripts/hooks/run-hook.sh stop-guard",
+						"command": "if project_root=\"$(unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; git rev-parse --show-toplevel 2>/dev/null)\"; then unset GIT_ALTERNATE_OBJECT_DIRECTORIES GIT_COMMON_DIR GIT_DIR GIT_INDEX_FILE GIT_NAMESPACE GIT_OBJECT_DIRECTORY GIT_WORK_TREE; else project_root=\"$(git rev-parse --show-toplevel)\"; fi && cd \"$project_root\" && sh scripts/hooks/run-hook.sh stop-guard",
 						"timeout": 20
 					}
 				]

package/.github/actions/setup-node/action.yml

@@ -26,7 +26,7 @@ runs:
   using: composite
   steps:
     - name: Setup Node.js
-      uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
+      uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0
       with:
         node-version: '24'
         registry-url: ${{ inputs.registry-url }}

package/.github/workflows/ci.yml

@@ -493,7 +493,7 @@ jobs:
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
 
       - name: Run security audit
-        uses: google/osv-scanner-action/osv-scanner-action@a345acffa64b0eaede81a3d9aae6141214d9c8fc # v2.6.0
+        uses: google/osv-scanner-action/osv-scanner-action@b1d267aea5211fa648d9d442fa64b90dbdcbdd36 # v2.7.0
         with:
           scan-args: --lockfile=pnpm-lock.yaml
 

package/.github/workflows/publish.yml

@@ -83,7 +83,7 @@ jobs:
         env:
           LATEST: ${{ steps.registry-latest.outputs.latest }}
 
-      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
         with:
           name: kit-package
           path: ${{ runner.temp }}
@@ -126,7 +126,7 @@ jobs:
         with:
           cache: 'false'
 
-      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
+      - uses: actions/download-artifact@9000827ccba6bdab643e8b6fd33ac0654aef8333 # v8.0.2
         with:
           name: kit-package
           path: ${{ runner.temp }}

package/CLAUDE.md

@@ -7,13 +7,14 @@ Stack: TypeScript · pnpm · SvelteKit · Vitest · Playwright · TailwindCSS ·
 ## Communication
 
 - **Answer opinion-seeking questions from a neutral standpoint.** A leading question is not a cue to agree — recommend the option you genuinely judge best.
-- **Fix root causes, not symptoms.** Where the proper fix is out of scope, surface the root cause instead of papering over it.
+- **Fix root causes, not symptoms.** Where the proper fix is out of scope, surface it instead of papering over it.
 - **Cross-package problems → file the upstream Issue, then stop.** A defect in another package (a dependency, or `josh` / kit tooling) is never worked around locally — **weakening a verification gate is a workaround too**. File it (first-party Tier A, third-party Tier C) and stop. `prompts/collaboration-workflow/upstream-interrupt.md`. Your own repository's run tooling is not another package: `upstream-interrupt.md` → "実行中のリポジトリ自身のラン機構の不具合".
 - **Third-party repositories are Tier C.** Decide the party with `pnpm josh repo:party`; every write to a tracker we do not own needs explicit current-turn instruction. `prompts/collaboration-workflow/upstream-interrupt.md`.
 - **No clones — single-source, even across package boundaries.** Duplicate non-trivial logic only after presenting the alternative and getting explicit approval. `prompts/collaboration-workflow/principles.md` → "no-clones".
 - **Design for elegance and simplicity first.** Before adding a hook, guard, rule or abstraction, ask whether fixing the cause makes it unnecessary. `prompts/collaboration-workflow/principles.md` → "elegant-design"; conflicting quality goals → "quality-priority".
+- **Write concise prose: conditions and actions only.** `prompts/collaboration-workflow/principles.md` → "concise-prose".
 - **Distinguish consultation from execution.** A question or goal statement asks for analysis only — act on an explicit imperative or a workflow keyword. `prompts/collaboration-workflow/principles.md` → "consult-vs-execute".
-- **Route distributed-doc / config changes upstream to kit.** In a consumer repo never edit kit-distributed docs/config (`josh sync` overwrites them); in kit you are the source. `prompts/collaboration-workflow/principles.md` → "upstream-to-kit".
+- **Route distributed-doc / config changes upstream to kit.** In a consumer repo never edit kit-distributed docs/config; in kit you are the source. `prompts/collaboration-workflow/principles.md` → "upstream-to-kit".
 - **Latest-first, fix forward — pin back only as a last resort.** `prompts/collaboration-workflow/principles.md` → "latest-first".
 - **Output language follows `JOSH_SESSION_LANG`** (default `ja`) for session output and artifact prose; English for Issue/PR titles, code comments, test titles, commit messages and script strings. `prompts/collaboration-workflow/overview.md`.
 - **Durable rules belong in prompts/docs, not local MEMORY.** `prompts/collaboration-workflow/principles.md` → "durable-rules".
@@ -31,16 +32,16 @@ Log auto-decisions: an Issue comment in an Issue workflow, else a one-line "Auto
 
 ## Critical Conventions (non-standard — always apply)
 
-Naming, exports, file names and content rules are enforced by `eslint/rules/`; their single source is `prompts/coding-standards.md` → "Conventions". `function` syntax, not arrows (named SvelteKit route handlers may use the typed-const arrow idiom) — lint does not check it.
+Naming, exports, file names and content rules are enforced by `eslint/rules/`; their single source is `prompts/coding-standards.md` → "Conventions". `function` syntax, not arrows (named SvelteKit route handlers may use typed-const arrows); lint does not check it.
 
 ### Quality limits
 
-- Function complexity ≤5 · nesting ≤2 · function ≤25 lines · file ≤300 lines · params ≤4 · statements per function ≤10 · cognitive complexity ≤4 — line counts are code lines, not physical lines (`pnpm josh lint`); test files allow 35 code lines per function.
+- Function complexity ≤5 · nesting ≤2 · function ≤25 lines · file ≤300 lines · params ≤4 · statements per function ≤10 · cognitive complexity ≤4 — line counts are code lines, not physical lines; test functions allow 35 code lines.
 - No magic numbers beyond `0`, `1`, `-1` · no `any` · restricted `as` · explicit param and return types · single short early return → one-liner `if (x) return y`.
 
 ## Package-First Development
 
-Before building a feature, check for a well-maintained package — measure with `pnpm josh pkg:scout <keywords>`: `clear` → select it (Tier A), `close` → ask (Tier B).
+Before building a feature, run `pnpm josh pkg:scout <keywords>`: `clear` → use it (Tier A), `close` → ask (Tier B).
 
 ## Code Change Rules
 
@@ -79,7 +80,7 @@ Never start a `kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun` workflo
 
 #### Mid-workflow stop notification (`confirmation`)
 
-Before pausing **any** run for the user — a command's stop, an upstream-Issue interrupt, a Tier C confirmation — send once per stop (skip when the user asked for the stop this turn):
+The `Stop` hook sends it when your held run awaits a decision — lead with the reason, end with `Recommended: <choice>`. Send it yourself only when the hook refuses the stop:
 
 ```bash
 pnpm josh notify --task-type confirmation --issue-url "<url>" --body=$'<reason>' --recommended "<choice>" --alternative "<other>"

package/cspell/index.yaml

@@ -26,11 +26,17 @@ ignorePaths:
   # joshuafolkken/kit#1347: `josh lint:related` has its own for the same reason — an implementation
   # loop calls it while the gate lints the whole tree, and two eslint runs on one cache file discard
   # each other's entries.
+  # joshuafolkken/kit#3948: prettier's gate and scoped caches, and the pre-commit hook's own cspell and
+  # eslint caches — a staged-files run on the gate's file would prune or narrow it.
   - '**/.eslintcache'
   - '**/.eslintcache.edit'
   - '**/.eslintcache.related'
+  - '**/.eslintcache.commit'
   - '**/.tsbuildinfo'
   - '**/.cspellcache'
+  - '**/.cspellcache.commit'
+  - '**/.prettiercache'
+  - '**/.prettiercache.related'
   - '**/.gitignore'
   - '**/pnpm-lock.yaml'
   - '**/.vscode/**'
@@ -110,6 +116,7 @@ words:
   - domcontentloaded
   - esbuild
   - eslintcache
+  - prettiercache
   - fetchpriority
   - fullrun
   - halfrun

package/dist/CLAUDE.md

@@ -7,13 +7,14 @@ Stack: TypeScript · pnpm · SvelteKit · Vitest · Playwright · TailwindCSS ·
 ## Communication
 
 - **Answer opinion-seeking questions from a neutral standpoint.** A leading question is not a cue to agree — recommend the option you genuinely judge best.
-- **Fix root causes, not symptoms.** Where the proper fix is out of scope, surface the root cause instead of papering over it.
+- **Fix root causes, not symptoms.** Where the proper fix is out of scope, surface it instead of papering over it.
 - **Cross-package problems → file the upstream Issue, then stop.** A defect in another package (a dependency, or `josh` / kit tooling) is never worked around locally — **weakening a verification gate is a workaround too**. File it (first-party Tier A, third-party Tier C) and stop. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/upstream-interrupt.md`. Your own repository's run tooling is not another package: `upstream-interrupt.md` → "実行中のリポジトリ自身のラン機構の不具合".
 - **Third-party repositories are Tier C.** Decide the party with `pnpm josh repo:party`; every write to a tracker we do not own needs explicit current-turn instruction. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/upstream-interrupt.md`.
 - **No clones — single-source, even across package boundaries.** Duplicate non-trivial logic only after presenting the alternative and getting explicit approval. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "no-clones".
 - **Design for elegance and simplicity first.** Before adding a hook, guard, rule or abstraction, ask whether fixing the cause makes it unnecessary. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "elegant-design"; conflicting quality goals → "quality-priority".
+- **Write concise prose: conditions and actions only.** `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "concise-prose".
 - **Distinguish consultation from execution.** A question or goal statement asks for analysis only — act on an explicit imperative or a workflow keyword. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "consult-vs-execute".
-- **Route distributed-doc / config changes upstream to kit.** In a consumer repo never edit kit-distributed docs/config (`josh sync` overwrites them); in kit you are the source. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "upstream-to-kit".
+- **Route distributed-doc / config changes upstream to kit.** In a consumer repo never edit kit-distributed docs/config; in kit you are the source. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "upstream-to-kit".
 - **Latest-first, fix forward — pin back only as a last resort.** `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "latest-first".
 - **Output language follows `JOSH_SESSION_LANG`** (default `ja`) for session output and artifact prose; English for Issue/PR titles, code comments, test titles, commit messages and script strings. `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/overview.md`.
 - **Durable rules belong in prompts/docs, not local MEMORY.** `node_modules/@joshuafolkken/kit/prompts/collaboration-workflow/principles.md` → "durable-rules".
@@ -31,16 +32,16 @@ Log auto-decisions: an Issue comment in an Issue workflow, else a one-line "Auto
 
 ## Critical Conventions (non-standard — always apply)
 
-Naming, exports, file names and content rules are enforced by `node_modules/@joshuafolkken/kit/eslint/rules/`; their single source is `node_modules/@joshuafolkken/kit/prompts/coding-standards.md` → "Conventions". `function` syntax, not arrows (named SvelteKit route handlers may use the typed-const arrow idiom) — lint does not check it.
+Naming, exports, file names and content rules are enforced by `node_modules/@joshuafolkken/kit/eslint/rules/`; their single source is `node_modules/@joshuafolkken/kit/prompts/coding-standards.md` → "Conventions". `function` syntax, not arrows (named SvelteKit route handlers may use typed-const arrows); lint does not check it.
 
 ### Quality limits
 
-- Function complexity ≤5 · nesting ≤2 · function ≤25 lines · file ≤300 lines · params ≤4 · statements per function ≤10 · cognitive complexity ≤4 — line counts are code lines, not physical lines (`pnpm josh lint`); test files allow 35 code lines per function.
+- Function complexity ≤5 · nesting ≤2 · function ≤25 lines · file ≤300 lines · params ≤4 · statements per function ≤10 · cognitive complexity ≤4 — line counts are code lines, not physical lines; test functions allow 35 code lines.
 - No magic numbers beyond `0`, `1`, `-1` · no `any` · restricted `as` · explicit param and return types · single short early return → one-liner `if (x) return y`.
 
 ## Package-First Development
 
-Before building a feature, check for a well-maintained package — measure with `pnpm josh pkg:scout <keywords>`: `clear` → select it (Tier A), `close` → ask (Tier B).
+Before building a feature, run `pnpm josh pkg:scout <keywords>`: `clear` → use it (Tier A), `close` → ask (Tier B).
 
 ## Code Change Rules
 
@@ -79,7 +80,7 @@ Never start a `kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun` workflo
 
 #### Mid-workflow stop notification (`confirmation`)
 
-Before pausing **any** run for the user — a command's stop, an upstream-Issue interrupt, a Tier C confirmation — send once per stop (skip when the user asked for the stop this turn):
+The `Stop` hook sends it when your held run awaits a decision — lead with the reason, end with `Recommended: <choice>`. Send it yourself only when the hook refuses the stop:
 
 ```bash
 pnpm josh notify --task-type confirmation --issue-url "<url>" --body=$'<reason>' --recommended "<choice>" --alternative "<other>"