style(docs): markdownlintエラーを一括修正

- MD025: セクション見出し(# N.)をH2(##)に降格（160箇所）
- MD040: コードブロックに言語識別子を追加（typescript/bash/text/json等）
- MD036: 哲学的引用をブロッククォートに、ラベルをH3見出しに変換
- MD024: 無効化（各フックの繰り返しサブセクションは意図的設計）
- MD022/MD032等: 空行・リストスタイルを自動修正

Co-Authored-By: Claude <assistant> <noreply@anthropic.com>

Author: yunbow

.markdownlint-cli2.jsonc

@@ -2,6 +2,7 @@
   "config": {
     "MD001": false,
     "MD013": false,
+    "MD024": false,
     "MD033": false,
     "MD041": false
   }

01_philosophy/anti-patterns.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Anti-Patterns
 
 This defines repeatedly observed "do not do this" patterns.

01_philosophy/mental-models.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Mental Models
 
 This defines the thinking patterns behind design decisions.
@@ -8,7 +9,7 @@ These are not concrete rules, but the "way of thinking" from which rules emerge.
 
 ## 1. Constraints Breed Creativity
 
-**"Fewer choices lead to faster and better decisions."**
+> *"Fewer choices lead to faster and better decisions."*
 
 "Faster" here means reduced decision fatigue and shorter code review cycles. When the framework constrains choices (e.g., "no Enums, use union literals"), developers spend zero time debating the approach and reviewers can focus on logic rather than style. This compounds across a team — eliminating 10 micro-decisions per PR across 50 PRs/week saves meaningful cognitive load.
 
@@ -22,7 +23,7 @@ These are not concrete rules, but the "way of thinking" from which rules emerge.
 
 ## 2. Code is Read More Than Written
 
-**"Write code that the future reader (including yourself 3 months later) can understand as quickly as possible."**
+> *"Write code that the future reader (including yourself 3 months later) can understand as quickly as possible."*
 
 - Write code where intent is clear, rather than optimizing for brevity or shortness
 - Consistency in naming conventions directly impacts searchability and refactoring ease
@@ -34,9 +35,9 @@ These are not concrete rules, but the "way of thinking" from which rules emerge.
 
 ## 3. Validate at Boundaries
 
-**"Trust the internals, but validate strictly at the points of contact with the outside."**
+> *"Trust the internals, but validate strictly at the points of contact with the outside."*
 
-```
+```text
 External Input ──[Zod]──▶ Server Action ──[Types]──▶ Business Logic ──[ORM]──▶ DB
               ↑ Guard here                ↑ Protected by types here
 ```
@@ -49,7 +50,7 @@ External Input ──[Zod]──▶ Server Action ──[Types]──▶ Busines
 
 ## 4. Design for Failure
 
-**"Don't write code that assumes things work. Design with the assumption that things break."**
+> *"Don't write code that assumes things work. Design with the assumption that things break."*
 
 - All external communication can fail (timeouts, rate limits, service outages)
 - Use types to prevent forgetting error handling (discriminated union `ActionResult<T>`)
@@ -62,9 +63,9 @@ External Input ──[Zod]──▶ Server Action ──[Types]──▶ Busines
 
 ## 5. Unidirectional Data Flow
 
-**"If the data flow is consistent, most bugs disappear."**
+> *"If the data flow is consistent, most bugs disappear."*
 
-```
+```text
 Server Actions (commands)
        ↓
     Hooks (state management / side-effect control)
@@ -86,7 +87,7 @@ Server Actions (next command)
 
 ## 6. Rule of Three (Timing of Abstraction)
 
-**"Premature abstraction leads to wrong abstraction."**
+> *"Premature abstraction leads to wrong abstraction."*
 
 | Occurrences | Action |
 |-------------|--------|
@@ -102,7 +103,7 @@ Server Actions (next command)
 
 ## 7. Make the Implicit Explicit
 
-**"Implicit agreements become bugs the moment the team changes."**
+> *"Implicit agreements become bugs the moment the team changes."*
 
 - Make side effects clear through naming (`fetchUser()` = has side effects, `calculatePrice()` = pure)
 - Always include a reason with `eslint-disable`

01_philosophy/principles.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Design Principles
 
 This document defines the fundamental principles that underpin all projects.
@@ -10,23 +11,23 @@ It articulates the "why" behind our guidelines and serves as the ultimate refere
 
 All design decisions are made in this order of priority.
 
-```
+```text
 1. Correctness   — Guarantee correct behavior through types and validation
 2. Observability  — Ensure the running state can be observed and traced
 3. Pragmatism     — Achieve goals with the minimum necessary complexity
 ```
 
 ### 1. Correctness
 
-**"Eliminate code that fails at runtime by catching it at compile time."**
+> *"Eliminate code that fails at runtime by catching it at compile time."*
 
 - Security is built into the architecture, not bolted on after the fact
 
 > The "cost" of types is negligible compared to the cost of runtime errors.
 
 ### 2. Observability
 
-**"Understand what is happening in production without redeploying."**
+> *"Understand what is happening in production without redeploying."*
 
 - Assign a Trace ID to every request and propagate it across layers
 - Automatically mask PII. Never expose secrets in logs
@@ -36,7 +37,7 @@ All design decisions are made in this order of priority.
 
 ### 3. Pragmatism
 
-**"Don't build it until you need it. When you need it, build it the simplest way possible."**
+> *"Don't build it until you need it. When you need it, build it the simplest way possible."*
 
 - Copy-paste is not evil. Don't abstract until duplication appears in 3 places. The number 3 is deliberate: with 1 occurrence you have no pattern; with 2 you see similarity but may be misled by coincidence; with 3 you have enough evidence to extract a correct, stable abstraction. Abstracting at 2 often produces the *wrong* abstraction because you lack sufficient examples to identify the true commonality
 - Convention over Configuration
@@ -65,7 +66,7 @@ All design decisions are made in this order of priority.
 
 ## Security Philosophy: Zero Trust
 
-**"Trust no input. Every user is a potential attacker."**
+> *"Trust no input. Every user is a potential attacker."*
 
 1. **API Layer**: Zod validation, CORS, rate limiting
 2. **Auth Layer**: Session validation, IDOR checks (always verify ownership for resource access)
@@ -78,7 +79,7 @@ Apply the principle of least privilege to everything (DB users, API scopes, feat
 
 ## Approach to Errors
 
-**"Don't try to prevent every failure — detect, contain, and communicate them."**
+> *"Don't try to prevent every failure — detect, contain, and communicate them."*
 
 - Errors fall into 3 categories: System (unexpected), Application (expected), User (input mistakes)
 - Do not leak internal error details to the UI (return sanitized messages)
@@ -89,7 +90,7 @@ Apply the principle of least privilege to everything (DB users, API scopes, feat
 
 ## UI/Design Philosophy
 
-**"Constraints create consistency, and consistency creates speed."**
+> *"Constraints create consistency, and consistency creates speed."*
 
 - Constraint-based design with Tailwind CSS (spacing scale, color palette)
 - CSS Variables serve as the Single Source of Truth

02_decision-criteria/abstraction.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Decision Criteria for Generalization and Abstraction
 
 Criteria for deciding whether to "extract" or "leave as-is" when you find code duplication.
@@ -7,7 +8,7 @@ Criteria for deciding whether to "extract" or "leave as-is" when you find code d
 
 ## Fundamental Principle
 
-**"Premature abstraction leads to wrong abstraction."**
+> *"Premature abstraction leads to wrong abstraction."*
 
 Abstraction increases the cost of understanding. It only has value when "enough reuse" exists — meaning 3+ call sites with genuinely identical logic, not just superficially similar code. Two similar-looking functions that evolve independently don't justify abstraction.
 

02_decision-criteria/architecture.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Architecture Decision Criteria
 
 Defines the selection criteria for rendering strategies, data fetching, component placement, and API design.
@@ -126,7 +127,7 @@ Defines the selection criteria for rendering strategies, data fetching, componen
 
 ### Test Target Priority
 
-```
+```text
 1. Authentication/authorization (sessions, IDOR)     ← Highest: a flaw here means full data breach
 2. Payment processing                                ← Financial loss is immediate and concrete
 3. DB operations + API Routes                        ← Data corruption is hard to reverse

02_decision-criteria/error-strategy.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Error Strategy Decision Criteria
 
 Defines error handling policies, retry decisions, and how to communicate errors to users.
@@ -7,7 +8,7 @@ Defines error handling policies, retry decisions, and how to communicate errors
 
 ## Fundamental Principle
 
-**"Don't try to prevent all failures — detect, contain, and communicate them."**
+> *"Don't try to prevent all failures — detect, contain, and communicate them."*
 
 ---
 
@@ -23,7 +24,7 @@ Defines error handling policies, retry decisions, and how to communicate errors
 
 The boundary between System and Application errors: "Could the developer have predicted it?" means — is this error a known, enumerable case in the domain logic? If yes (e.g., "user not found", "insufficient balance"), it's an Application error that should be handled with a specific code path. If no (e.g., database connection dropped, OOM), it's a System error that gets generic handling.
 
-```
+```text
 Error Occurs
   │
   ├─ Is this a known, enumerable domain case?
@@ -51,7 +52,7 @@ Error Occurs
 
 ### Retry Implementation Criteria
 
-```
+```text
 Should we retry?
   │
   ├─ Is the status code 5xx?
@@ -133,7 +134,7 @@ type ActionResult<T> =
 
 ### Server Action Checklist
 
-```
+```typescript
 ✅ Use withAction() wrapper
 ✅ Authentication check with requireAuth()
 ✅ Resource ownership check with requireOwnership() (IDOR prevention)

02_decision-criteria/security-vs-ux.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Balancing Security and UX
 
 Criteria for judging the appropriate balance by considering the impact of security measures on user experience.
@@ -7,7 +8,7 @@ Criteria for judging the appropriate balance by considering the impact of securi
 
 ## Fundamental Principle
 
-**"Security is enabled by default. When relaxing it for UX reasons, make the risks explicit before deciding."**
+> *"Security is enabled by default. When relaxing it for UX reasons, make the risks explicit before deciding."*
 
 ---
 
@@ -52,7 +53,7 @@ Criteria for judging the appropriate balance by considering the impact of securi
 
 ### UX When Rate Limit Is Exceeded
 
-```
+```text
 Limit Exceeded
   │
   ├─ Return Retry-After header
@@ -74,7 +75,7 @@ Limit Exceeded
 
 ### Suspicious Login Detection Flow
 
-```
+```text
 Login Attempt
   │
   ├─ First-time login? → No alert (accept)
@@ -131,7 +132,7 @@ Login Attempt
 
 ## 6. Decision Tree When in Doubt
 
-```
+```text
 Want to relax a security measure
   │
   ├─ Can the user not complete their operation without relaxation?

02_decision-criteria/technology-selection.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Decision Criteria for Technology Selection
 
 A decision framework for introducing new technologies, libraries, and tools.
@@ -22,6 +23,7 @@ Weight definitions: **High** = can veto adoption on its own. **Medium** = weigh
 ### De Facto Standard Identification
 
 A library qualifies as "de facto standard" when it meets 2+ of:
+
 - Referenced in the framework's official documentation (e.g., Next.js docs mention it)
 - 10x+ GitHub stars compared to the next alternative
 - Used by the framework's own starter templates or examples