plan-to-spec: spec-finalize が --spec を 1 つしか受けず、既存の複数ファイルの確定仕様へ溶かすと残りのファイルがコミットに入らないまま ok で終わる #1715

何を見つけたか

plan-to-spec の plan-to-spec-steps.py spec-finalize は --spec を 1 つしか受けず、コミットに入れるのは「その 1 ファイル・索引・用語集・消した設計」だけである（cmd_spec_finalize の paths）。

設計を既に複数ファイルに分かれた確定仕様のディレクトリ（例: docs/specifications/writing-pipeline/01-overview.md〜09-tests.md）へ溶かし込むと、--spec に渡さなかった書き換え済みのファイルはコミットに入らない。status: ok で終わるため、見落とすと「設計は消えたが仕様の半分が未コミット」のまま push される。

あわせて、用語集の pending_source を持つ語の source は、すべて --spec に渡した 1 ファイルへ移る。語ごとに定義の在るファイルを選べない。

再現:

1. 確定仕様のディレクトリに 2 つ以上のファイルがあるリポジトリで、設計の内容を 03 と 05 の 2 ファイルへ書き込む
2. spec-finalize --spec <03> --design <設計> を打つ
3. status: ok。git status に 05 の変更が残る

どこで見つけたか

takemi-ohama/novel の issue #143 の確定仕様化（PR #152）。worker が spec-finalize の直後に残りの 6 ファイルを git add して git commit --amend で同じコミットへ入れて回避した。

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

スクリプトは NDF プラグイン（devbasex/ai-plugins）にあり、開発対象リポジトリでは直せない。#143 の受け入れ条件は段 8 の進め方の手順書と検査であり、NDF の工程のスクリプトは含まない。根拠: 開発対象のリポジトリの外の不具合（MVV 版 3）。

直さないと何が起きるか

既存の確定仕様が章ごとのファイルに分かれているプロジェクトでは、確定仕様化のたびに手で amend する手当てが要り、忘れると仕様の一部が未コミットのまま残る。用語の出所が定義の無いファイルを指すことがある。

案: --spec を複数受ける（nargs="+"）か、「書き換えた既存の仕様」を受ける --also を足し、それらもコミットに入れる。用語の出所は語ごとに、定義を含むファイルを選ぶか、明示できるようにする。

由来

issue #143（takemi-ohama/novel、PR #152）