検査のプランの構造改善が --sync-command を渡さず、生成元に触れる改善が push で止まる #2049

何を見つけたか

supervise.py new check が作る検査のプランの refactor のステップは、cross-refactoring の drive.py に --sync-command を渡さない。.ndf/supervise.json の sync_checks に build（bash scripts/build-runtime-plugins.sh）があっても使われない。

改善項目が生成元（scripts/build-runtime-plugins.sh の installer の雛形）を変えると、push の直前に生成物（Kiro の install.sh 10 本）が作り直されず、pre-push の「生成物が古い」で push が落ちる。手で生成物を作り直してコミットしても、台帳に無いコミット（stray）として「公開してよくないコミット」で拒まれる。

どこで見つけたか

• PR Kiro の MCP 導入で default.json に tools を持たせる（#1873） #2043（Kiro 用の導入スクリプトが作る default.json に tools の欄が無く、MCP のツールを呼べない #1873）の検査 ~/.local/state/ndf/sv/fix-1873/check.json の refactor のステップ（2026-10-17）
• 雛形: plugins/ndf/scripts/supervise_lib/templates.py:234 付近（--budget-minutes だけを足している）
• 拒む側: skills/cross-refactoring/scripts/refactor_lib/publish.py の _require_publishable・_sync_generated

なぜこの変更の範囲外なのか

#1873 の受け入れ条件は Kiro で MCP のツールを呼べることで、検査のプランの雛形は対象に含まない。根拠: MVV なし

直さないと何が起きるか

生成物を持つリポジトリで、生成元に触れる構造改善が採られるたびに検査が refactor で止まり、conductor が状態ファイルとプランを手で直すことになる。

起票者の推定

• 渡す値は sync_checks の build から取るのがよい（推した出所: .ndf/supervise.json と cross-refactoring の SKILL.md の --sync-command の説明）

由来

PR #2043