Repository navigation
docs: M7 の完了を反映し、追い越された文書・skill・hook を直す - #74
Merged
Merged
Conversation
check-unityengine-leak.sh は Runtime/Interop と Runtime/Core の 2 つを 写して持っていたが、M7c が profile 分離で Runtime/Interop.Dnn と Runtime/Dnn を足し、shim の csproj は 4 フォルダをコンパイルするように なっていた。4 つとも asmdef が noEngineReferences: true を宣言している ので、後の 2 つに UnityEngine を書くと L3 の shim ビルドが落ちるが、 hook は何も言わなかった。 実測（4 フォルダに using UnityEngine; の probe を当てた）: 修正前 Core=検知 / Interop=検知 / Interop.Dnn=素通り / Dnn=素通り 修正後 4 つとも検知 一覧を長くするのではなく、正本 （tests/Managed/CvUnity.Runtime.Shim/CvUnity.Runtime.Shim.csproj の <Compile Include> 行）から読む形にした。csproj に 5 本目 （Runtime/Cuda）を足すと、hook を 1 行も触らずに Runtime/Cuda が 検知されることを実測してある —— 次の profile では増やし忘れが起きない。 副次: 速い経路はフォルダ名で絞らず Runtime/ で切る（絞ると一覧を 写すことに戻る）。native/src・tools/dev.ps1 は今までどおり jq に 到達せず抜けることを sh -x のトレースで確認した。Runtime 配下の 非対象フォルダ（UnityIntegration / Plugins）は jq までは進むが 指摘しない。正本が読めないときは黙って素通しせず声を上げる （check-platform-list-drift.sh と同じ判断。実測で発火を確認）。
M7 の 3 commit（#70 / #72 / #73）は docs/ をほとんど触っておらず、 散文が M7 自身の判定表と食い違っていた。24 件の監査結果を当てた。 **M7 の総合判定が無かったので足した。** 5 件の判定は 4 節（M7a / M7b / CUDA / M7c）に分かれており、「M7 は完了した」と書いた文が docs/ に 1 つも無かった。roadmap に索引としての `### M7 の判定` を 置き、M5 / M6 と同じ形にした。**「満たした」と「実証した」を別の列に 分けてある** —— 5 件とも満たしたが、1 件は実機で 1 度も動かしておらず、 2 件は CI が見ていない経路を含み、1 件は根拠となる文書を読んでいない。 穴（dnn の実機・`.clone()` の再現テスト・MLAS / ONNX Runtime が allowlist から見えない・`WITH_CAROTENE` / `WITH_KLEIDICV` 未監査・ notices の platform 差）は畳まずに索引として並べた。 **M7 が最後のマイルストーンであることを事実として書いた** （`## M` 見出しは M0〜M7 で M8 は無い）。帰結として「次のマイルストーン へ送る」という行き先が構造上存在しないので、M7 spec 計画の `gapi` / `videoio` の項は「担当が無い」に直した。 **逆向きの陳腐化を 3 箇所直した** ——「nightly は schedule でまだ 1 度も 走っていない」は偽で、2026-08-29 から毎日 13 回走り直近 8 回は success （`gh run list --event schedule` で実測）。**動いている検査を存在しない ことにする記述は、赤くならないまま残る。** その他: roadmap 決定 2 / 決定 4 の「dnn はまだ無い」（M7c で入った。 取り消し線で残し、同じ前提が他所にも無いか確かめられる形にした）、 M7a 判定の「実行されたのは 2 計画」（3 計画）、依存図の M7 に注記が 無かった件、OpenUPM の配信版（0.2.0 → 0.3.0）、`docs/README.md` の M7 段落・Status の自己矛盾・`ocvu_debug_throw` の抜け、 `performance.md` の「測っていないこと」への dnn 推論、 `m4-device-verification.md` の失効した v0.3.0 警告、競合調査の module 数と推論欄、abi §4 の「全 9 module」（実際は 10）。 **数の写しは、直すより消す方を選んだ** —— export の「53 本」は 2 箇所とも本数を落として `docs/api-map.md` を指す形にし、abi §4 と 競合調査の module 数も正本（`OCVU_ALL_MODULES` / `Modules` / `COMPONENTS`）を指す形にした。 確認: ci-lint の documentation link check と同じ判定をローカルで実行 （checked 209 links / no broken links）。
M7 の 3 commit は .claude/ を 1 行も触っていない。skill はマイルストーン ごとの学びが溜まる場所なので、その分がまるごと欠けていた。 **add-abi-function は実際の経路を指していなかった。** 「新規 .cpp は native/CMakeLists.txt の OCVU_SOURCES に足す」と書いていたが、M7b 以降 そこに一覧は無い（正本は native/modules.cmake の OCVU_MODULE_<module>）。 新しい module を足すときの手作業も 1 つ（#include）ではなく 2 つ （modules.cmake の 2 行）で、足さないと configure が FATAL_ERROR になる。 profile という軸も 1 語も出てこなかったので節を新設した —— 出力先・ クラス名・assembly が変わること、LibraryName を生成器が複製する理由、 そして **到達性テストの呼び出し元を自分で作らないと、生成されたのに 1 度も呼ばれない = stripping の対象になる**（M7c で実際にそうなった）。 CI はどのレーンも OCVU_PROFILE_DNN を立てないので確認は手動である （.github/ と tools/ を grep して 0 件であることを確かめた）。 逆向きの検査も 1 本ではなく 2 本になっている（ソースを読む方と、 binary の export 面を読む verify-exported-symbols.ps1）。 **add-a-platform**: release.yml の「未知の platform は落とす」門は 2 つ ではなく 3 つ（M7b が公開面の検査を足した）。表に 2 行追加 （verify-exported-symbols.ps1 の配線 2 箇所、measure-package-size.ps1 の 上限 —— M7c は実際にここで落ちた）。native/CMakeLists.txt の行に Android の strip を追記。罠 8 に対になる半分を足した —— **構成ハッシュは opencv-config.psd1 の内容しか見ないので、toolchain file に書いた flag は復元済み artifact に反映されない。** 罠 5 には allowlist の限界（静的に取り込まれた third-party は見えない。MLAS / ONNX Runtime で実測）。**「17 箇所」という数は落とした** —— M7 で 2 つ 増えたのに数だけ取り残されており、まさにこの skill が警告している形 だった。add-abi-function にあった写しも同時に落とした。 **milestone-complete**: 回すレーンに test-unity-graphics と benchmark を 追加（どちらも CI に配線が無く、判定のときだけが唯一の実行機会）。 test-unity-player が後始末でハングする既知の欠陥を注記。「次マイルストーン へ送る」の行き先が M7 以降は構造的に無いことを明記。そして新しい節 —— **判定を複数の節に割ったら、残数を書かず、名指し参照を自分で洗う** （ci-lint のリンク検査は backtick 見出し参照を見ない。M7 では警告を 書いた branch の中でさらに 1 件を 2 人がかりで見落とした）。 **prove-a-check-works** に 4 件: (1) 2 つの assertion が対になって初めて 1 つの門になる形（片方だけだと、直書きへ戻してコメントに引数の形を書く だけで PASS する。実測）、(2) 検査が当たっていた対象が本番の物ではなく 代用物だった 2 例（開発用 binary / 手書き probe）、(3) 負の対照の 3 例目 —— **壊しても落ちず、かつ必要性を確定させる経路がリポジトリに存在しない** （.clone()）。「検査が働くことを示せていない」と「そのコードが要ることを 示せていない」は別の主張なので表で分けた、(4) test-unity-tarball が M7a で同じ理由で再発したこと（走らないレーンは直した後も同じ速さで腐る）。 **hook のコメント 2 件。** block-bulk-git-add.sh の冒頭は「生成物、 一時的なデバッグ変更を巻き込む」と書きながら、それを正確に stage する `-u` を実装が 1 度も見ていなかった（実装は変えない —— 分担は意図的で、 隣の check-staged-generated-file.sh がその判断を書いている）。 check-platform-list-drift.sh の「6 つとも 5/5」は M6 で古くなっていた —— 今日測り直して 6 つとも 6/6 であることを確認し、実測日を添えた。
CLAUDE.md の現在地が M6 のままだった。M7 は完了条件 5 件すべてを満たし、 **M7 が最後のマイルストーンである**（roadmap の `## M` 見出しは M0〜M7）。 判定が 4 節に分かれていることと、**「満たした」と「実証した」が M7 では 大きく食い違うこと**（dnn は実機で 1 度も動かしておらず、RenderTexture の 画素経路は CI が 1 度も実行せず、CUDA / cuDNN のライセンスは読んでいない）を 現在地に書き、**穴の一覧は roadmap に置いて写さなかった。** 「M7 の計画はまだ無いので writing-plans で先に書く」も偽だったので、 4 本の計画と担当条件に置き換えた。 **逆向きの陳腐化を 3 箇所**（CLAUDE.md の workflow 表と「CI が保証して いないこと」、README 英日）—— nightly は 2026-08-29 から毎日 schedule で 走っている。「CI が保証していないこと」からはこの項目ごと削った： **動いている検査を穴として掲げていた。** **Web の 3 本を必須にしない理由が失効していた。** 「緑の実績が浅い」は 2026-09-10 時点で成立しない（PR #63/#69/#70/#72/#73 の 5 本すべてと、 main の直近 6 run で緑。gh で実測）。**設定は変えていない** —— 昇格は所有者の判断なので、**未決の判断として開いている**と書いた。 README 英日の同じ段落も直し、あわせて因果の誤りを正した —— 過去 2 回踏んだのは「早すぎる昇格」ではなく**レーンを足して必須にしな かったこと**である。 **README の Status が「リポジトリと公開版は揃っている」と言い続けていた。** M7c が足した dnn 節と PNG NEON の段は v0.3.0 に入っていないので、 Status で明示し、両方の節に「次の版から」を付けた —— **v0.3.0 に対して OCVU_PROFILE_DNN を立てても CvDnn は存在しない。** 非ゴールの「DNN を有効にした binary を配らない」も、同じ README の 191 行が「native binary には dnn が常に入る」と書いていて自己矛盾して いたので、意図的な例外として書き分けた。 **CI が見ていないレーンは 2 本ではなく 4 本**（`test-unity-graphics` と `benchmark` が M7a で増えた）。**後ろ 2 本は前の 2 本より重い** —— `RenderTextureConverter` は配るパッケージの公開 API なのに、 **画素を運ぶ経路がどの CI レーンからも実行されない**。利用者向けの README にそれが書かれていなかったので足した（英日とも）。 開発コマンドの一覧にも 2 レーンを足した。 その他: export の「53 本」の写しを落として api-map を指す形に、 全部入り tarball の「34 passed」の写しを落として test-unity-tarball の 行を指す形に、設計文書の計画一覧（M3.5 で止まっていた）を docs/README.md へ委譲、README 英日の文書一覧に M7 の計画 4 本と docs/performance.md を追加。skill / hook の表には M7 の学びと、 今回直した check-unityengine-leak.sh の欠陥を反映した。 確認: documentation link check をローカルで実行（checked 219 / 壊れ 0）。
レビューの 6 件に対応する。
**1. hook の csproj 解析が、直したはずの欠陥を作り直していた（must fix）。**
2 件ともレビュアーの指摘どおり再現した。
(a) MSBuild は 1 つの Include に ';' 区切りで複数のパスを書ける。
行ごとの貪欲な .* は 1 行 1 フォルダしか取らないので、4 フォルダを
2 行に書いた csproj から **2 つしか読めず、Interop と Core が
素通りした**。**しかも古い門（-lt 2）は 2 件読めているので通した** ——
欠けた一覧が、揃った一覧と同じ顔をする。これはこの hook が無くそうと
した形そのものである。
(b) コメントは「<Compile Include> 行を読む」と書いていたが、実装は
`$(OcvuPackageRuntime)` を含む任意の行に当たっていた。
`<None Include="$(OcvuPackageRuntime)\UnityIntegration\...">` を足すと
Runtime/UnityIntegration を対象と誤認し、負の対照が壊れた。
block-bulk-git-add.sh で直したのと同じ「理由と実装のずれ」である。
直した形: 改行を潰して '<' で切り、**要素単位**で読む。XML コメントは
範囲指定で落とす。`<Compile>` だけを見る。Include を ';' で割り、
引用符は二重・単重の両方を受ける。
**門を閾値にしない。** 「N 件以上読めたか」は (a) を素通しした。
代わりに**読みの整合**を 3 つ見る: 変数を参照する <Compile> が 1 つ以上
ある / 変数を名指ししたパス 1 つにつきフォルダが 1 つ取れた /
フォルダ数が要素数以上。**後ろ 2 つは対で、片方だけでは
「パスを 1 つ落とした」「要素ごと落とした」をそれぞれ見逃す。**
実測（敵対的な対照。修正前 → 修正後）:
';' 区切り 2 パス x 2 行 Interop/Core 素通り -> 4 つとも検知
<None> が同じ変数を参照 UnityIntegration 誤検知 -> 指摘なし
コメントアウトした<Compile> UnityIntegration 誤検知 -> 指摘なし
属性が次行 / 1 行 2 要素 Core 素通り -> 3 つとも検知
シングルクォートの Include 読めるが偶然 -> 正しく読む
区切りが無いパス / <Compile> 0 件 / 壊れた csproj -> どれも声を上げる
実物の csproj では 4 検知 + 2 非検知（回帰なし）。速い経路も変化なし。
**2. README の「2 つが v0.3.0 に入っていない」は偽だった（Important）。**
tag から数え直した: v0.3.0 は `03a4557` で、2026-09 の API 拡張よりも
M7 よりも前である。`docs/api-map.md` は **v0.3.0 で 27 本、HEAD で 57 本**。
`CvAruco` / `CvCoreOps` / `CvStereo` / `CvDnn` / `RenderTextureConverter` は
その tag に存在しない。**古い文を新しい嘘に置き換えていた** ——
このスイープが避けようとしたその形なので、列挙をやめて境界（どの tag が
何より前か）と生成物から取れる数字だけを書き、正本は「配布 その 5」を指す。
`RenderTextureConverter` を「導入するパッケージの公開 API」と書いていた
段落（英日）にも「次の版から」を付けた。
**3. 排他の主張が、同じ branch の中で偽だった。** roadmap は nightly の
件数を「ここ 1 箇所に限る」と書いていたが、README 英日にも書いてある。
必須チェックの本数と同じ扱い（利用者向けの 2 段落は日付つきの記録として
持つ）に改め、**排他を主張する文は主張した本人がいちばん破りやすい**と
書き足した。実測: いま件数を持つのはちょうどその 3 箇所である。
**4. `CLAUDE.md` の「CI が保証していないこと」に、M7c が作った盲点を足した。**
`OCVU_PROFILE_DNN` を立てる workflow も dev.ps1 のレーンも無いので、
Unity の中で profile assembly がコンパイルされることと IL2CPP の stripping が
dnn の宣言を消さないことは、**人が手で 1 回確かめたきり**である。
**「dnn は CI が見ていない」とは丸めていない** —— L1 / L3
（`DnnInferenceTests`）/ shim が `Interop.Dnn` と `Dnn` を常にコンパイルする
こと / `NonStandardProfileCompile.Tests.ps1` の 4 つは CI が見ている（ただし
最後の 1 つが通しているのは合成 spec の出力で、実物の
`NativeMethods.Dnn.g.cs` ではない）。**空いているのは Unity と IL2CPP の側
だけである。**
**5. nit 2 件。** 「M5（続きの 4 本）」→「本体 1 本と続きの 3 本」。
M7b 計画に、共有仕様・(c)・(a) と同じ「実行済み」の枠を付けた ——
**残していた非対称は、直接その計画だけを読む人には古い話に見える。**
(a) にも同じ枠を置いたので、M7 の 4 計画すべてが同じ形になった。
確認: `dev.ps1 test-tools` exit 0 / documentation link check 219 件・壊れ 0 /
`sh -n` で hook の構文 / 実物の csproj は元どおり（git status が clean）。
**合計は釣り合わせられた。** 前の commit が入れた 3 本の突き合わせ
（要素数・パス数・フォルダ数）はどれも合計に対する算術なので、
同時に満たしてしまえる。レビュアーが出した形を実測で再現した:
<Compile Include="A;B;C" /> 3 パス / 3 フォルダ
<Compile Include ="D" /> Include の '=' の前に空白。0 / 0
要素 2 / パス 3 / フォルダ 3 で 3 本とも成立し、**Runtime/Dnn が黙って
無防備になった。** 閾値（`-lt 2`）より 1 段難しいだけで、形は同じ ——
**誤った読みが門を満たす**、この hook がそもそも無くそうとした形である。
**構造で見る形に変えた。** 合計は集約であり、情報は要素の側にある:
**「変数を根に持つ <Compile> 1 つにつき、その要素の Include から
フォルダがちょうど同じ数だけ取れたか」** を要素ごとに見る。
**この 1 本が、合計 3 本のうち 2 本を吸収した** —— 「パスを 1 つ
落とした」も「要素ごと落とした」も、要素の中で見れば同じ 1 つの不一致に
なる。残したのは下限（変数を根に持つ <Compile> が 1 つも無ければ
読めていない）だけで、そちらは要素ごとの検査では原理的に代替できない
（要素が 0 個なら、要素ごとの検査は空虚に真になる）。**重なる門を
3 つ置くのは、安全ではなく面積である。**
あわせて `Include` の '=' の前後の空白を受けるようにした（MSBuild は
許す）。したがって上の 8a は「声を上げる」ではなく**正しく 4 つとも
守る**方に落ちる。
実測（修正前 -> 修正後）:
8a 3 パス + 'Include =' に空白 Dnn 素通り -> 4 つとも検知
8b Include が変数を名指しせず
Condition だけが名指しする 素通り -> 声を上げる
8c <Compile Remove=...> 声を上げる -> 変わらず（意図どおり）
既存の 2〜6 群（';' 区切り / <None> / コメントアウト / 属性が次行 /
1 行 2 要素 / 単引用符 / 区切り無し / <Compile> 0 件 / 壊れた csproj）は
すべて変化なし。**実物の csproj は 4 検知 + 2 非検知**、速い経路も
`sh -x` のトレースで変化なし。
**docstring が実装より広く約束していたのを直した（2 件目の指摘）。**
この hook が読むのは「csproj の <Compile> 全部」ではなく
**「Include が $(OcvuPackageRuntime) を根に持つ <Compile>」だけ**である。
リテラルの相対パスで同じフォルダを指す書き方は grep の時点で落ち、
**そのフォルダは検査されない。** 意図してそうしてある（プロパティ経由が
現在の唯一の書き方）が、網羅していると読ませない。**この branch では
「理由と実装のずれ」を既に 2 度直している。3 度目を残さない。**
**Remove= / Update= が変数を名指しすると声を上げて止まる**ことも書いた
（3 件目の指摘）。Include を持たないので 0 フォルダになる。**安全な向き
なので振る舞いは変えない** —— 次に読む人が解析器の欠陥だと思わないよう、
意図であることを明記した。
確認: `dev.ps1 test-tools` exit 0 / `sh -n` / 実物の csproj は元どおり。
このブランチが 3 回払った教訓が、それを置くための file に入っていなかった。
skill の学びを足した commit（e68bee5）は hook の一件より前で、**M7 が
.claude/ を 1 行も触らなかったのと同じ形をこのブランチ自身が作っていた。**
**既存の「合計だけを固定した検査は、中身の入れ替えを通す」を広げた**
（新しい節を並べていない）。見出しは「**数を見る検査は、誤った読みに
満たされる**」に一般化し、struct の layout の例はそのまま先頭に残した ——
そこへ 2 例目として hook の 3 版を表で足した:
版 1 フォルダが 2 つ以上読めた 4 つ中 2 つしか読めない誤読が通った
版 2 合計 3 本 同時に満たせた（要素 2 / パス 3 /
フォルダ 3）。1 フォルダが無防備
版 3 要素ごとに、パス数と一致するか 閉じた
要点は 3 つ書いた。**版 2 は版 1 を難しくしただけで、問いは変わっていない**
（3 本とも合計に対する算術なので釣り合う）。**閉じたのは問いを変えたとき**
（合計は十分か -> フォルダを出すはずだった要素は全部出したか。**合計は集約で、
情報は要素の側にある**）。**構造の門は数の門を消せる**（版 3 の 1 本が版 2 の
3 本のうち 2 本を吸収した。残った下限だけは要素ごとの検査では代替できない ——
要素 0 個なら空虚に真になる）。一般形は「**数が正しく見えるかではなく、
誤った読みは何を出すかを問う**」。
**3 版とも見つけ方は同じ**（読み返してではなく、著者が想像していない形を
食わせた）ことも 1 行入れた —— skill の主題そのものなので、繰り返しではなく
補強として置いた。
**膨らませないために 1 つ畳んだ。** e68bee5 で足した
「2 つの assertion が対になって初めて 1 つの門になる」は、新しい教訓
（重なる門は面積であって安全ではない）と**同じ問い「門を何本置くか」に
別々の答えを与えていて、並べると読み手が矛盾を踏む。**
1 つの節「**門を何本置くか —— 単独で何を捕まえるかで決める**」に統合し、
2 行の表を散文へ落とし、見分け方を 1 行に締めた: **その 1 本を消したとき、
他のどれも捕まえない壊し方を挙げられるか。挙げられれば対、挙げられなければ面積。**
実測の中身（両 assertion の単独での穴、splatting では依然抜けられること）は
落としていない。差分は +52 / -18 行。
`CLAUDE.md` の skill 表も 4 つ -> 5 つに直した（見出しを改名したので、
写していた古い見出し名もそこで消えた）。
確認: `dev.ps1 test-tools` exit 0 / documentation link check 219 件・壊れ 0。
ayutaz
added a commit
that referenced
this pull request
Sep 10, 2026
設定はすでに変更済みで、この変更はそれに文書を合わせるものである。 `Web wasm32 (cross-build)` / `Web browser E2E` / `Package web-wasm` の 3 本を 必須チェックへ昇格させた（21 → 24 本）。**帰結: Web のレーンは、いまは 赤ければ merge を止める。** 根拠は実測である —— #63 以降に merge された 11 本の PR（#63〜#70、#72〜#74） すべてで 3 本とも success だった。当初は「直近 5 本」と書いたがレビューで 指摘されて数え直したところ、根拠はもっと強かった（旧記載の並びは「直近」でも 「連続」でもなく、何も指していなかった）。モバイルの 2 本が M4 の直後は必須外で 2026-08-31 に昇格したのと同じ手順である。 設定は required_status_checks だけを PATCH した —— /protection への PUT は 送らなかった項目を消しうる。変更後に strict / enforce_admins / 直線履歴 / force push 禁止 / 削除禁止 / レビュー必須数がいずれも元のままであることを 確認した。 CLAUDE.md は「必須チェックの正本はこの表ではなく GitHub 側の設定である。 増やしたらこの表も一緒に直すこと」と書き、さらに「二重に書かれているのは 両 README の 2 段落だけという状態を保つ」と書いている。その 3 箇所を同じ commit で直し、CLAUDE.md の列挙 24 件が API の 24 件と過不足なく一致する ことを機械で突き合わせた。 必須でないものを実測し直したら 6 本ではなく 9 本だった —— CodeQL の集約 check と、PR では skip される Unity の結果公開 job 2 本が漏れていた （旧記載の「9 本」も同じ穴を持っており、実際は 12 だった）。docs/roadmap.md の M6 節が「必須にするかはまだ決着していない」のまま残っていたので解消した 項として書き直し、両 README がリンク済み module を 8 つと書いていたのを 9 つ に直した（dnn が抜けていた）。 AI レビュー 2 回で、こちらが作り込んだ欠陥が 2 件出た。どちらも編集した本文の 中身は正しく、周囲との接続だけが壊れている形である: (1) 既存の閉じ記号の 直前に開き ** を挿したため対応がずれ、足した文が太字にならず生の ** が本文に 出ていた。(2) 必須外を 9 本に直したとき「残る 3 本は…」と書いたが 9 - 5 = 4 で、 読者が数えると 8 本で止まる。レビュアーは「偶数か」ではなく記号の対応そのものを 追っており、そちらの検算のほうが強い —— 行ごとの偶奇は必要条件でしかない。 確かめていないこと: GitHub の実レンダラでの描画は見ていない。Unity の結果公開 2 本が「PR では常に skip」かは 4 本の PR での実測にとどまる。gh pr checks が 返すのは各 check の最終結果なので、「一度も赤くならなかった」ではなく 「最終的に緑だった」である。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
M7 が完了したのに、文書・skill・hook が追いついていなかった。根本原因は機械で確かめられる ——
git log -- .claude/によれば、M7 の 3 つのコミット（be5615f/e1b0930/5967b82）はskill も hook も 1 行も触っていない。 最後に触ったのは #69 である。
読むだけの監査を 3 本並行で走らせ、74 件を洗い出した（
CLAUDE.md・README 系 21 /docs/**24 / skill・hook 24 + 実装者が「拡張子ではなく主張を grep して」見つけた 5 件）。72 件を適用、却下 0、7 件は理由を明記して見送り。
1. これは文書だけの PR ではない —— hook に live な欠陥があった
check-unityengine-leak.shは「Runtime/InteropとRuntime/CoreにUnityEngineを混ぜない」を守る hook だが、L3 の shim が実際にコンパイルするのは 4 フォルダである
（
CvUnity.Runtime.Shim.csproj:27-30のInterop/Interop.Dnn/Core/Dnn。M7c が後ろ 2 つを足した）。hook は前 2 つしか見ていなかった。
発火させて確かめた（修正前 → 修正後）:
Core/InteropInterop.Dnn/DnnUnityIntegration/Plugins（shim が見ない）つまり
Runtime/Dnn/にUnityEngineを書くと、hook は黙って通し、L3 の shim ビルドが壊れる状態だった。CI は何も言わない —— 誰もそこに書かなかっただけである。
一覧はハードコードしていない。csproj から導出する。 5 つ目の
<Compile Include>（
Runtime/Cuda）を足すと、hook を 1 行も編集せずに検知対象へ入ることを確認した。csproj が読めないときは黙って通さず、そう言って落ちる。
同じ欠陥を 3 度繰り返した（これが最も高く付いた）
導出そのものは正しくても、読みが正しいことを数で守ろうとして 3 度すり抜けられた。
Includeにセミコロン区切りで複数パスを書ける。4 フォルダを 2 行に分けた csproj から 2 個しか読めていないのに番人が通り、InteropとCoreが素通りしたInclude =に空白のある要素 1 つで「要素 2 / パス 3 / フォルダ 3」。3 つとも成立してRuntime/Dnnが無防備<Compile>は 1 つ残らず 1 個以上のフォルダを産む一般形: 検査が何かを数えているとき、問うべきは「その数が正しく見えるか」ではなく
「誤読は何を返すか」である。 算術は集約を比べ、構造は要素の中を見る。情報があるのは後者。
3 版とも、見つかった経路は同じである —— 読んで、ではなく、作者が想像しなかった形で
発火させて。この教訓は
prove-a-check-worksに入れた。2. 文書
CLAUDE.mdの現在地が M6 のまま、計画一覧が M6 で止まっていた（M7 の計画は 4 本ある）docs/**のどこにも「M7 は完了した」と書いた文が無かった —— 5 件の判定が 4 節に散っていたので、M5 / M6 と同じ形の要約を足した。判定表が記録している穴は平らにしていない
（dnn は実機で 1 度も動いていない、
ocvu_dnn_net_forwardの.clone()に再現テストが無い、MLAS / ONNX Runtime が依存 allowlist から見えない、
WITH_CAROTENE/WITH_KLEIDICVが未監査、third-party のライセンス集合が platform ごとに実際は違う）
の module は 1 つも無い」、決定 4「
Modulesに dnn は入っていない」、M7a 判定「実行されたのは2 計画」。いずれも同じ文書の別の場所が反証していた
残っていたが、実測では 13 回起動し直近は連日 green（
gh run list --event schedule）。毎日動いている検査を「無い」と読ませる形だった
abi-ownership-and-versioning.md§4 の「全 9 module」→ 103. skill と hook
add-abi-functionが 存在しない一覧へ誘導していた ——native/CMakeLists.txtのOCVU_SOURCESに足せと書いてあるが、M7b 以降それはnative/modules.cmakeから組み立てられる。profile の軸が丸ごと欠けていた（
Interop.Dnn/NativeMethodsDnn/defineConstraints、そして profile module では
reachable: trueだけでは足りないこと）add-a-platformの直す場所の一覧を M7 の実物に合わせたmilestone-complete/prove-a-check-worksに M7 の学びを入れた初めて 1 つの門になる」が、上の「3 つの番人は面積だった」と同じ問いに逆の答えを出していた。
判別基準（その番人が単独で捕まえる壊れ方を挙げられるか）を添えて 1 節に統合
AI レビュー（PR 前、別エージェント）
1 回目: REQUEST CHANGES（Important 1 / Minor 3 / nit 2）
最も重かったのは README に書いた「ここで説明している 2 つは v0.3.0 に入っていない」が誤り
だったこと。
git cat-file -e v0.3.0:<path>でRenderTextureConverter.cs/bindings/spec/stereo.json/native/src/ocvu_aruco.cpp/docs/performance.mdがいずれも当時は不在、
api-map.mdは v0.3.0 で 27 本・HEAD で 57 本。同じファイルの 343 行と正面から矛盾していた。 これはこの掃除が避けようとしていた失敗そのもの —— 古い記述を新しい断定で
置き換え、その新しいほうが間違っていて、しかも検証済みに読める。列挙をやめ、tag から数え直した。
2 回目（スコープを絞って）: APPROVE WITH FINDINGS —— 上表の版 2 がここで見つかった。
レビュアーは読むだけでなく発火させた ——
block-bulk-git-addを 14 通りの書き方で撃ち（
-A/./--all/:// 連結コマンドは阻止、-u/commit -a/ パス指定は通過）、新しいヘッダコメントが実装と一致していて弱まっていないことを確認。nightly の 13 回、
必須チェックの 21 contexts、リンク検査 219/0 も独立に再現している。
1 点、実装者の反論を採ってレビュアーと私の当初の見立てを退けた。 dnn の CI 被覆について、
「CI から見えない」は言い過ぎだった —— shim は
Interop.Dnn/Dnnを無条件にコンパイルし（生成された
NativeMethods.Dnn.g.csにはOCVU_PROFILE_DNNの守りが無く、gate は asmdef だけが持つ）、
DnnInferenceTestsは実物の DLL を叩く。NonStandardProfileCompile.Tests.ps1が compile するのは合成したdnnprobe.jsonである。空いているのは
OCVU_PROFILE_DNNを立てた Unity + IL2CPP、つまり stripping の側だけで、その境界を
CLAUDE.mdに書いた。意図的に見送ったもの
（「PR 1 回 + main 1 回」）は失効している —— feat(web): M6 — Web / Wasm を 6 つ目の platform として足す #63 / feat: API 拡張 26 本 —— 姿勢 / ArUco / imgproc / core / マッチング / ステレオ #69 / feat(m7): 低コピー経路の実測、C ABI / C# の module 分離、CUDA 同梱の判断 #70 / feat(m7c): dnn を opt-in profile として足す（作業中） #72 / fix: test-unity-tarball の Graphics 除外漏れと、setup-emsdk v16 への追随 #73 の 5 本で緑である。
文書には現在の証拠と「未決」であることだけ書いた。昇格は人の判断である
$(OcvuPackageRuntime)を名指す
<Compile>だけを読むためで、docstring にそう書き、何を除外するかも書いた<Compile Remove=...>/Update=...は声を上げて落ちる（hook が無効化される）。安全側なので挙動は変えず、意図であってパーサの欠陥ではないと記録した
確かめていないこと
dev.ps1 testは私が独立に回して exit 0。test-toolsと リンク検査（219 / broken 0）も緑shellcheckが無く、hook はsh -nまでしか確かめていない（CI が見る）