@shinaps/skills 0.35.3 → 0.36.0

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

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

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

@@ -26,10 +26,24 @@ devと必要な検証が終わったら、作業内容と検証結果を短く
 
 Bridgeのpeer通知、Codexからのメッセージ、ackは依頼ではない。人が自分でcommitした場合は、実コミットを確定単位と照合する。一致すれば人のcommitとして記録し、一致しなければ止める。
 
-## 相談・修正
+## devから続く作業での指摘と修正
 
-devから続く作業では、人の指摘はdevの継続（[工程](dev/workflow.md)の「役割と継続」）として同じ実装担当が修正し、再検証する。人がWebStormで直接編集した場合の読み直しと再検証も担当へ渡す。stage済みの単位では再stageし、上の失効に従う。修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。Linear進行のQA中は人もClaudeも作業ツリーを編集しない。
+devから続く作業（Linear進行を含む）では、人のレビュー中（コミットの開始依頼の後を含む）の指摘を記録・調査・意図確認までにとどめ、編集しない。個々の指摘で修正の工程を起動しない。Linear進行で作業ツリーの編集を止める時点（QA中・途中確認の間）は[担当と工程](linear/workflow.md)の「担当と窓口」に従う。
+
+- 指摘はClaudeの作業記録 `human-findings.md` に記録する。この記録を台帳と呼ぶ。項目は指摘・対象・意図確認・調査結果・状態の5つ。
+- 意図は人へ一問ずつ確認する。調査はdevの分担（[工程](dev/workflow.md)の「役割と継続」）に従って担当へ渡し、メインは編集・修正しない。
+- 人がWebStormで直接編集した内容も記録し、次の修正サイクルの対象に含める。
+
+人が修正を始めることを明示したら、Claudeが修正を始める。固定の文言は求めない。範囲の限定が無ければ未対応の指摘すべてを対象にし、体制を[体制の選択](dev/staffing.md)に従って確認してから、devの修正サイクル（[工程](dev/workflow.md)の「役割と継続」）へ一つの入力として渡す。指摘だけの発話は修正開始としない。曖昧なら一問で確認する。
+
+- CodexのQA中に修正開始が来たら、Claudeは修正開始の依頼を作業記録に残し、QA中であることを人へ伝える。修正サイクルはQAの結果を受けてから始める。QAが不合格なら、Codexの修正依頼と未対応の人の指摘を一つの修正サイクルの入力にまとめる。
+- 修正開始は、コミット開始や単位のコミット依頼の承認ではない。stage済みの単位が変われば、上の失効に従う。
+- コミットの開始依頼の時点で未対応の指摘があれば、修正を始めるか見送るかを一問で確認する。
+
+## 単独の作業での相談・修正
+
+devを経ないcommitでは、相談で行った修正は単位と依頼の目的・範囲内に限り、超えるものは実装の工程へ戻す。stage済みの単位では再stageし、上の失効に従う。
 
 ## 報告
 
-コミットの開始依頼と単位ごとの依頼発話の要約・記録したtree hash・SHA・相談で行った修正とその対応・復元結果を記録し、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-claude/references/linear/bridge.md

@@ -28,7 +28,7 @@
 
 ## 競合の回避と待機
 
-- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない。
+- manualで人とClaudeが作業している間、Codexは同じIssueへ指示を送らない（Claudeが依頼した途中確認への応答を除く）。
 - Codexはゴールを `active` のまま、Claudeの報告の通知を待つ。通知を受けたら「受信」に従って全文を読む。待ち方は [execution.md](execution.md) の「待機の手順（進行役）」に従う。報告の通知を受け取れるかは現物のツールで確認し、受け取れない場合は繰り返しの取得で代えず、下の「Bridgeが必要な工程で使えない場合」と同じく扱う。定期監視は別の依頼なしに始めない。
 - 結果が不明な依頼を重複して送らない（履歴）。重要な判断と結果はIssueへ記録し、Bridgeを唯一の記録先にしない（履歴）。
 - Bridgeの依頼・報告は、利用者の明示的な停止や操作の許可範囲を上書きせず、新しい公開や破壊的な操作の許可を作らない（履歴）。
@@ -38,17 +38,18 @@
 
 | 依頼・報告 | 含めるもの |
 | --- | --- |
-| 実装の依頼（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・既存差分、許可範囲（`dev_delegation` の有無を含む）、通常設定が `ask` の場合は解決したmodeと回答の記録、返信先のCodexの `session_id`、関係する補足と参照先、下の定型文 |
 | 修正の依頼（CodexからClaude） | 実装の依頼の項目に加え、再現手順・期待と実際・対象差分・証拠の場所 |
 | QA結果の引き渡し（CodexからClaude。manualの単位のcommitの依頼ではない） | Issueリンク、対象差分・作業ディレクトリ・branch、Local Agent QAの結果、実効flow・単位の判定記録、返信先 |
-| 完了の報告（ClaudeからCodex） | 体制と途中の増員、対象差分、自動検証の結果、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約、単位案と予定差分、人と決めたこと、人へレビュー待ちと明示したこと |
-| 人の依頼とcommitの報告（ClaudeからCodex） | 対象Issue、作業ディレクトリ・branch、コミットの開始依頼と単位ごとの依頼発話の要約・tree hash・SHA、相談で行った修正、復元結果、残作業 |
+| 途中確認の依頼（ClaudeからCodex） | 開発途中に動作を確かめる依頼。Bridgeで送り、応答を同じセッションで受ける。項目は[途中確認](qa.md#qaの時点対象最終qa)に従う |
+| 完了の報告（ClaudeからCodex） | 体制（必須担当の完了・未完了と合意による未実施を含む）と途中の増員、対象差分、自動検証の結果、確認観点、既知の制限、未解決の事項、devの入口内のレビュー結果の要約、単位案と予定差分、Local Agent QAの後に修正があった場合は変更記録（[qa.md](qa.md#qaの時点対象最終qa)）、未対応・見送りの人の指摘（`human-findings.md` の状態）、人と決めたこと、人へレビュー待ちと明示したこと |
+| 人の依頼とcommitの報告（ClaudeからCodex） | 対象Issue、作業ディレクトリ・branch、コミットの開始依頼と単位ごとの依頼発話の要約・tree hash・SHA、相談で行った修正、修正サイクルで確定した変更、Local Agent QAの後に修正があった場合は変更記録、未対応・見送りの人の指摘（`human-findings.md` の状態）、復元結果、残作業 |
 | 開発進行の引き渡し（ClaudeからCodex） | 利用者からの依頼の内容、対象Issue・Cycle、作業先リポジトリ、利用者が示した範囲と条件。Codexは作業先の設定と照合して進行を始め、不足する判断はCodexから利用者へ確認する |
 
 実装・修正の依頼には次の文を含める。
 
 ```text
-ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。初期体制はあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ返す。
+ユーザー承認済みの範囲でCodexが進行する。この依頼の範囲と受入条件の中では人へ着手を再確認せず、shinaps:dev-claudeで実行する。依頼の体制で進め、BASIC・ULTRAでは追加の担当をあなたが決めて報告する。計画上の判断・仕様の不明点はこのセッションで人へ直接一問ずつ確認し、決定を報告に含める。許可を広げる決定は報告に含めるだけで、Codexが人へ確認する。完了・障害・人の依頼によるcommitの完了は、Bridgeで依頼元のCodexへ返す。
 許可範囲: <設定と会話で許可された操作。dev_delegationの有無を含む>
 ```
 

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

@@ -6,12 +6,12 @@
 
 ## 起動と観測
 
-通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。model・effort・plugin構成を指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
+通常の `-p` は既存の設定・skills・plugins・Agentを読み込む。`--bare` やsafe-modeで省かない。メインのモデルは[経路](configuration.md#経路)のとおり、起動とすべてのresumeで `--model opus` を指定する。resumeで省くと既定のモデルで再開され得るため、毎回指定する。effort・plugin構成は指定して上書きせず、利用者のCLI設定を保持する。Skill/Agentを技術的に呼べることと、その操作の権限が許可されることは別である。
 
 依頼本文を作業記録のpromptファイルへ保存し、stdinで渡す。本文をshellへ展開しない。以下は絶対パスを今回の記録先に置き換え、コマンドのcwdを確定済みcheckoutへ指定して実行する例。毎回異なる出力名を使い、既存記録を上書きしない。必要なSkill/Agent・Read/Edit・検証コマンド等の `--allowedTools` は依頼の許可と範囲から個別に追加する。たとえばcommit段階の `Bash(git add <対象パス>)` と `Bash(git commit -m <確定メッセージ>)` は実際の引数に限定し、初回実装にはcommit権限を渡さない。広範な既存allow設定がある場合も対象外操作の許可とは扱わない。
 
 ```sh
-claude -p --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
+claude -p --model opus --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/request.txt > /absolute/work/result.json 2> /absolute/work/stderr.log
 ```
 
 途中経過が必要なら `--output-format stream-json --verbose` を使い、JSONLへ保存する。シェル実行ツールのprocess/session ID、開始時刻、cwd、Issue、出力パスを記録する。実行中は、実行ツールがprocessの終了を通知する場合はその通知を待つ。通知を受け取れるかは、利用時の実行ツールが実際に提供する機能で判断する。通知を受け取れない場合だけ、起動または前回の確認から5分おきに同じprocessの終了だけを確認する。この5分は確認の間隔で、進行役の1回の待機の長さ（[実行](execution.md) の「待機の手順（進行役）」）とは別に扱い、短い待機から戻るたびには確認しない。終了を待つ間は、stream-json・stderr・出力ファイルなどのログや途中成果を読まない。異常の根拠がある場合と利用者に依頼された場合だけ、必要な範囲で調べる。新しいCLIを並行起動せず、終了したら終了コードを取得して結果を会話へ返す。
@@ -20,18 +20,18 @@ jsonの `session_id`、`result`、`is_error`、`permission_denials` を読み、
 
 ## 依頼・質問・修正・コミット
 
-promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作と起動時に渡す `--allowedTools` の個別エントリ、規約と参照先、返却条件を含める。通常設定が `ask` なら、解決したmodeと回答の記録も含め、Claudeが再質問しないようにする。初期体制はClaudeのメインが材料と現物から決め、体制と理由をresultに含める。linear-executeを再起動せず、実装後は未コミット差分を返してLocal Agent QAを待つ。spec/explore/review/debugの結果も同じ依頼へ渡す。質問・障害は最終resultに返し、Codexが既存合意で回答できれば回答、目的・権限の判断が必要なら人へ一問ずつ取り次ぐ。CLIからBridge送信や人の対話入力を待たせない。
+promptにはIssue、`shinaps:dev-claude`、成果物と受入条件、体制と体制判断の材料、exact cwd・branch・HEAD・既存差分、必須検証コマンドと確かめたツールチェーンの状態、許可・禁止操作と起動時に渡す `--allowedTools` の個別エントリ、規約と参照先、返却条件を含める。通常設定が `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` で別セッションを推測しない。
 
 ```sh
-claude -p --resume '<recorded-session-id>' --output-format json --permission-mode dontAsk --permission-prompts none < /absolute/work/follow-up.txt > /absolute/work/follow-up-result.json 2> /absolute/work/follow-up-stderr.log
+claude -p --resume '<recorded-session-id>' --model opus --output-format json --permission-mode dontAsk --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と回答の記録）を含める。完了報告は体制と途中の増員、変更範囲、検証、未解決事項、単位案、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` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。model・effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
+`review_flow.mode: auto` はClaudeの `--permission-mode auto` を意味しない。非対話起動では `--permission-mode dontAsk` を明示し、既存設定がbypassでも継承しない。effort・pluginsは保持し、操作許可は既存の個別allow設定と今回の範囲に限定する。`--permission-prompts none` は対話できないpromptを拒否として返すためであり、許可を付与しない。permission_denialsがあれば操作と必要な権限を報告し、既存の明示許可が対象を満たすか確認する。満たす場合だけ必要なSkill/Agentや対象を限定した `--allowedTools` を明示し、同じsessionへ明示的に再依頼する。新しい権限が必要ならCodexが人へ確認する。`--allowedTools` を使う場合も対象・操作に限定し、無条件の `Bash(*)`、bypassPermissions、dangerously-skip-permissionsを使わない。拒否を隠すsilent retryをしない。会話上の許可はCLIの権限チェックを消さない。
 
 CLI仕様の参照: [headless](https://code.claude.com/docs/en/headless)、[CLI reference](https://code.claude.com/docs/en/cli-reference)。利用版で必要なflagが非対応なら状態を報告して停止し、権限回避へ切り替えない。

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.35.3のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.35.3`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.36.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.36.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にする。
 
@@ -88,13 +88,17 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 ## 経路
 
-実装・修正・コミットはClaude Codeが `shinaps:dev-claude` と `shinaps:commit` で行う。Codexとの間の経路は、着手時に通常設定の `review_flow.mode` で一つに決める。
+実装・修正・コミットはClaude Codeが `shinaps:dev-claude` と `shinaps:commit` で行う（境界内のUIの微調整はCodexが行える。[担当と工程](workflow.md#codexによるuiの微調整)）。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` |
-| `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 |
+| 通常設定 | 経路 | 必要な許可 | メインのモデル |
+| --- | --- | --- | --- |
+| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli` | Opus。起動とすべてのresumeで `--model opus` を指定する |
+| `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
+| `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
+
+- メインはdevを実行するClaude Codeのセッションを指す。担当（独立レビュー・簡素化を含む）のモデルは役割定義の値で、経路とは独立している。単独のdev（Linear進行を経ないdev）のメインは利用者のセッション設定のまま。
+- manualの対話セッションのモデルは、人が `/model` で切り替える。Claudeへのプロンプトや Bridge のメッセージでは切り替えられない（[model-config](https://code.claude.com/docs/en/model-config)）。
+- manualで基本（Opus）と違う選択なら、Codexが人へ切り替えを依頼する。Codexは人の報告を記録し、実際のモデルを照合できたとは扱わない。
 
 - `ask` では、進行役がClaudeへ依頼する前に、Issueの作業内容と推奨する経路の理由を添えてautoかmanualかを一問で確認し、回答まで着手しない。回答・Issue・作業先・設定・選んだ経路を作業記録に残し、同じIssueの修正・再開・QA・差分確定では再質問せず記録した選択を使う。同じIssueに明示的な既存の選択があれば再質問しない。Cycle全体・バックログ消化でもIssueごとに選ぶ。設定の `ask` は書き換えない。選択は他の許可を増やさず、選んだ経路の許可を確認する。
 - 経路はIssueの途中で切り替えない。`permissions`・`stop_after`・`dev_delegation`・worktreeや別セッションの作成の許可は、経路によって変わらない。
@@ -173,7 +177,7 @@ 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操作を継続的に許可する。下の範囲に従う |
-| `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。既存CLI設定と個別の操作権限を維持する（[手順](claude-cli.md)） |
+| `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の作成と更新 |

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

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

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

@@ -22,13 +22,32 @@ Simulator等の仮想端末は、プロジェクトごとのQA専用端末を作
 - 同じプロジェクトの別の作業が使用中なら、調整して順に使い、占有を奪わない。
 - 自動QAでは端末を不要に前面へ出さず、人の確認が必要なときに対象を表示する。表示やUI操作ツールの制約で他の作業と衝突する場合は、一方的に切り替えず調整する。
 
+## QAの時点・対象・最終QA
+
+Linear進行でpushまでにCodexへ依頼する動作QAは、次の3つの時点だけにする。push後の環境ごとのAgent QAとCycleの全体QAは、各工程の定めに従う。Claude側の検証・独立レビューとCodexのQAは互いの代わりにしない。
+
+| 時点 | 内容 |
+| --- | --- |
+| 途中の目的別確認（以下、途中確認） | 開発途中に実現性や実際の動作を確かめる必要があるとき、Claudeが疑問と確認範囲を明示して依頼する。結果はLocal Agent QAの合格に読み替えない |
+| Local Agent QA | devの完了後の初回QA。不合格後の再QAも初回QAの一部とし、修正の影響で範囲を決めて合格まで続ける |
+| 最終QA | 全コミットの完了後、push前に行う。差分確定中の修正・コミットのたびにはCodexのQAへ戻さず、Claudeが検証・レビューして変更記録を残す |
+
+依頼には、対象リビジョン、変更と影響範囲、既存のQA結果、今回確認したい内容を含める。
+
+- **対象**: 比較元と予定差分を対象とする。対象外の未コミット変更は環境として記録し、対象に含めない。対象外の変更を含む作業ツリーでQAする場合、その影響を比較できなければ全検証にする。対象の識別は `.git` へ書き込まない読み取りで行う。
+- **範囲**: 変更の影響と既存結果の有効性で決め、修正量の大小では決めない。影響を特定できる範囲は重点的に確認し、比較できない、または影響を限定できない範囲は全検証する。結果の再利用は[テスト方針](../testing.md)に従う。
+- **変更記録**: Local Agent QAの後の各修正・各コミットについて、QAに関わる項目（変更内容・影響範囲・既存QA結果との差分・実施した検証とレビュー・単位案と予定差分の更新）を `fix-log.md` に残したもの。
+- **最終QA**: 比較元からのコミット済み差分が、控え（Local Agent QAに合格した時点の比較元と全体差分。[担当と工程](workflow.md)の「単位案からコミット完了まで」で記録する）と一致すれば、根拠を記録して結果を再利用し、一致を確かめたHEADのSHAを最終合格の対象とする。控えは、更新後の全体期待差分（`commit` の照合基準）とは別に扱い、全体期待差分を更新しても書き換えない。一致しなければ、最終的なコミット済み状態を対象にし、変更記録から影響範囲を決めてQAする。比較できなければ全検証にする。Local Agent QAの後に修正サイクルがあれば、報告された体制をLocal Agent QAと同じ基準で照合する。
+- **不合格**: devの修正サイクル（[工程](../dev/workflow.md)の「役割と継続」。[UIの微調整](workflow.md#codexによるuiの微調整)の範囲ならCodexの微調整）、必要なレビュー、既存の承認条件でのコミット、影響範囲の再QAを経て、最終状態での合格を確かめる。
+- **push**: pushするHEADのSHAが最終合格の対象のSHAと一致することを記録してからpushする。一致しない、または確かめられないならpushしない。
+
 ## QAコメントの書式と更新
 
 Codexは各工程のQA結果を、対応するIssueのコメントへ残す。初回と再検証、Local・Staging・Productionを区別する。
 
 ```markdown
 ### <工程・環境> Agent QA — <確認日>
-対象: <Issue・差分またはコミットSHA>
+対象: <Issue・比較元・差分またはコミットSHA>
 環境: <URL・配備版・端末／ブラウザ・ビルド番号>
 
 | 受入条件 | 確認方法・期待結果 | 実際の結果 | 判定・証拠 |

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

@@ -4,15 +4,16 @@
 
 | 担当 | 責務 |
 | --- | --- |
-| Codex（進行役） | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、作業先設定からの経路と許可の確定（askなら人へ一問で確認）、体制判断の材料（受入条件・関連範囲・既存検証・リスク）の提示、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のWebStormでの差分レビュー・修正相談・コミットの開始と単位ごとの依頼、本人の操作が必要な認証等、必要なHuman QA |
+| Codex（進行役） | Issueの作成・整理、仕様相談、Ready判定、依存・Cycle管理、進行判断、作業先設定からの経路と許可の確定（askなら人へ一問で確認）、メインのモデル（manualのみ）と体制の確認と記録、体制判断の材料（受入条件・関連範囲・既存検証・リスク）の提示、Claudeへの依頼（auto: CLI、manual: Bridge）、境界内の[UIの微調整](#codexによるuiの微調整)、Local・Staging・ProductionのAgent QA、単位・全体の照合、許可されたpush・PR・merge・配備・公開、Issueへの記録、人への依頼 |
+| Claude（実装担当・Claude Code） | 追加の担当の判断と途中の増員（BASIC・ULTRA）、`shinaps:dev-claude` による技術調査・計画・実装・検証・独立レビュー、QA指摘の修正、`shinaps:commit`（auto: 独立レビュー後にcommit、manual: 人の開始依頼で分割案、人が依頼した単位ごとにcommit）、結果の報告。実装を伴わない文書整理は、作業先リポジトリの規約に従いdevの入口の対象外にできる。スキル・コードの変更は文書の形でも実装としてdevの入口を使う |
+| 人 | 未合意の仕様・権限の判断、manualのWebStormでの差分レビュー・修正相談・修正開始の明示・コミットの開始と単位ごとの依頼、本人の操作が必要な認証等、必要なHuman QA |
 
 経路は着手時に通常設定の `review_flow.mode` で決まり、askでは着手時の人の回答で決まる（[経路](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合格の根拠にせず、この引き渡しを進行全体の終了と扱わない。
 
 - Issueに関わる人への質問・依頼はCodexが窓口になる。manualでは人がWebStormの対話セッションで直接Claudeと相談する。Claudeは決定事項を報告に含め、CodexがIssueへ記録する。
-- manualで人とClaudeが作業している間、Codexは同じIssueへ追加の指示を送らず、ゴールを `active` のままClaudeの報告を待つ。Claudeの報告後、CodexのQA中は人とClaudeが作業ツリーを編集しない。
-- CodexはQAで見つけた不具合を修正せず、再現条件と証拠を同じClaude sessionへ返す。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
+- manualで人とClaudeが作業している間、Codexは同じIssueへ追加の指示を送らず（Claudeが依頼した途中確認への応答と、[UIの微調整](#codexによるuiの微調整)の人と調整したうえでの一時停止の依頼・返却を除く）、ゴールを `active` のままClaudeの報告を待つ。Claudeの報告の後のCodexのQA中と、Claudeが依頼した途中確認の間は、人とClaudeが作業ツリーを編集しない。
+- 人の指摘は、Codexが窓口としてIssueへ記録する。manualでは、Claudeの報告が台帳（[人のレビュー](../human-review.md)の `human-findings.md`）の未対応・見送りの指摘を伝える。autoでは修正開始の明示を受けたら、未対応の指摘をまとめて同じsessionへ渡す。経路によらず、未対応の指摘があるまま差分確定・pushへ進む前に、人へ一問で確認する。
+- CodexはQAで見つけた不具合を修正せず（[UIの微調整](#codexによるuiの微調整)を除く）、再現条件と証拠を同じClaude sessionへ返す。同じ作業ツリーを同時に編集せず、人や他のAIの変更を保持する。
 
 Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐付けなど）は、Codexが利用可能なブラウザで行う。MCPが対応していないという理由だけで人へ回さない。人の認証や権限が必要な場合だけ人へ依頼する。
 
@@ -22,10 +23,10 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 | 工程 | 状態キー | 内容と次へ進む条件 |
 | --- | --- | --- |
-| 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
-| 実装 | `coding`, `local_agent_qa` | Claudeのメインが初期体制を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合を含む）を行い、不合格なら同じsessionへ戻す |
-| 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼した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・配備・公開。適用しない項目は理由を記録する |
+| 着手 | `ready` | Readyと依存を確認し、作業先設定を読み、通常設定の `review_flow` から経路と必要な許可（auto: `claude_cli`、manual: `bridge_request`）を確定する。通常設定がaskなら、Claudeへの依頼前に作業内容と推奨理由を添えてautoかmanualかを人へ一問で確認し、回答まで着手しない。回答と根拠を作業記録に残し、同じIssueでは再質問しない。依頼の前に `dev_delegation`（または今回の明示依頼）があるかを確かめ、無ければ人へ一問で確認する。経路・メインのモデル（manualのみ。[経路](configuration.md#経路)）・体制（[体制の選択](../dev/staffing.md)）は別の項目とし、指定されていないものだけを推奨とともに一問ずつ確認して記録する。体制は依頼にも書く。checkout・branch・HEAD・既存差分を固定し、体制判断の材料を添えてClaudeへ依頼する。経路がautoでmanualのパス別ルールがあれば、起こり得る停止（[経路](configuration.md#経路)）を依頼に書く |
+| 実装 | `coding`, `local_agent_qa` | Claudeのメインが依頼の体制の担当（BASIC・ULTRAでは追加の担当を含む）を決めて報告し、`shinaps:dev-claude` で実装・検証・独立レビューを行い、未コミット差分・単位案・予定差分・判定記録を返す。manualでは人へユーザーのレビュー待ちと明示する。CodexがLocal Agent QA（判定記録と経路の整合、必須担当の照合を含む）を行う。依頼に書いた体制の必須担当（[実装体制の判断](../dev/staffing.md)）は、完了または合意の記録付きの未実施を合格とする。不合格（必須担当のそれ以外の未完了や代替を含む）なら同じsessionへ戻し、再QAは[初回QAの一部](qa.md#qaの時点対象最終qa)として合格まで続ける |
+| 差分確定 | `code_review` | QA合格後、Codexが実効flow・判定記録・QA結果を同じsessionへ渡し、Claudeが `shinaps:commit` を行う。autoは単位ごとに独立レビュー後にcommitする。manualではCodexはcommitを依頼せず、渡した後は報告を待つ。人のコミット開始依頼でClaudeが分割案を示し、人が単位ごとに依頼したcommitを行う。Codexは各コミットの単位照合と全体照合を行う。差分確定中の実装の修正は、devの修正サイクル（[工程](../dev/workflow.md)の「役割と継続」）で行い、ステータスは `code_review` のままにする。修正やコミットのたびにCodexのQAへ戻さない（[最終QA](qa.md#qaの時点対象最終qa)） |
+| 公開確認 | `post_commit`, `staging_agent_qa`, `staging_human_qa`, `release`, `production_agent_qa`, `production_human_qa` | 受入条件と許可に応じて必要なものだけ行う: push前の最終Agent QAとpushするHEADの照合（[最終QA](qa.md#qaの時点対象最終qa)）、push・PR作成、環境配備とStaging/ProductionのAgent QA、必要なHuman QA、merge・配備・公開。適用しない項目は理由を記録する |
 | 結果報告 | （状態キーなし） | 結果・証拠・省略した工程と理由・残項目をIssueへ記録し、終了地点に到達する。必須受入条件をすべて満たしたIssueは `done` にする |
 
 - `todo`（未着手）・`refinement`（`linear-plan` による仕様整理）・`human_input`（外部対応の待ち）は5工程の外の状態を表す。
@@ -47,7 +48,7 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 全工程に共通する。
 
-- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正はすべて同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い、Codexは再検証だけを行う。
+- **戻し先**: 検証失敗・レビュー指摘・QA不合格・単位照合の不一致は、見つけた担当が直さず原因の担当へ戻す。実装・修正は同じClaude session（autoは同じCLI sessionのresume、manualは同じ対話セッション）で行い（[UIの微調整](#codexによるuiの微調整)を除く）、Codexは[QAの時点](qa.md#qaの時点対象最終qa)に従って再検証だけを行う。
 - **許可**: 操作の前に `permissions`・実効 `review_flow`・今回の明示指示を照合する。許可がなければ許可待ちで止める。これは終了地点への到達ではない。設定の存在だけを合意と扱わない。
 - **Issueの範囲**: 範囲はIssueの目的・変更内容・受入条件から判断する。記載のない作業でも、目的の実現に必要な手段は範囲に含む。仕様や範囲の拡大が必要になったら、進める前に次の「停止と人への確認」に従って確認する。
 - **停止と人への確認**: 設定不備、経路と単位modeの競合、照合の不一致、目的・仕様・受入条件・許可範囲の変更、本人にしかできない操作、根拠を確認しても解消できない報告の矛盾では、安全な状態で止める。確認の担当は経路で決まる。auto経路と、manualで人がセッションにいない間は、Codexが人へ一問で確認する。manualの作業中は対話セッションのClaudeが人へ一問で確認し、決定を報告に含める。新しい許可が要る決定や許可範囲を広げる決定（push・PR・merge・配備・公開・破壊的操作など）は報告では成立させず、Codexが人へ一問で確認する。
@@ -59,8 +60,8 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 | 状況 | 必要な行動 |
 | --- | --- |
 | Codexから許可範囲と受入条件を伴う実装・修正の依頼を受けた | Claudeは人へ着手を再確認せず、指定されたスキルで実行する |
-| devの入口の中で計画上の判断が必要になった | autoはClaudeがresultでCodexへ相談し、Codexは既存の合意で判断できれば回答する。manualはClaudeが人へ直接確認し、決定を報告する |
-| QAで受入条件の範囲内の不具合が見つかった | Codexが同じClaude sessionへ修正を依頼し、Claudeは人の着手許可を改めて取らずに修正する。Codexが再検証する |
+| devの入口の中で計画上の判断が必要になった | autoはClaudeがresultでCodexへ相談し、Codexは既存の合意で判断できれば回答する。manualはClaudeが人へ直接確認し、決定を報告する。[途中確認](qa.md#qaの時点対象最終qa)はこの相談の一種で、autoはresult、manualはBridgeで依頼する |
+| QAで受入条件の範囲内の不具合が見つかった | Codexが同じClaude sessionへ修正を依頼し（[UIの微調整](#codexによるuiの微調整)の範囲ならCodexが直せる）、Claudeは人の着手許可を改めて取らずに修正する。Codexは[QAの時点](qa.md#qaの時点対象最終qa)に従って再検証する |
 | ClaudeがCLIのresultでcommitの完了を、またはBridgeで人の依頼によるcommitの完了を報告した | Codexは人に同じ事実を聞き直さず、報告の対象とGitの状態を照合して次の工程へ進む |
 | 通常設定がaskで、同じIssueの経路を着手時に選んでいる | Codexは修正・再開・QA・差分確定で経路を再質問せず、記録した選択を使う |
 | 次の操作の継続的な許可があり、必要な工程の結果が揃った | Codexは「進めてもよいか」を再質問せずに実行する |
@@ -72,12 +73,27 @@ Linear MCPで扱えない画面操作（添付、並べ替え、Cycleへの紐
 
 単位計画の作成・確認にはコミット許可を要求しない。
 
-1. Claudeは成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。CodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。依頼の比較元と全体差分も最終照合用に記録する。判定記録に経路と異なるmanual単位があれば、差分確定の依頼前に[経路](configuration.md#経路)に従って人へ確認する。
+1. Claudeは成果引き渡しに、モードによらず自然な責務で決めたコミット単位案と予定差分を含める。CodexはLocal Agent QAで対象を検証し、単位案が依頼全体を漏れなく覆い対象外変更を含まないことと、各単位の[判定記録](configuration.md#判定記録と変更時の扱い)を確認する。合格したLocal Agent QAの比較元と全体差分を、最終照合と[最終QA](qa.md#qaの時点対象最終qa)の控えとして記録する。再QAで合格したら記録し直し、全体期待差分の更新では書き換えない。判定記録に経路と異なる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` の手順で正当な人の修正を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
+4. 全単位完了後、Codexは各コミットの単位照合結果を実差分で独立確認したうえで、依頼の比較元からの全体差分が、`commit` の手順で正当な人の修正とdevの修正サイクルで確定した変更を反映した確定済みの全体期待差分と一致し、対象の未コミット変更が残っていないことを照合する。最終差分だけでは途中で混入し後で相殺された対象外変更を検出できないため、単位照合を省かない。人レビューを省略した単位は、上の省略記録を完成させる。
 5. 単位の組み替え・内容・設定の変更は[変更時の扱い](configuration.md#判定記録と変更時の扱い)に従って再判定し、必要なレビュー・許可確認・検証へ戻す。人の依頼によるcommit（または人自身のcommit）の後は、`commit` に従って正当な修正と元の予定差分の対応を記録し、確定単位に更新する。確定単位と実コミットに不一致があれば次工程を止め、SHA・予定差分・実差分の違いを記録して人に確認する。履歴を無断で書き換えない。
 
+## CodexによるUIの微調整
+
+本書と経路の手順にある「Claudeが実装・修正する」規定（戻し先を含む）の例外として、Linear進行に限って、CodexのメインセッションがUIを直接微調整できる範囲をここにだけ定める。Managedには適用しない（作業先が共有されないremote checkoutで、Codexは直接編集できないため）。
+
+- **対象**: iOS・フロントエンドで、画面を見ながら行う方が速いUIの微調整。合意済みの仕様と許可の範囲の内側で、進行役が選ぶ。仕様・アーキテクチャ・データ・契約に関わる変更は対象外とし、通常の相談（Claudeへの修正依頼、または人への確認）へ戻す。
+- **許可**: 依頼・会話・合意済みの設定の対象・操作・範囲で、Codexによる微調整が既に許可されていれば、再確認せず進める。許可が無い場合だけ、必要になった時点で推奨と理由を添えて人へ一問で確認し、回答は同じIssueの中で引き継ぐ。`development_operations` だけから編集の主体の変更を推測しない。別のプロジェクトへ許可を広げない。新しい包括的な権限を加えない。
+- **編集の前**: Claudeのメインと編集中の担当を安全な区切りで待たせる。差分確定中は、単位の退避・stageが無い時点に限る。停止は次の2つで確かめ、auto・manualとも同じに扱う。
+  - Claudeのメインが、実行中の担当（実装担当を含む）が無いことを確かめ、その時点のHEADと変更パスを添えて報告している。autoでは、CLIのprocessが終了してresultを受け取っている。
+  - Codexが編集の前に、報告の状態と現物の `git status` が一致することを確かめる。
+
+  実行中のCLIは終了を待つ。止める必要があるときは、session ID・差分・作業記録を保持し、再開する工程を記録してから止める。manualで人が作業中なら、無断で介入せず人と調整する。同時に編集しない。
+- **編集**: 画面を確認しながら、対象のUIファイルだけを編集する。stage・commit・indexの操作はしない。Codex独自の設計体制や独立レビューは置かない。
+- **返却**: 変更したパスと差分、理由、視覚確認の結果（証拠の所在）、未確認事項を、同じClaudeセッションへ返し（autoは終了したprocessのsessionのresume、manualはBridge）、Issueにも記録する。
+- **Claude側**: 現在の工程の差分として取り込み（実装担当が読み直して `fix-log.md` に記録する）、必要な検証を行って既存のレビューを続ける（[工程](../dev/workflow.md)の「役割と継続」）。全体レビューの回数はリセットしない。Local Agent QAより前の変更はそのQAの対象に含め、QAより後の変更は[変更記録](qa.md#qaの時点対象最終qa)として最終QAへ集約する。QAを追加で起動しない。
+
 ## 待ち状態
 
 その場の質問と、本人が対応できるレビュー・作業の待ちは、元の工程を維持する。外部の資料提供・権限付与・審査など、自分たちでは解消できない対応の待ちだけを `human_input` で表す。別Issueの待ちは依存関係、Claudeの作業待ちはAI間の待機として扱う。

package/plugins/shinaps-claude/references/managed/execute.md

@@ -1,12 +1,12 @@
 # Managed Agents への依頼と観測
 
-作業先の設定を読み、Claude Managed Agents の lead `shinaps-dev-managed-cc` へ dev を依頼し、進み具合の観測・質問の取り次ぎ・成果物と draft PR の確認を行う手順。計画・実装・レビューの工程と体制は lead が [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) に従って決めるので、ここでは指示しない。
+作業先の設定を読み、Claude Managed Agents の lead `shinaps-dev-managed-cc` へ dev を依頼し、進み具合の観測・質問の取り次ぎ・成果物と draft PR の確認を行う手順。体制は合意する入力として渡す。計画・実装・レビューの工程と追加の担当は lead が [skill `dev-managed-cc`](../../managed-agents/skills/dev-managed-cc/SKILL.md) に従って決めるので、ここでは指示しない。
 
 ## 呼び出し時に合意する入力
 
 設定からは読まず、依頼のたびに利用者と合意する。
 
-- 必須: base ブランチとその SHA、head ブランチ、範囲と受入条件、許可（commit・head への push・draft PR の作成のうち明示されたもの）、予算（USD のセント単位）
+- 必須: base ブランチとその SHA、head ブランチ、範囲と受入条件、体制（LITE・BASIC・ULTRA。[体制の選択](../dev/staffing.md)に従い推奨を添えて確認する）、許可（commit・head への push・draft PR の作成のうち明示されたもの）、予算（USD のセント単位）
 - 任意: 必須検証のコマンド、コミットの author、利用者 CLAUDE.md の添付
 
 設定から読むのは `definitions`（lock の場所）・`repository`・`vault_id` だけで、lead と環境の ID は lock から読む（[設定](configuration.md)）。許可と予算は合意した内容だけで、会話の途中で増やさない。
@@ -52,6 +52,7 @@ initial_events:
           base: <ブランチ> @ <SHA>
           head: <ブランチ名>
           範囲と受入条件: <内容>
+          体制: <LITE|BASIC|ULTRA>
           許可: <commit・headへのpush・draft PRの作成のうち許可するもの>
           予算: <金額>
           必須検証（任意）: <コマンド。省略時はリポジトリの規約に従う>
@@ -105,7 +106,7 @@ unset GITHUB_TOKEN
 
 ## 6. 終了する
 
-状態行、取得した出力ファイル、コミット、push 先、PR の URL、未検証の事項を報告する。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。QA は呼び出し元が別に行う。
+状態行、取得した出力ファイル、コミット、push 先、PR の URL、未検証の事項を報告する。merge・deploy・release・Issue の更新・セッションのアーカイブは行わない。QA は呼び出し元が別に行う。完了後に修正する場合は、新しい依頼として、体制を含めて合意し直す。
 
 ## 未検証の境界
 
@@ -114,3 +115,4 @@ unset GITHUB_TOKEN
 - GitHub MCP で draft PR を作れるか。`draft: true` は lead への指示でしか担保されない。
 - vault に資格情報を登録できたことは、上の3点の確認にならない。
 - `events send` による回答の送信は、本文の構造を API 仕様で確かめただけで、実際のセッションではまだ送っていない。出力ファイルの一覧と取得は既存のセッションで確かめた。
+- 完了したスレッドが同時実行の枠（25本）を空けるか。ULTRAでは、ラウンドごとに新しく起動する担当を含めて、同時に保つスレッドが多い。