プロセス・OS・デバイス・IME・外部レンダラなど、相手側の反映が非同期または非決定な操作では、「呼び出しが返った／例外を投げなかった」ことを成功の証拠にしない。最適化するのは『意図した効果が実際に起きたかを、観測可能なシグナルで確かめてから次へ進むこと』、避けるのは『呼び出しの正常終了・例外の不在・情報取得の成功を、効果が起きた証拠と推定すること』。見かけの成功と確認された成功を別物として扱う。

判断基準

• 非同期・子プロセスのライフサイクルは、終了・エラーの通知を起動時点から固定的に購読し、その結果ハンドルを保持する。停止処理の中で初めて購読を張ると、既に終了していた場合に通知が二度と来ず、待ちが永久にハングして元エラーを隠す。停止・シグナル送信は呼び出しの戻り値でシグナルが生存プロセスに実際に届いたかを判定し、『呼んだのだから自分で止めた』と推定しない（届かなかった＝自発終了として扱う）。in-flight な処理は流入を止めてから drain し、確定させる。集合のスナップショットを取るだけでは『終了待ち』にならない。
• 副作用の反映は、呼び出しの完了が『投函までしか保証しない』ものとして扱う。入力・貼り付けのような操作は、番兵となる判別用の値を先に置いてから実行し、実際の反映を読み戻して確かめる。固定の待ち時間を反映完了や準備完了の代用にしない（負荷時のみ遅延して破綻する）。
• 前提・能力の preflight は、問い合わせが例外を投げないことでなく、実効を反映するプロパティの値そのもの、または対照条件（ある起動フラグの有無で挙動が変わるか等）での実起動で確かめる。存在列挙・情報取得のような『ゲートを素通りしうる』クエリを権限・能力の判定に使わない。無言で失敗する経路（フラグ付きだと黙って起動しない等）は、正常に動く対照と突き合わせて確定する。
• 生成・録画・描画などの成果物の成否は、走行ログや例外の不在でなく、成果物そのもの（最終フレーム、レンダリング結果、実応答）を観測して判定する。

なぜ

呼び出しの完了は、しばしばイベントの投函・情報の取得までしか保証せず、実際の効果は後から非同期に起きるか、条件次第で黙って起きない。見かけの成功を成功として扱うと、中途で壊れた成果物を有効とみなす、権限不足をすり抜ける、早期クラッシュのハングが本来のエラーを覆い隠す、といった事故になる。単体・低負荷では再現せず負荷時や境界でのみ出るため切り分けも難しい。観測点を『効果側』に据えると、これらを構造的に捉えられる。

適用条件・境界

• 操作側が決定的でも、相手（プロセス・OS・デバイス・IME・外部レンダラ）の反映が非同期／非決定な経路に効く。相手が同期的でモックのように決定的なら、素直に待ちを詰める方が軽い。
• これは『不変条件を最も内側の機構に強制し、呼び出し側の遵守を信頼境界にしない』姿勢や『テストの緑を額面で信じない』偽陰性対策とは軸が別で、実行時の外部・非同期操作の完了検知の正本を効果側に置く姿勢として扱う。併用する。

検証

早期失敗（不正な起動引数、権限の剥奪、入力デバイスの不在、途中でのリソース失効）を意図的に起こし、(1) 呼び出しは例外を出さないのに効果が無いケースで確実に『失敗』と判定できること、(2) 起動時からの固定購読が『既に発火済みなら即解決』になり待ちがハングしないこと、(3) 番兵の読み戻し・実効プロパティ・対照起動・成果物観測の判定が実結果と一致することを確認する。反映遅延は負荷を与えた状態でも再現する。

根拠（synthesize 元）

• 682 Node.js child_process の exit/error は spawn 直後に固定 Promise で購読し、停止処理側では後から購読しない（kill の戻り値で自己停止と自発終了を判別）
• 680 子プロセスの graceful shutdown は「すでに終了済み」を先に扱い、待機を有界にする
• 664 非同期イベントの終了処理は流入停止→drain→リソース解放の順にする
• 685 macOS 自動化の日本語入力はクリップボード経由が確実で、キーイベントは投函までしか保証されない（番兵で反映を読み戻す）
• 681 macOS のアクセシビリティ権限の preflight は実効プロパティで判定する（プロセス列挙は権限不足でも成功する）
• 678 Electron アプリは remote debugging フラグを黙って起動拒否することがある — 実起動検証を対照付きで先に行う
• 687 応答時間が非決定なAIチャットのデモ録画は末尾フレームで成否を判定する（走行ログでは画面状態は分からない）