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

- MD025: セクション見出し(# N.)をH2(##)に降格（多重H1の解消）
- MD040: コードブロックに言語識別子を追加（python/bash/text/yaml等）
- MD036: 哲学的引用をブロッククォートに、ラベルをH3見出しに変換
- MD022/MD032/MD031/MD004等: 空行・リストスタイルを自動修正

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

Author: yunbow

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., "use Literal types over plain strings," "no bare `except`"), 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 ──[Pydantic]──> Route Handler ──[Type Hints]──> Service Layer ──[ORM]──> DB
                ^ Guard here                    ^ Protected by types here
 ```
@@ -49,7 +50,7 @@ External Input ──[Pydantic]──> Route Handler ──[Type Hints]──> S
 
 ## 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 and explicit result patterns to prevent forgetting error handling (e.g., `Result[T, E]` or custom exception hierarchies)
@@ -62,9 +63,9 @@ External Input ──[Pydantic]──> Route Handler ──[Type Hints]──> S
 
 ## 5. Layered Architecture
 
-**"If the data flow is consistent, most bugs disappear."**
+> *"If the data flow is consistent, most bugs disappear."*
 
-```
+```text
 Route Handlers / CLI Commands (entry points)
        |
     Service Layer (business logic / orchestration)
@@ -84,7 +85,7 @@ Route Handlers / CLI Commands (entry points)
 
 ## 6. Rule of Three (Timing of Abstraction)
 
-**"Premature abstraction leads to wrong abstraction."**
+> *"Premature abstraction leads to wrong abstraction."*
 
 | Occurrences | Action |
 |-------------|--------|
@@ -100,7 +101,7 @@ Route Handlers / CLI Commands (entry points)
 
 ## 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 (`fetch_user()` = has side effects, `calculate_price()` = pure)
 - Always include a reason with `# noqa` or `type: ignore`

01_philosophy/principles.md

@@ -1,4 +1,5 @@
 $NOTE
+
 # Design Principles
 
 This document defines the fundamental principles that underpin all projects.
@@ -10,15 +11,15 @@ 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 runtime errors by catching them during static analysis (mypy/pyright)."**
+> *"Eliminate runtime errors by catching them during static analysis (mypy/pyright)."*
 
 - Type hints catch errors via static analysis (mypy/pyright) before code reaches production
 - Security is built into the architecture, not bolted on after the fact
@@ -27,7 +28,7 @@ All design decisions are made in this order of priority.
 
 ### 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
@@ -37,7 +38,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
@@ -66,7 +67,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**: Pydantic validation, CORS, rate limiting
 2. **Auth Layer**: Session/token validation, IDOR checks (always verify ownership for resource access)
@@ -79,7 +80,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 client (return sanitized messages)
@@ -90,7 +91,7 @@ Apply the principle of least privilege to everything (DB users, API scopes, feat
 
 ## API Design Philosophy
 
-**"Constraints create consistency, and consistency creates speed."**
+> *"Constraints create consistency, and consistency creates speed."*
 
 - Consistent response schemas using Pydantic models
 - Pydantic models serve as the Single Source of Truth for data shapes

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 sync vs async, API design, data access patterns, dependency injection, and project structure.
@@ -143,7 +144,7 @@ Defines the selection criteria for sync vs async, API design, data access patter
 
 ### 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 endpoints                     <- 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?
@@ -155,7 +156,7 @@ class AuthorizationError(AppError):
 
 ### Service Method Checklist
 
-```
+```text
 - Use the service layer for all business logic
 - Authentication check via dependency injection
 - Resource ownership check (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., FastAPI docs mention it)
 - 10x+ GitHub stars compared to the next alternative
 - Used by the framework's own tutorials or starter templates