@shinaps/skills 0.48.0 → 0.50.0

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

@@ -13,10 +13,10 @@ devの体制はLITE・BASIC・ULTRAの3段階で、作業ごとに人が選ぶ
 | 調査・設計・計画 | メイン（短い計画と検証方針） | メイン | メインが自案を保存した後、独立設計担当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名の範囲に属するようにする。
-
 ## 記録と引き渡し
 
 設計を始める前に、選んだ体制、追加した担当とその根拠、工程ごとの役割・人数・確認範囲、技術領域ごとに担当を置く場合はその割り当て、必須検証を短く記録する。独立した担当は、実装したメインとは別のコンテキストにする。

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

@@ -22,10 +22,10 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 | Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
 
 - 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合（resumeをまたぐ場合を含む）は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
-- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
-- 独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず意見交換させない。継続担当には前回の確定済み指摘と採否を渡してよい。対象を編集中にレビューせず、全結果が揃うまでメインは対象を変えない。外部変更が入れば影響範囲を同じ最新の版で確認し直す。
-- メインは、依頼の確認、体制と工程の調整、調査・設計・計画の統合・実装・検証・修正、指摘の検証と採否、修正計画、担当の起動・待機・全文保存、結果と未解決事項の取りまとめ、利用者判断の取り次ぎを行う。体制が求める独立確認（独立案・計画の独立確認・実装後の独立レビュー）をメインの自己確認で代えない。起動失敗・空回答・未確認範囲を「指摘なし」にしない。
-- devの完了後に同じ会話・sessionで来る依頼（対話の次のターン、resume、Bridge、人の相談、QA差し戻し）も同じdevとして扱う。質問への回答と人の指摘の調査は、メインが読み取りだけで行い、編集は修正サイクルで行う。初回devの完了・短い追加依頼・通常の会話への復帰を例外にしない。Codexが[UIの微調整](../linear/workflow.md#codexによるuiの微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
+- 目的・範囲・規約全文（Phase 6の照合では読むファイルの指定）・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
+- 計画の確認と実装後の確認に、[レビューの共通契約](../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の扱いで再確認する。
@@ -35,13 +35,15 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 
 ## 3. Phase 1: タスクと体制の確定
 
+依頼に「規約の適用結果を記録しない」があれば、この時点で[作業記録へ書く](../rules.md#適用結果を記録する)。
+
 依頼・引数・指定された成果物から目的・受入条件・範囲を確定する。確定済みの内容を聞き直さず、依頼されていない過去の作業を始めない。成果物に実装可否の状態があればreadyを確認し、欠落・不明なら変更内容を推測せずタスクを確定する。内容ハッシュがある根拠は現在値と照合し、古い根拠は読み直す。
 
 Issue・既存spec・調査記録・関連コード・検証方法を必要な範囲だけ確認する。依頼に書かれた体制（無ければ[体制の選択](staffing.md)に従って確認する）の担当で進め、BASIC・ULTRAではlinear-executeから受けた材料と現物からメインが追加の担当を決める。設計を始める前に、[体制](staffing.md)の「記録と引き渡し」の項目を作業記録の `staffing.md` へ保存し、短く報告する。不足する調査があればPhase 2で補い、体制を更新する。
 
 ## 4. Phase 2: 規約と必要な探索
 
-規約はメインが取得し、以降の担当へ全文を渡す。担当はShinaps MCPを呼ばない。
+規約はメインが取得する。担当はShinaps MCPを呼ばない。Phase 3・4の担当へは全文を渡し、Phase 6の照合の担当へは[snapshot](../rules.md#照合のために取得する)を読ませる。
 
 - [Shinaps規約の取得](../rules.md)に従い、対象に関連するfacetで一覧を取り、必要な全文を取得する。
 - プロジェクト規約と関連docs、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
@@ -84,35 +86,15 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 8. Phase 6: 実装後の確認
 
-同じ差分を固定し、選んだ体制の担当と追加した担当を `shinaps-reviewer` で並行して起動する。依頼するレビューの種類は体制ごとに次のとおり。設計適合性（計画・受入条件・責務・依存方向と実コードの照合）は、独立コードレビューの種類の中で毎回依頼する。
-
-| 体制 | 担当と依頼するレビューの種類 |
-| --- | --- |
-| LITE・BASIC | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない |
-| ULTRA | A: 新規の1名に、独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する |
-
-- 独立コードレビューには、対象コード・全差分・利用側・規約・計画・検証結果を渡し、計画自体も誤りうるものとして確かめさせる。
-- 規約照合には、規約全文・対象ファイル全文と、変更範囲の確認コマンド（`git diff HEAD -- <path>`。未追跡のファイルは全行を今回の変更とする）を渡す。
-- 可読性・慣習レビューには、担当する範囲の差分と対象ファイルの現状全文、規約、計画に記した先例、合意済み仕様を渡す。
-- 技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属することを確かめ、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
+[レビューの共通契約](../review.md)に従い、同じ差分を固定して、選んだ体制の担当と追加した担当を並行して起動する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは `git diff HEAD -- <path>` を渡す。
 
-変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。staged・unstaged・untrackedを含めて対象を特定し、新規ファイルも確認する。
+固定した対象について、[Shinaps規約の取得](../rules.md)の「照合のために取得する」で領域ごとに snapshot を作る。`checks` があれば、担当へ渡す前に[規約の機械検査](../lint.md)の「照合で使う」を行い、「担当へ渡す」の依頼文で読ませる。
 
-結果を `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 +106,12 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 ## 11. Phase 9: 完了と引き渡し
 
-選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。規約照合の種類を依頼しない体制（BASIC・LITE）では、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。修正サイクルの後は、初回の報告項目を最新にし、対応した指摘と採否・再実施した工程・[変更記録](../linear/qa.md#qaの時点対象最終qa)を加える。
+全指摘の採否が確定したら、[規約の適用結果](../rules.md#適用結果を記録する)を既定で記録する（作業ごとにOFFにできる。失敗は未記録として報告し、完了の判定を変えない）。
+
+選んだ体制・追加した担当と変更理由、実際の担当・確認範囲と必須担当の完了状況（合意による未実施を含む）、計画と実装後のレビュー回数、採否・修正（退けた Critical・Warning と、欠陥を示す Info・提案の件数と根拠の場所、人の判断で解決した件数と判断の記録の場所、既存箇所の指摘の件数を含む）、検証結果、未実施・未照合・未解決事項を報告する。機械検査の組の状態ごとの数と実行できなかった理由、`rule-coverage` の未確認の規約・ファイル、規約照合の種類を依頼しない体制（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進行・新しいゴールを必須にしない。
 
-explore・spec・review・debugからの成果物は入口の引数で直接渡す。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。
+explore・spec・review・debugからの成果物は入口の引数で直接渡す。reviewから渡された指摘は修正サイクルの入力とし、体制が渡された場合はその体制で進める。専用の引き継ぎファイルは作らず、Phase 1・2で既存成果物を再利用する。

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

@@ -2,6 +2,8 @@
 
 通常設定が `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#経路)に従う。
 
 ## 起動と観測

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.48.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.48.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.50.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
 0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 

package/plugins/shinaps-claude/references/lint.md

@@ -6,13 +6,13 @@ Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配
 
 ## 照合で使う
 
-[Shinaps規約の取得](rules.md)で全文を取得した後、照合の担当へ渡す前に行う。
+[Shinaps規約の取得](rules.md)の「照合のために取得する」で snapshot を作った後、照合の担当へ渡す前に領域ごとに行う。
 
-1. 全文の `checks` を持つ規約を、`{ "rules": [{ "id": "<規約id>", "checks": [<全文のchecksのまま>] }] }` の形で作業記録の下（例: `.shinaps/work/<作業>/lint-checks.json`）に書く。checksを書き換えない。持つ規約が無ければこの節を省く。
-2. 対象ファイル（照合の対象として確定したもの。削除されたファイルを除く）を付けて1回実行する。
+1. snapshot の `lint-checks.json` を使う。`rule-snapshot` が応答の `checks` から生成したもので、手で写したり書き換えたりしない。`rules` が空ならこの節を省く。
+2. 領域の対象ファイル（照合の対象として確定したもの。削除されたファイルを除く）を付けて1回実行する。
 
    ```sh
-   shinaps-skills lint --checks <lint-checks.json> --root <リポジトリのルート> --out <lint-result.json> -- <対象ファイル...>
+   shinaps-skills lint --checks <snapshot>/lint-checks.json --root <リポジトリのルート> --out <lint-result.json> -- <対象ファイル...>
    ```
 
    コマンドが無い、終了コードが0でない、または結果を読めないときは、全ての規約をAI照合に回し、理由を報告する。CLIは利用中のスキルと同じ版を使う。
@@ -22,7 +22,8 @@ Shinaps AIの規約は、機械検査（`checks`）を持てる。検査は配
    - `partial`: 一部だけを検査する検査だけが実行された。`findings` を指摘にし、規約はそのファイルの照合に残す（担当にはlintの指摘も渡す）。
    - `not-run`: 実行していない（対象外、この版に無いルール、ESLintが設定を拒否した、型が得られない、致命的な報告など）。照合に残し、`reason` を記録する。
 4. lint由来の指摘は、根拠に規約idとルールID（`findings[].rule`）を付けて集約に入れる。誤報告がありうるので自動修正にせず、メインがその位置を読んで確認してから扱う。
-5. 報告に、状態ごとの組の数、`not-run` の理由、`units[].error` を書く。照合から外した組を「AIが照合した」と書かない。
+5. 結果は `checksSha256` とファイルごとの内容のhashを持つ。`rule-coverage` はこれで、別の snapshot の結果と、実行の後にファイルが変わった結果を拒否する。
+6. 報告に、状態ごとの組の数、`not-run` の理由、`units[].error` を書く。照合から外した組を「AIが照合した」と書かない。
 
 ## 検査を登録・更新する
 

package/plugins/shinaps-claude/references/request-scope.md

@@ -15,7 +15,7 @@
 
 依頼範囲の内側で到達点へ進むために必要な操作は、操作ごとの許可を求めずに行う。到達点を越える操作は依頼範囲を広げる操作として、下の「確認する操作」に従う。
 
-通常操作には、ローカル環境の準備と依存の導入、開発・検証、Issueの更新、Claude CLIの起動と同じsessionの再開、devの既定の経路（登録済みの役割）での委託、隔離のためのworktree、stage・commit、push、PRの作成・更新、マージ、指定された先への配備・公開を含む。操作の前に、必要なレビュー・QAなどの前工程が揃っていることを確かめる（下の「工程の条件」）。
+通常操作には、ローカル環境の準備と依存の導入、開発・検証、Issueの更新、Claude CLIの起動と同じsessionの再開、devと `review` の既定の経路（登録済みの役割）での委託、隔離のためのworktree、stage・commit、push、PRの作成・更新、マージ、指定された先への配備・公開を含む。操作の前に、必要なレビュー・QAなどの前工程が揃っていることを確かめる（下の「工程の条件」）。
 
 一つの操作に伴う副作用も、目的・対象・到達点・制約の内側にあることを確かめる。たとえばマージをきっかけに本番へ自動で配備される場合は、その配備まで依頼範囲に含まれている必要がある。含まれていなければ、その操作の前で止まる。
 

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

@@ -0,0 +1,58 @@
+# 単独レビューの手順
+
+`review` を単独で起動するときの、実行環境によらない手順。担当の構成・対象の固定・担当へ渡すもの・独立性・機械検査・完了の判定・指摘の採否・報告は[レビューの共通契約](review.md)に従う。担当の起動と修正の引き継ぎ先は実行環境ごとに `review` のスキルに書く。
+
+利用者が明示して起動したレビューはdevの工程とは別の作業で、同じセッションでdevが完了した後でも、devの体制とレビューの回数を引き継がない。
+
+## 1. 対象
+
+依頼された対象を、追跡状態によらず全て確認する。体制・種類・到達点の語（「修正まで」など）を除いた引数を次の順に判定する（残らなければ指定なし）。
+
+1. 数字またはPRのURLならPR。
+2. 存在するパスならパス。
+3. `..` を含むなら範囲。ローカルまたはリモート追跡のブランチ名なら、ベースブランチからそのブランチまでの範囲（`<base>...<ブランチ>`）。それ以外で `git rev-parse --verify <引数>^{commit}` で解決できるなら単一のコミット。
+4. どれでもなければ、対象を一問で確認する。
+
+| 対象 | 固定する版 | ファイルの列挙 | 変更範囲の確認コマンド |
+| --- | --- | --- | --- |
+| PR | `gh pr view <番号> --json baseRefOid,headRefOid` の head のSHA（ローカルに無ければ fetch する） | `git diff --name-only <base のSHA>...<head のSHA>` | `git diff <base のSHA>...<head のSHA> -- <path>` |
+| 単一のコミット（最初のコミットとマージコミットを含む） | そのSHA | `git show --format= --first-parent --name-only <SHA>` | `git show --format= --first-parent <SHA> -- <path>` |
+| 範囲 | 両端のSHA | `git diff --name-only <範囲>` | `git diff <範囲> -- <path>` |
+| ファイル・ディレクトリ | HEADのSHAと内容のハッシュ | 下の「パスの列挙」 | 無し（範囲判定なし） |
+| 指定なし | merge-base のSHA、HEADのSHA、内容のハッシュ | `git diff --name-only <merge-base のSHA>` と `git ls-files --others --exclude-standard` の和 | `git diff <merge-base のSHA> -- <path>` |
+
+指定なしの場合、merge-base はベースブランチとHEADから1回だけ解決し、解決したSHAをコマンドに書いて担当へ渡す（コミット済みと未コミットの変更を今回の変更として判定するため）。差分を対象にして差分が空なら、差分が無いと報告して止まる。削除されたファイルは列挙から外す。ファイル数で対象を減らさない。
+
+作業ツリーがその版でなければ、その版の一時worktreeを作って担当と機械検査に読ませ、終わったら取り除く。
+
+### パスの列挙
+
+指定された各パスについて、追跡中と未追跡のファイルを `git ls-files --cached --others --exclude-standard -- <path>` で列挙し、存在するものを対象にする。
+
+- 明示されたパス自体が ignore 対象なら、ファイルシステムから列挙して対象にする。
+- 指定したディレクトリの中で一部だけ ignore されて対象から外れたものは `git ls-files --others --ignored --exclude-standard --directory -- <path>` で確かめ、未確認の範囲として報告する。
+- Gitの作業ツリーの外なら、ファイルシステムから列挙する。
+
+## 2. 体制
+
+依頼に書かれていれば聞き直さない。種類が限定されていれば、体制を聞かず契約のとおりの人数で行う。どちらも無ければ[実装体制の判断](dev/staffing.md)の「推奨の目安」に沿った推奨と理由を添えて、LITE・BASIC・ULTRA を一問で確認する。
+
+## 3. 記録
+
+記録は `.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{対象}/` に置き、[作業記録の共通手順](work-records.md)に従う。`input.md` に対象・固定した版・列挙したファイル・体制を書き（依頼に「規約の適用結果を記録しない」があれば[作業記録へ書く](rules.md#適用結果を記録する)）、担当の応答は全文を `raw/review-{round}-{n}.md` に保存し、全指摘の採否を `findings.md` に書く。関連する既存の spec・調査記録があれば要約して担当へ渡す。
+
+## 4. 規約と機械検査
+
+[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
+
+## 5. 検証と報告
+
+契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
+
+## 6. 到達点
+
+依頼に修正まで含まれていなければ、報告で終わる。対象のファイルの修正・コミット・PRへの投稿・公開をしない（規約の適用結果の記録は本人のShinaps AIの集計だけに書く）。
+
+- **修正**: 明示的に修正まで依頼された場合、採用した指摘が1件以上あれば、指摘（`findings.md` のパスと本文）・固定した版・選んだ体制（選んでいれば）・依頼範囲と制約・`rule-outcomes.json` の値を開発の担当へ渡す。作業ツリーが固定した版でなければ（別のブランチのPR、過去のコミットなど）、修正する場所を先に一問で確認する。開発の担当がdevの修正サイクルで修正と再レビューを行い、未コミットの差分を返す。採用した指摘が無ければ引き継がず報告で終わる。コミット・PR・公開は、それぞれ依頼に含まれている場合だけ別の工程で行う。
+- **PRへの投稿**: 明示的に依頼された場合だけ、本文を確認してから投稿する。
+- **規約の登録・更新**: 利用者がその場で依頼した場合だけ、[Shinaps規約の書き方](rule-writing.md)に従って行う。指摘から自動で登録しない。

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

@@ -0,0 +1,70 @@
+# レビューの共通契約
+
+実装後の差分や既存のコードを独立してレビューするときの、担当の構成・対象の固定・完了の判定・指摘の採否を定める。devの実装後レビューと単独の `review` が同じ契約を使う。種類ごとの作業手順は `shinaps-reviewer` の定義にある。規約の取得、質問の経路、担当の起動方法、作業記録の場所、修正の進め方は呼び出す入口の手順に従う。「メイン」はレビューの結果を統合するセッション（Managed では lead）を指す。
+
+## 担当の構成
+
+担当はすべて `shinaps-reviewer` で起動し、次の種類を依頼する。
+
+| 体制 | 担当と依頼するレビューの種類 |
+| --- | --- |
+| LITE | 新規の1名に、独立コードレビュー（設計適合性を含む）・可読性・慣習レビュー・実装の簡素化を依頼する。規約は独立コードレビューの rule 観点で照らし、規約照合の種類は依頼しない。担当は追加しない |
+| BASIC | LITE と同じ1名を下限に、不確実性・影響範囲・失敗時の影響から担当を追加できる |
+| ULTRA | A: 新規の1名に、対象全体の独立コードレビュー（設計適合性を含む）・実装の簡素化を依頼する。B: 技術領域ごとの1名に、規約照合・可読性・慣習レビューを依頼する。必要な担当を追加できる |
+
+依頼が種類を限定している場合（規約照合だけ、簡素化だけなど）は、限定された種類だけを依頼する。担当は1名とする。ただし ULTRA を同時に指定され、限定された種類に規約照合または可読性・慣習レビューが含まれるときは、その種類を技術領域ごとに1名へ依頼する。
+
+技術領域は、Web・API・iOSのように技術や実装慣習が違う領域とする。配布先・写し・文書の分類は、別の技術領域に数えない。技術領域ごとに担当を置く場合は、全変更ファイルがちょうど1名の範囲に属するようにし、足りない技術領域があれば担当を足す。複数担当なら確認範囲を明記し、重大な契約の独立確認を分担だけで置き換えない。
+
+## 対象の固定
+
+- レビューの前に対象の版を固定して記録する。コミットはSHAで、未コミットの変更はHEADのSHAと追跡・未追跡ファイルの内容のハッシュで識別する。全文・差分・機械検査は同じ固定版を読む。作業ツリーが固定版でない場合（別のブランチのPRなど）は、担当と機械検査がその版の一時worktreeを読む。
+- 全結果が揃うまで対象を変えない。外部の変更が入ったら、影響範囲を同じ最新の版で確認し直す。
+- 変更を対象にするときは、staged・unstaged・untrackedのうち対象に含まれるものを特定する。未追跡のファイルは全行を今回の変更とし、削除されたファイルは全文の照合と機械検査から外す。
+- 変更範囲の確認コマンドは、入口が対象に合わせて決めて担当へ渡す。既存のコードを変更と関係なく対象にするときは「範囲判定なし」と渡す。
+
+## 担当へ渡すもの
+
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
+- 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
+- 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
+- 実装の簡素化: 目的、維持する外部契約、対象コード、計画。
+- 指摘の検証: 元の対象、検証する指摘の全文、確認範囲、外部調査があればその結果。
+
+## 独立性
+
+独立確認する担当には同じ版の入力を渡し、今回の他担当の結果を読ませず、意見を交換させない（指摘の検証の担当は、検証する指摘だけを読む）。担当は読み取り専用で、修正・追加の委託・コミット・公開をしない。担当を起動できない場合は、その担当を未完了とし、メインの確認を独立レビューとは報告しない。
+
+## 機械検査
+
+規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
+
+- 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
+- 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
+- 機械検査の指摘は、メインが該当位置を読んで確かめてから、他の指摘と同じ基準で扱う。
+- 実行できない場合は全ての規約をAIの照合に回し、理由を報告する。
+
+## 完了の判定
+
+未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。入口の手順が規約の報告の形を指定したときは、その報告が無い担当の範囲を未確認にする。指摘なしの担当は、完了と確認範囲を確かめる。
+
+担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で完了を判定する。未照合の規約は、特定できる単位（例: id・topic）で報告する。対象が大きい場合は、件数を理由に対象を減らさず、関連するファイルをまとめて同じ担当へ分けて渡し、分けた範囲をまたぐ契約は統合のときに確かめる。担当を再開できない場合は、確認済みと未確認の範囲を後任へ引き継いで交代を記録する。
+
+## 指摘の検証と統合
+
+メインが全レポート全文・出典・確認範囲・要件・対象の版・規約・検証結果を使い、全指摘を整理する。各指摘に担当・ラウンド・項番の出典IDを付け、実コード・利用箇所・計画・規約から根拠や反証を確かめ、根拠・誤認・重複・対立・未確認を区別する。同じ原因・影響・修正方針の指摘だけまとめ、元の項目と重要度を消さない。外部の仕様が判断を左右する指摘は、公式情報で確かめる。
+
+全項目の採否と理由、必要な修正と検証を一つにまとめる。統合は多数決ではなく根拠で行う。メイン自身の確認を独立検証とは報告しない。
+
+- 今回の対象（変更を対象にしたときは今回の変更とその影響範囲。範囲判定なしのときは指定された対象全体）にある次の指摘は、修正で解消するか事実（file:line・コマンドの結果）で反証するまで、退けたり消したりしない。
+  - (1) Critical・Warning の指摘（例: 今回の変更の規約違反、正しさ・契約・設計適合性の欠陥）。
+  - (2) 重要度・種類（Info・簡素化の提案）によらず、確認対象（計画またはコード）の正しさ・契約・設計上の欠陥を示す指摘。
+  - (1)・(2) のどちらも、修正案だけを退ける場合は、その欠陥をどう解消するか、またはその欠陥が成り立たない根拠を書く。前回の採否（人が決めた判断を除く）は退ける理由にならない。仕様を変えなければ解消できない欠陥は、入口の経路で利用者に確認し、利用者の判断を記録した時点で解決とする。
+- 事実で決まらない対立と、根拠不足で判断できない指摘は、同じ担当の継続で指摘元に確認する（レビューのラウンドに数えない）。解消しなければ未解決とし、品質上の完了にしない。
+- 変更を対象にしたときの既存箇所（今回の変更と無関係な箇所）の規約違反と欠陥は、「既存箇所の指摘」として別の一覧で報告し、完了を止めない。
+- 欠陥を示さず、好み・任意の改善に留まる Info と提案は、採らない理由を記録するだけで同意を求めない。仕様・受入条件・ユーザー体験の変更や、依頼範囲・許可の拡大は、利用者の合意前に採用しない。
+
+## 報告
+
+固定した版、体制と担当、確認範囲と完了状態、全指摘の対象箇所・発生条件・影響・修正案と採否・根拠、既存箇所の指摘、機械検査の組の状態ごとの数と実行できなかった理由、未照合の規約、未確認の範囲、未解決の事項を報告する。推測と確認済みの事実、実施した検証と未実施を区別する。独立コードレビューを依頼し規約照合の種類を依頼しなかった場合は、規約を独立コードレビューの中で照らし、ファイルごとの完了一覧が無いことを書く。どちらも依頼しなかった場合は、規約を照合していないと書く。

package/plugins/shinaps-claude/references/rule-writing.md

@@ -2,6 +2,8 @@
 
 Shinaps AIへ個人規約を登録・更新するときの書き方。短さそのものではなく、1回読めば判断と行動が分かることを目的にする。
 
+規約の登録・更新は、利用者がその場で依頼したときだけ行う。レビューの指摘などから自動で登録しない。
+
 ## 1件1判断
 
 1件には1つの判断だけを書く。別々に適用・変更できる判断は分ける。
@@ -75,3 +77,10 @@ coding の規約は、使えるlintのルールで検査できるかを判断し
 | `examples` の good・bad | 各300字、15行 |
 
 上限はサーバーが入力を拒否する値で、目標ではない。値はMCPツールの入力の説明に従う。超過はエラーになり保存されないので、切り詰めずに書き直す。record_rulesは1件でも超えると全体が保存されない。
+
+## 書き込みのエラー
+
+- `RULE_TOO_LARGE`: その呼出し分は全体として保存されていない。details の limit・actual・title を確かめ、該当する本文・例を短くしてから同じ呼出しをやり直す。
+- `RULE_UPDATE_CONFLICT`: 全文を読み直してから再試行する。
+- `RULE_LIMIT_REACHED`: 書き込みを止める。残りの枠が足りない `record_rules` はその呼出し分が全体として保存されない（それより前の呼出しの分は保存されている）。details の `limit` と `actual` から残りの枠を示し、件数を絞るか既存の規約を整理するかを利用者に確認する。
+- `RATE_LIMITED`: 制限の時間枠が切り替わるまで待ってから、同じ呼出しを1回だけ再試行する。再び拒否されたら中断して報告する。

package/plugins/shinaps-claude/references/rules.md

@@ -1,6 +1,6 @@
 # Shinaps規約の取得
 
-Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当へは全文を渡す。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の順に全件を辿る。
+Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メイン）だけが行い、担当はMCPを呼ばない。対象ファイルが確定した規約照合の担当には、[照合のために取得する](#照合のために取得する)で保存した同じ snapshot を読ませる。保存できる規約は必ず1応答に収まり、1応答は100件かつ32,000 bytes（MCPのcontent textのUTF-8）までに分かれるので、下の順に全件を辿る。
 
 ## 語彙を確認する
 
@@ -10,7 +10,7 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 対象の技術を選ぶ
 
-対象ファイルが確定した照合（`refine`・`review`）は、ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
+対象ファイルが確定した照合（`review`）は、対象全体を規約と広く照らすので `kind` で絞らない（絞ると見落としが増える）。ファイルごとに `languages`・`platforms`・`frameworks` の各軸を「確定（slugの集合。空でもよい）」か「不明」に判定する。
 
 **確定と言えるのは、そのファイルに当てはまる規約のその軸のlabelが、必ずその集合に入るときだけ。** サーバーは指定した軸のどれか1つでも不一致の規約を除くので、この条件が満たせない軸は不明にする。
 
@@ -21,6 +21,8 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - **語彙外の技術**: 語彙のslugと同じ役割なら不明にする（Prisma、Kotlin、Android、Nodeのサーバー、フレームワークなしのサーバー実装、生SQLなど。類似のslugで置き換えない）。役割が重ならない補助ライブラリは数えない。
 - 辿っていない・確かめられない軸は不明にする。
 
+**領域**: 技術や実装慣習が違う領域（Web・APIなど）が複数あるときは、領域ごとにこの判定と合成を行い、取得も領域ごとに行う。共通の規約は、label の無い軸が不一致にならないので全領域に入る。
+
 **合成**: 全ファイルが確定で、和が1〜8件の軸だけを検索に渡す。不明なファイルがある軸と9件以上の軸は省略する。和が空の軸は検索で表せないので、全文の選択で使う。
 
 対象が確定していない工程（devの入口・`spec`・`explore`・`debug`）は、論点の技術を語彙から推定してよい。`filterUserRulesByLabels` は指定しない。
@@ -38,8 +40,29 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 - **更新**: `update_rule` で `scope: "repo"` と3つをそろえて渡すのは、適用先を repo にするとき、別のrepositoryに変えるとき、表示名を現在の名前にするとき（2の `full_name` が規約の `repoOwner`・`repoName` と違うとき）だけ。内容だけの更新では適用先の項目を渡さない（`scope` なしで渡すと入力エラーになる）。
 - **`repoId` が得られないとき**: `scope: repo` では書き込まず、`scope: user`・`scope: repo_owner` に変えるか中止するかを利用者に確認する。範囲を変えるときは、[Shinaps規約の書き方](rule-writing.md)の比較をやり直す。
 
+## 照合のために取得する
+
+対象ファイルが確定した照合の手順。応答をモデルが書き写すと本文や `checks` が欠けうるので、plugin の hook（PostToolUse）が応答をそのまま `<Gitのルート>/.shinaps/work/rule-captures/` へ保存し、そこから `shinaps-skills rule-snapshot` が担当と機械検査の読むファイルを作る。保存先はGit管理の外のローカルで、サーバーへは送らない。
+
+1. 取得の前の時刻を `date +%s000` で記録する。
+2. 領域ごとに入力を作業記録の下（例: `rules/<領域>/input.json`）へ書く。「一覧を取る」と同じ条件で、`fields` だけ `"full"` にする。
+3. その入力のまま `search_rules` を呼び、`nextCursor` がnullになるまで `cursor` だけ足して続ける。モデルに見える応答は切り詰められることがあるが、続きの `nextCursor` だけ読めばよい。`RATE_LIMITED` は短い時間を置いて同じ `cursor` から再開する。
+4. 領域ごとに実行する。版の違いで入力を分けたときは `--input` を並べ、idの和にする。
+
+   ```sh
+   shinaps-skills rule-snapshot --since <時刻> --input <input.json> [--exclude-label <slug>] --out <作業記録>/rules/<領域>
+   ```
+
+   取得と同じGitのルートで実行する（別の場所なら `--captures <dir>` で保存先を渡す）。`rule-snapshot` が無いときは、利用中のスキルと同じ版のCLIを導入する。`--exclude-label` には、「全文を取る規約を選ぶ」の除外の条件に当たる軸のlabelだけを渡す（CLIはこの条件を判定しない）。除外した規約はidと理由が `manifest.json` に残る。
+
+出力は `manifest.json`（`contentHash`、入力、`ruleIds`、除外、partのhash）、`parts/part-NNN.json`（全文）、`lint-checks.json`（全文の `checks` そのまま）。
+
+**失敗したとき**: 欠けたcursorや「捕捉が無い」というエラーで非0終了し、snapshotを作らない。`--since` より前の捕捉は使わない。hookの未信頼・無効、途中で止まった取得がこの形で現れる。Codexでは更新のたびに `/hooks` で信頼し直す必要があり、未信頼でも `exec` は何も表示しない。原因を直して取り直す。直せなければ、その領域の規約照合を未完了として報告し、全文の書き写しで代えない。
+
 ## 一覧を取る
 
+対象が確定していない工程と書込みの前の比較では、この節から「全文を取る」までの手順で取得する。照合の条件の決め方もこの節の規則を使う。
+
 `search_rules` を `fields: "summary"` で呼ぶ。`repoOwner`・`repoId` は「リポジトリを特定する」で決めた値を渡す。対象が確定した照合では `filterUserRulesByLabels: true` を渡す。
 
 ```json
@@ -83,12 +106,41 @@ Shinaps AIのMCPから規約を取得する手順。取得は呼出し元（メ
 
 ## 担当へ渡す
 
-`checks` を持つ規約がある照合では、渡す前に[規約の機械検査](lint.md)の「照合で使う」を行い、照合から外す組を決める。全文は取得した応答の単位で、続きのバッチとして渡す。1回の依頼に全件をまとめない。担当には読み終えた規約のidを報告させ、報告の無い範囲は同じ担当へ戻す。
+対象ファイルが確定した照合の担当へは、全文を依頼文に書き写さず、snapshot のファイルを読ませる。渡す前に[規約の機械検査](lint.md)の「照合で使う」を行う。依頼文には次を書く（全領域を見る担当には領域ごとに）。
+
+> 規約は `<manifest.json>` の `parts` の全ファイルを読む（MCPは呼ばない）。切り詰めの表示が出たら行範囲を指定して読み直す。対象の版は `<版>`、対象ファイルは `<対象ファイルの一覧>`。機械検査の結果は `<lint-result.json>` にある。報告の末尾に次のJSONを付ける。`completedFiles` には全文の照合を終えたファイルだけを書く（`path` は対象ファイルと同じ基準のパス）。読めなかった規約は `unchecked` に、途中までのファイルは `incompleteFiles` に理由を付けて入れる。
+>
+> ```json
+> [{ "contentHash": "<manifestの値>", "targetVersion": "<版>", "completedFiles": ["..."], "unchecked": [{ "id": "...", "reason": "..." }], "incompleteFiles": [{ "path": "...", "reason": "..." }] }]
+> ```
+
+担当の報告を受けたら、末尾のJSONをファイルに保存し、manifest ごとに、領域の全担当の報告を `--report` に並べて実行する。
+
+```sh
+shinaps-skills rule-coverage --manifest <manifest.json> --target-version <版> [--lint <lint-result.json>] [--report <report.json> ...] --out <coverage.json> -- <対象ファイル...>
+```
+
+組は `machine`（機械検査で確定）・`reported`（この snapshot と版の報告がそのファイルを `completedFiles` に挙げ、その規約を未照合としていない担当の申告）・`unconfirmed`（それ以外。報告に書かれていないファイルを含む）のどれか一つに入る。機械が保証するのは同じ snapshot と、id・保存データ・対象の版の整合までで、読了と理解は担当の申告である。snapshot が変わったときは `rule-snapshot` から、lint の結果が別の snapshot のもの、lint の後にファイルが変わった、対象が lint の対象に無いときは lint からやり直す。領域内のファイルを担当に分けて渡すときも、対象ファイル全体と全担当の報告で実行する（誰も照合しなかったファイルは `unconfirmed` に残る）。
+
+修正の後は固定版を更新し、機械検査を対象全体でやり直す。規約を取り直して `contentHash` が変わった領域は、AIの照合もやり直す。AIの照合の範囲は呼び出す入口の手順に従う。
+
+独立設計・計画レビューの担当へは、これまでどおり全文を応答の単位で渡す（照合の完了の判定には使わない）。
+
+## 適用結果を記録する
+
+全指摘の採否が確定したら、規約の改善の材料として確定した結果を `report_rule_outcomes` で既定で記録する。記録は照合の結果を変えない。
+
+- **OFF**: 依頼に「規約の適用結果を記録しない」があれば、依頼を受けた時点で `rule-outcomes.json` に `"off": true` を書く。送信の前に必ずこのファイルを読み、`off` が true なら送らない（後の修正サイクルの依頼にOFFの語が無くても同じ）。
+- **作業記録**: 作業記録の下の `rule-outcomes.json` に `{ "reportKey": "...", "off": false }` を書く。key は最初の送信の前に `node -p "Date.now() + '-' + crypto.randomUUID()"` で作る。同じ作業の修正サイクルと再送は同じ値を使う。単独の `review` から開発の担当へ修正を渡すときは、この2つも渡す。
+- **送るもの**: 規約のidを根拠に持つ指摘だけを、`violation`（採用した規約違反）・`improvement`（採用した改善）・`false_positive`（事実で反証して退けた）・`accepted_as_is`（妥当だが現状を許容した）へ対応づけ、100件ずつ送る。機械検査の `covered` と、指摘の無かった規約は送らない。コード・差分・会話・ファイル名・repositoryは送らない（入力に項目が無い）。
+- **失敗**: `RATE_LIMITED` は短い時間を置いて同じ内容で最大2回まで送り直す。それ以外は送り直さない。`RULE_OUTCOME_LIMIT_REACHED` は同じ呼出しの新規を1件も記録しない。`REPORT_KEY_EXPIRED` では新しいkeyを作らない（同じ作業を二重に数える）。読取り専用のsandboxなどで承認が得られないときも失敗として扱う。どの場合も作業は止めず、未記録の規約のidと理由を報告する。
+- **報告**: 記録した件数・重複の件数・`notFoundIds`・未記録の範囲を書く。OFFならOFFと書く。集計は `get_rule` の `outcomes` で本人の分だけを見られ、直近90日で削除される。
 
 ## 照合結果に書くこと
 
-- 渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
-- 全文の選択で除外した規約のidと理由、`notFoundIds`。
+- `manifest.json` のパスと `contentHash`。渡した全てのfacet・`projectVersions`・`filterUserRulesByLabels`。サーバーが除外した規約のidは返らないので、除外の条件として残す。
+- 除外した規約のidと理由。`get_rules` を使ったときは `notFoundIds`。
+- `rule-coverage` の状態ごとの組の数と、`unconfirmed` の規約・ファイルと理由。`reported` を照合の証明として書かない。
 - 省略した軸・版と理由、未照合になった公式ルールの範囲。
 - 取得・受渡し・読了のいずれかが終わらなかった規約のidまたは条件。これらは照合済みにしない。