Integrate concept philosophy into manuals

.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:

_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 %}"

_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 %}"

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".

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) ➡️