Rewrite FAQ paradigm answer and improve clarity

manuals/1.0/en/14-faq.md

@@ -11,9 +11,11 @@ permalink: /manuals/1.0/en/faq.html
 
 ### Q. Is this a new "programming paradigm"?
 
-A. Yes. Be Framework makes temporal existence first-class citizens and designs based on "what something is" rather than "what it does."
+A. A pattern is a better answer to an existing question. A paradigm changes the question itself.
 
-While it's a significant paradigm shift philosophically, implementation-wise it coexists with OOP/FP/DDD and doesn't require replacing existing styles.
+`$email` is not validated externally — its very existence is proof of correctness. Semantic variables, self-determination, self-proof, choreography — these are not individual features but all derived from a single viewpoint: "seeing the world from the domain's own self."
+
+Procedural programming asked **HOW** (how to do it). Object-oriented programming asked **WHAT** (what is it). Being-oriented programming asks **WHETHER** (can it even exist).
 
 ---
 
@@ -25,19 +27,17 @@ A. They operate at different layers and can coexist.
 
 Web MVC effectively functions as input/output responsibility separation, and DDD is a domain modeling methodology. Be Framework is a design paradigm that organizes object creation through "existence conditions and temporal transformation" — it can be called from an MVC Controller or used inside a DDD aggregate.
 
-Interestingly, what MVC originally aimed for — "projecting mental models" — and what DDD aimed for — "coding in business language" — are naturally realized in Be Framework through existence types and semantic variables.
-
 ### Q1-a. How does this relate to CQRS?
 
-A. The separation of "decision-making" and "data retrieval" that CQRS achieves through external structure is naturally inherent within a single existence type in Be.
+A. CQRS is an architecture that separates "operations that change data (Command)" from "operations that read data (Query)." In Be, this separation is naturally inherent within a single existence type.
 
 The constructor is decision-making (Command), and public properties are data retrieval (Query). Business decisions that tend to get buried in generic methods like `updateUser()` are expressed as type names like `DeactivatedUser`, so intent is never lost from the code.
 
 ### Q2. Is this OOP or FP?
 
-A. It incorporates elements of both, but the relationship with OOP is more fundamental.
+A. OOP elements are central, but FP elements are also incorporated.
 
-OOP originally envisioned a world where autonomous objects cooperate through messages. In practice, however, service layers issue instructions while objects become obedient data containers. In Be, objects declare their own destiny through `#[Be]` and self-organize without external orchestrators. This is a recovery of the autonomy that OOP originally intended.
+In Be, objects declare their own destiny through `#[Be]` and self-organize without external orchestrators.
 
 ### Q2-a. How are FP elements utilized?
 
@@ -151,7 +151,7 @@ See [Final Objects](./04-final-objects.html) for details.
 
 A. Inside the constructor, delegated to Reason and completed there.
 
-Traditional service layers operate on objects from the outside — "save this," "notify that." In Be, the object itself completes side effects in its constructor. This is the autonomy described in [Q2](#q2-is-this-oop-or-fp) in action — no external orchestrator needed.
+Traditional service layers operate on objects from the outside — "save this," "notify that." In Be, the object itself completes side effects in its constructor. No external orchestrator needed.
 
 ### Q12. How are exceptions handled?
 
@@ -179,13 +179,11 @@ See [Implementation Guidelines](./05-metamorphosis.html) for details.
 
 ### Q15. Can this be introduced to existing MVC apps?
 
-A. Yes. Replace the Use Case layer with Be, and just call `becoming(new …Input)` from Controllers. Gradually organize into immanent/transcendent.
+A. Yes. Replace the Use Case layer with Be and call `becoming(new …Input)` from Controllers. Gradual migration is possible.
 
 ### Q16. Where do you use DB or external APIs?
 
-A. Confined to Reason.
-
-Persistence and external communication are implementation details, not user concerns. By consolidating them in Reason, existence types are freed from database schemas and API constraints — the definition of existence is separated from technical means.
+A. Confined to Reason. Existence types are freed from database schemas and API constraints — the definition of existence is separated from technical means.
 
 ### Q17. What are the framework dependencies?
 
@@ -249,6 +247,9 @@ final readonly class UserInput {
 
 // 2) Being (moment of transformation)
 final readonly class ValidatedUser {
+    public string $display;
+    public bool $isValid;
+
     public function __construct(
         #[Input] string $name,
         #[Input] string $email,
@@ -258,8 +259,6 @@ final readonly class ValidatedUser {
         $this->display = $fmt->format($name);
         $this->isValid = $v->validate($email);
     }
-    public string $display;
-    public bool $isValid;
 }
 
 // 3) Execution (self-organization)

manuals/1.0/ja/14-faq.md

@@ -11,9 +11,11 @@ permalink: /manuals/1.0/ja/faq.html
 
 ### Q. これは新しい"プログラミングパラダイム"ですか？
 
-A. はい。Be Frameworkは、 時間的存在を第一級市民（first-class citizen）に据え、「何をするか」ではなく「何であるか」に基づいて設計します。
+A. パターンは既存の問いに対するより良い答えです。パラダイムは問いそのものを変えます。
 
-思想面では大きなパラダイム転換ですが、実装面ではOOP/FP/DDDと共存可能で、既存スタイルを置き換える必要はありません。
+`$email`は外部から検証されるのではなく、存在していること自体が正しさの証明です。意味変数も、自己決定も、自己証明も、コレオグラフィーも——個別の機能ではなく、「ドメインの自我を中心に世界を見る」という一つの視点からすべてが導出されます。
+
+手続き型は **HOW**（どうやるか）を問い、オブジェクト指向は **WHAT**（それは何か）を問いました。存在指向は **WHETHER**（そもそも存在できるか）を問います。
 
 ---
 
@@ -25,19 +27,17 @@ A. レイヤーが異なり、共存できます。
 
 Web MVCは実質的に入出力の責務分割であり、DDDはドメインのモデリング手法です。Be Frameworkは「存在の条件と時間的変容」でオブジェクトの生成を組み立てる設計パラダイムで、MVCのControllerから呼び出すことも、DDDの集約の内部で使うこともできます。
 
-興味深いことに、MVCが目指した「メンタルモデルの投影」とDDDが目指した「ビジネスの言葉でコードを書く」は、Be Frameworkの存在型と意味変数によって自然に実現されています。
-
 ### Q1-a. CQRSとはどう関係しますか？
 
-A. CQRSが外部構造で分離しようとした「意思決定」と「データ参照」が、Beでは一つの存在型の中に自然に内在しています。
+A. CQRSは「データを変更する操作（Command）」と「データを読み取る操作（Query）」を分離するアーキテクチャです。Beでは、この分離が一つの存在型の中に自然に内在しています。
 
 コンストラクタが意思決定（Command）、publicプロパティがデータ参照（Query）です。`updateUser()`のような汎用メソッドに埋もれがちなビジネス判断が、`DeactivatedUser`のような型名として表出するため、意図がコードから失われません。
 
 ### Q2. OOP/FPのどちらですか？
 
-A. どちらの要素も取り入れていますが、OOPとの関係はより本質的です。
+A. OOPの要素が中心ですが、FPの要素も取り入れています。
 
-OOPは本来、自律したオブジェクトがメッセージで協調する世界を目指しました。しかし実際には、サービス層が指示を出し、オブジェクトは従順なデータの入れ物になりがちです。Beでは`#[Be]`によりオブジェクトが自らの運命を宣言し、外部のオーケストレーターなしに自己組織化します。これはOOPが本来目指した自律性の回復です。
+Beでは`#[Be]`によりオブジェクトが自らの運命を宣言し、外部のオーケストレーターなしに自己組織化します。
 
 ### Q2-a. FPの要素はどう活かされていますか？
 
@@ -153,7 +153,7 @@ A. その存在が完了した証跡（誰が・いつ・何を）を内在さ
 
 A. コンストラクタの中で、Reasonに委譲して完結させます。
 
-従来のサービス層はオブジェクトの外側から「保存しろ」「通知しろ」と操作していました。Beではオブジェクト自身がコンストラクタで副作用を完結させます。[Q2](#q2-oopfpのどちらですか)で述べた自律性が、ここに現れています。外部オーケストレーターは不要です。
+従来のサービス層はオブジェクトの外側から「保存しろ」「通知しろ」と操作していました。Beではオブジェクト自身がコンストラクタで副作用を完結させます。外部オーケストレーターは不要です。
 
 ### Q12. 例外はどう扱いますか？
 
@@ -185,15 +185,11 @@ A. 手順依存=線形／条件で結果が排他的=分岐／独立処理の合
 
 ### Q15. 既存のMVCアプリに導入できますか？
 
-A. はい、可能です。UseCase層をBeで置き換えて、Controllerからは`becoming(new …Input)`を呼ぶことで実現できます。
-
-徐々に内在/超越へ整理できますので、段階的な移行が可能です。
+A. はい。UseCase層をBeで置き換え、Controllerから`becoming(new …Input)`を呼びます。段階的な移行が可能です。
 
 ### Q16. DBや外部APIはどこで使いますか？
 
-A. Reasonに閉じ込めます。
-
-永続化や外部通信はユーザーの関心ではなく実装詳細です。Reasonに集約することで、存在型はDBスキーマやAPIの都合から自由になり、存在の定義と技術的手段が分離されます。
+A. Reasonに閉じ込めます。存在型はDBスキーマやAPIの都合から自由になり、存在の定義と技術的手段が分離されます。
 
 ### Q17. フレームワークの依存関係は？
 
@@ -264,6 +260,9 @@ final readonly class UserInput {
 
 // 2) 存在（変容の瞬間）
 final readonly class ValidatedUser {
+    public string $display;
+    public bool $isValid;
+
     public function __construct(
         #[Input] string $name,
         #[Input] string $email,
@@ -273,8 +272,6 @@ final readonly class ValidatedUser {
         $this->display = $fmt->format($name);
         $this->isValid = $v->validate($email);
     }
-    public string $display;
-    public bool $isValid;
 }
 
 // 3) 実行（自己組織化）
@@ -290,16 +287,21 @@ $user = $becoming(new UserInput($name, $email));
 ## 9) 重要用語の詳細解説
 
 ### 存在指向 / Ontological（オントロジカル）
+
 「何をするか」ではなく「何が存在できるか」を中心に据える設計思想です。存在可能性と時間を第一級の抽象として扱い、プログラムの状態を時間的な存在として捉えます。その結果、存在できない状態は型として表現されないため、不正状態が自然に排除されます。
 
 ### イマナンス / トランセンデンス（内在 / 超越）
+
 内在（`#[Input]`）はオブジェクトが本来持つ性質、超越（`#[Inject]`）は外部から与えられる力です。変容は常に「内在 + 超越 → 新しい内在」の公式に従います。超越は内在を変え、自らは消えていきます。
 
 ### 存在理由層（Reason Layer）
+
 ある存在が成立するために必要な根拠と道具一式をまとめたオブジェクトです。詳細は[Q9](#q9-存在理由層reasonとは何ですか)を参照してください。
 
 ### 意味変数（Semantic Variables）
+
 変数名そのものが意味と制約を表現する概念です。例えば`$email`は名前で意味を表し、型として「有効なEmail」でなければ存在できないという制約を持ちます。分散しがちな検証ロジックを型レベルで統合します。
 
 ### 意味的例外（Semantic Exceptions）
+
 失敗を単純な文字列ではなく、意味を持った構造化されたデータとして保持する仕組みです。多言語対応や監査要件に対応し、システムの動作を意味レベルで追跡可能にします。