全量テストスイートが数分かかるリポジトリで、実装・デバッグの反復のたびに全量を回すと、反復ループの支配項がテスト実行になる。特に AI エージェントへ実装を委譲する並列開発では、律速境界の反復コストがそのまま壁時計を決める（実測: 全量約2.5分を反復のたびに実行していた実装者が境界全体の律速だった）。

vitest には未コミット変更のモジュールグラフに関連するテストファイルだけを選択する changed フラグがあり、通常の単体プロジェクトだけでなく Storybook の addon-vitest ブラウザモードのプロジェクトにも効く（story → コンポーネント → 変更ファイルの依存を辿る）。passWithNoTests を併用し、関連テストがゼロのときは正常終了させる。実測では全量約2.5分（単体210件＋ストーリー343件）に対し、1コンポーネント変更時は関連9テストのみ十数秒で完了した。

落とし穴

• 設定ファイルが dirty だと全件実行にフォールバックする: vitest の forceRerunTriggers のデフォルトにより、package.json や vite/vitest 設定ファイル自体が未コミットだと changed 指定でも全テストが走る。仕組みを導入した直後にそのまま計測すると「効いていない」と誤認する。設定変更をコミットしてから効果を計測する。
• 動的 import は依存グラフに乗らない: 実行時にパスを組み立ててロードされる資産（ロケール別の i18n メッセージ等）は changed が拾えない。テスト用 Provider などが静的 import している経路があるロケールだけ検知され、それ以外は素通りする。乗らない資産の変更は完了時の全量実行で担保する運用に倒し、その分担をリポジトリの AI 向け規約に明記する。
• 導入前に「どこが遅いか」を測る: エコシステムによっては affected-only 相当が既に組み込まれている。Go はビルド/テストキャッシュがコンテンツハッシュベース・パッケージ単位のため、全量コマンドでも実質差分のみ実行（キャッシュ時数秒）であり、追加機構を作らない判断が正しい。遅いスイートにだけ仕組みを足す。

運用への接続

「反復中は affected-only、完了ゲート（レビュー依頼・完了報告前）は全量を1回」という分担をリポジトリの AI 向け規約ファイルに書く。AI エージェントは規約に書かれていない限り完了条件のコマンド（全量）を反復中も回しがちで、これが委譲開発の反復を数倍遅くする。

検証

選択機構そのものを2点で検証する: (1) クリーンツリーで実行し、対象ゼロで正常終了すること。(2) 1ファイルだけ合成変更を入れて実行し、そのファイルに関連するテストだけが選ばれること（件数と対象ファイル名で確認）。