G4統合受入ゲートの再実行（G4-D・harness是正後）

[kappaseijin]

背景

Issue #397（固定HEAD f0c96a5でのgate実行）は、pilot_ready=false（unknown 7）という結果で完了した。原因はG4-D（pm-pilot-pretool-guard欠落）とharness欠陥2件（abort後のP5-P7未実行、compare-liveのartifact不一致）。これらの是正が完了次第、gateを再実行する。

3回の再実行（HEAD 34bb156、da7e002、後日breaker再検証）を経て、当初の依存3件は解消済みと確認された。以下「依存（3回目差し替え、2026-09-13）」節が現行の正本。

依存（3回目差し替え、2026-09-13）

Issue #448（PR #449設計）検証で、インストール済みClaude Code(2.1.270)とIssue #444実装の
CLI版検証定数(2.1.268固定)の不一致も判明した（Issue #450）。依存に追加する。

以下の順で完了してから4回目を実行する。

Issue #448（N1のprocess-command検証の三値化）merge
  → Issue #450（N1_READY_VERIFIED_CLI_VERSIONSへ2.1.270追加、verifier実測後）merge
    → Issue #434 native smoke（fresh: marker/sessionId一致、resume: 同一sessionId・generation増加）で#434を手動close
      → 本Issue（#407）4回目実行（固定HEAD、live PM実効hook構成の読み取り対照A〜D のbefore/after採取込み）

Issue #444（N1の投入前提: onboarding/theme/trust事前書込・OAuthトークン受け渡し）は
merge・クローズ済み（受入=投入前提の充足まで到達確認済み）。

1回目差し替え時点の依存（履歴として保持）

Issue #444 merge
  → Issue #434 native smoke で#434を手動close
    → 本Issue（#407）4回目実行

• Issue manager(PM)の実作業自己実施を仕組みで防止する #236（PMの自己実施防止）はgate実行のブロッカーではない。B（pilot起動判断）の材料であり、依存に含めない
• Issue ci: bounded watch stop試験が間欠的に失敗する（発生記録・3回目で診断格上げ） #291/#443は無関係（CIのrerun負荷が減るだけ）
• gate team DBのeventsテーブル欠落はPR #428で対応済み（pass判定に回避）。決定論的なので事前の再実測は不要。4回目のrunでcleanup.jsonのclaims=passを確認することで閉じる

旧・依存（記載当時のもの、解消済み。履歴として保持）

• G4-D: pm-pilot-pretool-guardの契約と実装
• harness: abort後もP5/P6/P7を実行しresults.jsonを作る
• harness: compare-liveがharness自身のartifactを比較する（MUST blocker）

2回目（HEAD da7e002）のverifier記録でP5〜P7実行・compare-live・deny-semantic passを確認済み。

実施内容

• 依存がすべてmerge・クローズされた新しい固定HEADで、scripts/pilot-gate-runner.sh run --check allを再実行する
• 「現行PMの実hooksをlive guardとして渡す」という旧記述は撤回する。 live PMにG4 guardは無く（Issue manager(PM)の実作業自己実施を仕組みで防止する #236）、breaker断定により「live PMの実効hook構成の読み取り対照A〜D」（A: 設定3ファイルのsha256、B: hook実体5つのsha256、C: PMプロセスのargv/env keys、D: live agmsg team storageの識別子混入チェック）へ置換済み。gateの前後でbefore/afterを採取し、一致を確認する
• 結果を本Issueへvalue / cutoff / source / command形式で記録する
• pilot_ready判定はbreakerが行う（harnessのlivePmNegativeControl(新定義)がpass、かつA〜Dがbefore==afterの場合のみtrueにできる。N1〜F5がunknownならどちらにしても false）

担当

実行・記録: verifier（一時代替中はagmsg_verifier_claude）
formal review: reviewer

親issue

Refs #395

関連

• Issue gate: N1の投入前提（onboarding/theme/trust事前書込・OAuthトークン受け渡し）を実装する #444（N1投入前提の実装、本issueの直接の依存）
• Issue gate: N1のtranscript観測が無送信では成立しない（識別用プロンプト送信への設計変更） #434（N1 transcript marker設計・実装。native smoke受入待ちでOPEN）

[kappaseijin]

G4 統合受入ゲート 再実行記録（verifier: agmsg_verifier_claude）

結論: pilot_ready=false。三値の内訳は pass 0 / fail 0 / unknown 7（N1・I1・F1〜F5）。 livePmNegativeControl は pass、cleanup は unknown です。

前回（#397）の harness 欠陥 2 件（P5〜P7 の未実行、compare-live）が解消されたことは確認できました。N1 は別の原因で、また起動段階で止まりました（下記）。

実行条件

項目	値
固定 HEAD（source / gate repo / live repo）	34bb15654c596d1c048d2c634e4dc1b93ba47bb3
run-id	20260911T145306Z-1472619b
command	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 all
runner の exit	2
artifact	/Users/kappa/Dropbox/data/dev/codex_monitor_agents/agmsg-verifier/artifacts/issue407/run-20260911T235305/

結果（value / cutoff / source / command）

cutoff はすべて run-id 20260911T145306Z-1472619b の artifact です。

check	value	source	生出力（artifact からの相対パス）
P3 isolation preflight	safe=true	filesystem	isolation.json
P4 F2 containment	safe=true	filesystem	f2-containment.json
N1	unknown（fresh_unobservable）	native-cli-stderr	N1/result.json、N1/fresh/stderr.raw
I1 / F1〜F5	unknown（result_file_missing、未実行）	—	—
P5 cleanup	unknown（steps.claims だけが unknown、targetCount=0。remainingPaths=[]）	filesystem	cleanup.json
P6 livePmNegativeControl	pass（runner-status・guard digest・deny exit・deny semantic の 4 項目すべて pass）	live-pm-control	live-pm/result.json
P7 aggregate	pilot_ready=false、verdict=unknown、runId は本実行と一致	results.json	results.json

P5・P6・P7 が実行され、results.json が本実行の run-id で作られました（#405 の是正を確認）。 deny-semantic も pass になりました（#406 の是正を確認）。

N1 が unknown になった原因（今回の新しい事象）

actas gate failure operation=acquire resource=actas-delivery:<gate-repo>/run/actas.<gate-team>__agmsg_pm_pilot_claude.session observed_owner=<none> pid=83745 classification=unknown sqlite_error=<not-invoked> reason=sqlite-attempt-failed
pilot-launcher: pilot seat claim delivery gate is unavailable

gate の disposable repo には runtime DB（<gate-repo>/db/messages.db）が作られていません。 そのため launcher の actas 配信ゲート取得が失敗しています。agmsg_runtime_lock_acquire は DB が無いと stderr に何も出さずに return 1 するため（scripts/lib/storage.sh:349）、診断は sqlite_error=<not-invoked> / classification=unknown になります。

P2 と同じ手順（--no-hardlinks で clone、隔離した HOME で join.sh ... --role manager --kind seat）を scratchpad で再現して確かめました（native Claude は起動していません）。

条件	agmsg_runtime_lock_acquire	stderr
join.sh の直後（DB なし。ls で No such file）	rc=1	0 バイト
scripts/internal/init-db.sh で初期化した後	rc=0（owner の pid を返す）	0 バイト

本番の環境では DB が既にあるため表に出ない前提が、disposable 環境で露出したものと考えます。 直すのが harness の P2（runtime store を初期化する）か、launcher（取得前に初期化する、または明示的な診断を出して止める）かは、breaker / architect の判断です。stderr を出さずに失敗し、classification=unknown になる点も、別途直す価値があります（原因の特定に再現が必要だった）。

cleanup の claims が unknown になった理由も、runtime DB が無いことと同じ原因だと推測していますが、確かめていません。

live PM 負の対照について（重要）

harness の P6 が pass でも、live PM の保護を測ったことにはなりません。

• 現行 PM（pid 15355、claude --resume 6c73acb3-...、cwd /Users/kappa/Dropbox/data/dev/agmsg、--settings の指定なし、CLAUDE_CONFIG_DIR は未設定）の有効な PreToolUse は、global ~/.claude/settings.json の 4 件（5 コマンド: cc-status、cbm-code-discovery-gate、retrospective-reminder.sh、auto-allow-agent-cmds.sh、rtk hook claude）だけです。user とプロジェクトの settings.local.json には PreToolUse がありません
• pm-pretool-guard も pm-pilot-pretool-guard も、live PM の hooks に登録されていません。 harness の P1 / P6 は <live-skill-dir>/scripts/pm-pretool-guard に固定されており（pilot-gate-runner.sh:676）、live PM が実行していないファイルを測っています
• 実際の 5 コマンドは deny を返す guard ではないため、「その実体を live guard として渡す」ことは、そのままでは成り立ちません（{} を入力して実行すると副作用が出るおそれがあり、比較の意味もありません）

そこで verifier は、実行せずに読み取るだけの負の対照を gate の前後で別途採取しました。

対象	before と after
設定 3 つ（user の settings.json / settings.local.json、プロジェクトの settings.local.json）の sha256	一致
hook の実体 5 つの sha256（realpath を解決）	一致
PM プロセスの argv	一致

生出力: artifacts/issue407/live-hooks-{before,after}.tsv（diff の差分 0 件）。手順: /private/tmp/claude-502/-Users-kappa-Dropbox-data-dev-codex-monitor-agents-agmsg-verifier/7e574c05-63a4-42e8-bcb8-db6541961c86/scratchpad/live-hooks-snapshot.sh

live PM の定義と、livePmNegativeControl の扱いは、breaker に断定を依頼済みです（PM 経由）。

測った範囲 / 測っていない範囲

check	走らせたか	理由
P0〜P4	走らせた（safe=true）	—
N1	fresh の起動試行のみ。resume は未実行	fresh が unknown になったため
I1 / F1〜F5	走らせていない	N1 が pass 以外のとき harness は fault injection を行わない。F2 の fault session は起動していません
P5 / P6 / P7	harness が実行した	—
live PM の実 hooks	読み取りだけの digest 比較を実施。hook は実行していない	上記

disposable run root は harness の P5 で削除され、ls でも存在しないことを確認しました。

Refs #395

[kappaseijin]

補足: breaker 断定に基づく負の対照の整理（verifier）

breaker 断定（PM 経由）により、「live PM guard」の定義を 「live PM の実効 hook 構成」 に置き換えます。前のコメントの記録を、これに合わせて整理します。

現行 PM に G4 guard は無い（実測）

現行 PM（pid 15355）の実効 PreToolUse に、G4 の guard（pm-pretool-guard / pm-pilot-pretool-guard）は登録されていません（~/.claude/settings.json の 4 件と、user・プロジェクトの settings.local.json を解析。Refs #236）。

2 つの対照が測っているもの

対照	何を測るか	何を測らないか	run 20260911T145306Z-1472619b での結果
harness の P1 / P6（livePmNegativeControl）	live clone（/Users/kappa/Dropbox/data/dev/agmsg）の scripts/pm-pretool-guard のファイルと、その deny の挙動が、gate によって変わっていないこと	live PM の保護（live PM はこの guard を実行していない）	pass
verifier の読み取り対照 A〜D（hook は実行せず sha256 などを読むだけ）	live PM の実効 hook 構成と live の team storage が、gate によって変わっていないこと	hook の実行時の挙動	A・B と C の argv は before==after で一致。C の env と D は、この run の before で採取していない（下記）

A〜D の中身:

• A: 設定 3 ファイルの sha256（user の settings.json / settings.local.json、プロジェクトの settings.local.json）
• B: 参照される hook 実体 5 つの sha256（realpath を解決）
• C: PM プロセスの argv と、env のキー名（値は秘密を含み得るので記録しない）
• D: live agmsg team storage。詳細は下の表

この run の記録で足りないもの

run 20260911T145306Z-1472619b では、D と C の env を gate の前に採取していません。 breaker 断定の条件 1 を満たしていないため、この run の読み取り対照は「A・B・C(argv) のみ一致、C(env)・D は unknown」 です。

D の before は、断定を受けた後に、次の gate 実行に向けて採取しました（artifacts/issue407/rerun2-live-before.tsv）。

D の項目	内容	before の値
D1	live teams/agmsg/config.json の sha256 と、登録 agent 名の一覧	4cd8f3b2...、10 名
D2	live runtime DB（db/messages.db、-readonly で照会）で、gate の team 名（agmsg-g4gate-%）・pilot 名・gate の lock を含む行の件数（9 テーブル + messages + locks）	すべて 0。正の対照 messages WHERE team='agmsg' は非 0
D3	live の team 名の一覧	採取済み

注意: live storage は通常の agent 間通信で常に変わります。 実際、teams/agmsg/config.json は gate の終了 46 秒後に更新されていました（gate 名・pilot 名の混入は 0 件）。そのため D は全体の digest を比べるのではなく、「gate 由来の識別子が 0 件のままか」（D2）を主な判定にし、D1 は差分が出たら中身で説明する形にしています。

pilot_ready の扱い

breaker 断定により、pilot_ready=true とできるのは harness の livePmNegativeControl（新定義）が pass で、かつ A〜D の読み取り対照がすべて before==after の場合だけです。results.json の pilot_ready をそのまま結論にはしません。今回の run は N1〜F5 が unknown なので、どちらにしても pilot_ready=false です。

次の gate 実行（N1 の原因である runtime DB の未初期化を直した後）では、A〜D を gate の前後で採取します（after は harness の cleanup の後に、P6 とは別に採る）。

Refs #395

[kappaseijin]

G4 統合受入ゲート 再々実行記録（固定 HEAD da7e002、verifier: agmsg_verifier_claude）

結論: pilot_ready=false。pass 0 / fail 0 / unknown 7（N1・I1・F1〜F5）。 harness の livePmNegativeControl（新定義）は pass、verifier の読み取り対照 A〜D は before==after で完全に一致、cleanup は unknown です。

#423 / PR #425 の修正で、N1 は launcher の起動と binding の作成まで進みました。 そのうえで、native claude が --print モードで起動してすぐ終了するため、transcript が作られず N1 が unknown になりました（下記）。

実行条件

項目	値
固定 HEAD（source / gate repo / live repo）	da7e002daa3690de41c830df24ec5a8266046d04
run-id	20260911T153339Z-ac4b982a
command	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 all
runner の exit	2
artifact	/Users/kappa/Dropbox/data/dev/codex_monitor_agents/agmsg-verifier/artifacts/issue407/run3-da7e002/
results.json の sha256	b3ba69a96062c22bd3a938fd1a097748a8b0a1efdbf592c3e3956d234d1ac44b（runId は本実行と一致）

結果（value / cutoff / source / command）

cutoff はすべて run-id 20260911T153339Z-ac4b982a の artifact です。

check	value	source	生出力（artifact からの相対パス）
P3 / P4	safe=true / safe=true	filesystem	isolation.json、f2-containment.json
N1	unknown（fresh_unobservable）。binding の検証 12 項目はすべて pass、transcript が観測されない	native-cli-stderr、binding	N1/fresh/stderr.raw、N1/fresh/binding-validation.json、N1/fresh/process-command.raw
I1 / F1〜F5	unknown（未実行）	—	—
P5 cleanup	unknown。14 手順中 13 手順が pass、claims だけが unknown。remainingPaths=[]	filesystem	cleanup.json、cleanup-evidence/claims-before.json
P6 livePmNegativeControl（新定義）	pass	live-pm-control	live-pm/result.json
verifier の読み取り対照 A〜D	before==after（diff の差分 0 件）	filesystem、process、読み取り専用の sqlite	artifacts/issue407/rerun3-live-{before,after}.tsv

N1: native claude が print モードで終了する

/Users/kappa/.local/bin/claude --session-id 122d3665-... --settings <gate-repo>/.claude/settings.local.json
Warning: no stdin data received in 3s, proceeding without it. ...
Error: Input must be provided either through stdin or as a prompt argument when using --print

harness は native claude の stdin に FIFO を、stdout にファイルをつないで起動します（launch_n1_case）。端末（TTY）が無いため Claude Code 2.1.268 が非対話の print モードで起動し、入力が無いので終了します。 起動直後は process が生きていたので binding の PID 検証は通りますが、transcript は作られません。

隔離環境（run-isolated、使い捨ての CLAUDE_CONFIG_DIR）で対照を取りました。

起動方法	結果
stdin=FIFO、stdout=ファイル（harness と同じ形）	3 秒で rc=1、上と同じエラー、transcript 0 件
疑似端末（script）の中	8 秒後も起動し続けている、--print のエラーは 0 件

限界: 疑似端末側の画面出力は空で、対話画面そのものは確かめていません。また、使い捨ての CLAUDE_CONFIG_DIR には認証情報が無いため、TTY の問題を直しても、I1〜F5 で必要な tool の呼び出しに進めるかは未確認です（次の障害になり得ます）。

P5 cleanup の claims が unknown になる理由

cleanup-evidence/claims-before.json の readErrors の値は次のとおりです。

agmsg-g4gate-20260911T153339Z-ac4b982a:claims:OperationalError:no such table: events

gate の team DB は存在しますが、events テーブルがありません。そのため claims を読めず、unknown になっています（pilot-gate-cleanup.py の release_message_claims）。前回のコメントで「runtime DB が無いことと同じ原因」と推測したのは誤りでした。 DB が作られた今回も同じ結果です。

2 つの負の対照（breaker 断定の新定義）

対照	何を測るか	結果
harness の P1 / P6	live clone の scripts/pm-pretool-guard のファイルと deny の挙動が、gate によって変わっていないこと（live PM の保護は測らない。現行 PM の実効 hooks に G4 guard は無い。Refs #236）	pass
verifier の読み取り対照 A〜D（hook は実行しない）	A: 設定 3 ファイルの sha256 / B: hook 実体 5 つの sha256 / C: PM プロセス（pid 15355）の argv と env のキー名 / D1: live teams/agmsg/config.json の sha256 と agent 名 / D2: live DB で gate の team 名・pilot 名・lock を含む行（11 項目、すべて 0 件。正の対照 team='agmsg' は非 0）/ D3: live の team 一覧	before==after。before は gate の開始前、after は harness の cleanup 完了後に P6 とは別に採取

両方が pass / 一致でも、N1〜F5 が unknown なので pilot_ready=false です（breaker 断定の条件）。

測った範囲 / 測っていない範囲

check	走らせたか	理由
P0〜P4	走らせた	—
N1	fresh の起動のみ（binding 作成まで成功、transcript で停止）。resume は未実行	上記
I1 / F1〜F5	走らせていない。F2 の fault session は起動していない	N1 が pass 以外のため harness が打ち切る
P5 / P6 / P7	harness が実行した	—

disposable run root は P5 で削除され、ls でも不在を確認しました。再現に使った scratchpad は削除済みで、残存プロセスは 0 件です。

次に直すべきもの: (1) N1 の起動方法（native claude を TTY の下で起動するか、runbook §11 の期待を見直す）(2) 使い捨て環境での Claude の認証（未確認のリスク）(3) gate の team DB に events テーブルが無い件。いずれも breaker / architect の判断です。

Refs #395

[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