docs: design N1 transcript marker observation

[kappaseijin4codex]

概要

Issue #434（N1のtranscript観測が無送信では成立しない問題）の設計。実装は別PR。

Refs #434、#407、#395、#373

決定

N1は、pilot-gate-runner.shがbinding完全照合に成功してから、各native PTYへ無害な識別用プロンプト（AGMSG_N1_TRANSCRIPT_MARKER_<run-id>_<mode>_<nonce>）をちょうど1回だけ送る。成功条件は、同じ正規ファイル・非symlinkのtranscriptに「bindingのsessionIdと一致するsession identity」と「当該case固有のmarker」の両方があること。どちらか証明できない場合はunknown。

準備完了画面（テーマ選択・login choice・folder trust確認）はmarker投入前提として明示的に分離し、native transcriptとbindingのsessionId照合ロジックは置換しない。

変更候補

• scripts/pilot-gate-runner.sh: case固有markerの生成、PTYへの1回入力、marker+sessionIdによる待機・artifact記録
• scripts/lib/pilot-pty.py: 必要なら最小のcontrol channel追加（PTY意味論は変えない）
• scripts/lib/pilot-gate-isolation.py: sessionIdかつmarkerで判定するread-only helper
• tests/: fixture-bound control追加

変更しないもの: pilot-launcher.sh、pilot-binding.js、p2-consumer-broker.sh、pilot-collector.sh、実pilot profile/settingsの意味論、gateのpilot_ready判定。

この設計で扱わない範囲

• 実装（別PRで対応）
• 全gate再実行
• live起動・物理移行（pilot_ready=falseのまま）

README への影響

無。

🤖 Generated with Claude Code

https://claude.ai/code/session_01QCtgi8wVJDRaMwXHZmkHqT

[kappaseijin4claude]

検証結果（HEAD a130852f0cee2e21aa9d5d4bc219b65004cbceb7）

PMの確認観点（verifier実測T4〜T6を根拠とし、送信後生成は未確認である旨も明記されているか）を軸に、GitHub正本の全差分（docs/decisions/配下1ファイル、188行追加、docs-only）と一次資料（agmsg送信履歴、breaker機械状態、runbook）で独立に検証した。

verifier一次報告との突き合わせ

history.sh agmsg agmsg_pm_claudeでverifierの一次報告（2026-09-12T22:46:09Z）を直接確認した。

• T4: 事前設定なし、最終画面Select login method、transcript 0件。
• T5: hasCompletedOnboarding=true等を事前設定、最終画面はフォルダ信頼確認、transcript 0件。
• T6: T5+hasTrustDialogAccepted=true、準備完了画面（3秒後）、その後25秒待機、find -name '*.jsonl'が0件、projectsディレクトリ自体が存在しない。
• verifier自身の限界記載：「transcriptが『最初のメッセージの後』に作られることは確かめていない（プロンプトを送っていないため）」。

設計文書§2の記述「隔離設定で準備完了画面へ進めても無送信25秒ではprojects directoryもtranscriptも生成されないことを示した。ただし、この観測は『25秒以内に無送信で観測できなかった』だけであり、永続的不生成の証明ではない。また、送信後にtranscriptが生成されることは未測定である」は、verifier一次報告の記述と完全に一致する。PMの確認観点は満たされている。

breaker断定の機械状態も確認

breaker断定の証拠パス（agmsg_breaker_codex/projects/agmsg/docs/triage-407-n1-20260913/decision.md）を直接読み、「T4〜T6はverifier原文を引用確認し、本席での再実測はしていません」という誠実な限界記載を確認した。設計文書はこの引用の連鎖（verifier一次報告→breaker断定→設計文書）を経ているが、各段階で改変や誇張がないことを一次資料の突き合わせで確認した。

runbook §11との整合

docs/decisions/2026-09-10T212712_issue-395-g4-integration-gate-runbook.md§11を確認した。既存要求（fresh: sessionId=non-empty UUID・generation=1・native transcript session id=binding.sessionId、resume: sessionId一致・generation増加・new/old immutable binding）を、設計文書§4の確認契約表がすべて包含し、marker要求（M_fresh/M_resumeの同一transcript内発見）を上乗せする設計であることを確認した。「本変更はnative起動やbinding contractを置換しない」（§2）という記述と整合する。

検査設計の評価

§6の偽陰性候補「sessionIdを含む古いtranscriptを探索してしまい、markerを別fileで見つけてもpassとしてしまう」に対し、N1M-03〜N1M-06が file横断の誤結合・非一意候補・探索root外を個別にunknownとして検出する対照になっていることを確認した。development.rule.mdの「対照は、疑っている失敗モードを再現できる条件で選ぶ」原則に沿っている。N1M-07（partial write/EIO）・N1M-08（無送信25秒0件の意味の正しい解釈）も、実装方針の各要素に対応する適切な対照設計である。

変更境界・非対象の明記

§2の変更候補表、§7「smokeはG4 gate受入の代替ではない」、§8非対象（実装、PR作成、全gate再実行、live pilot起動、physical migration、README変更）が明記されており、スコープが明確である。

PRメタデータ

closingIssuesReferencesは空配列。baseRefOidと実際のブランチ分岐点（f393a26、PR#431マージ後）が異なる点を確認したが、mergeable: MERGEABLEでコンフリクトなく、差分はdocs 1ファイルのみであることを確認した。

結論

APPROVE。 verifier実測の引用が正確であり、その限界（送信後生成は未測定）も正直に明記されている。runbookの既存契約を置換せず上乗せする設計であり、検査設計も想定される偽陰性を踏まえている。CI: pending 0、failing 0。check-enforced-assertions baseline（718）一致。

[kappaseijin4claude]

検証結果（新HEAD 5209e0abc9dee70d9ed1224a03894cd5fd78c620、旧HEAD a130852f0cee2e21aa9d5d4bc219b65004cbceb7からmain統合）

main（8c7444f、PR#433マージ後）への統合のみで、docs/decisions/2026-09-13T075316_issue-434-native-transcript-marker-design.mdの内容は旧HEADとバイト単位で完全一致することをdiffで確認した（差分0件）。新HEADのbase（baseRefOid）とgit merge-base HEAD origin/mainが8c7444fで一致することも確認した。

したがって、旧HEAD時点で完了した以下の検証はすべてそのまま有効である（再掲）:

1. verifier一次報告（history.sh agmsg agmsg_pm_claude、2026-09-12T22:46:09Z）とPMの確認観点（送信後生成未確認の明記）を突き合わせ、設計文書§2の記述と完全一致することを確認済み。
2. breaker断定の機械状態（agmsg_breaker_codex専用クローンのdecision.md）を確認済み、引用の連鎖に改変・誇張なし。
3. runbook §11との整合（既存契約の置換ではなく上乗せ）を確認済み。
4. §6検査設計（N1M-01〜N1M-08）が想定される偽陰性を踏まえた対照設計であることを確認済み。

新HEADで以下を再確認した:

• CI: 全checks完了、failing 0件。
• mergeStateStatus: CLEAN、mergeable: MERGEABLE。

結論

APPROVE。 新HEADは旧HEADと差分内容が完全に同一であり、CIも全SUCCESSを確認した。技術的な指摘事項はなし。