diff --git a/.github/workflows/claude-code-review.yml b/.github/workflows/claude-code-review.yml
index 0a62f42..9380fa5 100644
--- a/.github/workflows/claude-code-review.yml
+++ b/.github/workflows/claude-code-review.yml
@@ -2,13 +2,8 @@ name: Claude Code Review
 
 on:
   pull_request:
-    types: [opened, synchronize]
-    # Optional: Only run on specific file changes
-    # paths:
-    #   - "src/**/*.ts"
-    #   - "src/**/*.tsx"
-    #   - "src/**/*.js"
-    #   - "src/**/*.jsx"
+    types: [opened]
+  workflow_dispatch:
 
 jobs:
   claude-review:
diff --git a/_includes/manuals/1.0/en/contents.html b/_includes/manuals/1.0/en/contents.html
index 24d7c7b..77626a0 100644
--- a/_includes/manuals/1.0/en/contents.html
+++ b/_includes/manuals/1.0/en/contents.html
@@ -18,7 +18,7 @@
         <ul class="navbar-nav mr-auto">
             {% assign en_pages = site.pages | where: "layout", "docs-en" | where: "category", "Manual" | sort: "path" %}
             {% for item in en_pages %}
-            {% unless item.path contains "/index.md" or item.path contains "/convention/" or item.path contains "12-philosophy-behind.md" %}
+            {% unless item.path contains "/index.md" or item.path contains "/convention/" %}
             {% assign item_link = item.permalink | default: item.url %}
             <li class="nav-item">
                 <a class="nav-link {% if page.permalink == item_link %}active{% endif %}"
diff --git a/_includes/manuals/1.0/ja/contents.html b/_includes/manuals/1.0/ja/contents.html
index 361448c..7588b88 100644
--- a/_includes/manuals/1.0/ja/contents.html
+++ b/_includes/manuals/1.0/ja/contents.html
@@ -18,7 +18,7 @@
         <ul class="navbar-nav mr-auto">
             {% assign ja_pages = site.pages | where: "layout", "docs-ja" | where: "category", "Manual" | sort: "path" %}
             {% for item in ja_pages %}
-            {% unless item.path contains "/index.md" or item.path contains "/convention/" or item.path contains "12-philosophy-behind.md" %}
+            {% unless item.path contains "/index.md" or item.path contains "/convention/" %}
             {% assign item_link = item.permalink | default: item.url %}
             <li class="nav-item">
                 <a class="nav-link {% if page.permalink == item_link %}active{% endif %}"
diff --git a/manuals/1.0/en/01-overview.md b/manuals/1.0/en/01-overview.md
index 754174d..6f897ec 100644
--- a/manuals/1.0/en/01-overview.md
+++ b/manuals/1.0/en/01-overview.md
@@ -4,15 +4,20 @@ title: "1. Overview"
 category: Manual
 permalink: /manuals/1.0/en/01-overview.html
 ---
+
 # Overview
 
-> "The real voyage of discovery consists not in seeking new landscapes, but in having new eyes."
-> 
+> "Becoming the self you want to be"
+> Be Framework is a framework for objects to transform into the self they want to be, by their own will.
+
+Marcel Proust said:
+> The real voyage of discovery consists not in seeking new landscapes, but in having new eyes.
+>
 > —Marcel Proust, 'The Prisoner' (In Search of Lost Time, Volume 5) 1923
 
-## A Different Way to Think About Code
+## From Doing to Being
 
-First, Look at This.
+First, look at this:
 
 ```php
 // Traditional way to delete a user
@@ -24,65 +29,79 @@ $activeUser = User::find($id);
 $deletedUser = new DeletedUser($activeUser);
 ```
 
-**`DeletedUser`?** What is that?
+"DeletedUser"? What is that? you might think.
 
-This question is your doorway into a new world of programming—one that invites you to think in **a completely different way**.
+Actually, this question is the entrance to a new world of programming. Let's think about programming in a way you have never thought of before.
 
-## From What to Do to What to Be
+## From 'What to Do' to 'What to Be'
 
-Traditional programming focuses on **DOING (actions)**:
+Traditional programming focuses on DOING (what to do):
 ```php
 $user->validate();
 $user->save();
 $user->notify();
 ```
 
-Be Framework focuses on **BEING (existence)**:
+Be Framework focuses on BEING (what to be):
 ```php
 $rawData = new UserInput($_POST);
 $validatedUser = new ValidatedUser($rawData);
 $savedUser = new SavedUser($validatedUser);
 ```
 
-One tells objects what to DO.
-The other defines what they can BE.
+The former instructs objects "what to do".
+The latter expresses "what state the object will become".
 
 ## Why This Matters
 
-When you focus on DOING:
-- You constantly check if actions are allowed
-- You handle endless error cases
-- You fight against invalid states
+When focusing on DOING:
+- You need to check "Is this action possible?" every time before execution
+- You have to deal with various error cases
+- Processing to prevent invalid states is always necessary
 
-When you focus on BEING:
-- Invalid states cannot exist in the first place
-- Objects carry their own validity just by existing
-- You can only focus on what's actually possible at that moment
+When focusing on BEING:
+- Invalid state objects simply do not exist from the beginning
+- The existence of the object itself becomes the proof of "correct state"
+- You can focus only on what you can do at that time. What you cannot do is simply not executable
 
-The difference is in the types themselves:
+The difference lies in the type itself:
 ```php
-// Traditional: general User type
+// Traditional: Generic type
 function processUser(User $user) { }
 
-// Be Framework: specific states of being
+// Be Framework: Specific state of being
 function processUser(ValidatedUser $user) { }
 function saveUser(SavedUser $user) { }
 function archiveUser(DeletedUser $user) { }
 ```
 
-Each type represents a specific stage of existence, not just data. The type system captures the temporal evolution of objects—you cannot delete what does not exist.
+Each type is not just data, but expresses a specific state of the object. In other words, the temporal change of the object is represented by the type, and you can only do what is possible at that time. For example, you cannot order a non-existent object to be deleted.
+
+## Why Not a "Controller"? (Wu Wei / Non-doing)
+
+The "Controller" in traditional MVC frameworks aims for "control and domination" as its name suggests. However, as systems become complex, this "approach of trying to control everything" becomes difficult.
+
+A Controller has "omnipotent freedom" to access all models and components, but having no constraints means implicitly bearing "infinite responsibility" to control and maintain consistency for every procedure in the system by itself.
+
+Be Framework adopts a different approach, incorporating the philosophy of "Wu Wei" (Non-doing) from Eastern philosophy. Rather than operations creating the target data, simple input objects like seeds meet other objects, grow naturally, and "transform themselves (Metamorphosis)" into the target final objects.
+
+### Commander to Gardener:
+* The Commander orders subordinates (objects) to "Move!". But it is impossible to keep ordering all complex autonomous movements.
+* The Gardener does not order plants. They only prepare the environment like water and light.
+
+Plants care only about their own transformation. They do not try to change others, but accept the environment and transform themselves autonomously (Metamorphosis) to become what they should be. Be Framework also prepares an environment where, once given input, objects become final objects by themselves. Let go of control and entrust to autonomous transformation. This is the core concept of Be Framework.
 
-## What You'll Learn
+## What You Will Learn in This Manual
 
-This manual will show you how to:
+You can acquire the following new programming methods:
 
-1. **Design "what objects are"** instead of "what they should do"
-2. **Make invalid states impossible to create** instead of checking for them
-3. **Express natural transformation (self-metamorphosis)** instead of forcing changes
-4. **Trust correct states** instead of defending against errors
+1. Design "what to be" instead of "what to do"
+2. Make it impossible to create invalid states from the beginning instead of checking them
+3. Express natural transformation (self-metamorphosis) instead of forcing objects to change
+4. Trust the correct state instead of preventing errors
 
-## Ready?
+## Let's Get Started
 
-Let's start with the foundation. Everything begins with [Input Classes]({% link manuals/1.0/en/02-input-classes.md %}) →
+Let's learn from the foundation. Everything starts from [Input Classes]({{ '/manuals/1.0/en/02-input-classes.html' | relative_url }}) →
 
-You'll build your first Being—and discover why `DeletedUser` makes perfect sense.
+Create your first object and experience why it is "DeletedUser".
diff --git a/manuals/1.0/en/02-input-classes.md b/manuals/1.0/en/02-input-classes.md
index e67c68c..2078e8c 100644
--- a/manuals/1.0/en/02-input-classes.md
+++ b/manuals/1.0/en/02-input-classes.md
@@ -7,36 +7,36 @@ permalink: /manuals/1.0/en/02-input-classes.html
 
 # Input Classes
 
-> "We begin from conditions we did not choose, and from there we build our existence."
-> 
-> —From Heidegger's concept of Geworfenheit (thrownness) in 'Being and Time' (1927)
+> "We begin from conditions we cannot choose, and build our existence from there."
+>
+> —From Heidegger's concept of Thrownness (Geworfenheit) ('Being and Time', 1927)
 
-## The Beginning
+## The Starting Point
 
-Input Classes are the starting point of every transformation in Be Framework.
+Input Classes are the starting point of all transformations in the Be Framework.
 
-They contain only what the object itself possesses—no external dependencies. Think of it as the object's identity. These elements exist within the object, forming what we call the object's **Immanent Nature**.
+This contains only the elements that the object itself possesses, with no external dependencies. It is, so to speak, the identity of the object. Since it is inside the object, we call this **Immanence**.
 
 ## Basic Structure
 
 ```php
-#[Be(UserProfile::class)]  // The object's destiny
+#[Be(UserProfile::class)]  // Destiny of Metamorphosis
 final readonly class UserInput
 {
     public function __construct(
-        public string $name,     // Immanent Nature
-        public string $email     // Immanent Nature
+        public string $name,     // Immanent
+        public string $email     // Immanent
     ) {}
 }
 ```
 
 ## Key Characteristics
 
-**Pure Identity**: Input Classes contain only what the object fundamentally *is*—no external dependencies, no complex logic.
+**Pure Identity**: Input Classes contain only *what the object fundamentally is*—no external dependencies or complex logic.
 
-**Metamorphosis Destiny**: The `#[Be()]` attribute declares what this input will become.
+**Destination (Object's Destiny)**: The `#[Be()]` attribute declares what this input will become.
 
-**Readonly Properties**: All data is immutable, representing fixed identity that will transform, not mutate.
+**Read-only Properties**: All data is immutable, representing a fixed identity that transforms rather than mutates.
 
 ## Examples
 
@@ -46,8 +46,8 @@ final readonly class UserInput
 final readonly class OrderInput
 {
     public function __construct(
-        public array $items,        // Immanent Nature
-        public string $currency     // Immanent Nature
+        public array $items,        // Immanent
+        public string $currency     // Immanent
     ) {}
 }
 ```
@@ -58,23 +58,21 @@ final readonly class OrderInput
 final readonly class PaymentInput
 {
     public function __construct(
-        public Money $amount,           // Immanent Nature
-        public CreditCard $card,        // Immanent Nature
-        public Address $billing         // Immanent Nature
+        public Money $amount,           // Immanent
+        public CreditCard $card,        // Immanent
+        public Address $billing         // Immanent
     ) {}
 }
 ```
 
-## The Role of Immanent Nature
+## The Role of Immanence
 
-Input Classes contain only **Immanent Nature** elements. These are the object's own data, independent of external dependencies.
+In Input Classes, everything is **Immanence**. There is no **Transcendence (transcendent power)** here. Transcendence explains powers provided from the outside that cannot be realized by oneself, and they appear later in **Being Classes**.
 
-**Transcendent Forces** (powers that the object cannot achieve by itself) are not included here. They appear in Being Classes, which we'll learn about next.
+For example, the `UserInput` class holds only raw data like email address and name. The power to validate if this email is valid, the power to save to the database, the power to send notifications—these are all Transcendence and do not exist in the Input Class. The Input Class simply declares "I am this kind of data".
 
-For example, a `UserInput` class holds only raw data like email address and name. The power to validate whether the email is valid, the power to save to a database, the power to send notifications—these are all transcendent forces and do not exist in Input Classes. Input Classes simply declare "this is the data I am."
-
-Input Classes represent the starting point of transformation—the object's initial form.
+Input Classes are the starting point of transformation. They represent the first form that meets something beyond itself and changes into something new.
 
 ---
 
-Input Classes meet the outside world and begin their transformation. We'll see this process in [Being Classes]({{ '/manuals/1.0/en/03-being-classes.html' | relative_url }}) ➡️
+The Input Class meets the outside world and begins transformation. We will see that process in [Being Classes](./03-being-classes.html) ➡️
diff --git a/manuals/1.0/en/03-being-classes.md b/manuals/1.0/en/03-being-classes.md
index 1a286d6..fb92f6f 100644
--- a/manuals/1.0/en/03-being-classes.md
+++ b/manuals/1.0/en/03-being-classes.md
@@ -7,19 +7,39 @@ permalink: /manuals/1.0/en/03-being-classes.html
 
 # Being Classes
 
-> "The Tao does nothing, yet nothing is left undone."
-> 
-> —Laozi, Tao Te Ching, Chapter 37 (6th century BC)
+> "The Way constantly does nothing, yet there is nothing it does not do."
+>
+> —Laozi, 'Tao Te Ching', Chapter 37 (6th Century BC)
 
-## Immanence Meets Transcendence
+## Immanence and Transcendence
 
-Being Classes are where transformation actually occurs.
+Being Classes are where metamorphosis actually happens.
 
-The object's own nature (**Immanent Nature**) meets forces provided from the outside (**Transcendent Forces**), and a new being is born.
+The properties that the object itself possesses (**Immanence**) meet the powers provided from the outside (**Transcendence**), and a new Being is born.
 
-For example, a `UserInput` with email and name (immanence) meets an email validation service and formatter (transcendence), creating a "validated user profile" as a new being. The original data remains immutable; by meeting validation—a transcendent force the object doesn't possess—a new being emerges.
+For example, the email address and name (Immanence) held by `UserInput` meet the email validation service or formatter (Transcendence), and a new being called "Validated User Profile" is born. The original data remains unchanged, but through the encounter with the transcendent power of validation that it does not possess, a new existence arises.
 
-If Input Classes are the "beginning," Being Classes express the "moment of change."
+If Input Classes are the "Beginning", Being Classes express the "Moment of Change".
+
+## Objects as Temporal Beings
+
+In Be Framework, objects are not treated as static data structures, but as "Life" living in time.
+
+### Lifecycle: Birth, Life, and "Becoming the self you want to be"
+
+1.  **Birth (Constructor)**:
+    *   The constructor is where objects are born. Here, Immanence and Transcendence meet, and new Immanence is born.
+    *   The moment it is born, the object's identity and state are determined and become Immutable.
+2.  **Life (Being)**:
+    *   The object exposes its "form as it should be" to the world as `public readonly` properties. But no one touches those properties except its future self.
+    *   This state is the crystallization of the encounter between Immanence and Transcendence.
+3.  **Becoming the self you want to be**:
+    *   All transformations are journeys to become the final "Self you want to be (Final Object)".
+    *   The Transcendence encountered influences the new Immanence and disappears. Like a childhood friend, they shape me and become part of me, but as a **temporal being only at that moment**, they are no longer there.
+    *   The life of an object in Be Framework exists for this self-realization (Entelechy).
+
+> "Becoming the self you want to be"
+> Objects are reborn into the self they want to be, according to their own will (type definition). Code is the story of this "Self-realization".
 
 ## Basic Structure
 
@@ -30,36 +50,36 @@ final readonly class UserProfile
     public bool $isValid;
     
     public function __construct(
-        #[Input] string $name,                    // Immanent
-        #[Input] string $email,                   // Immanent
-        #[Inject] NameFormatter $formatter,       // Transcendent
-        #[Inject] EmailValidator $validator       // Transcendent
+        #[Input] string $name,                    // Immanence
+        #[Input] string $email,                   // Immanence
+        #[Inject] NameFormatter $formatter,       // Transcendence
+        #[Inject] EmailValidator $validator       // Transcendence
     ) {
-        $this->displayName = $formatter->format($name);     // New Immanent
-        $this->isValid = $validator->validate($email);      // New Immanent
+        $this->displayName = $formatter->format($name);     // New Immanence
+        $this->isValid = $validator->validate($email);      // New Immanence
     }
 }
 ```
 
-## The Transformation Pattern
+## Metamorphosis Pattern
 
-Every Being Class follows the same flow of transformation:
+All Being Classes follow the same flow of transformation:
 
-**Immanent Nature** (`#[Input]`) + **Transcendent Forces** (`#[Inject]`) → **New Immanent Nature**
+Immanence (`#[Input]`) + Transcendence (`#[Inject]`) → New Immanence
 
-It's like cooking. Ingredients (immanent nature) combined with fire and seasoning (transcendent forces) create a dish (new immanent nature). Flour alone isn't bread; with yeast and an oven's power, it becomes bread. The ingredients persist, yet their form becomes something new.
+It's like cooking. By adding fire and seasoning (Transcendence) to ingredients (Immanence), a dish (New Immanence) is created. Flour alone does not become bread, but with the help of yeast and an oven, it becomes bread. Even if the ingredients are the same, it becomes a completely new existence.
 
-- **Immanent factors**: What the object inherits from its previous form
-- **Transcendent factors**: External capabilities and context provided by the world
-- **New Immanent**: The transformed being that emerges from this interaction
+- **Immanent Factor**: What the object inherits from its previous form
+- **Transcendent Factor**: External capabilities and context provided by the world
+- **New Immanence**: Transformed existence born from this interaction
 
-This pattern appears everywhere in nature. A seed (immanent) meets soil, water, and sunlight (transcendent) to become a flower. A student (immanent) meets teachers and materials (transcendent) to become an expert. All growth, all learning, all change follows this pattern. The Be Framework expresses this universal law of transformation in code.
+This pattern is found everywhere in the natural world. A seed (Immanence) meets soil, water, and sun (Transcendence) to become a flower. A student (Immanence) meets a teacher and textbooks (Transcendence) to become an expert. All growth, all learning, all change follows this pattern. Be Framework expresses this universal law of transformation in code.
 
-The programming world is the same. `$cartItems` (immanent) meets tax calculation services (transcendent) to become billing amounts. `$zipCode` (immanent) meets address lookup APIs (transcendent) to become complete addresses. `$rawImage` (immanent) meets image processing engines (transcendent) to become thumbnails. Data cannot change by itself. Only by borrowing external forces can it become something new.
+It is the same in the world of programming. `$cartItems` (Immanence) meets tax calculation service (Transcendence) to become a billing amount. `$zipCode` (Immanence) meets address search API (Transcendence) to become a complete address. `$rawImage` (Immanence) meets image processing engine (Transcendence) to become a thumbnail. Data cannot change on its own. It borrows external power to finally become a new existence.
 
-## Entelecheia - Becoming Who You're Meant to Be
+## Entelechy - Becoming the self you want to be
 
-The constructor is where a new self is born. To become the intended self, **Immanent Nature** meets **Transcendent Forces** that the self doesn't possess, and transformation logic unfolds.
+The constructor is a special place where a new self is born. To become the self it should be, Immanence meets Transcendence given by the world (which it does not possess itself), and the logic of transformation works.
 
 ```php
 final readonly class OrderCalculation
@@ -69,31 +89,31 @@ final readonly class OrderCalculation
     public Money $total;
     
     public function __construct(
-        #[Input] array $items,                    // Immanent
-        #[Input] string $currency,                // Immanent
-        #[Inject] PriceCalculator $calculator,    // Transcendent
-        #[Inject] TaxService $taxService          // Transcendent
+        #[Input] array $items,                    // Immanence
+        #[Input] string $currency,                // Immanence
+        #[Inject] PriceCalculator $calculator,    // Transcendence
+        #[Inject] TaxService $taxService          // Transcendence
     ) {
         $this->subtotal = $calculator->calculateSubtotal($items, $currency);
         $this->tax = $taxService->calculateTax($this->subtotal);
-        $this->total = $this->subtotal->add($this->tax);     // New Immanent
+        $this->total = $this->subtotal->add($this->tax);     // New Immanence
     }
 }
 ```
 
-1. Properties inherited from previous classes become constructor arguments and meet injected external capabilities.
-2. They interact, and the transformation logic unfolds.
-3. Through property assignment, a new being is born.
+1. Properties inherited from the previous class become constructor arguments and meet injected external capabilities.
+2. They interact, and transformation logic works.
+3. A new existence is born by assigning properties.
 
-Entelecheia (ἐντελέχεια) is a philosophical concept proposed by Aristotle, meaning "having purpose within." An acorn is born to become an oak tree, an egg exists to become a bird. Each harbors its "intended self" within. The egg as potentiality becomes the bird as actuality. In other words, the egg exists for the entelecheia of becoming a bird.
+Entelechy (entelecheia) is a philosophical concept proposed by Aristotle, meaning "having the end within itself". An acorn is born to become an oak tree, and an egg exists to become a bird. Each holds the "self it wants to be" within.
 
-The Be Framework is the same. This constructor transformation process is precisely the realization of entelecheia. `OrderCalculation` wants to become a calculated order. `ValidatedUser` wants to become a verified user. Each class becomes its "intended self" through the constructor. The Be Framework focuses not on actions (DOING) but on being (BEING). Actions are not the purpose—they are the means to become the intended being.
+In Be Framework, this transformation process in the constructor is exactly the realization of Entelechy. `OrderCalculation` wants to become a calculated order. `ValidatedUser` wants to become a validated user. Each class becomes the "self it wants to be" in the constructor. In Be Framework, we think centering on BEING (existence), not DOING (action).
 
-Life is the same. Reading books is to become "a person with deep insight," practicing instruments is to become "a person who moves hearts through music." Actions are means; being is the purpose. Focusing not on "what to do" but "what to become"—the Be Framework expresses this way of thinking in code.
+It's the same in life. You read books to become a "person with deep insight", and practice instruments to become a "person who moves hearts with music". Action is the means, and existence is the purpose. Focusing on "What you want to become" rather than "What you do"—Be Framework expresses this way of thinking in code.
 
-## Bridging to Final Objects
+## Bridge to Final Object
 
-Being Classes often serve as bridges, preparing data for final transformation:
+Being classes often serve as bridges, preparing data for final transformation:
 
 ```php
 #[Be([SuccessfulOrder::class, FailedOrder::class])]  // Multiple destinies
@@ -101,12 +121,12 @@ final readonly class OrderValidation
 {
     public bool $isValid;
     public array $errors;
-    public SuccessfulOrder|FailedOrder $being;  // Being Property
+    public SuccessfulOrder|FailedOrder $being;  // Being property
     
     public function __construct(
-        #[Input] Money $total,                    // Immanent
-        #[Input] CreditCard $card,                // Immanent
-        #[Inject] PaymentGateway $gateway         // Transcendent
+        #[Input] Money $total,                    // Immanence
+        #[Input] CreditCard $card,                // Immanence
+        #[Inject] PaymentGateway $gateway         // Transcendence
     ) {
         $result = $gateway->validate($card, $total);
         $this->isValid = $result->isValid();
@@ -122,8 +142,8 @@ final readonly class OrderValidation
 
 ## Natural Flow
 
-Being Classes don't "do" things. What they possess (immanence) meets forces given from outside (transcendence), naturally transforming into what they should be. This is the same as Laozi's teaching at the beginning: "The Tao does nothing, yet nothing is left undone"—without forcing, everything is accomplished in the natural flow. They don't change other things; they transform themselves.
+Being classes do not "do" anything. By meeting what they have (Immanence) and power given from outside (Transcendence), they naturally transform into the form they should be. This is the same as Laozi's teaching at the beginning, "The Way constantly does nothing, yet there is nothing it does not do"—everything is accomplished in the natural flow without forcing power. It does not change something else, but changes itself.
 
 ---
 
-Where transformation leads, to [Final Objects](./04-final-objects.html) ➡️
+To the destination of transformation, [Final Objects](./04-final-objects.html) ➡️
diff --git a/manuals/1.0/en/04-final-objects.md b/manuals/1.0/en/04-final-objects.md
index 605a792..a6d1c04 100644
--- a/manuals/1.0/en/04-final-objects.md
+++ b/manuals/1.0/en/04-final-objects.md
@@ -7,36 +7,39 @@ permalink: /manuals/1.0/en/04-final-objects.html
 
 # Final Objects
 
-> "You are not me. How can you know that I don't know the feelings of fish?"
-> 
-> —Zhuangzi's reply when asked "You are not a fish. How can you know the feelings of fish?" (Zhuangzi, 4th century BC)
+> "You are not me. How do you know that I do not know the feelings of a fish?"
+>
+> —Zhuangzi's response when asked "You are not a fish. How do you know the feelings of a fish?" ('Zhuangzi', 4th Century BC)
 
 ## The Destination
 
-Final Objects represent the destination of metamorphosis—complete, transformed beings that embody the user's actual interest. These are what the application ultimately cares about.
+Final Objects are the destination of the journey of metamorphosis.
+They are the complete and final existence where the value users seek and the result the application wants to deliver are embodied.
+
+This is the final form achieved after the Immanence that started from the Input Class met various Transcendence and underwent natural metamorphosis. It embodies the Entelechy spoken of by Aristotle—the state where potentiality is completely actualized.
 
 ## Characteristics of Final Objects
 
-**Complete Beings**: Final Objects are fully formed entities that need no further transformation for their intended purpose.
+**Completeness (Entelechy)**: A completely actualized existence that requires no further metamorphosis.
 
-**User-Focused**: They represent what users actually want—successful operations, meaningful data, actionable results.
+**Realization of User Value**: Expresses what the user truly needs, meaningful data, or the successful result of an operation.
 
-**Rich State**: Unlike Input Classes, Final Objects contain the full richness of transformed data.
+**Rich State**: In contrast to Input Classes, Final Objects completely express the richness of the domain.
 
-## Temporal Completeness
+## Completeness of Temporal Being
 
-Here's an intriguing question: What if objects had such completeness that they needed no external testing?
+Here is an interesting question. What if there was an object so complete that it didn't need tests?
 
-The Be Framework captures the temporal existence of objects along two axes:
+In Be Framework, we capture the temporal existence of objects on two axes:
 
-- **`#[Be]`**: The intended self, the destination (future directionality)
-- **`$been`**: The completed self (past perfect self-evidence)
+- **`#[Be]`**: The self you want to become, the destination (Direction towards the future)
+- **`$been`**: The self that has completed (Self-proof of past perfect)
 
-Traditional programming verifies whether objects have been processed correctly through external tests. But what if objects themselves contained evidence of their completion? Instead of external verification, intrinsic self-evidence becomes possible.
+In traditional programming, we verify whether an object has been processed correctly with external tests. But what if the object itself contained the proof of completion? Instead of external verification, immanent self-proof becomes possible.
 
 ## Examples
 
-### Intrinsic Self-Evidence
+### Result with Immanent Self-Proof
 ```php
 final readonly class SuccessfulOrder
 {
@@ -44,20 +47,20 @@ final readonly class SuccessfulOrder
     public string $confirmationCode;
     public DateTimeImmutable $timestamp;
     public string $message;
-    public BeenProcessed $been;          // Self-evidence
+    public BeenProcessed $been;          // Self-proof
     
     public function __construct(
-        #[Input] Money $total,                    // Immanent nature
-        #[Input] CreditCard $card,                // Immanent nature
-        #[Inject] OrderIdGenerator $generator,    // Transcendent force
-        #[Inject] Receipt $receipt                // Transcendent force
+        #[Input] Money $total,                    // Immanence
+        #[Input] CreditCard $card,                // Immanence
+        #[Inject] OrderIdGenerator $generator,    // Transcendence
+        #[Inject] Receipt $receipt                // Transcendence
     ) {
-        $this->orderId = $generator->generate();              // New immanent nature
-        $this->confirmationCode = $receipt->generate($total); // New immanent nature
-        $this->timestamp = new DateTimeImmutable();           // New immanent nature
-        $this->message = "Order confirmed: {$this->orderId}"; // New immanent nature
+        $this->orderId = $generator->generate();              // New Immanence
+        $this->confirmationCode = $receipt->generate($total); // New Immanence
+        $this->timestamp = new DateTimeImmutable();           // New Immanence
+        $this->message = "Order Confirmed: {$this->orderId}"; // New Immanence
         
-        // Self-evidence of completion
+        // Self-proof of completion
         $this->been = new BeenProcessed(
             actor: $card->getHolderName(),
             timestamp: $this->timestamp,
@@ -71,27 +74,27 @@ final readonly class SuccessfulOrder
 }
 ```
 
-This object requires no external testing. The `$been` property contains complete evidence of completion.
+This object does not need external tests. This is because the `$been` property contains complete evidence of completion.
 
-### Error States with Self-Evidence
+### Self-Proof of Error State
 ```php
 final readonly class FailedOrder
 {
     public string $errorCode;
     public string $message;
     public DateTimeImmutable $timestamp;
-    public BeenRejected $been;          // Self-evidence of failure
+    public BeenRejected $been;          // Self-proof of failure
     
     public function __construct(
-        #[Input] array $errors,                   // Immanent nature
-        #[Inject] Logger $logger,                 // Transcendent force
-        #[Inject] ErrorCodeGenerator $generator   // Transcendent force
+        #[Input] array $errors,                   // Immanence
+        #[Inject] Logger $logger,                 // Transcendence
+        #[Inject] ErrorCodeGenerator $generator   // Transcendence
     ) {
         $this->errorCode = $generator->generate();
-        $this->message = "Order failed: " . implode(', ', $errors);
+        $this->message = "Order Failed: " . implode(', ', $errors);
         $this->timestamp = new DateTimeImmutable();
         
-        // Self-evidence of failure
+        // Self-proof of failure
         $this->been = new BeenRejected(
             reason: 'validation_failed',
             timestamp: $this->timestamp,
@@ -107,23 +110,23 @@ final readonly class FailedOrder
 }
 ```
 
-Both success and failure carry their own self-evidence of completion. Instead of external tests, the objects themselves maintain complete records of what occurred.
+Both success and failure have self-proof of completion. Instead of external tests, the object itself holds a complete record of what happened.
 
 ## Final Objects vs Input Classes
 
-| Input Classes | Final Objects |
-|---------------|---------------|
-| Pure identity | Rich, transformed state |
-| Starting point | Destination |
-| What user provides | What user receives |
-| Simple structure | Complete functionality |
+| Input Class | Final Object |
+|-----------|-----------------|
+| Pure Identity | Rich Transformed State |
+| Starting Point of Metamorphosis | Destination of Metamorphosis |
+| What User Provides | What User Receives |
+| Simple Structure | Completely Realized Function |
 
 ## Multiple Final Destinies
 
-Objects can have multiple possible final forms, determined by their nature:
+Objects can have multiple possible final forms determined by their nature:
 
 ```php
-// From OrderValidation's being property:
+// From Being property of OrderValidation:
 public SuccessfulOrder|FailedOrder $being;
 
 // Usage:
@@ -136,24 +139,24 @@ if ($order->being instanceof SuccessfulOrder) {
 }
 ```
 
-## The Journey Complete
+## A Completed Journey
 
-The path from Input to Final Object represents a complete transformation journey:
+The path from Input to Final Object represents a complete journey of metamorphosis:
 
-1. **Input Class**: Pure identity ("Here's what I am")
-2. **Being Classes**: Transformation stages ("Here's how I change")  
-3. **Final Object**: Complete result ("Here's what I became")
+1. **Input Class**: Pure Identity ("This is me")
+2. **Being Class**: Stage of Metamorphosis ("This is how I change")
+3. **Final Object**: Complete Result ("This is what I have become")
 
-Users primarily care about Input (what they provide) and Final Objects (what they get back). The Being Classes in between are our responsibility as designers. It's crucial to understand the temporal transformation of the domain well and design the mechanisms of that transformation to bridge intention and result.
+Users are primarily interested in Input (what they provide) and Final Object (what they receive). The Being Class in between is our responsibility as designers. To bridge the gap between intention and result, it is important to understand the temporal metamorphosis of the domain well and design the mechanism of that metamorphosis.
 
-## Transformation Complete
+## Completion of Metamorphosis
 
-Final Objects express the state of entelecheia (complete realization). They are fully realized beings that no longer need transformation.
+The Final Object expresses the state of Entelechy (Full Realization). It is a completely realized existence that no longer needs metamorphosis.
 
-The immanent nature that began with Input Classes, through encounters with various transcendent forces and natural transformation, finally reaches this completed form. There is no more "trying to become" or "intending to change." Everything is complete, and the value that users truly sought is realized here. This is the essential value of our system.
+It is the completed form reached after the Immanence started from the Input Class met various Transcendence and underwent natural metamorphosis. Here, there is no longer any effort to "try to become" or intention to "try to change". Everything is complete, and the value the user truly sought is realized here. This is the essential value of our system.
 
-This is the destination that Be Framework aims for in programming—existence that embodies not "what to do" but "what to be."
+This is exactly the destination of programming that Be Framework aims for—an existence that embodies "What It Is" rather than "What To Do".
 
 ---
 
-There's not just one path. Learn the various paths in [Metamorphosis](./05-metamorphosis.html) ➡️
+There is not just one way. Learn various paths in [Metamorphosis](./05-metamorphosis-patterns.html) ➡️
diff --git a/manuals/1.0/en/12-philosophy-behind.md b/manuals/1.0/en/12-philosophy-behind.md
index 75a635a..453cecb 100644
--- a/manuals/1.0/en/12-philosophy-behind.md
+++ b/manuals/1.0/en/12-philosophy-behind.md
@@ -1,153 +1,411 @@
 ---
 layout: docs-en
-title: "12. The Philosophy Behind"
+title: "12. Philosophy Behind"
 category: Manual
 permalink: /manuals/1.0/en/12-philosophy-behind.html
 ---
 
-# The Philosophy Behind
+# Philosophy Behind
 
-Now that you understand how Be Framework works in practice, let's explore the deep philosophical principles that make it possible.
+> "Everything flows" (Panta Rhei)
+> —Heraclitus (535-475 BC)
 
-## Wu Wei: The Art of Non-Doing
+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.
 
-**Wu Wei (無為)** is the ancient Chinese principle of "actionless action"—achieving through being rather than forcing through doing.
+## 1. Ontological Programming: Discovery of "WHETHER?"
 
-In Be Framework, this manifests as:
+### Why Ontology?
+
+Traditional programming has answered two questions:
+
+- **"What to do?" (WHAT?)** - Functions and algorithms
+- **"How to do it?" (HOW?)** - Implementation and performance
+
+However, the most fundamental question has been overlooked:
+
+- **"Can it exist in the first place?" (WHETHER?)**
+
+Ontological Programming asks this "WHETHER?" first. Can an invalid email address exist as `$email`? Can a negative age be born as `$age`?
 
 ```php
-// Not this (imperative doing):
-$validator->validate($email);
-$formatter->format($name);
-$user->save();
-
-// But this (natural becoming):
-$user = $becoming(new UserInput($email, $name));
-// The user simply becomes what it's meant to be
+// 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
+    ) {}
+}
+
+// Answer: If conditions are met, it exists as ValidatedUser
 ```
 
-Objects don't "do" anything—they **become** what they are through natural transformation. Like water flowing downhill, the path emerges from the nature of things, not from external commands.
+**Traditional**: "Validate this data" (Imperative)
+**Ontological**: "Can this data exist?" (Ontological inquiry)
+
+### Human Role in the AI Era
+
+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
 
-## Immanent and Transcendent: The Dance of Existence
+## 2. Temporal Being: Expressing Heidegger's "Dasein" in Code
 
-These terms come from philosophy, describing how beings come into meaningful existence:
+### Being Thrown into Time
 
-**Immanent**: What something already is—its inherent nature, identity, essence. The "self" that persists through change.
+Heidegger described humans as beings with **Thrownness (Geworfenheit)**. We start from conditions we cannot choose, and build our existence from there.
 
-**Transcendent**: What comes from beyond the self—context, capabilities, meaning provided by the world.
+Be Framework objects have a similar structure:
 
 ```php
-// Philosophical example in code:
-final readonly class Greeting
+// Thrownness: Unchooseable initial conditions
+#[Be(UserProfile::class)]
+final readonly class UserInput     // Thrown existence
+{
+    public function __construct(
+        public string $name,     // Given condition
+        public string $email     // Given situation
+    ) {}
+}
+
+// Projection: Possibility towards the future
+final readonly class UserProfile   // Projection into possibility
 {
     public function __construct(
-        #[Input] string $name,                // Immanent: who you are
-        #[Inject] CultureService $culture     // Transcendent: how the world greets
+        #[Input] string $name,                    // Thrown past
+        #[Input] string $email,
+        #[Inject] NameFormatter $formatter        // Encounter with the world
     ) {
-        $this->message = $culture->formatGreeting($name);  // New being emerges
+        $this->displayName = $formatter->format($name);  // New existence
     }
+    
+    public string $displayName;
 }
 ```
 
-This mirrors how humans become who they are—not through internal properties alone, but through encountering others, culture, and world beyond themselves.
+### Objects as Dasein
 
-## BE = Be, Everything
+Heidegger's **Dasein** means "being there", an existence that understands itself within time. Be Framework objects possess exactly this Dasein-like character:
 
-**BE** represents the universal scope of this principle:
+- **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)
 
-- **Be**: Focus on existence, not action
-- **Everything**: This principle applies to all programming domains
-
-Whether you're processing:
-- Database records → Domain objects
-- HTTP requests → API responses  
-- User input → Validated commands
-- Raw data → Business insights
+```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);
+    }
+}
+```
 
-The pattern remains the same: **Immanent + Transcendent → New Immanent**
+## 3. The Tao and Wu Wei: Realizing Laozi's Philosophy in Programming
 
-## Ontological Programming
+### Principle of Wu Wei (Non-doing)
 
-**Ontology** is the philosophical study of existence—what it means for something "to be."
+Laozi said: "The Way constantly does nothing, yet there is nothing it does not do."
 
-Ontological Programming asks: **"What can exist?"** rather than **"What should happen?"**
+This does not mean "doing nothing". It means following the natural flow, without forcing things, acting in accordance with the true nature of things.
 
 ```php
-// Traditional: "How do I validate this email?"
-if ($email->isValid()) {
-    $user = new User($email);
-    $user->save();
+// 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
+    }
 }
 
-// Ontological: "What exists when email meets validation?"
-#[Be(ValidatedUser::class)]
-final readonly class EmailInput { /* ... */ }
+// Not this (Yu Wei / Action: Forced execution):
+// $gateway->validateCard($order->card);
+// $gateway->chargeAmount($order->amount);  
+// $gateway->sendConfirmation($order->email);
+```
+
+### Code Flowing Like Water
+
+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.
+
+Be Framework objects flow like water:
 
-final readonly class ValidatedUser { /* ... */ }  // This simply exists or doesn't
+- **Do not contend**: No external control, metamorphosis by self-determination
+- **Low places**: Simple structure, avoiding complexity
+- **Nourish all things**: Enabling metamorphosis of other objects
+
+```php
+// Natural flow like water
+$result = $becoming(new ApplicationInput($data));
+
+// The object itself knows the next form (like water flowing to low places)
+// No external orchestrator needed
 ```
 
-We design by declaring what forms of existence are possible, then let objects naturally become those forms.
+## 4. Entelechy: Aristotle's Full Realization
+
+### Transition from Potentiality to Actuality
+
+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.
+
+```php
+// Entelechy: Full realization of potentiality
+final readonly class MatureUser     // Fully realized existence
+{
+    public function __construct(
+        #[Input] UserData $potentiality,         // Potentiality
+        #[Inject] ValidationService $actuator    // Power of actualization
+    ) {
+        // Entelechy: Moment when potentiality transitions to actuality
+        $this->actualizedProfile = $actuator->actualize($potentiality);
+    }
+    
+    public UserProfile $actualizedProfile;  // Actualized existence
+}
+```
 
-## Subject-Object Unity
+### Constructor as the Stage of Metamorphosis
 
-In traditional programming, there's always a "controller" that commands objects. In Be Framework, **objects are their own subjects**—they determine their own transformation.
+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
-// The object decides its own destiny
-public SuccessfulPayment|FailedPayment $being;
+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
+
+### Everything Has a Reason for Existence
+
+Leibniz's **Principle of Sufficient Reason (Principium rationis sufficientis)** states that "for everything, there is a sufficient reason why it exists".
+
+In Be Framework, this philosophy is realized as the **Reason Layer**:
 
-public function __construct(/* ... */) {
-    $this->being = $this->isValid 
-        ? new SuccessfulPayment(/* ... */)
-        : new FailedPayment(/* ... */);  // Self-determination
+```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);
+    }
 }
 ```
 
-No external orchestrator tells the object what to become. The transformation emerges from the object's own nature meeting the world's capabilities.
+### Raison d'être
+
+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
+
+Each existence has a sufficient reason that enables that existence.
 
-## Temporal Being
+## 6. Immanence and Transcendence: Spinoza's Dual Aspects
 
-Objects in Be Framework exist **in time**—they have memory of their past (Immanent) and knowledge of their potential futures (Being Property with union types).
+### Immanent Nature and Transcendent Power
+
+Spinoza perceived reality as two aspects of one substance: **Immanence** and **Transcendence**.
 
 ```php
 final readonly class UserProfile
 {
-    // Memory of past
-    #[Input] string $originalEmail;
-    
-    // Present being  
-    public string $displayName;
+    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
+    ) {
+        // 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
+    }
+}
+```
+
+### Eternal Formula of Metamorphosis
+
+All Being Classes possess the same philosophical structure:
+
+**Immanence** + **Transcendence** → **New Immanence**
+
+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.
+
+## 7. Zhuangzi's Relativity: Accepting Multiple Destinies
+
+### Philosophy of Equality of All Things
+
+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.
+
+Type-Driven Metamorphosis embodies this philosophy:
+
+```php
+#[Be([Success::class, Failure::class])]  // Success and Failure are equivalent possibilities
+final readonly class PaymentAttempt
+{
+    public Success|Failure $being;  // Both are valid existences
     
-    // Potential futures
-    public ActiveUser|SuspendedUser $being;
+    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
+    }
 }
 ```
 
-This creates **temporal awareness**—objects understand their place in the flow of transformation.
+## 8. Heraclitean Flux: Perpetual Change
 
-## The Beauty of Natural Law
+### "Everything Flows"
 
-Just as physics describes how matter naturally transforms under different forces, Be Framework describes how data naturally transforms through constructor injection.
+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.
 
-The laws are simple:
-1. **Immutable existence**: Each stage is complete and unchanging
-2. **Constructor metamorphosis**: All transformation happens at the moment of becoming
-3. **Self-determination**: Objects choose their own destiny based on their nature
-4. **Transparent state**: Everything is public and readable
+Metamorphosis expresses this perpetual change:
 
-These simple laws create infinite possibility for complex, natural transformation—just like how simple physical laws create the infinite complexity of the universe.
+```php
+// Time T0: Primal existence
+#[Be(EmailValidation::class)]
+final readonly class EmailInput { /* ... */ }
 
----
+// Time T1: First Metamorphosis (T0 is already past)
+#[Be(UserCreation::class)]  
+final readonly class EmailValidation { /* ... */ }
+
+// Time T2: Final Existence (encompassing all past)
+final readonly class UserCreation { /* ... */ }
+```
+
+Each moment never returns, and objects naturally transform within the flow of time.
+
+### Unity of Opposites
+
+Heraclitus also preached the "Unity of Opposites". Day and night, life and death, up and down—opposites are actually different aspects of one reality.
+
+```php
+// Unity of Opposites: Activation and Deactivation are two sides of the same reality
+public ActiveUser|InactiveUser $being;
+```
+
+## 9. Buddhist Dependent Origination: Interdependent Existence
 
-*"Be Framework is not just a way to write code—it's a way to think about existence, transformation, and the natural flow of becoming in digital realms."*
+### Non-Self and Dependent Origination
 
-## The Paradigm Shift
+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.
+
+Be Framework objects are exactly this Dependent Origination existence:
+
+```php
+final readonly class UserProfile    // Existence of Dependent Origination
+{
+    public function __construct(
+        #[Input] string $name,              // Dependent on other existence
+        #[Inject] DatabaseConnection $db,   // Dependent on relationship with outside
+        #[Inject] ValidationService $validator  // Interdependent with service
+    ) {
+        // New existence appears from interdependent relationships
+    }
+}
+```
+
+### Implementation of Non-Self (Anātman)
+
+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)
+
+## 10. Integration of Programming Philosophy
+
+### Wisdom of East and West
+
+Be Framework integrates Eastern and Western philosophical traditions:
+
+**Eastern Wisdom**:
+- **Taoism**: Flow of Wu Wei / Non-doing
+- **Buddhism**: Dependent Origination and Non-Self, Impermanence
+- **Zhuangzi**: Acceptance of relativity and metamorphosis
+
+**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
+
+When these ancient wisdoms are realized in modern programming, a new **Computational Philosophy** is born:
+
+- **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
+
+## 11. Prospect for the Future: Next Evolution of Programming
+
+### Evolution of Paradigm
+
+Looking at the evolution of programming paradigms, we are gradually approaching the principles of nature:
+
+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
+
+In an era where AI can optimize "How to do", human uniqueness lies in the ability to decide "What should exist, what has meaning".
+
+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
+
+### 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.
+
+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"
+
+---
 
-Understanding this philosophy changes how you approach programming:
+> **"Where the river flows, there is the way."**
+> —Modern interpretation of Laozi
 
-- From **commanding** objects → **creating conditions** for becoming
-- From **managing state** → **enabling natural transformation**  
-- From **controlling flow** → **declaring possibilities**
-- From **doing** → **being**
+Be Framework is where ancient wisdom meets modern technology. Here, code becomes philosophy, programming becomes ontology, and engineers become modern philosophers.
 
-This is the essence of **Ontological Programming**—programming that aligns with the natural principles of existence and transformation.
+Objects flow naturally, transform, and become what they should be—this is the new possibility of programming embodied by Be Framework.
diff --git a/manuals/1.0/en/13-vision-ldd.md b/manuals/1.0/en/13-vision-ldd.md
new file mode 100644
index 0000000..1f64922
--- /dev/null
+++ b/manuals/1.0/en/13-vision-ldd.md
@@ -0,0 +1,74 @@
+---
+layout: docs-en
+title: "13. Log-Driven Development"
+category: Manual
+permalink: /manuals/1.0/en/13-vision-ldd.html
+---
+
+# Log-Driven Development (LDD)
+
+> "Once Zhuang Zhou dreamt he was a butterfly... Suddenly he awoke and there he was, solid and unmistakable Zhuang Zhou. But he didn't know if he was Zhuang Zhou who had dreamt he was a butterfly, or a butterfly dreaming he was Zhuang Zhou."
+> —Zhuangzi, 'The Adjustment of Controversies' (Qi Wu Lun) (Circa 4th Century BC)
+
+> **Note**: This chapter describes the "Future Vision" that Be Framework aims for. Not everything is implemented in the current version.
+
+## Ultimate Transparency
+
+Be Framework aims for a world where there is ultimate transparency in all layers—code, execution, log, and specification—and also where the boundaries between them become ambiguous.
+
+### Reversibility Brought by Three Transparencies
+
+The one-way flow of writing code from specifications, executing it, and outputting logs is the natural order of things (standard). However, Be Framework seeks to explore the possibility of complete "Reversibility" through the following three transparencies:
+
+1.  **Structural Transparency**:
+    *   The `#[Be]` attribute explicitly manifests the flow of metamorphosis as the structure of the code itself. This allows drawing the entire specific Decision Graph of the application just by static analysis.
+2.  **Semantic Transparency**:
+    *   Variable names are not just labels, but contracts. A name like `$email` encompasses validation by the `Email` class and philosophical definitions (like ALPS). This lets you understand the "meaning" and "guarantee" of the data just by looking at the variable name.
+3.  **Execution Transparency**:
+    *   Semantic logs are not merely "transit records" but record the entire basis of judgment "why that decision was reached".
+
+## Infinite Loop of Value
+
+This transparency enables the "Elimination of Guesswork" by AI.
+
+1.  **Log**: Humans (or AI) write the "story that should be" as a log.
+2.  **AI Construction**: AI assembles code not by guesswork but as "work" from that log, relying on structural and semantic transparency.
+3.  **Code**: The generated code becomes the definition of Temporal Being.
+4.  **Execution**: The code is executed, and a log according to the contract is output.
+5.  **Verification**: Confirm that the output log matches the original story (Log) through execution transparency.
+
+Through this cycle, a world where "Dream (Log)" and "Reality (Code)" are mutually and continuously converted is completed.
+
+## Log-Driven Development (LDD)
+
+The new development method brought about by this reversibility is **Log-Driven Development (LDD)**.
+
+### "Code ⇔ Log ⇔ Specification"
+
+Just as TDD (Test-Driven Development) defines "Behavior (Doing)" and then implements it, LDD defines "Story (Log)" and then generates Existence (Code/Being).
+
+1.  **Narrative First**: Developers first write the "Semantic Log that should be". This is the "story" the system should trace, and is itself the DSL (Domain Specific Language) defining the application.
+    ```yaml
+    UserRegistration:
+      - Input: {email: "New User", ...}
+        Becomes: ValidatedUser
+      - ValidatedUser:
+        Becomes: RegisteredUser
+    ```
+2.  **Specification Generation**: "Specifications (what state transitions are required)" are derived from the log.
+3.  **Code Generation**: From the specifications, `#[Be]` chains and class definitions to realize them are automatically generated.
+
+### Future Debugging
+
+In a world where ultimate transparency is realized, debugging becomes synonymous with "reading logs". Non-reproducible bugs do not exist. This is because the log is a complete "executable specification", and just by pouring that log in, the system can Reproduce (Replay) exactly the same metamorphosis process.
+
+## Conclusion: Code as Philosophy
+
+The "Butterfly Dream" at the beginning is an anecdote of the ancient Chinese thinker Zhuangzi.
+
+> He dreamt he was a butterfly, fluttering about... suddenly he awoke... but he didn't know if he was Zhuang Zhou who had dreamt he was a butterfly, or a butterfly dreaming he was Zhuang Zhou.
+
+Digital reality where logs can become code in LDD is exactly this Butterfly Dream, and Be Framework's complete transparency makes the boundary of meaning between log and code ambiguous. Thought becomes word, word becomes code, and code becomes story.
+
+Programming in Be Framework is not merely ordering a computer.
+It is an act of defining "Temporal Being" in digital space acting like life, and letting its metamorphosis spin out a meaningful story (Log).
diff --git a/manuals/1.0/ja/01-overview.md b/manuals/1.0/ja/01-overview.md
index dc6c199..ce1be43 100644
--- a/manuals/1.0/ja/01-overview.md
+++ b/manuals/1.0/ja/01-overview.md
@@ -7,11 +7,15 @@ permalink: /manuals/1.0/ja/01-overview.html
 
 # 概要
 
-> 「真の発見の航海は、新しい風景を求めることではなく、新しい目を持つことにある。」
+> 「なりたい自分になる (Becoming the self you want to be)」
+> Be Frameworkとは、オブジェクトが自らの意思で、なりたい自分へと変容するためのフレームワークです。
+
+マルセル・プルーストは言いました。
+> 真の航海とは、新しい風景を探すことではなく、新しい目を持つことである。
 > 
 > 　　—マルセル・プルースト『囚われの女』（À la recherche du temps perdu 第5巻）1923年
 
-## 新しい考え方
+## DoingからBeingへ
 
 まず、これを見てください
 
@@ -27,18 +31,18 @@ $deletedUser = new DeletedUser($activeUser);
 
 「`DeletedUser`」って何？と思いましたか？
 
-実はこの疑問が、プログラミングの新しい世界への入り口なんです。これまで**考えてもみなかった方法**で、プログラミングを考えてみましょう。
+実はこの疑問が、プログラミングの新しい世界への入り口です。これまで考えてもみなかった方法で、プログラミングを考えてみましょう。
 
 ## 『何をするか』から『何であるか』へ
 
-従来のプログラミングは**DOING（何をするか）**に着目します：
+従来のプログラミングはDOING（何をするか）に着目します：
 ```php
 $user->validate();
 $user->save();
 $user->notify();
 ```
 
-Beフレームワークは**BEING（何であるか）**に着目します：
+BeフレームワークはBEING（何であるか）に着目します：
 ```php
 $rawData = new UserInput($_POST);
 $validatedUser = new ValidatedUser($rawData);
@@ -50,12 +54,12 @@ $savedUser = new SavedUser($validatedUser);
 
 ## なぜこれが重要なのか
 
-**DOING**に着目すると：
+DOINGに着目すると：
 - 実行前に「このアクションは可能か？」を毎回チェックする必要があります
 - 様々なエラーケースに対処しなければなりません
 - 不正な状態を防ぐための処理が常に必要です
 
-**BEING**に着目すると：
+BEINGに着目すると：
 - 不正な状態のオブジェクトは最初から存在しません
 - オブジェクトが存在すること自体が「正しい状態」の証明になります
 - その時にできることだけに集中できます。できないことはそもそも実行できません
@@ -73,14 +77,28 @@ function archiveUser(DeletedUser $user) { }
 
 各型はただのデータではなく、オブジェクトの特定の状態を表現しています。つまり、オブジェクトの時間的な変化が型で表されていて、その時に可能なことだけが行えます。例えば、存在しないオブジェクトに削除を命じることはできません。
 
+## なぜ「コントローラー」ではないのか？ (Wu Wei / 無為自然)
+
+従来のMVCフレームワークにおける「コントローラー (Controller)」は、その名の通り「制御・支配」を目的としています。 しかし、システムが複雑になるにつれて、この「全てを支配しようとするアプローチ」は困難になります。
+
+コントローラーは全てのモデルやコンポーネントに無制限にアクセスできる「全能の自由」を持っていますが、制約がないということは、逆に言えばシステム内のあらゆる手続きについて、自分自身で制御し整合性を保つという「無限の責任」を負うことを意味します。
+
+Be Frameworkは、東洋哲学の「無為自然 (Wu Wei)」の思想を取り入れた異なるアプローチを採ります。 操作が目的のデータをつくり出すのではなく、種子のような単純な入力オブジェクトが他のオブジェクトと出会い、自然に成長し、目的の最終オブジェクトへと「自ら変容（Metamorphosis）」していきます。
+
+### Commander (司令官) から Gardener (庭師) へ:
+* 司令官は、部下（オブジェクト）に「動け」と命令します。しかし、複雑な自律的な動きを全て命令し続けることは不可能です。
+* 庭師は、植物に命令しません。ただ、水や光という環境を整えるだけです。
+
+植物は、自らの変容のみに関心を持ちます。他者を変えようとするのではなく、環境を受け入れて自らを自律的に変容（Metamorphosis）させ、在るべき姿に成ります。Beフレームワークも最初に入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。
+
 ## このマニュアルで学べること
 
 以下の新しいプログラミング手法を身につけることができます：
 
-1. **「何をするか」ではなく「何であるか」を設計する**
-2. **不正な状態をチェックするのではなく、最初から作れないようにする**
-3. **オブジェクトを無理に変更するのではなく、自然な変容（自己変容）を表現する**
-4. **エラーを防ぐのではなく、正しい状態を信頼する**
+1. 「何をするか」ではなく「何であるか」を設計する
+2. 不正な状態をチェックするのではなく、最初から作れないようにする
+3. オブジェクトを無理に変更するのではなく、自然な変容（自己変容）を表現する
+4. エラーを防ぐのではなく、正しい状態を信頼する
 
 ## さあ、始めましょう
 
diff --git a/manuals/1.0/ja/03-being-classes.md b/manuals/1.0/ja/03-being-classes.md
index 80dab3c..be1524e 100644
--- a/manuals/1.0/ja/03-being-classes.md
+++ b/manuals/1.0/ja/03-being-classes.md
@@ -15,12 +15,32 @@ permalink: /manuals/1.0/ja/03-being-classes.html
 
 存在クラスは変容が実際に起こる場所です。
 
-オブジェクト自身が持つ性質（**内在的性質（イマナンス）**）と、外部から提供される力（**超越的な力（トランセンデンス）**）が出会い、次の新しい存在が生まれます。
+オブジェクト自身が持つ性質（内在的性質（イマナンス））と、外部から提供される力（超越的な力（トランセンデンス））が出会い、次の新しい存在が生まれます。
 
 例えば、`UserInput`が持つメールアドレスと名前（イマナンス）が、メール検証サービスやフォーマッター（トランセンデンス）と出会うことで、「検証済みのユーザープロフィール」という新しい存在が生まれます。元のデータは不変のまま、検証という自分にはない超越的な力との出会いを通じて、新しい存在が立ち上がります。
 
 入力クラスが「始まり」なら、存在クラスは「変わる瞬間」を表現します。
 
+## 時間的存在としてのオブジェクト (Temporal Being)
+
+Be Frameworkにおいて、オブジェクトは静的なデータ構造ではなく、時間の中を生きる「生命」として扱われます。
+
+### ライフサイクル：誕生、生、そして「なりたい自分になる」
+
+1.  **誕生 (Birth/Constructor)**:
+    *   コンストラクタは、オブジェクトが生まれる場所です。ここで内在と超越が出会い、新しい内在が生まれます。
+    *   生まれた瞬間、そのオブジェクトのアイデンティティと状態は確定し、不変（Immutable）となります。
+2.  **生 (Life/Being)**:
+    *   オブジェクトは `public readonly` プロパティとして、その「あるべき姿」を世界に晒します。しかしそのプロパティを触るものは未来の自分以外いません。
+    *   この状態は、内在と超越の出会いが結晶化したものです。
+3.  **なりたい自分になる (Becoming the self you want to be)**:
+    *   すべての変容は、最終的な「なりたい自分（Final Object）」になるための旅です。
+    *   出会った超越は、新しい内在（Immanence）に影響を与えて消滅します。幼少期の友人のように、私を形作り私の一部にはなりますが、その時だけの時間的存在として、もうそこにはいないのです。
+    *   Be Frameworkにおけるオブジェクトの生涯は、この自己実現（Entelechy）のためにあります。
+
+> "Becoming the self you want to be"
+> オブジェクトは、自らの意思（型定義）に従って、なりたい自分へと生まれ変わります。コードはこの「自己実現」の物語です。
+
 ## 基本構造
 
 ```php
@@ -45,7 +65,7 @@ final readonly class UserProfile
 
 すべての存在クラスは同じ変容の流れに従います：
 
-**内在的性質** (`#[Input]`) + **超越的力** (`#[Inject]`) → **新しい内在的性質**
+内在的性質 (`#[Input]`) + 超越的力 (`#[Inject]`) → 新しい内在的性質
 
 まるで料理のようです。素材（内在的性質）に、火や調味料（超越的力）を加えることで、料理（新しい内在的性質）が生まれます。小麦粉はそれだけではパンになりませんが、イーストとオーブンの力を借りてパンになります。素材は同じでも、まったく新しい存在になるのです。
 
diff --git a/manuals/1.0/ja/04-final-objects.md b/manuals/1.0/ja/04-final-objects.md
index a1617fe..25e602f 100644
--- a/manuals/1.0/ja/04-final-objects.md
+++ b/manuals/1.0/ja/04-final-objects.md
@@ -159,4 +159,4 @@ if ($order->being instanceof SuccessfulOrder) {
 
 ---
 
-道は１つではありません。[変容](./05-metamorphosis.html)で様々な道を学びます ➡️
+道は１つではありません。[変容](./05-metamorphosis-patterns.html)で様々な道を学びます ➡️
diff --git a/manuals/1.0/ja/07-type-driven-metamorphosis.md b/manuals/1.0/ja/07-type-driven-metamorphosis.md
index eedaff8..7b562d1 100644
--- a/manuals/1.0/ja/07-type-driven-metamorphosis.md
+++ b/manuals/1.0/ja/07-type-driven-metamorphosis.md
@@ -107,7 +107,23 @@ final readonly class ComplexDecision
 
 確定できるものは型で決定し、不確定なものは専門家に委譲する意思決定システムです。
 
-## 制御構造の排除
+## 運命の地図としての型 (Destiny Map)
+
+Type-Driven Metamorphosis（型駆動変容）において、Union型 (`Success|Failure`) は単なる「複数の型の可能性」ではありません。それはオブジェクトの「運命の地図」です。
+
+### 実存的問い (Existential Question)
+
+従来のプログラミングでは、外部のコントローラーが `if` 文を使って「もしAなら、こっちに行け」と命令（Routing）していました。
+Be Frameworkでは、この主従関係が逆転します。オブジェクト自身がコンストラクタ内で**「私は誰なのか？（Who am I?）」**という実存の問いに向き合います。
+
+*   **Destiny (運命)**: `public readonly Success|Failure $being`
+  *   このプロパティ定義は、「私の未来はこの2つのどちらかである」という予言です。
+*   **Self-Discovery (自己発見)**: `$this->being = ...`
+  *   コンストラクタの中で、自身のデータ（Immanence）と環境（Inject）を照らし合わせ、自分が何者になったのかを発見します。
+
+「制御（Routing）」を捨てて「自己発見（Discovery）」に委ねることで、コードから条件分岐の複雑さが消え去り、あるのは純粋な「存在の定義」だけになります。
+
+## 条件分岐の排除
 
 Be Frameworkは従来の"メソッドの中にある複雑な制御構造"を排除します。フレームワークは`#[Be]`で宣言された流れに従い、型マッチングで次のクラスを選択します。
 
diff --git a/manuals/1.0/ja/13-vision-ldd.md b/manuals/1.0/ja/13-vision-ldd.md
new file mode 100644
index 0000000..b70650d
--- /dev/null
+++ b/manuals/1.0/ja/13-vision-ldd.md
@@ -0,0 +1,77 @@
+---
+layout: docs-ja
+title: "13. ログ駆動開発"
+category: Manual
+permalink: /manuals/1.0/ja/13-vision-ldd.html
+---
+
+
+---
+
+# ログ駆動開発 (LDD)
+
+> 「かつて荘周は夢で胡蝶となった。（中略）はたして周が夢で胡蝶となったのか、それとも胡蝶が夢で周となっているのか。」
+> 　　—荘子『斉物論』（紀元前4世紀頃）
+
+> **注意**: 本章はBe Frameworkが目指す「未来のビジョン」を記述したものです。現在のバージョンではすべてが実装されているわけではありません。
+
+## 究極の透明性
+
+Be Frameworkが目指すのは、コード、実行、ログ、仕様の全てにおいて究極の透明性があり、またその境界が曖昧になる世界です。
+
+### 3つの透明性がもたらす可逆性
+
+仕様書からコードを書き、実行してログが出力されるという一方通行の流れは当たり前のものです。しかし、Be Frameworkは以下の3つの透明性によって、完全な「可逆性（Reversibility）」の可能性を探ろうとしています。
+
+1.  **構造的透明性 (Structural Transparency)**:
+  *   `#[Be]` 属性によって、変容のフローがコードの構造そのものとして明示されています。これにより、静的解析だけでアプリケーションの全遷移図（Decision Graph）を描くことが可能です。
+2.  **意味的透明性 (Semantic Transparency)**:
+  *   変数名は単なるラベルではなく、契約です。`$email` という名前は `Email` クラスによる検証と思想的な定義（ALPSなど）を内包しています。これにより、変数名を見るだけでそのデータの「意味」と「保証」が分かります。
+3.  **実行透明性 (Execution Transparency)**:
+  *   セマンティックログは、単なる「通過記録」ではなく、「なぜその決定に至ったか」という判断の根拠を全て記録します。
+
+## 価値の無限ループ
+
+この透明性が、AIによる「推測の排除」を実現します。
+
+1.  **Log**: 人間（またはAI）が「あるべき物語」をログとして記述する。
+2.  **AI Construction**: AIはそのログから、構造的・意味的透明性を頼りに、推測ではなく「作業」としてコードを組み立てる。
+3.  **Code**: 生成されたコードは、時間的存在（Temporal Being）の定義になる。
+4.  **Execution**: コードが実行され、契約通りのログが出力される。
+5.  **Verification**: 出力されたログと、最初の物語（Log）が一致することを、実行透明性によって確認する。
+
+このサイクルにより、「夢（Log）」と「現実（Code）」が相互に変換され続ける世界が完成します。
+
+## Log-Driven Development (LDD)
+
+この可逆性がもたらす新しい開発手法が、**Log-Driven Development (LDD)** です。
+
+### "Code ⇔ Log ⇔ Specification"
+
+TDD（テスト駆動開発）が「振る舞い（Doing）」を定義してから実装するように、LDDでは「物語（Log）」を定義してから実存（Code/Being）を生成します。
+
+1.  **Narrative First**: 開発者はまず、「あるべき実行ログ（Semantic Log）」を書きます。これはシステムが辿るべき「物語」であり、アプリケーションを定義するDSL（ドメイン固有言語）そのものです。
+    ```yaml
+    UserRegistration:
+      - Input: {email: "New User", ...}
+        Becomes: ValidatedUser
+      - ValidatedUser:
+        Becomes: RegisteredUser
+    ```
+2.  **Specification Generation**: ログから「仕様（どのような状態遷移が必要か）」が導き出されます。
+3.  **Code Generation**: 仕様から、それを実現するための `#[Be]` チェーンとクラス定義が自動生成されます。
+
+### 未来のデバッグ
+
+究極の透明性が実現された世界では、デバッグは「ログを読む」ことと同義になります。再現不可能なバグは存在しません。なぜなら、ログが完全な「実行可能な仕様書」となっており、そのログを流し込むだけで、システムは全く同じ変容プロセスを再現（Replay）できるからです。
+
+## 結論: Code as Philosophy
+
+冒頭の「胡蝶の夢」は古代の中国の思想家の荘子の逸話です。
+
+> 夢の中で胡蝶（蝶のこと）としてひらひらと飛んでいた所、目が覚めたが、はたして自分は蝶になった夢をみていたのか、それとも実は夢でみた蝶こそが本来の自分であって今の自分は蝶が見ている夢なのか
+
+LDDでログがコードになりえるのはまさにこの胡蝶の夢で、Be Frameworkの完全な透明性が、ログとコードの意味の境界を曖昧にします。意味的ログはいわば、アプリケーション実行のDSLです。その時、思想が言葉になり、言葉がコードになり、コードが物語になる。
+
+Be Frameworkにおけるプログラミングは、単にコンピュータに命令することではありません。
+それはまるで生命のようなデジタル空間における「時間的存在」を定義し、その変容の意味が物語（Log）を紡ぎ出させる行為なのです。