Fix markdownlint errors in Part 1 chapters

Resolved linting issues across Architecture Principles and Digestible Interfaces chapters:
- Added language specifiers to code blocks (MD040)
- Added blank lines around lists and headings (MD032, MD022)
- Removed extra consecutive blank lines (MD012)
- Converted emphasized text to proper headings (MD036)
- Fixed table formatting (MD060)

All validation checks now pass.

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

Author: testac974

book/part1-foundations/03-architecture-principles/02-the-digestibility-principle.md

@@ -209,7 +209,7 @@ Let's make this concrete with a real scenario I encountered at a previous compan
 
 The payment processing system was spread across 12 files:
 
-```
+```text
 payment/
   ├── handlers.py          (routing, 300 lines)
   ├── validators.py        (validation, 250 lines)
@@ -243,7 +243,7 @@ By file #5, the AI agent's context window is half full with payment code, leavin
 
 We refactored to a single, self-contained module:
 
-```
+```text
 payment/
   └── payment_processor.py  (single file, 600 lines)
       ├── PaymentConfig      (configuration, 50 lines)
@@ -270,7 +270,7 @@ Now, an AI agent (or human) could:
 Let's be specific about the numbers:
 
 | Component Type | Lines of Code | Tokens | Fits in AI Context? |
-|----------------|---------------|--------|---------------------|
+| --- | --- | --- | --- |
 | Single digestible module | 500-1,000 | 2,000-4,000 | ✓ Yes, with room to spare |
 | Medium component with deps | 2,000-3,000 | 8,000-12,000 | ✓ Yes, but tight |
 | Large scattered system | 5,000+ | 20,000+ | ✗ No, requires fragmentation |

book/part1-foundations/03-architecture-principles/03-component-decomposition.md

@@ -30,7 +30,7 @@ The answer is **component decomposition**: the art of dividing a system into ind
 
 Let's start with a common scenario. You're building an e-commerce platform. The traditional approach might decompose it like this:
 
-```
+```text
 ecommerce/
   ├── backend/
   │   ├── services/
@@ -60,7 +60,7 @@ That's six different directories and potentially 10+ files. The AI must keep all
 
 Now consider **vertical decomposition**—organizing by feature:
 
-```
+```text
 ecommerce/
   ├── cart/
   │   ├── cart_api.py        (API endpoints)
@@ -162,7 +162,7 @@ graph TB
 
 **Example structure**:
 
-```
+```text
 features/
   ├── user_auth/
   │   ├── auth_api.py          # API endpoints
@@ -198,7 +198,7 @@ features/
 
 **Example**: E-commerce bounded contexts
 
-```
+```text
 contexts/
   ├── catalog/              # Product discovery domain
   │   ├── products/
@@ -366,7 +366,7 @@ Let me show you a real refactoring I did on a project where AI agents were strug
 
 ### Before: Monolithic User Service
 
-```
+```text
 user_management/
   └── user_service.py      (1,200 lines, 15 methods)
       - User registration
@@ -383,7 +383,7 @@ user_management/
 
 ### After: Feature-Based Decomposition
 
-```
+```text
 user_management/
   ├── registration/
   │   ├── signup.py         (150 lines)
@@ -412,7 +412,7 @@ Here are anti-patterns to avoid:
 
 **Bad**:
 
-```
+```text
 utils/
   ├── string_utils.py
   ├── date_utils.py
@@ -425,7 +425,7 @@ utils/
 
 **Good**: Put utilities near where they're used:
 
-```
+```text
 cart/
   ├── cart_service.py
   ├── cart_validators.py   (validation specific to carts)
@@ -456,15 +456,15 @@ def process_cart(user: User, items: List[Item]) -> Order:
 
 **Bad**:
 
-```
+```text
 orders → cart → inventory → orders  (circular!)
 ```
 
 **Problem**: AI agents must load entire cycle into context.
 
 **Good**: Establish dependency hierarchy:
 
-```
+```text
 orders → cart → inventory  (one direction, no cycles)
 ```
 

book/part1-foundations/03-architecture-principles/04-interface-boundaries.md

@@ -266,7 +266,7 @@ A specification is a machine-readable contract. There's no room for interpretati
 
 **Human documentation**:
 
-```
+```text
 The email field should be a valid email address.
 ```
 
@@ -578,7 +578,7 @@ When asking an AI agent to implement an interface:
 
 **Good prompt**:
 
-```
+```text
 Implement the UserService according to this OpenAPI specification:
 [paste spec]
 

book/part1-foundations/03-architecture-principles/05-separation-of-concerns.md

@@ -401,7 +401,7 @@ An AI agent can now modify tax logic without touching configuration management.
 
 **Structure**:
 
-```
+```text
 project/
   ├── src/
   │   ├── domain/          # Business logic

book/part1-foundations/03-architecture-principles/06-testability-for-ai-code.md

@@ -34,11 +34,13 @@ In traditional development, you write code slowly and carefully, testing as you
 Consider this scenario: You prompt Claude Code to implement user authentication. Five minutes later, you have a complete implementation with password hashing, session management, JWT tokens, and email verification. It looks sophisticated. But does it work? Are there security vulnerabilities? Does it handle edge cases?
 
 Without good tests, you're forced to:
+
 - **Manually test every scenario** (slow and error-prone)
 - **Read and understand all the generated code** (defeats the velocity gains)
 - **Hope the AI got it right** (dangerous)
 
 With a testable architecture, you can:
+
 - **Run automated tests in seconds** and know if it works
 - **Trust the AI-generated code** if tests pass
 - **Iterate quickly** by regenerating implementations and re-running tests
@@ -72,6 +74,7 @@ class UserService:
 ```
 
 This code is **impossible to test** without:
+
 - A real PostgreSQL database running
 - SendGrid credentials configured
 - Actually sending emails during tests
@@ -122,6 +125,7 @@ When you prompt an AI agent to implement a feature, you can specify: "Use depend
 ### 2. Pure Functions: Predictable and Easy to Test
 
 A **pure function** is one that:
+
 - **Always returns the same output for the same inputs** (deterministic)
 - **Has no side effects** (doesn't modify external state, doesn't do I/O)
 
@@ -149,6 +153,7 @@ def calculate_total_price(cart_id):
 ```
 
 This function is **painful to test**:
+
 - Need to set up global cart store
 - Need a database with tax rates
 - Behavior changes based on time of day
@@ -222,11 +227,13 @@ graph TD
 *Figure 3.6: Component boundaries define test boundaries. Each component has focused unit tests, while integration tests verify components work together.*
 
 When components have:
+
 - **Clear interfaces**: Easy to mock for testing
 - **Single responsibility**: Tests focus on one thing
 - **Explicit dependencies**: Easy to inject test doubles
 
 Then you can:
+
 - **Test each component in isolation** (fast unit tests)
 - **Test integrations between components** (targeted integration tests)
 - **Know exactly what broke** when tests fail (precise test boundaries)
@@ -274,6 +281,7 @@ def test_user_creation_logic():
 ```
 
 With fast unit tests, you can run hundreds of tests in seconds. This enables:
+
 - **Continuous testing** while developing with AI
 - **Immediate feedback** when something breaks
 - **Confidence to iterate rapidly** knowing tests will catch regressions
@@ -313,7 +321,7 @@ This loop accelerates over time. The more you optimize for testability, the fast
 
 ## Common Testability Mistakes
 
-**Mistake 1: Testing implementation details instead of behavior**
+### Mistake 1: Testing implementation details instead of behavior
 
 Don't test *how* the code works internally. Test *what* it does from the outside.
 
@@ -340,11 +348,11 @@ def test_password_hashing_is_secure():
     assert not service.verify_password("wrong", hashed)
 ```
 
-**Mistake 2: Skipping tests because "AI code is usually correct"**
+### Mistake 2: Skipping tests because "AI code is usually correct"
 
 AI code is usually *plausible*, not necessarily correct. It can have subtle bugs, security issues, or misunderstand requirements. Tests catch these.
 
-**Mistake 3: Over-mocking to the point of meaningless tests**
+### Mistake 3: Over-mocking to the point of meaningless tests
 
 ```python
 # Bad: Mocks so much that test is meaningless

book/part1-foundations/03-architecture-principles/07-practical-application.md

@@ -32,19 +32,22 @@ Let's walk through a complete example: **designing a task management API** that
 Imagine we're building a REST API for a task management system with these key requirements:
 
 **Core Features**:
+
 - Users can create projects and add tasks
 - Tasks have assignees, due dates, status, and comments
 - Teams can collaborate on shared projects
 - Real-time notifications when tasks are updated
 - Search and filtering across tasks
 
 **Non-Functional Requirements**:
+
 - Must handle 1,000 concurrent users
 - API response time < 200ms (p95)
 - Easy for frontend developers to integrate
 - Testable in isolation without external services
 
 **Constraints**:
+
 - 6-week timeline to MVP
 - Small team (1-2 developers + AI agents)
 - Standard tech stack (Node.js, PostgreSQL, REST)
@@ -94,7 +97,7 @@ graph TD
 
 **Working with Claude Code**:
 
-```
+```text
 Prompt: "Design the Task Service for our task management API.
 Requirements:
 - Manage CRUD operations for tasks
@@ -172,7 +175,7 @@ paths:
 
 **Working with Claude Code**:
 
-```
+```text
 Prompt: "Implement the POST /tasks endpoint according to the
 OpenAPI spec. Use dependency injection for ProjectService and
 UserService. Include input validation and error handling."
@@ -187,14 +190,15 @@ Claude generates code that exactly matches the specification.
 **Applying the principles**:
 
 We'll use a **layered architecture** that separates:
+
 - **API layer**: HTTP handling, request validation
 - **Business logic layer**: Task rules and workflows
 - **Data access layer**: Database queries
 - **Infrastructure layer**: External service clients
 
 **Task Service Structure**:
 
-```
+```text
 task-service/
 ├── src/
 │   ├── api/
@@ -216,10 +220,10 @@ task-service/
 
 **Why this separation?**
 
-1. **Testability**: Business logic in `domain/` is pure—easy to test
-2. **Clarity**: Each file has one job
-3. **AI-friendly**: Clear file naming tells Claude what goes where
-4. **Maintainability**: Changes localized to single layer
+- **Testability**: Business logic in `domain/` is pure—easy to test
+- **Clarity**: Each file has one job
+- **AI-friendly**: Clear file naming tells Claude what goes where
+- **Maintainability**: Changes localized to single layer
 
 **Example - Pure Business Logic**:
 
@@ -373,7 +377,7 @@ Here's our final architecture applying all five principles:
 
 **Working with Claude Code on This Architecture**:
 
-```
+```text
 Session 1 - Design Phase:
 Prompt: "Review this architecture diagram and OpenAPI specs.
 Identify any missing error cases or edge conditions."

book/part1-foundations/03-architecture-principles/08-common-pitfalls.md

@@ -364,7 +364,7 @@ This test works regardless of hashing algorithm. Switch to argon2? Tests still p
 
 **What it looks like**:
 
-```
+```text
 Your 6-week MVP split into 15 microservices:
 - User Service
 - Auth Service