# Code Analysis

Template for generating architecture analysis, dependency graphs, and structural reports. The primary output is Mermaid diagrams with supporting explanations.

## Instructions

1. Complete Phase 1 (project exploration) first
2. Determine which analysis dimensions apply to the project
3. For each applicable dimension, search for relevant code and generate the analysis
4. Write each report to `.deepwiki/analysis/{dimension}.md`

## Analysis Dimensions

### Architecture Analysis

**Goal:** Map the high-level module/component structure and their relationships.

**How to investigate:**
- Scan the top-level directory structure to identify major modules/packages
- Read entry points (main files, app configuration, routers) to understand how modules connect
- Trace import chains between modules to identify coupling
- Look for boundary patterns: interfaces, abstract classes, API contracts between modules

**Output structure:**

```markdown
# Architecture Overview

## Module Map

{Mermaid graph TD showing all major modules and their relationships}

## Module Details

### {Module Name}
- **Purpose:** ...
- **Key files:** ...
- **Dependencies:** imports from ...
- **Dependents:** imported by ...

...
```

**Mermaid diagram guidelines:**
- Use `graph TD` (top-down, never LR)
- One node per major module/package
- Arrows show dependency direction (A depends on B: `A --> B`)
- Label arrows with the nature of the dependency when not obvious
- Group related modules with `subgraph` blocks
- Keep node labels to 3-4 words max

---

### Dependency Analysis

**Goal:** Map both external and internal dependencies.

**How to investigate:**
- Read package manifests (package.json, pyproject.toml, Cargo.toml, go.mod, etc.)
- Categorize external dependencies: core vs dev, by purpose (HTTP, DB, testing, etc.)
- Trace internal imports between modules to build a dependency graph
- Identify circular dependencies if any

**Output structure:**

```markdown
# Dependency Analysis

## External Dependencies

| Package | Purpose | Category |
|---------|---------|----------|
| ...     | ...     | ...      |

## Internal Dependency Graph

{Mermaid graph TD showing internal module dependencies}

## Circular Dependencies

{List any circular dependency chains found, or "None detected"}
```

---

### Data Flow Analysis

**Goal:** Trace how data moves through the system.

**How to investigate:**
- Identify entry points: HTTP routes, CLI commands, event handlers, message consumers
- Trace a typical request from entry to response: router → controller → service → data layer → response
- Identify data stores: databases, caches, file system, external APIs
- Look for data transformation points: serialization, validation, mapping

**Output structure:**

```markdown
# Data Flow

## Request Lifecycle

{Mermaid sequenceDiagram showing a typical request from entry to response}

## Data Stores

| Store | Type | Used By | Purpose |
|-------|------|---------|---------|
| ...   | ...  | ...     | ...     |

## Key Data Transformations

{Description of where and how data is transformed}
```

**Sequence diagram rules** (same as page-content.md):
- `sequenceDiagram` on its own line
- Define all participants first
- Use `->>` for calls, `-->>` for responses
- Use activation boxes for processing: `A->>+B: Process`, `B-->>-A: Result`
- Use `alt`/`else` for conditional paths
- Use `loop` for repeated operations

---

### Entry Point Analysis

**Goal:** Map how the application starts and handles different types of requests.

**How to investigate:**
- Find the main entry point (main function, app factory, server bootstrap)
- Trace the initialization sequence: config loading → service setup → server start
- Map routing: how incoming requests are dispatched to handlers
- Identify middleware/interceptor chains

**Output structure:**

```markdown
# Entry Points and Initialization

## Startup Sequence

{Mermaid graph TD showing initialization flow}

## Request Routing

{Mermaid graph TD or table showing route → handler mapping}

## Middleware Chain

{Ordered list or diagram of middleware/interceptors}
```

## Quality Rules

- All diagrams must be derived from actual code, not assumptions
- Cite specific files and line numbers for every claim
- Use tables for structured data (dependencies, routes, config)
- Each analysis report should have at least 2 Mermaid diagrams
- Keep explanatory text concise — let the diagrams do the heavy lifting