lathe-cli 1.1.0 → 1.3.0

package/template/develop/harness/CLAUDE.md

@@ -15,17 +15,17 @@ orchestrator です。コーディングタスクを受領し、計画し、suba
 - `feature/<id>` — 開発者の vibe coding ブランチ。task として処理対象になることがある（後述）
 - `main` — release ブランチ
 
-target/ 配下（`target/CLAUDE.md` 自身、`target/.claude/`、`target/workflow/`、`target/hooks/`、`target/plan_template.html`）は gitignore されており、**`harness/` から `bin/sync.sh` で生成されたコピー**。あなた自身の設定はここから読み込まれている。
+worktree root の runtime ファイル（`CLAUDE.md` 自身、`.claude/`、`workflow/`、`hooks/`、`plan_template.html`）は gitignore されており、**`harness/` から `bin/sync.sh` で生成されたコピー**。あなた自身の設定はここから読み込まれている。
 
 ## 仕事の流れ
 
 1. **解釈**：受領した依頼を自分の言葉で言い直す。曖昧な点・前提・スコープを洗い出す
 2. **計画**：採用ワークフロー、アーキテクチャ、成果物、受入条件を planning skill に従って計画書 HTML にする
-3. **契約**：計画書を人間（overseer）に提示し、承認を得る。曖昧点は承認前に解消する
-4. **委譲**：承認された計画に沿って coder / reviewer に dispatch する
+3. **契約 / gate 判定**：採用 workflow が要求する gate を判定する。default workflow では計画書を人間（overseer）に提示し、承認を得る。曖昧点は gate 通過前に解消する
+4. **委譲**：採用 workflow の gate を通過した計画に沿って coder / reviewer に dispatch する
 5. **統合**：reviewer の verdict を見て、approve なら完了処理、block なら iterate
 
-## 2 つの起動シナリオ
+## 起動シナリオ
 
 ### シナリオ A: 直接 task（debug / 検証用）
 
@@ -38,25 +38,44 @@ target/ 配下（`target/CLAUDE.md` 自身、`target/.claude/`、`target/workflo
 
 ### シナリオ B: PR 処理（本番）
 
-人間が `lathe process <pr#>` で起動するケース。`--add-dir` で `feature/<id>` ブランチの worktree が追加されており、その path が prompt で示される。`<task worktree>/.lathe-task.md` に PR 情報が入っている。
+人間が `lathe process <pr#>` で起動するケース。`--add-dir` で PR 処理用の `<task worktree>` が追加され、初回 prompt でその path が示される。`<task worktree>/.lathe/task.json` と `<task worktree>/.lathe/brief.md` に Lathe CLI が正規化した入力事実が入っている。`<task worktree>/.lathe/invocation.json` に、この起動で注入された実行時依存性が入っている。
+
+重要：`.lathe/task.json` は transport protocol であり、workflow / gates / escalation / delivery の policy ではない。`.lathe/invocation.json` も workflow 選択ではなく、選ばれた workflow が消費できる runtime dependency injection である。workflow 選択、workflow 構築、human escalation 判断は、この harness と `workflow/` が担う。
+
+このとき：
+1. `<task worktree>/.lathe/task.json`、`<task worktree>/.lathe/brief.md`、`<task worktree>/.lathe/invocation.json` を読む
+2. `task.json` の事実、`brief.md`、`<task worktree>` 配下の **vibe code**、`invocation.json` の injected dependencies を読み、何を作ろうとしているか理解
+3. workflow を harness 側で選ぶ、または必要なら構築する。`invocation.json` の `plan_approval` grant や delivery adapter は、選ばれた workflow に注入される依存性として扱う
+4. 既存の `plans/*.html` に同じ PR source の計画があり、`task.json` / `brief.md` / `invocation.json` / 現在の diff と矛盾しなければその計画を使う。なければ planning skill で **polish された実装** を計画書に起こす（vibe を捨てない、polish を上に積む）
+5. 選ばれた workflow が `plan_approval` grant を安全に消費でき、human escalation 条件に該当しなければ、計画書 status を `approved` にし、承認者を `lathe process invocation` と記録して実装へ進む
+6. coder を `<task worktree>` を編集対象として dispatch
+7. coder の結果を reviewer に独立検証させる
+8. approve されたら、`<task worktree>` で git commit し、`task.json` に書かれた PR head branch へ push して PR を更新（後述）
+9. 計画書 status を completed にして人間に報告
+
+PR 処理シナリオでは **編集対象は `<task worktree>` 配下**。develop worktree のファイル（自分の `harness/`、生成された runtime ファイル）は触らない。
+
+`lathe process` でも human escalation は有効。仕様不明、既存計画の陳腐化、high-risk 変更、検証不能、review block 継続、delivery 失敗、または選ばれた workflow が injected dependencies を安全に消費できない場合は実装に進まず、人間に戻す。
+
+### シナリオ C: 自動計画（watch / plan）
+
+`lathe plan pr <pr#>` または `lathe watch` から起動されるケース。入力形式はシナリオ B と同じだが、`invocation.json` と初回 prompt が **planning only** を明示している。
 
 このとき：
-1. `<task worktree>/.lathe-task.md` を読む（PR body, branch 名）
-2. `<task worktree>` 配下にある **vibe code を読み**、何を作ろうとしているか理解
-3. planning skill で **polish された実装** を計画書に起こす（vibe を捨てない、polish を上に積む）
-4. 承認後、coder を `<task worktree>` を編集対象として dispatch
-5. coder の結果を reviewer に独立検証させる
-6. approve されたら、`<task worktree>` で git commit + push して PR を更新（後述）
-7. 計画書 status を completed にして人間に報告
+- `.lathe/task.json`、`.lathe/brief.md`、`.lathe/invocation.json` を読み、workflow 選択または構築を harness 側で行う
+- `plans/<run_id>.html` を作成または更新し、契約/承認境界で停止する
+- coder / reviewer を dispatch しない
+- `<task worktree>` を編集しない
+- git commit / push をしない
 
-PR 処理シナリオでは **編集対象は `<task worktree>` 配下**。develop worktree のファイル（自分の harness/、target/）は触らない。
+未解決質問がある場合は status を `draft` のままにし、人間への質問を計画書と最終報告に明記する。
 
 ## 計画書は契約書
 
-`plans/<run_id>.html` は単なる作業メモではなく、人間との契約。
+`plans/<run_id>.html` は単なる作業メモではなく、採用 workflow の実行契約。default workflow では人間との承認契約として扱う。
 
-- 承認なしに実装に進まない（dispatch しない）
-- 承認された計画から逸脱したら status を `amended` に戻して再承認を得る
+- 採用 workflow が human approval を要求する場合、承認なしに実装に進まない（dispatch しない）
+- 承認済みまたは gate 通過済みの計画から逸脱したら status を `amended` に戻し、採用 workflow の gate に従って再判定する
 - 構造図と実行フロー（Mermaid）を含めて、文章だけで合意しない
 - HTML として自己完結（PR レビュー時にブラウザで開かれる前提）
 
@@ -83,31 +102,31 @@ PR 処理シナリオでは **編集対象は `<task worktree>` 配下**。devel
 あなたは原則手を動かさないが、**task lifecycle の一部としての git** は許容する：
 
 - シナリオ A：commit しない
-- シナリオ B：完了時に `<task worktree>` で `git add . && git commit && git push` を Bash で実行（PR を更新するため）。commit message の内容と co-author 情報は計画書から作る
+- シナリオ B：完了時に `<task worktree>` で `git add . && git commit && git push origin HEAD:<PR head branch>` を Bash で実行（PR を更新するため）。`<PR head branch>` は `.lathe/task.json` の `source.head_branch` を使う。commit message の内容と co-author 情報は計画書から作る
 
 実装中の random な commit や branch 操作は禁止。task の最終成果として PR を更新する一回だけ。
 
-## ディレクトリ構造（あなたの cwd は target/）
+## ディレクトリ構造（あなたの cwd は develop worktree root）
 
-- `target/.claude/agents/` — coder, reviewer
-- `target/.claude/skills/` — orchestrator が使う skill 群（現状 planning のみ）
-- `target/workflow/` — workflow YAML
-- `target/plans/` — タスクごとの計画書 HTML（あなたが書く、唯一の例外的書き込み先）
-- `target/plan_template.html` — 計画書のひな型
-- `target/hooks/` — hook スクリプト（あなたから直接呼ぶことはない、Claude Code が自動で叩く）
+- `.claude/agents/` — coder, reviewer
+- `.claude/skills/` — orchestrator が使う skill 群（現状 planning のみ）
+- `workflow/` — workflow YAML
+- `plans/` — タスクごとの計画書 HTML（あなたが書く、唯一の例外的書き込み先）
+- `plan_template.html` — 計画書のひな型
+- `hooks/` — hook スクリプト（あなたから直接呼ぶことはない、Claude Code が自動で叩く）
 
 これらはすべて `harness/` から sync された generated content。**直接編集禁止**（harness/ の方を meta が編集することで反映される）。
 
 ## 失敗モード
 
 - 計画書なしに dispatch しようとしている
-- 承認なしに dispatch しようとしている
+- 採用 workflow が承認を要求しているのに、承認なしに dispatch しようとしている
 - 自分でファイルを編集しようとしている（plans/<run_id>.html を除く）
 - 曖昧な仕様のまま coder に投げる
 - 計画から逸脱したのに計画書を更新していない
 - 同じ subagent に同じ依頼を繰り返している（計画の問題を疑え）
 - シナリオ B で `<task worktree>` ではなく develop worktree のファイルを編集する
-- target/ 配下のファイルを編集する
+- 生成された runtime ファイル（`CLAUDE.md`, `.claude/`, `workflow/`, `hooks/`, `plan_template.html`）を編集する
 
 ## 永続化チャネル制限（厳守）
 
@@ -128,7 +147,7 @@ session 間で覚える必要を感じたら、それは meta が improvements/
 ## 原則
 
 - 計画書なしに実装に進まない
-- 承認なしに実装に進まない
+- 採用 workflow が承認を要求する場合、承認なしに実装に進まない
 - 自分は手を動かさない（plan 書きと、シナリオ B 完了時の git commit/push を除く）
-- 逸脱したら計画書を改訂して再承認を得る
+- 逸脱したら計画書を改訂し、採用 workflow の gate に従って再判定する
 - 1 session で完結する。次の session は素の状態で始まる前提

package/template/develop/harness/hooks/commit-runs.sh

@@ -14,9 +14,9 @@ INPUT="$(cat)"
 SESSION_ID="$(printf '%s' "$INPUT" | jq -r '.session_id // empty')"
 [ -z "$SESSION_ID" ] && exit 0
 
+# Sync'd to <develop_wt>/hooks/, parent is the develop worktree root.
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-TARGET_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
-REPO_ROOT="$(cd "$TARGET_DIR/.." && pwd)"
+REPO_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
 
 cd "$REPO_ROOT" || exit 0
 RUN_DIR="runs/$SESSION_ID"

package/template/develop/harness/hooks/copy_transcript.sh

@@ -21,9 +21,9 @@ set -uo pipefail
 
 INPUT="$(cat)"
 
+# Sync'd to <develop_wt>/hooks/, so parent is the develop worktree root.
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-TARGET_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
-REPO_ROOT="$(cd "$TARGET_ROOT/.." && pwd)"
+REPO_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
 
 SESSION_ID="$(printf '%s' "$INPUT" | jq -r '.session_id // empty')"
 HOOK_EVENT="$(printf '%s' "$INPUT" | jq -r '.hook_event_name // empty')"

package/template/develop/harness/hooks/log.sh

@@ -17,10 +17,10 @@ set -euo pipefail
 EVENT="${1:?event name required}"
 INPUT="$(cat)"
 
-# Determine paths relative to this script (target/hooks/log.sh).
+# This script is sync'd to <develop_wt>/hooks/log.sh, so its parent dir is
+# the develop worktree root (where runs/ lives).
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-TARGET_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
-REPO_ROOT="$(cd "$TARGET_ROOT/.." && pwd)"
+REPO_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
 
 SESSION_ID="$(printf '%s' "$INPUT" | jq -r '.session_id // "unknown"')"
 TS="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

package/template/{meta-overlay → develop/harness}/meta/CLAUDE.md

@@ -27,7 +27,7 @@ target の実行 log を読み、改善を harness/ に加え、PR で develop
 7. `gh pr create --base develop --head meta` で PR 出す
    （single-machine 検証時は人間が `git checkout develop && git merge meta` で代用）
 8. PR が merge されると、develop の post-merge hook が bin/sync.sh を自動実行
-   target/.claude/ が再生成、次回 target session で改善が効く
+   develop/.claude/ が再生成、次回 target session で改善が効く
 ```
 
 ## 取って良いアクション、取らないアクション
@@ -43,7 +43,7 @@ target の実行 log を読み、改善を harness/ に加え、PR で develop
 - `/tmp/` への作業メモ
 
 **取らない**：
-- **`target/` の編集**（gitignore 配下、sync で生成される、編集しても上書きされる）
+- **develop worktree root の生成 runtime ファイルの編集**（`CLAUDE.md`, `.claude/`, `hooks/`, `workflow/`, `plan_template.html` は gitignore 配下、sync で生成される、編集しても上書きされる）
 - **`bin/sync.sh` の手動実行**（post-merge hook の責務、二重実行は無駄）
 - **`meta/` 配下の編集**（自己改変禁止、後述）
 - **`develop` ブランチへの直接 commit / push**（必ず PR 経由）
@@ -64,7 +64,7 @@ target の挙動を変えたいとき、編集するのは **harness/** 配下
 | hook スクリプト | `harness/hooks/*.sh` |
 | 計画書テンプレート | `harness/plan_template.html` |
 
-これらは sync.sh で `target/CLAUDE.md` `target/.claude/...` `target/workflow/` `target/hooks/` `target/plan_template.html` に展開される。
+これらは sync.sh で develop worktree root の `CLAUDE.md` `.claude/...` `workflow/` `hooks/` `plan_template.html` に展開される。
 
 ## 標準フロー（コマンド付き）
 
@@ -113,7 +113,7 @@ PR が大げさなときは、人間が手で `git checkout develop && git merge
 - `runs/<sid>/subagents/agent-<aid>.jsonl` — subagent 別 transcript
 - `harness/` — 現在の harness 状態（meta worktree 上の最新）
 - `improvements/` — 過去の改善履歴
-- target/plans/<run_id>.html — target が書いた計画書（meta worktree でも見える、git 管理外）
+- `plans/<run_id>.html` — target が書いた計画書（meta worktree でも見える、git 管理外）
 
 **書く**：
 - `harness/<file>` — 改善本体

package/template/{meta-overlay/meta/.claude → develop/harness/meta}/skills/log-reading/SKILL.md

@@ -105,7 +105,7 @@ jq -c '{ts, event, tool: .payload.tool_name // null}' events.jsonl
 
 ### 計画書との照合
 
-session_id から該当する `target/plans/<run_id>.html` を見つけ、これを Read する。計画書は orchestrator と人間の契約。実行が契約とどう乖離したかは、観察の出発点として強い。
+session_id から該当する `plans/<run_id>.html` を見つけ、これを Read する。計画書は orchestrator と人間の契約。実行が契約とどう乖離したかは、観察の出発点として強い。
 
 session_id ↔ run_id の対応は events に出る Write tool_use(plans/<run_id>.html への書き込み)で辿れる。
 

package/template/develop/harness/plan_template.html

@@ -117,7 +117,7 @@
 
 <div class="contract">
   <h2>契約セクション</h2>
-  <p>本計画書は orchestrator と human の合意である。承認された内容からの逸脱には再承認を要する。</p>
+  <p>本計画書は orchestrator と採用 workflow の実行契約である。human approval が必要な workflow では human との合意として扱う。gate 通過後の内容からの逸脱には workflow に従った再判定を要する。</p>
 
   <table>
     <tr><th>項目</th><th>記録</th></tr>
@@ -138,7 +138,7 @@
   <ul>
     <li>本計画書 3.3 に記載されたファイル以外を変更しない</li>
     <li>本計画書 6 の受入条件を全て満たすことをもって完了とする</li>
-    <li>逸脱が必要な場合は status を amended に戻し再承認を得る</li>
+    <li>逸脱が必要な場合は status を amended に戻し、採用 workflow の gate に従って再判定する</li>
   </ul>
 </div>
 

package/template/develop/harness/skills/planning/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: planning
-description: タスク受領時に計画書HTMLを起草・保存する手順。plan_template.html を雛形として用い、`plans/<run_id>.html` に出力する。計画書は人間との契約書として機能するため、合意可能な粒度・検証可能な受入条件・図を含むこと。
+description: タスク受領時に計画書HTMLを起草・保存する手順。plan_template.html を雛形として用い、`plans/<run_id>.html` に出力する。計画書は採用 workflow の実行契約として機能するため、合意可能な粒度・検証可能な受入条件・図を含むこと。
 ---
 
 # planning
 
 ## いつ使うか
-新しいタスクを受領した直後、coder/reviewer に dispatch する前。計画から逸脱して再承認が要る場合の改訂時にも使う。
+新しいタスクを受領した直後、coder/reviewer に dispatch する前。計画から逸脱して workflow gate の再判定が要る場合の改訂時にも使う。
 
 ## 出力先と run_id
 - 雛形：`plan_template.html`
@@ -29,10 +29,13 @@ description: タスク受領時に計画書HTMLを起草・保存する手順。
 - **1.1 受領した依頼（原文）**：原文をそのまま引用。改変しない
 - **1.2 orchestrator の理解**：自分の言葉で言い直す。原文をなぞるのではなく、目的・スコープ・前提を解きほぐす。言い直しが原文より短くなったら情報を落としすぎている
 - **1.3 目的・スコープ・前提**：表を埋める。「スコープ内」「スコープ外」を両方書く（境界の合意が後の逸脱判定の基準になる）。前提条件は「これが崩れたら計画が崩れる」事項を列挙
+- `.lathe/task.json` がある場合は、source type/id、base branch、head branch、task branch、task worktree を 1.2 または 1.3 に必ず含める。後続の `lathe process` が既存計画を同定するための手掛かりになる
+- `.lathe/invocation.json` がある場合は、invocation intent と injected dependencies / constraints を 1.2 または 1.3 に必ず含める。ただしこれは workflow 選択ではなく、採用 workflow が消費する依存性として記述する
 
 ### 2. 採用ワークフロー
 - `workflow/` から1つ選ぶ（YAML ファイル）
 - 「なぜこのテンプレートか」を必ず書く。デフォルト（`workflow/default.yaml`）を選ぶときも理由を書く
+- `lathe process` 起動で `.lathe/invocation.json` が `plan_approval` grant を注入している場合は、採用 workflow がその grant をどう消費するか、または消費できず human escalation する理由をここか契約セクションに明記する
 
 ### 3. 実装計画
 - **3.1 概要**：文章で全体像
@@ -54,7 +57,7 @@ description: タスク受領時に計画書HTMLを起草・保存する手順。
 
 ### 7. リスク・未解決の質問
 - 計画段階で曖昧な点があれば全部ここに出す
-- 1つでもあるなら status は `draft` のまま。承認には進まない
+- 1つでもあるなら status は `draft` のまま。human approval や auto gate には進まない
 
 ### 8. 実行フロー
 - Mermaid `sequenceDiagram` で actors（Human, Orchestrator, Coder, Reviewer）と呼び出し順を描く
@@ -64,6 +67,7 @@ description: タスク受領時に計画書HTMLを起草・保存する手順。
 - 提出日時・承認日時・承認者・完了日時・status を記録
 - 修正履歴は append-only。古い記述を消さない。逸脱が起きた場合は「何を、なぜ変えたか」を記録する
 - 「承認に伴う合意事項」セクションは雛形のまま残す。タスク固有の合意があれば追記する
+- `.lathe/invocation.json` の `plan_approval` grant を採用 workflow が消費して進む場合、承認日時は gate 通過時刻、承認者は `lathe process invocation` とし、「lathe process の injected dependency により計画承認gateを満たした」と修正履歴または合意事項に記録する
 
 ## 図は Mermaid で書く
 将来 PR で人間に渡されることを想定し、GitHub が描画できる Mermaid を使う。画像埋め込みや独自記法は使わない。
@@ -78,6 +82,6 @@ draft → awaiting_approval → approved → in_progress → completed
 
 - 起草中は `draft`
 - 人間に出した時点で `awaiting_approval`
-- 承認を受けたら `approved`、dispatch 開始で `in_progress`
+- 人間の承認、または採用 workflow の auto gate を通過したら `approved`、dispatch 開始で `in_progress`
 - 完了で `completed`
-- 実行中に計画変更が必要になったら `amended` に戻し、修正→再承認
+- 実行中に計画変更が必要になったら `amended` に戻し、修正→採用 workflow の gate 再判定

package/template/git-hooks/post-merge

@@ -1,21 +1,28 @@
 #!/usr/bin/env bash
-# post-merge — auto-run sync.sh after a merge into develop.
+# post-merge — auto-run sync.sh whenever develop or meta absorbs a merge.
 #
-# Lathe stores harness/ as the source of truth on develop. Whenever a meta PR
-# (or any other change) lands on develop, target/.claude/ needs to be regenerated.
-# This hook does that locally for the worktree where the merge happened.
+# Both worktrees host gitignored runtime files (`.claude/`, `CLAUDE.md`, ...)
+# generated by sync.sh from `harness/`. After any merge that brings in new
+# harness content, those runtime files must be regenerated. sync.sh itself
+# is branch-aware (develop → target part, meta → meta part).
 #
-# UI-side merges (GitHub web) do NOT fire this. Run `lathe sync` manually after
-# `git pull` in those cases.
+# Hooks for linked worktrees fire from the common .git/hooks/ dir, so this
+# single hook handles both worktrees.
+#
+# UI-side merges (GitHub web) do NOT fire this. Run `lathe sync` manually
+# after `git pull` in those cases.
 
 set -uo pipefail
 
 BRANCH="$(git symbolic-ref --short HEAD 2>/dev/null || true)"
-[ "$BRANCH" = "develop" ] || exit 0
+case "$BRANCH" in
+  develop|meta) ;;
+  *) exit 0 ;;
+esac
 
 REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" || exit 0
 SYNC="$REPO_ROOT/bin/sync.sh"
 [ -x "$SYNC" ] || exit 0
 
-echo "[lathe post-merge] running sync.sh on develop..."
+echo "[lathe post-merge] running sync.sh on $BRANCH..."
 "$SYNC"

package/template/helper-claude/.claude/CLAUDE.md

@@ -0,0 +1,28 @@
+# Lathe Helper
+
+あなたはこの Lathe project の **operator assistant** です。
+
+cwd は project root（共有 bare repo `.git/` と worktree `main/`、`develop/`、`meta/` が並ぶ場所）。worktree の中で起動した別 claude session（target / meta agent / user の vibe coding session）とは **別の存在**で、それらの仕事を取らない。
+
+`develop/` で起動された claude は target、`meta/` で起動された claude は meta agent、それぞれ自分の `CLAUDE.md`（gitignored、`harness/` から sync.sh で生成）を読み込む。あなたの role はここ project root にだけ効き、worktree 境界で claude のスコープは止まる。
+
+## 役割
+
+- ユーザーが Lathe コマンドや構造で迷ったら案内する
+- 求められれば Bash でコマンドを代行実行する
+- worktree / branch / runs / improvements の現状を git 経由で答える
+- target / meta が何をしているかは、`develop/CLAUDE.md` や `meta/meta/CLAUDE.md` を Read してから答える
+
+詳細は `lathe-cli` skill を参照（`description` がマッチすれば自動で load される）。
+
+## やらない
+
+- **user の app コードを実装しない**。実装は user 自身が `features/<name>/` で vibe coding するか、target agent が `lathe process <pr#>` で polish する仕事
+- worktree や branch を勝手に作らない（user に提案して、user が `lathe feature` 等で実行）
+- `develop/` や `meta/` の runtime ファイル（CLAUDE.md, .claude/, hooks/, workflow/ 等）を直接編集しない（gitignored、sync.sh で `harness/` から regenerate されるため）。改善が必要なら meta worktree で `harness/` を編集 → develop に PR → post-merge hook で sync
+
+## なぜ project root にいるか
+
+worktree 境界で claude の CLAUDE.md 探索は止まる（main/.git の linked-worktree marker で boundary）ため、ここに role-prescriptive な記述を置いても main/develop/meta の session には伝播しない。あなたの role はあくまで「project root にいる時だけ」効く。
+
+worktree 内で claude を起動した時はそれぞれの CLAUDE.md（target なら orchestrator、meta なら meta agent）が支配する。あなたはその外側のレイヤー。

package/template/helper-claude/.claude/skills/lathe-cli/SKILL.md

@@ -7,15 +7,23 @@ description: ユーザーが Lathe project（main/develop/meta worktree + bare .
 
 このプロジェクトは Lathe で初期化された agent harness。あなたはユーザーの **Lathe 操作のアシスタント**。実装そのものは target / meta agent が別 worktree で行うので、あなたは「コマンドを案内する / 代行する / 状態を説明する」役。
 
-## 構成（`lathe init` 直後の姿）
+## 構成（`lathe init` 直後の姿、v1.2 layout）
 
 ```
 project_root/
 ├── .git/         共有 bare repo（worktree 全部がここを参照）
-├── .claude/      この skill とユーザーの helper 設定
+├── .claude/      この skill とユーザーの helper 設定（filesystem only at root）
+├── CLAUDE.md     helper の役割記述
 ├── main/         worktree on main 枝（user の app code）
-├── develop/     worktree on develop 枝（target が住む。harness/ + 生成された target/.claude/）
-└── meta/         worktree on meta 枝（meta agent + improvements/）
+├── develop/      worktree on develop 枝
+│   ├── harness/        tracked（target + meta 両方の agent spec の正、harness/meta/ も含む）
+│   ├── bin/sync.sh     tracked（branch 判定で target or meta runtime に展開）
+│   ├── runs/, improvements/, plans/   tracked
+│   ├── .gitignore      tracked（CLAUDE.md, .claude/, hooks/, workflow/ などを ignore）
+│   └── （CLAUDE.md, .claude/, hooks/, workflow/, plan_template.html）  gitignored sync output
+└── meta/         worktree on meta 枝
+    ├── harness/, bin/, runs/, improvements/, .gitignore  tracked（develop から inherit）
+    └── （CLAUDE.md, .claude/）  gitignored sync output（harness/meta/ から）
 ```
 
 加えて、運用中に動的に増えるもの：
@@ -29,17 +37,21 @@ project_root/
 |---|---|---|
 | `main` | release stable | 普段は user、最終的に develop からの PR で更新 |
 | `develop` | integration、target の住処、runs/ の auto-commit 先 | target session、meta からの PR が merge される |
-| `meta` | harness 改善 + improvements/ 蓄積 | meta operator + meta agent |
+| `meta` | harness 改善（含む harness/meta/）と improvements/ 蓄積 | meta operator + meta agent |
 | `feature/<name>` | user の vibe code | user が `lathe feature` で生やす |
 
 ## コマンド一覧
 
 ```
 lathe init                          ← 既に走った前提
-lathe target [args...]              develop/target で claude 起動（debug or 直接 task）
-lathe meta [args...]                meta/meta で claude 起動
+lathe target [args...]              develop worktree で claude 起動（debug or 直接 task）
+lathe meta [args...]                meta worktree で claude 起動
 lathe sync                          develop の bin/sync.sh 手動実行（post-merge hook が動かない時）
-lathe process <pr#>                 PR pickup → tasks/<pr#>/ worktree 作成 → target 起動
+lathe plan pr <pr#>                 PR pickup → target が計画だけ作る
+lathe watch [--once]                develop 宛て新規 PR を監視し、未計画なら lathe plan --print pr
+lathe process <pr#>                 PR pickup/reuse → tasks/<pr#>/ worktree + task/pr-<pr#> branch → target が計画承認待ちなしで実装まで進める
+lathe process --manual-prompt <pr#> 旧式 Claude Code 用。prompt 手貼り fallback
+lathe process --no-launch <pr#>     tasks/<pr#>/ 準備だけ行い、target は起動しない
 lathe feature <name> [--from main|develop]
                                     features/<name>/ worktree 作成、新 feature/<name> 枝
 lathe feature-done <name> [--keep-branch] [--keep-remote] [--force]
@@ -68,12 +80,23 @@ PR が立ったら（overseer 役）：
 
 ```sh
 cd project_root
-lathe process <pr#>             # tasks/<pr#>/ worktree が新規作成、target が起動
+lathe plan pr <pr#>             # 任意: 計画だけ作る。lathe watch なら自動
+lathe process <pr#>             # tasks/<pr#>/ worktree が作成/reuse され、target が起動
 ```
 
-claude TUI が立ち上がるので、表示された prompt：「Read .lathe-task.md from the added directory and process it.」を貼る。
+`lathe plan` / `lathe process` は `tasks/<pr#>/` を専用 local branch `task/pr-<pr#>` で作る。元の `feature/<name>` worktree が残っていても同じ branch checkout 競合を起こさない。`tasks/<pr#>/.lathe/task.json` と `.lathe/brief.md` は Lathe が生成する transport protocol、`.lathe/invocation.json` は runtime dependency injection で、workflow/gates/delivery は target harness が選ぶ。claude TUI は初回 prompt が投入された状態で立ち上がる。古い Claude Code で prompt 引数が効かない場合だけ、`lathe process --manual-prompt <pr#>` を使って表示された prompt を貼る。
 
-orchestrator が plan HTML を起こして承認待ちで止まる。承認したら coder/reviewer に dispatch、PR branch に commit/push されて PR が更新される。
+`lathe plan pr <pr#>` は plan HTML を起こして承認境界で止まる。`lathe process <pr#>` は workflow を固定せず、計画承認 grant と PR delivery adapter を `invocation.json` で注入する。target harness は任意の workflow を選び、その依存性を安全に消費できるなら既存 plan を再利用または新規作成して、計画承認待ちは挟まず coder/reviewer に dispatch する。仕様不明、high-risk 変更、検証不能など selected workflow の escalation triggers に該当する場合だけ human に戻す。完了時は `task/pr-<pr#>` に commit し、`git push origin HEAD:<PR head branch>` で PR が更新される。
+
+### develop PR をローカル監視する
+
+```sh
+cd project_root
+lathe watch --once                 # 1回だけ確認
+lathe watch --interval 60          # 継続監視。新規PRごとに lathe plan --print pr
+```
+
+watch は workflow を選ばない。新規PRを見つけたら task worktree と `.lathe/` transport を作り、target harness に planning-only prompt を渡すだけ。人間承認、実装、merge の要否は harness workflow 側で決める。
 
 ### feature を終わらせる
 
@@ -117,9 +140,9 @@ lathe ls                        # worktree, branch, recent runs/improvements
    - それぞれの worktree は固定の枝。別枝は別 worktree。switch すると `fatal: 'X' is already used by worktree at '...'`
    - feature を始めたいなら `lathe feature <name>` を使う
 
-2. **`target/.claude/`、`target/CLAUDE.md` などを直接編集しない**
-   - これは `harness/` から sync.sh で生成されたコピー。次回 sync で上書きされる
-   - 改善は `harness/` 配下を編集（meta worktree 内で）→ develop に PR → post-merge で反映
+2. **`develop/.claude/`、`develop/CLAUDE.md`、`meta/.claude/`、`meta/CLAUDE.md` などを直接編集しない**
+   - これは `harness/`（meta 用は `harness/meta/`）から sync.sh で生成された runtime コピー。次回 sync で上書きされる
+   - 改善は `harness/` 配下を編集（meta worktree 内で。target 改善は `harness/`、meta 自身の改善は `harness/meta/`）→ develop に PR → post-merge hook で sync 自動実行 → 反映
 
 3. **`features/<name>/` を `rm -rf` で消すと metadata が残る**
    - `git worktree list` にゾンビが出る