@joshuafolkken/kit 1.1514.0 → 1.2114.0

package/.claude/skills/workflow-commands/fullrun-steps.md

@@ -7,57 +7,49 @@ full.
 
 File Issues with `pnpm josh issue:file` (it applies the classification labels); see `prompts/collaboration-workflow/issue-template.md`.
 
-**`in-progress` is already on the Issue** — `run:entry` applied it once the tree was held and the
-budget allowed the run, and `run:release <N>` takes it back off → Read Issue #N and its comments
-(`issue-comments.md`) → **normalize the title** (if not in English or can be phrased more clearly,
-derive a better English title and `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"`)
-→ post the agreed plan only if the Issue body is blank (`gh api -X PATCH
-repos/{owner}/{repo}/issues/<N> -f body="<plan>"`); if the body already has content, skip the
-plan-posting step → implement (the `plan` event `run:board` draws 📝 from is written by code — by
-`run:entry` for a `run:planned` issue, else at the first implementation edit — never by hand; no cut
-follows the plan — a lane child's context is bounded by the
-threshold-gated implementation cut alone) → run the **verification gate** (the full procedure is `chain-rule.md`;
-in outline: refactor → `pnpm josh main:merge` → **a dispatched lane child hands the rest to
-`pnpm josh ship --detach --review "<title> #<N>"` and ends its turn** (`chain-rule.md` step 0) → otherwise `pnpm josh run:cut <N>` (the pre-gate cut, before the gate; a no-op
-outside a lane) → start `pnpm josh gate` and a subagent `/code-review`
-with the brief `pnpm josh review:brief` prints on `git diff main`, join the gate before the commit,
-iterate to no high/medium findings, within the round cap (`prompts/review.md`) → **the clean path folds the ship region into
-one call**, `pnpm josh ship "<title> #<N>"` (gate → commit/push/PR → the CI-wait `followup` → the
-`run:tail` report bookkeeping, stopping at the first failed step), with any
-branch-2 filing (`pnpm josh issue:file`, which runs `epic:bundle` itself) run before it → **when a second round is due `ship` does not
-fit**: open the PR between the rounds with `pnpm josh git -y "<title> #<N>"`, run round 2 beside CI, then
-`pnpm josh followup` and `pnpm josh run:tail <N>`). Issue plan comments are written in the session language (`JOSH_SESSION_LANG`,
-default `ja`). Before implementing, run `pnpm josh ms`, then `pnpm josh latest:scope`
-and update dependencies only on `required` — `latest-gate.md` is its single source, and on `required`
-load the `dependency-update` skill afterwards. **A dispatched lane child skips `pnpm josh ms`** — it
-refuses in a lane, and `pnpm josh main:merge` brings the latest default in during the gate. The parent runs
-`pnpm josh ms` in the primary checkout, never the child — `backlogrun-lanes.md` and
-`backlogrun-child.md` are the single sources. When running `pnpm josh followup`, pass an
-implementation summary via `--notify-message` in the session language, leading with the three
-plain-language lines: `"Implemented <title>\nCause: ...\nFix: ...\nResult: ...\n\nDetails:\n-
-<change1>\n- <change2>"`. **`pnpm josh followup` waits for CI, verifies AI review findings, sends the
-completion notification, then merges; if blockers are found it exits non-zero — fix and re-run.**
-**Run `pnpm josh ms` after the merge.** A Codex lane skips it — the parent's `run:merge` syncs the
-primary checkout; a Claude run keeps it.
+1. **`in-progress` is already on the Issue** — `run:entry` applied it once the tree was held and the
+   budget allowed the run, and `run:release <N>` takes it back off.
+2. Read the Issue and its comments off `run:entry`'s `run:prep` report (`issue-comments.md`).
+3. **Record the agreed plan** with `pnpm josh issue:plan <N> --body-file <path>`, adding
+   `--title "<title>"` when the title is not in English or can be phrased more clearly (the plan goes
+   into the body when it is blank and its author has write access, otherwise into a comment; its
+   `### 影響を受ける既存の利用者` section is drafted with `pnpm josh plan:consumers` — `kickoff.md` step 4).
+4. Run `pnpm josh ms`, then update dependencies only where the `run:prep` report answers
+   `latest: required` — `latest-gate.md` is its single source, and on `required` load the
+   `dependency-update` skill afterwards. **A dispatched lane child skips `pnpm josh ms`** — it refuses
+   in a lane, and ship's sync brings the latest default in before its gate. The parent runs
+   `pnpm josh ms` in the primary checkout, never the child — `backlogrun-lanes.md` and
+   `backlogrun-child.md` are the single sources.
+5. Implement. The `plan` event `run:board` draws 📝 from is written by code — by `run:entry` for a
+   `run:planned` issue, else at the first implementation edit — never by hand; no cut follows the
+   plan — a lane child's context is bounded by the threshold-gated implementation cut alone.
+6. Run the **verification gate** through the merge: `chain-rule.md` → "Run the review-to-merge
+   chain". Branch-2 filing (`pnpm josh issue:file`, which runs `epic:bundle` itself) runs before
+   `pnpm josh ship`.
+7. When running `pnpm josh followup`, pass an implementation summary via `--notify-message` in the
+   session language, leading with the three plain-language lines: `"Implemented <title>\nCause:
+   ...\nFix: ...\nResult: ...\n\nDetails:\n- <change1>\n- <change2>"`. **`pnpm josh followup` waits
+   for CI, verifies AI review findings, sends the completion notification, then merges; if blockers
+   are found it exits non-zero — fix and re-run.**
+8. `run:tail` returns the checkout to the default branch (`main:sync`) after the merge; a lane child's
+   `run:tail` skips that step and the parent syncs the primary checkout.
 
 ## The `fullrun new` step list
 
 `kickoff new` + `fullrun #N` in one run. Steps: (1) Derive an English title, or use the provided one.
-(2) Create Issue: `pnpm josh issue:file "<title>" --body-file <body-file> --depth <n>`,
+(2) Create Issue: `pnpm josh issue:file "<title>" --body-file <body-file>`,
 with the labels `kickoff.md` → "Words typed after `new`" maps (per
 `prompts/collaboration-workflow/issue-template.md`) — its duplicate scan runs first, and a candidate
 that covers the same work stops the run rather than filing a second Issue (`issue-scout.md`). Capture
-`<N>`. (3) Add `in-progress` (the bare hold named no issue):
-`gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=in-progress'`. (4) Post the agreed plan
-in the session language: fill the body if blank,
-otherwise add a comment. (5) If the working tree already has staged or modified files,
-`git stash push -m "fullrun new: pre-existing changes" -- ':!.josh/observations'` first. (6) `pnpm josh ms`. (7)
-`pnpm josh latest:scope`; on `required` run `josh latest` and load the `dependency-update` skill; on
-`skip` neither runs (`latest-gate.md` is the single source). If you stashed in (5),
-`pnpm josh stash:pop "fullrun new: pre-existing changes"` — by message, never a positional `git stash
-pop`. (8) Implement. (9) Run the verification gate (as in `chain-rule.md`; only the first review round
-runs here). (9a) **Ask `pnpm josh review:round2 --round-1-closed` whether a second round is due**, once
-round 1's fixes are in and before the commit. (10) Where the tree was edited after the first gate
+`<N>`. (3) `pnpm josh run:hold --adopt <N>` — re-keys the bare hold to `<N>` and applies `in-progress`;
+every later stop releases with `run:release <N>`. (4) Record the agreed plan
+in the session language: `pnpm josh issue:plan <N> --body-file <path>` (its consumers section as in
+`kickoff.md` step 4). (5) `pnpm josh stash:push "fullrun new: pre-existing changes"`. (6) `pnpm josh ms`. (7)
+`pnpm josh run:prep <N>`; on `latest: required` run `pnpm josh latest:if-required` and load the `dependency-update`
+skill; on `skip` neither runs (`latest-gate.md` is the single source). If (5) answered `stashed`,
+`pnpm josh stash:pop "fullrun new: pre-existing changes"`. (8) Implement. (9) Run the verification gate (as in `chain-rule.md`; only the first review round
+runs here). (9a) **Ask `pnpm josh review:round2 --record <N>` whether a second round is due**, once
+round 1 is fixed and recorded, before the commit. (10) Where the tree was edited after the first gate
 started, re-run `pnpm josh gate` and join it. (11) `pnpm josh git -y "<title> #<N>"` — the pull request
 opens here, between the two rounds. (11a) Run the **second round** now beside the CI, where (9a)
 answered `required` (brief `pnpm josh review:brief --round 2`); a finding it fixes in place is pushed
@@ -67,9 +59,8 @@ round was due** (9a `skip`), fold steps (10)–(13) and the release bookkeeping
 ship "<title> #<N>" --notify-message "..."` (gate → commit/push/PR → the CI-wait `followup` → `run:tail`,
 stopping at the first failed step); **where a second round ran**, the PR opened
 at (11) and the region stays separate — `pnpm josh followup "<title> #<N>" --notify-message "..."` then
-`pnpm josh run:tail <N>`. (14) **After the merge, run `pnpm josh ms`.** (15) **Ask `pnpm josh
-release:scope` and close the completion summary with what it answered** (`followup.md` →
-"When `pnpm josh release` runs").
+`pnpm josh run:tail <N>`. (14) **Close the completion summary with `run:tail`'s `release:scope`
+answer** (`followup.md` → "When `pnpm josh release` runs").
 
 ## The release ask — the last step of either form
 

package/.claude/skills/workflow-commands/fullrun.md

@@ -9,15 +9,15 @@ run's next single action. `chain-rule.md`, `followup.md`, `background-commands.m
 
 - **The entry passes no `--to`**: `pnpm josh run:entry <N>` is `fullrun`'s stage. Follow `run:step`
   into `fullrun-steps.md` — the `fullrun #N` list or the `fullrun new` list.
-- **The end merges**: `run:step` names the verification gate, `pnpm josh followup`, `pnpm josh ms` and
-  the release ask in order. Invoking `fullrun` authorizes the merge, through `pnpm josh followup` only.
+- **The end merges**: `run:step` names the verification gate, `pnpm josh followup` and the release ask
+  in order. Invoking `fullrun` authorizes the merge, through `pnpm josh followup` only.
 - **A split or a prerequisite stops the run**: typing `fullrun` approved **one** Issue.
 
 ## The lane-child seam
 
 - **A lane child asks whether it is a resume first — `pnpm josh run:cut --resume <N>`** (`run:entry` asks it
   before the hold); on `resume` it skips the title, plan, hold and implementation and goes to the gate. At the pre-gate
-  boundary — immediately after `pnpm josh main:merge`, before the gate — it takes the cut with
+  boundary of `chain-rule.md` step 1 — step 0's ship fallen through, before the gate — it takes the cut with
   `pnpm josh run:cut <N>` (the ordered step in `chain-rule.md`, which names the cut's single source),
   and it records any park on the Issue before the stop notify. A run that is not a lane child never
   reads the cut's document.

package/.claude/skills/workflow-commands/halfrun.md

@@ -1,6 +1,6 @@
 # `halfrun` — the manifest (implement + verify, stop before commit)
 
-When this run files a new Issue, file it with `pnpm josh issue:file`, which lints the body and applies the classification labels it declares beside the `--depth` and `--route` labels; `prompts/collaboration-workflow/issue-template.md` is the single source for this classification.
+When this run files a new Issue, file it with `pnpm josh issue:file`, which lints the body and applies the classification labels it declares beside the `--route` label; `prompts/collaboration-workflow/issue-template.md` is the single source for this classification.
 
 `halfrun` implements the change and runs the full verification gate, then **stops before commit** —
 nothing is committed, pushed, or opened as a PR — so a person verifies the working tree by hand. The
@@ -15,36 +15,28 @@ entry sequence and the stop branches are `entry-sequence.md`.
 
 ## The step list
 
-`halfrun #<N>`: read Issue #N and its comments → **normalize the title** (same as
-`fullrun`) → post the agreed plan only if the body is blank → `pnpm josh ms`, then `pnpm
-josh latest:scope` and update dependencies only on `required` (`latest-gate.md`; the
-`dependency-update` skill) → implement → run the **full verification gate** (refactor →
+`halfrun #<N>`: read Issue #N and its comments → **record the agreed plan**, normalizing
+the title (`pnpm josh issue:plan`, same as `fullrun`) → `pnpm josh ms`, then on `run:prep`'s
+`latest: required` `pnpm josh latest:if-required` (`latest-gate.md`; the `dependency-update` skill) → implement → run the **full verification gate** (refactor →
 start `pnpm josh gate` beside a subagent `/code-review` with the brief `pnpm josh review:brief` prints,
 join the gate before the stop, iterate to no high/medium findings, within the round cap (`prompts/review.md`) → `pnpm josh
 test:e2e`, run by **you**, because `halfrun` opens no pull request and there is no CI E2E job; a printed
 skip is the answer where the project has no suite) → **mark the stop: `pnpm josh run:hold <N>
---halfrun-stop`** (the record `fullrun #<N>` adopts; `new` passes the filed number) → send a
-`confirmation` Telegram with the resume commands in the body → **stop**. Plan comments are in the session language. The `confirmation` Telegram
-body MUST include the exact resume commands — **the `Next:` line first**, since that is how a verified
-`halfrun` ships: its `run:entry` adopts this stop's marked hold and resumes at
-the gate. The direct commands follow for shipping without an agent:
-`pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'halfrun ready for manual
-verification\nNext: prrun #<N> | fullrun #<N>\nWithout an agent: pnpm josh git -y "<title> #<N>" && pnpm josh
-followup "<title> #<N>" --notify-message "Implemented <title>\\nCause: ...\\nFix: ...\\nResult:
-...\\n\\nDetails:\\n- <change1>"' --recommended "Verify by hand, then prrun #<N>" --alternative "fullrun
-#<N>"`. The stop report names the same two, in the same order.
+--halfrun-stop`** (the record `fullrun #<N>` adopts; refused with `e2e-owed` until `test:e2e` answered
+green on this tree; it also sends the `confirmation` Telegram, its body led by
+`Next: prrun #<N> | fullrun #<N>` — never compose one) → **stop**. Plan comments are in
+the session language. The stop report names `prrun #<N>` (recommended) and `fullrun #<N>`, in that order.
 **Invoking `halfrun` is _not_ authorization to commit, push, or merge** — do not run `pnpm josh git -y` or `pnpm josh followup` yourself. If the user comes
-back with fixes, treat each as a new round: implement, re-run `pnpm josh gate`, send another
-`confirmation` Telegram, stop again.
+back with fixes, treat each as a new round: implement, re-run `pnpm josh gate`, mark the stop again
+(it sends the `confirmation`), stop again.
 
 `halfrun new` or `halfrun new "<title>"`: `kickoff new` + `halfrun #<N>` (no Issue exists yet). Steps
 mirror `fullrun new` (1)–(8): derive an English title (or use the provided one) → create the Issue
-(`pnpm josh issue:file "<title>" --body-file <body-file> --depth <n>`, with the labels
+(`pnpm josh issue:file "<title>" --body-file <body-file>`, with the labels
 `kickoff.md` → "Words typed after `new`" maps, body per
-`prompts/collaboration-workflow/issue-template.md`; its duplicate scan is read per `issue-scout.md`) → add `in-progress` (as `fullrun new` (3)) → post the agreed plan → stash
-any pre-existing changes with `git stash push -m "halfrun new: pre-existing changes" -- ':!.josh/observations'`
-(the pathspec keeps the observation ledger in the tree for this run's commit), popped by
-message with `pnpm josh stash:pop "halfrun new: pre-existing changes"`, never a positional `git stash pop` →
-`pnpm josh ms` → `pnpm josh latest:scope` → implement → run the gate (as above, `pnpm
-josh test:e2e` run by **you**) → `pnpm josh run:hold <N> --halfrun-stop` → send the `confirmation`
-Telegram and **stop**.
+`prompts/collaboration-workflow/issue-template.md`; its duplicate scan is read per `issue-scout.md`) → `pnpm josh run:hold --adopt <N>` (as `fullrun new` (3)) → post the agreed plan → stash
+any pre-existing changes with `pnpm josh stash:push "halfrun new: pre-existing changes"`, popped
+after `stashed` with `pnpm josh stash:pop "halfrun new: pre-existing changes"` →
+`pnpm josh ms` → `pnpm josh run:prep <N>`, and on `latest: required` `pnpm josh latest:if-required` → implement → run the gate (as above, `pnpm
+josh test:e2e` run by **you**) → `pnpm josh run:hold <N> --halfrun-stop` (it sends the `confirmation`)
+→ **stop**.

package/.claude/skills/workflow-commands/issue-comments.md

@@ -8,12 +8,17 @@ turn as whatever else the run needs:
 
 ```bash
 pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch
-gh api repos/{owner}/{repo}/issues/<N>/comments --jq '.[] | {user: .user.login, created_at, body}'
+gh api repos/<owner>/<repo>/issues/<N>/comments --jq '.[] | {user: .user.login, created_at, body}'
 ```
 
 **Type the first line**; it **says when a comment listing could not be read rather than showing no
-comments**. The `gh api` form is for a **cross-repository** read (the command takes no `--repo`). Never
-`gh issue view <N> --comments` — GraphQL-backed, `403` in a cloud session.
+comments**. The `gh api` form is **cross-repository only** (the command takes no `--repo`); a read
+of this repository's Issue, its comments or its timeline — `repos/{owner}/…` or the repository
+spelled out, and `gh issue view` — is refused (`pnpm josh rule:list` → `direct-issue-read`).
+
+An Issue whose author has no write access stops at `run:entry` until a person with write access
+plans it with `kickoff #N`; the run then follows that plan (`scripts/run/entry/run-entry-trust.ts`).
+A trust read that failed stops there too, naming the failed read.
 
 **This repository writes its agreements into comments and then reads only bodies.** **What the
 reading is for**: the scope boundary — work a comment moved elsewhere or added here; an auto-decision
@@ -47,25 +52,29 @@ means "waiting for an answer", and here the answer exists.
 the Issue (`scripts/issue/issue-labels.ts` → `NOT_DIRECTLY_RUNNABLE_LABELS`, `epic-classify.ts` →
 `human`), and `epic:busy` stops counting it. **Only a person removes it, by closing the Issue.**
 
+**Commit nothing, push nothing, open no pull request** — run one command; it posts the evidence,
+applies `already-done` and releases the hold, in that order, stopping at the first failure:
+
 ```bash
-gh api repos/{owner}/{repo}/labels -f name=already-done -f color=6f42c1 -f description="Verified already merged — a person closes it" --silent 2>/dev/null || true
-gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=already-done'
+pnpm josh issue:already-done <N> --evidence-file <path>
 ```
 
-1. **Record the evidence as an Issue comment, before the label**: the merging pull request or commit
-   and, per acceptance criterion, the file and lines that satisfy it. **A claim with no citations is not
-   the finding this exit is for.**
-2. **Apply `already-done`** — the two commands above.
-3. **Commit nothing, push nothing, open no pull request.** Release the hold with
-   `pnpm josh run:release <N>`, which also removes `in-progress`.
-4. **Then behave as the entry point does for a parked child.** A typed `fullrun` / `halfrun` sends a
-   `confirmation` Telegram naming the Issue and the covering merge, and stops; a `backlogrun` child is
-   park-and-continue (`backlogrun-park.md` → "park and continue").
-5. **Never close the Issue** — Tier C at every entry point.
+**The evidence file names the merging pull request or commit and, per acceptance criterion, the
+`file:line` that satisfies it.** **A claim with no citations is not the finding this exit is for.**
+
+Then behave as the entry point does for a parked child: a typed `fullrun` / `halfrun` sends a
+`confirmation` Telegram naming the Issue and the covering merge, and stops; a `backlogrun` child is
+park-and-continue (`backlogrun-park.md` → "park and continue"). **Never close the Issue** — Tier C.
 
 **Looking familiar is no license to skip the work**: a criterion you cannot point at merged code for is
 one this run still owes.
 
+## A measurement-only Issue
+
+**Every criterion is a measurement, so no pull request closes it** → `pnpm josh issue:measured <N>
+--evidence-file <path>` (per criterion, the result and its run), never a bare comment: an OPEN child is
+parked `run:stalled`. Invoking `fullrun` / `backlogrun` authorizes this close. `docs/josh-commands-backlog.md` → "`josh issue:measured`".
+
 ## A long thread
 
 **The fetch is one call; what costs is carrying it** — hence the projection to author, timestamp and
@@ -79,4 +88,4 @@ and refuses every other body-only read; the Codex adapter refuses them all** (`p
 ## A person's update mid-run
 
 When the hook, `review:attest --check` or `followup` shows an Issue update, read it as above, fix what it
-changes, then `pnpm josh issue:ack <N>`. The watch: `docs/josh-commands-backlog.md` → "`josh issue:ack`".
+changes, then `pnpm josh issue:ack <N>`. A withheld-body notice (author without write access) needs no ack. The watch: `docs/josh-commands-backlog.md` → "`josh issue:ack`".

package/.claude/skills/workflow-commands/issue-fold-existing.md

@@ -21,7 +21,8 @@ pnpm josh issue:fold-existing assessment.json --json > result.json
 jq -e '.verdict == "fold"' result.json
 jq '{body: .body}' result.json > patch.json
 gh api -X PATCH repos/{owner}/{repo}/issues/<N> --input patch.json
+pnpm josh issue:priority <N>
 pnpm josh issue:read <N>
 ```
 
-Re-read it and confirm the original requirements, the decisions recorded in comments, the added requirements and the verification all remain. A failed write or re-read means the fold is not complete. A fold never creates a new Issue. `separate` returns to the ordinary filing path, and `inspect` re-reads the missing information.
+A body edit applies no label: `pnpm josh issue:priority <N>` applies the body's floor (`issue-template.md` → F). Re-read it and confirm the original requirements, the decisions recorded in comments, the added requirements and the verification all remain. A failed write or re-read means the fold is not complete. A fold never creates a new Issue. `separate` returns to the ordinary filing path, and `inspect` re-reads the missing information.

package/.claude/skills/workflow-commands/issue-scout.md

@@ -6,8 +6,8 @@ Every filing asks whether the work already exists and which epic owns it; the co
 named in `--distinct`:
 
 ```bash
-pnpm josh issue:file "<title>" --body-file <complete-draft.md> --depth <n> [--route <route>]
-pnpm josh issue:file "<title>" --body-file <complete-draft.md> --depth <n> --distinct 2801,2795
+pnpm josh issue:file "<title>" --body-file <complete-draft.md> [--route <route>]
+pnpm josh issue:file "<title>" --body-file <complete-draft.md> --distinct 2801,2795
 ```
 
 - **`Duplicates:` is read, not skimmed.** Open each candidate and apply `issue-fold-existing.md`

package/.claude/skills/workflow-commands/kickoff.md

@@ -4,18 +4,22 @@
   nothing and prints the stage line alone; on `start: reached` report the stage line and **stop**. Then:
   1. Read Issue #N **and every comment on it** — `pnpm josh issue:read <N>`; the later text is the
      agreement in force (`issue-comments.md`, which also carries the answers that stop the run).
-  2. **Normalize the title** to clear English: `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"`.
+  2. Derive a clear English title.
   3. Analyze requirements → **scope assessment per `split-assessment.md`**.
-  4. Post the plan — a blank body takes `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"`,
-     otherwise `pnpm josh issue:comment <N> --body-file <path>` — in the session language
-     (`JOSH_SESSION_LANG`, default `ja`).
-  5. **Apply the `run:planned` label** — the next command's `run:entry` starts at the implementation
-     (`gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=run:planned' --silent`).
-  6. Send the Telegram notification, its last line `Next: halfrun #<N> | prrun #<N> | fullrun #<N>` →
+  4. **Record the plan** — written to a file in the session language (`JOSH_SESSION_LANG`, default
+     `ja`), then `pnpm josh issue:plan <N> --body-file <path> --title "<title>" --planned`: it renames
+     the issue, writes the plan into the body when it is blank and its author has write access (a
+     comment otherwise), and applies `run:planned`, so the next command's `run:entry` starts at the implementation. A target named in front of the reference
+     adds `--repo <owner/name>`. Before writing the plan, run `pnpm josh plan:consumers
+     <identifier...>` on what it adds or changes and finish the `### 影響を受ける既存の利用者` draft it
+     prints; `issue:plan` refuses a plan without it (`docs/josh-commands-backlog.md` → "`josh issue:plan`").
+  5. Send the Telegram notification, its last line `Next: halfrun #<N> | prrun #<N> | fullrun #<N>` →
      **stop** (do not implement).
 
-  **Two or more separately-mergeable deliverables** take the split path instead of a plan: create the
-  children as in `kickoff new`, then either **promote `#N`** with `pnpm josh epic --promote <N> <N1> <N2>
+  **Two or more separately-mergeable deliverables** take the split path instead of a plan: rename `#N`
+  to the step-2 title (`gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` — neither
+  `issue:plan` nor `epic --promote` runs here to apply it), create the children as in `kickoff new`,
+  then either **promote `#N`** with `pnpm josh epic --promote <N> <N1> <N2>
   ... [--ordered] [--rationale-file <path|->]` (when `#N` is a request, a discussion or a container), or
   keep `#N` as a child and create a new epic with `pnpm josh epic`. That branch is Tier A: choose and
   record the reasoning on the Issue. Present `backlogrun #<E> --only` and stop.
@@ -41,13 +45,13 @@ gate must hold **together**. The rest of `split-assessment.md` is read when a sp
 - `kickoff new` or `kickoff new "<title>"`: (0) **Scope assessment** per `split-assessment.md` — one
   deliverable takes the **single-issue path**, several the **multi-issue split path**.
   - **Single-issue path**: (1) Derive an English title, or use the one given. (2) `pnpm josh issue:file
-    "<title>" --body-file <body-file> --depth <n>` plus the labels the words typed after `new` name
+    "<title>" --body-file <body-file>` plus the labels the words typed after `new` name
     ("Words typed after `new`", below; body per `prompts/collaboration-workflow/issue-template.md`) —
     its duplicate scan runs first, and a candidate covering the same work stops the run (`SKILL.md` →
     `issue-scout.md`). Capture `<N>`. (3) Post the plan as `kickoff #<N>` does. (4) Telegram. (5)
     **Stop**.
   - **Multi-issue split path**: (1) Per deliverable, `pnpm josh issue:file "<sub-title>" --body-file
-    <body-file> --depth <n> --route split` plus the labels the words after `new` name (duplicate scan
+    <body-file> --route split` plus the labels the words after `new` name (duplicate scan
     per `issue-scout.md`). A split filed into another repository gives every child body the `## Origin`
     backlink, the epic the same link as prose (never a checkbox row, which disables its auto-close), and
     the originating Issue lists children and epic under `## Upstream issues`. (2) **Epic — always, for
@@ -57,19 +61,13 @@ gate must hold **together**. The rest of `split-assessment.md` is read when a sp
     a hand-edited epic with `pnpm josh epic:check <E>`. (3) Telegram listing every created Issue. (4)
     Present `backlogrun #<E> --only`. (5) **Stop**.
 
-  **The epic itself is never implemented** — `backlogrun` runs its *children*, and `pnpm josh followup`
-  closes it once every child is closed. Children with no required order take `None — the children are
+  **The epic itself is never implemented** — `backlogrun` runs its *children*, and it closes itself
+  once every child is closed, whichever josh path closes the last one. Children with no required order take `None — the children are
   independent; any execution order works.` under `Dependencies`. **Only when the execution order
   matters** (`execution-waves.md` → "When a wave may be declared") pass `--ordered`, which treats the
   argument order as the dependency order.
 
-  **Only where `josh` is unavailable**, the manual fallback: `gh api repos/{owner}/{repo}/labels -f
-  name=epic -f color=5319e7 -f description="Tracks a batch of child issues from one split" --silent
-  2>/dev/null || true`, then `gh api repos/{owner}/{repo}/issues -f title="<epic-title>" -f
-  'labels[]=epic' -F body=@<body-file>` with the epic format of `issue-template.md`; an order is
-  recorded per pair with `gh api repos/{owner}/{repo}/issues/<N2>/dependencies/blocked_by -F
-  issue_id="$(gh api repos/{owner}/{repo}/issues/<N1> --jq .id)"` (the blocker's **database id**; a
-  failure is non-fatal), never folded into the creation call.
+  Without `josh`: `issue-template.md` → "複数 Issue に分割するときの epic Issue".
 
 `pnpm josh issue:file` lints the body and applies the classification labels it declares (`issue-template.md`; `docs/josh-commands-backlog.md` → `josh issue:file`).
 An Issue a consumer can use only once it is published is filed with `--release` (`kickoff new`), or linked with `pnpm josh issue:release <N>` (`kickoff #N`) — either makes it a blocker of the repository's `release` Issue, which never gets `auto-ok` on its own.
@@ -83,7 +81,10 @@ An Issue a consumer can use only once it is published is filed with `--release`
 **Words after `new`** (`kickoff new high`) are read like `into <target>`, never inferred. Each adds its
 labels to the filing; a word not in the table is asked about:
 
-| Typed     | Added to `pnpm josh issue:file` |
-| --------- | ------------------------------- |
+| Typed      | Added to `pnpm josh issue:file` |
+| ---------- | ------------------------------- |
 | `auto ok` | nothing — `issue:file` judges it |
-| `high`    | `--label priority:high`         |
+| `critical` | `--label priority:critical`     |
+| `high`     | `--label priority:high`         |
+
+A typed priority wins: `issue:file` then skips the body's `- 優先度:` judgement (`scripts/issue/issue-priority.ts`).

package/.claude/skills/workflow-commands/latest-gate.md

@@ -26,26 +26,21 @@ judgement that the dependencies are probably still fresh.
 ## What runs when the answer is `required`
 
 ```bash
-git stash push -u -m "josh latest"    # only if the working tree has staged or modified files
-pnpm josh ms
-pnpm josh latest     # on `required` only
-pnpm josh stash:pop "josh latest"     # only if you stashed above — by message, never a positional pop
+pnpm josh latest:if-required   # stash → josh latest → pop by message; nothing on `skip`
 ```
 
-**The pop is by message, never a bare `git stash pop`** — the stash is a repository-wide stack every
-work tree shares.
+It asks `latest:scope` itself, so a run reads `run:prep`'s `latest:` line and never asks again. A
+failed update or a conflicted pop stops with the stash kept and names the pop to run.
 
 Then **load the `dependency-update` skill and follow its procedure** — the overrides in **both**
 `pnpm-workspace.yaml` and `package.json`, and the one expected `devEngines` pnpm bump — in every run in
 which `josh latest` actually ran; never report the pins intact without having run it.
 
-**On `skip`, one line of that block goes away and no more.** `pnpm josh latest` does not run, and
-the `dependency-update` skill is not read, because nothing rewrote a pin for it to check.
+**On `skip`, the command does nothing** and the `dependency-update` skill is not read, because
+nothing rewrote a pin for it to check.
 
-**Two of those steps are not this gate's, and making either conditional breaks something.**
-`pnpm josh ms` runs per issue and per child either way — it brings the previous merge into the tree.
-The stash before it is the branch switch's, not the update's, so it is conditional on the **tree**,
-never on the answer.
+**`pnpm josh ms` is not this gate's** — it runs per issue and per child either way, bringing the
+previous merge into the tree, before the update.
 
 ## The vulnerability net is not what moved
 

package/.claude/skills/workflow-commands/needs-human-review.md

@@ -8,18 +8,18 @@ point reached it — `fullrun` or `backlogrun` — and the label may be applied
 - **Implementation and the verification gate run normally** — refactor, `pnpm josh gate`,
   `/code-review`, exactly as for any other child.
 - **Run `pnpm josh test:e2e` yourself before stopping.** With no pull request there is no CI E2E job,
-  and `pnpm josh followup` is never reached. This is `halfrun`'s situation exactly: you run it and read
-  what it prints. A printed skip is the answer for a project with no E2E suite; a skip nobody saw
-  printed is not.
+  and `pnpm josh followup` is never reached. A printed skip is the answer for a project with no E2E
+  suite.
 - **Nothing is committed, pushed, opened as a pull request or merged.** `pnpm josh bump`,
   `pnpm josh git` and `pnpm josh followup` are never reached.
 - **The working tree is left uncommitted, and nothing is stashed.**
-- **Send a `confirmation` Telegram and stop the whole run.** The remaining children are not started —
-  inside a `backlogrun` this is the one thing that is *not* park-and-continue.
-- The Telegram body carries the **resume command**, in the same form `halfrun`'s own stop uses.
+- **Mark the stop: `pnpm josh run:hold <N> --human-review-stop`, then stop the whole run.** It keeps
+  the hold, marks it as `halfrun`'s stop, and sends the `confirmation` Telegram with the resume command
+  and the lane directory — never compose one. It answers `e2e-owed` until `test:e2e` answered green on
+  this tree. The remaining children are not started — inside a `backlogrun` this is the one thing that
+  is *not* park-and-continue.
 - **Resuming is `halfrun`'s stop exactly**: a person looks at the working tree and, if it is right,
-  carries on from the commit themselves. The stop report carries that resume command too, not only the
-  Telegram.
+  carries on from the commit themselves. The stop report carries the resume command too.
 
 **Stopping is the specification, not a failure.**
 
@@ -34,12 +34,7 @@ pnpm josh issue:state <N> --repo <owner/repo>  # a child in another repository
 
 **Never apply or remove it**: a mark a run can clear for itself is
 not a mark. Everything but typing the command on an explicit instruction in the current turn is a
-proposal, written as an Issue comment and left for the person. The label itself is created once per
-repository, by a person:
-
-```bash
-gh api repos/{owner}/{repo}/labels -f name=needs-human-review -f color=d93f0b -f description="Implement and verify, but stop before committing so a person can look"
-```
+proposal, written as an Issue comment and left for the person. `josh sync` creates the label.
 
 **It is not `needs-decision`**: `needs-decision` withholds a run's *start*; this withholds its *end*.
 So a `needs-human-review` issue is still offered, and a child stopped by it **goes on holding its

package/.claude/skills/workflow-commands/observation-filing.md

@@ -23,12 +23,13 @@ report. Drop an observation nobody would act on.
 `pnpm josh run:event --append note "#<N> <text>"`, shown by `pnpm josh run:board`
 (`docs/josh-commands-run.md` → "`josh run:board`").
 
-**The filing ceilings still apply.** Count it in the run's ten-Issue limit; above the target
+**The filing ceilings still apply.** It counts toward the per-origin cap of ten (`prerequisite.md`); above the target
 repository's WIP cap, close one first or do not file (`prompts/collaboration-workflow/wip-cap.md`).
 File with `pnpm josh issue:file` (`issue-scout.md`): it lints the body, applies the classification
 labels, scans for duplicates and runs `epic:bundle` (an `auto-ok` epic adds it to the backlog pool —
 `backlogrun-steps.md` → "What one invocation approves"). On the second filing of the run it asks the fold
 question and holds a `fold` (`split-assessment.md` → "The same two questions decide the filing-time fold").
+A bug filing's origin line: `prompts/collaboration-workflow/issue-template.md` (`- 原因:`).
 
 ### The depth test — a discretionary filing cites the product work it blocked
 
@@ -40,24 +41,7 @@ question and holds a `fold` (`split-assessment.md` → "The same two questions d
 | **1** | The run orchestration that executes an Issue | `fullrun` / `backlogrun`, lanes, the `epic:*` commands, the filing routes themselves |
 | **2** | What measures a run | `josh cost` and the run-timing report |
 
-**The depth is recorded on the Issue as a label, and the label is applied when the Issue is filed.**
-`depth:0` / `depth:1` / `depth:2` are defined in `scripts/issue/issue-labels.ts` with no definition of
-their own — **the table above is the single source**. **Every filing route applies one**: each route
-of `prerequisite.md`'s table, a split child and a review branch-2 filing pass `--depth <n>` to
-`pnpm josh issue:file`, beside any `--route`.
-
-```bash
-pnpm josh issue:file "<title>" --body-file <body-file> --depth 1
-gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=depth:1'   # an Issue already filed
-```
-
-`issue:file` creates any missing workflow label from `DEPTH_LABELS` before the create call.
-
-- **It is read off the subject, exactly as the table is** — not a judgement, unlike `auto-ok` and
-  `needs-human-review`; it withholds nothing.
-- **Applied at filing, not at completion.**
-- **An Issue carrying more than one counts as the lowest depth present.**
-- **An `epic` takes no depth label** and is excluded from the share's denominator.
+**The depth is read, not recorded** — no label carries it.
 
 - **A discretionary observation at depth 1 or deeper is filed only where it can cite the depth-0 work
   it stopped or delayed** — an Issue number or a run, never "this would slow runs down". **Cannot cite
@@ -80,22 +64,6 @@ to branch 2 of `prompts/review.md` → "Review round cap" is filed under that se
 to decide something, or the path of the rule that reads it. **A measurement with no reader is not
 added.** `route:tier-a` and `route:interrupt` carry over unchanged.
 
-### The depth-0 share — what is counted
-
-**The depth-0 share is the share of open Issues at depth 0.**
-
-**The denominator is a rule, not a choice, and this is it:**
-
-- **Counted: every open Issue that does not carry `epic`.**
-- **`route:tier-a` and `route:interrupt` are counted like anything else.**
-- **An Issue with no depth label is in the denominator**, counted separately as `unlabelled`.
-- **The numerator is what is left**: open, non-epic Issues carrying `depth:0`.
-
-**Two readings of the same backlog give the same number.**
-
-**What the number is for is not decided here** — no `backlog:next` change and no target value until it
-has been measured the same way more than once.
-
 ### A delegated child does not take this route
 
 **A delegated child files `route:tier-a` and `route:interrupt` only.** Its discretionary observations
@@ -104,6 +72,6 @@ summary carries, and how long it may be"); the parent files what survives the de
 run's ceiling.
 
 **A delegated child does not append to the ledger either — the parent collapses the duplicates and
-appends what is left.** **The 10-per-run ceiling for this route is the parent's to count.** **Lines
+appends what is left.** **Lines
 its own `review:record` and `measure:rerun` write are not this route** — they go to its issue's file in
 its lane (`observation-ledger.md` → "The ledger — where an observation that cannot cite a blockage goes").

package/.claude/skills/workflow-commands/observation-ledger.md

@@ -66,9 +66,11 @@ blocked depth-0 work is filed as before.
   goes ahead.
 - **A review round that passes after the pull request opened is recorded on the Issue, not in the
   ledger** — `pnpm josh review:record --issue <N> --comment` (`pnpm josh ship --review` does this for a
-  passing round 2), so CI does not restart. **A round 2 that blocks records in the tree as before.**
-  Once the Issue closes, the next ledger round carries the comment's lines into
-  `<N>-comment-rounds.md` (`review-comment-round.ts`).
+  passing round 2), so CI does not restart; so does any code round on a pushed, clean tree, a
+  blocking round 2 included.
+  Once the Issue closes, the next ledger round outside a lane carries the comment's lines into
+  `<N>-comment-rounds.md` (`review-comment-round.ts`); a lane child leaves that to
+  `pnpm josh observations:flush`.
 - **`pnpm josh followup` commits any other line appended after the run's commit onto the pull request,
   before the merge** — only when the ledger holds a pending append; a broken line refuses the merge.
 - **A lane carries its own lines, in its own pull request.**
@@ -88,7 +90,7 @@ blocked depth-0 work is filed as before.
 - **On `observation:record` answering `file`, the observation is filed**, at depth 1 or deeper, with
   no depth-0 citation (only when exactly one earlier sighting exists).
 - **The Issue quotes the ledger's own dates — the first sighting's and this one's.**
-- **Both ceilings still apply** (`observation-filing.md`): the 10-per-run cap and the WIP cap.
+- **Both ceilings still apply** (`observation-filing.md`): the per-origin filing cap and the WIP cap.
 
 **A third and later sighting appends a line and files nothing more** — `pnpm josh issue:scout` finds
 the open Issue.