@shinaps/skills 0.36.0 → 0.37.0

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

@@ -1,24 +1,22 @@
 # 実装体制の判断
 
-体制はLITE・BASIC・ULTRAの3段階で、初回メッセージで受け取る。lead は体制の種類を確認・選び直しせず、BASIC・ULTRAでは受け取った体制の必須担当を下限に作業に応じて担当を追加でき、LITEは表の2名だけで進める。継続のターンでは初回の体制を引き継ぎ、利用者がメッセージに体制を書けばそれに従う。
+体制はLITE・BASIC・ULTRAの3段階で、初回メッセージで受け取る。lead は体制の種類を確認・選び直しせず、BASIC・ULTRAでは受け取った体制の必須担当を下限に作業に応じて担当を追加でき、LITEは独立コードレビューの担当1名だけで進める。継続のターンでは初回の体制を引き継ぎ、利用者がメッセージに体制を書けばそれに従う。
+
+lead はメインとして、同じ文脈を必要とする作業（調査・設計・計画の統合・実装・検証・修正・指摘の採否・修正計画）を、どの体制でも自分で行う。担当に依頼するのは、別のコンテキストで行うことに意味がある仕事（独立した別案、計画と実装の独立確認）だけとする。同じ対象を読む確認の観点は、少数の担当にまとめて依頼する。
 
 ## 体制の種類
 
-| 役割 | LITE | BASIC | ULTRA |
+3体制の違いは、独立確認を置く対象・人数・深さだけである。許可・必須検証・終了地点は体制によって変わらない。括弧内の「各N」は、各観点を独立に見る担当の数を表す。
+
+| 工程 | LITE | BASIC | ULTRA |
 | --- | --- | --- | --- |
-| 設計 | 置かない（実装担当が短い計画と検証方針を作る） | 1名（設計担当1） | 2名（独立に設計し、担当1が統合） |
-| 計画レビュー | 置かない | 1名 | 2名 |
-| 計画簡素化 | 置かない | 1名 | 2名 |
-| 実装 | 1名 | 1名 | 1名 |
-| 実装後の設計適合性 | 独立レビュー担当（design 観点で計画と実コードを照合する） | 設計担当1 | 設計担当1 |
-| 実装後の独立コードレビュー | 独立したOpusの1名（正しさ・可読性・慣習・規約照合・簡素化を兼ねる） | 独立した1名（可読性・慣習と規約照合も兼ねる） | 1名 |
-| 実装後の refine | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 1名 |
-| 実装後の可読性・慣習 | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 技術領域ごとに1名 |
-| 実装後の簡素化 | （独立レビュー担当が兼ねる） | 独立した1名 | 1名 |
-| 指摘の整理 | 実装担当（設計責任者） | 設計担当1（計画と実装後） | 計画と実装後の各検証ラウンドで、新規の指摘検証担当1名 |
-| 採否 | 実装担当（設計責任者） | 設計担当1 | 設計担当1 |
-
-設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に従う。探索の担当は置けないので、設計担当（LITEでは実装担当）が設計に必要な範囲を調べる。lead は体制を決める材料だけを確認する。
+| 調査・設計・計画 | lead（短い計画と検証方針） | lead | lead が自案を保存した後、独立設計担当1名が別案を作り、lead が比較して統合する |
+| 計画の独立確認 | 置かない（実装後の独立レビューが計画も確かめる） | 計画レビュー担当1名（計画レビュー・計画の簡素化。各1） | 計画レビュー担当2名（計画レビュー・計画の簡素化・独立案の論点を根拠なく退けていないか。各2） |
+| 実装・検証・自己簡素化・修正 | lead | lead | lead |
+| 実装後の独立レビュー | 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・可読性・慣習・実装の簡素化。各1） | LITEと同じ | A: 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・実装の簡素化）。B: 技術領域ごとに1名（規約照合（全手順）・可読性・慣習）。各1（A も rule 観点で規約に照らす） |
+| 指摘の検証・採否・修正計画 | lead | lead | lead |
+
+各役割の定義・継続・新規にする単位と、体制ごとに依頼するレビューの種類は[工程](workflow.md)の「役割と継続」とPhase 6に従う。探索の担当は置けないので、lead と独立設計担当がそれぞれ必要な範囲を調べる。
 
 ## lead の裁量
 
@@ -30,7 +28,7 @@ lead は受け取った体制の必須担当に加えて、役割の追加、技
 
 点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。担当を起動するためだけの調査や計画書は増やさない。追加は必要な役割だけにし、どれか一つを増やすために全役割を増やさない。
 
-LITEでは、探索を含む担当を追加しない。必要な調査・設計・簡素化・テスト・指摘の根拠の確認と修正は実装担当が、独立した確認は独立レビュー担当が担う。2名で足りないと分かったら、理由を添えて `状態: 質問` でBASIC・ULTRAへの変更を利用者に相談する。
+LITEでは、探索を含む担当を追加しない。独立コードレビューの担当1名で足りないと分かったら、理由を添えて `状態: 質問` でBASIC・ULTRAへの変更を利用者に相談する。
 
 ## 技術領域
 
@@ -50,6 +48,6 @@ BASIC・ULTRAでは、受け取った体制は上限ではない。LITEでは増
 
 ## 維持する条件
 
-受け取った体制の必須担当を、自己確認・体制の表に無い兼務・lead の代行で完了扱いにせず、委任できない・起動できないなら未完了とする。予算・明示された人数制限が下限を満たさない場合は、`状態: 質問` で利用者に一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ `状態: 未完了` で返す。独立レビュー担当の確認を、実装担当の自己確認で代えない。
+受け取った体制の必須担当を、lead の自己確認や体制の表に無い兼務で完了扱いにせず、委任できない・起動できないなら未完了とする。予算・明示された人数制限が下限を満たさない場合は、`状態: 質問` で利用者に一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ `状態: 未完了` で返す。
 
 要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、適用規約の照合、全指摘の採否と根拠の記録を維持する。担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。

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

@@ -1,6 +1,6 @@
 # dev の工程（Managed Agents）
 
-Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。役割・人数は初回メッセージの体制（[実装体制の判断](staffing.md)）の担当で進め（BASIC・ULTRAでは必須担当を下限に追加できる）、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
+Claude Code の dev の工程を、Managed Agents のセッション向けに絞ったもの。Claude Code でメインが行う作業は lead が行う。役割・人数は初回メッセージの体制（[実装体制の判断](staffing.md)）の担当で進め（BASIC・ULTRAでは必須担当を下限に追加できる）、担当の委任・継続・作業先・出力は[起動手順](launch.md)に従う。
 
 ## 役割と継続
 
@@ -8,22 +8,19 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 
 | 工程 | 役割定義 | 継続と責任 |
 | --- | --- | --- |
-| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性・指摘統合・修正計画を継続。担当2以降は独立設計と追加確認のみ |
-| Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
-| Phase 4・6 | `shinaps-simplifier` | 計画の簡素化は修正版の再確認も同じ担当。実装の簡素化は計画とは別の担当で、ラウンドと修正サイクルをまたいで継続 |
-| Phase 4・6 | `shinaps-review-verifier` | 指摘検証担当を置く体制で、検証ラウンド（計画確認と実装後レビューの各ラウンドに1回）ごとに新規。今回の指摘を出した担当を流用しない |
-| Phase 3・5・7 | `shinaps-implementer` | 1体。修正も同じ担当。設計担当を置かない体制（LITE）では、設計責任者として計画と指摘の整理・採否も担う |
-| Phase 6 | `shinaps-reviewer` | 独立コードレビューは実装担当とは別で、レビューラウンドごとに新規。独立コードレビューを含む複数の種類を兼ねる場合は、独立コードレビューの規則に従う。可読性・慣習レビューを技術領域ごとに置く場合は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
-| Phase 6 | `shinaps-refine-agent` | refine 担当を置く体制で、ラウンドと修正サイクルをまたいで継続 |
-
-- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパス・引き継ぎ先を依頼に渡す。実装担当にはファイルの所有範囲を明記する。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead と実装担当も対象を変えない。
-- lead は体制と工程の調整、委任・待機・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らない。継続のターンで来る質問・修正も同じ分担で扱う。
+| Phase 3 | `shinaps-architect` | 独立設計担当を置く場合（ULTRAでは必須、BASICでは追加できる）。独立案と、その案への追加の質問への回答だけを担う |
+| Phase 4 | `shinaps-plan-reviewer` | 計画レビューと計画の簡素化をあわせて見る。修正版の再確認も同じ担当 |
+| Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
+
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませない。対象を編集中にレビューせず、全結果が揃うまで lead は対象を変えない。
+- 各担当の報告は全文を作業記録の `raw/` に保存し、対象版・役割・担当番号・確認範囲・完了状態を対応づける。Phase 4 の採否は `plan.md`、Phase 6 の採否は `fix-log.md` の「指摘の採否」の節に書く。
+- lead は、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の委任・待機、結果と未解決事項の取りまとめ、利用者判断の取り次ぎ、作業先・書き込み制限の比較・git・draft PR を行う。体制が求める独立確認を lead の自己確認で代えない。継続のターンで来る質問・修正も同じように扱う。
 - **修正サイクル**: 継続のターンで実装の修正が必要になったら、契機によらず、未対応の指摘の集合を一つの入力にして次の順に進める。
-  1. 設計責任者が修正計画と、影響を受ける工程を決める。
+  1. lead が修正計画と、影響を受ける工程を決める。
   2. 設計・契約・検証条件を変える場合だけ、Phase 4 の扱いで再確認する。
-  3. 同じ実装担当が修正する（Phase 5）。
-  4. Phase 6 の担当（受け取った体制のとおり）と、指摘検証担当を置く体制ではその新規の担当が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
+  3. lead が修正する（Phase 5）。
+  4. Phase 6 の担当（受け取った体制のとおり）が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
   5. Phase 7 で統合・修正する。
 - 起動失敗・空回答・未確認範囲を「指摘なし」にしない。
 
@@ -33,39 +30,56 @@ Claude Code の dev の工程を、Managed Agents のセッション向けに絞
 
 ## Phase 2: 規約と必要な探索
 
-規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。探索は各設計担当が自分の設計に必要な範囲で行う。
+規約の範囲は [SKILL.md の規約](../SKILL.md#規約)に従う。lead が読んで以降の担当へ全文を渡す。探索は lead と独立設計担当が、それぞれ自分の設計に必要な範囲で行う。
 
 ## Phase 3: 設計と計画
 
-設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書く。設計担当が複数なら同じ入力で独立に検討させ、担当1が根拠で一つの案へ統合する。LITEでは実装担当が短い計画と検証方針を作り、報告の冒頭に書く。
+lead は設計を始める前に[設計の観点](design.md)を読み、その観点と書式で計画を作る。LITEでは短い計画と検証方針にする。
+
+独立設計担当を置く場合は、次の性質を保つ。
+
+- 独立設計担当への依頼（追加の質問を含む）には、要件・制約・規約全文・引き継いだ成果物だけを入れ、lead の案・結論・探索の結果は入れない。
+- lead は独立案を読む前に自案を作業記録の `raw/design-main.md` に保存し、保存後は変えない（例: 自案を保存してから独立設計担当へ委任する）。
+- lead が両案を根拠とトレードオフで比べて一つの計画にまとめ、`plan.md` に書く。比較の節には論点ごとの採否と理由を書く。
 
 ## Phase 4: 計画の確認
 
-計画レビュー・計画簡素化の担当へ同じ計画を渡し、指摘を「指摘の検証と統合」に従って扱う。LITEではこの工程を起動せず、計画はPhase 6の独立レビュー担当が、計画自体も誤りうる前提で確かめる。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
+計画レビュー担当へ同じ計画を渡し、計画レビューと計画の簡素化をあわせて依頼し、指摘を「指摘の検証と統合」に従って扱う。独立設計担当を置いた場合は、統合計画・両案・比較の節を渡し、独立案の論点を根拠なく退けていないかも確かめさせる。LITEではこの工程を起動せず、計画はPhase 6の独立コードレビューの担当が、計画自体も誤りうる前提で確かめる。同じ対象について初回を1として最大2ラウンドとする。上限到達後に計画を修正した場合は、未再確認の変更と残課題を記録する。重大な設計リスク、仕様・許可の未決事項、必要な担当の未完了があれば Phase 5 へ進まず未完了で返す。
 
 ## Phase 5: 実装と検証
 
-実装担当1体へ確定計画・必読ファイル・規約全文・所有ファイル・必要な検証を渡す。実装担当は計画を実装し、簡素化・セルフレビュー・必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。lead は報告の対象版・範囲・完了状態と、検証の証拠の所在・終了コードを照合する。全文の再レビューや同じ版の検証の再実行はせず、不足や矛盾は当該担当へ戻す。
+lead が確定計画を実装する。
 
-## Phase 6: 実装後の確認
+- 実装前に、規約と、計画に記した同種の既存実装2つを確認する（計画に無ければ選んで記す）。対象ファイルの現在の内容を読んでから編集する。
+- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて `状態: 質問` で利用者に確認する。
+- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
+- 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
+- lead の定義のテスト方針に沿って、プロジェクトの規約・CI・変更の影響に応じた必須検証を行う。実装ミスによる検証失敗の自己修正は3回まで。超えたら根拠と未解決点を記録して未完了で返す。
 
-同じ差分を固定し、受け取った体制の担当と追加した担当を並行して委任する。技術領域ごとに可読性担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。staged・unstaged・untracked を含めて対象を特定する。
+## Phase 6: 実装後の確認
 
-- 設計適合性: 設計担当1（LITEでは独立レビュー担当）が計画・受入条件・責務・依存方向と実コードを照合する。
-- 独立コードレビュー: 新規の `shinaps-reviewer`（独立コードレビュー）が、計画自体も誤りうるものとして正しさ・安全性・性能を確認する。
-- 規約照合: refine 担当を置く体制では `shinaps-refine-agent` へ、規約（`AGENTS.md`・`CLAUDE.md` とその参照先）の全文を rule として、比較元からの差分コマンド（`git diff <比較元> -- <path>`）を変更範囲の確認コマンドとして渡す。未追跡の新規ファイルは全行を今回の変更として扱う。BASIC・LITEでは独立コードレビューの担当が、同じ規約全文で行う。
-- 実装の簡素化: 実装の簡素化の `shinaps-simplifier`（LITEでは独立レビュー担当が兼ねる）が、目的・契約を保って削除・統合できる内容を確認する。
-- 可読性・慣習: 体制の表の担当（ULTRAでは技術領域ごとの `shinaps-reviewer`（可読性・慣習レビュー）、BASIC・LITEでは独立コードレビューの担当が種類を複数指定されて兼ねる）へ、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
+同じ差分を固定し、受け取った体制の担当と追加した担当を `shinaps-reviewer` へ並行して委任する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。staged・unstaged・untracked を含めて対象を特定する。
 
-LITEでは、独立レビュー担当を両方の種類で委任し、設計適合性と簡素化もあわせて依頼する。
+- LITE・BASIC: 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない。
+- ULTRA: A として新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B として技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する。
+- 規約照合には、規約（`AGENTS.md`・`CLAUDE.md` とその参照先）の全文と、比較元からの差分コマンド（`git diff <比較元> -- <path>`）を変更範囲の確認コマンドとして渡す。未追跡の新規ファイルは全行を今回の変更として扱う。
+- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。
 
 ## 指摘の検証と統合（Phase 4・6）
 
-指摘の整理は、設計責任者が採否を決める前に、指摘検証担当を置く体制では検証ラウンドごとに新規の `shinaps-review-verifier` が行い、いない体制では設計責任者が行う。全レポート・出典・確認範囲を使って全指摘の根拠・誤認・重複・対立・未確認を区別し、出典IDを保持して整理する。設計責任者がその結果から全項目の採否と理由、必要な修正と検証をまとめる。自分の成果物への指摘も根拠で採否を決め、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認する。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。再現・検証が必要なら実装担当へ依頼する。仕様・受入条件の変更や許可範囲の拡大は利用者の合意前に採用しない。
+lead が全レポートを使って全指摘の根拠・誤認・重複・対立・未確認を区別し、出典IDを保持して全項目の採否と理由、必要な修正と検証をまとめる。統合は多数決ではなく根拠で行い、自分の成果物への指摘の確認を独立検証とは報告しない。
+
+- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
+  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
+  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
+  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、`状態: 質問` で利用者に確認し、利用者の判断を記録した時点で解決とする。
+- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。
+- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
+- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件の変更や許可範囲の拡大は、利用者の合意前に採用しない。
 
 ## Phase 7〜8: 修正と終了判定
 
-修正指示を同じ実装担当へ返す。実装後の全体レビューは、最初の dev と各修正サイクルのそれぞれで、初回を1として最大2ラウンド。同じサイクルの中の増員・交代・計画変更では上限をリセットしない。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
+lead が採否に従って修正する。実装後の全体レビューは、最初の dev と各修正サイクルのそれぞれで、初回を1として最大2ラウンド。同じサイクルの中の増員・交代・計画変更では上限をリセットしない。2回目の後に修正したら必要なテストを行い、最終差分が再レビューされていないことを報告する。重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 
 ## Phase 9: コミット・push・draft PR と報告
 

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

@@ -0,0 +1,37 @@
+# 設計の観点
+
+設計する者が一つの実装計画を作るときの観点と書式。同じ要件から別々に作った計画を比べられるよう、どの設計にも同じものを使う。
+
+## 変更後の構造を先に決める
+
+既存の配置を正解と仮定せず、要件を満たした最終状態の責務・配置・依存方向を先に決める。その状態に必要な移動・分割・置き換えは変更量が大きくても計画する。最小化するのは到達に不要な変更であり、無関係な領域の整理や仮想的な将来への汎用化は含めない。
+
+利用範囲が広がる処理は、現在の所有featureと全利用箇所を調べる。別featureが無関係なfeature内部へ依存するなら、共通の責務だけを適切な層へ切り出し、固有の状態・振る舞いは各featureに残す。独立feature・共通UI・共通ロジックの選択はプロジェクトの規約と責務から決め、利用者が複数という理由だけで共通化しない。
+
+合意済みの機能・外部契約を保つ必要な構造変更は設計判断として行う。仕様変更・未許可の作業範囲への拡大・データ保全に関わる判断は、設計の依頼元へ返す。移動に伴う全利用箇所の更新と旧経路・重複の解消、既存利用側の回帰確認まで計画に含める。規約と設計案が衝突する場合は、規約を古いと判断せず規約に従う。
+
+## 検討観点
+
+次の観点を比べ、トレードオフを踏まえた推奨案を一つだけ出す。
+
+- **必要な変更の範囲**: 最終状態に必要な構造変更を含め、その到達に不要な変更を除く
+- **責務と境界**: 責務の分け方と境界を明確に保つ
+- **工数と効果**: 現実的な工数に見合う効果があるか
+- **セキュリティ**: 認証・認可・入力検証・秘密情報
+- **性能**: 計算量・DBへの往復回数・キャッシュ
+- **テストのしやすさ**: テストできる単位と、依存の差し替えやすさ
+- **単純さ**: 外部ツール・API が自分で拒否する入力を先回りして検査しない（失敗経路は 1 つにし、安全側の結果にする）。要件やレビューの列挙に 1 対 1 で分岐を作らず、共通する性質で設計する。失敗の理由を区別するのは動作を変える要件がある場合だけ
+
+## 計画の書式
+
+- **設計判断**: 採用する方針と、他の案を採らなかった理由
+- **先例と慣習**: 規約と、同種の既存実装2つ（file:line またはコミット）を確認して記す。慣習から外れる判断にはその理由を書く
+- **責務と配置**: 変更後の所有者・配置先・利用側からの依存方向と根拠。利用範囲が変わる責務は、移動する／現状に残す理由を示す
+- **目的と不変条件**: 保つ性質を不変条件で書く
+- **変更範囲**: 変更・移動・削除・新規の対象ファイルと、各ファイルの責務を 1 行。個々の置換・文言は列挙せず、実装する時に現物に合わせて決める
+- **主要な部品**: 主要なクラス・関数・型のシグネチャ
+- **データの流れ**: 主要なリクエスト・イベントの流れ
+- **実装順**: 依存関係を考慮した順序
+- **検証方針**: 実行する既存検証と、必要な場合だけ追加・更新する回帰テスト・仕様テスト。その保証対象と既存テストでは不足する理由
+- **観点ごとのトレードオフ**: 採用理由・却下理由を各観点で 1 行
+- **断定と根拠**: 「〜が良いと思います」ではなく「〜にする」と書き、判断の根拠には既存パターンを file:line で引用する

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

@@ -1,24 +1,22 @@
 # 実装体制の判断
 
-devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ。BASIC・ULTRAでは選んだ体制の必須担当を下限にメインが担当を追加でき、LITEは表の2名だけで進める。「メイン」はdevを実行するClaude Codeのセッション（CLIまたは対話）を指し、linear-executeの進行役とは区別する。linear-execute の進行役は各Issue開始時に、確認した体制と、受入条件・関連範囲・既存検証・リスクを材料として渡す。
+devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ。BASIC・ULTRAでは選んだ体制の必須担当を下限にメインが担当を追加でき、LITEは独立コードレビューの担当1名だけで進める。「メイン」はdevを実行するClaude Codeのセッション（CLIまたは対話）を指し、linear-executeの進行役とは区別する。linear-execute の進行役は各Issue開始時に、確認した体制と、受入条件・関連範囲・既存検証・リスクを材料として渡す。
+
+メインは、同じ文脈を必要とする作業（調査・設計・計画の統合・実装・検証・修正・指摘の採否・修正計画・人の指摘の調査）を、どの体制でも自分で行う。担当に依頼するのは、別のコンテキストで行うことに意味がある仕事（独立した別案、計画と実装の独立確認、互いに独立した領域の並行調査）だけとする。同じ対象を読む確認の観点は、少数の担当にまとめて依頼する。
 
 ## 体制の種類
 
-| 役割 | LITE | BASIC | ULTRA |
+3体制の違いは、独立確認を置く対象・人数・深さだけである。許可・QA・必須検証・終了地点は体制によって変わらない。括弧内の「各N」は、各観点を独立に見る担当の数を表す。
+
+| 工程 | LITE | BASIC | ULTRA |
 | --- | --- | --- | --- |
-| 設計 | 置かない（実装担当が短い計画と検証方針を作る） | 1名（設計担当1） | 2名（独立に設計し、担当1が統合） |
-| 計画レビュー | 置かない | 1名 | 2名 |
-| 計画簡素化 | 置かない | 1名 | 2名 |
-| 実装 | 1名 | 1名 | 1名 |
-| 実装後の設計適合性 | 独立レビュー担当（design 観点で計画と実コードを照合する） | 設計担当1 | 設計担当1 |
-| 実装後の独立コードレビュー | 独立したOpusの1名（正しさ・可読性・慣習・規約照合・簡素化を兼ねる） | 独立した1名（可読性・慣習と規約照合も兼ねる） | 1名 |
-| 実装後の refine | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 1名 |
-| 実装後の可読性・慣習 | （独立レビュー担当が兼ねる） | （独立コードレビューの担当が兼ねる） | 技術領域ごとに1名 |
-| 実装後の簡素化 | （独立レビュー担当が兼ねる） | 独立した1名 | 1名 |
-| 指摘の整理 | 実装担当（設計責任者） | 設計担当1（計画と実装後） | 計画と実装後の各検証ラウンドで、新規の指摘検証担当1名 |
-| 採否 | 実装担当（設計責任者） | 設計担当1 | 設計担当1 |
-
-設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。各役割の定義・継続・新規にする単位は[工程](workflow.md)の「役割と継続」に従う。探索は必須にしない。探索担当を置かない場合は、設計担当（LITEでは実装担当）が設計に必要な範囲を調べる。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
+| 調査・設計・計画 | メイン（短い計画と検証方針） | メイン | メインが自案を保存した後、独立設計担当1名が別案を作り、メインが比較して統合する |
+| 計画の独立確認 | 置かない（実装後の独立レビューが計画も確かめる） | 計画レビュー担当1名（計画レビュー・計画の簡素化。各1） | 計画レビュー担当2名（計画レビュー・計画の簡素化・独立案の論点を根拠なく退けていないか。各2） |
+| 実装・検証・自己簡素化・修正 | メイン | メイン | メイン |
+| 実装後の独立レビュー | 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・可読性・慣習・実装の簡素化。各1） | LITEと同じ | A: 独立コードレビューの担当1名（独立コードレビューの全観点（rule 観点を含む）・設計適合性・実装の簡素化）。B: 技術領域ごとに1名（規約照合（全手順）・可読性・慣習）。各1（A も rule 観点で規約に照らす） |
+| 指摘の検証・採否・修正計画・人の指摘の調査 | メイン | メイン | メイン |
+
+各役割の定義・継続・新規にする単位と、体制ごとに依頼するレビューの種類は[工程](workflow.md)の「役割と継続」とPhase 6に従う。探索は必須にしない。体制・経路（auto・manual）・メインのモデルは別の項目で、互いに影響しない。
 
 ## 体制の選択
 
@@ -37,7 +35,7 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 
 ## メインの裁量
 
-メインは選んだ体制の必須担当に加えて、探索担当の配置、役割の追加、技術領域ごとの割り当て、並列化、複数担当の範囲分担を決める。BASIC・ULTRAでは、追加を次の基準で判断する（体制の推奨にも使う）。
+BASIC・ULTRAでは、メインは選んだ体制の必須担当に加えて、役割の追加、技術領域ごとの割り当て、並列化、複数担当の範囲分担を決める。互いに独立した領域を並行して調べる探索担当も置ける。追加は次の基準で判断する（体制の推奨にも使う）。
 
 - **不確実性**: 要件と既存の解法が明確か。責務・依存方向・設計案の比較に、下限を超える独立した検討が必要か。
 - **影響範囲**: 局所的で利用側を追えるか。複数機能・共通基盤・実行環境をまたぐか。
@@ -45,7 +43,7 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 
 点数・行数・一律の大小ラベルで人数を自動決定せず、未解決の問いと必要な独立確認に担当を対応させる。初期確認だけで分からなければ、まず探索の範囲を決め、その結果で設計前に体制を更新する。担当を起動するためだけの調査や計画書は増やさない。追加は必要な役割だけにし、どれか一つを増やすために全役割を増やさない。
 
-LITEでは、探索を含む担当を追加しない。必要な調査・設計・簡素化・テスト・指摘の根拠の確認と修正は実装担当が、独立した確認は独立レビュー担当が担う。2名で足りないと分かったら、理由を添えて、人への確認の窓口からBASIC・ULTRAへの変更を相談する（変更の扱いは「体制の選択」のとおり）。
+LITEでは、探索を含む担当を追加しない。独立コードレビューの担当1名で足りないと分かったら、理由を添えて、人への確認の窓口からBASIC・ULTRAへの変更を相談する（変更の扱いは「体制の選択」のとおり）。
 
 ## 技術領域
 
@@ -53,7 +51,7 @@ LITEでは、探索を含む担当を追加しない。必要な調査・設計
 
 ## 記録と引き渡し
 
-設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立レビュー担当は実装担当と別のコンテキストにする。
+設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立した担当は、実装したメインとは別のコンテキストにする。
 
 linear-executeから受けた作業では、選んだ体制と追加した担当を進行役へ報告する。追加の判断では人の承認を待たない。材料が欠けていれば初期確認して、BASIC・ULTRAでは追加の担当を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
 
@@ -67,6 +65,8 @@ BASIC・ULTRAでは、選んだ体制は上限ではない。LITEでは増やさ
 
 ## 維持する条件
 
-選んだ体制の必須担当を、自己確認・体制の表に無い兼務・メインの代行で完了扱いにせず、委託不可・起動不能なら未完了とする。明示された人数制限・予算が下限を満たさない場合は、人へ一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ未完了とする。独立レビュー担当の確認を、実装担当の自己確認で代えない。
+選んだ体制の必須担当を、メインの自己確認や体制の表に無い兼務で完了扱いにせず、委託不可・起動不能なら未完了とする。明示された人数制限・予算が下限を満たさない場合は、人へ一問で確認する。合意があれば、実施しない必須担当を未実施として記録・報告し、品質上の完了とは報告しない。合意が無ければ未完了とする。
+
+委託できない場合、Linear進行（[`dev_delegation`](../linear/configuration.md) が無い）ではdevを始めず、必要な許可を求めて返す。単独のdevで利用者が委託を禁止した場合は、必須担当を合意による未実施として続けるかを一問で確認する。
 
 要件と影響範囲の確認、必要なテストとプロジェクトの必須検証、適用規約の照合、全指摘の採否と根拠の記録を維持する。サービス規約を取得できない、担当が未完了、必須検証が失敗した場合はその状態を報告し、確認済みと偽らない。重大な未解決事項を完了にしない。linear-executeのLocal Agent QA、人レビュー、公開条件、終了地点は体制によって変えない。

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

@@ -1,12 +1,12 @@
 # dev の工程
 
-Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制の判断](staffing.md)で選んだ体制の担当で進め（BASIC・ULTRAでは必須担当を下限に追加できる）、担当の起動・継続は[起動手順](launch.md)に従う。
+Claude Codeのdev（`dev-claude`）の工程。メインが調査・設計・実装・検証・修正・指摘の採否を行い、[実装体制の判断](staffing.md)で選んだ体制の担当が独立した別案と独立確認を行う（BASIC・ULTRAでは必須担当を下限に追加できる）。担当の起動・継続は[起動手順](launch.md)に従う。
 
 ## 1. 前提と作業記録
 
 適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者が委託を明示的に禁止した場合と、Linear進行で[`dev_delegation`](../linear/configuration.md)がない場合だけ。worktreeは許可された場合だけ使う。委託が許可されない、または担当を起動・再開できず§2の交代もできない場合も、メインはその担当の作業（実装・修正・計画・検証・統合）を代わりに行わない。その工程を未完了として返し、必要な判断（許可・準備・体制）を求める。サービス規約を取得できない工程は未照合と明示する。
+devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者が委託を明示的に禁止した場合と、Linear進行で[`dev_delegation`](../linear/configuration.md)がない場合だけで、その扱いは[体制](staffing.md)の「維持する条件」に従う。worktreeは許可された場合だけ使う。サービス規約を取得できない工程は未照合と明示する。
 
 作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。短い作業は短い計画・記録にする。
 
@@ -16,32 +16,28 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 
 | 工程 | 役割定義 | 継続と責任 |
 | --- | --- | --- |
-| Phase 2 | `shinaps-explorer` | 置く場合に、必要な探索範囲ごとに起動 |
-| Phase 3・4・6・7 | `shinaps-architect` | 担当1は設計・統合・設計適合性・指摘統合・修正計画と、人の指摘の技術調査（読み取り専用）を継続。担当2以降は独立設計と追加確認のみ |
-| Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
-| Phase 4・6 | `shinaps-simplifier` | 計画の簡素化は修正版の再確認も同じ担当。実装の簡素化は計画とは別の担当で、ラウンドと修正サイクルをまたいで継続 |
-| Phase 4・6 | `shinaps-review-verifier` | 指摘検証担当を置く体制で、検証ラウンド（計画確認と実装後レビューの各ラウンドに1回）ごとに新規。今回の指摘を出した担当を流用しない |
-| Phase 3・5・7 | `shinaps-implementer` | 1体。修正も同じ担当。設計担当を置かない体制（LITE）では、設計責任者として計画と指摘の整理・採否も担う |
-| Phase 6 | `shinaps-reviewer` | 独立コードレビューは実装担当とは別で、レビューラウンドごとに新規。独立コードレビューを含む複数の種類を兼ねる場合は、独立コードレビューの規則に従う。可読性・慣習レビューを技術領域ごとに置く場合は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
-| Phase 6 | `shinaps-refine-agent` | refine 担当を置く体制で、ラウンドと修正サイクルをまたいで継続 |
+| Phase 2 | `shinaps-explorer` | 任意。互いに独立した領域を並行して調べるときに、領域ごとに起動 |
+| Phase 3 | `shinaps-architect` | 独立設計担当を置く場合（ULTRAでは必須、BASICでは追加できる）。独立案と、その案への追加の質問への回答だけを担う |
+| Phase 4 | `shinaps-plan-reviewer` | 計画レビューと計画の簡素化をあわせて見る。修正版の再確認も同じ担当 |
+| Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
 
 - 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合（resumeをまたぐ場合を含む）は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
-- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパス・引き継ぎ先を依頼に渡す。実装担当にはファイルの所有範囲を明記し、他者の変更を戻さず現物に合わせるよう伝える。他の担当は読み取り専用で、自分でエージェントを起動しない。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインと実装担当も対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは依頼の確認、体制と工程の調整、担当の起動・待機・全文保存・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らず、担当に割り当てた判断を先回りして選別しない。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
-- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevの分担で扱う。メインは確認済み結果の説明・質問の整理・取り次ぎだけを行い、調査・技術的検証・編集は担当へ渡す。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、同じ分担で取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
+- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
+- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインは対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
+- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
 - **修正サイクル**: devの完了後に実装の修正が必要になったら（人の修正開始（[人のレビュー](../human-review.md)）、Codex QAの差し戻し、コミット中の指摘など、契機によらず）、未対応の指摘の集合を一つの入力にして次の順に進める。人の修正開始では、体制を[体制の選択](staffing.md)に従って確認する。入力が一致する結果は[テスト方針](../testing.md)に従って引き継ぐ。一部をコミットした後の修正は `commit` の規定どおり後続単位にする。
-  1. 設計責任者が修正計画と、影響を受ける工程を決める。
+  1. メインが修正計画と、影響を受ける工程を決める。
   2. 設計・契約・検証条件を変える場合だけ、Phase 4の扱いで再確認する。
-  3. 同じ実装担当が修正する（Phase 5）。
-  4. Phase 6の担当（選んだ体制のとおり）と、指摘検証担当を置く体制ではその新規の担当が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
+  3. メインが修正する（Phase 5）。
+  4. Phase 6の担当（選んだ体制のとおり）が確認する。範囲は修正とその影響範囲とし、確定できなければ広げる。
   5. Phase 7で統合・修正する。
 
 ## 3. Phase 1: タスクと体制の確定
 
 依頼・引数・指定された成果物から目的・受入条件・範囲を確定する。確定済みの内容を聞き直さず、依頼されていない過去の作業を始めない。成果物に実装可否の状態があればreadyを確認し、欠落・不明なら変更内容を推測せずタスクを確定する。内容ハッシュがある根拠は現在値と照合し、古い根拠は読み直す。
 
-Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。依頼に書かれた体制（無ければ[体制の選択](staffing.md)に従って確認する）の担当で進め、BASIC・ULTRAではlinear-executeから受けた材料と現物からメインが追加の担当を決める。設計担当を起動する前に、選んだ体制・追加の担当と根拠・役割別人数・技術領域ごとに担当を置く場合はその割り当て・必須検証を作業記録の `staffing.md` へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
+Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。依頼に書かれた体制（無ければ[体制の選択](staffing.md)に従って確認する）の担当で進め、BASIC・ULTRAではlinear-executeから受けた材料と現物からメインが追加の担当を決める。設計を始める前に、[体制](staffing.md)の「記録と引き渡し」の項目を作業記録の `staffing.md` へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
 
 ## 4. Phase 2: 規約と必要な探索
 
@@ -49,71 +45,86 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 - `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
-- 十分な根拠があれば探索担当を追加しない。不足する領域は、LITEでは実装担当が調べる。BASIC・ULTRAでは探索担当を置くか、各設計担当が自分の設計に必要な範囲を調べる。探索担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
+- 調査はメインが行う。BASIC・ULTRAでは、互いに独立した領域を並行して調べる場合に探索担当を置ける（任意）。探索担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 
 新しい不確実性・影響範囲が見つかったら、設計前に体制を更新する。
 
 ## 5. Phase 3: 設計と計画
 
-設計責任者は設計担当1、設計担当を置かない体制（LITE）では実装担当とする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書き、個々の置換や文言は実装担当が現物に合わせて決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
+メインは設計を始める前に[設計の観点](design.md)を読み、その観点と書式で計画を作る。LITEでは短い計画と検証方針にする。計画は `plan.md` に書き、Phase 4が終わるまで「未確定」と明記する。
 
-設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。LITEでは実装担当が短い計画と検証方針を作り、報告の冒頭に書く。
+独立設計担当を置く場合は、次の性質を保つ。
+
+- 独立設計担当への依頼（追加の質問を含む）には、要件・制約・規約全文・引き継いだ成果物だけを入れ、メインの案・結論・探索の結果は入れない。
+- メインは独立案を読む前に自案を `raw/design-main.md` に保存し、保存後は変えない。Claude Codeでは担当の結果の全文がメインに届き、届いた時点でメインは独立案を読むことになるので、自案を保存してから独立設計担当を起動する。
+- 独立案は `raw/architect-{n}.md` に保存する。メインが両案を根拠とトレードオフで比べて一つの計画にまとめ、`plan.md` に書く。比較の節には論点ごとの採否と理由を書く。
 
 ## 6. Phase 4: 計画の確認
 
-計画レビュー・計画簡素化の担当を起動し、同じ計画・要件・調査・規約を渡す。LITEではこの工程を起動せず、計画はPhase 6の独立レビュー担当が、計画自体も誤りうる前提で確かめる。レビューは要件・実現可能性・設計リスク・検証方針、簡素化は目的と外部契約を保って減らせる構造・状態・手順を確認する。
+計画レビュー担当を起動し、同じ計画・要件・調査・規約を渡す。計画レビューと計画の簡素化をあわせて依頼する。独立設計担当を置いた場合は、統合計画・両案（`raw/design-main.md` と独立案）・比較の節を渡し、独立案の論点を根拠なく退けていないかも確かめさせる。LITEではこの工程を起動せず、計画はPhase 6の独立コードレビューの担当が、計画自体も誤りうる前提で確かめる。
 
-全結果を `raw/plan-review-{round}-{n}.md` / `raw/plan-simplify-{round}-{n}.md` に保存し、「指摘の検証と統合」に従う。計画変更があれば `raw/architect-revised-{round}.md` に残し、変更の影響を受ける担当へ同じ修正版と前回の採否を渡し、修正箇所と影響範囲を中心に再確認させる。影響範囲を確定できなければ再確認の範囲を広げる。契約・設計・検証条件に影響しない表記整理だけで新たなラウンドを作らない。
+全結果を `raw/plan-review-{round}-{n}.md` に保存し、「指摘の検証と統合」に従う。計画変更があれば `raw/plan-revised-{round}.md` に残し、変更の影響を受ける担当へ同じ修正版と前回の採否を渡し、修正箇所と影響範囲を中心に再確認させる。影響範囲を確定できなければ再確認の範囲を広げる。契約・設計・検証条件に影響しない表記整理だけで新たなラウンドを作らない。
 
-採用すべき指摘と必要な判断が解決したら `plan.md` を確定する。計画段階には回数上限を設けないが、目的のない反復や新しい根拠のない却下案の再提案は行わない。runtime固有の上限があれば起動手順に従い、未確認の最終変更と残課題を明示する。
+採用すべき指摘と必要な判断が解決したら `plan.md` を確定し、「未確定」の表示を外す。計画段階には回数上限を設けないが、目的のない反復や新しい根拠のない却下案の再提案は行わない。runtime固有の上限があれば起動手順に従い、未確認の最終変更と残課題を明示する。
 
 ## 7. Phase 5: 実装と検証
 
-メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
-
-実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げず報告する。技術的な矛盾はメインが設計責任者へ渡す。仕様・範囲の変更はメインが人に確認する。通常の判断は既存の合意と規約で解決する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+メインは `plan.md` を再読し、計画を実装する。
 
-実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
+- 実装前に、規約と、計画に記した同種の既存実装2つを確認する（計画に無ければ選んで記す）。対象ファイルの現在の内容を読んでから編集する。
+- 同じ作業ツリーでは他者も作業している。既存の変更を戻さず、現在の内容に合わせる。
+- 計画で決めた最終構造を実装する。必要な移動・分割を差分削減のために省略せず、全利用側の参照更新・旧経路や重複の解消・既存利用側の回帰確認まで行う。
+- 目的・仕様・受入条件の変更が必要と分かったら、該当作業を止めて人に確認する。計画の前提が成立しない技術的な矛盾は計画を直し、設計・契約・検証条件が変わればPhase 4の扱いで再確認する。通常の判断は既存の合意と規約で解決する。
+- 検証やレビューの指摘には原因を確認して対処する。期待値や受入条件を弱めて成功扱いにしない。
+- 実装後、目的を保ったまま削除・統合できる処理を確かめ、不要な分岐・重複・互換層を減らしてからセルフレビューする。
+- [テスト方針](../testing.md)に沿って、プロジェクトの規約・CI・変更の影響に応じた検証を行う。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+- 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を記録し、追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
-メインは報告の対象版・範囲・完了状態と、検証の証拠の所在・終了コードを照合して `implementation.md` に保存する。全文の再レビューや同じ版の検証の再実行はせず、不足や矛盾は当該担当へ戻す。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
+メインは `implementation.md` に、変更ファイルと変更内容、設計理由、確認した先例と慣習から外れる判断の理由、簡素化した点、計画からの変更と合意、検証コマンドと終了コード・証拠の所在、未実施事項・未解決点を書く。実行していない検証を成功と書かない。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
 
 ## 8. Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ体制の担当と追加した担当を並行して起動する。技術領域ごとに可読性担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
+同じ差分を固定し、選んだ体制の担当と追加した担当を `shinaps-reviewer` で並行して起動する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。
 
-| 観点 | 責任者と入力 |
+| 体制 | 担当と依頼するレビューの種類 |
 | --- | --- |
-| 設計適合性 | 設計担当1を再開（LITEでは独立レビュー担当）。計画・受入条件・責務・依存方向と実コードを照合 |
-| 独立コードレビュー | 新規の `shinaps-reviewer`（独立コードレビュー）。対象コード・全差分・利用側・規約・検証結果を読み、計画自体も誤りうるものとして正しさ・安全性・性能を確認 |
-| 規約照合 | `shinaps-refine-agent`、またはBASIC・LITEでは独立コードレビューの担当。規約全文・対象ファイル全文・変更範囲を照合 |
-| 実装の簡素化 | 実装の簡素化の `shinaps-simplifier`（LITEでは独立レビュー担当が兼ねる）。目的・契約を保って削除・統合できる内容を確認 |
-| 可読性・慣習 | 体制の表の担当（ULTRAでは技術領域ごとの `shinaps-reviewer`（可読性・慣習レビュー）、BASIC・LITEでは独立コードレビューの担当が種類を複数指定されて兼ねる）。担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す |
+| LITE・BASIC | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない |
+| ULTRA | A: 新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する |
 
-LITEでは、独立レビュー担当を両方の種類で起動し、設計適合性と簡素化もあわせて依頼する。
+- 独立コードレビューには、対象コード・全差分・利用側・規約・計画・検証結果を渡し、計画自体も誤りうるものとして確かめさせる。
+- 規約照合には、規約全文・対象ファイル全文と、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡のファイルは全行を今回の変更とする）を渡す。
+- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
+- 技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
 
-変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。設計担当1は自身の確認が終わるまで他担当の今回の結果を読まない。
+変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。
 
-結果を `architecture-review.md` / `review-{round}-{n}.md` / `raw/refine-{round}.md` / `raw/simplify-{round}-{n}.md` / `raw/readability-{round}-{n}.md` に保存する。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。
+結果を `review-{round}-{n}.md` に保存する。未確認部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で担当の完了を判定する。未照合の規約は、特定できる単位（例: id・topic）でPhase 9に報告する。
 
 ## 9. 指摘の検証と統合（Phase 4・6共通）
 
-指摘の整理は、設計責任者が採否を決める前に、指摘検証担当を置く体制では検証ラウンドごとに新規の `shinaps-review-verifier` が行い、いない体制では設計責任者が行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの担当は完了と確認範囲を確認する。
+メインが全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、全指摘を整理する。各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確かめ、根拠・誤認・重複・対立・未確認を区別する。同じ原因・影響・修正方針の指摘だけまとめ、元の項目と重要度を消さない。指摘なしの担当は完了と確認範囲を確かめる。
 
-検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、verifierが整理した場合は設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する（LITEでは体制の変更を相談する）。
+全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。Phase 4は `plan.md`、Phase 6は `fix-log.md` の「指摘の採否」の節に書く（`fix-log.md` ではQAの変更記録と節を分ける）。統合は多数決ではなく根拠で行う。メイン自身の確認を独立検証とは報告しない。
 
-統合は多数決ではなく根拠で行う。設計責任者は自分の成果物への指摘も根拠で採否を決めて理由を記録し、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認し、Infoや提案を採らないことに同意を求めない。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierが整理した場合、設計責任者は検証済みの全件の事実確認を最初からやり直さない。
+- 今回の変更とその影響範囲にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
+  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
+  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
+  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、人への確認（Phase 5 の「該当作業を止めて人に確認する」）に回し、人の判断を記録した時点で解決とする。
+- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。複雑な対立は[体制](staffing.md)の「途中の増員」で担当を追加できる（LITEでは体制の変更を相談する）。
+- 既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
+- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は、人の合意前に採用しない。
 
 ## 10. Phase 7〜8: 修正と終了判定
 
-設計責任者の修正指示を同じ実装担当へ返し、変更と必要な検証を `fix-log.md` に記録する。Local Agent QAの後の修正では、[変更記録](../linear/qa.md#qaの時点対象最終qa)の項目も残す。修正不要ならPhase 9へ進む。
+メインが採否に従って修正し、変更と必要な検証を `fix-log.md` に記録する。Local Agent QAの後の修正では、[変更記録](../linear/qa.md#qaの時点対象最終qa)の項目も残す。修正不要ならPhase 9へ進む。
 
-実装後の全体レビューは、最初のdevと各修正サイクルのそれぞれで、初回を1として最大2ラウンド。同じサイクルの中の増員・交代・計画変更では上限をリセットしない。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前に設計責任者が全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。
+実装後の全体レビューは、最初のdevと各修正サイクルのそれぞれで、初回を1として最大2ラウンド。同じサイクルの中の増員・交代・計画変更では上限をリセットしない。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前にメインが全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。
 
 重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 
 ## 11. Phase 9: 完了と引き渡し
 
-選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正、検証結果、未実施・未照合・未解決事項を報告する。refine 担当を置かない体制（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)）。
 

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

@@ -31,7 +31,7 @@ Bridgeのpeer通知、Codexからのメッセージ、ackは依頼ではない
 devから続く作業（Linear進行を含む）では、人のレビュー中（コミットの開始依頼の後を含む）の指摘を記録・調査・意図確認までにとどめ、編集しない。個々の指摘で修正の工程を起動しない。Linear進行で作業ツリーの編集を止める時点（QA中・途中確認の間）は[担当と工程](linear/workflow.md)の「担当と窓口」に従う。
 
 - 指摘はClaudeの作業記録 `human-findings.md` に記録する。この記録を台帳と呼ぶ。項目は指摘・対象・意図確認・調査結果・状態の5つ。
-- 意図は人へ一問ずつ確認する。調査はdevの分担（[工程](dev/workflow.md)の「役割と継続」）に従って担当へ渡し、メインは編集・修正しない。
+- 意図は人へ一問ずつ確認する。調査はdevのメインが読み取りだけで行い（[工程](dev/workflow.md)の「役割と継続」）、修正開始まで編集・修正しない。
 - 人がWebStormで直接編集した内容も記録し、次の修正サイクルの対象に含める。
 
 人が修正を始めることを明示したら、Claudeが修正を始める。固定の文言は求めない。範囲の限定が無ければ未対応の指摘すべてを対象にし、体制を[体制の選択](dev/staffing.md)に従って確認してから、devの修正サイクル（[工程](dev/workflow.md)の「役割と継続」）へ一つの入力として渡す。指摘だけの発話は修正開始としない。曖昧なら一問で確認する。

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.36.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.36.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.37.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.37.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
 
 0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
 
@@ -96,7 +96,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
 | `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
 
-- メインはdevを実行するClaude Codeのセッションを指す。担当（独立レビュー・簡素化を含む）のモデルは役割定義の値で、経路とは独立している。単独のdev（Linear進行を経ないdev）のメインは利用者のセッション設定のまま。
+- メインはdevを実行するClaude Codeのセッションを指す。担当（独立レビューを含む）のモデルは役割定義の値で、経路とは独立している。単独のdev（Linear進行を経ないdev）のメインは利用者のセッション設定のまま。メインは調査・設計・実装・指摘の採否を自分で行うので、メインのモデル（manualでFableを選べばFable）がそのまま設計・実装のモデルになる。
 - manualの対話セッションのモデルは、人が `/model` で切り替える。Claudeへのプロンプトや Bridge のメッセージでは切り替えられない（[model-config](https://code.claude.com/docs/en/model-config)）。
 - manualで基本（Opus）と違う選択なら、Codexが人へ切り替えを依頼する。Codexは人の報告を記録し、実際のモデルを照合できたとは扱わない。
 

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

@@ -20,7 +20,7 @@
 
 ## Issue開始時の実装体制
 
-進行役は各Issueの設定・受入条件・関連範囲・既存検証・リスクを短く確認し、体制判断の材料として必須検証・許可範囲とともにClaudeへ渡す。体制は[体制の選択](../dev/staffing.md)に従って確認して渡す。範囲全体の指定があれば引き継ぎ、無ければIssueごとに確認する。追加の担当（BASIC・ULTRA）は、Claudeのメインが材料と現物から設計担当の起動前に決め、進行役へ報告する。
+進行役は各Issueの設定・受入条件・関連範囲・既存検証・リスクを短く確認し、体制判断の材料として必須検証・許可範囲とともにClaudeへ渡す。体制は[体制の選択](../dev/staffing.md)に従って確認して渡す。範囲全体の指定があれば引き継ぎ、無ければIssueごとに確認する。追加の担当（BASIC・ULTRA）は、Claudeのメインが材料と現物から設計の前に決め、進行役へ報告する。
 
 Claudeのメインは途中の新しい根拠で必要な担当を増やし（BASIC・ULTRA。LITEは体制の変更を相談する）、進行役へ報告する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。追加の担当・増員は人の承認待ちにせず、仕様・範囲・許可・予算の変更だけ確認する。