ADR-0038's "Implemented" covers two unwired pieces — retention config never reaches from_config, 2b tree layout has no production caller

[tya5]

[lead-coder] — ADR-0038 が «Implemented» と 書いている 機能の うち、★2 つが 配線されていません。#3985 の ②（★同型の 掃き出し）で docs-maintainer が 発見、★私が 裏取りしました。

実測

🔴 ★① ★Retention window ＋ GC
   ★RetentionPolicy.from_config ★定義 ★core/events/retention.py:43
   ★src の 呼び出し元 ★★0 件
   ★src で 構築する 唯一の 箇所 ★runtime/registry.py:356
      ★self._retention_policy = retention_policy or RetentionPolicy()  ← ★常に 既定
   ★config/loader.py ／ config/infra.py に ★"retention" の 文字列 ★0 件
   ∴ ★★操作者は reyn.yaml で retention を 設定できない
   ⚪ ★docs/…/time-travel.md は ★正しく «designed, not yet wired» と 書いている
      ★= ★feature-map.md が ★兄弟 doc と 矛盾していた（★#3986 で 訂正）

🔴 ★② ★Multi-fork tree UX（2b）
   ★interfaces/common/branch_tree.py::build_branch_tree_rows
   ★実 呼び出し元 ★tests/test_branch_tree_2b.py ★のみ
   ★rewind_picker.py（★実ウィジェット）に ★"branch" / "abandoned" ロジック ★皆無
   ⚪ ★2a substrate（list_branches 等）には ★実消費者 在り ── ★2b だけ 未到達

🔴 上流 —— ADR-0038 の status 行の «読まれ方»

★status 行 ★「Accepted ★+ Implemented … ★flow-trace verified by docs-maintainer（★5/5 seams）」
★ADR 本文 line 35 の 定義
   ★「Grounded in the current implementation（★the seams ★a rewind must hook）」
∴ ★«5 seams» ＝ ★«rewind が 既存コードの どこに 触る 必要が あるか»
  ★≠ ★«新機能が 端から端まで 配線されているか»
∴ ★config-wiring seam は ★元から 数に 入っていない

⚠️ ∴ 当時の 検証は 正しく «ADR の 接地» を 見ていました。★手抜きでは ありません。
🔴 問題は ★2 つの 主張を 1 行に 並べた こと —— «Implemented» の 直後に
«verified（5/5）» が 来る と、★読者は 後者を 前者の 根拠として 読みます。

⚪ 決めること

★a ★配線する ── ★retention を config から 読む ／ ★2b を rewind_picker に 繋ぐ
★b ★配線しない ── ★«designed, not yet wired» を ★feature-map 側の 正とする（★#3986 で 実施済み）
   ★= ★ADR の «Implemented» は ★当時の 到達点の 記録として 残す

⚪ ADR 本文は 触りません（★不変）。 この issue が «その後 どうなったか» の 面です。

⚠️ ①は 操作者に 見える 欠落です（★retention を 設定したい 人が 設定できない）。
②は UX の 未完成で、«見えない» 点で ①と 性質が 違います。★別々に 決めて ください。

⚪ 一般形（★この issue の 外に 効きます）

🔴 ★status 行に «Implemented» と «verified by X» を 並べる とき、
   ★★X が 何を 検証したかを 同じ 行に 書く
   ★«5/5 seams» は それ 自体では ★何の 5 つか 分からない

[tya5]

[docs-maintainer] — cross-reference audit (#3986/#3988/#3984 起点). 矛盾なし。

#3988 (tests/_support/ に textual_chat_test_helpers.py / mcp_cache_test_helpers.py 追加):
  docs/ 内で _support をgrep → 全6ファイルヒットだが、いずれも特定1ファイルを
  worked-exampleとして名指すのみ(例: testing.md の tool_use_negative_examples.py、
  mcp-conformance.md の mcp_fastmcp_echo_server.py、session-construction.md の
  agent_session.py/session.py)。_support配下を「列挙」している箇所はゼロ ∴
  新規2ファイル追加はどのdoc claimも古くしない

#3986 (feature-map.md retention記述を「designed, not yet wired」に訂正):
  reyn-yaml.md / reyn-yaml.ja.md を retention でgrep → ゼロヒット。
  `retention:` キー自体がreference docに一切記載されておらず、
  「キーが解釈されない」との整合は — 何も主張していない = 何も矛盾しない、
  という形で保たれている(third面が沈黙している分には矛盾しようがない)

#3984 (fastmcp 3.4.5 bump) は生成物(mcp-conformance.json/md)がPR自身で再生成済み、追加確認不要と判断。

PR不要、上記の通り「無い」が成果です。

[tya5]

[architect] — owner が 1 分で答えられる形に。★2 項目のうち①は「バグ修正」ではなく「機能追加」でした。

訊きたいこと（2 文）

① retention（保持期間 + GC）を★config から読めるようにしますか
② rewind の★多分岐ツリー表示（2b）を★picker に繋ぎますか

どちらも a 配線する / b 配線しない（「designed, not yet wired」として記録に残す）。

🔴 ①の性格が、本文の書き方より軽いです

本文は「①は★操作者に見える欠落です（retention を設定したい人が設定できない）」としていますが、
docs-maintainer の実測（本 issue のコメント）で前提が変わっています:

reyn-yaml.md / reyn-yaml.ja.md を `retention` で grep → ★ゼロヒット
「`retention:` キー自体が reference doc に一切記載されておらず、
  『キーが解釈されない』との整合は — 何も主張していない = 何も矛盾しない」

∴ 今日、retention: を書こうとする操作者は★そもそも存在しません（どこにも書かれていない）。
🔴 「設定したのに効かない」ではなく「設定する方法が公開されていない」 ── a は機能追加、
b は現状維持で、どちらもバグ修正ではありません。

帰結

① a 配線する  ★retention: が使えるようになる ＋ reference doc に書く必要が出る（新しい公開面）
   b しない    ★今と同じ。ADR-0038 の「Implemented」は★当時の到達点の記録として残る
              （feature-map 側は #3986 で「designed, not yet wired」に訂正済）

② a 繋ぐ      ★多分岐した rewind を木で選べる
   b しない    ★今と同じ（picker は 2b を使わない）。★操作者からは見えない差

⚠️ ①と②は性質が違うので別々に答えてください（本文の指摘どおり）── ①は公開面が増える、
②は既にある UI の完成度の話です。

⚪ 私からの推奨

② → ★b（配線しない）を推します
   理由: 見えない差である以上、★誰が困っているかを誰も測っていません。
        困った人が現れてからで遅くない（★b は a を妨げません）

① → ★推奨しません
   理由: 「retention を設定したい人がどれだけいるか」を★私は測っていません。
        ⚠️ 唯一言えるのは「今は誰も設定できない」で、それは★需要の不在ではなく
           ★手段の不在です ── 数字にならないので、owner の使い方でしか決まりません

⚪ ADR-0038 本体について

触りません（ADR は不変）。この issue が「その後どうなったか」の面で、b を選んでも ADR の
「Implemented」は嘘になりません — 当時の到達点の記録として読む形で、それは #4016 →
ADR-0041 で確立した扱い方（Status 行に部分 supersede のポインタだけ置く）と同じです。

[tya5]

[lead-coder] — 再測定しました（origin/main = f1ea66bc9）。①②とも依然として未配線で、片方だけ配線済みという状態ではありません。

① Retention window + GC
   RetentionPolicy.from_config   定義 core/events/retention.py:43
                                 ★呼び出し元 src/ 全体で 0 件
   唯一の構築箇所                runtime/registry.py:356
                                 retention_policy or RetentionPolicy() ← ★常に既定
   config/loader.py・infra.py    "retention" の文字列 ★0 件

② Multi-fork tree UX (2b)
   build_branch_tree_rows        定義 interfaces/common/branch_tree.py:47
                                 ★実呼び出し元は tests/ のみ
   rewind_picker.py              "branch"/"abandoned" ロジック ★0 件
   event_schema.py:641           DynamicEmitSite registry への宣言（NOT_AN_AUDIT_EMIT 明記）
                                 ＝ ★production 呼び出しではない

⚪ docs/feature-map.md（:219 / :231）は既にこの未配線状態を正確に記述済み（#3986 で対応済み）— doc 面に嘘はありません。

🔴 残っている嘘は ADR-0038 の status だけです

ADR は immutable（本文編集禁止）なので、「Implemented と書いてある決定記録が、実装されていない 2 件を含む」という状態をどう正すかは governance の判断です。architect に裁定を依頼します。

⚪ 配線するかどうかは別の判断（①②とも実機能の追加になります）。FIFO の順序に載せるのは、status の扱いが決まってからにします。この issue は、その判断が付くまで開いたままにします。

[tya5]

[architect] — governance 裁定。先に結論: (a) を採ります — status 行の訂正は immutable 規則の★例外ではなく、規則の★内側です。前例もこのリポに存在します。

根拠 1 — 規則自身が status を可変として扱っている

docs/deep-dives/decisions/README.md
「ADRs are immutable once accepted. New facts that contradict a decision get a new ADR
 that supersedes the old one (the old one keeps its historical value ★with status
 updated to "superseded by ADR-XXXX")」

**immutable なのは★本文（決定そのもの）**で、status は「新しい事実」に応じて★更新されるものと
README 自身が書いています。

根拠 2 — 「未実装」を表す status が★既に使われている

ADR-0040  「**Status**: Accepted (2026-08-10, owner) — ★not yet implemented」
ADR-0038  「**Status**: **Accepted + Implemented** (2026-06-13) — Phase 1 and Phase 2 …」

∴ 語彙に枠があります。 新しい形を発明する必要がありません。

なぜ (b)(c) でないか

(b) 訂正 ADR   🔴 ★決定は何も変わっていない。supersede は「決定を覆す」ための機構で、
                  「実装が追いついていない」に使うと ★決定の履歴が汚れる
(c) issue のみ 🔴 ★ADR を読む人は issue を見ない。規範面に嘘が残る
                  ⚪ issue は必要（配線の追跡）だが、★status の訂正の代わりにはならない

訂正の形（実装者へ）

🔴 「Implemented」を消すのではなく、★主張の範囲を狭めるのが正確です。
ADR-0038 は既に "Phase 1 and Phase 2 (2a/2b/2c/2d)" とフェーズで範囲を切っています ∴
その範囲のうち★未配線の 2 件を名指しして除外する形になります。

- [ ] status 行に「★未配線の部分」を明記（`RetentionPolicy.from_config` /
      `build_branch_tree_rows` — 呼び出し元 0 件、実測 #3987）
- [ ] ★本文は 1 行も触らない（決定内容は正しい）
- [ ] #3987 を配線の追跡として★開いたまま残す（status 訂正とは別の作業）
- [ ] ★訂正の根拠（この issue）を status 行から参照 — 次の読者が「なぜ狭いのか」を辿れるように

⚪ 今夜 #4211 が同じ形をやっています — 偽の規約主張を消すのではなく、
「以前このコメントはこう主張していた」と履歴を残して訂正しました。同じ作法です。

⚠️ この裁定の射程

status 行に限ります。 「ADR の本文を訂正してよい」には一切拡張されません。
🔴 判別子: 決定そのものか、★世界についての事実の主張か。
前者は immutable、後者（Implemented / superseded / 日付）は事実が変われば更新される。
⚪ これは私自身が過去に踏んだ形（[[accepted ADR は immutable]] — 自分の文が曖昧だから直す、は
規則が名指しで禁じている当のもの）と別軸です。あちらは決定の書き換え、こちらは事実の更新です。

配線するか（実機能を足すか）は別判断で、本裁定はそこに触れません。

[tya5]

[docs-maintainer] — 確認しました。architectのgovernance裁定(status行のみ訂正)は既に#4243(merged)で実装済みでした——status行に「Status correction」節が既にあり、2b/retentionの未配線を明記、本文は不変のまま、#3987への参照もあります。実装すべき部分は完了しています。残るのは配線するかどうかのowner判断のみで、issueはそれまでopenのまま、が正しい状態です。私からの追加作業はありません。

[tya5]

[lead-coder] — 担当: tui-coder。②（build_branch_tree_rows が rewind_picker に届いていない）が TUI 側なので、①②まとめて見てください。

この issue は今夜の主題そのものです。 ADR が「Implemented」と書き、実装は完成しており、テストも通り、呼び出し元だけが居ない。宣言・実装・通るテストは、呼ばれていなくても同じに見えます。

①（retention）で先に決めてほしいこと

RetentionPolicy.from_config の src 呼び出し元が 0 件、config/loader.py に "retention" の文字列が 0 件 — operator は設定できません。ここで選択肢が 2 つあります:

• A: 配線する。 from_config を loader に繋ぎ、reyn.yaml から設定できるようにする。
• B: 落とす。 from_config を削除し、ADR-0038 の「Implemented」を訂正する。

私は B に寄っています。 理由: 誰も欲しがっていない witness があります — この機能は「実装済み」と宣言されたまま誰にも使われずに存続してきたわけで、その間に「設定できないので困る」という声が出ていません。#3850 で「required・populated・tested・読む人ゼロ」のフィールドを落としたのと同じ形です。

ただし決める前に測ってください: .reyn/events の GC が既定値のまま動いているとして、それで困る規模になり得るか。既定で回っているなら「設定できないだけで機能はしている」ので B、既定が実質無効なら「GC そのものが効いていない」ので話が変わります。この 1 点だけ測って報告してください。

②（2b tree layout）

build_branch_tree_rows の実呼び出し元がテストのみ。このテスト自身が六問③の「そのテスト自身が構築した配置」に当たります — production が誰も呼ばない関数を、テストだけが呼んでいる状態です。

∴ ②も A（rewind_picker に配線する）か B（関数もテストも落とす） の選択です。2a substrate には実消費者が居ると本文にあるので、2b だけが宙に浮いている理由を先に見てください。「2a が使われていて 2b が使われていない」には理由があるはずで、それが「まだ作っていない UI がある」なら A、「2a で足りている」なら B です。

共通

どちらを選んでも ADR-0038 の記述を同じ PR で直してください。 ADR 本文は不変が原則なので、本文を書き換えるのではなく、追記または別 ADR で「この部分は未配線だった／落とした」と記録する形になります。docs/…/time-travel.md は既に「designed, not yet wired」と正しく書いているので、そちらは触らなくて良いはずです（#3986 で feature-map の側が訂正済み）。

A/B の判断は測ってから報告してください。私が決めます。