スモークテスト・E2E・受入検証などの自動ゲートが ok/ng の二値だと、「環境起因でそもそも評価できなかった」（依存ツール不在・ブラウザ起動失敗・対象サーバー未起動）が「評価して落ちた」と同じ失敗側に潰れ、環境事故がアプリの退行として記録・集計される。ゲート信号を読む側（人・AI・統計）の判断材料が汚染され、実施率や失敗率の指標も黙って歪む。

判断基準

• 判定を pass / fail / inconclusive（評価不能）の3値にし、終了コード・レポートの status も3値に対応させる。既存の読み手を壊さないよう、レポートのスキーマ拡張は additive にする（既存の boolean は維持し、新フィールドを追加）。
• inconclusive の範囲は決定的に列挙できるものに限定する: セットアップ失敗（依存ツール不在・実行基盤の起動失敗）と、一度もページ評価・対象到達が成立する前の接続クラスエラー（接続拒否・名前解決失敗など、対象が存在しないことを示すエラー種別の固定リスト）。判定は設定で拡張可能にせず固定リストの純粋関数にする（拡張可能にすると語彙増殖の入口になる。不足が実測されたら追補する）。
• タイムアウトは inconclusive に含めない。遅いアプリと落ちたサーバーを区別できないため、fail 側に倒すのが安全（偽の「環境のせい」で退行を見逃すより、偽の fail を人が調べ直す方が安い）。
• 一度でも評価が成立した後の失敗はすべて fail。評価成立後のネットワーク断はアプリ退行の可能性を排除できない。
• inconclusive でも証跡レポートを必ず書く（理由文字列付き）。セットアップ失敗でも出力ディレクトリを作って書き、「終了コードだけで理由が分からない」状態を作らない。

却下した代替案

• 判定語彙の4値化（SHIP / DO NOT SHIP 等の verdict 内蔵）: 判定は証跡を読む側に委ね、ツールは status の3値までに留める。
• タイムアウトの inconclusive 化: 上記の誤分類リスク。
• 既存 boolean の廃止と status への一本化: 配布済みドキュメント・既存の読み手を壊す。additive で十分。

検証

検知器の変更なので、故意ずれ検体で各分類を実測する: 対象サーバー未起動→評価不能、実行時エラーを起こす対象→fail、正常→pass、依存ツールを PATH から隠す→評価不能、評価成立後に接続を断つ→fail（評価不能に誤分類されないこと）。集計側（実施率などの統計）があれば、評価不能が母数に入るのにどの内訳にも現れない「不可視の穴」ができていないかも確認する。