From de11bb303d02b64904385d1182be2739c6dd3c28 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Wed, 17 Dec 2025 01:14:21 +0000
Subject: [PATCH 1/3] refactor: rewrite philosophy chapter with humble,
 accessible tone

- Add "Why Read This?" intro explaining the chapter's purpose
- Replace academic jargon (Dasein, Geworfenheit) with plain language
- Use tentative framing ("One way to see...", "This suggests...")
- Add new "From Tell to Be" section grounding philosophy practically
- Add "Designing for Impossibility" section with concrete examples
- Remove grandiose claims about "engineers becoming philosophers"
- New conclusion acknowledging these may be useful analogies
- Improve overall readability while preserving philosophical depth
---
 manuals/1.0/en/12-philosophy-behind.md | 501 ++++++++++++-------------
 1 file changed, 248 insertions(+), 253 deletions(-)

diff --git a/manuals/1.0/en/12-philosophy-behind.md b/manuals/1.0/en/12-philosophy-behind.md
index 453cecb..17aae9b 100644
--- a/manuals/1.0/en/12-philosophy-behind.md
+++ b/manuals/1.0/en/12-philosophy-behind.md
@@ -10,402 +10,397 @@ permalink: /manuals/1.0/en/12-philosophy-behind.html
 > "Everything flows" (Panta Rhei)
 > —Heraclitus (535-475 BC)
 
-Now that we have learned the implementation of Be Framework, let's explore the deep philosophical insights flowing at its foundation. This is not merely a technical choice, but an encounter between ancient wisdom about the essence of existence and transformation, and modern computational theory.
+## Why Read This?
 
-## 1. Ontological Programming: Discovery of "WHETHER?"
+You've learned how Be Framework works. This chapter explores **why** it works this way—the philosophical ideas that shaped its design.
 
-### Why Ontology?
+These connections between ancient philosophy and modern code aren't meant to impress. They're offered because understanding them may help you see familiar problems differently, and perhaps find the patterns more intuitive.
 
-Traditional programming has answered two questions:
+---
+
+## 1. From "Tell" to "Be"
+
+### A Different Emphasis
+
+**1967: Tell, Don't Ask**
 
-- **"What to do?" (WHAT?)** - Functions and algorithms
-- **"How to do it?" (HOW?)** - Implementation and performance
+> "Don't ask an object for data, tell it what to do"
 
-However, the most fundamental question has been overlooked:
+This principle guided OOP for decades. But notice—we were still *commanding* objects.
 
-- **"Can it exist in the first place?" (WHETHER?)**
+**2025: Be, Don't Do**
 
-Ontological Programming asks this "WHETHER?" first. Can an invalid email address exist as `$email`? Can a negative age be born as `$age`?
+> "Don't tell an object what to do, let it become what it is"
 
 ```php
-// Ontological Question: Is this state possible?
-#[Be(ValidatedUser::class)]  // Declare destiny of existence
-final readonly class UserInput
-{
-    public function __construct(
-        public string $email,    // Existence condition 1
-        public int $age          // Existence condition 2
-    ) {}
-}
+// Tell, Don't Ask (imperative)
+$user->validate();
+$user->save();
 
-// Answer: If conditions are met, it exists as ValidatedUser
+// Be, Don't Do (declarative)
+$user = $becoming(new UserInput($data));
 ```
 
-**Traditional**: "Validate this data" (Imperative)
-**Ontological**: "Can this data exist?" (Ontological inquiry)
+### A Question Worth Considering
+
+Alan Kay envisioned objects as autonomous cells communicating through messages. What emerged in practice often looks more like controllers commanding passive data structures.
 
-### Human Role in the AI Era
+One way to see Be Framework: an attempt to move closer to that original vision—objects that participate in determining their own transformation.
 
-In an era where AI can optimize "How to do", the role of humans shifts to "What should exist". Engineers change from implementers to definers.
+---
 
-- **Human**: Definition of meaning, setting conditions for existence
-- **AI**: Generation of optimal implementation methods
-- **Collaboration**: Human meaning creation × AI implementation optimization
+## 2. The Question of "WHETHER?"
 
-## 2. Temporal Being: Expressing Heidegger's "Dasein" in Code
+### Three Questions
 
-### Being Thrown into Time
+| Question     | Focus          | Paradigm    |
+|--------------|----------------|-------------|
+| **HOW?**     | Implementation | Imperative  |
+| **WHAT?**    | Transformation | Functional  |
+| **WHETHER?** | Existence      | Ontological |
 
-Heidegger described humans as beings with **Thrownness (Geworfenheit)**. We start from conditions we cannot choose, and build our existence from there.
+Traditional programming asks "How to validate?" or "What to transform?"
 
-Be Framework objects have a similar structure:
+Ontological Programming suggests asking first: "Can this exist at all?"
 
 ```php
-// Thrownness: Unchooseable initial conditions
-#[Be(UserProfile::class)]
-final readonly class UserInput     // Thrown existence
+#[Be(ValidatedUser::class)]
+final readonly class UserInput
 {
     public function __construct(
-        public string $name,     // Given condition
-        public string $email     // Given situation
+        public string $email,
+        public int $age
     ) {}
 }
-
-// Projection: Possibility towards the future
-final readonly class UserProfile   // Projection into possibility
-{
-    public function __construct(
-        #[Input] string $name,                    // Thrown past
-        #[Input] string $email,
-        #[Inject] NameFormatter $formatter        // Encounter with the world
-    ) {
-        $this->displayName = $formatter->format($name);  // New existence
-    }
-    
-    public string $displayName;
-}
 ```
 
-### Objects as Dasein
+If conditions are met, `ValidatedUser` exists. If not, it simply doesn't.
 
-Heidegger's **Dasein** means "being there", an existence that understands itself within time. Be Framework objects possess exactly this Dasein-like character:
+---
 
-- **Temporality**: Past (Input Class) → Present (Being Class) → Future (Final Object)
-- **Self-understanding**: Understanding of one's own possibilities via `#[Be()]`
-- **Being-in-the-world**: Relationship with the world via `#[Inject]`
-- **Existentiality**: Choosing one's own existential possibilities (Type-Driven Metamorphosis)
+## 3. Designing for Impossibility
 
-```php
-// Dasein-like Object: Understanding self in time
-#[Be([ApprovedLoan::class, RejectedLoan::class])]  // Understanding possibilities of existence
-final readonly class LoanApplication
-{
-    // Existential choice determining one's destiny
-    public ApprovedLoan|RejectedLoan $being;
-    
-    public function __construct(
-        #[Input] Money $amount,                   // Thrown condition
-        #[Input] CreditScore $score,              // Given situation
-        #[Inject] LoanPolicy $policy              // Encounter with the world
-    ) {
-        // Existential Decision: What will I become?
-        $this->being = $policy->evaluate($amount, $score) > 0.7
-            ? new ApprovedLoan($amount, $score)
-            : new RejectedLoan($amount, $score);
-    }
-}
-```
+### Two Approaches
 
-## 3. The Tao and Wu Wei: Realizing Laozi's Philosophy in Programming
+**Defensive approach:**
 
-### Principle of Wu Wei (Non-doing)
+```txt
+"What if an error occurs?"
+→ Add checks, handle exceptions
+```
 
-Laozi said: "The Way constantly does nothing, yet there is nothing it does not do."
+**Existence approach:**
 
-This does not mean "doing nothing". It means following the natural flow, without forcing things, acting in accordance with the true nature of things.
+```txt
+"Can invalid states exist?"
+→ Design so they cannot
+```
 
 ```php
-// Practice of Wu Wei: Do not force, flow naturally
-final readonly class OrderProcessing
-{
-    public function __construct(
-        #[Input] Order $order,                    // Natural premise
-        #[Inject] PaymentGateway $gateway         // External power
-    ) {
-        // Wu Wei: Not making something do, but enabling it to become what it should be
-        $this->result = $gateway->process($order);  // Natural metamorphosis
-    }
+// Defensive
+function processUser(User $user) {
+    if (!$user->isValid()) { throw new Exception(); }
+    if (!$user->hasEmail()) { throw new Exception(); }
+    // ...
 }
 
-// Not this (Yu Wei / Action: Forced execution):
-// $gateway->validateCard($order->card);
-// $gateway->chargeAmount($order->amount);  
-// $gateway->sendConfirmation($order->email);
+// Existence-based
+function processUser(ValidatedUser $user) {
+    // ValidatedUser exists, so it's valid by construction
+}
 ```
 
-### Code Flowing Like Water
+The idea: rather than handling errors, make certain errors impossible to represent.
 
-Laozi also said: "The highest good is like water." Water does not contend, places itself in low places that people dislike, yet nourishes all things.
+---
+
+## 4. Heraclitus: Everything Flows
+
+### Objects in Time
+
+Heraclitus observed that you cannot step into the same river twice.
+
+Traditional objects often exist outside of time:
+
+```php
+$user->age = 5;
+$user->age = 50;   // Same object, different age
+$user->delete();
+$user->getName();  // After deletion?
+```
 
-Be Framework objects flow like water:
+### Temporal Sequence
 
-- **Do not contend**: No external control, metamorphosis by self-determination
-- **Low places**: Simple structure, avoiding complexity
-- **Nourish all things**: Enabling metamorphosis of other objects
+One observation: domain concepts often have natural temporal order.
 
 ```php
-// Natural flow like water
-$result = $becoming(new ApplicationInput($data));
+// Types can express this order:
+UserInput → RegisteredUser → ActiveUser → DeletedUser
+```
 
-// The object itself knows the next form (like water flowing to low places)
-// No external orchestrator needed
+Each stage is distinct. A `DeletedUser` type cannot become `ActiveUser`—the type system reflects this constraint.
+
+```txt
+Time T0: EmailInput       — initial state
+    ↓
+Time T1: ValidatedEmail   — after validation
+    ↓
+Time T2: RegisteredUser   — after registration
 ```
 
-## 4. Entelechy: Aristotle's Full Realization
+Each stage represents a complete state, not a partial one.
+
+---
+
+## 5. Aristotle's Dynamis: Potentiality
 
-### Transition from Potentiality to Actuality
+Aristotle distinguished **Dynamis** (potentiality) from **Energeia** (actuality). An acorn has the potential to become an oak tree.
 
-Aristotle's **Entelechy (ἐντελέχεια)** represents the process of potential becoming actual. Like an acorn becoming an oak tree, it is the moment when immanent potential is realized through interaction with the outside.
+Union types can express this idea:
 
 ```php
-// Entelechy: Full realization of potentiality
-final readonly class MatureUser     // Fully realized existence
+#[Be([ApprovedLoan::class, RejectedLoan::class])]
+final readonly class LoanApplication
 {
+    public ApprovedLoan|RejectedLoan $being;
+
     public function __construct(
-        #[Input] UserData $potentiality,         // Potentiality
-        #[Inject] ValidationService $actuator    // Power of actualization
+        #[Input] Money $amount,
+        #[Input] CreditScore $score,
+        #[Inject] LoanPolicy $policy
     ) {
-        // Entelechy: Moment when potentiality transitions to actuality
-        $this->actualizedProfile = $actuator->actualize($potentiality);
+        $this->being = $policy->evaluate($amount, $score) > 0.7
+            ? new ApprovedLoan($amount, $score)
+            : new RejectedLoan($amount, $score);
     }
-    
-    public UserProfile $actualizedProfile;  // Actualized existence
 }
 ```
 
-### Constructor as the Stage of Metamorphosis
+The type `ApprovedLoan|RejectedLoan` declares the possible outcomes from the start. The object carries its potential futures.
 
-The constructor is the sacred place where Entelechy occurs. Here, immanent potential (`#[Input]`) meets external actualizing power (`#[Inject]`) and a new existence is born.
-
-```php
-public function __construct(
-    #[Input] string $name,           // Immanent potentiality
-    #[Inject] Formatter $formatter   // Actualizing power
-) {
-    // Entelechy: A new existence is born at this moment
-    $this->formattedName = $formatter->format($name);
-}
-```
+---
 
-## 5. Principle of Sufficient Reason: Leibniz's Reason for Existence
+## 6. Wu Wei: Non-Forcing
 
-### Everything Has a Reason for Existence
+Laozi wrote:
 
-Leibniz's **Principle of Sufficient Reason (Principium rationis sufficientis)** states that "for everything, there is a sufficient reason why it exists".
+> "The Tao does nothing, yet nothing is left undone."
 
-In Be Framework, this philosophy is realized as the **Reason Layer**:
+This suggests acting in accordance with natural flow rather than forcing outcomes.
 
 ```php
-final readonly class ValidatedUser
-{
-    public function __construct(
-        #[Input] string $email,                 // Immanence
-        #[Input] ValidationReason $reason       // Reason for existence (raison d'être)
-    ) {
-        // ValidationReason provides the reason for existence for ValidatedUser
-        $this->isValid = $reason->validate($email);
-    }
-}
+// Forcing
+$controller->forceUserToValidate();
+$controller->forceUserToSave();
+
+// Enabling
+#[Be(ValidatedUser::class)]
+#[Be(SavedUser::class)]
+$user = $becoming(new UserInput($data));
 ```
 
-### Raison d'être
+The second approach doesn't force—it declares what the object can become and lets the transformation happen.
 
-French for "reason for being". The Reason Layer provides the grounds for an object to be that existence:
+---
 
-- `ValidatedUser`'s raison d'être → Validation capability
-- `SavedUser`'s raison d'être → Saving capability
-- `DeletedUser`'s raison d'être → Deletion capability
+## 7. Buddhist Dependent Origination
 
-Each existence has a sufficient reason that enables that existence.
+### Pratītyasamutpāda
 
-## 6. Immanence and Transcendence: Spinoza's Dual Aspects
+Buddhist philosophy teaches:
 
-### Immanent Nature and Transcendent Power
+> "When this exists, that comes to be."
 
-Spinoza perceived reality as two aspects of one substance: **Immanence** and **Transcendence**.
+This describes interdependent arising—things don't exist in isolation.
 
 ```php
-final readonly class UserProfile
+final readonly class ValidatedEmail
 {
     public function __construct(
-        #[Input] string $name,              // Immanence: What it already has
-        #[Input] string $email,             // Immanence: Given nature
-        #[Inject] Formatter $formatter,     // Transcendence: Power from outside
-        #[Inject] Validator $validator      // Transcendence: Capability provided by the world
+        #[Input] string $value,              // Prior existence
+        #[Inject] EmailValidator $validator  // Enabling condition
     ) {
-        // A new existence is born from the encounter of Immanence and Transcendence
-        $this->displayName = $formatter->format($name);    // New Immanence
-        $this->isValid = $validator->validate($email);     // New Immanence
+        // ValidatedEmail arises from these conditions
     }
 }
 ```
 
-### Eternal Formula of Metamorphosis
+### What Persists, What Falls Away
 
-All Being Classes possess the same philosophical structure:
+This also suggests thinking about what continues through transformation versus what enables it:
 
-**Immanence** + **Transcendence** → **New Immanence**
+```php
+#[Be(Adult::class)]
+final readonly class Child
+{
+    public function __construct(
+        #[Input] string $name,           // Continues: identity
+        #[Input] array $memories,        // Continues: experiences
+        #[Inject] SchoolService $school  // Enables, then releases
+    ) {
+        $this->wisdom = $school->learn($memories);
+    }
+}
+```
 
-This reflects Spinoza's philosophy of "Deus sive Natura" (God or Nature). Nature (external power) and Divinity (immanent essence) are two sides of one reality, and a new existence arises from their interaction.
+- `#[Input]` — what carries forward
+- `#[Inject]` — what enables transformation but doesn't persist
 
-## 7. Zhuangzi's Relativity: Accepting Multiple Destinies
+---
 
-### Philosophy of Equality of All Things
+## 8. Immanence and Transcendence
 
-Zhuangzi preached "The Equality of All Things" (Qi Wu Lun)—all things are fundamentally equivalent, and opposing concepts are merely different aspects of one reality.
+### Becoming Through Encounter
 
-Type-Driven Metamorphosis embodies this philosophy:
+Spinoza saw reality as interplay between what something already is (immanence) and what comes from beyond (transcendence).
 
 ```php
-#[Be([Success::class, Failure::class])]  // Success and Failure are equivalent possibilities
-final readonly class PaymentAttempt
+final readonly class UserProfile
 {
-    public Success|Failure $being;  // Both are valid existences
-    
-    public function __construct(/* ... */) {
-        // Both success and failure are treated as complete existences
-        $this->being = $result->isSuccessful()
-            ? new Success($result)    // Existence called Success
-            : new Failure($result);   // Existence called Failure
+    public function __construct(
+        #[Input] string $name,           // What it already has
+        #[Input] string $email,          // Given nature
+        #[Inject] Formatter $formatter,  // External capability
+        #[Inject] Validator $validator   // World's contribution
+    ) {
+        $this->displayName = $formatter->format($name);
+        $this->isValid = $validator->validate($email);
     }
 }
 ```
 
-## 8. Heraclitean Flux: Perpetual Change
+The pattern: **Given nature** + **External capability** → **New state**
 
-### "Everything Flows"
+This resembles how people develop—not through internal properties alone, but through encounters with others, culture, and environment.
 
-Heraclitus said "Panta Rhei" (πάντα ῥεῖ)—"Everything flows". You cannot step into the same river twice. Because it is no longer the same river, and you are no longer the same person.
+---
 
-Metamorphosis expresses this perpetual change:
+## 9. Three Kinds of Transparency
 
-```php
-// Time T0: Primal existence
-#[Be(EmailValidation::class)]
-final readonly class EmailInput { /* ... */ }
+Be Framework aims for clarity at three levels:
 
-// Time T1: First Metamorphosis (T0 is already past)
-#[Be(UserCreation::class)]  
-final readonly class EmailValidation { /* ... */ }
+**1. Structural**
 
-// Time T2: Final Existence (encompassing all past)
-final readonly class UserCreation { /* ... */ }
+```php
+UserInput → ValidatedUser → SavedUser → ActiveUser
 ```
 
-Each moment never returns, and objects naturally transform within the flow of time.
-
-### Unity of Opposites
+The transformation path is visible in the types.
 
-Heraclitus also preached the "Unity of Opposites". Day and night, life and death, up and down—opposites are actually different aspects of one reality.
+**2. Semantic**
 
 ```php
-// Unity of Opposites: Activation and Deactivation are two sides of the same reality
-public ActiveUser|InactiveUser $being;
+string $email     // Name suggests Email validation
+string $password  // Name suggests Password validation
 ```
 
-## 9. Buddhist Dependent Origination: Interdependent Existence
+Names carry meaning.
+
+**3. Execution**
 
-### Non-Self and Dependent Origination
+```json
+{
+  "metamorphosis": "UserInput → ValidatedUser",
+  "inputs": { "email": "user@example.com" },
+  "validations": ["email.format: passed"],
+  "result": "ValidatedUser created"
+}
+```
 
-Buddhist **Dependent Origination (pratītyasamutpāda)** teaches that "all things exist depending on each other". Independent entities do not exist, and everything is born within a web of relationships.
+Logs record what happened.
 
-Be Framework objects are exactly this Dependent Origination existence:
+When these align, the code can serve as its own documentation.
+
+---
+
+## 10. AI Collaboration
+
+Some decisions don't fit deterministic rules well. The `#[Accept]` pattern acknowledges this:
 
 ```php
-final readonly class UserProfile    // Existence of Dependent Origination
+#[Be(DiagnosedPatient::class)]
+final readonly class PatientSymptoms
 {
+    public Diagnosis|Undetermined $being;
+
     public function __construct(
-        #[Input] string $name,              // Dependent on other existence
-        #[Inject] DatabaseConnection $db,   // Dependent on relationship with outside
-        #[Inject] ValidationService $validator  // Interdependent with service
+        #[Input] array $symptoms,
+        #[Accept] DiagnosticAI $ai
     ) {
-        // New existence appears from interdependent relationships
+        $result = $ai->analyze($symptoms);
+        $this->being = $result->confidence > 0.85
+            ? new Diagnosis($result)
+            : new Undetermined($symptoms, $result->suggestions);
     }
 }
 ```
 
-### Implementation of Non-Self (Anātman)
+This suggests a division of concerns:
+
+- Humans define what states can exist and what they mean
+- AI can help determine which state applies
 
-Buddhist **Non-Self (anātman)** creates the teaching that "there is no fixed self". Everything is a bundle of changing relationships.
+---
 
-In Be Framework:
-- Objects have no fixed "essence"
-- State does not change due to `public readonly`
-- Each stage appears as a completely independent existence
-- "Self" is composed of relationships (Dependency Injection)
+## 11. Connections
 
-## 10. Integration of Programming Philosophy
+These philosophical ideas share common themes:
 
-### Wisdom of East and West
+| Source     | Concept                 | Expression in BOP        |
+|------------|-------------------------|--------------------------|
+| Heraclitus | Flow                    | `Input → Being → Final`  |
+| Aristotle  | Potentiality            | `Success|Failure $being` |
+| Laozi      | Non-forcing             | `#[Be]` declaration      |
+| Buddhism   | Interdependence         | `#[Input]` + `#[Inject]` |
+| Spinoza    | Immanence/Transcendence | Input/Inject distinction |
+| Leibniz    | Sufficient reason       | Reason Layer*            |
 
-Be Framework integrates Eastern and Western philosophical traditions:
+*See [Chapter 8: Reason Layer](./08-reason-layer.html) for details.*
 
-**Eastern Wisdom**:
-- **Taoism**: Flow of Wu Wei / Non-doing
-- **Buddhism**: Dependent Origination and Non-Self, Impermanence
-- **Zhuangzi**: Acceptance of relativity and metamorphosis
+These aren't forced mappings—the patterns emerged and the philosophical parallels became apparent afterward.
 
-**Western Thought**:
-- **Heidegger**: Dasein as Temporal Being
-- **Aristotle**: Entelechy (Realization of possibility)
-- **Leibniz**: Principle of Sufficient Reason
-- **Spinoza**: Unity of Immanence and Transcendence
+---
 
-### Sublimation to Computational Philosophy
+## 12. Shifting Perspective
 
-When these ancient wisdoms are realized in modern programming, a new **Computational Philosophy** is born:
+### Different Questions
 
-- **Ontological Design**: Defining what can exist
-- **Temporal Programming**: Respecting the temporality of objects
-- **Wu Wei Execution**: Control following natural flow
-- **Dependent Origination Dependency**: Realization of existence through interdependence
-- **Relativistic Result**: Accepting multiple valid results
+| Era         | Typical Question               |
+|-------------|--------------------------------|
+| Assembly    | "How to instruct the machine?" |
+| Procedural  | "What steps to execute?"       |
+| OOP         | "Who is responsible?"          |
+| Functional  | "What becomes what?"           |
+| Ontological | "What can exist?"              |
 
-## 11. Prospect for the Future: Next Evolution of Programming
+### A Different Role
 
-### Evolution of Paradigm
+This framing suggests the programmer's work includes:
 
-Looking at the evolution of programming paradigms, we are gradually approaching the principles of nature:
+- Deciding what states are meaningful
+- Defining what existence is possible
+- Designing the structure of valid states
 
-1. **Machine Language Era**: "Command the machine"
-2. **Procedural Era**: "Describe procedures"
-3. **Object-Oriented Era**: "Delegate responsibility to objects"
-4. **Functional Era**: "Define mathematical transformations"
-5. **Ontological Era**: "Declare conditions of existence and enable natural metamorphosis"
+---
 
-### Humanity in the AI Era
+## Where to Go from Here
 
-In an era where AI can optimize "How to do", human uniqueness lies in the ability to decide "What should exist, what has meaning".
+To explore further:
 
-Ontological Programming maximizes this human-specific value:
-- **Creator of Meaning**: Deciding what existence has value
-- **Designer of Existence**: Defining possible states of existence
-- **Philosophical Thinker**: Designing the ontological structure of systems
+1. **Re-read earlier chapters** — the patterns may look different now
+2. **Notice your habits** — when do you control vs. enable?
+3. **Experiment** — try asking "What should this become?" instead of "What should this do?"
 
-### Programming Paradigm in the AI Era
+---
 
-In an era where AI can handle the implementation of "How to do", the essence of programming changes. Rather than describing commands, defining **what can exist** becomes the core.
+## Conclusion
 
-Ontological Programming is a paradigm with a philosophical foundation for this new era:
-- Rather than implementation details that AI can optimize
-- Focusing on meanings and constraints of existence that humans should define
-- Enabling role shift from "Writer of commands" to "Designer of existence"
+Be Framework draws on old ideas: flow, potentiality, interdependence, natural transformation. These aren't decorations—they shaped the design.
 
----
+Whether these philosophical connections resonate with you or not, the practical patterns remain: immutable objects, type-driven transformation, constructor-based metamorphosis.
 
-> **"Where the river flows, there is the way."**
-> —Modern interpretation of Laozi
+Ancient philosophers and modern programmers ask similar questions in different languages. A different paradigm offers a different way to see. And how we see shapes what we can build.
 
-Be Framework is where ancient wisdom meets modern technology. Here, code becomes philosophy, programming becomes ontology, and engineers become modern philosophers.
+---
 
-Objects flow naturally, transform, and become what they should be—this is the new possibility of programming embodied by Be Framework.
+*Next: Return to [Overview](./01-overview.html) or see [Reference](./11-reference-resources.html) for additional resources.*

From c265a1a5136ddf421ad48dbf2a4430cabcf679b8 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Wed, 17 Dec 2025 01:19:26 +0000
Subject: [PATCH 2/3] refactor: rewrite Japanese philosophy chapter with humble
 tone
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Mirror the English version changes:
- Add "なぜこの章を読むのか" intro section
- Replace academic jargon with plain language
- Use tentative framing throughout
- Remove Heidegger/Dasein section
- Add practical "Tell to Be" and "Designing for Impossibility" sections
- New humble conclusion matching English version
---
 manuals/1.0/ja/12-philosophy-behind.md | 504 ++++++++++++-------------
 1 file changed, 249 insertions(+), 255 deletions(-)

diff --git a/manuals/1.0/ja/12-philosophy-behind.md b/manuals/1.0/ja/12-philosophy-behind.md
index 630eda4..2f9ac90 100644
--- a/manuals/1.0/ja/12-philosophy-behind.md
+++ b/manuals/1.0/ja/12-philosophy-behind.md
@@ -7,406 +7,400 @@ permalink: /manuals/1.0/ja/12-philosophy-behind.html
 
 # 背後にある哲学
 
-> 「万物は流転する」  
+> 「万物は流転する」（パンタ・レイ）
 > ——ヘラクレイトス（紀元前535-475年）
 
-Beフレームワークの実装を学んだ今、その根底に流れる深い哲学的洞察を探求しましょう。これは単なる技術的選択ではなく、存在と変容の本質についての古代からの叡智と、現代の計算理論との出会いです。
+## なぜこの章を読むのか
 
-## 1. 存在論的プログラミング：「WHETHER?」の発見
+Beフレームワークの使い方は学びました。この章では、**なぜ**このように設計されたのか——その背後にある哲学的なアイデアを探ります。
 
-### なぜ存在論なのか
+古代哲学と現代のコードを結びつけるのは、格好つけるためではありません。これらを理解することで、馴染みのある問題を違う角度から見られるようになり、パターンがより直感的に感じられるかもしれない——そう思って紹介しています。
 
-従来のプログラミングは二つの問いに答えてきました：
+---
+
+## 1.「Tell」から「Be」へ
+
+### 強調点の違い
+
+**1967年：Tell, Don't Ask**
 
-- **「何をするか？」（WHAT?）** - 機能とアルゴリズム
-- **「どうやるか？」（HOW?）** - 実装とパフォーマンス
+> 「オブジェクトにデータを尋ねるな、何をすべきか伝えよ」
 
-しかし、最も根本的な問いが見過ごされていました：
+この原則は何十年もOOPを導いてきました。しかし気づいてください——私たちはまだオブジェクトに*命令*していたのです。
 
-- **「そもそも存在できるか？」（WHETHER?）**
+**2025年：Be, Don't Do**
 
-存在論的プログラミングは、この「WHETHER?」を最初に問います。無効なメールアドレスは`$email`として存在できるでしょうか？負の年齢は`$age`として生まれることができるでしょうか？
+> 「オブジェクトに何をすべきか伝えるな、あるべき姿にならせよ」
 
 ```php
-// 存在の問い：この状態は可能か？
-#[Be(ValidatedUser::class)]  // 存在の運命を宣言
-final readonly class UserInput
-{
-    public function __construct(
-        public string $email,    // 存在条件1
-        public int $age          // 存在条件2
-    ) {}
-}
+// Tell, Don't Ask（命令的）
+$user->validate();
+$user->save();
 
-// 答え：条件が満たされれば ValidatedUser として存在する
+// Be, Don't Do（宣言的）
+$user = $becoming(new UserInput($data));
 ```
 
-**従来型**：「このデータを検証してください」（命令）  
-**存在論型**：「このデータは存在できますか？」（存在の問い）
+### 考えてみる価値のある問い
+
+アラン・ケイは、オブジェクトをメッセージでコミュニケーションする自律的な細胞として構想しました。しかし実際に生まれたものは、受動的なデータ構造を操作するコントローラーに近いものでした。
 
-### AI時代における人間の役割
+Beフレームワークの一つの見方：オブジェクトが自らの変容に参加する——そのオリジナルのビジョンに近づこうとする試みです。
 
-AIが「どうやるか」を最適化できる時代に、人間の役割は「何が存在すべきか」にシフトしていきます。エンジニアは実装者から、定義者に変わるのです。
+---
 
-- **人間**：意味の定義、存在の条件の設定
-- **AI**：最適な実現方法の生成
-- **協働**：人間の意味創造 × AIの実装最適化
+## 2.「WHETHER?」という問い
 
-## 2. 時間的存在：ハイデガーの「現存在」をコードで表現
+### 三つの問い
 
-### 時間の中に投げ込まれた存在
+| 問い | 焦点 | パラダイム |
+|------|------|------------|
+| **HOW?** | 実装 | 命令型 |
+| **WHAT?** | 変換 | 関数型 |
+| **WHETHER?** | 存在 | 存在論的 |
 
-ハイデガーは人間を**被投性（Geworfenheit）**を持つ存在として描きました。私たちは選択できない条件から始まり、そこから自分の存在を築き上げます。
+従来のプログラミングは「どう検証するか？」「何に変換するか？」と問いました。
 
-Beフレームワークのオブジェクトも同様の構造を持ちます：
+存在論的プログラミングは、まず「そもそも存在できるか？」と問います。
 
 ```php
-// 被投性：選択できない初期条件
-#[Be(UserProfile::class)]
-final readonly class UserInput     // 投げ込まれた存在
+#[Be(ValidatedUser::class)]
+final readonly class UserInput
 {
     public function __construct(
-        public string $name,     // 与えられた条件
-        public string $email     // 与えられた状況
+        public string $email,
+        public int $age
     ) {}
 }
-
-// 企投性：未来への可能性
-final readonly class UserProfile   // 可能性への投企
-{
-    public function __construct(
-        #[Input] string $name,                    // 被投された過去
-        #[Input] string $email,
-        #[Inject] NameFormatter $formatter        // 世界との出会い
-    ) {
-        $this->displayName = $formatter->format($name);  // 新しい存在
-    }
-    
-    public string $displayName;
-}
 ```
 
-### 現存在としてのオブジェクト
+条件が満たされれば`ValidatedUser`は存在します。満たされなければ、存在しません。
 
-ハイデガーの**現存在（Dasein）**は、「そこに存在する」という意味で、時間の中で自己を理解する存在です。Beフレームワークのオブジェクトは、まさにこの現存在的性格を持ちます：
+---
 
-- **時間性**：過去（入力クラス）→現在（存在クラス）→未来（最終オブジェクト）
-- **自己理解**：`#[Be()]`による自己の可能性の理解
-- **世界内存在**：`#[Inject]`による世界との関わり
-- **実存性**：自らの存在可能性を選択する（型駆動変容）
+## 3. 不可能性のための設計
 
-```php
-// 現存在的オブジェクト：時間の中で自己を理解する
-#[Be([ApprovedLoan::class, RejectedLoan::class])]  // 存在可能性の理解
-final readonly class LoanApplication
-{
-    // 自己の運命を決定する実存的選択
-    public ApprovedLoan|RejectedLoan $being;
-    
-    public function __construct(
-        #[Input] Money $amount,                   // 被投された条件
-        #[Input] CreditScore $score,              // 与えられた状況
-        #[Inject] LoanPolicy $policy              // 世界との出会い
-    ) {
-        // 実存的決断：自分は何者になるか
-        $this->being = $policy->evaluate($amount, $score) > 0.7
-            ? new ApprovedLoan($amount, $score)
-            : new RejectedLoan($amount, $score);
-    }
-}
-```
+### 二つのアプローチ
 
-## 3. 道と無為：老子の哲学をプログラミングで実現
+**防御的アプローチ：**
 
-### 無為自然の原理
+```txt
+「エラーが起きたらどうする？」
+→ チェックを追加し、例外を処理する
+```
 
-老子は言いました：「道常無為而無不為」——道は常に無為でありながら、なしえないことはない。
+**存在アプローチ：**
 
-これは「何もしない」という意味ではありません。自然の流れに従って、無理に強制することなく、事物の本性に沿って作用することです。
+```txt
+「無効な状態は存在できるか？」
+→ 存在できないように設計する
+```
 
 ```php
-// 無為の実践：強制しない、自然に流れる
-final readonly class OrderProcessing
-{
-    public function __construct(
-        #[Input] Order $order,                    // 自然な前提
-        #[Inject] PaymentGateway $gateway         // 外部の力
-    ) {
-        // 無為：何かをさせるのではなく、なるべき姿になることを可能にする
-        $this->result = $gateway->process($order);  // 自然な変容
-    }
+// 防御的
+function processUser(User $user) {
+    if (!$user->isValid()) { throw new Exception(); }
+    if (!$user->hasEmail()) { throw new Exception(); }
+    // ...
 }
 
-// これではない（有為：強制的な実行）：
-// $gateway->validateCard($order->card);
-// $gateway->chargeAmount($order->amount);  
-// $gateway->sendConfirmation($order->email);
+// 存在ベース
+function processUser(ValidatedUser $user) {
+    // ValidatedUserが存在する以上、構造的に有効
+}
 ```
 
-### 水のように流れるコード
+アイデア：エラーを処理するのではなく、特定のエラーを表現不可能にする。
 
-老子はまた言いました：「上善若水」——最高の善は水のようなものです。水は争わず、みんなが嫌がる低いところに身を置き、しかも万物を潤します。
+---
 
-Beフレームワークのオブジェクトは水のように流れます：
+## 4. ヘラクレイトス：万物は流転する
 
-- **争わない**：外部制御なし、自己決定による変容
-- **低いところ**：シンプルな構造、複雑さを回避
-- **万物を潤す**：他のオブジェクトの変容を可能にする
+### 時間の中のオブジェクト
+
+ヘラクレイトスは、同じ川に二度入ることはできないと観察しました。
+
+従来のオブジェクトは、しばしば時間の外に存在します：
+
+```php
+$user->age = 5;
+$user->age = 50;   // 同じオブジェクト、違う年齢
+$user->delete();
+$user->getName();  // 削除後に？
+```
+
+### 時間的な順序
+
+一つの観察：ドメイン概念にはしばしば自然な時間的順序があります。
 
 ```php
-// 水のような自然な流れ
-$result = $becoming(new ApplicationInput($data));
+// 型でこの順序を表現できる：
+UserInput → RegisteredUser → ActiveUser → DeletedUser
+```
+
+各段階は区別されます。`DeletedUser`型は`ActiveUser`にはなれない——型システムがこの制約を反映しています。
 
-// オブジェクト自身が次の形を知っている（水が低きに流れるように）
-// 外部のオーケストレーターは不要
+```txt
+時間 T0: EmailInput       — 初期状態
+    ↓
+時間 T1: ValidatedEmail   — 検証後
+    ↓
+時間 T2: RegisteredUser   — 登録後
 ```
 
-## 4. エンテレケイア：アリストテレスの完全実現
+各段階は部分的な状態ではなく、完全な状態を表します。
+
+---
+
+## 5. アリストテレスのデュナミス：可能態
 
-### 可能性から現実性への移行
+アリストテレスは**デュナミス**（可能態）と**エネルゲイア**（現実態）を区別しました。どんぐりは樫の木になる可能性を持っています。
 
-アリストテレスの**エンテレケイア（ἐντελέχεια）**は、潜在的なものが現実的になる過程を表します。どんぐりが樫の木になるように、内在的な可能性が外部との相互作用で実現される瞬間です。
+Union型でこのアイデアを表現できます：
 
 ```php
-// エンテレケイア：潜在性の完全実現
-final readonly class MatureUser     // 完全実現された存在
+#[Be([ApprovedLoan::class, RejectedLoan::class])]
+final readonly class LoanApplication
 {
+    public ApprovedLoan|RejectedLoan $being;
+
     public function __construct(
-        #[Input] UserData $potentiality,         // 潜在性
-        #[Inject] ValidationService $actuator    // 現実化の力
+        #[Input] Money $amount,
+        #[Input] CreditScore $score,
+        #[Inject] LoanPolicy $policy
     ) {
-        // エンテレケイア：潜在性が現実性へ移行する瞬間
-        $this->actualizedProfile = $actuator->actualize($potentiality);
+        $this->being = $policy->evaluate($amount, $score) > 0.7
+            ? new ApprovedLoan($amount, $score)
+            : new RejectedLoan($amount, $score);
     }
-    
-    public UserProfile $actualizedProfile;  // 現実化された存在
 }
 ```
 
-### コンストラクタは変容の舞台
-
-コンストラクタは、エンテレケイアが起こる神聖な場所です。ここで内在的な可能性（`#[Input]`）が外部の現実化する力（`#[Inject]`）と出会い、新しい存在が生まれます。
+`ApprovedLoan|RejectedLoan`という型は、最初から可能な結果を宣言しています。オブジェクトは自らの潜在的な未来を携えています。
 
-```php
-public function __construct(
-    #[Input] string $name,           // 内在的可能性
-    #[Inject] Formatter $formatter   // 現実化する力
-) {
-    // エンテレケイア：この瞬間に新しい存在が生まれる
-    $this->formattedName = $formatter->format($name);
-}
-```
+---
 
-## 5. 充足理由律：ライプニッツの存在理由
+## 6. 無為：強制しない
 
-### すべてのものには存在する理由がある
+老子は書きました：
 
-ライプニッツの**充足理由律（Principium rationis sufficientis）**は「すべてのものには、それが存在するための十分な理由がある」と述べます。
+> 「道は常に無為にして、而も為さざるは無し」
 
-Beフレームワークでは、この哲学が**存在理由層**として実現されています：
+これは、結果を強制するのではなく、自然な流れに従って作用することを示唆しています。
 
 ```php
-final readonly class ValidatedUser
-{
-    public function __construct(
-        #[Input] string $email,                 // 内在的性質
-        #[Input] ValidationReason $reason       // 存在理由（raison d'être）
-    ) {
-        // ValidationReasonが、ValidatedUserの存在理由を提供
-        $this->isValid = $reason->validate($email);
-    }
-}
+// 強制する
+$controller->forceUserToValidate();
+$controller->forceUserToSave();
+
+// 可能にする
+#[Be(ValidatedUser::class)]
+#[Be(SavedUser::class)]
+$user = $becoming(new UserInput($data));
 ```
 
-### raison d'être（存在理由）
+後者のアプローチは強制しません——オブジェクトが何になれるかを宣言し、変容が起こるに任せます。
 
-フランス語の**raison d'être**は「存在する理由」を意味します。存在理由層は、オブジェクトがその存在でいられるための根拠を提供します：
+---
 
-- `ValidatedUser`の raison d'être → 検証能力
-- `SavedUser`の raison d'être → 保存能力
-- `DeletedUser`の raison d'être → 削除能力
+## 7. 仏教の縁起
 
-各存在には、その存在を可能にする十分な理由があります。
+### 縁起（プラティーティヤサムトパーダ）
 
-## 6. 内在と超越：スピノザの二重のアスペクト
+仏教哲学は教えます：
 
-### 内在的性質と超越的力
+> 「これあるとき、かれあり」
 
-スピノザは現実を一つの実体の二つのアスペクトとして捉えました：**内在（Immanence）**と**超越（Transcendence）**。
+これは相互依存的な生起を表しています——物事は孤立して存在しません。
 
 ```php
-final readonly class UserProfile
+final readonly class ValidatedEmail
 {
     public function __construct(
-        #[Input] string $name,              // 内在：既に持っているもの
-        #[Input] string $email,             // 内在：与えられた性質
-        #[Inject] Formatter $formatter,     // 超越：外部からの力
-        #[Inject] Validator $validator      // 超越：世界が提供する能力
+        #[Input] string $value,              // 先行する存在
+        #[Inject] EmailValidator $validator  // 可能にする条件
     ) {
-        // 内在と超越の出会いで新しい存在が生まれる
-        $this->displayName = $formatter->format($name);    // 新しい内在
-        $this->isValid = $validator->validate($email);     // 新しい内在
+        // ValidatedEmailはこれらの条件から生起する
     }
 }
 ```
 
-### 変容の永遠の公式
+### 何が続き、何が落ちるか
 
-すべての存在クラスは同じ哲学的構造を持ちます：
+これはまた、変容を通じて何が続くか vs 何がそれを可能にするかを考えることを示唆します：
 
-**内在的性質** + **超越的力** → **新しい内在的存在**
+```php
+#[Be(Adult::class)]
+final readonly class Child
+{
+    public function __construct(
+        #[Input] string $name,           // 続く：アイデンティティ
+        #[Input] array $memories,        // 続く：経験
+        #[Inject] SchoolService $school  // 可能にし、そして離れる
+    ) {
+        $this->wisdom = $school->learn($memories);
+    }
+}
+```
 
-これはスピノザの「神即自然」の思想を反映しています。自然（外部の力）と神性（内在的本質）は一つの現実の二面であり、その相互作用から新しい存在が生まれます。
+- `#[Input]` — 引き継がれるもの
+- `#[Inject]` — 変容を可能にするが持続しないもの
 
-## 7. 荘子の相対性：複数の運命を受け入れる
+---
 
-### 万物斉同の思想
+## 8. 内在と超越
 
-荘子は「万物斉同」を説きました——すべてのものは根本的に同等であり、対立する概念も実は一つの現実の異なる側面に過ぎません。
+### 出会いを通じた生成
 
-型駆動変容は、この思想を体現しています：
+スピノザは現実を、すでにそうであるもの（内在）と外から来るもの（超越）の相互作用として捉えました。
 
 ```php
-#[Be([Success::class, Failure::class])]  // 成功と失敗は同等の可能性
-final readonly class PaymentAttempt
+final readonly class UserProfile
 {
-    public Success|Failure $being;  // 両方とも有効な存在
-    
-    public function __construct(/* ... */) {
-        // 成功も失敗も、どちらも完全な存在として扱われる
-        $this->being = $result->isSuccessful()
-            ? new Success($result)    // 成功という存在
-            : new Failure($result);   // 失敗という存在
+    public function __construct(
+        #[Input] string $name,           // すでに持っているもの
+        #[Input] string $email,          // 与えられた性質
+        #[Inject] Formatter $formatter,  // 外部の能力
+        #[Inject] Validator $validator   // 世界からの寄与
+    ) {
+        $this->displayName = $formatter->format($name);
+        $this->isValid = $validator->validate($email);
     }
 }
 ```
 
-## 8. ヘラクレイトスの流転：永続的な変化
+パターン：**与えられた性質** + **外部の能力** → **新しい状態**
 
-### 「万物は流転する」
+これは人間の発達に似ています——内部の性質だけでなく、他者、文化、環境との出会いを通じて。
 
-ヘラクレイトスは「パンタ・レイ」（πάντα ῥεῖ）——「万物は流転する」と言いました。同じ川に二度入ることはできません。なぜなら、それはもはや同じ川ではないし、あなたも同じ人間ではないからです。
+---
 
-変容は、この永続的変化を表現します：
+## 9. 三種類の透明性
 
-```php
-// 時間 T0: 原初の存在
-#[Be(EmailValidation::class)]
-final readonly class EmailInput { /* ... */ }
+Beフレームワークは三つのレベルでの明確さを目指しています：
 
-// 時間 T1: 第一変容（T0は既に過去）
-#[Be(UserCreation::class)]  
-final readonly class EmailValidation { /* ... */ }
+**1. 構造的**
 
-// 時間 T2: 最終存在（すべての過去を内包）
-final readonly class UserCreation { /* ... */ }
+```php
+UserInput → ValidatedUser → SavedUser → ActiveUser
 ```
 
-各瞬間は二度と戻らず、オブジェクトは時間の流れの中で自然に変容していきます。
+変容の経路が型に見えています。
 
-### 対立の統一
-
-ヘラクレイトスはまた「対立物の統一」を説きました。昼と夜、生と死、上と下——対立するものは実は一つの現実の異なる側面です。
+**2. 意味的**
 
 ```php
-// 対立の統一：活性化と非活性化は同じ現実の両面
-public ActiveUser|InactiveUser $being;
+string $email     // 名前がEmail検証を示唆
+string $password  // 名前がPassword検証を示唆
 ```
 
-## 9. 仏教の縁起：相互依存の存在
+名前が意味を運びます。
+
+**3. 実行時**
 
-### 諸法無我と縁起
+```json
+{
+  "metamorphosis": "UserInput → ValidatedUser",
+  "inputs": { "email": "user@example.com" },
+  "validations": ["email.format: passed"],
+  "result": "ValidatedUser created"
+}
+```
 
-仏教の**縁起（pratītyasamutpāda）**は「すべてのものは相互に依存して存在する」という教えです。独立した実体は存在せず、すべては関係性の網の中で生まれます。
+ログが何が起きたかを記録します。
 
-Beフレームワークのオブジェクトは、まさにこの縁起的存在です：
+これらが揃うと、コードはそれ自身のドキュメントになります。
+
+---
+
+## 10. AIとの協働
+
+決定論的なルールにうまく当てはまらない判断もあります。`#[Accept]`パターンはこれを認めています：
 
 ```php
-final readonly class UserProfile    // 縁起的存在
+#[Be(DiagnosedPatient::class)]
+final readonly class PatientSymptoms
 {
+    public Diagnosis|Undetermined $being;
+
     public function __construct(
-        #[Input] string $name,              // 他の存在に依存
-        #[Inject] DatabaseConnection $db,   // 外部との関係に依存
-        #[Inject] ValidationService $validator  // サービスとの相互依存
+        #[Input] array $symptoms,
+        #[Accept] DiagnosticAI $ai
     ) {
-        // 相互依存の関係から新しい存在が現れる
+        $result = $ai->analyze($symptoms);
+        $this->being = $result->confidence > 0.85
+            ? new Diagnosis($result)
+            : new Undetermined($symptoms, $result->suggestions);
     }
 }
 ```
 
-### 無我の実装
+これは関心の分離を示唆しています：
+
+- 人間がどの状態が存在でき、何を意味するかを定義する
+- AIがどの状態が適用されるか判断を助ける
 
-仏教の**無我（anātman）**は「固定した自己は存在しない」という教えです。すべては変化する関係性の束です。
+---
 
-Beフレームワークでは：
-- オブジェクトに固定した「本質」はありません
-- `public` により状態は変化しません
-- 各段階は完全に独立した存在として現れます
-- 「自己」は関係性（依存性注入）によって構成されます
+## 11. 関連性
 
-## 10. プログラミング哲学の統合
+これらの哲学的アイデアは共通のテーマを持っています：
 
-### 東洋と西洋の叡智
+| 出典 | 概念 | BOPでの表現 |
+|------|------|-------------|
+| ヘラクレイトス | 流転 | `Input → Being → Final` |
+| アリストテレス | 可能態 | `Success|Failure $being` |
+| 老子 | 無為 | `#[Be]`宣言 |
+| 仏教 | 縁起 | `#[Input]` + `#[Inject]` |
+| スピノザ | 内在/超越 | Input/Injectの区別 |
+| ライプニッツ | 充足理由 | 存在理由層* |
 
-Beフレームワークは、東洋と西洋の哲学的伝統を統合します：
+*詳細は[第8章：存在理由層](./08-reason-layer.html)を参照。*
 
-**東洋の叡智**：
-- **道教**：無為自然の流れ
-- **仏教**：縁起と無我、諸行無常
-- **荘子**：相対性と変容の受容
+これらは無理やりな対応づけではありません——パターンが先に生まれ、哲学的な類似性は後から明らかになりました。
 
-**西洋の思想**：
-- **ハイデガー**：時間的存在としての現存在
-- **アリストテレス**：エンテレケイア（可能性の実現）
-- **ライプニッツ**：充足理由律
-- **スピノザ**：内在と超越の統一
+---
 
-### 計算哲学への昇華
+## 12. 視点の転換
 
-これらの古代の叡智が現代のプログラミングで実現されるとき、新しい**計算哲学**が生まれます：
+### 異なる問い
 
-- **存在論的設計**：何が存在できるかを定義する
-- **時間的プログラミング**：オブジェクトの時間性を尊重する
-- **無為的実行**：自然な流れに従う制御
-- **縁起的依存性**：相互依存を通した存在の実現
-- **相対主義的結果**：複数の有効な結果を受け入れる
+| 時代 | 典型的な問い |
+|------|--------------|
+| アセンブリ | 「機械にどう指示するか？」 |
+| 手続き型 | 「どのステップを実行するか？」 |
+| OOP | 「誰が責任を持つか？」 |
+| 関数型 | 「何が何になるか？」 |
+| 存在論的 | 「何が存在できるか？」 |
 
-## 11. 未来への展望：プログラミングの次なる進化
+### 異なる役割
 
-### パラダイムの進化
+このフレーミングは、プログラマの仕事に以下が含まれることを示唆します：
 
-プログラミングパラダイムの進化を見ると、私たちは徐々に自然の原理に近づいています：
+- どの状態が意味を持つか決める
+- どの存在が可能か定義する
+- 有効な状態の構造を設計する
 
-1. **機械語時代**：「機械に命令する」
-2. **手続き型時代**：「手順を記述する」
-3. **オブジェクト指向時代**：「オブジェクトに責任を委譲する」
-4. **関数型時代**：「数学的変換を定義する」
-5. **存在論的時代**：「存在の条件を宣言し、自然な変容を可能にする」
+---
 
-### AI時代の人間性
+## ここからどこへ
 
-AIが「どうやるか」を最適化できる時代に、人間の独自性は「何が存在すべきか、何に意味があるか」を決める能力にあります。
+さらに探求するために：
 
-存在論的プログラミングは、この人間固有の価値を最大化します：
-- **意味の創造者**：どんな存在に価値があるかを決定
-- **存在の設計者**：可能な存在状態を定義
-- **哲学的思考者**：システムの存在論的構造を設計
+1. **前の章を読み返す** — パターンが違って見えるかもしれません
+2. **自分の習慣に気づく** — いつ制御し、いつ可能にしているか？
+3. **実験する** — 「これは何をすべきか？」の代わりに「これは何になるべきか？」と問うてみる
 
-### AI時代のプログラミングパラダイム
+---
 
-AIが「どうやるか」の実装を担える時代では、プログラミングの本質が変わります。命令を記述することよりも、**何が存在できるか**を定義することが中核となります。
+## 結論
 
-存在論的プログラミングは、この新しい時代のための哲学的基盤を持つパラダイムです：
-- AIが最適化できる実装の詳細よりも
-- 人間が定義すべき存在の意味と制約に焦点を当てる
-- 「命令の書き手」から「存在の設計者」への役割転換を可能にする
+Beフレームワークは古いアイデアに基づいています：流転、可能態、縁起、自然な変容。これらは飾りではありません——設計を形作りました。
 
----
+これらの哲学的な繋がりが響くかどうかは別として、実践的なパターンは残ります：イミュータブルなオブジェクト、型駆動の変容、コンストラクタベースの変容。
 
-> **「川の流れるところに道がある」**  
-> ——老子の言葉の現代的解釈
+古代の哲学者と現代のプログラマは、異なる言語で似た問いを投げかけています。異なるパラダイムは、異なる見方を提供します。そして、どう見るかが、何を作れるかを形作るのです。
 
-Beフレームワークは、古代の叡智と現代の技術が出会う場所です。ここでは、コードが哲学となり、プログラミングが存在論となり、エンジニアが現代の哲学者となります。
+---
 
-オブジェクトが自然に流れ、変容し、そしてあるべき姿になる——これが、Beフレームワークが体現する、プログラミングの新しい可能性です。
-```
+*次へ：[概要](./01-overview.html)に戻る、または[リファレンス](./11-reference-resources.html)で追加リソースを参照*

From f9f1b99bb6d09ede6e48e5a085c86258dc1bfbaf Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Wed, 17 Dec 2025 01:37:59 +0000
Subject: [PATCH 3/3] fix: use heading syntax instead of bold for subsection
 titles

---
 manuals/1.0/en/12-philosophy-behind.md | 6 +++---
 manuals/1.0/ja/12-philosophy-behind.md | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/manuals/1.0/en/12-philosophy-behind.md b/manuals/1.0/en/12-philosophy-behind.md
index 17aae9b..99e3451 100644
--- a/manuals/1.0/en/12-philosophy-behind.md
+++ b/manuals/1.0/en/12-philosophy-behind.md
@@ -279,7 +279,7 @@ This resembles how people develop—not through internal properties alone, but t
 
 Be Framework aims for clarity at three levels:
 
-**1. Structural**
+### 1. Structural
 
 ```php
 UserInput → ValidatedUser → SavedUser → ActiveUser
@@ -287,7 +287,7 @@ UserInput → ValidatedUser → SavedUser → ActiveUser
 
 The transformation path is visible in the types.
 
-**2. Semantic**
+### 2. Semantic
 
 ```php
 string $email     // Name suggests Email validation
@@ -296,7 +296,7 @@ string $password  // Name suggests Password validation
 
 Names carry meaning.
 
-**3. Execution**
+### 3. Execution
 
 ```json
 {
diff --git a/manuals/1.0/ja/12-philosophy-behind.md b/manuals/1.0/ja/12-philosophy-behind.md
index 2f9ac90..969be3d 100644
--- a/manuals/1.0/ja/12-philosophy-behind.md
+++ b/manuals/1.0/ja/12-philosophy-behind.md
@@ -279,7 +279,7 @@ final readonly class UserProfile
 
 Beフレームワークは三つのレベルでの明確さを目指しています：
 
-**1. 構造的**
+### 1. 構造的
 
 ```php
 UserInput → ValidatedUser → SavedUser → ActiveUser
@@ -287,7 +287,7 @@ UserInput → ValidatedUser → SavedUser → ActiveUser
 
 変容の経路が型に見えています。
 
-**2. 意味的**
+### 2. 意味的
 
 ```php
 string $email     // 名前がEmail検証を示唆
@@ -296,7 +296,7 @@ string $password  // 名前がPassword検証を示唆
 
 名前が意味を運びます。
 
-**3. 実行時**
+### 3. 実行時
 
 ```json
 {