@shinaps/skills 0.32.1 → 0.33.0

package/plugins/shinaps-claude/references/linear/configuration.md

@@ -1,10 +1,10 @@
 # プロジェクト設定
 
-設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定は `config_version: 1` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。利用前に同梱CLIで構造を検証し、合意・参照先・工程の実在確認は各手順で行う。
+設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定は `config_version: 2` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。利用前に同梱CLIで構造を検証し、合意・参照先・工程の実在確認は各手順で行う。
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.32.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.32.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.33.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.33.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 ```sh
 shinaps-skills --version
@@ -64,28 +64,39 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 | キー | 内容 |
 | --- | --- |
-| `config_version` | 整数 `1`。パッケージ版とは独立した契約版 |
+| `config_version` | 整数 `2`。パッケージ版とは独立した契約版 |
 | `$schema` | 任意のエディタ補助。固定URLは下記。CLIはこのURLを取得しない |
 | `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
 | `target.workspace` | Linearのworkspace |
 | `target.team` | チームのキー（例 `SHINAPS`） |
 | `target.project` | 使うprojectのURL。projectを使わない運用では `null` |
 | `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
-| `statuses` | 工程キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
+| `statuses` | 状態キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
 | `stop_after` | 終了地点（下の「終了地点」） |
-| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。許可なしは `[]` |
+| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli`、manual: `bridge_request`）も含む。許可なしは `[]` |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
-| `implementation_skill` | Issueの実装・修正に使うruntimeの入口。担当数は固定せずメインが作業ごとに決める。`dev-claude`（auto/manualともCodexがローカルClaude CLIの同じsessionへ依頼する）、`dev-codex`（Issueごとの別Codexタスクがその入口を実行し、会話側は進行・Agent QAを担当する）、または `dev-managed-cc`（linear-executeを実行する会話が進行役になり、IssueごとのClaude Managed Agentsセッションのleadがその入口で実装する） |
-| `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）、`{ "mode": "manual", "tool": "plasma" }` または `{ "mode": "manual", "tool": "webstorm" }`（AIが単位を計画し、単位外を安全にstashしてstage・提示、人がレビュー・修正・commit） |
+| `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIが単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人の単位承認後にAIがcommit）。開始時の値で経路も決まる（下の「経路」） |
 | `path_policy_overrides` | パス別に `review_flow` を上書きするルールの一覧。例外なしは `[]`（下の「パス別の方針」） |
 
-- 利用者と合意した `review_flow` は両方とも対象のstageを許可し、`auto` だけAIのcommitも許可する。`manual` のcommitは人が行う。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
-- `implementation_skill` が決めるのは、実装・修正の担当と実行方式だけである。`permissions`・`stop_after`・人レビュー・コミットの方針と、`dev_delegation`・worktreeの作成・別セッションの作成の許可を変えない。その場の明示的な指定は設定に優先する。既存の設定にキーがなくても、自動で書き加えない。担当と工程の対応は [workflow.md](workflow.md) の「担当と窓口」にある。
+- 利用者と合意した `review_flow` は両方とも対象のstageとAIのcommitを許可する。`auto` は独立レビュー後、`manual` は人の単位承認後にcommitする。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
 - どちらのflowもdev内の確認、必須検証、Agent QA、必要なHuman QAを維持する。`auto` は独立レビューを必須とし、利用できなければ自己確認で代用せず止める。人レビュー省略を人のレビュー済みと記録しない。
-- 工程キーは [workflow.md](workflow.md) の工程表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
+- 状態キーは [workflow.md](workflow.md) の「工程とステータス」の表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
 - `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
 
+## 経路
+
+実装・修正・コミットはClaude Codeが `shinaps:dev-claude` と `shinaps:commit` で行う。Codexとの間の経路は、着手時に通常設定の `review_flow.mode` で一つに決める。
+
+| 通常設定 | 経路 | 必要な許可 |
+| --- | --- | --- |
+| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli` |
+| `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` |
+
+- 経路はIssueの途中で切り替えない。`permissions`・`stop_after`・`dev_delegation`・worktreeや別セッションの作成の許可は、経路によって変わらない。
+- manual経路でパス別の方針によりauto単位が生じた場合は、対話session内のClaudeが独立レビュー後に人の承認なしでcommitし、人のレビューの省略を記録する。
+- auto経路でmanual単位が生じた場合、非対話CLIは人との相談・承認を扱えない。CodexはLocal Agent QAで判定記録を照合した時点で検出し、差分確定の依頼前に人へ一問で確認する: 「今回の明示指示でその単位をautoとして進める」か「Issueを中止し、未コミット差分を保全したまま設定（通常設定またはルール）を見直してから、manual経路でやり直す」か。黙ってautoへ落とさない。`commit` の中で検出した場合は手順を進めず、判定を記録してresultへ返す。
+
 ## パス別の方針
 
 `path_policy_overrides` は、各予定コミットに入る全変更を対象に方針を適用する。Linear進行でも単独の `commit` でも同じ規則を使う。新規設定は `path_policy_overrides: []` とし、具体的なパスと上書き項目を利用者と合意した場合だけルールを追加する。
@@ -98,8 +109,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 }
 ```
 
-- 上書きは `review_flow` オブジェクト全体を置換する。autoへ切り替える場合はtoolを引き継がない。各ルールは空でない `paths` と `review_flow` オブジェクト だけを必須とする。その他のキー、省略、不正値や構文は設定不備として依存工程を止める。
-- パス別のflowもstageとcommit担当を上記のとおり決める。push・公開・終了地点・ツール権限・必要なQAは変更しない。実装開始時のClaude CLI sessionを保持し、パス例外では切り替えない（[Claude CLI](claude-cli.md)）。
+- 上書きは `review_flow` オブジェクト全体を置換する。各ルールは空でない `paths` と `review_flow` オブジェクト だけを必須とする。その他のキー、省略、不正値や構文は設定不備として依存工程を止める。
+- パス別のflowもstageとcommit担当を上記のとおり決める。push・公開・終了地点・ツール権限・必要なQAは変更しない。経路はパス例外では切り替えず、単位のmodeと経路が異なる場合は上の「経路」に従う。
 - パス設定への合意は対象と工程の許可であり、変更内容に含まれる未合意仕様や権限拡張への承認ではない。内容や拡張子から例外許可を推定しない。
 
 ### パターンとコミット全体の照合
@@ -109,24 +120,34 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 各予定コミットの全変更に現れる旧・新パスが、一つのルールのパターン一覧で覆われる場合だけ、そのルールをそのコミット全体へ適用できる。追加は新パス、削除は旧パス、改名・移動は両方を含め、modeだけの変更も対象にする。新パスだけの一覧や現在残っているファイルだけでは判定しない。
 
 - コミット全体に適用できるルールがなければ、そのコミット全体を通常方針とする。複数ルールをファイル別・項目別に合成しない。
-- コミット全体に適用できるルールが複数ある場合、`review_flow` のmodeとtoolが両方同じならその方針を採用し、適用した全ルールを記録する。同じmanualでもtoolが異なるなど、一つでも結果が異なれば依存工程を止めて競合の解消を求める。並び順やパターンの詳細度では優先しない。
+- コミット全体に適用できるルールが複数ある場合、`review_flow` のmodeが同じならその方針を採用し、適用した全ルールを記録する。一つでも結果が異なれば依存工程を止めて競合の解消を求める。並び順やパターンの詳細度では優先しない。
 - モードによらず自然な責務単位を先に決め、その予定コミットごとに判定する。同じ依頼に別の変更があっても、独立した範囲内コミットには例外を適用できる。例外取得だけを目的とした恣意的な分割はしない。依頼全体は網羅性と最終照合に使い、方針を固定する単位にはしない。
 
 ### 判定記録と変更時の扱い
 
-各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
+各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。manualの単位は承認記録（承認発話の要約・承認したtree hash・作成したSHA）も残す。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
+
+予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人の修正・承認を経てcommitした場合は `commit` に従い、commit後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
 
-予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人が修正・commitした場合は `commit` に従い、完了通知後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
+### config_version 1 からの移行
 
-### 旧設定の移行
+0.33.0から `config_version: 1`、`implementation_skill`、`review_flow.tool`、許可の `codex_task`・`managed_session:*` は受け付けない。Codex実装タスク・Managedセッションの経路はなくなるため、次の順で展開する。
 
-0.32.0から `.shinaps/linear.yaml` とscalar `review_flow` は受け付けない。`linear-plan` で以下を行い、正本発見・検証・保存を完了してから再開する。CLIは移行しない。
+1. 進行中Issueを棚卸しする（Codex実装タスク・Managedセッション上の未取り込み差分、Coding・QA中のIssue）。
+2. 各Issueを、旧版のまま終了地点まで進めるか、差分を作業先へ取り込んで実装工程からClaudeへ引き継ぐかに分ける。
+3. 0.33.0を公開し、各端末のpluginとCLIを更新する。
+4. リポジトリごとに下の手順で設定と補足を移行し、CLIで検証する。
+5. 進行中Issueを再開する。
 
-1. 旧設定の正本と保存方式、既存の許可・終了地点・補足を確認する。JSONとYAMLが共存する場合は内容を比較し、移行未完了として扱う。
-2. `config_version: 1`、必須の `config_storage` と `path_policy_overrides` を明記する。省略していた値も移行案で明示する。autoは `{ "mode": "auto" }`、manualは利用する `tool` を含むオブジェクトへ移す。既存のWebStorm等の合意は維持できるが、不明なUIをruntimeから推測しない。
-3. Claudeの実装は両modeとも `claude_cli` を使う。旧Bridge経路からの権限変更は移行案へ明記し、許可なく追加しない。`bridge_request` 自体は有効で、他runtimeや別用途の既存許可を削除しない。
-4. YAMLコメントの運用条件は `instructions.md` または対応する参照資料へ移し、sharedでは参照と共有対象に含める。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・`document_only_changes`・パス別ai_commitは除去する。旧noneは例外なしへの移行案、旧ai_commitは具体的パスへの移行または廃止を合意し、暗黙変換しない。
-5. 合意済みのJSONを保存して検証し、旧YAMLを除き、ignore・参照・共有対象も更新する。追跡解除・stage・commitは既存の許可と安全手順に従う。新旧差分で許可・工程・保存方式・補足が保たれていることを確認する。
+`linear-plan` は各リポジトリで以下を行い、検証・保存を完了してから再開する。CLIは移行しない。
+
+1. 現在の設定・許可・補足・進行中Issueを確認する。
+2. `config_version: 2` にし、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool` を削除する。
+3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
+4. `statuses` は変更しない。補足からCodex実装タスク・Managed・tool・人がコミットする条件の記述とそれらの資料へのリンクを除き、合意日付を残す。
+5. `$schema` を0.33.0のURLへ更新し、CLIで検証して読み戻す。
+
+旧 `.shinaps/linear.yaml` とscalar `review_flow`（0.32.0より前）も同じ手順でv2のJSONへ移す。YAMLコメントの運用条件は `instructions.md` または対応する参照資料へ移す。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・`document_only_changes`・パス別ai_commitは除去し、旧noneは例外なし、旧ai_commitは具体的パスへの移行または廃止を合意して暗黙変換しない。保存後に旧YAMLを除き、ignore・参照・共有対象も更新する。追跡解除・stage・commitは既存の許可と安全手順に従う。
 
 ## 終了地点
 
@@ -134,7 +155,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 | `stop_after` | 止まる地点 |
 | --- | --- |
-| `pre_push_qa` | `code_review` の工程を終えた後、push前の最終Agent QAが合格し、記録した時点 |
+| `pre_push_qa` | 差分確定を終えた後、公開確認でpush前の最終Agent QAが合格し、記録した時点 |
 | `pr_created` | 必須の検証と許可されたpush・PR作成を終え、IssueとPRの相互リンクを確認した時点。Staging QAが未実施なら残項目として記録する |
 | `issue_done` | Issueの必須受入条件をすべて満たし、Doneにした時点 |
 
@@ -147,19 +168,17 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | --- | --- |
 | `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
 | `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
-| `codex_task` | 対象IssueごとのCodex実装タスクの新規作成・状態確認・実装や修正や許可済みコミットの依頼。アーカイブ、worktree作成、操作許可の追加、タスク側でのゴールや実装タスクの再作成は含めない。ツールの明示依頼要件も満たす。アーカイブの合意と手順は [完了後の整理](codex-task.md#完了後の整理) に従う |
-| `claude_cli` | auto/manual共通のClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。既存CLI設定と個別の操作権限を維持する（[手順](claude-cli.md)） |
-| `bridge_request` | Bridgeによる別会話との任意の進行の引き渡し・人の完了報告。報告は照合材料であり、CLIの実装経路・レビューUI・操作許可を変更しない（[手順](workflow.md#bridgeでの任意の引き渡し・報告)） |
-| `managed_session:<USD>` | 対象IssueごとにClaude Managed Agentsのセッションを作り、同じIssueのコミット前のQA修正には続けて使う（コミット後の修正は新しいセッションで行う。扱いは[Managedセッション](managed-session.md)の「QAと修正」に従う）。`<USD>` は1セッションの予算の上限で、正の整数のUSD（作成時にセントへ換算する）。値がない、または正の整数でない場合は設定不備として止める。含める操作: 作業先のコミット済みの内容（git bundle）と、あれば `~/.claude/CLAUDE.md` のFiles APIへのアップロード、上限内での予算の設定、一覧から名前で一件に特定したvaultの受け渡し、状態・イベント・出力の取得、回答と修正依頼の送信、取得した差分の作業先への適用と作業記録の展開。含めない操作: 上限を超える予算の引き上げ（その場で確認する）、セッションとファイルのアーカイブ・削除、定義のapply、vaultの作成・変更 |
+| `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。既存CLI設定と個別の操作権限を維持する（[手順](claude-cli.md)） |
+| `bridge_request` | manual経路で、CodexがBridgeで対話Claude Codeセッションへ行う依頼と報告の受け取り、および別会話との任意の進行の引き渡し。報告は照合材料であり、操作許可を変更しない（[手順](bridge.md)） |
 | `push` | 対象Issueの作業ブランチの通常のpush |
 | `pr_create` | 対象IssueのPRの作成と更新 |
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
 | `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
 | `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
-| `dev_delegation` | `implementation_skill` で選んだdevの入口の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
+| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
-- 開発進行には `issue_update` が必要。Claudeの入口はauto/manualとも `claude_cli` とローカルClaude CLIを使う。今回の明示依頼による同じ経路の許可も引き継ぐ。Codexの入口は `codex_task` とタスク操作ツール、Managedの入口は `managed_session:<USD>`・`dev_delegation` と認証済み `ant` CLIが必要。初期設定は `issue_update`・選んだ経路の許可・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。manualの提示UIは `review_flow.tool` で選び、利用不能なら止める。
+- 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
 - `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
 - この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
 - 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
@@ -182,12 +201,12 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ## 設定例
 
-shinaps-skills側の例。shinaps-aiも、自分のリポジトリの設定で同じprojectを指す。
+manualの設定例。同じprojectを複数のリポジトリがそれぞれの設定で指してよい。
 
 ```json
 {
-  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.32.1/plugins/shinaps-claude/references/linear/configuration.schema.json",
-  "config_version": 1,
+  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.33.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "config_version": 2,
   "config_storage": "shared",
   "target": {
     "workspace": "shinaps",
@@ -207,17 +226,15 @@ shinaps-skills側の例。shinaps-aiも、自分のリポジトリの設定で
     "done": "Done"
   },
   "stop_after": "pre_push_qa",
-  "implementation_skill": "dev-claude",
   "review_flow": {
-    "mode": "manual",
-    "tool": "webstorm"
+    "mode": "manual"
   },
   "path_policy_overrides": [],
   "cycle_report": null,
   "permissions": [
     "development_operations",
     "issue_update",
-    "claude_cli",
+    "bridge_request",
     "dev_delegation"
   ],
   "references": {
@@ -248,7 +265,7 @@ Claudeもこの手順で初期設定を行える。合意した設定の保存
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
 3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離（[workflow.md](workflow.md) の工程表に対応するステータス）を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
-4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`、`review_flow`、`team_settings`、Cycle報告、`implementation_skill`）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
+4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`、`review_flow`、`team_settings`、Cycle報告）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
 5. 合意した方式の正本へ、下の保存手順に従って保存する。sharedでは採用する補足の `references` と共有対象を照合し、別checkoutでも同じ条件を読めるようにする。同梱CLIでJSONを検証し、正本と補足を読み直して確認する。
 6. Linearのチーム設定の変更は、設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
 
@@ -295,8 +312,4 @@ sharedでは `.shinaps/.gitignore` 自身、`linear.json`、採用した補足
 
 `instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法など、プロジェクト共通の条件・手順・相対パス・URLを書く。共通の手順は複製しない。端末固有の絶対パス、session/thread ID、一時的なログイン状態、進捗、QA結果は現在の `.shinaps/work/` へ記録する。秘密値はshared・localのどちらにも保存しない。
 
-委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。Managedのセッションには[初回メッセージ](managed-session.md#初回メッセージと修正依頼)で渡す。
-
-## 旧dev入口からの移行
-
-通常／ultraの人数指定は廃止した。旧 `dev-claude-ultra`・`dev-codex-ultra`・`dev-managed-cc-ultra` は、それぞれ `dev-claude`・`dev-codex`・`dev-managed-cc` へ設定と呼び出しを移行する。旧名を受け付ける別名は残さない。移行が依頼・許可されている場合はruntime・操作許可・QA・終了地点を保って該当名だけを更新する。未許可の設定変更は依存する実行前に確認する。人数は恒久設定へ保存せず、各作業の体制記録に残す。
+委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。

package/plugins/shinaps-claude/references/linear/configuration.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.32.1/plugins/shinaps-claude/references/linear/configuration.schema.json",
-  "title": "Shinaps Linear configuration v1",
+  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.33.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "title": "Shinaps Linear configuration v2",
   "type": "object",
   "properties": {
     "$schema": {
@@ -9,7 +9,7 @@
     },
     "config_version": {
       "type": "integer",
-      "const": 1
+      "const": 2
     },
     "config_storage": {
       "enum": ["shared", "local"]
@@ -109,9 +109,6 @@
     "stop_after": {
       "enum": ["pre_push_qa", "pr_created", "issue_done"]
     },
-    "implementation_skill": {
-      "enum": ["dev-claude", "dev-codex", "dev-managed-cc"]
-    },
     "review_flow": {
       "$ref": "#/definitions/reviewFlow"
     },
@@ -144,19 +141,14 @@
             "enum": [
               "issue_update",
               "development_operations",
-              "codex_task",
               "claude_cli",
               "bridge_request",
+              "dev_delegation",
               "push",
               "pr_create",
-              "merge",
-              "dev_delegation"
+              "merge"
             ]
           },
-          {
-            "type": "string",
-            "pattern": "^managed_session:[1-9][0-9]*$"
-          },
           {
             "type": "string",
             "pattern": "^(deploy|publish|evidence):[^\\s]+$"
@@ -265,7 +257,6 @@
     "team_settings",
     "statuses",
     "stop_after",
-    "implementation_skill",
     "review_flow",
     "path_policy_overrides",
     "permissions",
@@ -275,31 +266,14 @@
   "additionalProperties": false,
   "definitions": {
     "reviewFlow": {
-      "oneOf": [
-        {
-          "type": "object",
-          "properties": {
-            "mode": {
-              "const": "auto"
-            }
-          },
-          "required": ["mode"],
-          "additionalProperties": false
-        },
-        {
-          "type": "object",
-          "properties": {
-            "mode": {
-              "const": "manual"
-            },
-            "tool": {
-              "enum": ["plasma", "webstorm"]
-            }
-          },
-          "required": ["mode", "tool"],
-          "additionalProperties": false
+      "type": "object",
+      "properties": {
+        "mode": {
+          "enum": ["auto", "manual"]
         }
-      ]
+      },
+      "required": ["mode"],
+      "additionalProperties": false
     }
   }
 }

package/plugins/shinaps-claude/references/linear/execution.md

@@ -20,23 +20,21 @@
 
 ## Issue開始時の実装体制
 
-進行役のメインは各Issueの設定・受入条件・関連コード・既存検証を短く確認し、[実装体制の判断](../dev/staffing.md)に従って設計担当の起動前に役割・人数・専任なしの責任者・理由を決める。`implementation_skill` は実行環境の選択であり、担当数を固定しない。Issueごとに判断し、Cycleや前のIssueの体制を無条件に流用しない。
+進行役は各Issueの設定・受入条件・関連範囲・既存検証・リスクを短く確認し、体制判断の材料として必須検証・許可範囲とともにClaudeへ渡す。初期体制はClaudeのメインが材料と現物から[実装体制の判断](../dev/staffing.md)に従って設計担当の起動前に決め、進行役へ報告する。Issueごとに判断し、Cycleや前のIssueの体制を無条件に流用しない。
 
-初期体制を人へ短く示し、根拠・必須検証・許可範囲とともに実装担当へ渡す。実装側のメインは初期確認と照合し、途中の新しい根拠で必要な担当を増やして進行役へ報告できる。追加担当の確認が必要な工程は結果が揃うまで完了にしない。通常の体制決定・増員は人の承認待ちにせず、仕様・範囲・許可・予算の変更だけ確認する。
+Claudeのメインは途中の新しい根拠で必要な担当を増やし、進行役へ報告する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。通常の体制決定・増員は人の承認待ちにせず、仕様・範囲・許可・予算の変更だけ確認する。
 
 ## 継続と待機
 
 原則、確定した順序で一つずつ実行する。Issue単体の依頼では完了後に別Issueへ進まない。複数対象では、現在のIssueのQA・必要な人の対応・コミットを残して次へ切り替えない。
 
-- 実装担当の作業中や、人レビュー・Human QA・本人認証・予定された手動コミット・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
-- 観測結果が得られないことだけでは終了条件を満たさない。同じタスクの状態を確認して待機を続け、新しい実装タスクやゴールを作る根拠にしない。
-- 許可範囲で自分が解消できる実装・QAの不具合は修正して再検証する。テストの失敗だけでバックログ実行を打ち切らない。
+- 実装担当の作業中や、manualの単位承認・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答がないことや待ち時間をブロッカー到達・承認・完了と扱わない。
+- 観測結果が得られないことだけでは終了条件を満たさない。同じsessionの状態を確認して待機を続け、新しいsessionやゴールを作る根拠にしない。
+- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
 - 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
 - バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
 - Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
 
-合意した終了地点に達して成果を記録した後、Codexの専用実装タスクは [完了後の整理](codex-task.md#完了後の整理) の条件に従って会話側が整理する。終了地点への到達・IssueのDone・ゴールの完了と、タスク整理の成否は分けて扱う。
-
 ## ゴール機能
 
 実行開始の必須条件として、上の対象と終了条件を持つゴールが設定済みであることを確認する。ゴールの作成成功、または同じ対象の既存ゴールの状態をツールで確認してから実装・QA・公開の進行を始める。文章で目標を書くだけでは設定済みとしない。ツールが利用者の明示依頼を要求する場合、スキルの選択だけで迂回せず、既存の明示依頼を使い、なければ開始時に一度確認し、回答と設定成功を待つ。同じ対象のゴールは再利用し、別の未完了ゴールを上書きしない。予算は明示された場合だけ設定する。モデルのツールでゴールの設定を確認できないruntimeでは、そのruntimeのlinear-executeの手順が定める確認手段で確認する。確認できなければ下の段落に従って開始前で止まる。

package/plugins/shinaps-claude/references/linear/workflow.md

@@ -4,116 +4,99 @@
 
 | 担当 | 責務 |
 | --- | --- |
-| Codex | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、Claudeの入口のときのCLIでの依頼、Local・Staging・ProductionのAgent QA、許可されたPR・配備等の運用、結果の記録、人への依頼 |
-| 実装担当 | 技術調査、`implementation_skill` で選んだdevの入口による実装・自動テスト・簡素化・セルフレビュー、QA指摘の修正、成果と人の対応結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
-| 人 | 未合意の仕様・権限の判断、manualのコードレビュー・必要な修正・コミット、本人の操作が必要な認証等、必要なHuman QA |
+| Codex（進行役） | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、作業先設定からの経路と許可の確定、体制判断の材料（受入条件・関連範囲・既存検証・リスク）の提示、Claudeへの依頼（auto: CLI、manual: Bridge）、Local・Staging・ProductionのAgent QA、単位・全体の照合、許可されたpush・PR・merge・配備・公開、Issueへの記録、人への依頼 |
+| Claude（実装担当・Claude Code） | 初期体制の決定と途中の増員、`shinaps:dev-claude` による技術調査・計画・実装・検証・独立レビュー、QA指摘の修正、`shinaps:commit`（auto: 独立レビュー後にcommit、manual: 提示・相談・人の単位承認後にcommit）、結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
+| 人 | 未合意の仕様・権限の判断、manualの単位レビュー・修正相談・承認、本人の操作が必要な認証等、必要なHuman QA |
 
-実装担当は、作業先リポジトリの設定の `implementation_skill` で決まる。Claudeの入口（`dev-claude`）では、auto/manualともCodexが[ローカルClaude CLI](claude-cli.md)を起動し、同じsessionをresumeする。パス例外はreview_flow全体に反映し、実装経路は変えない。manualのUIは実効 `review_flow.tool` で決める。Codexの入口（`dev-codex`）では、この文書でClaudeが行うとした実装・修正・コミット・完了報告を会話側とは別のCodex実装タスクが行い、[Codex実装タスク](codex-task.md)の手順で依頼・結果を扱う。Bridgeは使わない。どちらでも実装担当はdev内レビューと検証を終えて進行役へ結果を返し、進行役がLocal Agent QAを行う。実装担当の報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
+経路は着手時に通常設定の `review_flow.mode` で決まる（[経路](configuration.md#経路)）。autoはCodexが[ローカルClaude CLI](claude-cli.md)の同じsessionをresumeし、manualはWebStorm内の対話Claude Codeセッションへ[Bridge](bridge.md)で依頼する。どちらでもClaudeはdev内レビューと検証を終えて結果を返し、CodexがLocal Agent QAを行う。Claudeの報告をQA合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 
-Managedの入口（`dev-managed-cc`）では、linear-executeを実行している会話（ClaudeまたはCodex）が進行役になり、`linear/` の各文書でCodexが行うとした進行・Agent QA・記録・人への窓口を行う。実装・修正はIssueごとのClaude Managed Agentsセッションのleadがその入口のskillで行い、[Managedセッション](managed-session.md)の手順で依頼・結果を扱う。この文書でClaudeまたは実装担当が行うとした実装・修正・完了報告はleadが行う。leadはローカルの作業先へ書けないため、差分の適用と、人の対応結果の受け取りは進行役が行う。コミット工程は進行役が `commit` に従い、autoなら自身がcommit、manualなら安全なstash・stage・提示まで行い人のcommitを待つ。BridgeとCodex実装タスクは使わない。
-
-人への質問と依頼は会話側のCodexが窓口になる。実装担当は人へ着手確認やコミット依頼をしない。人がClaudeへ直接伝えた指示や結果は、Claudeが保持してCodexへ報告する。
-
-CodexはQAで見つけた不具合をQAの工程の中で修正せず、再現条件と証拠を実装担当へ返す。Codexの入口でも会話側は修正せず、同じ実装タスクへ戻してから改めてQAを行う。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+- Issueに関わる人への質問・依頼はCodexが窓口になる。manualでは人がWebStormの対話セッションで直接Claudeと相談する。Claudeは決定事項を報告に含め、CodexがIssueへ記録する。
+- manualで人とClaudeが作業している間、Codexは同じIssueへ追加の指示を送らず、ゴールを `active` のままClaudeの報告を待つ。Claudeの報告後、CodexのQA中は人とClaudeが作業ツリーを編集しない。
+- CodexはQAで見つけた不具合を修正せず、再現条件と証拠を同じClaude sessionへ返す。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
 
 Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
 
-## 再確認せず進める条件
-
-| 状況 | 必要な行動 |
-| --- | --- |
-| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | 実装担当は人へ着手を再確認せず、指定されたスキルで実行する |
-| devの入口の中で計画上の判断が必要になった | 実装担当が会話側のCodexへ相談する。Codexは既存の合意で判断できれば回答し、人へ再承認を求めない |
-| QAで受入条件の範囲内の不具合が見つかった | CodexがClaudeへ修正を依頼し（Codexの入口では同じCodex実装タスクへ依頼し）、実装担当は人の着手許可を改めて取らずに修正する。Codexが再検証する |
-| Claudeが人のレビュー・コミット完了をBridgeで報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
-| 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
-| Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
-
-「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各CLI・Bridge依頼に書く。
-
-## 人に確認する条件
-
-目的・仕様・受入条件・許可範囲の変更、設定で必要な未実施の人のレビュー、Human QA、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾は、人に確認する。経過時間、無回答、Bridgeの送信成功や受領通知を、人の完了や合格として扱わない。
-
 ## 工程とステータス
 
-| 工程キー | 工程 | 内容・次へ進む条件 |
+主フローは5工程で、各工程が使う `statuses` のキーはLinear上の表示状態の対応を表す。
+
+| 工程 | 状態キー | 内容と次へ進む条件 |
 | --- | --- | --- |
-| `todo` | Todo | 未着手のIssue |
-| `refinement` | 仕様整理中 | 目的・仕様・範囲・依存・受入条件を整理する |
-| `ready` | Ready | 自分たちの作業を依存順に進めれば着手できる。開始時に、必要な前工程の成果を再確認する |
-| `coding` | Coding | 実装担当が実装・自動検証・簡素化・セルフレビューを完了し、差分と結果を渡す |
-| `local_agent_qa` | Local Agent QA | Codexが受入条件を検証する。不合格なら `coding` へ戻す |
-| `code_review` | Code Review・コミット | Local Agent QA合格後、実効 `review_flow.mode: auto` は独立レビュー・検証後にAIが単位ごとにstage・commitする。manualはAIが単位外を安全にstashしてstage・提示し、人がレビュー・修正・commitする。単位照合、人の完了通知（manual）、stash/index復元を確認して次へ進む |
-| `post_commit` | コミット後の検証・PR準備 | 設定に従って、push前の最終Agent QA、必須検証、許可されたpush・PR作成を行う |
-| `staging_agent_qa` | Staging Agent QA | 配備されたPR候補版をCodexが検証する |
-| `staging_human_qa` | Staging Human QA | そのPRで必要な人の確認。不要なら理由を記録して省略する |
-| `release` | マージ・本番配備・公開 | 必要なQA・承認と操作の許可が揃ってから実行する |
-| `production_agent_qa` | Production Agent QA | 公開対象の版・環境差・主要導線をCodexが検証する |
-| `production_human_qa` | Production Human QA | 本番で必要な人の確認。不要なら省略する |
-| `done` | Done | そのIssueの必須受入条件を満たした状態 |
+| 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。通常設定がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
+| 実装 | `coding`, `local_agent_qa` | Claudeのメインが初期体制を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。CodexがLocal Agent QA（判定記録と経路の整合を含む）を行い、不合格なら同じsessionへ戻す |
+| 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualは退避・stage・提示、相談・修正、人の明示承認の後にcommitする。Codexは各コミットの単位照合と全体照合を行う。差分確定中の修正は単位の目的・範囲内に限り、超えるものは実装へ戻す。差分確定で差分が変わったIssueは、確定後にCodexのAgent QAを必須にする（公開確認のpush前の最終Agent QAで兼ねてよい） |
+| 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QA、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |
+| 結果報告 | （状態キーなし） | 結果・証拠・省略した工程と理由・残項目をIssueへ記録し、終了地点に到達する。必須受入条件をすべて満たしたIssueは `done` にする |
 
+- `todo`（未着手）・`refinement`（`linear-plan` による仕様整理）・`human_input`（外部対応の待ち）は5工程の外の状態を表す。
 - 工程名を使うことは、チーム設定を変更する許可ではない。専用のステータスがないQA工程は進行中の状態に対応づけ、工程・待ち理由・再開条件をコメントへ記録する。`done` と途中の工程を同じ完了状態に対応づけない。
 - QAステータスへの移動とQAの合格を区別する。終了地点への到達とIssueのDoneを区別する。
-- Codexの専用実装タスクの整理は、終了条件への到達と成果記録を確認した後、会話側が [完了後の整理](codex-task.md#完了後の整理) に従って行う。タスクのアーカイブを工程・Issue・ゴールの完了確認の代わりにしない。
-- 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業のレビュー・コミット・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
+- 工程を行うかどうかは、Issueの受入条件と終了地点で決める。Issueに適用されない工程は通らない（配備しない変更の環境配備・環境QA、Git変更がない作業の差分確定・PRなど）。省略した工程は理由を記録する。工程の省略を理由に、必要なQAや未達の受入条件を省かない。
 - 終了地点の工程がそのIssueにない場合は、適用される最後の必要工程まで進めて止まる。そのとき必須受入条件をすべて満たしていればDoneにする。満たしていなければ、残る条件を記録してDoneにしない（push前QAで止める運用で、本番公開の受入条件が残るIssueなど）。
-- 人がレビュー中に修正した場合は `code_review` を続ける。AIへ追加実装を依頼する場合は、範囲と受入条件をIssueで更新してから `coding` へ戻す。
 - Human QAが新たに必要になった場合は、理由と具体的な残項目をIssueに記録して利用者に相談する。
 - プロジェクトの規約や補足の記述だけでは、AIコミットの許可として扱わない。[共通設定のパス別の方針](configuration.md#パス別の方針)に従って、通常設定・適用ルール・今回の明示指示から実効方針を決める。
-- 実効方針が `review_flow.mode: auto` なら、Codexは `code_review` で対象単位を明示し、省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。
+- 実効方針が `review_flow.mode: auto` の単位は、Codexが差分確定で対象単位を明示し、人のレビューの省略と実施した確認への参照をIssueへ記録する。人のレビュー済みとは記録しない。
 
   ```text
   人のコードレビュー: <対象単位>は省略（根拠: <通常設定または適用したパス別ルール>、判定: <Local Agent QAの記録へのリンク>）
-  実施した確認: devの入口内のレビュー（使った場合。実装担当の完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
+  実施した確認: devの入口内のレビュー（Claudeの完了報告 <コメントへのリンク>）、Local Agent QA（<記録へのリンク>）
   コミット: <SHAの一覧>（<実際の実施者と方法>）
   ```
 
-### 単位案からコミット完了まで
+## 失敗・許可・停止の共通ルール
 
-以下はすべての実装方式に共通する（Managedの入口での手順2・3の読み方は、[Managedセッション](managed-session.md)の「Managed固有の読み替えと記録」にある）。単位計画の作成・確認にはコミット許可を要求しない。
+全工程に共通する。
 
-1. 実装担当は成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。進行役のCodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。
-2. QA合格後、Codexは実効flow・単位の判定記録・QA結果を実装担当へ渡す。Claudeは両modeとも同じCLI sessionをresumeする。manualは準備したprocessの終了後に進行役が指定toolで提示する。担当は設定・予定差分・合意根拠を照合する。manualの依頼は人への提示準備でありAIコミットの依頼ではない。
-3. 担当は `commit` に従い、autoでは独立レビュー後にAIがstage・commitし、manualでは単位外を安全にstashしてstage・提示、人がレビュー・修正・commitする。各コミット直前・作成後の実差分と確定した予定単位を照合し、予定単位・SHA・検証・レビュー・復元結果を進行役へ返す。
-4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が、`commit` の手順で正当な人の修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
-5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。人の完了通知後は `commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
+- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
+- **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
+- **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
+- 経過時間、無回答、Bridgeの送信成功・ack・peer通知を、承認・完了・合格として扱わない。
+- 人がClaudeへ直接伝えた指示・承認はClaudeが報告に含め、CodexはGitの状態と照合し、合意済みの設定・会話の許可範囲内で次へ進む。報告は新しい許可を作らない（[Bridge](bridge.md)）。既存の許可内の後続処理は人へ聞き直さない。
 
-## 待ち状態
+### 再確認せず進める条件
 
-その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、実装担当の作業待ちはAI間の待機として扱う。
+| 状況 | 必要な行動 |
+| --- | --- |
+| Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
+| devの入口の中で計画上の判断が必要になった | autoはClaudeがresultでCodexへ相談し、Codexは既存の合意で判断できれば回答する。manualはClaudeが人へ直接確認し、決定を報告する |
+| QAで受入条件の範囲内の不具合が見つかった | Codexが同じClaude sessionへ修正を依頼し、Claudeは人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| ClaudeがCLIのresultでcommitの完了を、またはBridgeで人の承認とcommitの完了を報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
+| 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
+| Cycle全体を任され、対象Issueが設定された終了地点に達した | Codexは開始時に確定した対象と順序を照合し、その範囲の次のIssueへ進む |
 
-待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
+「自律的に進める」とだけ書かず、この表と具体的な許可範囲を各CLI・Bridge依頼に書く。
 
-Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
+## 単位案からコミット完了まで
 
-## Bridgeでの任意の引き渡し・報告
+単位計画の作成・確認にはコミット許可を要求しない。
 
-Claudeの実装依頼は両modeともCLIを使い、Bridgeを必須にしない。既存の `bridge_request` または今回の明示許可で別会話から進行の引き渡し・人の完了報告を受ける場合だけ、この節を使う。報告は照合材料であり、CLIの実装経路やレビューUI、操作許可を変更しない。
+1. Claudeは成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。CodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。判定記録に経路と異なるmanual単位があれば、差分確定の依頼前に[経路](configuration.md#経路)に従って人へ確認する。
+2. QA合格後、Codexは実効flow・単位の判定記録・QA結果を同じClaude sessionへ渡す。Claudeは設定・予定差分・合意根拠を照合する。
+3. Claudeは `commit` に従う。autoでは独立レビュー後にClaudeがstage・commitする。manualでは単位外を安全に退避して単位をstage・提示し、人と修正を相談し、人がその単位を承認した後にClaudeがcommitする。各コミット直前・作成後の実差分と確定した予定単位を照合し、予定単位・SHA・検証・レビュー・承認記録・復元結果をCodexへ返す。
+4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が、`commit` の手順で正当な人の修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
+5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。承認後のcommit（または人自身のcommit）の後は、`commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
-### 開発進行の引き渡し
+## 待ち状態
 
-利用可能なBridgeツールでプロジェクト名・絶対パス・正確なsession IDを確認し、Issue・受入条件・現在の状態・正本と補足・許可範囲・返信先を渡す。宛先を推測しない。受信は全文を読み、ackは受領だけを表す。結果不明の依頼を重複送信せず、重要な判断と結果はIssueへ残す。Bridgeがなければ進行役のCodex側へ開始を案内する。
+その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、Claudeの作業待ちはAI間の待機として扱う。
 
-### 人のレビュー・コミット完了の報告
+待つときは、必要な対応・担当・再開条件・戻る工程をIssueのコメントへ記録する。人の回答や対応完了を確認したら続け、同じ依頼を繰り返さない。
 
-Claudeは、対象Issue、Gitの作業ディレクトリとブランチ、コミットSHA、人から受けたレビュー・コミット完了通知、残作業を報告する。Gitにコミットがあるだけで、人のレビュー済みと推測しない。manualでは人がcommitする。
+Linearの工程のステータスと、Codexのゴールの状態は別に扱う。会話側のゴールの維持・終了・状態変更は [execution.md](execution.md) の「継続と待機」「ゴール機能」に従う。通知を受けたら対象と結果を照合し、次工程の許可と前提が揃っていれば再確認せずに続ける。
 
-Codexは、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。これは人のレビューをAIのレビューで代わりにする扱いではなく、人の完了通知を別のセッション経由で受け取る扱いである。
+## Bridge
 
-Bridgeの報告は、新しい公開や破壊的な操作の許可を作らない。対象や通知の内容が足りない場合は、まずClaudeへ補足を求める。利用者の判断が必要な矛盾だけ、Codexから人へ確認する。
+manual経路の依頼・報告と、別会話との任意の進行の引き渡しは [Bridge](bridge.md) に従う。
 
 ## 人への依頼
 
-manualでは合意済みflowを根拠に、`commit` のstash安全手順で単位外を退避し、対象だけstageして提示する。`git diff --cached` と `git status --short` で漏れと混入を確認する。stage後は人のレビュー・修正・commitを待つ。
-
-人レビューの差分提示は[共通手順](../human-review.md)に従う。
+manualの単位の提示・相談・承認は、WebStorm内の対話Claude Codeセッションで[manualの差分提示と単位承認](../human-review.md)に従って行う。
 
 会話でIssueリンクと必要な作業を明示し、ステータスの変更だけで依頼を済ませない。
 
 | 依頼 | 文例 |
 | --- | --- |
-| Code Review | できるようになったことと重点確認点を添えて「[Issueリンク]の<依頼する作業>をお願いします。」依頼する作業は、manualのコードレビュー・必要な修正・コミットにする |
+| manualの単位レビュー | できるようになったことと重点確認点を添えて「[Issueリンク]の単位レビュー・承認を、WebStormのClaude Codeセッションでお願いします。」 |
 | Human QA | 「[Issueリンク]のHuman QAをお願いします。」 |
 | 外部対応 | 「[Issueリンク]の〇〇をお願いします。」 |