cross-refactoring: 全体テストを CI に任せる戦略の着手前のテストがディレクトリを {paths} へ入れ、ファイルだけを受けるテンプレートで落ちる #2096

何を見つけたか

テストの戦略が local-scoped-ci-whole（全体テストを CI に任せる）のとき、cross-refactoring の init の着手前のテストは、--scope のうちテストの置き場所とみなしたもの（ディレクトリ）を範囲テストのテンプレートの {paths} へ入れる（refactor_lib/baseline.py の locations_of・commands_of）。改修の範囲テストはテストのファイルを入れる。テンプレートがファイルだけを受けるランナー（unittest の python3 -m unittest {paths}）だと、着手前のテストはディレクトリで落ちる。

手元の再現（Python 3.14.4、tests/test_x.py・tests/test_y.py）:

着手前のテストが red になり、JUnit を読めなければ既存失敗が「読めない」になる。

どこで見つけたか

#1630 の設計（issues/issue-1630-design.md）で、要求の未決 3（{paths} に入るパスの種類をそろえるか）を判断したとき。

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

#1630 の対象範囲は「含まない: {paths} に入れるパスの種類を変えること」と定める。#1630 は入るパスの種類を契約に書き、改修の範囲テストと同じ形（ファイル）でテンプレートを試して見分ける。着手前のテストへ入れるパスをファイルへそろえるのは、範囲テストの所要の履歴（置き場所ごとの記録）にも効く別の変更である。根拠: Value 5 / Value 6（MVV 版 2）

直さないと何が起きるか

ファイルだけを受けるランナーを使い、全体テストを CI に任せるプロジェクトで、着手前のテストが毎回 red になり、既存失敗の記録が意味を持たない。

起票者の推定

• 着手前の範囲テストも、置き場所の配下のテストのファイルを {paths} へ入れる形にそろえるのがよい（推した出所: cross-refactoring の範囲テストが変わったファイルのディレクトリを discover し、テストを tests/ にだけ置くプロジェクトで落ちて fix を繰り返す #1630 の要求の未決 3）

由来

issue #1630