@shinaps/skills 0.47.0 → 0.49.0

package/plugins/shinaps-codex/managed-agents/skills/dev-managed-cc/references/workflow.md

@@ -13,7 +13,7 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 | Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
 
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead は対象を変えない。
+- 計画の確認と実装後の確認に、[レビューの共通契約](review.md)の「対象の固定」「独立性」「完了の判定」を適用する。計画の確認では対象の版を計画の内容のハッシュとし、差分・機械検査・変更範囲の文は適用しない。Phase 4 の入力として定めた両案は他担当の結果に当たらない。独立案（Phase 3）はPhase 3の節に従う。
 - 各担当の報告は全文を作業記録の `raw/` に保存し、対象版・役割・担当番号・確認範囲・完了状態を対応づける。Phase 4 の採否は `plan.md`、Phase 6 の採否は `fix-log.md` の「指摘の採否」の節に書く。
 - lead は、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の委任・待機、結果と未解決事項の取りまとめ、利用者判断の取り次ぎ、作業先・書き込み制限の比較・git・draft PR を行う。体制が求める独立確認を lead の自己確認で代えない。継続のターンで来る質問・修正も同じように扱う。
 - **修正サイクル**: 継続のターンで実装の修正が必要になったら、契機によらず、未対応の指摘の集合を一つの入力にして次の順に進める。
@@ -22,7 +22,6 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
   3. lead が修正する（Phase 5）。
   4. Phase 6 の担当（受け取った体制のとおり）が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
   5. Phase 7 で統合・修正する。
-- 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
 ## Phase 1: タスクと体制
 
@@ -58,24 +57,11 @@ lead が確定計画を実装する。
 
 ## Phase 6: 実装後の確認
 
-同じ差分を固定し、受け取った体制の担当と追加した担当を `shinaps-reviewer` へ並行して委任する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。staged・unstaged・untracked を含めて対象を特定する。
-
-- LITE・BASIC: 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない。
-- ULTRA: A として新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B として技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する。
-- 規約照合には、規約（`AGENTS.md`・`CLAUDE.md` とその参照先）の全文と、比較元からの差分コマンド（`git diff <比較元> -- <path>`）を変更範囲の確認コマンドとして渡す。未追跡の新規ファイルは全行を今回の変更として扱う。
-- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。
+[レビューの共通契約](review.md)に従い、同じ差分を固定して、受け取った体制の担当と追加した担当を並行して委任する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは比較元からの差分（`git diff <比較元> -- <path>`）を渡す。規約は [SKILL.md の規約](../SKILL.md#規約) の範囲で、機械検査は実行しない。
 
 ## 指摘の検証と統合（Phase 4・6）
 
-lead が全レポートを使って全指摘の根拠・誤認・重複・対立・未確認を区別し、出典IDを保持して全項目の採否と理由、必要な修正と検証をまとめる。統合は多数決ではなく根拠で行い、自分の成果物への指摘の確認を独立検証とは報告しない。
-
-- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
-  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
-  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
-  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、`状態: 質問` で利用者に確認し、利用者の判断を記録した時点で解決とする。
-- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。
-- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
-- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件の変更や許可範囲の拡大は、利用者の合意前に採用しない。
+[レビューの共通契約](review.md)の「指摘の検証と統合」に従う。利用者への確認は `状態: 質問` で行う。
 
 ## Phase 7〜8: 修正と終了判定
 

package/plugins/shinaps-codex/references/dev/launch.md

@@ -1,7 +1,8 @@
 # 担当の起動（Codex）
 
-review・debug・spec・refine・explore のCodexスキルが、名前を挙げる登録済みの担当を Codex のサブエージェントで起動・継続する手順。
+review・debug・spec・explore のCodexスキルが、名前を挙げる登録済みの担当を Codex のサブエージェントで起動・継続する手順。
 
+- 委託できるかは[依頼範囲と操作](../request-scope.md)で判断し、操作ごとの許可は求めない。利用者または作業先の制約が委託を禁止した場合と、Codexの実行環境がサブエージェントの起動に利用者の明示依頼を求めていてその依頼がない場合は委託しない（実行環境が強制する条件）。
 - 担当は `spawn_agent` で起動し、毎回 `agent_type`（役割定義名。例 `shinaps-reviewer`）と `fork_turns: "none"` を明示する。`fork_turns` を省略すると親の履歴を引き継ぎ、独立した担当にならない。役割定義には model を書かないので、`model`・`reasoning_effort` はスキルが指定する場合だけ明示し、指定がなければ親セッションから継承する。親セッションの設定は変更しない。
 - 同じ役割の複数担当 は、同じ `agent_type` で別々に起動する。担当番号は起動前に固定し、返された ID と対応づけて保持する。
 - `task_name` は実行の中で重複しない名前にし、継続では変えない。使う文字は英小文字・数字・`_` だけにする。

package/plugins/shinaps-codex/references/dev/staffing.md

@@ -6,17 +6,17 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 
 ## 体制の種類
 
-3体制の違いは、独立確認を置く対象・人数・深さだけである。許可・QA・必須検証・終了地点は体制によって変わらない。括弧内の「各N」は、各観点を独立に見る担当の数を表す。
+3体制の違いは、独立確認を置く対象・人数・深さだけである。依頼範囲・制約・QA・必須検証・終了地点は体制によって変わらない。括弧内の「各N」は、各観点を独立に見る担当の数を表す。
 
 | 工程 | LITE | BASIC | ULTRA |
 | --- | --- | --- | --- |
 | 調査・設計・計画 | メイン（短い計画と検証方針） | メイン | メインが自案を保存した後、独立設計担当1名が別案を作り、メインが比較して統合する |
 | 計画の独立確認 | 置かない（実装後の独立レビューが計画も確かめる） | 計画レビュー担当1名（計画レビュー・計画の簡素化。各1） | 計画レビュー担当2名（計画レビュー・計画の簡素化・独立案の論点を根拠なく退けていないか。各2） |
 | 実装・検証・自己簡素化・修正 | メイン | メイン | メイン |
-| 実装後の独立レビュー | 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・可読性・慣習・実装の簡素化。各1） | LITEと同じ | A: 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・実装の簡素化）。B: 技術領域ごとに1名（規約照合（全手順）・可読性・慣習）。各1（A も rule 観点で規約に照らす） |
+| 実装後の独立レビュー | [レビューの共通契約](../review.md)の LITE（1名） | 同じ契約の BASIC（1名） | 同じ契約の ULTRA（全体1名・技術領域ごとに1名） |
 | 指摘の検証・採否・修正計画・人の指摘の調査 | メイン | メイン | メイン |
 
-各役割の定義・継続・新規にする単位と、体制ごとに依頼するレビューの種類は[工程](workflow.md)の「役割と継続」とPhase 6に従う。探索は必須にしない。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
+各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に、体制ごとに依頼するレビューの種類と技術領域の定義は[レビューの共通契約](../review.md)に従う。探索は必須にしない。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
 
 ## 体制の選択
 
@@ -29,7 +29,7 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 確認の規則は次のとおり。
 
 - 確認するのは人への確認の窓口とする。Linear進行では[停止と人への確認](../linear/workflow.md)の経路の規則に従い、単独のdevではメインが行う。
-- 各Issueの着手時と、人の指摘の一括修正を始めるたびに確認する。次の場合は聞き直さない: 依頼に体制が書かれている、利用者が範囲全体に体制を指定している、同じ修正単位を再開する、QAの差し戻しやコミット中の指摘で修正する、個々の指摘。
+- 各Issueの着手時と、人の指摘の一括修正を始めるたびに確認する。単独の `review` の体制はこの確認とは別に、その入口で選ぶ。次の場合は聞き直さない: 依頼に体制が書かれている、`review` で選んだ体制を修正へ引き継ぐ、利用者が範囲全体に体制を指定している、同じ修正単位を再開する、QAの差し戻しやコミット中の指摘で修正する、個々の指摘。
 - 人の修正開始以外で始まる修正サイクルは、その作業で直近に選んだ体制を使う。
 - 体制を変えたときは、新しく必要になった担当を新規に起動し、既存の成果と確定済みの判断・採否を引き継ぐ。レビューの回数はリセットしない。
 
@@ -45,10 +45,6 @@ BASIC・ULTRAでは、メインは選んだ体制の必須担当に加えて、
 
 LITEでは、探索を含む担当を追加しない。独立コードレビューの担当1名で足りないと分かったら、理由を添えて、人への確認の窓口からBASIC・ULTRAへの変更を相談する（変更の扱いは「体制の選択」のとおり）。
 
-## 技術領域
-
-技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにする。
-
 ## 記録と引き渡し
 
 設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立した担当は、実装したメインとは別のコンテキストにする。
@@ -61,12 +57,12 @@ BASIC・ULTRAでは、選んだ体制は上限ではない。LITEでは増やさ
 
 - 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。既存担当の仕事を理由なく最初から繰り返さない。
 - 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
-- 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
+- 体制判断は依頼範囲・制約・モデル・予算を変えない。依頼範囲と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・制約・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
 
 ## 維持する条件
 
 選んだ体制の必須担当を、メインの自己確認や体制の表に無い兼務で完了扱いにせず、委託不可・起動不能なら未完了とする。明示された人数制限・予算が下限を満たさない場合は、人へ一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ未完了とする。
 
-委託できない場合、Linear進行（[`dev_delegation`](../linear/configuration.md) が無い）ではdevを始めず、必要な許可を求めて返す。単独のdevで利用者が委託を禁止した場合は、必須担当を合意による未実施として続けるかを一問で確認する。
+委託はdevの既定の経路で、操作ごとの許可を求めない（[依頼範囲と操作](../request-scope.md)）。利用者または作業先の制約が委託を禁止した場合と、実行環境が委託を拒否した場合は、必須担当を合意による未実施として続けるかを一問で確認する（Linear進行では進行役へ返す）。
 
 要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、適用規約の照合、全指摘の採否と根拠の記録を維持する。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。

package/plugins/shinaps-codex/references/dev/workflow.md

@@ -4,9 +4,9 @@ Claude Codeのdev（`dev-claude`）の工程。メインが調査・設計・実
 
 ## 1. 前提と作業記録
 
-適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
+適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・制約を引き継ぐ（[依頼範囲と操作](../request-scope.md)）。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者が委託を明示的に禁止した場合と、Linear進行で[`dev_delegation`](../linear/configuration.md)がない場合だけで、その扱いは[体制](staffing.md)の「維持する条件」に従う。worktreeは許可された場合だけ使う。サービス規約を取得できない工程は未照合と明示する。
+devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者または作業先の制約が委託を禁止した場合と、実行環境が委託を拒否した場合だけで、その扱いは[体制](staffing.md)の「維持する条件」に従う。worktreeは依頼範囲の中で隔離が必要な場合に使う。サービス規約を取得できない工程は未照合と明示する。
 
 作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。短い作業は短い計画・記録にする。
 
@@ -23,9 +23,9 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 
 - 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合（resumeをまたぐ場合を含む）は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインは対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
-- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
+- 計画の確認と実装後の確認に、[レビューの共通契約](../review.md)の「対象の固定」「独立性」「完了の判定」を適用する。計画の確認では対象の版を計画の内容のハッシュとし、差分・機械検査・変更範囲の文は適用しない。Phase 4 の入力として定めた両案は他担当の結果に当たらない。独立案（Phase 3）はPhase 3の節に従う。継続担当には前回の確定済み指摘と採否を渡してよい。
+- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。
+- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。ただし、利用者が `review` を明示して起動したレビューはdevの工程とは別の作業とし、devの体制とレビューの回数を引き継がない。その結果の修正を依頼された場合は人の修正開始として修正サイクルに入る。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
 - **修正サイクル**: devの完了後に実装の修正が必要になったら（人の修正開始（[人のレビュー](../human-review.md)）、Codex QAの差し戻し、コミット中の指摘など、契機によらず）、未対応の指摘の集合を一つの入力にして次の順に進める。人の修正開始では、体制を[体制の選択](staffing.md)に従って確認する。入力が一致する結果は[テスト方針](../testing.md)に従って引き継ぐ。一部をコミットした後の修正は `commit` の規定どおり後続単位にする。
   1. メインが修正計画と、影響を受ける工程を決める。
   2. 設計・契約・検証条件を変える場合だけ、Phase 4の扱いで再確認する。
@@ -84,35 +84,15 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 8. Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ体制の担当と追加した担当を `shinaps-reviewer` で並行して起動する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。
+[レビューの共通契約](../review.md)に従い、同じ差分を固定して、選んだ体制の担当と追加した担当を並行して起動する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは `git diff HEAD -- <path>` を渡す。
 
-| 体制 | 担当と依頼するレビューの種類 |
-| --- | --- |
-| LITE・BASIC | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない |
-| ULTRA | A: 新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する |
+変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。取得した規約に `checks` があれば、担当へ渡す前に[規約の機械検査](../lint.md)の「照合で使う」を行う。
 
-- 独立コードレビューには、対象コード・全差分・利用側・規約・計画・検証結果を渡し、計画自体も誤りうるものとして確かめさせる。
-- 規約照合には、規約全文・対象ファイル全文と、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡のファイルは全行を今回の変更とする）を渡す。
-- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
-- 技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
-
-変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。
-
-結果を `review-{round}-{n}.md` に保存する。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で担当の完了を判定する。未照合の規約は、特定できる単位（例: id・topic）でPhase 9に報告する。
+結果を `review-{round}-{n}.md` に保存する。未照合の規約はPhase 9に報告する。
 
 ## 9. 指摘の検証と統合（Phase 4・6共通）
 
-メインが全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、全指摘を整理する。各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確かめ、根拠・誤認・重複・対立・未確認を区別する。同じ原因・影響・修正方針の指摘だけまとめ、元の項目と重要度を消さない。指摘なしの担当は完了と確認範囲を確かめる。
-
-全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。Phase 4は `plan.md`、Phase 6は `fix-log.md` の「指摘の採否」の節に書く（`fix-log.md` ではQAの変更記録と節を分ける）。統合は多数決ではなく根拠で行う。メイン自身の確認を独立検証とは報告しない。
-
-- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
-  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
-  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
-  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、人への確認（Phase 5 の「該当作業を止めて人に確認する」）に回し、人の判断を記録した時点で解決とする。
-- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。複雑な対立は[体制](staffing.md)の「途中の増員」で担当を追加できる（LITEでは体制の変更を相談する）。
-- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
-- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は、人の合意前に採用しない。
+[レビューの共通契約](../review.md)の「指摘の検証と統合」に従う。全項目の採否と理由、必要な計画修正・実装修正・検証は、Phase 4は `plan.md`、Phase 6は `fix-log.md` の「指摘の採否」の節に書く（`fix-log.md` ではQAの変更記録と節を分ける）。仕様を変えなければ解消できない欠陥は、Phase 5 の「該当作業を止めて人に確認する」に回す。複雑な対立は[体制](staffing.md)の「途中の増員」で担当を追加できる（LITEでは体制の変更を相談する）。
 
 ## 10. Phase 7〜8: 修正と終了判定
 
@@ -124,10 +104,10 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 11. Phase 9: 完了と引き渡し
 
-選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。規約照合の種類を依頼しない体制（BASIC・LITE）では、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。修正サイクルの後は、初回の報告項目を最新にし、対応した指摘と採否・再実施した工程・[変更記録](../linear/qa.md#qaの時点対象最終qa)を加える。
+選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。機械検査の組の状態ごとの数と実行できなかった理由、規約照合の種類を依頼しない体制（BASIC・LITE）では規約を独立コードレビューの中で照らしファイルごとの完了一覧が無いことも書く。修正サイクルの後は、初回の報告項目を最新にし、対応した指摘と採否・再実施した工程・[変更記録](../linear/qa.md#qaの時点対象最終qa)を加える。
 
 linear-executeから受けた作業は未コミットの差分と結果を進行役へ返す。devの完了はLocal Agent QAへの引き渡しであり、進行全体の終了ではない。[Linear共通設定](../linear/configuration.md)と[担当と工程](../linear/workflow.md)に従い、autoはQA後の差分確定の依頼を受けて、manualは人のコミット開始依頼で `commit` を始め、単位の退避・stage・commitはQA結果の引き渡し後に行う。auto経路は [Claude CLI](../linear/claude-cli.md) のresultへ報告し、同じsessionのresumeで質問・修正を受ける。manual経路は同じ対話セッションで人と作業し、[Bridge](../linear/bridge.md)で依頼元Codexへ報告する。manualの完了時は、修正サイクルの後も含めて、人へユーザーのレビュー待ちと明示する（[manualの手順](../human-review.md)）。
 
-単独のdevではコミットが許可されている場合だけ範囲とモードを `commit` へ渡す。許可がなければ未コミットで返し、形式的な許可確認を追加しない。PR・リリースも許可された範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
+単独のdevではコミットが依頼の到達点に含まれる場合だけ範囲とモードを `commit` へ渡す。含まれなければ未コミットで返し、形式的な確認を追加しない。PR・リリースも依頼の到達点に含まれる範囲で各スキルへ渡す。単独devにLinear進行・新しいゴールを必須にしない。
 
-explore・spec・review・debugからの成果物は入口の引数で直接渡す。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。
+explore・spec・review・debugからの成果物は入口の引数で直接渡す。reviewから渡された指摘は修正サイクルの入力とし、体制が渡された場合はその体制で進める。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。

package/plugins/shinaps-codex/references/human-review.md

@@ -1,6 +1,6 @@
 # manualのレビュー待ちと単位ごとのコミット
 
-実効 `review_flow.mode: manual` の差分を、人がWebStormの差分表示でレビューし、人の依頼に従ってWebStorm内の対話Claude Codeセッションで単位ごとにClaudeがcommitする手順。review_flow・操作許可は、プロジェクト設定と今回の依頼に従う。この手順はそれらを変更しない。
+実効 `review_flow.mode: manual` の差分を、人がWebStormの差分表示でレビューし、人の依頼に従ってWebStorm内の対話Claude Codeセッションで単位ごとにClaudeがcommitする手順。review_flow・依頼範囲・制約は、プロジェクト設定と今回の依頼に従う（[依頼範囲と操作](request-scope.md)）。この手順はそれらを変更しない。
 
 会話では単位名・目的・対象ファイル・検証結果・短い推奨コミットメッセージなど判断に必要な最小限を示し、差分本文を貼らない。Claude自身の差分の読取りと独立レビューは制限しない。
 
@@ -12,7 +12,7 @@ devと必要な検証が終わったら、作業内容と検証結果を短く
 
 ## コミットの開始と分割案
 
-人がコミットの開始を依頼したら（「コミットしましょう」など。固定の文言は求めない）、`commit` に従って自然な責務単位の分割案を示す。各単位の名前・目的・対象ファイル・順序・推奨コミットメッセージを短く示す。許可された独立レビュアーによる分割案の確認は `commit` に従う。
+人がコミットの開始を依頼したら（「コミットしましょう」など。固定の文言は求めない）、`commit` に従って自然な責務単位の分割案を示す。各単位の名前・目的・対象ファイル・順序・推奨コミットメッセージを短く示す。独立レビュアーによる分割案の確認は `commit` に従う。
 
 分割案への合意は単位の構成への合意であり、どの単位のcommitの承認でもない。
 
@@ -46,4 +46,4 @@ devを経ないcommitでは、相談で行った修正は単位と依頼の目
 
 ## 報告
 
-コミットの開始依頼と単位ごとの依頼発話の要約・記録したtree hash・SHA・相談で行った修正や修正サイクルで確定した変更とその対応・変更記録（[QAと証拠](linear/qa.md#qaの時点対象最終qa)）・未対応・見送りの指摘・復元結果を記録し、Codexへ報告する。Codexは実コミットと照合する。stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。WebStormで差分を表示することはstage・commit・pushの許可を追加しない。
+コミットの開始依頼と単位ごとの依頼発話の要約・記録したtree hash・SHA・相談で行った修正や修正サイクルで確定した変更とその対応・変更記録（[QAと証拠](linear/qa.md#qaの時点対象最終qa)）・未対応・見送りの指摘・復元結果を記録し、Codexへ報告する。Codexは実コミットと照合する。stashの復元では人の修正を保持し、古い対象パッチで上書きしない。具体的な単位照合・復元は `commit` に従う。WebStormで差分を表示することは、stage・commit・pushの依頼に当たらない。

package/plugins/shinaps-codex/references/linear/bridge.md

@@ -1,6 +1,6 @@
 # Bridge
 
-通常設定が `review_flow.mode: manual` のIssueと、`ask` で着手時にmanualを選んだIssue（[経路](configuration.md#経路)）で、CodexがWebStorm内の対話Claude CodeセッションへAI Terminal Bridge（以下Bridge）で依頼し、報告を受ける手順。`bridge_request` があれば、別会話との任意の進行の引き渡しにも使う。
+通常設定が `review_flow.mode: manual` のIssueと、`ask` で着手時にmanualを選んだIssue（[経路](configuration.md#経路)）で、CodexがWebStorm内の対話Claude CodeセッションへAI Terminal Bridge（以下Bridge）で依頼し、報告を受ける手順。Bridgeを使える場合は、別会話との任意の進行の引き渡しにも使う。
 
 各項目の根拠を括弧で示す。「履歴」はこのリポジトリのコミット 6ebbfbf・c766eb6 時点の `plugins/shinaps-claude/skills/linear/references/workflow.md` の「Bridgeでの依頼と報告」に記録された運用、「現物確認」は2026-10-19に進行役がBridge MCPのツール一覧で確認した内容を指す。どちらにもない挙動は、使う時点で現物のツール一覧と挙動で確認し、確認できなければ止める。
 
@@ -31,14 +31,14 @@
 - manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない（Claudeが依頼した途中確認への応答を除く）。
 - Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
 - 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
-- Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
+- Bridgeの依頼・報告は、利用者の明示的な停止や依頼範囲・制約を上書きせず、依頼範囲を公開や破壊的な操作へ広げない（履歴）。
 - Bridgeが必要な工程で使えない場合は、未実施の引き渡しを完了扱いにせず、経路を切り替えず、状態と必要な準備を利用者へ伝える（履歴）。
 
 ## 依頼と報告
 
 | 依頼・報告 | 含めるもの |
 | --- | --- |
-| 実装の依頼（CodexからClaude） | Issueリンク、`shinaps:dev-claude`、範囲・受入条件、体制と体制判断の材料、Gitの作業ディレクトリ・branch・HEAD・既存差分、許可範囲（`dev_delegation` の有無を含む）、通常設定が `ask` の場合は解決したmodeと回答の記録、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文 |
+| 実装の依頼（CodexからClaude） | Issueリンク、`shinaps:dev-claude`、範囲・受入条件、体制と体制判断の材料、Gitの作業ディレクトリ・branch・HEAD・既存差分、依頼範囲（目的・対象・実効到達点のうちClaudeが行う部分）と制約（`constraints`・補足・今回の範囲限定）、通常設定が `ask` の場合は解決したmodeと回答の記録、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文 |
 | 修正の依頼（CodexからClaude） | 実装の依頼の項目に加え、再現手順・期待と実際・対象差分・証拠の場所 |
 | QA結果の引き渡し（CodexからClaude。manualの単位のcommitの依頼ではない） | Issueリンク、対象差分・作業ディレクトリ・branch、Local Agent QAの結果、実効flow・単位の判定記録、返信先 |
 | 途中確認の依頼（ClaudeからCodex） | 開発途中に動作を確かめる依頼。Bridgeで送り、応答を同じセッションで受ける。項目は[途中確認](qa.md#qaの時点対象最終qa)に従う |
@@ -49,8 +49,8 @@
 実装・修正の依頼には次の文を含める。
 
 ```text
-ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。依頼の体制で進め、BASIC・ULTRAでは追加の担当をあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ返す。
-許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
+ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。依頼の体制で進め、BASIC・ULTRAでは追加の担当をあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。依頼範囲を広げる決定や制約を変える決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ返す。
+依頼範囲と制約: <目的・対象・実効到達点のうちClaudeが行う部分、constraints・補足・今回の範囲限定>
 ```
 
-Codexは人の依頼とcommitの報告を受けたら、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、許可済みの工程へ進む場合は、人へ再確認しない。Gitにコミットがあるだけで人の依頼によるcommitと推測しない。報告が足りない場合は、まずClaudeへ補足を求める。
+Codexは人の依頼とcommitの報告を受けたら、対象Issue・差分・コミットと、対象作業の未コミット変更の有無を照合する。報告と実体が一致し、依頼範囲の内側の工程へ進む場合は、人へ再確認しない。Gitにコミットがあるだけで人の依頼によるcommitと推測しない。報告が足りない場合は、まずClaudeへ補足を求める。

package/plugins/shinaps-codex/references/linear/claude-cli.md

@@ -1,12 +1,14 @@
 # ローカルClaude CLIによる実装
 
-通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、`claude_cli` と `claude_cli_bypass_permissions` の許可（または今回の明示依頼）、必須検証とそのツールチェーンの状態、依頼で許可・禁止する操作を確定する。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
+通常設定が `review_flow.mode: auto` のIssueと、`ask` で着手時にautoを選んだIssue（[経路](configuration.md#経路)）で、Codexが作業先でローカル `claude -p` を起動する。初回実装前に、正確なcheckout・branch・HEAD・既存差分、必須検証とそのツールチェーンの状態、依頼範囲（目的・対象・実効到達点のうちClaudeが行う部分）と制約を確定する。auto経路の起動と同じsessionの再開は、依頼範囲の通常操作として行う（[依頼範囲と操作](../request-scope.md)）。必須検証は対象リポジトリの規約・CI・スクリプトから読み、ツールチェーンは実際のコマンド（例: `node --version`、依存の導入状態の確認）の結果で確かめる。確かめるのは依頼で実際に使うコマンドに限る。
+
+Linear進行ではない単独の `review` から修正まで依頼されたときも、Codexはこの文書の起動・resume・操作権限の手順でClaudeへ渡す（promptの内容と到達点は `review` のスキルに従う）。
 
 パス例外はコミット単位のreview_flowを全体置換し、実装sessionを途中で切り替えない。manual単位が生じた場合は[経路](configuration.md#経路)に従う。
 
 ## 起動と観測
 
-通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。権限モードも同じ理由で、起動とすべてのresumeで `--permission-mode bypassPermissions` を指定する（下の「操作権限」）。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。権限モードも同じ理由で、起動とすべてのresumeで `--permission-mode bypassPermissions` を指定する（下の「操作権限」）。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作が依頼範囲に含まれることは別である。
 
 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。
 
@@ -20,7 +22,7 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
 
 ## 依頼・質問・修正・コミット
 
-promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、依頼範囲と制約（`constraints`・補足・今回の範囲限定）、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。依頼の体制で進め、BASIC・ULTRAでは追加の担当をClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・範囲・制約の判断が必要なら人へ一問ずつ取り次ぐ。[途中確認](qa.md#qaの時点対象最終qa)の依頼は、実行中の担当が無い時点でresultに返す。この依頼は完了報告ではなく、CodexはLocal Agent QAへ進めない。CLIからBridge送信や人の対話入力を待たせない。
 
 回答・QA修正・QA後のautoコミット依頼は、元のprocess終了後、記録済みの正確なIDで同じセッションをresumeする。`--continue` で別セッションを推測しない。
 
@@ -28,16 +30,14 @@ promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と
 claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode bypassPermissions --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
 ```
 
-resumeにも同じcwdと許可境界を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠（askでは解決したmodeと回答の記録）を含める。完了報告は体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、変更範囲、検証、未解決事項、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、commitした場合はSHA・単位照合・残差分・stash復元結果・修正サイクルで確定した変更を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
+resumeにも同じcwdと依頼範囲・制約を指定し、外部で変化したHEAD・差分を渡す。commit依頼にはLocal Agent QA結果、独立レビュー、単位案と全差分、実効review_flowと合意根拠（askでは解決したmodeと回答の記録）を含める。完了報告は体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、変更範囲、検証、未解決事項、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、commitした場合はSHA・単位照合・残差分・stash復元結果・修正サイクルで確定した変更を含める。復帰不能時は理由を報告し、黙って別sessionに作り直さない。
 
 ## 操作権限
 
-`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動と同じsessionのresumeでは `--permission-mode bypassPermissions` を明示する。依頼で必要になる操作を個別のallowで事前に列挙しきれず、非対話では足りない許可を求められないまま作業が止まるためである。`--allowedTools` で個別の許可を足したり、dontAskなど別のモードで起動したりしない。`--permission-prompts none` は、bypassでも残る確認を入力待ちにせず拒否としてresultへ返すために付け、許可を付与しない。
-
-bypassでの起動には、`claude_cli` に加えて利用者が明示的に同意した `claude_cli_bypass_permissions`（または今回の明示依頼）が必要で、`claude_cli` だけをbypassへの同意とみなさない。同意が無ければCodexは起動前に人へ一問で確認し、回答まで起動しない。回答は同じIssueの起動とすべてのresumeに引き継ぐ。同意が得られなければauto経路では起動せず、許可不足のブロッカー（[実行](execution.md)）として報告する。manual経路で進めるかは利用者が決め、その場合は[経路](configuration.md#経路)のとおり設定（通常設定がaskなら同じIssueの選択）を見直してから着手する。
+`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動と同じsessionのresumeでは `--permission-mode bypassPermissions` を明示する。依頼で必要になる操作を個別のallowで事前に列挙しきれず、非対話では足りない許可を求められないまま作業が止まるためである。この指定は経路の手順の一部で、リポジトリごとの同意項目や起動前の確認は設けない。`--allowedTools` で個別の許可を足したり、dontAskなど別のモードで起動したりしない。`--permission-prompts none` は、bypassでも残る確認を入力待ちにせず拒否としてresultへ返すために付け、許可を付与しない。
 
-bypassはCLIの権限チェックを省くだけで、操作の許可ではない。Claudeが行う操作は依頼の範囲と、[共通設定](configuration.md)の `permissions`・合意済みの `review_flow` に限る。stage・commitは、QA後の差分確定の依頼を受けたときだけ `shinaps:commit` に従って行う。push・公開・外部への送信・破壊的操作は、それぞれの許可と工程に従う。CLIで実行できることや会話上の許可を、依頼の範囲外の操作の許可とは扱わない。
+bypassの扱いは[依頼範囲と操作](../request-scope.md#根拠にしないもの)に従う。Claudeが行う操作は依頼範囲・`constraints`・合意済みの `review_flow` に限る。stage・commitは、QA後の差分確定の依頼を受けたときだけ `shinaps:commit` に従って行う。push・公開は依頼で任された場合だけ、工程に従って行う。CLIで実行できることを、依頼範囲の外の操作の根拠とは扱わない。
 
-permission_denialsがあれば操作と理由を報告し、拒否を隠すsilent retryをしない。bypassでも残る拒否（deny設定・保護されたパス・組織の設定など）は、同じ指定で再依頼しても解消しない。依頼の範囲内で別の手段を指示できる場合だけ同じsessionへ再依頼し、それ以外や新しい許可が必要な場合はCodexが人へ確認する。
+permission_denialsがあれば操作と理由を報告し、拒否を隠すsilent retryをしない。bypassでも残る拒否（deny設定・保護されたパス・組織の設定など）は、同じ指定で再依頼しても解消しない。拒否された操作を別の手段で実行して迂回しない。拒否された操作を必要としない進め方が依頼範囲の内側にある場合だけ同じsessionへ再依頼し、それ以外や環境側の設定変更が必要な場合はCodexが人へ確認する。
 
 CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応、またはbypassPermissionsが組織の設定などで無効なら、状態を報告して停止し、別の権限モードへ切り替えて進めない。