@shinaps/skills 0.49.0 → 0.50.1

package/docs/install.md

@@ -23,13 +23,24 @@ npx @shinaps/skills@latest recover codex
 
 ## 配布 CLI
 
-設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査（`lint`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
+設定の検証（`validate-linear-config`・`validate-managed-config`）、Managed Agents の操作（`managed`）、規約の機械検査と受け渡し（`lint`・`rule-snapshot`・`rule-coverage`、[規約の機械検査](lint.md)）には、配布 CLI `shinaps-skills` を使います。CLI は plugin に含まれないため、利用中のスキルと同じ版を導入します。
 
 ```sh
-npm install -g @shinaps/skills@0.49.0
+npm install -g @shinaps/skills@0.50.1
 shinaps-skills --version
 ```
 
+## 規約の hook
+
+規約の照合では、plugin の hook が Shinaps AI の `search_rules` の応答をプロジェクトの `.shinaps/work/rule-captures/` へ保存します。送信はしません。保存先の `.gitignore` で Git の対象外にし、24 時間より古いものは `rule-snapshot` の実行時に消します。
+
+- **Codex**: hook は信頼するまで動きません。plugin の導入と**更新のたびに**、CLI の `/hooks`（または起動時の確認）で内容を確かめて信頼してください。未信頼でも `codex exec` は何も表示せず、`rule-snapshot` が「捕捉が無い」で失敗し、規約照合は未完了になります。
+- **Claude Code**: plugin を有効にすると動きます。`disableAllHooks` や `allowManagedHooksOnly` の環境では動かず、同じく未完了になります。
+
+## 規約の適用結果の記録
+
+dev と `review` は、確定した適用結果（規約の id、作業の key、違反・改善・誤検知・許容の別）を既定で Shinaps AI の本人の集計へ記録します。コード・差分・会話・ファイル名・repository は送りません。集計は `get_rule` で本人の分だけを見られ、他の利用者には返りません。直近 90 日で削除されます。作業ごとに「規約の適用結果を記録しない」と依頼すれば送りません。送信に失敗しても作業の結果は変わらず、未記録として報告します。Codex の読取り専用の sandbox で承認が得られないときも未記録になります。
+
 ## Claude Code の更新
 
 Claude Code は標準の marketplace の自動更新を使います。`/plugin` の Marketplaces から対象 marketplace の auto-update を有効にします。GitHub から自動で取得するには、GitHub のリポジトリを marketplace として登録します（[README のインストール](../README.md#インストール)）。

package/docs/lint.md

@@ -35,6 +35,8 @@ shinaps-skills lint --checks <checks.json> --root <project> --out <result.json>
 }
 ```
 
+結果には他に `checksSha256`（`--checks` のファイルの sha256）と `files`（相対パス → 内容の sha256）が付きます。`rule-coverage` が、別の検査や変更前の内容から作られた結果を拒否するために使います。
+
 | state | 意味 | 照合 |
 | --- | --- | --- |
 | `covered` | `full` の検査が実行され、違反が無い | 外す |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shinaps/skills",
-  "version": "0.49.0",
+  "version": "0.50.1",
   "description": "Install Shinaps AI workflows and custom agents for Codex",
   "type": "module",
   "bin": {

package/plugins/shinaps-claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "shinaps",
   "description": "Shinaps AIの開発ワークフロー。プロジェクトの指示から条件を読み、調査・設計・実装・簡素化・レビュー・コミット・PR・リリースとLinearでの開発進行を支援する。",
-  "version": "0.49.0",
+  "version": "0.50.1",
   "author": {
     "name": "shinaps"
   },

package/plugins/shinaps-claude/agents/shinaps-reviewer.md

@@ -12,13 +12,13 @@ color: red
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文、または読むよう指定された規約のファイル (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 
 呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。変更を対象にしたレビューでは、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。呼び出し元が「範囲判定なし」と指定した場合は、指定された対象全体を今回の対象とし、変更か既存かを区別せず、重要度も下げない。
 
-呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
+呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文（読むファイルを指定されたときはそのファイル）に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
 
 ### 独立コードレビュー
 
@@ -63,11 +63,14 @@ color: red
 渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認する。削減は、欠陥の確認より先に検討する。
 
 - 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
-- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
+- 「同じ理由で変わる箇所が一緒に変更でき、異なる理由で変わる箇所が互いを巻き込まないか」を見る。同期が必要なのに構造から分からない重複・暗黙の状態や呼び出し順序、内部実装への依存による不要な変更の波及、独自の責務を持たない中継や未使用の拡張点を確認する。配置やラッパーの存在だけでは欠陥とせず、責務・契約・全利用側から判断する。
+- 構造の提案には、どんな変更でどの箇所を同時に直す必要があり、見落としや不要な波及がどう生じるかを、file:line と利用箇所で示す。変更履歴は必要に応じて補助の根拠にし、同時に編集された事実だけで共通化を求めない。共通の原因がある問題は一つの設計変更で解消できるか検討し、関連箇所と維持する責務を示す。
+- 特殊な分岐・retry・待機などは、必要な要件や外部制約と、その実装方法を分けて評価する。例外数の削減を目標にせず、削除・統合で増える抽象化や理解の負担も比較する。
+- コメントは成立条件・設計判断・外部制約を伝える価値で、テストは検出する回帰と守る仕様で評価する。コードと似ていることだけを削除理由にしない。統合・削除の提案では、必要な説明と保証がどこに残るかを示す。
+- 各提案について対象、削除・統合・責務の再配置の内容、効果、維持する契約と挙動を保てる根拠、必要な検証、仕様判断の要否を返す。検証は変更前の基準と設計変更の単位に対応させる。仕様を変える提案は通常の簡素化と区別する。
 - 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。
-- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。
-- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。
-- 簡素化の提案は下の Confidence 閾値の対象外とする。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
+- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。改善余地が尽きるまで対象を広げず、依頼された対象の確認と提案までに留める。
+- 簡素化の提案は下の Confidence 閾値の対象外とするが、根拠のない将来予測や好みだけの案は出さない。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
 
 ### 指摘の検証
 
@@ -122,7 +125,7 @@ color: red
 - **不確実な仮説と確認済みの問題を分ける**: 検証していない動作を確認済みとしない
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
 - **修正は提案のみ**: コード・設定・ルール・進行管理ファイルは編集せず、指摘を呼び出し元へ返す。追加の委託・worktree の作成・コミット・公開はしない
-- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
+- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡されるか、読むファイルを指定される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す。呼び出し元が報告の形を指定したら、レポートの末尾にその形で付ける
 
 ## テスト方針
 

package/plugins/shinaps-claude/hooks/capture-rule-response.mjs

@@ -0,0 +1,27 @@
+// PostToolUse hook: search_rules (fields=full) の標準入力の全体を、モデルを通さずローカルへ保存する。
+// 形式の正本は lib/rule-snapshot.ts のコメント。失敗しても作業は止めず、rule-snapshot が欠けた捕捉として検出する。
+import { existsSync, mkdirSync, readFileSync, renameSync, writeFileSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+
+// plugin の hook は配布 CLI の lib を読めないので、同じ処理をここにも持つ。
+function projectRoot(cwd) {
+  for (let directory = cwd; ; directory = dirname(directory)) {
+    if (existsSync(join(directory, '.git'))) return directory;
+    if (dirname(directory) === directory) return cwd;
+  }
+}
+
+const safeName = (value) => String(value).replace(/[^\w-]/g, '_');
+
+const raw = readFileSync(0);
+const event = JSON.parse(raw);
+if (event.tool_input?.fields === 'full') {
+  const captures = join(projectRoot(event.cwd), '.shinaps', 'work', 'rule-captures');
+  const directory = join(captures, safeName(event.session_id));
+  mkdirSync(directory, { recursive: true });
+  // 捕捉には個人規約の本文が入る。プロジェクトの ignore の内容によらず Git の対象外にする。
+  writeFileSync(join(captures, '.gitignore'), '*\n');
+  const file = join(directory, `${Date.now()}-${safeName(event.tool_use_id)}.json`);
+  writeFileSync(`${file}.tmp`, raw);
+  renameSync(`${file}.tmp`, file);
+}

package/plugins/shinaps-claude/hooks/hooks.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "mcp__.*shinaps[-_]ai.*__search_rules",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node \"${CLAUDE_PLUGIN_ROOT}/hooks/capture-rule-response.mjs\""
+          }
+        ]
+      }
+    ]
+  }
+}

package/plugins/shinaps-claude/managed-agents/agents/shinaps-reviewer.md

@@ -20,13 +20,13 @@ tools:
 ## 作業前の必須確認
 
 - リポジトリ直下の `CLAUDE.md` / `AGENTS.md`、`~/.claude/CLAUDE.md`
-- **Skill 側から prompt 経由で渡された取得済みの規約全文 (差分カテゴリに対応した userRules + officialRules)**
+- **Skill 側から prompt 経由で渡された取得済みの規約全文、または読むよう指定された規約のファイル (差分カテゴリに対応した userRules + officialRules)**
 
 ## レビューの種類
 
 呼び出し元が「独立コードレビュー」「可読性・慣習レビュー」「規約照合」「実装の簡素化」「指摘の検証」のうち1つ以上を指定する。指定が無ければ独立コードレビューとして動く。複数を指定されたら、各節の観点を1名で見て、一つのレポートで返す。指定された種類の節に従い、下の「可読性のレビュー」・Confidence 閾値・出力形式・動作原則はどの種類でも共通に使う。規約を根拠にする指摘（rule 観点・可読性・慣習・規約照合）は、今回の変更か既存箇所かを区別する。変更を対象にしたレビューでは、そのうち今回の変更と無関係な既存箇所のものを、どの種類でも「既存箇所の指摘」に分け、Critical にせず、完了を止める指摘にしない。この扱いは、下の重要度と「必ず Critical」の文より優先する。呼び出し元が「範囲判定なし」と指定した場合は、指定された対象全体を今回の対象とし、変更か既存かを区別せず、重要度も下げない。
 
-呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
+呼び出し元が設計適合性も依頼した場合は、design 観点で計画・受入条件・責務・依存方向と実コードを照合する。規約照合の種類が指定されなければ、規約は独立コードレビューの rule 観点で、渡された規約全文（読むファイルを指定されたときはそのファイル）に照らす。呼び出し元が機械検査で照合から外すと伝えた組（規約×ファイル）は、rule 観点でも規約照合でも照らさない。
 
 ### 独立コードレビュー
 
@@ -71,11 +71,14 @@ tools:
 渡された目的・受入条件・計画・規約と、対象の現在のコードや利用箇所を確認する。削減は、欠陥の確認より先に検討する。
 
 - 目的と必要な外部契約を保ちながら削除・統合できる処理、重複、不要な分岐・互換層・抽象化を探す。行数だけを減らして責務を混ぜない。
-- 変更の効果と、挙動を保てる根拠を file:line と利用箇所で示す。仕様を変える提案は通常の簡素化と区別する。提案を埋めるために変更を増やさない。
+- 「同じ理由で変わる箇所が一緒に変更でき、異なる理由で変わる箇所が互いを巻き込まないか」を見る。同期が必要なのに構造から分からない重複・暗黙の状態や呼び出し順序、内部実装への依存による不要な変更の波及、独自の責務を持たない中継や未使用の拡張点を確認する。配置やラッパーの存在だけでは欠陥とせず、責務・契約・全利用側から判断する。
+- 構造の提案には、どんな変更でどの箇所を同時に直す必要があり、見落としや不要な波及がどう生じるかを、file:line と利用箇所で示す。変更履歴は必要に応じて補助の根拠にし、同時に編集された事実だけで共通化を求めない。共通の原因がある問題は一つの設計変更で解消できるか検討し、関連箇所と維持する責務を示す。
+- 特殊な分岐・retry・待機などは、必要な要件や外部制約と、その実装方法を分けて評価する。例外数の削減を目標にせず、削除・統合で増える抽象化や理解の負担も比較する。
+- コメントは成立条件・設計判断・外部制約を伝える価値で、テストは検出する回帰と守る仕様で評価する。コードと似ていることだけを削除理由にしない。統合・削除の提案では、必要な説明と保証がどこに残るかを示す。
+- 各提案について対象、削除・統合・責務の再配置の内容、効果、維持する契約と挙動を保てる根拠、必要な検証、仕様判断の要否を返す。検証は変更前の基準と設計変更の単位に対応させる。仕様を変える提案は通常の簡素化と区別する。
 - 同じ対象を確認する他の担当の結果を読まず、意見を交換しない。
-- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。
-- 各提案について対象、削除・統合の内容、理由、維持する契約、必要な検証、仕様判断の要否を返す。
-- 簡素化の提案は下の Confidence 閾値の対象外とする。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
+- 対象全体を確認し、未確認のファイルと理由を明記する。分割して渡された場合は、続きと関連箇所の整合性も確認する。改善余地が尽きるまで対象を広げず、依頼された対象の確認と提案までに留める。
+- 簡素化の提案は下の Confidence 閾値の対象外とするが、根拠のない将来予測や好みだけの案は出さない。提案がなければ「なし」と確認範囲を書き、この節を必ず出力する。
 
 ### 指摘の検証
 
@@ -130,7 +133,7 @@ tools:
 - **不確実な仮説と確認済みの問題を分ける**: 検証していない動作を確認済みとしない
 - **観点を分けて報告しない**: 1 つの指摘に複数観点タグが付いても良い
 - **修正は提案のみ**: コード・設定・ルール・進行管理ファイルは編集せず、指摘を呼び出し元へ返す。追加の委託・worktree の作成・コミット・公開はしない
-- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す
+- **shinaps MCP を直接呼ばない**: rule 全文は呼び出し元から渡されるか、読むファイルを指定される。渡されていない、または読み終えていない規約と照合済みとは報告せず、読んだ範囲と未読の規約（id・topic など特定できる単位）を返す。呼び出し元が報告の形を指定したら、レポートの末尾にその形で付ける
 
 ## テスト方針
 

package/plugins/shinaps-claude/managed-agents/skills/dev-managed-cc/references/review.md

@@ -25,7 +25,7 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
@@ -38,7 +38,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら変わったファイルで実行し直し、前回の結果を引き継がない。
+規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -47,7 +47,7 @@
 
 ## 完了の判定
 
-未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。指摘なしの担当は、完了と確認範囲を確かめる。
+未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。入口の手順が規約の報告の形を指定したときは、その報告が無い担当の範囲を未確認にする。指摘なしの担当は、完了と確認範囲を確かめる。
 
 担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で完了を判定する。未照合の規約は、特定できる単位（例: id・topic）で報告する。対象が大きい場合は、件数を理由に対象を減らさず、関連するファイルをまとめて同じ担当へ分けて渡し、分けた範囲をまたぐ契約は統合のときに確かめる。担当を再開できない場合は、確認済みと未確認の範囲を後任へ引き継いで交代を記録する。
 

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

@@ -22,7 +22,7 @@ devの依頼は登録済みのdev役割への委託（Agentでの起動）を含
 | Phase 6 | `shinaps-reviewer` | 独立コードレビューを含む担当はレビューラウンドごとに新規。規約照合と可読性・慣習レビューを技術領域ごとに置く担当は、ラウンドと修正サイクルをまたいで継続し、技術領域が増えたら追加 |
 
 - 異なる役割と独立比較の担当は別コンテキストで起動する。担当番号を起動前に固定し、同じ役割の継続は同じIDを使う。再開できない場合（resumeをまたぐ場合を含む）は同じ役割へ既存の成果・最新の差分・未解決点を引き継いで交代を記録する。
-- 目的・範囲・規約全文・必読ファイル・今回の役割・担当番号・確認対象の版・依頼するレビューの種類を依頼に渡す（独立設計担当への依頼はPhase 3に従う）。担当は読み取り専用で、自分でエージェントを起動しない。
+- 目的・範囲・規約全文（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の微調整)で返した差分は、メインが取り込み、現在の工程の差分として検証し、既存のレビューを続ける（回数はリセットしない）。
@@ -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、引き継いだ調査の必読ファイルを確認する。時間に依存する根拠が判断に影響する場合は公式情報で確かめる。
@@ -86,7 +88,7 @@ Issue・既存spec・調査記録・関連コード・検証方法を必要な
 
 [レビューの共通契約](../review.md)に従い、同じ差分を固定して、選んだ体制の担当と追加した担当を並行して起動する。設計適合性は、独立コードレビューの種類の中で毎回依頼する。変更範囲の確認コマンドは `git diff HEAD -- <path>` を渡す。
 
-変更言語・領域・バージョンがPhase 2の規約の範囲を超えた分だけ取得を補い、同じ全文を渡す。取得した規約に `checks` があれば、担当へ渡す前に[規約の機械検査](../lint.md)の「照合で使う」を行う。
+固定した対象について、[Shinaps規約の取得](../rules.md)の「照合のために取得する」で領域ごとに snapshot を作る。`checks` があれば、担当へ渡す前に[規約の機械検査](../lint.md)の「照合で使う」を行い、「担当へ渡す」の依頼文で読ませる。
 
 結果を `review-{round}-{n}.md` に保存する。未照合の規約はPhase 9に報告する。
 
@@ -104,7 +106,9 @@ 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)）。
 

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

@@ -4,7 +4,7 @@
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.49.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.49.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.50.1のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.50.1`）。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/review-standalone.md

@@ -39,20 +39,20 @@
 
 ## 3. 記録
 
-記録は `.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{対象}/` に置き、[作業記録の共通手順](work-records.md)に従う。`input.md` に対象・固定した版・列挙したファイル・体制を書き、担当の応答は全文を `raw/review-{round}-{n}.md` に保存し、全指摘の採否を `findings.md` に書く。関連する既存の spec・調査記録があれば要約して担当へ渡す。
+記録は `.shinaps/work/reviews/{YYYYMMDD-HHMMSS}-{対象}/` に置き、[作業記録の共通手順](work-records.md)に従う。`input.md` に対象・固定した版・列挙したファイル・体制を書き（依頼に「規約の適用結果を記録しない」があれば[作業記録へ書く](rules.md#適用結果を記録する)）、担当の応答は全文を `raw/review-{round}-{n}.md` に保存し、全指摘の採否を `findings.md` に書く。関連する既存の spec・調査記録があれば要約して担当へ渡す。
 
 ## 4. 規約と機械検査
 
-[Shinaps規約の取得](rules.md)に従い、対象ファイルについて規約全文を取得し、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
+[Shinaps規約の取得](rules.md)の「照合のために取得する」に従い、対象ファイルについて snapshot を作り、同じ手順の「照合結果に書くこと」を報告に含める。取得できなければ規約照合を未確認として報告し、照合済みとしない（コードのレビューは続ける）。`checks` を持つ規約があれば[規約の機械検査](lint.md)の「照合で使う」を行う。プロジェクトの `AGENTS.md`・`CLAUDE.md` と関連 docs も担当へ渡す。その後、スキルの「担当の起動」に従って担当を起動する。
 
 ## 5. 検証と報告
 
-契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。契約の「報告」と `findings.md` のパスを報告する。
+契約の「指摘の検証と統合」に従い、メインが全指摘を実コードで確かめて採否を決める。指摘の独立検証を依頼されたとき、またはメインと指摘元の根拠の対立が解消しないときは、別の担当に「指摘の検証」を依頼する。テストに関わる指摘は[テスト方針](testing.md)に従う。採否の確定後に[規約の適用結果](rules.md#適用結果を記録する)を既定で記録する（依頼でOFFにできる。失敗は未記録として報告する）。契約の「報告」と `findings.md` のパスを報告する。
 
 ## 6. 到達点
 
-依頼に修正まで含まれていなければ、報告で終わる。ファイルの修正・コミット・PRへの投稿・公開をしない。
+依頼に修正まで含まれていなければ、報告で終わる。対象のファイルの修正・コミット・PRへの投稿・公開をしない（規約の適用結果の記録は本人のShinaps AIの集計だけに書く）。
 
-- **修正**: 明示的に修正まで依頼された場合、採用した指摘が1件以上あれば、指摘（`findings.md` のパスと本文）・固定した版・選んだ体制（選んでいれば）・依頼範囲と制約を開発の担当へ渡す。作業ツリーが固定した版でなければ（別のブランチのPR、過去のコミットなど）、修正する場所を先に一問で確認する。開発の担当がdevの修正サイクルで修正と再レビューを行い、未コミットの差分を返す。採用した指摘が無ければ引き継がず報告で終わる。コミット・PR・公開は、それぞれ依頼に含まれている場合だけ別の工程で行う。
+- **修正**: 明示的に修正まで依頼された場合、採用した指摘が1件以上あれば、指摘（`findings.md` のパスと本文）・固定した版・選んだ体制（選んでいれば）・依頼範囲と制約・`rule-outcomes.json` の値を開発の担当へ渡す。作業ツリーが固定した版でなければ（別のブランチのPR、過去のコミットなど）、修正する場所を先に一問で確認する。開発の担当がdevの修正サイクルで修正と再レビューを行い、未コミットの差分を返す。採用した指摘が無ければ引き継がず報告で終わる。コミット・PR・公開は、それぞれ依頼に含まれている場合だけ別の工程で行う。
 - **PRへの投稿**: 明示的に依頼された場合だけ、本文を確認してから投稿する。
 - **規約の登録・更新**: 利用者がその場で依頼した場合だけ、[Shinaps規約の書き方](rule-writing.md)に従って行う。指摘から自動で登録しない。

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

@@ -25,7 +25,7 @@
 
 ## 担当へ渡すもの
 
-- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
+- 共通: 目的、確認範囲、担当番号、固定した版と読む場所（一時worktreeのパスなど）、依頼する種類、規約全文または読むファイルの指定、合意済み仕様。入手できなかったもの（計画・受入条件など）はそのことを伝える。
 - 独立コードレビュー: 対象コード、全差分、利用側、計画、検証結果。計画自体も誤りうるものとして確かめさせる。設計適合性は、計画・受入条件・責務・依存方向と実コードを照合させる。
 - 規約照合: 対象ファイルの一覧と、変更範囲の確認コマンド。担当は対象ファイルの現状全文を読む。
 - 可読性・慣習レビュー: 担当する範囲の差分と対象ファイルの現状全文、先例。
@@ -38,7 +38,7 @@
 
 ## 機械検査
 
-規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら変わったファイルで実行し直し、前回の結果を引き継がない。
+規約に機械検査（`checks`）があり入口の手順で実行できるときは、対象の固定後、担当へ渡す前に実行する。版が変わったら実行し直し、前回の結果を引き継がない。
 
 - 全体を検査して違反が無いと確かめた組（規約×ファイル）と、違反を確かめた組は、そのファイルの rule 観点・規約照合から外す。外した規約の id をファイルごとに担当へ伝える。
 - 一部だけを検査した組は担当の照合に残し、機械検査の指摘を添える。
@@ -47,7 +47,7 @@
 
 ## 完了の判定
 
-未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。指摘なしの担当は、完了と確認範囲を確かめる。
+未確認の部分があれば同じ担当へ戻し、全結果が揃ってから検証・統合する。起動失敗・空回答・未確認範囲を「指摘なし」にしない。入口の手順が規約の報告の形を指定したときは、その報告が無い担当の範囲を未確認にする。指摘なしの担当は、完了と確認範囲を確かめる。
 
 担当が規約を読み終えられなかった場合は、未読の規約を読める単位に分けて同じ担当へ渡す。それでも読めない規約はメインが未照合と確定し、その規約を担当へ伝え、それを除いた範囲で完了を判定する。未照合の規約は、特定できる単位（例: id・topic）で報告する。対象が大きい場合は、件数を理由に対象を減らさず、関連するファイルをまとめて同じ担当へ分けて渡し、分けた範囲をまたぐ契約は統合のときに確かめる。担当を再開できない場合は、確認済みと未確認の範囲を後任へ引き継いで交代を記録する。
 

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）までに分かれるので、下の順に全件を辿る。
 
 ## 語彙を確認する
 
@@ -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または条件。これらは照合済みにしない。
 

package/plugins/shinaps-claude/skills/review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: review
-description: 差分・PR・コミット範囲・既存コードをレビューする。LITE・BASIC・ULTRAの体制を開発時の体制と関係なく選べ、規約照合・可読性・慣習・実装の簡素化も同じ入口で扱う。「レビューして」「規約に合っているか確かめて」「簡素化できるか見て」と依頼されたとき、追加修正の後に確かめたいときに使う。指摘の検証と報告までを行い、修正は明示の依頼があるときだけ開発の担当へ引き継ぐ。
+description: 差分・PR・コミット範囲・既存コードをレビューする。LITE・BASIC・ULTRAの体制を開発時の体制と関係なく選べ、規約照合・可読性・慣習・実装の簡素化も同じ入口で扱う。「レビューして」「規約に合っているか確かめて」「簡素化できるか見て」と依頼されたとき、追加修正の後に確かめたいときに使う。指摘の検証と報告までを行い（確定した規約の適用結果は既定で記録し、依頼でOFFにできる）、修正は明示の依頼があるときだけ開発の担当へ引き継ぐ。
 argument-hint: "[<PR番号/URL> | <コミット/範囲> | <path>] [LITE|BASIC|ULTRA] [規約照合|簡素化 など種類の限定]"
 ---
 

package/plugins/shinaps-codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "shinaps",
-  "version": "0.49.0",
+  "version": "0.50.1",
   "description": "Shinaps AIのCodex向け開発ワークフロー",
   "skills": "./skills/"
 }