id:変更時の移行方針Accepted (reconsideration proposed in 0013)
外部評価レビュー(テスト知識管理のGit-nativeモデル_評価レビュー_有用性判定と修正指示.md P2)で、feature.ymlのid:を変更すると同一Featureとして追跡できなくなるという制約が、設計上の既知事項でありながら利用者向けドキュメントに明記されていない、との指摘を受けた。
現状の実装(src/id_cache.rs)は、Feature idをfeature.ymlのid:フィールドから読み取ることでディレクトリのリネームには追従できる(論文§3.3)。しかしid:フィールドの値そのものを書き換えた場合、changes compute(論文§3.2〜3.4)は旧idのFeatureが削除され新idのFeatureが追加されたものとして扱い、両者を同一Featureとして結びつける手段を持たない。版履歴(derived_from)がその時点で断絶する。
markharness feature rename-id <old> <new>が過去のマイルストーンに遡ってchanges/*.yamlを書き換える、またはid_aliasesのようなマッピングファイルを追加する)。feature.ymlにaliases: [旧id, ...]を持たせ、changes computeが旧idの履歴も辿れるようにする)。選択肢3を採用する。移行コマンド・エイリアス機構のいずれも実装しない。
理由：
changes computeの「2つのtree SHAを比較するだけ」というモデルの単純さ(論文§3.2〜3.4の中核的な設計上の利点)を損なう。id解決の経路が複数に分岐し、キャッシュキー(§3.3)・true_divergences判定(§3.4)の双方に例外パスが増える。docs/cli-manual.md 1.10節に、id:変更時に版履歴が断絶すること、および移行手順が現状存在しないことを明記した(利用者が誤ってid:を書き換え、履歴の断絶に気づかないまま使い続けるリスクへの対処)。id:変更後も履歴を追跡したいという具体的な要望が出た場合、上記選択肢1・2を再検討する。