自分以外の環境で動く配布物（プラグイン、拡張、共有設定）がホスト側の拡張点（起動時フック、接続時コマンド、動的な設定生成）に依存するとき、正常系が動くことだけ確認して採用すると、利用者環境で拡張点が失敗した瞬間に何が起きるかを知らないまま配ることになる。

判断基準

• 採用可否は「正常系で動くか」ではなく「失敗したとき劣化で済むか」で決める。失敗時にその機能だけ無効になるなら必須経路に載せてよい。接続や起動そのものが落ちるなら、任意機能へ降格するか代替経路を先に用意する。
• 拡張点が外部ランタイム（特定の言語処理系など）を必要とするなら、利用者環境にそれが無い前提で設計する。ホスト本体が同梱していない依存を配布物の必須経路へ持ち込まない。
• 自分が書く側の実装は「どんな入力でも正常終了し、何も足さない出力を返す」形に寄せる。ホストの失敗時挙動の親切さに賭けない。

検証

拡張点の指定先を意図的に壊し（存在しない実行対象、不正な出力）、ホストが劣化するのか停止するのかを実測する。失敗時挙動はドキュメントに書かれていないことが多く、書かれていても実装が追随しているとは限らないため、一次情報より再現結果を優先する。

落とし穴

自分の環境で動いたことは利用者環境で動く根拠にならない。開発者は必要な処理系を既に持っているため、依存の欠落にもっとも気づきにくい立場にいる。