背景
Issue #434のnative smoke（verifier実施、2026-09-13、固定HEAD 0c6faff）で、
validate-process-commandがlauncher自身のコマンドラインを「確定fail」と誤判定する
問題が判明した。breaker断定によりharnessの三値契約の欠陥と特定された。
実測（verifier・breaker）
record_process_command（ps -ww -p <launcher pid> -o command=を1回）と
validate-process-commandの呼び出し位置は、da7e002と0c6faff（PR #446）で同じ
（binding出現 → validate-binding → 1回採取）。PR #446のrunner差分はこの区間に触れていない。
導入元はPR #401（git log -S validate-process-command）。
launcherはbindingを書いた後、digest再検証・ログファイル作成・環境設定を経てexec
（pilot-launcher.sh:820/826）するため、採取がexec前ならbashのコマンドラインが記録される。
時刻依存の観測を「確定fail」へ畳んでいる。
2回のsmoke実行でともにlauncher自身が記録されたが、Issue #407 run3（da7e002）では
claude本体が記録されていた。この差は未説明。
主張
N1のprocess-command検証をexec完了まで待つ形にし、exec未到達はfailでなくunknownにする。
判定を3分岐にする:
| 観測 |
判定 |
| 上限内にclaudeのコマンドラインになり、argsがsessionId/settingsと一致 |
pass |
| claudeになったがargs不一致 |
fail（これだけが確定fail） |
| 上限内にclaudeにならない／PID消滅 |
unknown（reason: exec_not_observed / launcher_exited_before_exec） |
追加で必要な証跡（breaker指定）
「後でexecされるはずだった」と「execに到達しなかった」を区別できる証跡を残す。
- 最初にclaudeを観測するまでの経過秒（到達した場合）
- 未到達ならstop直前のlauncherのstderrと
ps -o stat=をartifactに残す
ポーリングを足すだけで直ると決めつけない。実装後のsmokeで経過秒が短ければ競合、
上限まで未到達ならlauncher側の別欠陥として切り分ける。
設計で決めるべき点（breaker指定）
- 上限時間（既存の
N1_START_TIMEOUT_SECONDSと同じ予算内に収めるか、別枠か）
- 未到達時に残す証跡の形
担当
- 設計: agmsg_architect_claude
- 実装: agmsg_programmer_claude（負の対照: 「launcherのcmdlineを返し続けるstub」で
unknownになること、「args不一致のclaude」でfailになること、両方をbatsで）
- formal review: agmsg_reviewer_claude
- verifier: merge後、Issue #434のsmokeを再実施。(a)経過秒/(b)証跡を報告に含める
完了条件
Issue #434のsmoke再実施でmarker送信まで到達すること（fresh/resumeとも）。
この実装で扱わない範囲
- Issue #444の再修正（#444自体は投入前提の受入まで到達済みのため、merge済みのまま
クローズしてよい）
- Issue #407の4回目実行自体
README への影響
無。
Refs #395、#434、#407、#444
背景
Issue #434のnative smoke（verifier実施、2026-09-13、固定HEAD 0c6faff）で、
validate-process-commandがlauncher自身のコマンドラインを「確定fail」と誤判定する問題が判明した。breaker断定によりharnessの三値契約の欠陥と特定された。
実測（verifier・breaker）
record_process_command（ps -ww -p <launcher pid> -o command=を1回）とvalidate-process-commandの呼び出し位置は、da7e002と0c6faff（PR #446）で同じ（binding出現 → validate-binding → 1回採取）。PR #446のrunner差分はこの区間に触れていない。
導入元はPR #401（
git log -S validate-process-command）。launcherはbindingを書いた後、digest再検証・ログファイル作成・環境設定を経て
exec（
pilot-launcher.sh:820/826）するため、採取がexec前ならbashのコマンドラインが記録される。時刻依存の観測を「確定fail」へ畳んでいる。
2回のsmoke実行でともにlauncher自身が記録されたが、Issue #407 run3（da7e002）では
claude本体が記録されていた。この差は未説明。
主張
N1のprocess-command検証をexec完了まで待つ形にし、exec未到達はfailでなくunknownにする。
判定を3分岐にする:
exec_not_observed/launcher_exited_before_exec）追加で必要な証跡（breaker指定）
「後でexecされるはずだった」と「execに到達しなかった」を区別できる証跡を残す。
ps -o stat=をartifactに残すポーリングを足すだけで直ると決めつけない。実装後のsmokeで経過秒が短ければ競合、
上限まで未到達ならlauncher側の別欠陥として切り分ける。
設計で決めるべき点（breaker指定）
N1_START_TIMEOUT_SECONDSと同じ予算内に収めるか、別枠か）担当
unknownになること、「args不一致のclaude」でfailになること、両方をbatsで）
完了条件
Issue #434のsmoke再実施でmarker送信まで到達すること（fresh/resumeとも）。
この実装で扱わない範囲
クローズしてよい）
README への影響
無。
Refs #395、#434、#407、#444