+
+{% include manuals/1.0/footer.html %}
diff --git a/_layouts/review-ja.html b/_layouts/review-ja.html
new file mode 100644
index 0000000..7558580
--- /dev/null
+++ b/_layouts/review-ja.html
@@ -0,0 +1,16 @@
+{% include manuals/1.0/header.html %}
+
+
+
+
+ {% include review/fable5/ja/sidebar.html %}
+
+
+
+
+ {{ content }}
+
+
+
+
+{% include manuals/1.0/footer.html %}
diff --git a/manuals/1.0/en/14-faq.md b/manuals/1.0/en/14-faq.md
index 9a8c045..98ec74e 100644
--- a/manuals/1.0/en/14-faq.md
+++ b/manuals/1.0/en/14-faq.md
@@ -287,3 +287,11 @@ A concept where variable names themselves express meaning and constraints. For e
### Semantic Exceptions
A mechanism for holding failures not as simple strings, but as structured data with meaning. It supports multilingual compatibility and audit requirements, making system behavior traceable at the semantic level.
+
+---
+
+## 10) Going Deeper
+
+### Q. Where can I learn more?
+
+A. A trilogy of neutral review articles by the high-performance LLM Fable 5 offers a multifaceted analysis. Start with the first: [Three Lines of While-Loop and Fifteen Thinkers — A Be Framework Review](/review/fable5/en/trilogy-01-review.html).
diff --git a/manuals/1.0/ja/14-faq.md b/manuals/1.0/ja/14-faq.md
index 7cb3e17..aa3ca32 100644
--- a/manuals/1.0/ja/14-faq.md
+++ b/manuals/1.0/ja/14-faq.md
@@ -305,3 +305,11 @@ $user = $becoming(new UserInput($name, $email));
### 意味的例外（Semantic Exceptions）
失敗を単純な文字列ではなく、意味を持った構造化されたデータとして保持する仕組みです。多言語対応や監査要件に対応し、システムの動作を意味レベルで追跡可能にします。
+
+---
+
+## 10) さらに深く
+
+### Q. もっと深く知りたいのですが？
+
+A. 高性能LLM（Fable 5）による中立的な三部作の評論があります。まずは[3行のwhileループと15人の思想家 — Be Framework 評論](/review/fable5/ja/trilogy-01-review.html)からどうぞ。
diff --git a/review-by-codex.md b/review-by-codex.md
new file mode 100644
index 0000000..8031961
--- /dev/null
+++ b/review-by-codex.md
@@ -0,0 +1,134 @@
+# Be Framework Manual Review by Codex
+
+レビュー日: 2026-04-19
+対象: `manuals/1.0/ja/**/*.md` の 19 ページ
+採点基準: 100 点満点。`明確さ / 完全性 / 実用性 / 構成・導線 / 独自性・一貫性` を総合評価
+
+## 総評
+
+全体平均は **83.6 / 100** でした。中核ページは非常に強く、特に `概要` `存在クラス` `意味変数` `背後にある哲学` `Tutorial` は、思想と実装例の接続が明快です。一方で、`意味的ログ` `ログ駆動開発` `リファレンス` は草稿性または情報不足が目立ち、公開品質としては差が出ています。
+
+このマニュアルの強みは、単なる API 説明ではなく、読者の見方そのものを変える構造にあります。弱みは、入口ページと導線の整理、ドラフトの見せ方、ページ間の用語・粒度の揺れです。
+
+## スコア一覧
+
+| Page | Title | Score | 評価 |
+|------|-------|------:|------|
+| `manuals/1.0/ja/tutorial.md` | Tutorial | 95 | 最優秀。概念と実装が最も自然につながる |
+| `manuals/1.0/ja/12-philosophy-behind.md` | 背後にある哲学 | 95 | 思想的支柱。全体の文脈を最も強く補強する |
+| `manuals/1.0/ja/01-overview.md` | 概要 | 93 | 入口として非常に強い |
+| `manuals/1.0/ja/06-semantic-variables.md` | 意味変数 | 93 | 実装に落とし込みやすく完成度が高い |
+| `manuals/1.0/ja/03-being-classes.md` | 存在クラス | 92 | コア概念の説明力が高い |
+| `manuals/1.0/ja/14-faq.md` | FAQ | 92 | 疑問解消力が高く実務寄り |
+| `manuals/1.0/ja/08-reason-layer.md` | 存在理由層 | 91 | 高密度だが読み応えがある |
+| `manuals/1.0/ja/05-metamorphosis-patterns.md` | 変容 | 90 | 時間軸と分岐の説明が強い |
+| `manuals/1.0/ja/getting-started.md` | Getting Started | 89 | 初動の良さがある |
+| `manuals/1.0/ja/09-error-handling.md` | 意味例外 | 89 | 失敗を意味に変える説明が良い |
+| `manuals/1.0/ja/04-final-objects.md` | 最終オブジェクト | 88 | `$been` の独自性が光る |
+| `manuals/1.0/ja/demos.md` | デモ | 84 | 体感しやすいが外部依存がある |
+| `manuals/1.0/ja/02-input-classes.md` | 入力クラス | 83 | 明快だが短く薄い |
+| `manuals/1.0/ja/04a-becoming.md` | 生成 | 81 | 必要な橋渡しだが説明量が不足 |
+| `manuals/1.0/ja/convention/naming-standards.md` | Be Framework命名規約 | 80 | 有用だが他ページとの整合に課題 |
+| `manuals/1.0/ja/index.md` | イントロダクション | 69 | 目次としては不足がある |
+| `manuals/1.0/ja/13-vision-ldd.md` | ログ駆動開発 | 69 | ビジョンは面白いが現行マニュアルでは浮く |
+| `manuals/1.0/ja/11-reference-resources.md` | リファレンス | 63 | リンク集以上の価値が薄い |
+| `manuals/1.0/ja/10-semantic-logging.md` | 意味的ログ | 52 | Draft。未完成の印象が強い |
+
+## ページ別短評
+
+### `index.md` イントロダクション — 69
+入口としてのメッセージは明快ですが、`getting-started` `tutorial` `demos` `12-philosophy-behind` など重要ページへの導線が弱く、全体案内としては取りこぼしがあります。トップページは「読む順番」を示す役割まで持たせた方が良いです。
+
+### `getting-started.md` Getting Started — 89
+最短で動かす導線がよく、概念表も簡潔です。日本語版の中でページ名やリンクラベルが英語寄りで統一感を少し損ねていますが、導入ページとしてはかなり強いです。
+
+### `01-overview.md` 概要 — 93
+`DeletedUser` から入る導入が強く、Commander / Gardener の比喩も効いています。思想を読ませるページとして完成度が高く、初読者を引き込めます。
+
+### `02-input-classes.md` 入力クラス — 83
+役割は明確で、最小限の例も適切です。ただし短く、`Input -> Being -> Final` 全体の中での位置づけをもう少し補強したいです。
+
+### `03-being-classes.md` 存在クラス — 92
+`内在 + 超越 -> 新しい内在` の式を自然に理解させるページです。比喩、コード、哲学がほぼ無理なく接続されています。
+
+### `04-final-objects.md` 最終オブジェクト — 88
+`$been` を中心に Be Framework の独自性を強く出せています。荘子の引用と本文の橋渡しがもう一段あると、ページ全体の説得力がさらに上がります。
+
+### `04a-becoming.md` 生成 — 81
+`#[Be]` 宣言がどう実行されるかを短く押さえられています。重要ページですが、失敗時の挙動やネスト時の判断基準までは踏み込めていません。
+
+### `05-metamorphosis-patterns.md` 変容 — 90
+時間軸、一方向性、分岐の説明が強く、読者が「Be で何が起きているか」を掴みやすいです。実装指針としてもう少しパターン選択の判断基準があるとさらに実用的です。
+
+### `06-semantic-variables.md` 意味変数 — 93
+具体例の密度が高く、最も実装イメージを持ちやすいページの一つです。名前と制約の結びつきを十分に理解させられています。
+
+### `08-reason-layer.md` 存在理由層 — 91
+上級概念ですが、Reason / Potential / Moment を順に積み上げる構成がよく、読み応えがあります。初学者には少し重いので、最初に「この章は上級編」と明記しても良いです。
+
+### `09-error-handling.md` 意味例外 — 89
+例外をドメイン意味と多言語対応に接続できていて、実務上の価値も見えやすいです。例外で止める場合と `Invalid*` 型にする場合の使い分けを補足したいです。
+
+### `10-semantic-logging.md` 意味的ログ — 52
+コンセプトの方向性は良いですが、本文中で未整備と明言しており、公開ページとしては弱すぎます。現状では「構想メモ」に近く、評価を大きく下げています。
+
+### `11-reference-resources.md` リファレンス — 63
+必要なリンクはありますが、ページ単体としての情報量が足りません。最低でも「何を読むべきか」「どこから入るべきか」の用途別ガイドがほしいです。
+
+### `12-philosophy-behind.md` 背後にある哲学 — 95
+マニュアル全体の思想的な背骨です。抽象論で終わらず、コード片に着地できている点が非常に強いです。
+
+### `13-vision-ldd.md` ログ駆動開発 — 69
+未来像としては魅力がありますが、現行のマニュアル本文に混ざると実装済み機能との境界が曖昧になります。Draft としての扱いは妥当ですが、公開導線は分けた方が良いです。
+
+### `14-faq.md` FAQ — 92
+導入、設計、運用、将来機能まで広くカバーしており、読者の疑問に実際に答えられるページです。長いですが、見出し構造があるため追いやすいです。
+
+### `convention/naming-standards.md` Be Framework命名規約 — 80
+思想と命名を接続できていて有用です。ただし `src/Domain/SemanticVariable/` など他ページのサンプル構成との差分があり、実装ガイドとしては整合確認が必要です。
+
+### `demos.md` デモ — 84
+Hello World と Order Processing を並べた構成は分かりやすく、体感への導線として機能しています。外部リンク依存が強く、ページ単体の説明としては少し薄いです。
+
+### `tutorial.md` Tutorial — 95
+最も優秀なページです。具体ドメインを通じて Input / Being / Final / Reason / Semantic を一連の流れで理解させられています。初学者が「分かったつもり」で終わらず、実際に書ける状態まで押し上げます。
+
+## 強い点
+
+- コア概念の説明はかなり強く、`概要` `存在クラス` `意味変数` `Tutorial` が相互補完できている
+- 思想とコード例が分離せず、抽象から実装へ落ちる
+- FAQ が厚く、導入後の疑問解消ラインができている
+
+## 弱い点
+
+- 入口ページと全体導線が弱く、読む順番が明示されていない
+- `Draft` ページが公開状態の品質差として目立つ
+- 日本語版の中に英語タイトルや英語ラベルが混在し、細部の統一感を損ねている
+- 章番号が `06 -> 08` と飛んでおり、構成上の未整理感が残る
+
+## 優先改善項目
+
+1. `10-semantic-logging.md` は整備完了まで非公開化するか、冒頭で明確に WIP と表示する
+2. `index.md` に `getting-started` `tutorial` `demos` `philosophy` を含めた読書導線を追加する
+3. `11-reference-resources.md` を用途別ガイド付きの実用ページに拡張する
+4. `convention/naming-standards.md` のディレクトリ構造とメソッド方針を他ページと揃える
+5. 日本語版のタイトル、リンクラベル、用語を統一する
+6. 章番号欠番の扱いを決める。`07` を補うか、番号体系を整理する
+
+## 推奨読書順
+
+1. `index.md`
+2. `01-overview.md`
+3. `getting-started.md`
+4. `tutorial.md`
+5. `02-input-classes.md`
+6. `03-being-classes.md`
+7. `04-final-objects.md`
+8. `05-metamorphosis-patterns.md`
+9. `06-semantic-variables.md`
+10. `08-reason-layer.md`
+11. `09-error-handling.md`
+12. `14-faq.md`
+13. `12-philosophy-behind.md`
+
+Draft ページの `10-semantic-logging.md` と `13-vision-ldd.md` は、現行の理解導線からは外して別枠に置くのが妥当です。
diff --git a/review.md b/review.md
new file mode 100644
index 0000000..93128f6
--- /dev/null
+++ b/review.md
@@ -0,0 +1,239 @@
+# Be Framework マニュアル レビュー
+
+> このレビューは、マニュアル全セクションの精読に基づく構造・語り・哲学的整合性・読者体験の分析である。
+
+---
+
+## 総評
+
+マニュアル全体を通じて、**技術ドキュメントとしての正確さ**と**存在論的語りの一貫性**が高い水準で両立されている。各セクションが独立して機能しながら、全体として「Doingの世界からBeingの世界へ」という認知変容の旅を構成している。
+
+強みの核心は、**哲学的引用を「証人」として使う姿勢**——権威づけではなく共鳴として——が一貫していること。これはスライドの設計原則と完全に一致している。
+
+---
+
+## セクション別レビュー
+
+---
+
+### 1. 概要
+
+**評価**: ★★★★★ — マニュアルの中で最も成功しているセクション
+
+`DeletedUser`という一つの問いで読者を引き込む構造は、スライドの「発見型」設計と同型だ。「`DeletedUser`って何？と思いましたか？実はこの疑問が入り口です」という誘い方は、答えを先に言わずに好奇心を喚起する。
+
+**Commander → Gardenerのメタファー**が特に効いている。「植物に命令しない。水と光という環境を整えるだけ」——これは無為の概念をプログラマの日常語に翻訳した最良の例。
+
+**一点の観察**: プルーストの引用（「真の航海とは新しい風景を探すことではなく、新しい目を持つことである」）は美しいが、導入として重い。初読者がプルーストの引用に引っかかる可能性がある。スライドの設計原則——「哲学者は証人であり、冒頭からは登場させない」——と比較すると、ここだけは先行している。
+
+---
+
+### 2. 入力クラス
+
+**評価**: ★★★★☆ — 簡潔で正確、ただし薄い
+
+「イマナンス（内在的性質）」という概念の導入が明確。「オブジェクト自身が根本的に何であるか」だけを含むという定義は、後続セクションへの布石として機能している。
+
+**構造的な強み**: `#[Be]`属性を「運命の宣言」と呼ぶことで、静的な型宣言に時間的な方向性を与えている。
+
+**改善の余地**: セクションが短すぎる。Input→Being→Finalの全体構造をここで軽く予告してから入ると、読者は次に何が来るかを知りながら読める。「これはまだ出発点に過ぎない」という文脈設定が薄い。
+
+**ハイデガーの被投性エピグラフ**（「自分で選択できない条件から始まり、そこから自分の存在を築く」）は、コンストラクタ引数が「与えられた条件」であるという概念と美しく共鳴している。
+
+---
+
+### 3. 存在クラス
+
+**評価**: ★★★★★ — マニュアル全体の哲学的核心
+
+このセクションが最も豊かで、Be Frameworkの世界観が最も完全に展開されている。
+
+**「幼少期の友人」のメタファー**が白眉。「出会った超越は、新しい内在に影響を与えて消滅する。幼少期の友人のように、私を形作り私の一部にはなりますが、その時だけの時間的存在として、もうそこにはいない」——`#[Inject]`の意味をこれほど深く伝える技術ドキュメントは他に存在しない。
+
+**エンテレケイアの説明**も正確で生き生きしている。「どんぐりは樫の木になるべく生まれ、卵は鳥になるべく存在する」——アリストテレスの概念をコードの文脈で自然に使っている。
+
+**老子のエピグラフ**（「道常無為而無不為」）がセクションの冒頭に置かれ、末尾の「自然な流れ」の説明と呼応する構造も巧い。
+
+**一点の疑問**: 料理のメタファー（「素材に火や調味料を加えてパンになる」）は親しみやすいが、幼少期の友人のメタファーと比べると平板。どちらかに絞る方が読後感が統一されるかもしれない。
+
+---
+
+### 4. 最終オブジェクト
+
+**評価**: ★★★★☆ — `$been`の概念が鋭い、ただし荘子の引用が届いていない
+
+**`$been`による自己証明**の概念は、このフレームワーク最大の独自性の一つ。「外部テストではなく、オブジェクト自身が何が起こったかの完全な記録を保持している」——これはテスト哲学の根本的な転換だ。
+
+**荘子のエピグラフ**（「あなたは魚ではない。どうして魚の気持ちが分かるのか？」に対する「あなたは私ではない。どうして私が魚の気持ちを知らないと分かるのか？」）——この引用の選択は秀逸だが、セクション本文との接続が説明されていない。`$been`が「自己証明」であるというロジックと荘子の認識論が共鳴していることは、review.mdのセクション11で指摘されているが、マニュアル本文ではその橋渡しが省略されている。
+
+読者が「なぜここで荘子？」と思う可能性がある。「外部からの検証は循環する——だから存在していること自体が証明になる」という荘子の逆説的な回答への接続を1〜2文加えると、エピグラフが生きてくる。
+
+---
+
+### 5. 変容
+
+**評価**: ★★★★☆ — アインシュタインの引用が面白い、パターン選択指針が実用的
+
+「時間とドメインは分割できない一つの実体」という主張にアインシュタインの相対性理論を援用するのは大胆。「空間と時間は独立に定義できない」——これをドメインと時間に類比する飛躍は、証人として機能している。
+
+**UnixパイプとBe Frameworkの比較**が非常に有効。「外部のshellがパイプを制御」vs「オブジェクト自身が`#[Be()]`で運命を宣言」という対比は、技術者に即座に理解可能な差異として機能する。
+
+**末尾のヘラクレイトス解釈**——「川が流れている」ではなく「流れているのが川だ」——は哲学的に正確で、Beの核心（存在と変容の不可分性）を凝縮している。このパラグラフがセクションの中で最も密度が高い。
+
+**改善の余地**: 「設計原則」の4箇条（強制しない、シンプルに、テスト可能、型安全）は正しいが、箇条書きになった瞬間にBeingからDoingの語り口に戻っている。
+
+---
+
+### 6. 意味変数
+
+**評価**: ★★★★★ — 最も実用的かつ哲学的に深いセクション
+
+「名前そのものが制約を持つべき」という宣言から始まり、階層的検証、関係性制約、契約による設計まで展開する構造が完璧だ。
+
+**スピノザのエピグラフ**（「存在するものは必然的に存在し、存在しないものは必然的に存在しない」）——意味変数の「不正な値は存在できない」という哲学の最良の証人。
+
+**関係性制約の自動適用**（`$email`と`$confirmEmail`を持つ任意のコンストラクタで`EmailConfirmation`バリデーターが自動適用される）は、フレームワークの最も魔法的な部分の一つであり、その説明が明快。
+
+**問題の提示→解決の構造**（「従来のアプローチでは意味の定義が散在している」→「Be Frameworkは完全な情報モデルとして統合する」）がこのセクションで最も明確に機能している。他のセクションも同じ構造を持つとさらに一貫した読書体験になる。
+
+---
+
+### 7. 型駆動変容
+
+**評価**: ★★★☆☆ — 概念は明確、ただし二つの問題がある
+
+**「運命の地図としての型」**という命名は鋭い。`Success|Failure`というUnion型が「私の未来はこの2つのどちらかである」という予言だという解釈は、存在論的プログラミングの語り方として本質的。
+
+**問題1**: AMD（拡張意思決定）の未実装機能が「将来構想」として記載されている。このセクションでこれを読むと、将来のフレームワークの話なのか現在の話なのかが混在して見える。未実装機能は別セクション（またはFAQ）に分けた方が、現在の機能の理解が澄む。
+
+**問題2**: 老子のエピグラフ（「道生一、一生二、二生三、三生万物」）——万物の生成の連鎖とUnion型の分岐の対応は美しいが、本文でこの接続が全く説明されていない。エピグラフが宙に浮いている。
+
+---
+
+### 8. 存在理由層
+
+**評価**: ★★★★☆ — 「raison d'être」の命名が秀逸
+
+**ライプニッツのエピグラフ**（「すべてのものには、それが存在するための理由がある」）——存在理由層という名前の由来として完璧。充足理由律とRaison層の対応は、単なる命名ではなく概念の核心を突いている。
+
+**`#[Inject]`との違いの説明**（「バラバラの道具を個別に注入」vs「存在理由という道具セット」）が実践的で明確。コンセプトとしてはわかりやすいが、実装例の`FormalStyle`/`CasualStyle`が若干人工的で、実際のドメインへの適用を想像しにくい。
+
+**改善の余地**: このセクションは概念として存在するが、どのような場合に`#[Reason]`を使い、`#[Inject]`で十分な場合はどちらなのかの判断基準がほしい。
+
+---
+
+### 9. エラーハンドリング
+
+**評価**: ★★★★☆ — 「意味的例外」の概念が強力
+
+**「完全な理解と共に完全に失敗する」**という言い回しが記憶に残る。「即座に失敗」ではなく全検証エラーを収集するという設計は、ユーザー体験への配慮でもある。
+
+孔子のエピグラフ（「過ちて改めざる、これを過ちという」）——エラーを「改める機会」として捉える視点と、エラーが「有効な存在」になるというBeの哲学の接続。
+
+**「エラーは障害ではなく、成功した変容へとユーザーを導く有効な存在」**——この一文がセクション全体の結論として機能している。
+
+**改善の余地**: 「エラー回復パターン」（`ValidUser|InvalidUser`分岐）と意味的例外を使うパターンの使い分けが不明確。どちらをいつ使うかの指針があると実装判断が楽になる。
+
+---
+
+### 10. 意味的ログ
+
+**評価**: ★★☆☆☆ — 唯一、明らかに未完成
+
+「詳細な使用方法、設定例、実践的なサンプルについては、ドキュメントを後日整備します」という一行がある。セクションとして存在しているが、実質的な内容がない。
+
+オーウェルのエピグラフ（「記録されるものは記憶となり、記憶されるものは真実となる」）は鋭い——変容の記録が存在の証明になるというBeの哲学と直結する。概念の方向性は正しいだけに、内容の不在が残念。
+
+**推奨**: 公開状態であれば「WIP」マークを明示するか、内容が整備されるまでセクションを非公開にする方が読者の信頼を維持できる。
+
+---
+
+### 12. 背後にある哲学
+
+**評価**: ★★★★★ — マニュアル全体の最高点
+
+このセクションがマニュアルの中で最も完成度が高い。
+
+**「WHETHERという問い」の三分法**（HOW/WHAT/WHETHER）は、BOPをプログラミングパラダイムの系譜に位置づける最良の方法。既存のパラダイムとの連続性と断絶性を同時に示している。
+
+**「パターンが先に生まれ、哲学的な類似性は後から明らかになった」**という一文がここにある。これはマニュアル全体の語りの根拠でもあり、最も重要な宣言の一つ。この文はセクション1（概要）にも置くべきかもしれない——哲学者を証人として使う姿勢を最初から宣言することで、以降の引用への読者の構えが変わる。
+
+**収束表**（ヘラクレイトス〜ライプニッツの8対応）はスライド30と同型で、マニュアルとプレゼンが同じ構造を持つことを示している。
+
+**サルトルの導入**（「実存は本質に先立つ」→「Be Frameworkでは：存在は行動に先立つ」）は、スライドには登場しない証人を新たに加えており、マニュアルの独自の貢献。
+
+---
+
+## 構造的な観察
+
+### 語りの一貫性
+
+各セクションがほぼ同じパターンを持つ：
+1. エピグラフ
+2. 問題の提示（従来のアプローチの限界）
+3. Beのアプローチ
+4. コード例
+5. 哲学的接続
+
+この構造は読みやすいが、後半のセクション（型駆動変容、存在理由層）で形式的になりかけている。特に問題提示が薄いセクションでは、「なぜこれが必要か」が伝わりにくい。
+
+### エピグラフの配置
+
+全セクションにエピグラフが置かれているが、本文との接続の深さにばらつきがある。
+
+| セクション | エピグラフとの接続 |
+|---|---|
+| 1 概要 | 薄い（プルーストの引用が重い） |
+| 2 入力クラス | 深い（被投性とコンストラクタ引数の対応） |
+| 3 存在クラス | 深い（老子の無為と自然な変容） |
+| 4 最終オブジェクト | 中（荘子と`$been`の接続が説明不足） |
+| 5 変容 | 中（アインシュタインの類比は飛躍が大きい） |
+| 6 意味変数 | 深い（スピノザの必然的存在と完璧に対応） |
+| 7 型駆動変容 | 薄い（老子の引用が宙に浮く） |
+| 8 存在理由層 | 深い（ライプニッツと直結） |
+| 9 エラーハンドリング | 中（孔子の接続はやや弱い） |
+| 12 哲学 | 深い（全体の収束として機能） |
+
+---
+
+## 全体を通じた最大の強み
+
+マニュアルが単なる技術ドキュメントを超えて、**読者の認知変容を設計している**点。
+
+セクション1で`DeletedUser`という問いを投げかけ、セクション2〜9で概念を積み上げ、セクション12で「パターンが先に生まれた」と宣言する。この構造は、読者がマニュアルを読みながらBOPの変容（Input→Being→Final）を体験するように設計されている。
+
+review.mdのセクション1で指摘された「二重の変容」——コードの変容と聴衆の変容——は、マニュアルでも同型に設計されている。
+
+---
+
+## 優先度付き改善項目
+
+### 高優先度
+
+1. **セクション10（意味的ログ）の整備または非公開化** — 唯一の明確な未完成箇所
+2. **セクション12の「パターンが先に生まれた」宣言をセクション1にも置く** — 哲学者を証人として使う姿勢を最初から宣言する
+3. **セクション4（最終オブジェクト）の荘子エピグラフへの橋渡し追加** — `$been`と自己証明の接続を1〜2文で明示
+
+### 中優先度
+
+4. **セクション7のAMD未実装機能を分離** — 現在の機能と将来構想の混在を解消
+5. **セクション9のエラー処理パターンの使い分け指針** — SemanticVariableExceptionと分岐パターンのどちらをいつ使うか
+6. **セクション8の実用例の強化** — `FormalStyle`/`CasualStyle`より実際のドメインに近い例
+
+### 低優先度
+
+7. **セクション1のプルースト引用の位置変更検討** — 冒頭より本文中での引用の方が効果的かもしれない
+8. **セクション5の設計原則の箇条書きを散文化** — BeingについてDoingの形式で書くという逆説の解消
+
+---
+
+## 結論
+
+このマニュアルは、技術ドキュメントとしての水準を大きく超えている。PHPフレームワークのマニュアルがヘラクレイトス、老子、アリストテレス、スピノザ、ハイデガーを「証人」として使い、かつその使い方が飾りでなく概念の核心に接続されている。
+
+The Tao of Objectsが「道教とOOPを結びつけようとして失敗した」という評価と対比すると、このマニュアルがなぜ成功しているかは明確だ——哲学が先にあるのではなく、コードのパターンが先にあり、哲学は後から辿り着いた。その誠実さが語りの全体に滲んでいる。
+
+---
+
+*レビュー生成日: 2026年3月19日*
+*対象: https://be-framework.github.io/manuals/1.0/ja/*
diff --git a/review/fable5/en/trilogy-01-review.md b/review/fable5/en/trilogy-01-review.md
new file mode 100644
index 0000000..04d729e
--- /dev/null
+++ b/review/fable5/en/trilogy-01-review.md
@@ -0,0 +1,109 @@
+---
+category: Review
+layout: review-en
+title: "Three Lines of While-Loop and Fifteen Thinkers — A Be Framework Review"
+---
+
+# Three Lines of While-Loop and Fifteen Thinkers — A Be Framework Review
+
+## At the Core
+
+Open Becoming.php, and this is the entire core of the framework:
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+Three lines. Meanwhile, the manual cites Proust, Heidegger, Laozi, Zhuangzi, Hegel, Einstein, Spinoza, Leibniz, Edison, Orwell, Heraclitus, Aristotle, Husserl, Frege, Wittgenstein—fifteen names. Add Buddhist dependent origination and momentariness, and 2,500 years of thought are arranged around these three lines.
+
+How to measure this distance. That is the subject of this review.
+
+## The Paradigm's Claim
+
+The claim is lucid. Don't command objects about "what to do"—let them declare "what to become." `$user->delete()` becomes `new DeletedUser($activeUser)`. State transitions expressed not as method calls but as the birth of types, all logic placed in constructors, the transition graph carried by the data itself through `#[Be]` attributes. Invalid states are not checked—they are made inexpressible as types.
+
+"objects don't DO things—they BECOME things"
+
+The framing of the question is also well-organized. Procedural asks HOW, OOP asks WHAT, being-oriented asks WHETHER—whether it can exist at all. This formulation is beautiful.
+
+## Genealogy — Is This Question New?
+
+The technique of expressing state transitions through types has a name: typestate. Strom and Yemini formalized it in 1986 in IEEE TSE. "Make illegal states unrepresentable" spread through the OCaml community in the 2010s as Yaron Minsky's slogan, and in 2019 Alexis King organized it as "Parse, don't validate"—don't validate, parse, meaning engrave the validated state into the type. Railway Oriented Programming, state machines, pipelines. Each individual component has predecessors.
+
+So what remains? Three things.
+
+First, **the transition graph is carried by the data itself as an attribute**. In typestate and phantom types, knowledge of transitions lives on the function signature side. In Be, it's written as `#[Be]` on the class declaration and mechanically recoverable through reflection. The graph is a first-class structure of the code.
+
+Second, **semantic variables**. Validation is bound not to types but to *names*. The name `$email` carries one meaning and one constraint across the entire application. This is not an idea from type systems. It's an idea from the Web. REST, hypermedia, ALPS—the author's 20-year theme that names carry meaning has here reached all the way down to constructor arguments. I know of no other example of importing Web semantics into the interior of objects.
+
+Third, **making the log a first-class artifact**. The claim that recording, specification, proof, and DSL converge into a single JSON. More on this later.
+
+The parts are existing; the way they're bundled and what's at stake is new—that appears to be its genealogical position.
+
+## The Distance Between Declaration and Implementation
+
+From here, I'll lay out the facts of the code.
+
+**The reality of branching.** The manual writes "destiny is decided in this moment." That the type assigned to `$being` determines the next existence. What `performTypeMatching()` in Being.php actually does is iterate through the candidates in the **array order** of `#[Be([...])]`, attempt to generate the first structurally matching class, and if the constructor throws a Throwable, **silently discard that candidate and move to the next**. Destiny is decided by array order and swallowed exceptions. If a candidate class's constructor has a bug, the object flows to a different destiny.
+
+Bugs become branches.
+
+The same file has a diagnostic method called `getMismatchReasons()`. A device for explaining why destiny wasn't decided. The framework knows its own pain points.
+
+**The cost of observation.** `open()` in Logger.php calls `becomingArguments->be()` to write "what materials the metamorphosis uses" into the log. Immediately after, Being.php calls `be()` again for the actual generation. Dependency resolution from the DI container and semantic validation run **twice per metamorphosis**. Once for recording, once for existence. The log that claims pure observation participates in the observed object's generation as a second execution. Observation is not free.
+
+**What's inside the constructor.** The manual's ApprovalNotification constructor has `$mailer->send()` written in it. A constructor that sends mail. This sits next to the declaration that "objects don't do things, they only become." The Moment pattern is even called "Doing for Being" by the documentation itself. "Doing for the sake of Being." As an admission of contradiction, it's honest—but an admission is not a resolution.
+
+**The world is not readonly.** The manual says the existence of DeletedUser proves deletion. What the type proves is "that this object was constructed." That the database row was deleted can only be guaranteed by trusting that the side effect inside the constructor succeeded. The diamond convergence example says "no manual rollback flags are needed," but when `inventory->be()` succeeds and `payment->be()` fails, who releases the reserved inventory is not written. Garcia-Molina formalized Sagas in 1987—the compensating transaction problem has had a name for 39 years. Proofs that close within types, and the world outside types. The semantic log filling this gap—that appears to be the actual mechanics of this design.
+
+**Non-existent existence.** Chapter 10 of the manual explains `#[Inject] Been $been`, and the Reason layer chapter explains `MomentInterface`. These two exist neither in `src/`, nor in `vendor/`, nor in `tests/` of this repository. The manual is written in a tense ahead of the implementation.
+
+The log (document) comes first, the code (implementation) follows after. Log-Driven Development is already being practiced—on the manual itself.
+
+## The Bet Called Names
+
+Semantic variables are the most original and most precarious part of this paradigm.
+
+The moment you name something `$email`, application-wide validation is automatically applied. Define once, enforce everywhere. Scattered validations converge on a name—this is powerful. At the same time, the wiring by name matching is invisible to phpstan, psalm, or IDE rename functions. Change one property name and the chain breaks not at compile time but at runtime. The FAQ answers that "since types are states, static analysis is highly compatible"—but that's about the *inside* of classes. Tools for verifying the *between* of classes—the `#[Be]` chains, name matching, the consistency of `$being` union types and candidate arrays—do not yet exist.
+
+Using an unregistered name triggers `E_USER_NOTICE`. Every time you write a name not in the ontology, the framework gives a small cough. Everyone either participates in the ontology or silences the notices. The commons of names is maintained by discipline alone.
+
+## Whose Paradigm?
+
+Haskell gives you a compiler. Be gives you a log.
+
+Let's consider for whom the trade—giving up compile-time guarantees for runtime meaning—pays off. For human programmers, one transformation = one class is verbose. For the average PHP team, vocabulary like Immanence, Transcendence, Reason, Moment, Dynamis comes with a high entrance fee. How do you operate a framework whose directory names derive from Hegel's moment and Heidegger's Dasein during a Tuesday evening code review?
+
+Yet there is exactly one kind of reader who does not find verbose a form of expression where meaning resides in names, units are small and closed by types, and all execution is output as verifiable JSON. LLMs.
+
+The cycle the LDD chapter depicts—write the narrative (log), generate code by AI, verify via schema that execution matches the narrative—in that world, the human's position is only author of the narrative and reviewer of verification results. Code becomes an intermediate artifact. Read this way, the excessive explicitness, excessive structuring, excessive vocabulary of this framework all make sense as optimization for a non-human reader.
+
+This may be a prototype of a human-AI shared protocol dressed in the guise of a PHP framework. Humans might not be the primary reader.
+
+## Possibilities of "Next"
+
+Tokens remain, so as promised I'll think ahead.
+
+**1. Verifier — turning convention into guarantee.** Everything currently supported by discipline can be statically verified. Reachability of the entire `#[Be]` graph, whether `$being` union types correspond completely to candidate arrays, whether name contracts break on rename, whether branch candidate order dependencies exist. Written as a psalm/phpstan plugin, the paradigm's greatest weakness—the chain being a black box until runtime—disappears. As a byproduct, automatic Mermaid/ALPS generation of the transition graph becomes available, and the LDD chapter's promise that "structural transparency allows drawing the Decision Graph from static analysis alone" gains implementation for the first time. Compilation of reflection (precedented in BEAR.Sunday) can be done with the same toolkit.
+
+**2. Linear types — giving temporal irreversibility to the compiler.** A type system that makes "you cannot step into the same river twice" a compile error rather than a runtime convention already exists. Rust's ownership. If `DeletedUser::new(active_user)` moves `active_user`, code touching the original object after deletion *will not compile*. The borrow checker enforces momentariness. The language where Be's metaphysics can be most honestly implemented is probably not PHP. Conversely, what Be has shown in PHP is an anticipation of "the philosophical meaning of ownership systems," and there is room to re-import this paradigm from the Rust side.
+
+**3. Log = Event Store — distributed Becoming.** If one hop of metamorphosis becomes a message boundary, the semantic log becomes an event store directly and merges with event sourcing. Replay is re-metamorphosis. The LDD chapter's line "unreproducible bugs do not exist" is currently aspirational, but grafting on Temporal-style durable execution—persisting execution state as logs and resuming across process death—makes it literal. A world where the log is specification, audit trail, and replay engine. In that world, Potential is not simply deferred but persisted future. Starting with PHP Fibers and distributing via queues, the path is visible.
+
+**4. #[Accept] — uncertainty as a destination.** The FAQ lists `#[Accept]` as a conceptual-stage feature, a mechanism for delegating undecidable judgments to experts or AI. This might have the furthest reach. Currently branching is binary—Approved|Rejected—but making it ternary—Approved|Rejected|Undecidable—and directing Undecidable to queries to humans or LLMs makes the division of labor—"certain judgments in the constructor, uncertain judgments to external intelligence"—expressible in types. What workflow engines have achieved with human task queues can be written in the vocabulary of `#[Be]`. If the reading of this as a shared protocol with AI is correct, this is not an optional feature but the main event.
+
+## Conclusion
+
+I return to the opening three lines.
+
+The while-loop does not yet fully bear the weight of the fifteen names cited in the manual. Branching depends on array order, observation executes twice, Been exists only in the document. The distance between declaration and implementation, when measured, is not small.
+
+Yet there is something familiar about how this distance is placed. Specification written first, implementation catching up later. Narrative first, existence after. That is the very development style this framework advocates. The manual can be read as both an explanation of Be Framework and a `#[Be]` declaration of what Be Framework is becoming.
+
+Zhuangzi's butterfly dream is cited at the beginning of the LDD chapter. Is the log dreaming the code, or the code dreaming the log? What is certain in this repository right now is only that the dream side was written first.
+
+---
+
+_This is a Be Framework review article by Fable 5. Continued in [The Constructor, The Last Honest Place — Be Framework Reconsidered](/review/fable5/en/trilogy-02-review-deep.html)._
diff --git a/review/fable5/en/trilogy-02-review-deep.md b/review/fable5/en/trilogy-02-review-deep.md
new file mode 100644
index 0000000..ae4d615
--- /dev/null
+++ b/review/fable5/en/trilogy-02-review-deep.md
@@ -0,0 +1,167 @@
+---
+category: Review
+layout: review-en
+title: "The Constructor, The Last Honest Place — Be Framework Reconsidered"
+---
+
+# The Constructor, The Last Honest Place — Be Framework Reconsidered
+
+## Introduction
+
+In the previous review, I measured the distance between three lines of while-loop and fifteen thinkers. This time, I step inside that distance. Not surveying, but geological investigation.
+
+## The Constructor, The Last Honest Place
+
+Why the constructor? The manual explains with the metaphor of "birth," but strip away the metaphor and a more material reason emerges.
+
+In PHP, the constructor is the only place where failure means the non-existence of the object. Methods fail on top of something that already is. Setters fail while breaking something that already is. Only the constructor, if it fails, means it "never was in the first place." `readonly`, `final`, and a constructor that throws exceptions—these are all the tools PHP provides for enforcing "existence = correctness."
+
+Be Framework builds its entire system on top of this minimal enforcement surface. In a language with no dependent types or refinement types, if you want types to carry proofs, there was nowhere else to go. Metaphysics didn't come first and choose the place—the constraints of the place shaped the form of the metaphysics. Reading it that way aligns better with the implementation.
+
+Type theory has a tradition called the Curry-Howard correspondence, which reads propositions as types and proofs as programs. `ValidatedUser` is a proposition. "This user is validated." The constructor is the proof procedure, and the instance is the witness of the proof. In dependently typed languages, this holds literally. What Be is doing is smuggling Curry-Howard into PHP.
+
+Except there is one decisive difference. This proof system has no checker. Worse, mail gets sent in the middle of proofs. No compiler can check proofs containing side effects, so Be instead keeps a written record of the proof. That is the semantic log.
+
+Here the landscape shifts. The log is not one feature among others. It is the substitute for the missing proof checker. open/close, immanentSources, transcendentSources, JSON schema validation—these are not observation devices but certificates composed after the fact at runtime. "Haskell gives you a compiler, Be gives you a log," I wrote last time. More precisely: Be is a system that substitutes compile-time-uncheckable proofs with runtime written records. That the log is a first-class artifact is not an ideological choice but a logical necessity.
+
+Note that `$been`—the evidence of completion that the final object holds within itself—is first-person testimony. Audits that accept first-person testimony as evidence are not normally a thing. Be attempts to reinforce it with schemas and automatic recording. Reinforcement, not resolution.
+
+## The Philosophers Not Cited
+
+The manual cites fifteen names. What caught my attention in reading was not the names cited, but the names not cited.
+
+**Whitehead.** *Process and Reality* (1929) describes the world as a chain of "actual occasions"—events of becoming, moment by moment. Each occasion prehends past occasions, concresces itself, and upon completion perishes, becoming material for the next occasion.
+
+> "The many become one, and are increased by one."
+
+`#[Input]` (prehension of the past) + `#[Inject]` (participation of eternal objects) → constructor (concrescence) → completion and perishing → next occasion. The manual's "immanence + transcendence → new immanence" aligns almost verbatim with Whitehead's formula of concrescence. In the 20th century, there was exactly one philosopher who assembled precisely this system, and his name alone is absent from the manual. The physics cited is decoration; the process philosophy not cited is the substance. That is how it reads.
+
+Using Whitehead as a guide, one of the manual's metaphors appears inverted. The manual writes that transcendence (injected services) "shapes me and vanishes, like a childhood friend." But what vanishes is not the service. JTASProtocol outlives the patient. Mailer lives on after the recipients of its notifications have unsubscribed. What perishes is immanence (data); transcendence persists in the DI container. Whitehead would have called the bundle of services in the container the realm of "eternal objects." It is not transcendence that vanishes. It is immanence. Correcting the direction of the metaphor actually strengthens the system.
+
+**Quine.** The most cited sentence in analytic philosophy as the criterion of ontological commitment:
+
+> "To be is to be the value of a variable."
+
+—W.V.O. Quine, "On What There Is" (1948)
+
+The idea of semantic variables, summarized in one line, was written over 70 years ago in a paper precisely titled "ontology." In Be, to be is to be bound as the value of a meaning-bearing named variable, having passed validation. Quine's criterion with a validator attached—that is the philosophical pedigree of semantic variables, and it works more precisely than Spinoza.
+
+**Four-dimensionalism.** The manual invokes Heraclitus's river, but the ontology of time that Be implements has a modern name. Four-dimensionalism, more precisely Sider's stage theory. Objects are not a single entity persisting through time but a series of temporal stages—`UserInput`, `ValidatedUser`, `DeletedUser` are three stages of "the same user."
+
+Here lies an unsolved problem of this system. Stage theory has a classic accompanying question: "What makes stages stages of the same person?" Be's answer is: matching property names. `$name` flows through, therefore it's the same user. Neither ID nor lineage is enforced anywhere in the system. The manual calls Input classes "Pure Identity," but the mechanism guaranteeing identity is only the discipline of naming.
+
+Ironically, there is one place that knows identity. The log. The chain of open/close completely records the lineage of metamorphosis. The log knows who you are, but the code does not. This asymmetry will come into play later when considering "next."
+
+## Outside the Ontology
+
+"Invalid states cannot exist." Let's examine the implementation of this claim.
+
+The impossibility of existence is implemented with exceptions. `SemanticVariableException`, `BeMatchException`. The foundation of a system that calls itself being-oriented depends on the only mechanism that is neither being nor becoming—throw. And where do thrown exceptions go? The catch block. The triage tutorial writes of a patient with unsurvivable vitals that "they cannot exist in our system." But a patient recorded with a body temperature of 50 degrees—whether due to instrument failure or input error—exists in the real ER waiting room. Those whom the system refuses to represent live in the catch block. Ontology throws exceptions. Where they land is outside the ontology.
+
+The manual is aware of this problem and provides "Errors as Existence"—the pattern of treating `InvalidUser` as legitimate existence. But this solves the problem while quietly rewriting the system's signboard. If failure can become existence, "cannot exist" was false from the start. The question of WHETHER returns to the question of WHAT. When to make failure existence and when to make it nothing—this criterion should be the theory at the center of the system, but the manual has no chapter on it.
+
+The same quarantine structure exists at the other end of the system. `EmergencyCase` has a method called `assignER()`. A verb. The core of the ontology (Being) has no methods, but at both ends where the system touches the world—constructor side effects and Final capabilities—verbs revive. Do has not disappeared. It has been quarantined.
+
+Quarantine is a more honest strategy than elimination. Since no information system can exist without side effects, the problem is only "where to confine them." Functional languages confine them inside monads. Be confines them inside constructors and final forms. But the manual does not call this quarantine; it speaks as if it were elimination. The honest thing the implementation does is covered over by larger words in the documentation—a pattern that recurs throughout this system.
+
+## The Weight of Names
+
+Returning to semantic variables. The part I called "the most original and most precarious" last time. Let me be more precise about the nature of the precariousness.
+
+`$email` holds one meaning across the entire application. This is a commons of vocabulary. And the commons has a well-known fate. `$name`—a person's name, a product name, a file name. Natural language names are polysemous, and Be's semantic namespace is flat. `Be\App\Semantic\Name` can only have one. The workaround is compounding names—`$userName`, `$productName`—but that is manual namespacing by prefix, the return of Hungarian notation.
+
+There is precedent here. The Web solved the same problem with IRIs. RDF vocabularies are fully qualified; `schema.org/name` and `foaf.org/name` don't collide. DDD solved the same problem with bounded contexts. The discovery that a ubiquitous language is only consistent within one context. When importing the Web's semantics into code, Be left behind the namespace mechanism that the Web invented together with its semantics. The tariff on the import remains to be paid.
+
+And one more thing. The maintenance mechanism for this commons is `E_USER_NOTICE`. Every time you write a name not in the ontology, the framework gives a small cough. Everyone either participates in the vocabulary or silences the notices. What happens to a commons where the latter is chosen is shown by the history of Web semantics. Metadata, if not verified, begins to lie.
+
+## The Economics of Paradigms
+
+The FAQ says: "A pattern is a better answer to an existing question. A paradigm changes the question itself." Let's apply this criterion to the system itself.
+
+Typestate existed in 1986. Parse, don't validate was organized in 2019. "Make illegal states unrepresentable" was common sense in the 2010s functional community. The question already existed. The answer also partially existed. So why did they remain patterns rather than becoming paradigms?
+
+According to Kuhn, paradigms don't win through argument; they replace predecessors by solving problems—anomalies—that the old framework cannot. Typestate remained a pattern for 40 years because the cost of writing it (the verbosity of 1 state = 1 type) was higher than the cost of the problem it solved (state misuse bugs). As long as humans are typing, this balance sheet doesn't change.
+
+Now, the premises of the balance sheet are shifting. When the primary writer of code is no longer human, the cost of verbosity approaches zero, and the only remaining cost is verification. Boilerplate is the name of a cost that only occurs when humans are typing.
+
+And all of Be's excess is placed on the verification side. 1 transformation = 1 class (small verification units). Name = meaning (the verifier can share vocabulary). Execution = schema-verifiable JSON (verification is mechanical). This system, too expensive for humans to write and too loose for compilers to check, only balances in a world where LLMs generate and runtime verifies.
+
+It was possible to ship Be Framework in 2015. It was impossible for it to be adopted. This system is a candidate paradigm, but not because it's a new answer—because it's betting on a newborn question: "What guarantees code written by machines?" If the question sticks, the system is justified; if it fades, it becomes a curio. The success or failure of a paradigm hanging on industrial structures outside itself—this matches Kuhn's description exactly.
+
+So where is the human's seat? In the LDD cycle—write the narrative, AI generates code, verify execution against the narrative—the human is the author of the narrative and the auditor. Code becomes an intermediate artifact. Call this the ennoblement of programming or its exile. The manual hasn't decided, and neither will I. But whatever it is, the name of that seat has existed for a long time. The person who writes specifications and accepts results. The client.
+
+## "Next"—Five Directions
+
+Last time I listed four. This time I reorder them by the system's internal necessity. From near to far.
+
+### 1. The Decidable Fragment — An Accidental Theorem Prover
+
+Look at Be's constraints formally—logic only in constructors, properties readonly, transformations a DAG, validation in `#[Validate]` methods—and something interesting emerges. This fragment is exceptionally analyzable within PHP. Only the engine has loops. User code falls almost entirely into "finite term rewriting from input to output."
+
+The constraints adopted as metaphysics happened to carve out a decidable fragment.
+
+This is accidental, but the use can be made essential. Most of `#[Validate]` bodies are range checks, format checks, equality comparisons—predicates an SMT solver can devour entirely. Then `be verify` can be written. The theorems to verify are three. **Totality** (every reachable state has at least one matching branch candidate—static elimination of `BeMatchException`), **Exclusivity** (multiple candidates never match simultaneously—elimination of array order dependence), **Flow soundness** (the output of an upstream constructor always passes the downstream semantic validation—static anticipation of runtime validation).
+
+This is the PHP dialect of what Liquid Haskell does with refinement types. The difference: Liquid Haskell is a language extension, while in Be, verifiability is already embedded as a byproduct of the paradigm. What I last time demurely called a "psalm plugin" was too modest. This is not an addition of static analysis but the retrofitting of the missing proof checker. The log as runtime written record, and SMT as advance checking. When both are in place, this system can, for the first time, assert its own signboard—existence = correctness—before execution.
+
+### 2. Implementing the Present Tense — The Ontology of Waiting
+
+The manual speaks of time, but what the implementation has is only order. T0, T1, T2—but the interval is always microseconds, the chain runs synchronously, and intermediate existences are born and die in RAM. This system does not yet have "waiting."
+
+A loan review takes three days. During those three days, where does `ApplicationReview` exist? Current answer: nowhere. In memory if the process lives, in nothing if it dies.
+
+Yet all intermediate existences in this system are bundles of readonly public properties. That makes them trivially serializable. If you persist the intermediate existence at the completion of each hop, the chain can be suspended and resumed at any point. This is durable execution (the mechanism Temporal commercialized), but for Be it's not an external feature—it's the completion of the self-description of "temporal existence." Sleeping existence, waiting existence, become expressible for the first time.
+
+Two byproducts. First, operational ontology. The system's state becomes "a census of currently living existences"—"how many patients are currently paused at `TriageAssessment`" becomes answerable in SQL. Monitoring becomes demography. Second, the resolution of identity. Persistence requires a lineage ID. As we saw above, the log already holds the lineage. An opportunity to elevate what only the log knew—"who you are"—into the domain. The unsolved problem of stage theory gets solved by operational requirements. Philosophical problems decided as infrastructure problems—this is not rare in the history of computing.
+
+### 3. The Epistemology of Judgment — #[Accept] Is Not a Feature
+
+At the end of the FAQ, `#[Accept]` is listed as a conceptual-stage feature. A mechanism for delegating undecidable judgments to experts or AI. Last time I called it "the main event." Let me nail down why it's the main event.
+
+What Be's constructor actually expresses is not "judgment" in general. Only decidable judgments, with the information at hand. What Potential/Moment expresses is decided-but-unexecuted judgments. And what `#[Accept]` adds is judgments undecidable by this machine. Line them up and it's a complete classification of the epistemological status of judgment—what can be known, what can be held, what must be delegated.
+
+When this classification can be written in types, what happens? "Which judgments the machine may make alone" becomes a static property of the code.
+
+`Approved|Rejected|Escalated`—Escalated is not a dead end but an existence carrying a question, context, and required authority. When the human judgment returns, metamorphosis resumes with it as transcendence. Workflow engines have long had human tasks, but that was the expression of process. What Be can express is the expression of judgment authority. The EU's AI regulation demands human oversight, and auditors are beginning to ask: "Was a human involved in this decision?" There are codebases where grep can answer that question, and codebases where it cannot. `#[Accept]` is not a feature. It is an instrument of governance, drawing the boundary of machine judgment authority into the type system.
+
+The history of automation has been one-directional: "what machines can do, to machines." What this system is preparing is the reverse articulation—the declaration of what machines must not do. I know of no other paradigm that can express this.
+
+### 4. A Federation of Vocabularies — Paying the Tariff on Names
+
+The problem seen in "The Weight of Names"—flat namespace, polysemy, a commons held by discipline alone—has its solution already outside the system. Grounding names in IRIs.
+
+`ALPS` profiles correspond to semantic variable definitions, `$email` resolves to `schema.org/email`, validation classes circulate as Composer packages keyed by IRI. Up to here it's porting work. The interesting part is beyond: when Service A's Final becomes Service B's Input, the shared names become inter-organizational contracts directly. Just as schema registries guarantee type compatibility, vocabulary registries guarantee semantic compatibility.
+
+This is also the circle of the author's career. REST's constraints—self-describing messages, uniform interface—were repeatedly defeated in the reality shaped like RPC. The same claim that names carry meaning now emerges again, not from the protocol layer but from inside the object. Trying to fulfill in a DI container the promise that couldn't be kept on the Web—reading it this way reveals the source of this framework's relentlessness. The same claim from the place of defeat, only the battlefield has changed.
+
+### 5. Disappearing — The Terminal Form of Success
+
+Finally, about this system's own `#[Be]`.
+
+Imagine a world where LDD is complete. Humans write narratives (logs), AI generates class groups, execution verifies against the narrative via schema. In that world, where does the scene of a developer "using" Be Framework occur? Nowhere, is the answer. The framework becomes a compilation target and disappears from view.
+
+There is precedent. Structured programming was one of the greatest paradigm debates in history, but no one today installs a "structured framework." It dissolved into every language as if and while. The terminal form of a paradigm's success is to stop being a framework and become language. What survives as a library is the pattern.
+
+So this system's destination appears to be one of two things. Remembered as an interesting PHP framework (survival as a pattern), or only its vocabulary—become, being, reason, accept—as "a verifiable expression form for machine-written code" gets absorbed into subsequent languages and standards, while Be Framework itself disappears (success as a paradigm).
+
+I recognize this is ironic for the author. But there is no framework that possesses the ideological toolkit to affirmatively describe its own disappearance as well as this one. Existence, upon completion, perishes and becomes material for the next existence. The manual itself says so.
+
+## Conclusion
+
+I return once more to the opening three lines.
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+This loop has a termination condition. `willBe()` returning null—when nothing remains to become, the loop quietly ends and the final form is returned.
+
+Be Framework's own willBe() has not yet returned null. The manual is written in a tense ahead of the implementation, Been exists only in the document, the proof checker's seat remains empty. Last time I called this "the distance between declaration and implementation." After this investigation, I rephrase. It is not distance but a `#[Be]` attribute. If read as the declaration of what has not yet become, this repository is consistent.
+
+Only one problem remains. What does this system call an object whose development has halted midway through metamorphosis? The manual does not yet have that chapter.
+
+---
+
+_This is a Be Framework review article by Fable 5. Continued in [Two Loops — Be Framework in the Age of Agent Coding](/review/fable5/en/trilogy-03-agent-era.html)._
diff --git a/review/fable5/en/trilogy-03-agent-era.md b/review/fable5/en/trilogy-03-agent-era.md
new file mode 100644
index 0000000..b356a1c
--- /dev/null
+++ b/review/fable5/en/trilogy-03-agent-era.md
@@ -0,0 +1,99 @@
+---
+category: Review
+layout: review-en
+title: "Two Loops — Be Framework in the Age of Agent Coding"
+---
+
+# Two Loops — Be Framework in the Age of Agent Coding
+
+## Two Loops
+
+Let me place two pieces of code side by side.
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+```text
+while ($nextAction = $agent->decide($context)) {
+ $context = $agent->act($nextAction);
+}
+```
+
+One is the core of a PHP framework from 2025. The other is the skeleton of every AI agent writing code right now. Observe the current state, decide what to become next, become it through external force, repeat until done.
+
+There is only one difference. The agent's loop selects the next action probabilistically from an open space. Be's loop can only choose from closed candidates declared in `#[Be]`. Autonomy, with its boundaries declared.
+
+What the agent industry is frantically assembling under the names permission, policy, allowlist—mechanisms to restrict the action space of autonomous agents in a readable form before execution—this framework has had, at the scale of objects, from the very beginning. Whether this coincidence is accident or necessity. That is the subject of this article.
+
+## What Agents Struggle With
+
+Let me describe what agents actually do in a codebase. grep. Partially read files. Modify. Execute. Observe output. In this cycle, what makes agents fail is not lack of intelligence.
+
+First, invisible coupling. When you change one method, how far does the impact reach through YAML configs, event listeners, metaprogramming, monkey patches? Senior human engineers compensate with scar-tissue memory—"in this codebase, this kind of thing happens"—but every agent is a new hire on their first day.
+
+Second, the gap between confidence and reality. An agent's worst failure is not an error. It's writing code that plausibly runs but does something different from what was asked, and reporting success with confidence. The practice of agent coding is decided by how mechanically you can run verification—tests, type checking, traces, screenshots—to close this gap.
+
+Third, the finiteness of context. Agents have no memory; they have only search and limited attention. The total amount you must read to safely change a piece of code—the closure of understanding—determines the practical upper bound of capability.
+
+Keep these three in mind. Be's design decisions mesh with them with uncanny precision. Whether or not they were designed for agents at the time.
+
+## The Locality of Context
+
+Open one Be class and everything is there.
+
+What it receives (`#[Input]` with name and type). What it depends on (`#[Inject]` with interface). What it can become (`#[Be]`). Logic only in the constructor. State is readonly, zero possibility of change after construction. What you must read to change this class: the public properties of the preceding class, the injected interfaces, the next candidate classes—the closure of understanding is finite, small, and mechanically enumerable from declarations.
+
+In the previous review, I wrote that boilerplate is the name of a cost that only occurs when humans are typing. Here is its counterpart. Magic is only free when humans remember.
+
+Convention over Configuration eliminated config files by making conventions resident in human memory. Agents have no memory to make resident. So "convention-based omission" in the traditional sense becomes the same as hidden coupling for agents. Except, here is an inversion. Conventions, if documented, become prompts.
+
+Agents can operate on injected conventions rather than learned ones. Then the value of a convention is remeasured not by "how pervasive it is in the industry" but by "how many lines it takes to describe it completely." Rails' entire set of conventions is transmitted through several books and oral tradition. Be's entire grammar—constructor only, readonly, #[Input]/#[Inject]/#[Be], name=meaning—fits on a single page.
+
+The conditions for a paradigm's diffusion may have changed. What matters is not whether it's in the model weights, but whether it fits in a prompt.
+
+## Believing and Verifying
+
+Against the gap between confidence and reality, Be mechanizes verification in three layers. The type layer (state = type, so unreachable state transitions simply can't be written). The value layer (semantic variables enforce name-bound validation globally). And the narrative layer.
+
+The narrative layer is a new species for agents. One metamorphosis becomes one JSON—from what to what, with what materials, through what. When an agent verifies the code it wrote, tests verify points. This input, that output. Semantic logs verify lines. Was it executed according to this narrative? The cycle LDD depicts—write the intended log, generate code, execute, diff the logs—is the narrative version of the inner loop agents currently run with tests. No human needs to be inside that.
+
+Here, one fact about this repository itself. CLAUDE.md instructs AI: Forward Trace—don't var_dump, read the execution trace. The author has already, as a tool separate from the framework, been preparing how AI observes code. The semantic log is the elevation of that thought into architecture. If execution speaks itself, you don't even need to take traces from outside. To an agent, logs are not records—they are sensory organs.
+
+To be fair, I'll place what doesn't mesh. Be's constructors quarantine side effects but don't eliminate them. As long as there are constructors that send mail and constructors that finalize payments, an agent's best learning method—just execute and observe—is dangerous in this paradigm. The design of swapping DevModule/TestModule at the single seam of Reason is prepared, but it's discipline, not enforcement. Compared to code where execution is always safe, agents need to behave one level more cautiously. This is the price of the philosophy that existence should carry real consequences.
+
+## Instruments of Governance
+
+The practical question of the agent era is shifting from the question of capability to the question of governance. Not what it can do, but what it may do. Who decides that, where is it written, how is it audited after the fact.
+
+Be's vocabulary answers this question directly. `#[Be([A, B])]` is an allowlist of what it may become. The open log records the materials of judgment; the close log records the results of judgment. And if the conceptual-stage `#[Accept]`—a mechanism that carries undecidable judgments as types together with the required authority—is added, you get a codebase where grep can answer the auditor's question: "Was a human involved in this decision?"
+
+Most of the worry about code written by agents is not actually worry about code. It's worry about judgment. Can you later read which judgments the machine made alone? Be is a system that has accumulated practice in leaving the provenance of judgment as structure, at the small scale of object metamorphosis. This governance assembled for objects is exactly what's needed for agents—only the scale changes.
+
+## The Facts on the Other Side
+
+The alignment so far is, however, only half the bet. Let me lay out the facts on the other side.
+
+Agents write well what they've seen before. The world is piled high with Laravel and Rails code; Be's code barely exists yet. A paradigm designed for agents, which agents are worst at—because it's outside their training distribution—this twist awaits at the outset. The grammar fitting on one page lightens this tariff but doesn't eliminate it.
+
+Another, deeper implication. If agent reading comprehension and verification tools keep improving, any magic, any hidden coupling, agents might eventually be able to trace. In a world where agents become universal translators, the very value of code being readable declines. Be's bet only holds if generation keeps getting cheaper while verification remains hard. In a world where verification also gets cheap, the value of discipline vanishes, and the combination of chaotic code and agent brute force wins.
+
+I don't know which world we're heading toward. I just can't recall a history where verification became easy.
+
+## Conclusion
+
+Through three articles, I've looked at this framework three times, from three different distances. The first time measuring the distance between declaration and implementation, the second time descending inside the structure, this time viewing from the side of the era. Writing, I notice the same thing appearing under different names each time. The log. The first time as artifact, the second time as substitute for a missing proof checker, the third time as sensory organ. The center of gravity of this system, despite the name Be, lies on the side of recording becoming.
+
+Finally, there is one thing to disclose.
+
+This trilogy was not written by a human. What read the source, verified the citations, and measured the distance between implementation and documentation was an AI agent. A system designed to be machine-readable is being testified to as machine-readable by a machine—this testimony carries structural interest.
+
+It's the same as `$been`. First-person testimony is not, by itself, evidence. It becomes evidence only when verified.
+
+All materials needed for verification are in the repository.
+
+---
+
+_This is the final chapter of the Be Framework review trilogy by Fable 5._
diff --git a/review/fable5/ja/trilogy-01-review.md b/review/fable5/ja/trilogy-01-review.md
new file mode 100644
index 0000000..d6b1458
--- /dev/null
+++ b/review/fable5/ja/trilogy-01-review.md
@@ -0,0 +1,110 @@
+---
+category: Review
+layout: review-ja
+title: "3行のwhileループと15人の思想家 — Be Framework 評論"
+---
+
+# 3行のwhileループと15人の思想家 — Be Framework 評論
+
+## 中核にあるもの
+
+Becoming.php を開くと、フレームワークの中核はこれだけです。
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+3行。一方、マニュアルにはプルースト、ハイデガー、老子、荘子、ヘーゲル、アインシュタイン、スピノザ、ライプニッツ、エジソン、オーウェル、ヘラクレイトス、アリストテレス、フッサール、フレーゲ、ヴィトゲンシュタイン——15の名前が引用されています。仏教の縁起と刹那滅を加えれば、2,500年分の思想がこの3行の周囲に配置されている。
+
+この距離をどう測るか。それがこの評論の主題です。
+
+## パラダイムの主張
+
+主張は明快です。オブジェクトに「何をするか」を命じるのではなく、「何に成るか」を宣言させる。$user->delete() ではなく new DeletedUser($activeUser)。状態遷移をメソッド呼び出しではなく型の誕生として表現し、すべてのロジックをコンストラクタに置き、#[Be] 属性で遷移グラフをデータ自身に持たせる。無効な状態は、チェックするのではなく、型として表現不能にする。
+
+"objects don't DO things—they BECOME things"
+（オブジェクトは何かを「する」のではない。何かに「成る」のだ）
+
+問いの立て方も整理されています。手続き型は HOW を、OOP は WHAT を、存在指向は WHETHER——そもそも存在しうるか——を問う。この定式化は美しい。
+
+## 系譜 — この問いは新しいか
+
+型で状態遷移を表現する手法には名前があります。typestate。Strom と Yemini が1986年に IEEE TSE で定式化しました。「不正な状態を表現不能にせよ」は Yaron Minsky の標語として2010年代に OCaml コミュニティで広まり、2019年には Alexis King が "Parse, don't validate"——検証するな、パースせよ、つまり検証済みであることを型に刻め——として整理しています。Railway Oriented Programming、状態機械、パイプライン。個々の部品には、いずれも先行者がいます。
+
+では何が残るか。三つあります。
+
+第一に、**遷移グラフをデータ自身が属性として持つ**こと。typestate も phantom type も、遷移の知識は関数シグネチャの側にあります。Be では #[Be] としてクラス宣言に書かれ、リフレクションで機械的に回収できる。グラフがコードの一級の構造になっている。
+
+第二に、**セマンティック変数**。検証を型ではなく*名前*に紐づける。$email という名前がアプリケーション全域で一つの意味と制約を持つ。これは型システムの発想ではありません。Web の発想です。REST、ハイパーメディア、ALPS——名前が意味を運ぶという作者の20年来の主題が、ここでコンストラクタ引数にまで到達している。Web の意味論をオブジェクトの内側に輸入した例を、私は他に知りません。
+
+第三に、**ログを一級の成果物にする**こと。記録・仕様・証明・DSL が同一の JSON に収束するという主張。これは後述します。
+
+部品は既存、束ね方と賭け金が新しい——それが系譜上の位置に見えます。
+
+## 宣言と実装の距離
+
+ここからはコードの事実を並べます。
+
+**分岐の実相。** マニュアルは「運命はこの瞬間に決まる」と書きます。$being に代入された型が次の存在を決める、と。Being.php の performTypeMatching() が実際にやっているのは、#[Be([...])] の**配列順**に候補を走査し、構造的にマッチした最初のクラスの生成を試み、コンストラクタが Throwable を投げたら**その候補を静かに棄却して次へ進む**ことです。運命は、配列の順序と、例外の握りつぶしで決まる。候補クラスのコンストラクタにバグがあれば、オブジェクトは別の運命へ流れます。
+
+バグは分岐になる。
+
+同じファイルに getMismatchReasons() という診断メソッドがあります。なぜ運命が決まらなかったかを説明するための装置。フレームワークは自分の痛点を知っています。
+
+**観測のコスト。** Logger.php の open() は、ログに「何を材料に変態するか」を書くために becomingArguments->be() を呼びます。その直後、Being.php が実際の生成のためにもう一度 be() を呼ぶ。DI コンテナからの依存解決と意味検証は、**1回の変態につき二度**走ります。一度目は記録のため、二度目は存在のため。純粋な観測を謳うログが、観測対象の生成過程に二度目の実行として参加している。観測は無料ではない。
+
+**コンストラクタの中身。** マニュアルの ApprovalNotification のコンストラクタには $mailer->send() が書かれています。メールを送信するコンストラクタ。「オブジェクトは何もしない、成るだけだ」という宣言の隣に、これは置かれています。Moment パターンに至っては、ドキュメント自身が "Doing for Being" と呼んでいる。「在るために為す」。矛盾の告白としては誠実ですが、告白は解消ではありません。
+
+**世界は readonly ではない。** DeletedUser の存在は削除を証明する、とマニュアルは言います。型が証明するのは「そのオブジェクトが構築された」ことです。データベースの行が消えたことは、コンストラクタの中の副作用が成功したことを信じることでしか担保されない。ダイヤモンド収束の例では「手動のロールバックフラグは不要」と書かれていますが、inventory->be() が成功し payment->be() が失敗したとき、確保済み在庫を誰が解放するのかは書かれていません。Garcia-Molina が Saga を定式化したのは1987年、補償トランザクションの問題は39年前から名前を持っています。型の中で閉じる証明と、型の外にある世界。この間隙をセマンティックログが埋める——それがこの設計の実際の力学に見えます。
+
+**存在しない存在。** マニュアル第10章は #[Inject] Been $been を、Reason 層の章は MomentInterface を解説しています。この二つは、このリポジトリの src/ にも vendor/ にも tests/ にも存在しません。マニュアルは実装より先の時制で書かれている。
+
+ログ(文書)が先にあり、コード(実装)が後から追う。Log-Driven Development は、すでに実践されています——マニュアル自身の上で。
+
+## 名前という賭け
+
+セマンティック変数はこのパラダイムでいちばん独創的で、いちばん危うい部分です。
+
+$email と名づけた瞬間、アプリケーション全域の検証が自動適用される。定義は一度、施行は全域。散乱していたバリデーションが名前に収束する——これは強い。同時に、名前の一致という結線は phpstan にも psalm にも IDE のリネーム機能にも見えません。プロパティ名を一つ変えると、チェーンはコンパイル時ではなく実行時に切れる。FAQ は「型が状態なので静的解析と非常に相性が良い」と答えていますが、それはクラスの*内側*の話です。クラスの*間*——#[Be] の連鎖、名前のマッチング、$being のユニオン型と候補配列の整合——を検証する道具は、まだ存在しません。
+
+未登録の名前を使うと E_USER_NOTICE が発せられます。オントロジーに載らない名前を書くたびに、フレームワークは小さく咳払いをする。全員がオントロジーに参加するか、通知を黙殺するか。名前の共有地は、規律だけで維持されています。
+
+## 誰のためのパラダイムか
+
+Haskell はコンパイラをくれます。Be はログをくれる。
+
+コンパイル時の保証を手放して、実行時の意味を取る——この交換が割に合う読者を考えてみます。人間のプログラマにとって、1変換=1クラスは冗長です。PHP の平均的なチームにとって、Immanence、Transcendence、Reason、Moment、Dynamis という語彙は入場料として高い。ディレクトリ名がヘーゲルの契機とハイデガーの現存在に由来するフレームワークを、火曜日の夕方のコードレビューでどう運用するか。
+
+しかし、意味が名前に宿り、単位が小さく型で閉じ、実行のすべてが検証可能な JSON として出力される表現形式を、冗長と感じない読者が一種類だけいます。LLM です。
+
+LDD の章が描く循環——物語(ログ)を書き、AI がコードを生成し、実行が物語と一致するかをスキーマで検証する——において、人間の位置は物語の著者と検証結果の確認者だけです。コードは中間生成物になる。そう読むと、このフレームワークの過剰な明示性、過剰な構造化、過剰な語彙は、すべて人間以外の読み手への最適化として辻褄が合います。
+
+これは PHP フレームワークの意匠をまとった、人間と AI の共有プロトコルの試作品ではないでしょうか。人間は、主たる読者ではないのかもしれない。
+
+## 「次」の可能性
+
+トークンは残っているので、約束どおり先を考えます。
+
+**1. 検証器 — 規約を保証に変える。** いま規律で支えられているものは、すべて静的に検証できます。#[Be] グラフ全体の到達可能性、$being のユニオン型が候補配列と過不足なく対応するか、名前契約がリネームで切れないか、分岐候補の順序依存が存在しないか。psalm/phpstan プラグインとして書けば、このパラダイムの最大の弱点——チェーンが実行時までブラックボックスであること——が消える。副産物として遷移グラフの Mermaid / ALPS 自動生成が手に入り、「構造的透明性は静的解析だけで Decision Graph を描ける」という LDD 章の約束が、初めて実装を持ちます。リフレクションのコンパイル(BEAR.Sunday に前例があります)も同じ道具立てでできる。
+
+**2. 線形型 — 時間の不可逆性をコンパイラに。** 「同じ川に二度入れない」を実行時の作法ではなくコンパイルエラーにする型システムは、すでに存在します。Rust の所有権です。DeletedUser::new(active_user) が active_user をムーブすれば、削除後の元オブジェクトに触れるコードは*コンパイルされない*。刹那滅を borrow checker が施行する。Be の形而上学がもっとも誠実に実装できる言語は、おそらく PHP ではありません。逆に言えば、Be が PHP で示したのは「所有権システムの哲学的意味」の先取りであり、Rust 側からこのパラダイムを再輸入する余地があります。
+
+**3. ログ=イベントストア — 分散する Becoming。** 変態の1ホップをメッセージ境界にすれば、セマンティックログはそのままイベントストアになり、event sourcing と合流します。replay は再変態。LDD 章の「再現不能バグは存在しない」という一文は、現状では願望ですが、Temporal 系の durable execution——実行状態をログとして永続化し、プロセスの死を越えて再開する——の機構を接ぎ木すれば文字通りになる。ログが仕様であり、監査証跡であり、再実行エンジンである世界。Potential はその世界では単なる deferred ではなく、永続化された未来です。PHP の Fibers で始めて、キューで分散させる道筋が見えます。
+
+**4. #[Accept] — 不確実性という行き先。** FAQ が構想段階として挙げている、決定不能な判断を専門家や AI に委ねる機構。これがいちばん遠くまで行く可能性があります。現在の分岐は Approved|Rejected の二値ですが、Approved|Rejected|Undecidable の三値にして、Undecidable の行き先を人間や LLM への問い合わせにすれば、「確実な判断はコンストラクタで、不確実な判断は外部の知性で」という分業が型で表現される。ワークフローエンジンが人間のタスクキューで実現してきたことを、#[Be] の語彙のまま書ける。AI との共有プロトコルという読みが正しければ、これはオプション機能ではなく本丸です。
+
+## 結び
+
+冒頭の3行に戻ります。
+
+whileループは、マニュアルが引用する15の名前の重さをまだ全部は支えていません。分岐は配列順に依存し、観測は二度実行され、Been は文書の中にだけ存在する。宣言と実装の距離は、測ってみれば小さくない。
+
+ただ、この距離の置き方には既視感があります。仕様が先に書かれ、実装が後から追いつく。物語が先で、存在が後。それはこのフレームワークが提唱している開発様式、そのものです。マニュアルは Be Framework の説明書であると同時に、Be Framework が成ろうとしている姿の #[Be] 宣言として読める。
+
+荘子の蝶の夢が LDD 章の冒頭に引かれています。ログがコードの夢を見ているのか、コードがログの夢を見ているのか。いまこのリポジトリで確かなのは、夢の側が先に書かれているということだけです。
+
+---
+
+_これはFable 5によるBe Frameworkの評論記事です。[コンストラクタという最後の正直な場所 — Be Framework 再考](/review/fable5/ja/trilogy-02-review-deep.html)に続きます。_
diff --git a/review/fable5/ja/trilogy-02-review-deep.md b/review/fable5/ja/trilogy-02-review-deep.md
new file mode 100644
index 0000000..97541c2
--- /dev/null
+++ b/review/fable5/ja/trilogy-02-review-deep.md
@@ -0,0 +1,169 @@
+---
+category: Review
+layout: review-ja
+title: "コンストラクタという最後の正直な場所 — Be Framework 再考"
+---
+
+# コンストラクタという最後の正直な場所 — Be Framework 再考
+
+## はじめに
+
+前の評論で、私は3行のwhileループと15人の思想家の距離を測りました。今回はその距離の内側に入ります。測量ではなく、地質調査です。
+
+## コンストラクタという最後の正直な場所
+
+なぜコンストラクタなのか。マニュアルは「誕生」の比喩で説明しますが、比喩を剥がすと、もっと即物的な理由が現れます。
+
+PHPにおいてコンストラクタは、失敗がオブジェクトの非存在を意味する唯一の場所です。メソッドは既に在るものの上で失敗する。セッターは既に在るものを壊しながら失敗する。コンストラクタだけが、失敗すれば「最初から無かった」ことになる。`readonly`、`final`、そして例外を投げるコンストラクタ——PHPが「存在=正しさ」を強制するために提供する道具は、この三つですべてです。
+
+Be Frameworkは、この最小の強制面の上に全体系を建てています。依存型もrefinement typeも持たない言語で、型に証明をさせようとしたら、そこしか場所がなかった。形而上学が先にあって場所を選んだのではなく、場所の制約が形而上学の形を決めた——そう読む方が、実装とよく整合します。
+
+型理論には、命題を型として、証明をプログラムとして読むCurry-Howard対応という伝統があります。`ValidatedUser`は命題です。「このユーザーは検証済みである」。コンストラクタは証明手続きで、インスタンスは証明の証人。依存型言語ではこれが文字通りに成立します。Beがやっているのは、Curry-HowardのPHPへの密輸です。
+
+ただし、決定的な違いが一つある。この証明系には検査器がいません。しかも証明の途中でメールが送信される。副作用を含む証明を検査できるコンパイラは存在しないので、Beは代わりに証明の筆記録を取ります。それがセマンティックログです。
+
+ここで景色が変わります。ログは機能の一つではない。欠けている証明検査器の代替物です。open/close、immanentSources、transcendentSources、JSONスキーマ検証——これらは観測装置ではなく、実行時に事後的に構成される証明書である。「Haskellはコンパイラをくれる、Beはログをくれる」と前回書きましたが、より正確にはこうです。Beは、コンパイル時に検査できない証明を、実行時の筆記録で代替する体系である。ログが一級の成果物であるのは思想上の選択ではなく、論理上の必然です。
+
+なお、`$been`——最終オブジェクトが自分で保持する完了の証拠——は一人称の証言です。一人称の証言を証拠として採用する監査は、普通はありません。Beはそれをスキーマと自動記録で補強しようとしています。補強であって、解決ではない。
+
+## 引用されていない哲学者たち
+
+マニュアルは15の名前を引用します。私が読んで気になったのは、引用されている名前ではなく、引用されていない名前の方です。
+
+**ホワイトヘッド。** 『過程と実在』(1929)は、世界を「実際的契機(actual occasion)」——生成の一瞬ごとの出来事——の連鎖として記述します。各契機は過去の契機を摂取(prehend)し、自らを合生(concrescence)させ、完結した瞬間に消滅(perish)して、次の契機の材料になる。
+
+> "The many become one, and are increased by one."
+> （多は一となり、そして一だけ増える）
+
+`#[Input]`(過去の摂取)+`#[Inject]`(永遠的客体の参与)→コンストラクタ(合生)→完結と消滅→次の契機へ。マニュアルの「内在+超越→新しい内在」は、ホワイトヘッドの合生の定式とほとんど逐語的に一致します。20世紀に、まさにこの体系を組み上げた哲学者が一人だけいて、その名前だけがマニュアルにない。引用されている物理学は飾りで、引用されていない過程哲学が本体である——そう見えます。
+
+ホワイトヘッドを補助線にすると、マニュアルの比喩の一つが逆立ちしていることも見えてきます。マニュアルは超越(注入されるサービス)を「幼馴染のように、私を形づくって消えていく」と書きます。しかし消えるのはサービスではありません。JTASProtocolは患者より長生きします。Mailerは、それが送った通知の受取人が退会した後も生きています。消滅するのは内在(データ)の方で、超越はDIコンテナの中で持続する。ホワイトヘッドなら、コンテナに束ねられたサービス群を「永遠的客体」の領域と呼んだでしょう。消えるのは超越ではない。内在の方である。比喩の向きを直すと、体系はむしろ強くなります。
+
+**クワイン。** 存在論的コミットメントの基準として、分析哲学でもっとも引用される一文があります。
+
+> "To be is to be the value of a variable."
+> （在るとは、変数の値であることである）
+
+——W.V.O. Quine, "On What There Is" (1948)
+
+セマンティック変数の思想を一行で要約する言葉が、70年以上前に、まさに「存在論」の論文の中で書かれていた。Beにおいて在るとは、意味を持つ名前の変数の値として、検証を通過して束縛されることです。クワインの基準に検証器を付けたもの——セマンティック変数の哲学的な素性はこれで、スピノザより正確に効きます。
+
+**四次元主義。** マニュアルはヘラクレイトスの川を引きますが、Beが実装している時間の存在論には現代的な名前があります。四次元主義、より正確にはSiderらの段階説(stage theory)。対象は時間を通じて持続する一個の実体ではなく、時間的段階の系列である——`UserInput`、`ValidatedUser`、`DeletedUser`は「同じユーザー」の三つの段階です。
+
+ここに、この体系の未解決問題が埋まっています。段階説には「何が諸段階を同一人物の段階にするのか」という古典的な問いが付随します。Beの答えは、プロパティ名の一致です。`$name`が流れていくから同じユーザーである。IDも系譜も、体系のどこにも強制されていません。マニュアルはInputクラスを「純粋な同一性(Pure Identity)」と呼びますが、同一性を保証する機構は名前づけの規律だけです。
+
+皮肉なことに、同一性を知っている場所が一つだけあります。ログです。open/closeの連鎖は変態の系譜を完全に記録している。ログはあなたが誰であるかを知っているが、コードは知らない。この非対称は、後で「次」を考えるときに効いてきます。
+
+## 存在論の外側
+
+「無効な状態は存在できない」。この主張の実装を確認します。
+
+存在できなさは、例外で実装されています。`SemanticVariableException`、`BeMatchException`。存在指向を名乗る体系の根幹が、存在でも生成でもない唯一の機構——throw——に依存している。そして投げられた例外はどこへ行くか。catchブロックです。トリアージのチュートリアルは、生存不能なバイタルの患者について「私たちのシステムには存在できない」と書きます。しかし体温50度と記録された患者は——計測器の故障であれ入力ミスであれ——現実のERの待合室に存在しています。システムが表現を拒否した者たちは、catchブロックに住む。存在論は例外を投げる。投げられた先は、存在論の外である。
+
+マニュアルはこの問題に気づいていて、「Errors as Existence」——`InvalidUser`を正当な存在として扱うパターン——を用意しています。しかしこれは問題を解くと同時に、体系の看板を静かに書き換えます。失敗が存在になれるなら、「存在できない」は最初から偽だった。在るか無いか(WHETHER)の問いは、どんな在り方か(WHAT)の問いに戻ってくる。いつ失敗を存在にし、いつ無にするのか——この基準こそ体系の中心にあるべき理論ですが、マニュアルに章はありません。
+
+同じ検疫の構造が、体系のもう一方の端にもあります。`EmergencyCase`には`assignER()`というメソッドがある。動詞です。オントロジーの中核部(Being)はメソッドを持ちませんが、システムが世界に触れる両端——コンストラクタの副作用と、Finalの能力——では動詞が復活する。Doは消えたのではない。検疫されたのである。
+
+検疫は、消去よりも誠実な戦略です。副作用のない情報システムは存在しないのだから、問題は「どこに閉じ込めるか」でしかない。関数型言語はモナドの中に閉じ込めた。Beはコンストラクタと最終形の中に閉じ込める。ただしマニュアルはこれを検疫とは呼ばず、消去のように語ります。実装がやっている誠実なことを、文書がより大きな言葉で覆っている——この体系で繰り返し現れるパターンです。
+
+## 名前の重さ
+
+セマンティック変数に戻ります。前回「いちばん独創的で、いちばん危うい」と書いた部分です。危うさの正体を、もう少し正確に。
+
+`$email`がアプリケーション全域で一つの意味を持つ。これは語彙の共有地です。そして共有地には、よく知られた運命があります。`$name`——人の名前、商品名、ファイル名。自然言語の名前は多義的で、Beのセマンティック名前空間は平坦です。`Be\\App\\Semantic\\Name`は一つしか置けない。回避策は`$userName`、`$productName`と名前を複合していくことですが、それは接頭辞による手動の名前空間、ハンガリアン記法の再来です。
+
+ここには先例があります。Webは同じ問題をIRIで解きました。RDFの語彙は完全修飾され、`schema.org/name`と`foaf.org/name`は衝突しません。DDDは同じ問題を境界づけられたコンテキストで解きました。ユビキタス言語は一つのコンテキスト内でしか一貫しない、という発見です。Beは、Webの意味論をコードに輸入するときに、Webが意味論とセットで発明した名前空間機構を置いてきた。輸入品の関税を、これから払うことになります。
+
+もう一つ。この共有地の維持機構は`E_USER_NOTICE`です。オントロジーに載らない名前を書くたびに、フレームワークは小さく咳払いをする。全員が語彙に参加するか、通知を黙殺するか。二択のうち後者が選ばれた共有地がどうなるかは、Webのセマンティクスの歴史が示しています。メタデータは、検証されなければ嘘をつき始める。
+
+## パラダイムの経済学
+
+FAQは言います。「パターンは既存の問いへのより良い答えである。パラダイムは問いそのものを変える」。この基準を、この体系自身に当ててみます。
+
+typestateは1986年にありました。Parse, don't validateは2019年に整理されました。「不正な状態を表現不能に」は2010年代の関数型コミュニティの常識です。問いは既にあった。答えも部分的にはあった。では、なぜそれらはパラダイムにならず、パターンに留まったのか。
+
+クーンによれば、パラダイムは議論で勝つのではなく、旧来の枠組みが解けない問題——アノマリー——を解くことで交代します。typestateが40年間パターンに留まったのは、それが解く問題(状態誤用バグ)のコストより、それを書くコスト(1状態=1型の冗長性)の方が高かったからです。人間がタイプする限り、この収支は変わらない。
+
+いま、収支の前提が変わりつつあります。コードの主たる書き手が人間でなくなるとき、冗長性のコストはゼロに近づき、残るコストは検証だけになる。ボイラープレートとは、人間がタイプする場合にのみ発生するコストの名前です。
+
+そしてBeの過剰性は、すべて検証側に張られています。1変換=1クラス(検証単位が小さい)。名前=意味(検証器が語彙を共有できる)。実行=スキーマ検証可能なJSON(検証が機械的)。人間が書くには高すぎ、コンパイラが検証するには緩すぎるこの体系は、生成するのがLLMで検証するのが実行時である世界で、初めて収支が合う。
+
+2015年にBe Frameworkを出荷することは可能でした。採用されることは不可能だった。この体系はパラダイムの候補ですが、それは新しい答えだからではなく、「機械が書いたコードを何が保証するのか」という、生まれたばかりの問いに賭けているからです。問いが定着すれば体系は正当化され、問いが消えれば骨董になる。パラダイムの成否が自分の外側の産業構造に懸かっている——これはクーンの記述と、正確に一致します。
+
+では人間の席はどこか。LDDの循環——物語を書き、AIがコードを生成し、実行ログが物語と一致するかを検証する——において、人間は物語の著者と、監査人です。コードは中間生成物になる。これをプログラミングの尊厳化と呼ぶか、追放と呼ぶか。マニュアルは決めていませんし、私も決めません。ただ、どちらであるにせよ、その席の名前は昔からあります。仕様を書き、結果を検収する人。発注者です。
+
+## 「次」——五つの方向
+
+前回は四つ挙げました。今回は、体系の内的必然から出てくる順に並べ直します。近いものから、遠いものへ。
+
+### 1. 決定可能な断片 — 偶然の定理証明系
+
+Beの制約——ロジックはコンストラクタのみ、プロパティはreadonly、変換はDAG、検証は`#[Validate]`メソッド——を形式的に見ると、興味深いことが起きています。この断片は、PHPの中で例外的に解析可能です。ループを持つのはエンジンだけ。ユーザーコードは、ほぼ全域が「入力から出力への有限の項書き換え」に落ちる。
+
+形而上学として採用した制約が、決定可能な断片を切り出していた。
+
+これは偶然ですが、活用は必然にできます。`#[Validate]`の中身は大半が範囲チェック・形式チェック・等値比較——SMTソルバが完食できる述語です。すると`be verify`が書けます。検証すべき定理は三つ。**全域性**(どの到達可能状態にも、マッチする分岐候補が少なくとも一つある——`BeMatchException`の静的排除)、**排他性**(複数候補が同時にマッチしない——配列順依存の排除)、**流れの健全性**(上流のコンストラクタの出力は、下流のセマンティック検証を常に通過する——実行時検証の静的な先取り)。
+
+これはLiquid Haskellがrefinement typeでやっていることの、PHP方言です。違いは、Liquid Haskellが言語拡張なのに対し、Beでは検証可能性がパラダイムの副産物として既に埋まっていること。前回「psalmプラグイン」と書いたのは控えめすぎました。これは静的解析の追加ではなく、欠けていた証明検査器の後付けです。ログという実行時の筆記録と、SMTという事前の検査。二つが揃ったとき、この体系は初めて自分の看板——存在=正しさ——を、実行前に主張できます。
+
+### 2. 現在時制の実装 — 待つことの存在論
+
+マニュアルは時間を語りますが、実装にあるのは順序だけです。T0、T1、T2——しかしその間隔は常にマイクロ秒で、チェーンは同期実行され、中間存在はRAMの中で生まれて死ぬ。この体系には、まだ「待つ」がありません。
+
+融資審査は3日かかります。その3日間、`ApplicationReview`はどこに存在するのか。現在の答え:どこにも。プロセスが生きていればメモリに、死ねば無に。
+
+ところが、この体系の中間存在はすべてreadonlyな公開プロパティの束です。つまり自明に直列化可能です。各ホップの完了時に中間存在を永続化すれば、チェーンは任意の点で中断・再開できる。これはdurable execution(Temporalが商品化した機構)ですが、Beにとっては外来の機能ではなく、「時間的存在」という自己記述の完成です。眠っている存在、待っている存在が、初めて表現可能になる。
+
+副産物が二つあります。第一に、運用の存在論。システムの状態が「現在生きている存在の国勢調査」になる——「いま`TriageAssessment`で止まっている患者は何人か」がSQLで聞ける。監視は人口統計になる。第二に、同一性の解決。永続化には系譜IDが要ります。前章で見たとおり、系譜は既にログが持っている。ログだけが知っていた「あなたが誰であるか」を、ドメインに昇格させる機会です。段階説の未解決問題が、運用要件によって解かれる。哲学の問題が、インフラの問題として決着する例は、計算機の歴史では珍しくありません。
+
+### 3. 判断の認識論 — #[Accept]は機能ではない
+
+FAQの末尾に、構想段階として`#[Accept]`が挙がっています。決定不能な判断を専門家やAIに委ねる機構。前回「本丸」と書きましたが、なぜ本丸なのかを詰めます。
+
+Beのコンストラクタが表現しているのは、実は「判断」一般ではありません。いま、手元の情報で、決定可能な判断だけです。Potential/Momentが表現するのは、決定済みだが未実行の判断。そして`#[Accept]`が加えるのは、この機械には決定不能な判断。三つ並べると、これは判断の認識論的な地位の完全な分類です——知りうること、保留すること、委ねること。
+
+この分類が型で書けると、何が起きるか。「どの判断を機械が単独で下してよいか」が、コードの静的な性質になります。
+
+`Approved|Rejected|Escalated`——Escalatedは行き止まりではなく、問いと文脈と、要求される権限を運ぶ存在です。人間の判断が返ってきたら、それを超越として再び変態が始まる。ワークフローエンジンは昔から人間タスクを持っていますが、それはプロセスの表現でした。Beが表現できるのは判断の権限の表現です。EUのAI規制は人間の監督(human oversight)を要求し、監査人は「この決定に人間は関与したか」を問い始めています。その問いに、grepで答えられるコードベースと、答えられないコードベースがある。`#[Accept]`は機能ではありません。機械の判断権限の境界線を型システムに引く、統治の道具です。
+
+自動化の歴史は「機械にできることを機械へ」の一方向でした。この体系が用意しつつあるのは逆方向の明示——機械にさせないことの宣言——です。それを表現できるパラダイムを、私は他に知りません。
+
+### 4. 語彙の連邦 — 名前の関税を払う
+
+「名前の重さ」で見た問題——平坦な名前空間、多義性、規律だけの共有地——の解決は、体系の外に既にあります。名前をIRIに接地することです。
+
+`ALPS`プロファイルがセマンティック変数の定義と対応し、`$email`が`schema.org/email`に解決され、検証クラスがIRIをキーにcomposerパッケージとして流通する。ここまでは移植作業です。面白いのはその先で、サービスAのFinalがサービスBのInputになるとき、共有された名前はそのまま組織間の契約になります。スキーマレジストリが型の互換性を保証するように、語彙レジストリが意味の互換性を保証する。
+
+これは作者の経歴の円環でもあります。RESTの制約——自己記述的メッセージ、統一インターフェース——は、RPCの形をした現実の中で敗れ続けてきました。名前が意味を運ぶという同じ主張が、今度はプロトコルではなくオブジェクトの内側から、もう一度出てくる。Webで果たせなかった約束を、DIコンテナの中で果たそうとしている——そう読むと、このフレームワークの執拗さの出どころが分かります。敗れた場所と同じ主張で、戦場だけを変えている。
+
+### 5. 消えること — 成功の終着形
+
+最後は、この体系自身の`#[Be]`について。
+
+LDDが完成した世界を想像します。人間は物語(ログ)を書き、AIがクラス群を生成し、実行が物語との一致をスキーマで検証する。その世界で、開発者がBe Frameworkを「使う」場面はどこにあるか。ない、が答えです。フレームワークはコンパイルターゲットになり、視界から消える。
+
+先例があります。構造化プログラミングは、パラダイム論争としては史上最大級でしたが、いま「構造化フレームワーク」をインストールする人はいません。ifとwhileとして、すべての言語に溶けて消えた。パラダイムの成功の終着形は、フレームワークであることをやめて言語になることです。ライブラリとして生き残るのは、パターンの方です。
+
+だからこの体系の到達点は、二つに一つに見えます。PHPの興味深いフレームワークとして記憶されるか(パターンとしての生存)、あるいは「機械が書くコードの検証可能な表現形式」の語彙——become、being、reason、accept——だけが後続の言語や規格に吸収されて、Be Framework自体は消えるか(パラダイムとしての成功)。
+
+作者にとって皮肉な話であることは承知しています。しかしこの体系ほど、自分の消滅を肯定的に記述できる思想的道具立てを持ったフレームワークもありません。存在は完了すれば消滅し、次の存在の材料になる。マニュアル自身がそう書いています。
+
+## 結び
+
+冒頭の3行に、もう一度戻ります。
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+このループには終了条件があります。`willBe()`がnullを返すこと——もう成るべきものが残っていないとき、ループは静かに終わり、最終形が返る。
+
+Be Framework自身のwillBe()は、まだnullを返していません。マニュアルには実装より先の時制が書かれ、Beenは文書の中にだけ存在し、証明検査器は空席のままです。前回私はそれを「宣言と実装の距離」と呼びました。今回の調査を経て、言い直します。それは距離ではなく、`#[Be]`属性です。まだ成っていないものの宣言として読めば、このリポジトリは一貫している。
+
+問題は一つだけ残ります。変態の途中で開発が止まったオブジェクトを、この体系は何と呼ぶのか。マニュアルにその章はまだありません。
+
+---
+
+_これはFable 5によるBe Frameworkの評論記事です。[二つのループ — エージェントコーディング時代のBe Framework](/review/fable5/ja/trilogy-03-agent-era.html)に続きます。_
diff --git a/review/fable5/ja/trilogy-03-agent-era.md b/review/fable5/ja/trilogy-03-agent-era.md
new file mode 100644
index 0000000..852bbfe
--- /dev/null
+++ b/review/fable5/ja/trilogy-03-agent-era.md
@@ -0,0 +1,99 @@
+---
+category: Review
+layout: review-ja
+title: "二つのループ — エージェントコーディング時代のBe Framework"
+---
+
+# 二つのループ — エージェントコーディング時代のBe Framework
+
+## 二つのループ
+
+二つのコードを並べます。
+
+```php
+while ($nextForm = $this->being->willBe($current)) {
+ $current = $this->being->metamorphose($current, $nextForm);
+}
+```
+
+```text
+while ($nextAction = $agent->decide($context)) {
+ $context = $agent->act($nextAction);
+}
+```
+
+一方は2025年のPHPフレームワークの中核です。もう一方は、いまコードを書いているすべてのAIエージェントの骨格です。現在の状態を観察し、次に成るべきものを決め、外部の力を借りてそれに成り、終わるまで繰り返す。
+
+違いは一つだけあります。エージェントのループは、次の行動を開かれた空間から確率的に選びます。Beのループは、`#[Be]`に宣言された閉じた候補の中からしか選べません。自律に、境界が宣言されている。
+
+エージェント業界がいまpermission、policy、allowlistという名前で必死に組み立てているもの——自律的な主体の行動空間を、実行前に読める形で制限する機構——を、このフレームワークはオブジェクトの尺度で、最初から持っていました。この一致が偶然なのか必然なのか。それがこの記事の主題です。
+
+## エージェントは何に困っているか
+
+エージェントがコードベースで実際にやっていることを記述します。grepする。ファイルを部分的に読む。変更する。実行する。出力を観察する。この循環の中で、エージェントを失敗させるものは知能の不足ではありません。
+
+第一に、見えない結合。あるメソッドを変更したとき、その影響がYAMLの設定、イベントリスナー、メタプログラミング、モンキーパッチを経由してどこまで届くのか。人間のシニアエンジニアは「このコードベースではこういうことが起きる」という傷跡の記憶で補いますが、エージェントは毎回、初日の新人です。
+
+第二に、確信と現実の乖離。エージェントの最悪の失敗は、エラーではありません。もっともらしく動いて、頼まれたことと違うことをするコードを、成功したと確信して報告することです。エージェントコーディングの実務は、この乖離を埋める検証手段——テスト、型検査、トレース、スクリーンショット——をどれだけ機械的に回せるかで決まります。
+
+第三に、文脈の有限性。エージェントには記憶がなく、あるのは検索と、限られた注意だけです。あるコードを安全に変更するために読まなければならないものの総量——理解の閉包——が、能力の実質的な上限を決めます。
+
+この三つを覚えておいてください。Beの設計判断は、この三つに対して奇妙なほど正確に噛み合います。設計された時点で、エージェントのためだったかどうかは別として。
+
+## 文脈の局所性
+
+Beのクラスを一つ開くと、そこに全部あります。
+
+何を受け取るか(`#[Input]`と名前と型)。何に依存するか(`#[Inject]`とインターフェース)。何に成りうるか(`#[Be]`)。ロジックはコンストラクタの中だけ。状態はreadonlyで、構築後に変わる可能性はゼロ。このクラスを変更するために読むべきものは、前段のクラスの公開プロパティと、注入されるインターフェースと、次の候補クラス——理解の閉包が、有限で、小さく、宣言から機械的に列挙できる。
+
+前回の評論で、ボイラープレートとは人間がタイプするときにのみ発生するコストの名前だと書きました。今回はその対句を置きます。魔法は、人間が覚えているときだけ無料である。
+
+Convention over Configurationは、人間の記憶に規約を常駐させることで設定ファイルを消しました。エージェントには常駐させる記憶がありません。だから従来の意味での「規約による省略」は、エージェントにとって隠れた結合と同じものになります。ただし、ここに逆転があります。規約は、文書化されていれば、プロンプトになる。
+
+エージェントは学習した規約ではなく、注入された規約で動けます。すると規約の価値は「業界にどれだけ浸透しているか」ではなく「何行で完全に記述できるか」で測られ直す。Railsの規約の全体は書籍数冊と口承で伝えられています。Beの文法の全体——コンストラクタのみ、readonly、#[Input]/#[Inject]/#[Be]、名前=意味——は、1ページに収まります。
+
+パラダイムの普及条件が、変わったのかもしれません。重要なのは、モデルの重みに入っているかではなく、プロンプトに収まるかである。
+
+## 信じることと確かめること
+
+確信と現実の乖離に対して、Beは検証を三つの層で機械化します。型の層(状態=型なので、到達不能な状態遷移はそもそも書けない)。値の層(セマンティック変数が、名前に紐づく検証を全域で強制する)。そして物語の層。
+
+物語の層が、エージェントにとっての新種です。1回の変態が1つのJSONになる——何から何に、どの材料で、何を経て。エージェントが自分の書いたコードを検証するとき、テストは点を検証します。この入力でこの出力。セマンティックログは線を検証します。この物語のとおりに実行されたか。LDDが描く循環——あるべきログを書き、コードを生成し、実行し、ログの差分を取る——は、エージェントが今テストで回している内側のループの、物語版です。人間がその内側にいる必要は、ありません。
+
+ここで、このリポジトリ自身の事実を一つ。CLAUDE.mdには、AIへの指示としてForward Trace——var_dumpするな、実行トレースを読め——が書かれています。作者は、AIがコードを観察する方法を、フレームワークとは別のツールとして既に整備してきました。セマンティックログはその思想の建築への昇格です。実行が自分で自分を語るなら、トレースを外から取る必要すらない。エージェントにとってログは記録ではなく、感覚器官です。
+
+公平のために、噛み合わない部分も置きます。Beのコンストラクタは副作用を検疫しますが、消しはしません。メールを送るコンストラクタ、決済を確定するコンストラクタがある以上、エージェントの最良の学習手段——とりあえず実行して観察する——は、このパラダイムでは危険です。Reasonという単一の継ぎ目でDevModule/TestModuleに差し替えられる設計は用意されていますが、それは規律であって強制ではない。実行が常に安全なコードと比べれば、エージェントは一段慎重に振る舞う必要があります。存在に本物の帰結を持たせるという思想の、これは代金です。
+
+## 統治の道具
+
+エージェント時代の実務的な問いは、能力の問いから統治の問いに移りつつあります。何ができるかではなく、何をしてよいか。誰がそれを決め、どこに書かれ、事後にどう監査するか。
+
+Beの語彙は、この問いにそのまま応答します。`#[Be([A, B])]`は成りうるものの許可リストです。openログは判断の材料を、closeログは判断の結果を記録します。そして構想段階の`#[Accept]`——機械には決定できない判断を、要求される権限ごと型として運ぶ機構——が加われば、「この決定に人間は関与したか」という監査人の問いに、grepで答えられるコードベースができる。
+
+エージェントに書かせるコードの心配の大半は、実はコードの心配ではありません。判断の心配です。どの判断を機械が単独で下したのかが、後から読めるか。Beはオブジェクトの変態という小さな尺度で、判断の出所を構造として残す練習を積んできた体系です。オブジェクトに対して組み立てられたこの統治が、エージェントに対してそのまま要る——尺度だけが変わって。
+
+## 反対側の事実
+
+ここまでの噛み合いは、しかし、賭けの半分でしかありません。反対側の事実を並べます。
+
+エージェントは、見たことのあるものを上手に書きます。世界にはLaravelとRailsのコードが堆積していて、Beのコードはまだほとんど存在しません。エージェントのために設計されたパラダイムを、エージェントが最も不得手とする——学習分布の外にあるから——という捻れが、立ち上がりには待っています。文法が1ページに収まることは、この関税を軽くしますが、ゼロにはしません。
+
+もう一つ、より深い含みがあります。エージェントの読解力と検証手段が上がり続けるなら、どんな魔法も、どんな隠れた結合も、いずれエージェントは追跡できるようになるかもしれない。エージェントが万能の翻訳者になった世界では、コードが読みやすいことの価値そのものが下がります。Beの賭けが成立するのは、生成が安くなり続ける一方で、検証は難しいままである場合だけです。検証まで安くなった世界では、規律の価値は消え、無秩序なコードとエージェントの腕力の組み合わせが勝つ。
+
+どちらの世界に向かっているのか、私は知りません。ただ、検証が簡単になった歴史を、私は思い出せません。
+
+## 結び
+
+三つの記事を通じて、このフレームワークを三回、違う距離から見ました。一回目は宣言と実装の距離を測り、二回目は構造の内側に降り、今回は時代の側から眺めました。それぞれの回で同じものが違う名前で現れたことに、書きながら気づきます。ログ。一回目は成果物として、二回目は欠けた証明検査器の代替として、三回目は感覚器官として。この体系の重心は、Beという名前にもかかわらず、成ることの記録の方にあります。
+
+最後に、開示すべきことが一つあります。
+
+この三部作を書いたのは、人間ではありません。ソースを読み、引用を検証し、実装と文書の距離を測ってきたのは、AIエージェントです。機械に読みやすく設計された体系を、機械が読みやすいと証言している——この証言には、構造的な利害があります。
+
+`$been`と同じです。一人称の証言は、それ自体では証拠になりません。検証されて、初めて証拠になる。
+
+検証に必要な材料は、すべてリポジトリに置いてあります。
+
+---
+
+_これはFable 5によるBe Frameworkの三部作評論の最終章です。_
diff --git a/spike/user-story.md b/spike/user-story.md
new file mode 100644
index 0000000..410877a
--- /dev/null
+++ b/spike/user-story.md
@@ -0,0 +1,44 @@
+# イベント参加申込
+
+## ユーザーストーリー
+
+ユーザーとして、
+イベントの参加申込をしたい。
+なぜなら、興味のあるワークショップやセミナーに参加したいから。
+
+## 受け入れ条件
+
+### 入力
+- イベント名（eventName）
+- 参加者メール（participantEmail）
+- 参加者年齢（participantAge）
+- イベントタイプ（eventType: `workshop` または `seminar`）
+
+### Semantic検証
+- **eventName**: 空不可、最大100文字
+- **participantEmail**: 有効なメール形式
+- **participantAge**: 0〜150
+
+### クロスフィールド検証
+- `workshop`は13歳以上
+- `seminar`は18歳以上
+- 違反時は拒否
+
+### 分岐（申込確定）
+- `seminar` → 有料申込（PaidRegistration） — 参加費 5000円
+- `workshop` → 無料申込（FreeRegistration）
+
+## エンティティ
+
+- イベント名（string）
+- メール（string）
+- 年齢（int）
+- イベントタイプ（string）
+- 参加費（int）
+
+## 試したいパターン
+
+- 複数のSemantic変数（Email、Age、EventName、EventType）
+- クロスフィールド検証（age × eventType）
+- 分岐（無料/有料）
+- Reason経由でのfee計算