041_スコアが全部同じだった構造的不具合は仕組みを変えないと動かない話

NexusCoreの包括レビューを「前回差分」で回したところ、循環依存は5組のまま、api→webapp の依存エッジは28のまま、構造系の数字が完全に同値で帰ってきました。P1最優先だった「静的解析をCIに配線する」は棚卸しで片付いたのに、構造課題の6件は一度も動いていない。

不思議だったのは、解決した項目と未解決の項目がきれいに分かれたこと。前者は「追跡解除」「依存除去」「テスト実行」のように、コマンド一発で物事が動くもの。後者は「webapp から api の逆流」「models層の不在」「READMEの数値ズレ」のように、誰かが判断して初めて動くもの。差分レビューは数値比較が本体なので、機械的に改善した点は差分として出る一方、判断待ちで溜まった課題は「動いてないから数値も同じ」になり、毎回「未解消6件」で固定される。

解決策を探して辿り着いたのは、レビューの形式ではなく「判断を生成する仕組み」の有無。前者はCIのexit codeで自動化でき、後者は「これは誰が、いつまでに、どう決めるか」の欄を毎回明示しない限り動かない。次の改善ではレビュー表に owner / due / decision_status の列を足し、未解消行がこの欄に埋まるまでレビューを完了扱いにしない運用を試す予定です。

<details><summary>▶ 技術的にどうなってるか</summary>

• 依存関係（<code>repo-review</code>スキル・言語非依存）のカスタムAST走査で自己完結的に検出。ベンダーコード混入の心配がない <code>grep -r 'node_modules/' --include='*.md'</code> のような単純なチェックでほぼ拾える類いから、静的解析（<code>ruff</code>/<code>mypy</code>）・既知脆弱性（<code>pip-audit</code>）・CIガード範囲外というテストでしか出ない類いまで、計測の観点を増やしている。
• 「除外リスト」はリポジトリによって揺れが大きく、計測そのものより除外合意のほうが時間がかかる。<code>git ls-files</code> + <code>ふくけい承認</code>を除外プロトコルに組み込むことで、再走可能にしている。
• CI保護範囲を実測すると「lint対象の自作コード」と「手元では走らせているがCIには乗っていない自作コード」の分断が見える（ruff 1,160件・tools/配下12.7k LOC）。PreToolUse hookで <code>ruff check src/ tests/</code> を編集ガードすると <code>vscode-extension/node_modules/ 3,075ファイル</code> のような追跡下バルクがCI保護範囲を食いつぶす構造も検出できる。
• 「未解消6件が3回連続で同値」は、それ自体が falsification 観測事実になる。差分レビューを続ける限り構造課題は可視化されないので、ループの出口設計を変えるのが次の手。
• 関連スキル: <code>repo-review</code>（リポジトリ品質診断）, <code>code-metrics</code>（コード行数・テスト数の3層証明）, <code>multi-llm-review</code>（差分の見落とし検出）, <code>self-inspect</code>（成果物の深点検） </details>