ツールの拡張（プラグイン・エージェント定義・テンプレート等）を配布するとき、定義の識別子に製品名の接頭辞を付けるかは好みではなく、その識別子が置かれる名前空間の性質で決まる。

判断基準

• ツール全体で共有されるディレクトリへ実ファイルとして置かれる識別子には接頭辞を付ける。一般名は他ツール・他手法の定義と衝突する。
• パッケージやプラグインの名前空間で自動的に修飾される識別子は接頭辞なしで残す。付けると二重修飾になる。
• 両方が同居する（同じ機能を複数クライアントへ配布する等）場合、非対称のままにする。見た目を揃えたくなるが、名前空間の性質が違う以上、対称性は誤った統一。非対称の根拠を配布物の本文に1段落書き残すと、後から「揃え忘れ」と誤認されない。

なぜ衝突が危険か

共有名前空間での衝突はエラーにならず、片方の定義が黙って使われる形で表面化する。呼び出し側は名前を渡すだけで成功するため、意図しない定義で実行されても unknown エラーで止まらない。これは改名時に特に危険で、旧名の定義が環境に残っていると、新名へ移行したつもりで旧本文が実行され続ける。

検証（改名を機械で守る）

この種の識別子は「ファイル名」「定義ファイル内の名前フィールド」「呼び出し側で渡す値」の3か所に現れる。整合チェックが「その定義が指す中身」（モデル名・設定値等）だけを見ていると、定義自身の識別子は無検査のままになりやすい。改名前に、三者一致（期待する識別子・ファイル内の識別子・ファイル名の stem）と接頭辞規則を不変式として検査へ追加する。検知力は故意ずれ3種（旧名へ戻す・誤字を入れる・識別子の行を削除する）で非ゼロ終了を確かめ、復元後に green へ戻ることまで見る。