開発中のリポジトリで cross-refactoring を回すと、骨組みが指すのは配布済みの版である #534

何を見つけたか

このリポジトリ自身の開発で cross-refactoring を回すと、動くのは配布済みの Skill である。
開発中のリポジトリで直した refactor.py は使われない。

#518 の直し（start-round が RUNTIMES を返す）を実装した直後に、その cross-refactoring
を構造改善の工程として回した。骨組みの for a in $RUNTIMES は、配布済みの v10.9.0 が
返さないため未定義のままだった。

$ "$SCRIPTS/refactor.py" start-round 529
ROUND=1
ROUND_KIND=test
...
（RUNTIMES は返らない — $SCRIPTS は配布済みの 10.9.0 を指している）

回避はできる。 状態ファイルの runtimes を読んで自分で設定する。

RUNTIMES=$(python3 -c "import json;print(' '.join(json.load(open('$TMP/cross-refactoring-rf<PR>-state.json'))['runtimes']))")

どの手順書にも書かれていない。

この例の RUNTIMES は ndf v10.10.0 以降で起きない。 start-round（scripts/refactor_lib/commands/setup.py の cmd_start_round、:532-533）が RUNTIMES / RUNTIMES_CSV を返す形で配布済みである（タグ ndf--v10.9.0 の setup.py では init の出力にだけあり、ndf--v10.10.0 で start-round にも入った）。#518 は閉じている。

残る課題は、Pull Request のマージ前に直した Skill を、同じ Pull Request の構造改善で使えないことである。 例は解消したが、骨組みが配布済みの版を指す仕組みは変わっていない。

どこで見つけたか

• plugins/ndf/skills/cross-refactoring/SKILL.md の「実行」節（$SKILL_DIR の解決、:239-244 の候補の並び。${CLAUDE_PLUGIN_ROOT} → <この Skill のディレクトリ> → .kiro/skills → ~/.kiro/skills の順で、開発中のリポジトリを見る候補が無い）
• 実測: PR Fix: 工程が止まる 2 か所と push の退避（#518 / #524） #529 の構造改善で、開発中のリポジトリの直しが効かなかった

実行する scripts の位置を決める bash は、同じ形の写しが 4 か所と、手順の参照 1 か所にある。 PLUGIN_ROOT='${CLAUDE_PLUGIN_ROOT}' の行で検索した結果である。

4 か所の写しで DEV_ROOT / projects-sync.sh / git rev-parse --show-toplevel を検索すると、いずれも出力なし。

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

#518 / #524 の受け入れ条件は refactor.py と scope.py と push の経路に閉じており、
Skill のディレクトリをどう解決するかは対象に含まない。計画の「やらないこと」にも、
他の Skill への変更を挙げている。

直さないと何が起きるか

このリポジトリの開発では、直した当人が直した結果を使えない。 直しが届くのは配布した
後であるため、同じ版のうちに 2 回目の構造改善を回すと同じ場所で止まる。

開発版のチャネル（develop。docs/versioning-and-distribution.md）でも、変更が載るのは
マージの後である。マージ前の Pull Request の中で直した結果は、開発版を入れても使えない。

SKILL.md の候補の並びは ${CLAUDE_PLUGIN_ROOT} を先に見るため、開発中のリポジトリを
先に見る手段が無い。開発中のリポジトリを指す候補を足すか、その旨を手順書へ書くかの
どちらかが要る。 前者は、scripts-lookup.md の候補 1 と同じ条件（現在地の git のトップの直下に
plugins/ndf/scripts/projects-sync.sh がある）で当てれば、他のリポジトリでの動作を変えない。この条件は
このリポジトリでだけ当たり、配布物を使う利用者の側では当たらない（scripts-lookup.md の説明のとおり）。

同じ性質の事象が #459 にある（工程名の記録が、配布済みの版に無い名前を黙って捨てる）。

由来

PR #529