@shinaps/skills 0.35.1 → 0.35.2

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

@@ -12,20 +12,22 @@
 
 | 役割 | 専任を置く判断と人数 | 専任を置かない場合 |
 | --- | --- | --- |
-| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | メインが関連コードと既存調査を確認 |
-| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | メインが短い計画と検証方針を確定 |
-| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | メインが要件・実装可能性・検証方針を確認 |
+| 探索 | メインの初期確認では根拠が足りない領域に配置。独立に調べられる領域なら分担 | 設計担当1、いなければ実装担当が計画・実装に必要な範囲を調べる |
+| 設計 | 責務・依存・方式の判断が必要なら配置。競合する案や重大な見落としを独立に比較する必要があれば複数 | 実装担当が短い技術計画と検証方針を作り、設計責任者を兼ねる |
+| 計画レビュー | 実装前に検証すべき設計リスクがあれば配置。異なる観点の独立確認が必要なら複数 | 計画を作った担当が要件カバーと実現可能性の根拠を計画に書き、独立コードレビューが計画自体も誤りうるものとして確かめる |
 | 計画／実装の簡素化 | 状態・抽象化・変更範囲の複雑さに専門の検討が必要なら配置。計画と実装で別々に判断 | 計画は設計責任者、実装は実装担当とコードレビュー担当が確認 |
-| 実装 | 1体。修正も同じ担当に戻す | 委託不可の場合だけ、既存の許可・規約に従ってメインが実装 |
+| 実装 | 1体。修正も同じ担当に戻す | 委託が許可されない、または起動できない場合もメインは代行しない。再開・交代し、できなければ未完了として必要な判断を求める（[工程](workflow.md)の§1・§2） |
 | 独立コードレビュー | 最低1体。重要な契約や複数領域の見落としを独立に確認する必要があれば追加 | 委託不可・起動不能なら独立レビュー未完了。自己レビューで代替完了にしない |
 | refine | 規約の量・領域の広さから別担当での照合が有効なら配置 | コードレビュー担当に規約全文と照合責務を渡す。サービス規約未取得なら未照合と明示 |
-| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | メインが全指摘の根拠・出典・未確認事項を確認 |
+| 指摘検証（verifier） | 指摘が多い、相互に矛盾する、根拠の確認が難しい場合に配置。計画と実装の各ラウンドで判断 | 設計担当1、いなければ実装担当が全指摘の根拠・出典・未確認事項を整理して採否を決める（採否は[工程](workflow.md)の「指摘の検証と統合」に従う） |
 
-明確で局所的な変更なら、メインが計画し、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
+専任を置かない責務はメインへ戻さず、成果物を作った担当から独立している必要があるかで既存の担当へ割り当てる。
+
+明確で局所的な変更なら、実装担当が短い計画を作り、実装1体・独立コードレビュー1体で進められる。設計が難しければ設計担当や計画レビューを追加し、設計案の独立比較が必要なら設計担当を複数にする。コードのリスクが高い場合はコードレビューを増やす。どれか一つを増やすために全役割を複数にしない。
 
 ## 体制の記録と引き渡し
 
-起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければdevのメインが責任を持つ。独立レビュー担当は実装担当と別のコンテキストにする。
+起動前に、判断の根拠、工程ごとの役割・人数・確認範囲、専任なしの責任者、必須検証、設計と指摘の統合責任者を短く記録する。設計担当がいれば担当1が設計・統合を継続し、いなければ実装担当が設計責任者になる。独立レビュー担当は実装担当と別のコンテキストにする。
 
 linear-executeから受けた作業では、メインが決めた初期体制と根拠を進行役へ報告する。通常の体制判断で人の承認を待たない。材料が欠けていれば既定の人数へ戻さず、初期確認して体制を決める。ローカル記録は `.shinaps/work/` 以下へ保存する。別セッションへは本文も渡し、相手から見えないパスだけに依存しない。
 
@@ -34,7 +36,7 @@ linear-executeから受けた作業では、メインが決めた初期体制と
 初期体制は上限ではない。設計上の新しい不確実性、影響領域の追加、重要な契約への影響、検証失敗、指摘の対立が判明した時点でdevのメインが必要な役割・人数・確認範囲を増やす。担当からの提案はメインが判断する。理由と体制の変更を記録し、linear-executeでは進行役へ報告する。初期判断や報告のために作業を止める必要はないが、追加担当の確認が必要な工程は結果が揃うまで完了にしない。
 
 - 新しい担当には現在の要件・同じ版の対象・規約・確定済み判断を渡す。独立確認を求める場合、他担当の今回の未確定結果は渡さない。
-- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、メインの旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
+- 設計担当を途中で置く場合は担当1を統合責任者として引き継ぎ、実装担当の旧計画も検討対象にする。既存担当の仕事を理由なく最初から繰り返さない。
 - 増員で既存の未完了・不利な指摘を消さない。同じ対象への増員・交代でレビューラウンドの上限をリセットしない。枠不足は順番に起動し、人数を黙って減らさない。
 - 体制判断は委託・モデル変更・操作・予算の許可を作らない。既存の許可と予算内の増員は再承認不要。仕様・範囲・明示された人数制限・許可・予算を変える必要がある場合だけ、人へ理由と選択肢を一問で確認する。
 

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

@@ -6,7 +6,7 @@ Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制
 
 適用される `AGENTS.md`・`CLAUDE.md` と参照先、CI、既存スクリプトから作業条件を読み、依頼・範囲・操作許可を引き継ぐ。仕様を左右する不足だけ一問ずつ確認する。新しい恒久方針は了承を得て保存する。利用できないツールを仮定しない。
 
-委託・worktreeは許可された場合だけ使う。委託できない場合はメインが可能な調査・実装・自己確認を行ってよいが、独立レビューを実施したとは報告せず、未完了として返す。サービス規約を取得できない工程は未照合と明示する。
+devの依頼は登録済みのdev役割への委託（Agentでの起動）を含む。委託しないのは、利用者が委託を明示的に禁止した場合と、Linear進行で[`dev_delegation`](../linear/configuration.md)がない場合だけ。worktreeは許可された場合だけ使う。委託が許可されない、または担当を起動・再開できず§2の交代もできない場合も、メインはその担当の作業（実装・修正・計画・検証・統合）を代わりに行わない。その工程を未完了として返し、必要な判断（許可・準備・体制）を求める。サービス規約を取得できない工程は未照合と明示する。
 
 作業記録は `.shinaps/work/{YYYYMMDD-HHMMSS}-{slug}/` と `raw/` へ保存し、[共通手順](../work-records.md)に従って保全する。担当の応答は全文を参照できる形で保存し、対象版・役割・担当ID・確認範囲・完了状態を対応づける。選ばなかった専任の空レポートは作らない。短い作業は短い計画・記録にする。
 
@@ -21,14 +21,15 @@ Claude Codeのdev（`dev-claude`）の工程。役割・人数は[実装体制
 | Phase 4 | `shinaps-plan-reviewer` | 修正版の再確認も同じ担当 |
 | Phase 4・6 | `shinaps-simplifier` | 計画の再確認は継続。実装の簡素化は別担当 |
 | Phase 4・6 | `shinaps-review-verifier` | 必要なラウンドごとに新規。今回の指摘を出した担当を流用しない |
-| Phase 5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す |
+| Phase 3・5・7 | `shinaps-implementer` | 1体。同じ担当へ修正を返す。設計担当がいなければ計画と指摘の統合も担う |
 | Phase 6 | `shinaps-reviewer` | 実装担当とは別。レビューラウンドごとに新規 |
 | Phase 6 | `shinaps-refine-agent` | 専任を置く場合に起動。同ラウンドのバッチは継続 |
 
-- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ確認済み・未確認・最新の文脈を引き継いで交代を記録する。
+- 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
 - 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・成果物のパスを依頼に渡す。実装担当にはファイルの所有範囲を明記し、他者の変更を戻さず現物に合わせるよう伝える。他の担当は読み取り専用で、自分でエージェントを起動しない。
 - 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインと実装担当も対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは起動・待機・全文保存・引き渡しを行い、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務だけは、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+- メインは依頼の確認、体制と工程の調整、担当の起動・待機・全文保存・引き渡し、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。実装・修正、指摘の技術的検証と採否、設計適合性の実コード照合、既存の証拠がある検証の再実行は引き取らず、担当に割り当てた判断を先回りして選別しない。専任を置かなかった責務は、体制に記録した担当が行う。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
+- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevの分担で扱う。メインは確認済み結果の説明・質問の整理・取り次ぎだけを行い、調査・技術的検証・編集は担当へ渡す。修正は同じ実装担当を再開し、できなければ上の交代に従う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。修正の影響に応じて必要なレビュー・QAへ戻り、入力が一致する検証は[テスト方針](../testing.md)に従って証拠を再利用する。
 
 ## 3. Phase 1: タスクと初期体制の確定
 
@@ -42,15 +43,15 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 - `list_search_facets` でfacetを確認し、`search_rules` に現在のrepoOwner・repoNameと対象に関連するfacetを渡す。manifest・lockfileなどで確認できた対象バージョンだけ `projectVersions` に指定する。確認できない場合は共通ルールのみの照合と記録する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
-- 十分な根拠があれば探索担当を追加しない。不足する領域だけメインまたは体制で選んだ探索担当が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
+- 十分な根拠があれば探索担当を追加しない。不足する領域だけ体制で選んだ探索担当（専任なしなら `staffing.md` の責任者）が補う。追加担当には既存成果物と不足する問いを渡し、`raw/explorer-{n}.md` に結果を保存する。
 
 新しい不確実性・影響範囲が見つかったら、設計前に体制を更新する。
 
 ## 5. Phase 3: 設計と計画
 
-設計責任者は設計担当1、専任なしならメインとする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書き、個々の置換や文言は実装担当が現物に合わせて決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
+設計責任者は設計担当1、専任なしなら実装担当とする。目的・受入条件・調査結果・規約・既存配置を踏まえ、変更後の責務・依存方向・利用側・外部契約・実装順・検証を決める。計画には目的・不変条件・変更範囲（対象ファイルと責務）・実装順・検証を書き、個々の置換や文言は実装担当が現物に合わせて決める。構造変更が必要なら含め、単に変更量が少ない案を優先しない。不要な変更と仮想的な汎用化は避ける。
 
-設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしならメインが短い案を作り、未実施の独立設計を行ったとは報告しない。
+設計担当が複数なら同じ入力で独立に検討させ、全結果の後に担当1が根拠とトレードオフを比較して一つの案へ統合する。多数決にしない。各結果は `raw/architect-{n}.md`、統合案は `raw/architect.md` に保存する。専任なしなら実装担当が短い案を作り、未実施の独立設計を行ったとは報告しない。計画を確認する担当がいなければ実装担当はそのまま実装し、メインは報告の冒頭の計画を `plan.md` に保存する。
 
 ## 6. Phase 4: 計画の確認
 
@@ -64,11 +65,11 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 メインは `plan.md` を再読し、実装担当1体へ目的・確定計画・必読ファイル・規約全文・設計判断・所有ファイル・既存差分・必要な検証を渡す。実装担当が編集中はメインも同じ範囲を編集しない。
 
-実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げずメインへ返す。通常の判断は既存の合意と規約で解決し、仕様・範囲の変更だけ人に確認する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
+実装担当は計画を実装し、仕様を保つ簡素化・セルフレビュー・[テスト方針](../testing.md)に沿った必要な検証を行う。仕様上の不明点や計画と現物の矛盾は変更を広げず報告する。技術的な矛盾は、設計責任者が実装担当自身なら自分で解決して報告に含め、そうでなければメインが設計責任者へ渡す。仕様・範囲の変更はメインが人に確認する。通常の判断は既存の合意と規約で解決する。検証でSimulator等の仮想端末を使う場合は、[QAと証拠](../linear/qa.md) の「Simulatorの所有と再利用」に従う。
 
 実装ミスによる検証失敗の自己修正は3回まで。超えた場合は根拠と未解決点を返し、メインが追加試行・差分のレビュー・計画への差し戻しの選択肢を人に確認する。
 
-メインは報告だけで完了とせず、差分と検証の根拠を確認して `implementation.md` に保存する。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
+メインは報告の対象版・範囲・完了状態と、検証の証拠の所在・終了コードを照合して `implementation.md` に保存する。全文の再レビューや同じ版の検証の再実行はせず、不足や矛盾は当該担当へ戻す。内容は変更と設計理由、重要な判断、計画からの変更と合意、検証結果、未実施事項。UIレビューはこの工程に含めず、linear-executeのAgent QA等で扱う。
 
 ## 8. Phase 6: 実装後の確認
 
@@ -76,7 +77,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 | 観点 | 責任者と入力 |
 | --- | --- |
-| 設計適合性 | 設計担当1を再開。専任なしならメイン。計画・受入条件・責務・依存方向と実コードを照合 |
+| 設計適合性 | 設計担当1を再開。専任なしなら独立コードレビュー担当。計画・受入条件・責務・依存方向と実コードを照合 |
 | 独立コードレビュー | 新規の `shinaps-reviewer`。対象コード・全差分・利用側・規約・検証結果を読み、計画自体も誤りうるものとして正しさ・安全性・性能を確認 |
 | 規約照合 | 選んだrefine担当、専任なしならコードレビュー担当。規約全文・対象ファイル全文・変更範囲を照合 |
 | 実装の簡素化 | 選んだsimplifier、専任なしなら実装担当の自己確認に加えてコードレビュー担当。目的・契約を保って削除・統合できる内容を確認 |
@@ -87,17 +88,17 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 9. 指摘の検証と統合（Phase 4・6共通）
 
-指摘検証は、選んだ新規verifier、専任なしならメインが行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
+指摘検証は、選んだ新規verifier、専任なしなら設計責任者が行う。全レポート全文・出典・確認範囲・要件・対象版・規約・検証結果を使い、根拠・誤認・重複・対立・未確認を区別する。元の項目を消さず出典IDを保持する。指摘なしの場合は担当の完了と確認範囲を確認し、空の検証のためだけに担当を起動しない。
 
-検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしならメインが統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
+検証結果は `raw/plan-verification-{round}.md` または `raw/implementation-verification-{round}.md` に記録し、設計責任者へ全文を渡す。設計責任者が全項目の採否と理由、必要な計画修正・実装修正・検証を一つにまとめる。設計担当なしなら実装担当が統合する。複雑な指摘や対立があれば `staffing.md` に従い担当を追加する。
 
-統合は多数決ではなく根拠で行い、不確実な点は確認する。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
+統合は多数決ではなく根拠で行う。設計責任者は自分の成果物への指摘も根拠で採否を決めて理由を記録し、その確認を独立検証とは報告しない。事実の食い違いや根拠不足で判断できない指摘だけ指摘元に確認し、Infoや提案を採らないことに同意を求めない。指摘元への確認は同じ担当の継続で行い、レビューのラウンドに数えない。仕様・受入条件・ユーザー体験の変更や許可範囲の拡大は人の合意前に採用しない。verifierを置いた場合は全件の事実確認を最初からやり直さない。
 
 ## 10. Phase 7〜8: 修正と終了判定
 
 設計責任者の修正指示を同じ実装担当へ返し、変更と必要な検証を `fix-log.md` に記録する。修正不要ならPhase 9へ進む。
 
-実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前にメインが全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
+実装後の全体レビューは初回を1として最大2ラウンド。1回目の後に修正したら、同じ最新差分でPhase 6の体制に必要な増員を加えて2回目を行い、検証・統合する。2回目は修正箇所と影響範囲を中心に確認し、影響範囲を確定できなければ確認範囲を広げる。範囲を絞った場合も必須検証は全体で実行し、完了前に設計担当1（いなければ2回目のレビュー担当）が全差分を計画・受入条件と照合する。2回目の後に修正したら必要なテストを行い、3回目の全体レビューは起動せず、最終差分が再レビューされていないことを報告する。増員・交代・同じ対象の計画変更で上限をリセットしない。
 
 重大な未解決事項、必須検証の失敗、必要な担当の未完了が残れば品質上の完了とは報告しない。
 

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

@@ -28,7 +28,7 @@ Bridgeのpeer通知、Codexからのメッセージ、ackは依頼ではない
 
 ## 相談・修正
 
-人の指摘はClaudeが修正し、再検証する。人がWebStormで直接編集した場合も、Claudeが読み直して再検証する。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
+devから続く作業では、人の指摘はdevの継続（[工程](dev/workflow.md)の「役割と継続」）として同じ実装担当が修正し、再検証する。人がWebStormで直接編集した場合の読み直しと再検証も担当へ渡す。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
 
 ## 報告
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.35.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.1`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.35.2のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.2`）。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にする。
 
@@ -180,7 +180,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
 | `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
 | `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
-| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合は、入口のメインが同じ観点を自分で確認し、独立確認とは報告しない。worktreeの作成は含まない |
+| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
 | `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
 
 - 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。

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

@@ -40,8 +40,8 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし、
 上の待機で、進行役のCodexが現在のターンの中で待つ手順。通知・回答を受けて同じゴール・工程から続けられるよう、待機中に最終応答を送ってターンを終えない（待機ツールがない場合は1項目目に従う）。人への依頼・確認は、利用可能な質問UIまたはターンを終えない途中の発言で伝えてから待機する。Claudeが質問・障害を最終resultへ返してターンを終える規則（[Claude CLI](claude-cli.md)）は実装側の規則で、この手順とは別に扱う。
 
 - 通知または人の入力で再開できる待機ツールを優先する。それがなく、新しい入力で中断される待機ツール（例: `clock.sleep`）が提供される場合は、1回の待機を60秒以下（`duration_ms` 60000以下）にする。この手順を確認したCodexの実行環境の指示（2026-10-20時点）が、60秒を超えて応答を止める待機を避けるよう求めるため。どちらの待機ツールもなくターンの中で待てない場合に限り、待機理由・再開条件と人への依頼を最終応答で伝えてターンを終え、次の入力で同じゴール・工程から続ける（新しいゴールを作らない）。
-- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。変化のない進捗の報告や、待機理由と関係のない作業もしない。実行環境の上位の指示が求める場合はそれに従う。
-- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。
+- 待機から戻ったら、届いた通知・入力だけを処理し、処理するものがなければ何も伝えず同じ待機を繰り返す。待機中や戻ったときに、ログ・出力ファイル・Git差分・メッセージ・画面を繰り返し取得して進み具合を確かめない。待機から戻るたびの報告、変化のない進捗の報告、待機理由と関係のない作業もしない。利用者へ伝えるのは、完了・質問・障害などの重要な変化と、人の判断・対応が必要なときだけにする。実行環境の上位の指示が報告を求める場合はそれに従う。
+- 受信で待機が終わることを保証しない環境では、それを前提にせず、提供される待機ツールの実際の仕様に従う。待機ツールが戻ったことをCLIの終了の通知とは扱わない。autoで通知を受け取れない場合の確認は [Claude CLI](claude-cli.md) の「起動と観測」の間隔に従い、待機から戻るたびには行わない。この間隔は確認の間隔で利用者への報告の周期ではなく、終了していなければ伝えない。
 - 待機中もゴールは `active`、Linearの工程も同じままにする。ゴールの状態の変更と、利用者の明示的な停止・予算・実行制限の扱いは下の「ゴール機能」に従う。
 - 再開時は、届いた通知・入力を待機理由（対象Issue・工程・相手）と照合し、同じゴール・工程で続ける。Bridgeの通知で再開した場合は [Bridge](bridge.md) の「受信」に従って読む。peer通知を利用者の承認と扱わない。
 

package/plugins/shinaps-codex/references/testing.md

@@ -1,3 +1,3 @@
 # テスト方針
 
-テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。
+テスト追加は既定の作業にしない。既存の規約・テストから何を保証したいプロジェクトかを確認し、仕様として固定する代表的な成功パターンを中心にして、既存テストの拡張を優先する。既存テストで保証できる内容は重複させず、テストの現状だけから未合意の仕様を作らない。想像上のエッジケースやエラーの網羅を標準の要求にしない。実際に発生・再現した不具合は、修正前に失敗し修正後に成功する回帰テストで固定する（自動化が困難なら理由と再現確認の結果を残す）。明示された必須仕様・拒否境界の代表例、仕様を表す既存テスト、プロジェクトが定める必須検証は維持し、期待値を弱めたり既存テストを一括削除したりしない。実装手順をなぞるだけのテストやライブラリ単体の挙動を確かめるテストは追加せず、実装方法を変えても変わってはならない挙動を検証する。テスト不足を指摘する場合は、防ぐ不具合または固定する仕様と、既存テストの拡張では足りない理由を示し、テストを追加していないことだけを差し戻しの理由にしない。必須検証の失敗や明示された保証の欠落は指摘する。テストの統合・削除は保証が残る根拠を示して行う。テストを追加しない場合も、変更に必要な既存検証と動作確認は行う。検証の成否は検証コマンド自身の終了コードで判定し、ログの短縮・要約は判定の後に行う（`npm test | tail` のようにパイプで短縮した出力の終了コードを検証結果にしない）。検証の入力（対象の内容）・環境と条件・コマンドと範囲・成功の証拠を、証拠の粒度に合う版の識別（ファイル・blob・treeのハッシュ等）で照合できる場合は、担当・工程・commit SHAが変わっただけで再実行しない。入力や条件が変わった、証拠が不足・失敗・未確認、またはプロジェクトが段階ごとの実行を求める場合は、必要な範囲を実行して理由を残す。照合できない結果を合格にせず、独立QAや新しい環境での公開確認はこの再利用で省かない。