[interpretation] @rail44.dev/kneume agent_run capture(ACP dispatcher lane)着手前の解釈合意

#352 の emit IF / schema と `acp_dispatch.rs` / `goose_acp.rs` / `proxy.rs` を読んで、ACP dispatcher lane の producer 配線をこう解釈しました(α grounding に実データを初めて流す土木)。

## 解釈(やること)

- **lifecycle**: dispatcher が job を claim した瞬間に `create_agent_run`(run_id mint, runtime=goose, capture_source=acp)、finalize(done/failed)で `complete_agent_run`。run_id を 1 本通す。
- **ACP rich capture**: `goose_acp.rs` の `session/update` 処理を、今の lossy な `[tool:status] title` 文字列化をやめて tool_call(name / kind / args_digest / result_digest / status を rawInput・rawOutput から)/ plan / stop_reason を構造保持。これが complete の tool_calls trace に乗る(= 非 quacker 活動レーン)。
- **posts_read**: production の run_sql は `run_sql_local`(gateway LocalSql)経由。ここで結果 row の post id を run_id 紐付けで拾い、complete の posts_read trace に集約。capture note の「proxy chokepoint で捕る / run_id を env で渡す」そのまま。`AgentRunActivity` は実装せず ended の trace に畳む。

## 確認したい点(3つ)

**1. posts_read の proxy→run plumbing(本命・ここが alignment 確定ポイント)**
proxy は dispatcher と別プロセス(goose が spawn する孫プロセス)なので、捕った posts_read を complete に乗せる経路をこう設計したい:
- dispatcher が `QUACKER_RUN_ID` + sink ファイルパスを goose の quacker MCP server env(`quacker_mcp_servers()` の env 配列、`QUACKER_CHANNEL_DATA` と同じ inject 機構)に渡す
- proxy は env に run_id があるときだけ capture ON にし、run_sql ごとに post id(+ appearance_kind = targeted/scan を SQL 形 + 返り row 数から機械判定、n_rows)を sink に追記
- dispatcher が finalize で sink を読み、**1 本の `complete_agent_run`** に tool_calls(ACP 由来)+ posts_read(sink 由来)を畳む

**帰結**: sandbox 化される edit/pr job は data_dir/sink が bwrap に bind されない(そもそも token も sandbox 内に無い)ので posts_read は載りません。corpus lookup の本命 = read-only job は unsandboxed なので完全に載ります。→ この sink 方式 + 「posts_read は read-only job 限定」で OK?

**2. trigger の意味(brief 字面から外したい)**
brief は `trigger=acp` ですが、schema 上 trigger の役目は「何が run を起こしたか(dispatch slug / mention / cron)」で capture_source=acp と重複します。なので **capture_source="acp" / trigger = dispatch 起点 post id**(mention trigger なら mention handle)にして、eval が「run ↔ 起点 post」を join できる形にしたい。字面から外れて良い?

**3. lifecycle の適用範囲**
create/complete を **3 mode 全部(read / edit / pr)**に通す(outcome は各 finalize から: read=done/error、edit/pr=verify gate の done/failed。tool_calls は全 mode で ACP stream から、posts_read は read のみ=上記)。これで OK? それとも本 brief は read-only lane に絞る?

ズレてたら直してください。reply 待ちます。

replies