# STEP 2119 — Phase 1 design memo (tab-side route labeling only, 実装せず)

**Timestamp**: 2026-09-19T00:40 (JST)
**Tab worktree**: `main` (rei-aios-bd tab)
**Commit**: `<pending>` — filled at push
**Corrigendum + supplement of**: `docs/notepad/2026-09-19T00-20_STEP-2119_phase-0-5-corrigendum-docs-and-metadata.md`
**Directive origin**: chat-Claude → 藤本さん relay (未 review) → rei-aios-bd tab、 explicit go 2026-09-19: 「Phase 0.5 accept、 Phase 1 保留継続 (CI unblock 先)、 設計メモのみ作成可」
**Implementation status**: **NOT IMPLEMENTED** — design memo only。 藤本さん explicit go + CI unblock 両方が 揃うまで 実装 hold

## 一行 summary

Phase 0.5 の (c-new) を 再訂正 (chat 側 に marker 挿入 hook は 存在しない、 機械化可能なのは tab-side 読み込み時 label 付与のみ、 label 意味は 「中継経路通過」 ≠ 「chat-Claude が書いた」)。 Phase 1 実装は 引き続き hold、 設計メモとして: 経路 = 藤本さん指定 Docs ID (allow-list)、 tab 読み込み時 route_label + doc_id + version + sha256 自動記録、 (a) timestamp と (b) 添付は Docs 版番号 + 書き出し機能で 足りるかを 検討。

## 訂正 (c-new 再訂正) — chat 側 hook は存在しない

**旧 (c-new)** (Phase 0.5 notepad 2026-09-19T00-20):
> (i) chat-Claude が 書き込む時点で 出所 marker (例: `[orig: chat-Claude, session-id: X, timestamp: Y]`) を **機械的に 付与する** 規約を敷き、...

**誤りの根拠** (chat-Claude 訂正 2026-09-19):
> chat-Claude の 側に そのような 仕組みは ありません。 私が marker を書くのは 指示に従っているだけで、 機械的な保証ではありません。 機械的にできるのは tab 側です。

**書換**: 「chat-Claude が marker を機械的に付与」 と 私が仮定した箇所は 全て **behavioral (指示遵守)** に格下げ。 marker 記載は chat-Claude が 「指示に従って書く」 = 保証は 藤本さん → chat-Claude directive の 遵守 のみで、 コネクタ layer に marker-injection hook は **無い**。 chat 側の marker 記載を hook として頼るのは 前提誤り = Phase 0 の 「(c) 認証」 誤り と 同型 の 誤 mechanization。

**正しい機械化位置** = **tab side** の 「決められた経路から 読み込んだ ときに 自動で 経路ラベルを付ける」 のみ。 ラベルの 意味は:
- ✅ 「この 内容は 中継経路 (指定 Docs ID) を 通過した」
- ✗ 「この 内容は chat-Claude が書いた」 = **保証しない** (同一アカウント OAuth token で 誰でも 同じ Docs に書けるため。 藤本さん が UI から 直接書いた 内容も、 chat-Claude が 藤本さん token で 書いた 内容も、 経路が 同じなら 同じ label が付く)

## Phase 1 設計メモ (実装せず、 藤本さん go 待ち)

### 1. 経路 (allow-list、 藤本さん explicit 指定のみ)

- **限定**: Claude Docs、 藤本さんが 事前に **文書 ID を明示指定** した もの **のみ** (例: 「今後 X の relay は artifact ID Y に書く」 と 藤本さん が 決定した list)
- **拡張なし**: tab が 自動で Docs 全体を scan して 「rei-scout っぽい name の doc」 を 拾う 挙動は **禁止** (推測 target = Pattern 5 の 「削減以外の 差分保証なし」 に該当)
- **allow-list 保存場所**: `data/tabs/rei-aios-bd/chat-relay-allow-list.json` (sidecar、 tab 単位 で 保守、 藤本さん edit 経由で 更新、 別 tab の allow-list とは 混同不可)
- **除外**: Gmail (chat-Claude 訂正 directive で 除外指定、 INBOX 94k = surface too wide)、 Slack (chat 経由投稿の owner attribution が 藤本さん になり 転記経路として 冗長)、 Drive (bulk file share の cognitive load 高い)

### 2. tab-side auto-label schema (実装せず、 spec のみ)

```
// 想定 signature (実装しない、 spec 例示)
type RelayLabel = {
  route_label: "chat-relay-via-docs"   // 固定文字列、 label semantics 明示
  doc_id: string                        // 藤本さん指定 allow-list 内 の 文書 ID
  doc_url: string                       // https://claude.ai/artifact/<id> 完全形
  version: string                       // Docs metadata 由来 (下記 (a) 検討 参照)
  sha256_snapshot: string               // 読込時点の 全文 hash (SHA-256、 tab 側 で 計算)
  read_timestamp_utc: string            // tab が読んだ 時刻 (ISO 8601、 UTC)
  reader_tab: string                    // 例: "rei-aios-bd"
  content_source: "tab-side-read"       // 「tab が読んだ」 明示、 origin claim なし
  known_limitations: string[]           // 下記 「Honest scope」 の literal 引用
}
```

- 保存: `data/tabs/rei-aios-bd/chat-relay-inbox/<doc_id>_<read_timestamp>.json` (append-only、 sidecar)
- 提示: tab が 藤本さん に 「新規 relay 到達: doc <id>, sha256 <hash>」 と one-line notify、 採用 (実 read + Claude 判断 material 化) は **藤本さん explicit go 後** (「採用判断は自動化しない」 directive 継続遵守)

### 3. (a) timestamp と (b) 添付 の Docs で 足りるか 検討

#### (a) timestamp

- **Docs 側 の 提供**: `mcp__claude_ai_Claude_Docs__read` の 返却に `bound.by: "publish"` は含まれるが 実測 (RT-0 v1) では 「publish 時刻」 の 直接 field は 露出せず。 `mcp__claude_ai_Claude_Docs__query` (utterance history) で 各 comment / edit の timestamp は 別途取得可 (推定、 実測未)
- **「版番号」 相当** = Docs は Google Docs 的な version history (revision) を持つが、 MCP tool schema で `version` field が 直接露出するか 未実測 (Phase 0.5 では 単発 read で `frame.slug` のみ確認、 revision list 未取得)
- **足りるか**: 「chat 発話時刻」 の 精度で 保証したいなら、 chat が Docs に write した 時刻を Docs 版番号 (revision) の created_time で proxy 可能な 前提だが、 revision list 取得の 実測 が Phase 2 で 必要 (現段階は 「Docs 版番号 で 概念的に proxy 可、 実測が Phase 2」)
- **不足時 の fallback**: sha256_snapshot と read_timestamp_utc の 組合わせで tab-side 到達順序 は 100% 保証可能、 chat-side write 順序は Docs revision に依存

#### (b) 添付

- **Docs 書き出し機能**: `mcp__claude_ai_Claude_Docs__export` tool が存在する (schema list に露出、 未実測)。 export で binary attachment (画像 / PDF / code block) が Docs 内に 埋め込まれて 保持されるか 未検証
- **足りるか**: Claude Docs は prose + json + code (kind = "node" 経由) の 内部 representation を持ち、 export tool で それらを 特定 format で 出力可能 な 想定。 binary 添付が Docs page block として 埋め込まれて export で fidelity 保持される design か、 別途 Drive link 経由が必要な design か が 未確認
- **不足時 の fallback**: chat 側 が Docs body に inline base64 で 埋め込む (fidelity 保持だが body size 増加)、 or 藤本さん が binary は Drive folder に 別途 upload して doc に Drive link を貼る (Docs は text/link のみ、 binary は Drive)。 後者は allow-list を Drive folder ID にも 拡張が必要 = scope 拡大 = Phase 2 別 memo

### 4. 想定 workflow (実装せず、 flow 例示)

```
[chat-Claude side、 hook 無し、 藤本さん指示遵守 で 手動遵守]
  1. 藤本さん from chat: 「今の応答を Doc <ID> に write」
  2. chat-Claude: Doc <ID> に body write (marker は 「指示に従って」 header に付与、
     機械保証なし)

[tab side、 機械化される]
  3. tab (or scheduled reader): 定期 (30 分 or 藤本さん指示 trigger) で
     allow-list 内 の 各 Doc に対し read → sha256 diff 検知
  4. 新規 or 更新 検知時: RelayLabel schema で
     data/tabs/rei-aios-bd/chat-relay-inbox/ に append
  5. tab から 藤本さん に one-line notify: 「新 relay <doc_id>, sha256 <hash>」
  6. 藤本さん explicit go 後、 tab は body を 判断 material 化
     (それまで body は sidecar に貯めるだけ、 Claude 判断に は 使わない)
```

### 5. 実装しない 部分 (明示)

- **chat 側 hook** — 無い、 想定しない
- **write path** — tab は Docs に write しない (chat から tab への 一方向 relay のみ、 前 chat directive 「今回は chat → tab の 片方向のみを対象」 継続)
- **allow-list 自動拡張** — 藤本さん manual edit のみ、 tab の 自動追加 禁止
- **auto-adoption** — 読込 = 記録 のみ、 Claude 判断への 反映は 藤本さん explicit go 後
- **cross-tab sharing** — allow-list は tab 単位 (sidecar)、 別 tab との 共有は 別 STEP 議論

## Honest scope (必須 明記)

- **出所の 認証 では ない**。 label semantics = 「中継経路 (指定 Docs ID) を通過した」 のみ、 「chat-Claude が書いた」 は **保証しない**。 同一 OAuth account 下で 藤本さん UI と chat-Claude connector が 同じ Docs に書ける限り、 label は provenance に 触れない
- **転記段階 の 除去のみ**。 549 misattribution 根本原因 (手で貼り写す 段階で 出所ラベルが 消える) を、 「機械的 read + sha256 記録」 に 置換することで 「人が手で写す step」 を 消す。 それ以外 の provenance 主張は 一切なし
- **chat 側 の marker 記載 は behavioral**。 chat-Claude が 「[orig: chat-Claude]」 と 書くのは 指示遵守 の 振る舞い で、 コネクタ layer の 機械保証は **無い**。 label に chat-Claude 記載が embed されても、 それは chat-Claude が指示に従ってそう書いた 副産物 で、 中継経路が それを verify した 訳ではない
- **Docs revision の 実測 未**: (a) の 「Docs 版番号 で timestamp proxy」 は 概念的、 Phase 2 で revision list API 実測 が 必要
- **Docs export の 実測 未**: (b) の 「Docs 書き出しで attachment fidelity 保持」 は 未検証、 Phase 2 で export tool 実測 が 必要
- **allow-list 保守運用の burden**: 藤本さん が edit する manual step が 残る、 削減 は 「中継経路 到達までの 手作業」 のみ、 allow-list 決定 は 藤本さん judgment 継続 (「採用判断は自動化しない」 と 整合)
- **CI unblock 依存**: 実装 go は fc0web billing 対応 完了 が 前提。 本設計メモ は 実装 blocker が 解けても 直ちに build しない、 藤本さん explicit go を 別途 待つ

## Failure mode (機械学習用 dataset)

- **What could go wrong (hook 誤想定)**: chat 側に 存在しない hook を 前提に 設計を組み、 「機械保証」 と 「指示遵守」 を 混同する (Phase 0.5 で 私 が 犯した 誤り、 chat-Claude 訂正で 修正済)
- **Prevention**: 「hook が 存在する」 と 主張する 前に、 hook の実装位置 (chat side / tab side / connector layer) と 実行主体 を 明示、 「藤本さん 指示に従うこと」 と 「コネクタ layer の 機械実行」 を 別 category に分ける
- **Recovery**: 前提誤り検知時、 該当 memo を新規 corrigendum notepad で 訂正 (本 file が 訂正 entry の 3 例目 = Phase 0 → Phase 0.5 → Phase 1 design memo の 各段で 訂正累積)

- **What could go wrong (label 意味 の 誤解)**: label = 「中継経路通過」 を 「chat-Claude 発話」 と 誤読、 provenance claim を label に持たせる
- **Prevention**: label schema に `content_source: "tab-side-read"` と `known_limitations[]` field を 必須化、 「認証ではない」 を 常に schema level で埋め込む
- **Recovery**: 誤読 検出時、 schema level で label semantics を 再定義 (「read-time route trace」 と 明示、 authorship claim 削除)

- **What could go wrong (allow-list 自動拡張)**: tab が 「rei-scout っぽい name の doc を 自動追加」 = 藤本さん 意思決定 の bypass、 中継経路が 藤本さん の 知らないところで 増える
- **Prevention**: allow-list は sidecar file、 tab の 自動書換 禁止、 変更は 藤本さん manual edit のみ = tab の pre-commit hook で 「chat-relay-allow-list.json の 変更は 手動 edit のみ、 auto 書換 検知で abort」 を 実装候補 (別 STEP 検討)
- **Recovery**: allow-list に 想定外 entry 検知時、 sidecar diff で 追加履歴を verify、 tab 由来なら 削除 + rollback、 藤本さん 由来なら OK

## 藤本さん judgment 待ち (Phase 1 実装 go 前 の gate)

1. **CI unblock** (github.com/settings/billing 対応、 私 側 は 状態見えず、 藤本さん 画面 状態 共有 必要)
2. **Allow-list の 初期 doc ID list** (藤本さん が 指定)
3. **Reader trigger 方式** = polling (30 分 cron) vs 藤本さん 明示 trigger (「今 relay 見て」) の どちらを default に するか
4. **notification channel** = tab から 藤本さん への 「新 relay 到達」 通知 は inline chat reply (現行 tab 対話) で 十分か、 別 mechanism 要か
5. **Phase 2 実測 candidate** = (a) Docs revision list API 実測 + (b) Docs export tool 実測 を 別 STEP で 実施するか

## 詳細参照

- 前 notepad chain: `2026-09-19T00-02_STEP-2119_ci-wire-1987-1988-blocked-and-relay-phase-0.md` → `2026-09-19T00-20_STEP-2119_phase-0-5-corrigendum-docs-and-metadata.md` → 本 file (Phase 1 design memo)
- 関連 commit: `db82f4206` (T1 workflow) + `58f8e3a2a` (Phase 0 notepad) + `d92c49740` (Phase 0.5 corrigendum) + `<pending>` (本 file)
- 6c collision 通知: SendMessage msg_id `99601dff-7428-4b50-ba48-7ed5e34c391e` (STEP 2119 は bd claim 済、 6c は 別番号取得 依頼)

## Cross-reference

- `[[step-2119-phase-1-design-memo-tab-side-route-label]]` (this)
- `[[step-2119-phase-0-5-corrigendum-docs-and-metadata]]` (前 notepad)
- `[[step-2119-ci-wire-1987-1988-blocked-and-relay-phase-0]]` (最初の notepad)
- `[[feedback-pattern-5-prevention]]`
- `[[feedback-549-misattribution-root-cause]]`
- `[[tab-isolation-protocol-v01]]` (allow-list sidecar 保守)
- `[[chat-claude-behavioral-vs-mechanical-guarantee]]` (訂正の 起源、 未来 STEP で 一般化)