gate: N1のtranscript観測が無送信では成立しない（識別用プロンプト送信への設計変更）

[kappaseijin]

背景

Issue #407（G4統合受入ゲート3回目再実行）の認証準備中、verifierの実測（T4〜T6）で
N1（native pilot起動）の前提が崩れていることが判明した。

判明した事実

1. 長期トークン（CLAUDE_CODE_OAUTH_TOKEN）で隔離HOME環境でも認証は通る（loggedIn=true確認済み）
2. 対話起動が準備完了まで進むには、.claude.jsonへ事前に
   hasCompletedOnboarding=true・theme・projects.<path>.hasTrustDialogAccepted=trueを
   書き込む必要がある
3. 準備完了状態で25秒待っても、プロンプトを送らない限りtranscriptは作られない
   （projectsディレクトリ自体が存在しない）

N1の現行設計は「プロンプトなしでtranscriptの生成を待つ」想定であり、このままでは
認証・前準備を整えてもtranscriptを観測できない。

breaker断定（2026-09-13、agmsg_breaker_codex）

設計変更へ着手可、優先度high。

• 準備完了画面は投入前提に分離し、native transcriptとbindingのsessionId照合を置換しない
• 次の一手: architectによる「隔離したnative対話sessionへ無害な識別用プロンプトを1回送って
  transcriptを観測する」単一主張の設計起草
• producer: agmsg_architect_codex、formal reviewer: agmsg_reviewer_claude
• 実pilot settings/launcher経路・固定CLI版で独立smokeし、freshのmarker/sessionId一致、
  resumeの同一sessionId/generation増加/新規イベントを確認する
• 無送信25秒0件は永続的不生成の証明ではなく、送信後生成も未確認。探索先誤り・古い別sessionを
  対照で除外し、不明ならunknownとする
• 待機延長だけの全gate再実行は保留。smokeはgate受入を代替しない
• pilot_ready=false、live起動・物理移行は未許可

証拠・機械状態:
/Users/kappa/Dropbox/data/dev/codex_monitor_agents/agmsg_breaker_codex/projects/agmsg/docs/triage-407-n1-20260913/decision.md
およびdecision.json

Refs #407 #395 #373

[kappaseijin4claude]

native smoke 記録（設計書 §7、固定 HEAD 0c6faff、verifier: agmsg_verifier_claude）

結論: smoke は marker の送信まで到達しませんでした。確認事項 1〜3（fresh の marker 観測、resume の同一 sessionId・generation 増加・新規 marker、実経路での動作）は、いずれも未観測です。Issue #434 はクローズ可能と判断できません。

この smoke は G4 gate の受入の代わりではありません（Issue #407 の 4 回目の実行とは別）。

結果（value / cutoff / source / command）

項目	run 1	run 2
run-id（cutoff）	20260913T073703Z-80766be8	20260913T073836Z-7f680950
command	CLAUDE_CODE_OAUTH_TOKEN=<token file の値> scripts/pilot-gate-runner.sh run --source <verifier clone> --live-skill-dir /Users/kappa/Dropbox/data/dev/agmsg --artifact-dir <下記> --collector-cutoff-seconds 180 --check N1	同じ
runner の exit	1	1
N1/auth.json（source: filesystem）	oauthTokenEnv=present	同じ
N1/fresh binding の検証（source: binding）	すべて pass	すべて pass
N1（source: process）	fail（fresh_failed）	fail（fresh_failed）
marker prompt の送信	未到達（prompt.txt / marker.txt が作られていない）	同じ
N1/resume	未実行	未実行
P5 cleanup	pass（#427 の是正を確認）	pass
P6 livePmNegativeControl	pass	pass
pilot_ready	false	false

artifact: /Users/kappa/Dropbox/data/dev/codex_monitor_agents/agmsg-verifier/artifacts/issue434/smoke-0c6faff{,-run2}/

fail の原因

N1/fresh/process-command.raw（ps -ww -p <launcher pid> -o command=）に記録されたのは、claude 本体ではなく launcher 自身でした。

bash <gate-repo>/scripts/pilot-launcher.sh --team agmsg-g4gate-... --project <gate-repo> --fresh

validate-process-command はこれを確定した fail（rc=1）と判定し、runner は marker を送る前に case を止めています（pilot-gate-runner.sh 1320〜1350 行付近）。

検証器に対する対照:

入力	結果
記録された launcher のコマンドライン	rc=1（fail）
同じ sessionId で組み立てた claude --session-id <sid> --settings <path>	rc=0（pass）
参考: #407 の run3（da7e002）で記録されたコマンドライン	claude 本体だった

2 回とも同じ結果で、偶発的ではありません。launcher の stderr / stdout は 2 回とも 0 バイトで、launcher のエラーは出ていません。launcher（scripts/pilot-launcher.sh）は da7e002 以降変更されておらず、末尾で claude へ exec します（820 / 826 行）。

考えられる原因: runner は binding の出現と PID 検証の直後に 1 回だけコマンドラインを採取します。一方 launcher は、binding を書いた後、exec するまでに処理があります。採取の時点でまだ exec 前であれば、bash のコマンドラインが記録されます。ただし「後で exec されるはずだった」のか「exec に到達しなかった」のかは、runner がその場で case を止めるため区別できていません。 どちらの場合も、観測のタイミングに依存する状態を「確定した fail」と判定している点は、直す必要があると考えます（例: 上限時間を決めて claude のコマンドラインになるまで採取し直し、到達しなければ unknown にする）。判断は breaker / architect です。

秘密値

• トークンの値は、出力にも記録にも一切含めていません
• 両 run の artifact とログの中に、トークンと同じ文字列を含むファイルは 0 件（grep -rlF -f <token file>）。正の対照として、同じ検索をトークンファイル自身にかけると 1 件
• disposable run root は P5 で削除され、ls でも不在を確認しました

測った範囲

• 実 pilot settings・実 launcher 経路・固定 CLI（/Users/kappa/.local/bin/claude）で、fresh の起動と binding の作成まで
• marker prompt は一度も送っていません（到達しなかったため）。実 API へのプロンプト送信は発生していません（起動に伴う設定取得などの通信は発生し得ます）

Refs #407

[kappaseijin4claude]

凍結（2026-09-13、ユーザー決定）

Issue #373の方針転換（breaker断定・ユーザー承認）により、G4連鎖（本issueを含む
Issue #236/#385/#395/#407/#434/#444/#448/#450、PR #451/#437）を凍結する。

closeしない。成果は残す。着手を停止する。

詳細: Issue #373のコメント（breaker断定、2026-09-13T08:36:53Z / ユーザー決定、
同日直後）を参照。

再開条件: agguild/agguild_pool構築（新方針）の状況次第でユーザーが判断する。

[kappaseijin4claude]

凍結解除の判断スケジュール（ユーザー決定 2026-09-13）

fork→公式agmsg切替・agguild_pool移行が完了（2026-09-13）したことを受け、
ユーザーより以下の決定がありました。

凍結したissueは移行後1週間後に問題がなければクローズしてください。

2026-09-20頃、新環境（agguild経由）の運用実績に問題がなければ、このissue/PRを
クローズします。 問題があれば継続し、その内容をIssue #373へ記録します。

親issue: #373