## Understanding Verification Status [Standard/Deep Mode Only]

| Core Concept | Self-Explanation | Understand "WHY" | Application Transfer | Status |
|---------|---------|-------------|---------|------|
| User Authentication Flow | ✅ | ✅ | ✅ | Understood |
| JWT Token Mechanism | ✅ | ⚠️ | ❌ | ⚠️ Needs in-depth understanding |
| Password Hashing | ✅ | ✅ | ⚠️ | Basic understanding |

# [Code Name] Quick Analysis

## 1. Quick Overview
- Programming language and version
- Code scale and type
- Core dependencies

## 2. Function Description
- What is the main function (WHAT)
- Brief explanation of WHY it's needed

## 3. Core Algorithm/Design
- Algorithm complexity (if applicable)
- Design patterns used (if applicable)
- WHY this algorithm/pattern was chosen

## 4. Key Code Snippets
- 3-5 core code snippets
- Brief explanation of each snippet's role

## 5. Dependency Relationships
- List of external libraries and their uses

## 6. Quick Usage Example
- Simple runnable example

# [Code Name] Deep Understanding Analysis

## Understanding Verification Status
[Self-explanation test result table]

## 1. Quick Overview
- Programming language, scale, dependencies

## 2. Background and Motivation (Elaborative Interrogation)
- WHY this code is needed
- WHY this solution was chosen
- WHY other solutions were not chosen

## 3. Core Concept Explanation
- List key concepts
- Answer 2-3 WHY questions for each concept

## 4. Algorithms and Theory
- Complexity analysis
- WHY this algorithm was chosen
- Reference materials

## 5. Design Patterns
- Identified patterns
- WHY they are used

## 6. In-Depth Key Code Analysis
- Line-by-line WHY analysis
- Execution flow example

## 7. Dependencies and Usage Examples
- Detailed WHY comments

# [Code Name] Complete Mastery Analysis

[Includes all content from Standard Mode, plus the following sections]

## 3+. Concept Network Diagram
- Core concept list (3 WHY questions each)
- Concept relationship matrix
- Connection to existing knowledge

## 6+. Complete Execution Example
- Multi-scenario execution flow
- Boundary condition explanation
- Error-prone point annotations

## 8. Test Case Analysis (if code includes tests)
- Test file list and coverage analysis
- Boundary conditions discovered from tests
- Test-driven understanding verification

## 9. Application Transfer Scenarios (at least 2)
- Scenario 1: Invariant principles + modified parts + WHY
- Scenario 2: Invariant principles + modified parts + WHY
- Extract general patterns

## 10. Dependency Relationships and Usage Examples
- Detailed WHY comments

## 11. Quality Verification Checklist
- Understanding depth verification
- Technical accuracy verification
- Practicality verification
- Final "Four Abilities" test

┌─────────────────────────────────────────────────────────────┐
│                     Main Coordinator Agent                              │
│  - Generates analysis outline and directory framework                                     │
│  - Identifies core concept list (shared with sub-Agents)                        │
│  - Assigns chapter tasks                                              │
│  - Aggregates sub-Agent results                                          │
│  - Final quality verification                                              │
└─────────────────────────────────────────────────────────────┘
                              │
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                 ▼
    ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
    │ Sub-Agent 1  │   │ Sub-Agent 2  │   │ Sub-Agent 3  │
    │ Background & Motivation  │   │ Core Concepts    │   │ Algorithms & Theory    │
    └─────────────┘   └─────────────┘   └─────────────┘
            │                 │                 │
            └─────────────────┼─────────────────┘
                              ▼
    ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
    │ Sub-Agent 4  │   │ Sub-Agent 5  │   │ Sub-Agent 6  │
    │ Design Patterns    │   │ Code Analysis    │   │ Application Transfer    │
    └─────────────┘   └─────────────┘   └─────────────┘

# Sub-Agent Task: [Chapter Name]

## Context Information
- **Project/Code Name:** [Project/Code Name]
- **Programming Language:** [Language]
- **Code Scale:** [Line count]
- **Core Concepts:** [Concept list from Main Agent]

## Your Task
You are a specialized analysis expert responsible for the "**[Chapter Name]**" section. Please conduct in-depth analysis of this section and generate detailed content.

## Output Requirements
1. **Content Depth:** This chapter must be at least [X] words
2. **WHY Analysis:** Each key point must answer 3 WHY questions
3. **Code Comments:** Use scenario/step + WHY style
4. **Citation Sources:** Provide authoritative reference links
5. **Independence:** Generate complete independent chapter content, no need to reference other chapters

## Output Format
Directly output Markdown-formatted chapter content, starting with `## [Chapter Name]`.

## Depth Standards
- [ ] All sub-items are covered (no "brief" or "same as above")
- [ ] Each WHY has at least 2-3 sentences of explanation
- [ ] Code examples have complete comments
- [ ] Execution flow has specific data tracking

Start analysis:

# Parallel Deep Mode Aggregation Specification

## Aggregation Steps

1. **Read All Sub-Chapters**

2. **Merge Order**
```markdown
# [Project/Code Name] Complete Mastery Analysis (Parallel Deep Version)

## Understanding Verification Status
[Generated from Main Agent's preliminary analysis]

[Insert chapter content in order]

#### Implementation Pseudocode

// Start parallel execution
sub_agent.start(parallel=True)
chapter_file_list.append(sub_agent.output_file)

---

## Analysis Process (Research-Driven)

**Depth Standards for Each Chapter:**

```markdown
## Depth Self-Check Checklist (Check after completing each chapter)

### Content Completeness
- [ ] All sub-items of the chapter are covered (no "brief" or "same as above")
- [ ] Each WHY has specific explanations (not just one sentence)
- [ ] Code examples have complete comments (scenario/step + WHY)

### Analysis Depth
- [ ] Each core concept has complete answers to 3 WHY questions
- [ ] Algorithms have complexity analysis + selection reasons
- [ ] Design patterns have WHY to use + consequences of not using
- [ ] Execution flow has specific data tracking

### Practicality
- [ ] Error-prone points are annotated
- [ ] Boundary conditions are explained
- [ ] At least 2 application transfer scenarios

Function: DeepModeProgressiveGeneration(code, file_path):

  // Phase 1: Generate Framework
  framework = generate_complete_outline(Standard structure + Deep extensions)
  write_file(file_path, framework)

  // Phase 2: Fill Chapters One by One
  chapter_list = [
    "1. Quick Overview",
    "2. Background and Motivation",
    "3. Core Concepts",
    "4. Algorithms and Theory",
    "5. Design Patterns",
    "6. In-Depth Key Code Analysis",
    "7. Test Case Analysis (if applicable)",
    "8. Application Transfer Scenarios",
    "9. Dependency Relationships",
    "10. Quality Verification"
  ]

  for each chapter in chapter_list:
    current_content = read_file(file_path)

    // Generate chapter content (focus on one task at a time to ensure depth)
    chapter_content = generate_deep_chapter(chapter, code)
    // Requirement: Each chapter is at least 300-500 words, code snippets have complete comments

    // Depth Self-Check
    if not pass_depth_check(chapter_content):
      chapter_content = append_details(chapter_content)

    // Update File
    new_content = current_content.replace(chapter_placeholder, chapter_content)
    write_file(file_path, new_content)

  // Phase 3: Overall Verification
  complete_document = read_file(file_path)
  if not pass_overall_check(complete_document):
    weak_chapters = identify_weak_sections(complete_document)
    for chapter in weak_chapters:
      supplement_content(chapter)

  return file_path

## Background and Motivation Analysis

### Problem Essence
**Problem to Solve:** [Describe in one sentence]

**WHY It Needs to Be Solved:** [Consequences of not solving it]

### Solution Selection
**Selected Solution:** [Current implementation method]

**WHY This Solution Was Chosen:**
- Advantages: [List 2-3 key advantages]
- Disadvantages: [List 1-2 known limitations]
- Trade-offs: [Explain what trade-offs were made]

**Alternative Solution Comparison:**
- Solution A: [Brief description] - WHY not chosen: [Reason]
- Solution B: [Brief description] - WHY not chosen: [Reason]

### Application Scenarios
**Applicable Scenarios:** [Specific scenario description]

**WHY Applicable:** [Explain why this scenario is suitable]

**Inapplicable Scenarios:** [List boundary conditions]

**WHY Inapplicable:** [Explain why certain scenarios are not suitable]

## Concept Network Diagram

### Core Concept List

**Concept 1: User Authentication**
- **What it is:** The process of verifying user identity
- **WHY needed:** Protect system resources from unauthorized access
- **WHY implemented this way:** Use JWT for stateless authentication to reduce server pressure
- **WHY not use other methods:** Session-based methods require server storage, which is not conducive to horizontal scaling

**Concept 2: Password Hashing**
- **What it is:** Convert plaintext passwords into irreversible hash values
- **WHY needed:** Even if the database is compromised, attackers cannot obtain original passwords
- **WHY use bcrypt:** Built-in salt, adjustable computational cost to resist brute-force attacks
- **WHY not use MD5/SHA1:** Too fast to compute, vulnerable to brute-force attacks

### Concept Relationship Matrix

| Relationship Type | Concept A | Concept B | WHY This Association |
|---------|--------|--------|-------------|
| Dependency | User Authentication | Password Hashing | Authentication requires password verification, which must be hashed first for comparison |
| Sequence | Password Hashing | Token Generation | Access Token can only be generated after password verification passes |
| Comparison | JWT | Session | JWT is stateless, suitable for distributed systems; Session is stateful, increases server pressure |

### Connection to Existing Knowledge

- **Connection to Design Patterns:** [Detailed below]
- **Connection to Algorithm Theory:** [Detailed below]
- **Connection to Security Principles:** Least privilege principle, defense-in-depth principle

## Algorithm and Theory Analysis

### Algorithm: Quick Sort

**Basic Information:**
- **Time Complexity:** Average O(n log n), Worst O(n²)
- **Space Complexity:** O(log n)

**Elaborative Interrogation:**

**WHY Choose Quick Sort?**
- Excellent average performance, usually the fastest in practical applications
- In-place sorting, high space efficiency
- Cache-friendly, good access locality

**WHY Is Worst-Case O(n²) Acceptable?**
- Worst-case scenario has very low probability (can be avoided through randomization)
- Actual data is usually not fully sorted/reverse sorted
- Can be optimized with Median-of-Three method

**WHY Not Choose Other Sorting Algorithms?**
- Merge Sort: Requires O(n) additional space, not suitable for memory-constrained scenarios
- Heap Sort: Although stable O(n log n), poor cache performance, slower than Quick Sort in practice
- Insertion Sort: Excellent for small datasets, but O(n²) is not suitable for large-scale data

**When Does Performance Degrade?**
- Input is already sorted or reverse sorted (can be solved with randomization)
- Poor pivot selection (can be solved with Median-of-Three)
- Large number of duplicate elements (can be optimized with three-way Quick Sort)

**Reference Materials:**
- [Quick Sort - Wikipedia](https://en.wikipedia.org/wiki/Quicksort)
- [Quick Sort Analysis - Princeton](https://algs4.cs.princeton.edu/23quicksort/)
- [Why is QuickSort better than MergeSort?](https://stackoverflow.com/questions/70402/why-is-quicksort-better-than-other-sorting-algorithms-in-practice)

### Theoretical Foundation: JWT (JSON Web Token)

**WHY Use JWT?**
- Stateless authentication, no need for server to store Sessions
- Self-contained, Token carries all necessary information
- Cross-domain friendly, suitable for microservice architecture

**WHY Is JWT Secure?**
- Uses signature to verify integrity
- Cannot be forged (unless private key is leaked)
- Can set expiration time (exp)

**WHY Does JWT Have Limitations?**
- Cannot be invalidated proactively (unless maintaining a blacklist, which undermines stateless advantage)
- Token size is relatively large (Base64 encoding increases size by about 33%)
- Sensitive information needs encryption, signature alone does not provide confidentiality

**Reference Materials:**
- [JWT.io - Introduction](https://jwt.io/introduction)
- [RFC 7519 - JWT Specification](https://tools.ietf.org/html/rfc7519)

## Design Pattern Analysis

### Pattern 1: Singleton Pattern

**Application Location:** `DatabaseConnection` class

**WHY Use Singleton?**
- Database connections have high overhead, reusing a single instance saves resources
- Avoids connection pool chaos, unified connection lifecycle management
- Global unique access point, easy to control concurrency

**WHY Not Use Singleton?**
- Creating new connections for each operation leads to resource exhaustion
- Multiple connection instances may cause transaction inconsistencies
- Difficult to control concurrent access

**Implementation Details:**
```python
class DatabaseConnection:
    _instance = None
    
    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            # WHY initialize in __new__:
            # Ensure singleton before object creation, thread-safe
        return cls._instance

---

### Step 6: In-Depth Line-by-Line Analysis (Key Code Snippets)

**Core Principles:**
- Select 3-5 most critical code snippets
- Each line of code must explain "what it does" + "WHY it's done this way"
- Provide execution flow examples with specific data
- Annotate error-prone points and boundary conditions

**Output Format:**

```markdown
## In-Depth Key Code Analysis

### Code Snippet 1: User Authentication Function

**Overall Role:** Verify username and password, return JWT Token or None

**WHY This Function Is Needed:** Authentication is the first line of defense for system security, must be reliable and efficient

**Original Code:**
```python
def authenticate_user(username, password):
    user = db.find_user(username)
    if not user:
        return None
    if verify_password(password, user.password_hash):
        return generate_token(user.id)
    return None

def authenticate_user(username, password):
    # Step 1: Query user
    user = db.find_user(username)
    # WHY query user first: Avoid password hashing for non-existent usernames (save computation)

    # Scenario 1: If user does not exist, immediately return None
    if not user:
        return None
        # WHY return None instead of throwing exception: Authentication failure is a normal business process, not an exception
        # WHY not distinguish between "user does not exist" and "wrong password": Prevent username enumeration attacks

    # Scenario 2: If password verification passes, generate and return Token
    if verify_password(password, user.password_hash):
        # verify_password internal flow:
        #   1. Extract salt from password_hash
        #   2. Hash plaintext password with the same salt
        #   3. Constant-time comparison of two hash values (prevent timing attacks)
        return generate_token(user.id)
        # Current state: user.id = 42 (example)
        # generate_token(42) → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

    # Scenario 3: Wrong password, return None
    return None
    # WHY same return value as "user does not exist": Prevent attackers from distinguishing between the two failure cases

// Example: Trace function that produces tensors (typical compiler code style)

Value getProducerOfTensor(Value tensor) {
  Value opResult;

  while (true) {
    // Scenario 1: If tensor is defined by LinalgOp, return directly
    if (auto linalgOp = tensor.getDefiningOp<LinalgOp>()) {
      opResult = cast<OpResult>(tensor);
      // while loop runs only once
      return;
    }

    // According to this section's example, first call to this function: tensor = %2_tile
    // Scenario 2: If tensor is linked via ExtractSliceOp, continue tracing source
    if (auto sliceOp = tensor.getDefiningOp<tensor::ExtractSliceOp>()) {
      tensor = sliceOp.getSource();
      // Current state: tensor = %2, defined by linalg.matmul
      // Execute second while loop, will enter Scenario 1 branch (linalg.matmul is LinalgOp)
      continue;
    }

    // Scenario 3: Via scf.for iteration parameter
    // Example IR:
    // %1 = linalg.generic ins(%A) outs(%init) { ... }
    // %2 = scf.for %i = 0 to 10 iter_args(%arg = %1) {
    //   %3 = linalg.generic ins(%arg) outs(%init2) { ... }
    //   scf.yield %3
    // }
    // getProducerOfTensor(%arg)
    if (auto blockArg = dyn_cast<BlockArgument>(tensor)) {
      // First while loop: tensor = %arg, which is BlockArgument
      if (auto forOp = blockArg.getDefiningOp<scf::ForOp>()) {
        // %arg is defined by scf.for, get loop's initial value: %1
        // blockArg.getArgNumber() = 0 (%arg is the 0th iteration parameter)
        // forOp.getInitArgs()[0] = %1
        tensor = forOp.getInitArgs()[blockArg.getArgNumber()];
        // Current state: tensor = %1, defined by linalg.generic
        // Execute second while loop, will enter Scenario 1 branch
        continue;
      }
    }

    return;  // Not found (may be function parameter)
  }
}

# Initial State
Input: username="alice", password="Secret123!"

# Execution Path
Step 1: db.find_user("alice")
   → Query database
   → Return User(id=42, username="alice", password_hash="$2b$12$KIX...")
   # Current state: user exists, skip return None in Scenario 1

Step 2: Enter Scenario 2 branch (password verification)
   → verify_password("Secret123!", "$2b$12$KIX...")
   → Extract salt: $2b$12$KIX...
   → Hash "Secret123!" with salt
   → Constant-time comparison of hash values
   → Return True

Step 3: generate_token(42)
   → Create payload: {"user_id": 42, "exp": 1643723400}
   → Sign with private key
   → Return "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjo0Miwi..."
   # Final return: Token string

# Performance Analysis
Time consumed: ~100ms (mainly bcrypt computation)

# Initial State
Input: username="bob", password="anything"

# Execution Path
Step 1: db.find_user("bob")
   → Query database
   → Return None
   # Current state: user = None, enter Scenario 1 branch

Step 2: if not user: # true
   → Directly return None
   # Scenarios 2 and 3 are not executed

# Performance Analysis
Time consumed: ~5ms (only database query)
⚠️ Note: Much faster than authentication success, may leak whether user exists
# Security Recommendation: Add fixed delay or fake hash computation to make response times similar for both cases

# Initial State
Input: username="alice", password="WrongPass"

# Execution Path
Step 1: db.find_user("alice")
   → Return User(id=42, ...)
   # Current state: user exists, skip return None in Scenario 1

Step 2: Enter Scenario 2 branch (password verification)
   → verify_password("WrongPass", "$2b$12$KIX...")
   → Hash "WrongPass"
   → Compare hash values
   → Return False

Step 3: Password verification fails, do not execute generate_token
   → Continue to final return None
   # Scenario 3: Password verification fails, return None

# Performance Analysis
Time consumed: ~100ms (similar to authentication success)
✅ Advantage: Cannot determine if password is correct via response time

---

### Step 6.5: Reverse Understanding via Test Cases (If Tests Exist)

**Goal:** Reverse verify and deepen understanding of code functionality through test cases

**Why It's Important:**
- Test cases reflect the **expected behavior** of the code, making them the most accurate "user manual"
- Tests usually cover **boundary conditions** and **exception scenarios**, which are easily overlooked in the main code
- Tests can **verify if understanding is correct**, avoiding false assumptions

**Must execute this step when code contains test files.**

#### 6.5.1 Test File Identification

**Common Test File Patterns:**

| Language | Test File Patterns | Test Directory Structure |
|------|-------------|-------------|
| **Python** | `test_*.py`, `*_test.py` | `tests/`, `test/` |
| **JavaScript/TypeScript** | `*.test.ts`, `*.test.js` | `__tests__/`, `tests/` |
| **Go** | `*_test.go` | Same directory as source code, `*_test.go` |
| **Java** | `*Test.java`, `*Tests.java` | `src/test/java/` |
| **C++** | `*.cpp` (contains tests), gtest | `test/`, `tests/`, `unittest/` |
| **Rust** | `*_test.rs`, `tests/*.rs` | `tests/` |
| **MLIR/LLVM** | `*.mlir` (test files) | `test/Dialect/*/` |

**Large Project Test Directory Structure Example:**

```bash
# MLIR Style (independent test directory)
mlir/test/Dialect/Linalg/
├── ops.mlir           # Linalg dialect operation tests
├── transformation.mlir # Transformation tests
├── interfaces.mlir    # Interface tests
└── invalid.mlir       # Error handling tests

# Traditional C++ Project Style
project/test/
├── unittest/          # Unit tests
├── integration/       # Integration tests
└── benchmark/         # Performance tests

## Test Case Coverage Analysis

### Test File List
| Test File/Directory | Tested Module | Number of Test Cases |
|--------------|-----------|-------------|
| `test/Dialect/Linalg/ops.mlir` | Linalg Ops | 156 |
| `test/Dialect/Linalg/invalid.mlir` | Error Handling | 43 |
| `unittest/test_auth.cpp` | `authenticate_user()` | 12 |

### Function Coverage Matrix
| Core Function | Main Code Location | Test Coverage | Coverage Evaluation |
|---------|-----------|---------|-----------|
| linalg.matmul operation | `Dialect/Linalg/Ops/*` | ✅ Has tests | Covers normal + boundary cases |
| linalg.generic interface | `Interfaces/*` | ✅ Has tests | Fully covered |
| Tile transformation | `Transforms/Tiling.cpp` | ⚠️ Insufficient tests | Missing nested scenarios |

## Boundary Conditions Discovered from Tests

### MLIR Example: Understanding linalg.generic Region Constraints

#### Test File: test/Dialect/Linalg/invalid.mlir
```mlir
// Test: generic region must have exactly one block
func.func @invalid_generic_empty_region(%arg0: tensor<10xf32>) -> tensor<10xf32> {
  %0 = linalg.generic {indexing_maps = [affine_map<(d0) -> (d0)>],
                     iterator_types = ["parallel"]}
    outs(%arg0) {
    // Empty region - should report error
  } -> tensor<10xf32>
  return %0 : tensor<10xf32>
}

// Test: Number of inputs and outputs must match indexing_maps
func.func @generic_mismatched_maps(%a: tensor<10xf32>, %b: tensor<10xf32>) -> tensor<10xf32> {
  %0 = linalg.generic {
    indexing_maps = [
      affine_map<(d0) -> (d0)>,  // Map for 1 input
      affine_map<(d0) -> (d0)>   // Map for 1 output
    ],
    iterator_types = ["parallel"]
  } ins(%a, %b : tensor<10xf32>, tensor<10xf32>)  // But there are 2 inputs
  outs(%0 : tensor<10xf32>) {
  ^bb0(%in: f32, %in_2: f32, %out: f32):
    linalg.yield %in : f32
  } -> tensor<10xf32>
  return %0 : tensor<10xf32>
}

// Test: Concurrent insertion of the same key
TEST(ConcurrentMapTest, ConcurrentInsertSameKey) {
  ConcurrentMap<int, int> map;
  const int num_threads = 10;
  const int key = 42;

  std::vector<std::thread> threads;
  for (int i = 0; i < num_threads; ++i) {
    threads.emplace_back([&map, key, i]() {
      map.Insert(key, i);  // All threads insert the same key
    });
  }

  for (auto& t : threads) t.join();

  // Verify: Only one insertion succeeds
  EXPECT_EQ(map.Size(), 1);
  EXPECT_TRUE(map.Contains(key));
}

#### 6.5.4 Test-Driven Understanding Example

**Complete Example: Understanding `linalg.tile` Transformation Through MLIR Tests**

```markdown
## Reverse Understanding via Test Cases: linalg.tile Transformation

### Question: Can we fully understand tile behavior just by reading documentation?

**Documentation Description (Simplified):**
> `linalg.tile` decomposes linalg operations into smaller fragments

**Potentially Missing Details:**
1. How is tile size determined?
2. Which operations support tiling?
3. What is the loop order after tiling?
4. How to handle remaining elements?

### Answers Discovered from Tests

#### Test 1: test/tile-mlir.mlir - Basic Tile Behavior
```mlir
// Original operation
%0 = linalg.matmul ins(%A: tensor<128x128xf32>, %B: tensor<128x128xf32>)
                     outs(%C: tensor<128x128xf32>)

// Tile size 32x32
%1 = linalg.tile %0 tile_sizes[32, 32]

// 127x127 matrix, tile size 32x32
%0 = linalg.matmul ins(%A: tensor<127x127xf32>, ...)
%1 = linalg.tile %0 tile_sizes[32, 32]

// Attempt to tile unsupported operation
%0 = linalg.generic ...
%1 = linalg.tile %0 tile_sizes[16]
// Expected: Compilation error or runtime failure

#### 6.5.5 Key Points for Parsing Test Files in Different Languages

**Notes for Testing in Each Language:**

```markdown
## Key Points for Parsing Test Files in Different Languages

### Python (pytest/unittest)
- Look for `test_*.py` or `*_test.py`
- Pay attention to `@pytest.mark.parametrize` parameterized tests
- Focus on `pytest.raises` exception tests
- Look for fixtures (`conftest.py`) to understand test context

### C++ (gtest/gtest)
- Look for `*_test.cpp` or `test/*.cpp`
- `TEST_F` indicates fixture tests with preconditions
- `EXPECT_*` vs `ASSERT_*`: Whether to continue after failure
- `TEST_P` indicates parameterized tests

### MLIR/LLVM
- Test files are usually `.mlir` or `.td`
- `RUN:` commands specify how to execute tests
- `// EXPECTED:` marks expected output
- `// ERROR:` marks expected compilation errors
- FileCheck directives: `CHECK-`, `CHECK-NOT:`, `CHECK-DAG:`

### JavaScript/TypeScript (Jest)
- `*.test.ts`, `*.spec.ts`
- `describe/it` nested structure
- `expect(...).toThrow()` exception tests
- `beforeEach/afterEach` hook functions

### Go
- Tests are in the same directory as source code: `*_test.go`
- `TestXxx(t *testing.T)` basic tests
- `TableDrivenTests` table-driven tests
- `TestMain` test entry point

### Rust
- `*_test.rs` inline tests
- `tests/` directory integration tests
- `#[should_panic]` exception tests
- `#[ignore]` skipped tests

## Test Quality Evaluation

### Covered Function Points
- ✅ Normal flow
- ✅ Boundary inputs
- ✅ Exception inputs
- ⚠️ Concurrent scenarios
- ❌ Performance tests

### MLIR-Specific Evaluation
- ✅ Positive tests (valid.mlir)
- ✅ Negative tests (invalid.mlir)
- ⚠️ Performance regression tests
- ❌ Cross-dialect interaction tests

### Test Deficiency Warnings
> ⚠️ **Warning: This module has insufficient test coverage**
> - Uncovered scenarios: [List specifically]
> - Recommended supplements: [Specific suggestions]

## Test Case Analysis

### Test File Structure
[List test files/directories and their corresponding source code modules]

### Key Test Case Interpretation
[Select 3-5 most valuable test cases]

### Hidden Behavior Discovered from Tests
[List details easily overlooked when only reading main code]

### Test Coverage Evaluation
- Core function coverage: X%
- Boundary condition coverage: [Sufficient/Insufficient]

### Test Quality Recommendations
[If tests are insufficient, propose improvement suggestions]

## Application Transfer Scenarios

### Scenario 1: Apply User Authentication to API Key Verification

**Original Scenario:** Web user login authentication  
**New Scenario:** Third-party API key verification

**Invariant Principles:**
- Core process of verifying "who is calling"
- Hash-stored credentials (API keys should also be hashed)
- Access token generation mechanism

**Modified Parts:**

```python
# Original: Username + Password
def authenticate_user(username, password):
    user = db.find_user(username)
    if not user:
        return None
    if verify_password(password, user.password_hash):
        return generate_token(user.id)
    return None

# Transferred: API Key
def authenticate_api_key(api_key):
    # WHY only one parameter: API key itself is both identity and credential
    
    app = db.find_app_by_key_prefix(api_key[:8])
    # WHY query by prefix: Avoid full table scan, API key prefix as index
    
    if not app:
        return None
    
    if verify_api_key(api_key, app.key_hash):
        # WHY hash too: Prevent key leakage if database is compromised
        
        return generate_token(app.id, scope=app.permissions)
        # WHY add scope: API keys usually have different permission levels
        
    return None

# Original: Simple Quick Sort
def quicksort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]
    left = [x for x in arr if x < pivot]
    middle = [x for x in arr if x == pivot]
    right = [x for x in arr if x > pivot]
    return quicksort(left) + middle + quicksort(right)

# Transferred: Log Sorting (External Sort + Optimization)
def quicksort_logs(log_file, output_file, memory_limit):
    # WHY external sort: Data volume exceeds memory, cannot be loaded all at once
    
    # 1. Split and sort chunks
    chunks = split_file_into_chunks(log_file, memory_limit)
    # WHY split into chunks: Each chunk can be loaded into memory and sorted individually
    
    for chunk in chunks:
        logs = load_chunk(chunk)
        
        # WHY use timsort instead of quicksort:
        # - Logs are usually partially ordered (appended by time)
        # - Timsort is optimized for partially ordered data to O(n)
        # - Python's built-in sorted() is timsort
        logs.sort(key=lambda log: log.timestamp)
        
        save_sorted_chunk(chunk, logs)
    
    # 2. Merge sorted chunks
    merge_sorted_chunks(chunks, output_file)
    # WHY merge: Combine multiple sorted sequences into one sorted sequence
    
    return output_file

---

### Step 10: Dependency Relationships and Usage Examples

(Similar to original version, but with added WHY explanations)

```markdown
## Dependency Relationship Analysis

### External Libraries

**bcrypt (v5.1.0)**
- **Purpose:** Password Hashing
- **WHY Choose bcrypt:**
  - Built-in salt, no manual management needed
  - Adjustable computational cost (cost factor)
  - Resists GPU/ASIC accelerated attacks
- **WHY Not Use SHA256:** Too fast to compute, vulnerable to brute-force attacks
- **WHY Not Use scrypt/argon2:** bcrypt is more mature and has better compatibility

**jsonwebtoken (v9.0.0)**
- **Purpose:** JWT token generation and verification
- **WHY Choose JWT:** Stateless authentication, suitable for distributed systems
- **WHY Not Use Session:** Session requires server storage, not conducive to scaling

### Internal Module Dependencies

**database.js → auth.js**
- **Dependency Reason:** Authentication requires querying user data
- **WHY This Design:** Separate data access and business logic (single responsibility principle)

**utils/crypto.js → auth.js**
- **Dependency Reason:** Authentication requires password hashing and verification
- **WHY Encapsulate into Utility Module:** Encryption logic is complex, centralized management is more secure

## Complete Usage Example

(Includes detailed WHY comments)

### Example 1: Standard User Login Flow

```javascript
// 1. Import authentication module
const auth = require('./auth');

// 2. Receive user input (from login form)
const username = req.body.username;  // Example: "alice"
const password = req.body.password;  // Example: "Secret123!"

// WHY not hash password on client:
// - After hashing on client, hash value itself becomes the "password"
// - Attackers can directly login if they obtain the hash value
// - Must hash with salt on server, client always sends plaintext

// 3. Call authentication function
const token = await auth.authenticate_user(username, password);

// 4. Respond based on result
if (token) {
    // Authentication success
    res.json({
        success: true,
        token: token,
        // WHY return token: Client needs to carry it in subsequent requests
        message: 'Login successful'
    });
    
    // WHY set HTTP-only Cookie (optional):
    // res.cookie('auth_token', token, {
    //     httpOnly: true,    // WHY: Prevent XSS attacks from reading it
    //     secure: true      // WHY: Only transmit over HTTPS
    // });
} else {
    // Authentication failure (user does not exist or wrong password)
    
    // WHY not distinguish failure reasons: Prevent username enumeration
    res.status(401).json({
        success: false,
        message: 'Incorrect username or password'  // Vague error message
    });
    
    // WHY return 401 instead of 403:
    // 401 = Unauthenticated (needs to provide credentials)
    // 403 = Authenticated but no permission
}

Client request → Server verification → Return Token
Time: ~100ms
Token example: "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

Client request → Server verification → Return 401 error
Time: ~100ms (similar to success, prevents timing attacks)

---

### Step 11: Self-Assessment Checklist

**After completing analysis, mandatory verification of the following items:**

```markdown
## Quality Verification Checklist

### Understanding Depth Verification

- [ ] **Each core concept answers 3 WHY questions**
  - WHY this concept is needed
  - WHY it's implemented this way
  - WHY other methods are not used

- [ ] **Self-explanation test passed**
  - [ ] Can explain each core concept without looking at code
  - [ ] Can explain "why" instead of just "what"
  - [ ] Can apply it in different scenarios (transfer test)

- [ ] **Concept connections established**
  - [ ] Marked dependency/comparison/combination relationships between concepts
  - [ ] Connected to existing knowledge (design patterns, algorithm theory)
  - [ ] Explained reasons for each connection (WHY)

### Technical Accuracy Verification

- [ ] **Algorithm analysis complete**
  - [ ] Time/space complexity marked
  - [ ] WHY this algorithm was chosen
  - [ ] WHY complexity is acceptable
  - [ ] Provided authoritative reference materials

- [ ] **Design pattern identification**
  - [ ] All patterns are marked
  - [ ] WHY this pattern is used
  - [ ] What would happen if not used
  - [ ] Provided standard references

- [ ] **Code analysis detailed**
  - [ ] Key code snippets have line-by-line analysis
  - [ ] Each line includes "what it does" + "WHY it's done this way"
  - [ ] Provided execution examples with specific data
  - [ ] Annotated error-prone points and boundary conditions

### Practicality Verification

- [ ] **Application transfer test**
  - [ ] At least 2 transfer examples in different scenarios
  - [ ] Explained what remains unchanged and what needs to be changed
  - [ ] Extracted general patterns

- [ ] **Usage examples are runnable**
  - [ ] Example code is complete
  - [ ] Includes detailed WHY comments
  - [ ] Explained execution results

- [ ] **Issues and improvement suggestions**
  - [ ] Pointed out potential issues
  - [ ] WHY it's an issue
  - [ ] Provided improvement solutions
  - [ ] WHY the improvement solution is better

### Final Verification Questions

**If you don't look at the original code, based on this analysis document:**

1. ✅ Can you understand the code's design ideas?
2. ✅ Can you implement similar functions independently?
3. ✅ Can you apply it to different scenarios?
4. ✅ Can you explain it clearly to others?

If any answer is "No", the analysis is not deep enough and needs supplementation.

# [Code Name] Deep Understanding Analysis

## Understanding Verification Status
[Self-explanation test result table]

## 1. Quick Overview
- Programming language:
- Code scale:
- Core dependencies:

## 2. Background and Motivation Analysis (Elaborative Interrogation)
- Problem essence (WHY needed)
- Solution selection (WHY chosen + WHY other solutions not chosen)
- Application scenarios (WHY applicable + WHY not applicable)

## 3. Concept Network Diagram
- Core concept list (3 WHY questions per concept)
- Concept relationship matrix
- Connection to existing knowledge

## 4. In-Depth Algorithm and Theory Analysis
- Each algorithm: Complexity + WHY chosen + WHY acceptable + reference materials
- Each theory: WHY used + WHY effective + WHY limited

## 5. Design Pattern Analysis
- Each pattern: WHY used + WHY not used + implementation details + reference materials

## 6. In-Depth Key Code Analysis
- Each code snippet: Line-by-line analysis (what it does + WHY) + execution examples + key takeaways

## 7. Test Case Analysis (if applicable)
- Test file list and coverage analysis
- Boundary conditions discovered from tests
- Test-driven understanding verification

## 8. Application Transfer Scenarios (at least 2)
- Each scenario: Invariant principles + modified parts + WHY transferred this way

## 9. Dependency Relationships and Usage Examples
- Each dependency: WHY chosen + WHY other solutions not chosen
- Examples include detailed WHY comments

## 10. Quality Verification Checklist
[Check all verification items]

1. Output 5000-token complete analysis in conversation
2. Use Write tool to write another 5000 tokens
→ Total: 10000+ tokens output

1. Use Write tool directly to write 5000 tokens
2. Output 200-token summary in conversation
→ Total: 5200 tokens output (saves ~50%)

Automatic trigger conditions (use parallel processing if any are met):
- Number of code files > 10
- Total code lines > 2000
- User explicitly mentions "large project", "complete project", "overall project analysis"
- User uses depth trigger words like "thoroughly", "complete mastery", "in-depth research" and code scale is large

if code_lines <= 2000:
    use Strategy A: Progressive Generation (sequential processing)
else:
    use Strategy B: Parallel Processing (detailed below)

# Create working directory
mkdir -p code-analysis/{tasks,chapters}

# Generate framework file
cat > code-analysis/00-framework.json << 'EOF'
{
  "project_name": "[project-name]",
  "language": "[language]",
  "total_lines": [line-count],
  "core_concepts": [concept-list],
  "chapters": [
    "Background and Motivation", "Core Concepts", "Algorithm Theory",
    "Design Patterns", "Code Analysis", "Application Transfer",
    "Dependency Relationships", "Quality Verification"
  ]
}
EOF

For each chapter, use Task tool to create independent sub-Agents:

Task(
  description: "In-depth analysis of [chapter-name] chapter",
  prompt: """
  You are a [chapter-name] analysis expert.

  ## Context
  - Project: {project_name}
  - Language: {language}
  - Core Concepts: {core_concepts}

  ## Task
  Conduct in-depth analysis of the [chapter-name] section of the code, generate detailed chapter content (at least {min_words} words).

  ## Requirements
  - Use scenario/step + WHY style comments
  - Each key point answers 3 WHY questions
  - Provide specific execution examples
  - Cite authoritative sources

  ## Output
  Write complete chapter content to file:
  code-analysis/chapters/{chapter-name}.md
  """,
  subagent_type: "general-purpose"
)

After all sub-Agents are completed, use Read tool to read all chapter files, merge in order:

1. Read code-analysis/00-framework.json
2. Read code-analysis/chapters/*.md (in order)
3. Merge into final document
4. Write to {project-name}-complete-mastery-analysis.md

## Chapter Depth Self-Check Checklist

### 1. Content Completeness (Mandatory)
- [ ] All sub-items of the chapter are covered (no "brief" or "same as above")
- [ ] Each WHY has specific explanations (at least 2-3 sentences, not just one sentence)
- [ ] Code examples have complete comments (use scenario/step + WHY style)
- [ ] Citations have source links (algorithms/patterns/theories)

### 2. Analysis Depth (By Chapter Type)

**Concept Chapters (Chapter 3):**
- [ ] Each core concept has 3 WHY answers
  - WHY this concept is needed
  - WHY it's implemented this way
  - WHY other methods are not used

**Algorithm Chapters (Chapter 4):**
- [ ] Time/space complexity marked
- [ ] Explanation of WHY this algorithm was chosen
- [ ] Explanation of WHY complexity is acceptable
- [ ] Explanation of degradation scenarios

**Design Pattern Chapters (Chapter 5):**
- [ ] Pattern name and standard reference provided
- [ ] Explanation of WHY this pattern is used
- [ ] Explanation of what would happen if not used

**Code Analysis Chapters (Chapter 6):**
- [ ] Line-by-line analysis (what it does + WHY)
- [ ] Execution examples with specific data
- [ ] Multi-scenario tracking (at least 2 scenarios)
- [ ] Error-prone points and boundary conditions annotated

### 3. Practicality (Application Value)
- [ ] Error-prone points annotated
- [ ] Boundary conditions explained
- [ ] At least 2 application transfer scenarios
- [ ] Improvement suggestions have WHY explanations

### 4. Format Specification
- [ ] Uses Markdown format
- [ ] Code blocks have language annotations
- [ ] Tables are aligned correctly
- [ ] List levels are clear

### Handling of Unqualified Chapters

**Case A: Insufficient Content (<300 words)**
→ Append details: Add more explanations, examples, comparisons

**Case B: Insufficient WHY Analysis**
→ Supplement WHY: Ask "why" for each core point

**Case C: Incomplete Code Comments**
→ Add detailed comments: Use scenario/step + WHY style

**Case D: Missing Execution Flow**
→ Add specific data examples: Track variable change trajectories