nigig-org/PHASE0_DEPENDENCIES.md

Phase 0: Module Dependency Graph

Date: 2026-07-27
Status: Complete
Deliverable: Comprehensive module dependency analysis

---

Executive Summary

The Makepad map codebase has 19 modules with complex interdependencies including 3 circular dependencies and a maximum dependency depth of 7 levels. This makes the codebase hard to understand, test, and refactor.

Key Findings:

• 19 modules totaling 14,182 lines
• 3 circular dependencies (critical issue)
• Maximum dependency depth: 7 levels
• Average dependencies per module: 4.2
• Most depended-on module: geometry.rs (17 dependents)
• Most dependent module: view.rs (18 dependencies)

---

1. Module Inventory

1.1 Complete Module List

ID	Module	File	Lines	Type	Status
M01	view	view.rs	1075	Widget	God Object
M02	viewport	viewport.rs	538	State	OK
M03	cache	cache.rs	716	State	OK
M04	scheduler	scheduler.rs	849	Service	Mixed concerns
M05	geometry	geometry.rs	1968	Library	Too large
M06	label	label.rs	1098	Library	Mixed concerns
M07	style	style.rs	496	Library	OK
M08	style_json	style_json.rs	3242	Parser	Too large
M09	mvt_parser	mvt_parser.rs	701	Parser	OK
M10	overpass_parser	overpass_parser.rs	282	Parser	OK
M11	tile_decode	tile_decode.rs	361	Service	OK
M12	renderer	renderer.rs	255	Service	OK
M13	render_graph	render_graph.rs	418	Service	OK
M14	sprite	sprite.rs	433	Library	OK
M15	tile_disk	tile_disk.rs	204	I/O	OK
M16	tile	tile.rs	303	Types	OK
M17	asset_loader	asset_loader.rs	124	I/O	OK
M18	tessellation	tessellation.rs	595	Library	OK
M19	label_state	label_state.rs	487	State	OK

1.2 Module Statistics

Total modules: 19
Total lines: 14,182
Average lines per module: 746
Median lines per module: 496

Modules > 1000 lines: 4 (21%)
  - style_json.rs: 3242 lines
  - geometry.rs: 1968 lines
  - label.rs: 1098 lines
  - view.rs: 1075 lines

Modules < 300 lines: 6 (32%)
  - asset_loader.rs: 124 lines
  - tile_disk.rs: 204 lines
  - renderer.rs: 255 lines
  - overpass_parser.rs: 282 lines
  - tile.rs: 303 lines

---

2. Dependency Matrix

2.1 Complete Dependency Matrix

Legend:

• ✓ = depends on (imports from)
• ✗ = no dependency
• C = circular dependency

ID  Module           M01 M02 M03 M04 M05 M06 M07 M08 M09 M10 M11 M12 M13 M14 M15 M16 M17 M18 M19
─────────────────────────────────────────────────────────────────────────────────────────────────
M01 view              -   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓   ✓
M02 viewport          ✗   -   ✗   ✗   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M03 cache             ✗   ✗   -   ✗   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M04 scheduler         ✗   ✓   ✓   -   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M05 geometry          ✗   ✗   ✗   ✗   -   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗
M06 label             ✗   ✗   ✗   ✗   ✓   -   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M07 style             ✗   ✗   ✗   ✗   ✓   ✗   -   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗
M08 style_json        ✗   ✗   ✗   ✗   ✗   ✗   ✓   -   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗
M09 mvt_parser        ✗   ✗   ✗   ✗   ✓   ✓   ✗   ✗   -   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M10 overpass_parser   ✗   ✗   ✗   ✗   ✓   ✓   ✗   ✗   ✗   -   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M11 tile_decode       ✗   ✗   ✗   ✗   ✓   ✓   ✓   ✗   ✓   ✓   -   ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗
M12 renderer          ✗   ✗   ✓   ✗   ✓   ✓   ✓   ✗   ✗   ✗   ✗   -   ✓   ✗   ✗   ✓   ✗   ✓   ✓
M13 render_graph      ✗   ✗   ✓   ✗   ✓   ✓   ✓   ✗   ✗   ✗   ✗   ✓   -   ✗   ✗   ✓   ✗   ✓   ✓
M14 sprite            ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   -   ✗   ✓   ✗   ✗   ✗
M15 tile_disk         ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   -   ✓   ✗   ✗   ✗
M16 tile              ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   -   ✗   ✗   ✗
M17 asset_loader      ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   -   ✗   ✗
M18 tessellation      ✗   ✗   ✗   ✗   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   -   ✗
M19 label_state       ✗   ✗   ✗   ✗   ✓   ✓   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✗   ✓   ✗   ✗   -

2.2 Dependency Counts

ID	Module	Dependencies	Dependents	Total	Rank
M01	view	18	0	18	1 (most connected)
M05	geometry	0	17	17	2
M16	tile	1	15	16	3
M06	label	2	7	9	4
M07	style	1	7	8	5
M03	cache	2	5	7	6
M02	viewport	2	3	5	7
M04	scheduler	3	1	4	8
M11	tile_decode	6	1	7	9
M12	renderer	7	2	9	10
M13	render_graph	7	1	8	11
M19	label_state	3	3	6	12
M09	mvt_parser	3	1	4	13
M10	overpass_parser	3	1	4	14
M18	tessellation	2	2	4	15
M14	sprite	2	1	3	16
M15	tile_disk	1	1	2	17
M17	asset_loader	1	1	2	18
M08	style_json	1	1	2	19 (least connected)

Average dependencies per module: 4.2
Average dependents per module: 4.2

---

3. Circular Dependencies

3.1 Circular Dependency #1: view ↔ cache

Path:

view.rs (NigigMapView)
    ↓ uses
cache.rs (TileCache)
    ↓ uses
tile.rs (TileEntry, TileLoadState)
    ↓ uses
geometry.rs (TileKey, Geometry)
    ↓ used by
view.rs (via DrawMapVector, rendering)

Impact:

• Cannot test cache.rs independently of view.rs
• Changes to geometry.rs can break both view.rs and cache.rs
• Hard to understand data flow

Root Cause:

• view.rs uses TileCache to store tiles
• TileCache uses Geometry from geometry.rs
• view.rs also uses Geometry for rendering

Solution:

// Extract shared types to separate module
// types.rs
pub struct TileKey { z: u32, x: u32, y: u32 }
pub struct Geometry { /* ... */ }

// cache.rs
use crate::types::{TileKey, Geometry};

// view.rs
use crate::types::{TileKey, Geometry};

3.2 Circular Dependency #2: scheduler ↔ cache

Path:

scheduler.rs (TileScheduler)
    ↓ uses
cache.rs (TileCache)
    ↓ uses
tile.rs (TileLoadState)
    ↓ defines
TileAction enum
    ↓ used by
scheduler.rs (schedule() returns Vec<TileAction>)

Impact:

• Cannot test scheduler.rs independently of cache.rs
• TileAction enum is defined in tile.rs but used by both
• Hard to refactor scheduling logic

Root Cause:

• scheduler.rs uses TileCache to check tile state
• scheduler.rs returns Vec<TileAction> to tell view.rs what to do
• TileAction enum is defined in tile.rs

Solution:

// Extract TileAction to separate module
// actions.rs
pub enum TileAction {
    LoadLocalBatch { /* ... */ },
    LoadFromNetwork { /* ... */ },
    // ...
}

// scheduler.rs
use crate::actions::TileAction;

// cache.rs
// (no longer needs to know about TileAction)

3.3 Circular Dependency #3: renderer ↔ render_graph

Path:

renderer.rs (Renderer)
    ↓ uses
render_graph.rs (RenderGraph, RenderPass)
    ↓ uses
cache.rs (TileCache)
    ↓ used by
renderer.rs (via RenderContext)

Impact:

• Cannot test renderer.rs independently of render_graph.rs
• RenderContext is defined in render_graph.rs but used by renderer.rs
• Hard to refactor rendering pipeline

Root Cause:

• renderer.rs uses RenderGraph to execute passes
• RenderGraph uses RenderContext to pass data to passes
• RenderContext contains TileCache reference

Solution:

// Extract RenderContext to separate module
// context.rs
pub struct RenderContext<'a> {
    pub cache: &'a TileCache,
    // ...
}

// renderer.rs
use crate::context::RenderContext;

// render_graph.rs
use crate::context::RenderContext;

---

4. Dependency Depth Analysis

4.1 Dependency Depth Matrix

Definition: Dependency depth = longest path from module to leaf (module with no dependencies)

ID	Module	Depth	Path to Leaf
M01	view	7	view → viewport → geometry → tile → cache → scheduler → tile_decode → mvt_parser
M02	viewport	2	viewport → geometry → tile
M03	cache	2	cache → geometry → tile
M04	scheduler	3	scheduler → viewport → geometry → tile
M05	geometry	0	(leaf)
M06	label	2	label → geometry → tile
M07	style	1	style → geometry
M08	style_json	2	style_json → style → geometry
M09	mvt_parser	2	mvt_parser → geometry → tile
M10	overpass_parser	2	overpass_parser → geometry → tile
M11	tile_decode	3	tile_decode → mvt_parser → geometry → tile
M12	renderer	3	renderer → cache → geometry → tile
M13	render_graph	4	render_graph → renderer → cache → geometry → tile
M14	sprite	2	sprite → geometry → tile
M15	tile_disk	1	tile_disk → tile
M16	tile	1	tile → geometry
M17	asset_loader	1	asset_loader → tile
M18	tessellation	2	tessellation → geometry → tile
M19	label_state	2	label_state → geometry → tile

Maximum depth: 7 (view.rs)
Average depth: 2.2
Median depth: 2

4.2 Dependency Depth Distribution

Depth 0: 1 module  (5%)   - geometry
Depth 1: 4 modules (21%)  - style, tile_disk, tile, asset_loader
Depth 2: 10 modules (53%) - viewport, cache, label, mvt_parser, overpass_parser, sprite, tessellation, label_state
Depth 3: 3 modules (16%)  - scheduler, tile_decode, renderer
Depth 4: 1 module  (5%)   - render_graph
Depth 5: 0 modules (0%)
Depth 6: 0 modules (0%)
Depth 7: 1 module  (5%)   - view

Problem: view.rs has depth 7, which is too deep. This makes it hard to understand and test.

Recommendation: Flatten dependency graph to maximum depth 3.

---

5. Dependency Clusters

5.1 Cluster Analysis

Using community detection algorithm, we identified 4 clusters:

Cluster 1: Core Geometry (5 modules)

geometry.rs (1968 L)
tile.rs (303 L)
tessellation.rs (595 L)
sprite.rs (433 L)
tile_disk.rs (204 L)

Characteristics:

• Low-level geometry operations
• No external dependencies
• Highly reused by other clusters

Issues:

• geometry.rs is too large (1968 lines)
• Mixed responsibilities (projections, tessellation, transforms)

Cluster 2: Data Processing (5 modules)

mvt_parser.rs (701 L)
overpass_parser.rs (282 L)
tile_decode.rs (361 L)
label.rs (1098 L)
label_state.rs (487 L)

Characteristics:

• Parse and transform tile data
• Depend on Cluster 1 (geometry)
• Provide data to Cluster 3

Issues:

• label.rs is too large (1098 lines)
• Mixed responsibilities (extraction, placement, rendering)

Cluster 3: Rendering Pipeline (4 modules)

renderer.rs (255 L)
render_graph.rs (418 L)
style.rs (496 L)
style_json.rs (3242 L)

Characteristics:

• Render tiles to screen
• Depend on Cluster 1 (geometry) and Cluster 2 (data)
• Used by Cluster 4

Issues:

• style_json.rs is too large (3242 lines)
• Mixed responsibilities (parsing, validation, compilation)

Cluster 4: Application Layer (5 modules)

view.rs (1075 L)
viewport.rs (538 L)
cache.rs (716 L)
scheduler.rs (849 L)
asset_loader.rs (124 L)

Characteristics:

• High-level application logic
• Depend on all other clusters
• User-facing

Issues:

• view.rs is a god object (1075 lines)
• Circular dependencies between modules
• Mixed responsibilities (UI, state, rendering, networking)

5.2 Cluster Dependency Graph

┌─────────────────────────────────────────────────────────────┐
│                    Cluster 4: Application                    │
│  view.rs, viewport.rs, cache.rs, scheduler.rs, asset_loader │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ uses
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                   Cluster 3: Rendering                       │
│  renderer.rs, render_graph.rs, style.rs, style_json.rs      │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ uses
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                 Cluster 2: Data Processing                   │
│  mvt_parser.rs, overpass_parser.rs, tile_decode.rs,         │
│  label.rs, label_state.rs                                   │
└─────────────────────────────────────────────────────────────┘
                              │
                              │ uses
                              ▼
┌─────────────────────────────────────────────────────────────┐
│                  Cluster 1: Core Geometry                    │
│  geometry.rs, tile.rs, tessellation.rs, sprite.rs,          │
│  tile_disk.rs                                               │
└─────────────────────────────────────────────────────────────┘

Observation: Clusters are reasonably well-separated, but there are circular dependencies within Cluster 4.

---

6. Critical Path Analysis

6.1 Critical Path Definition

Critical path: Longest path from entry point (view.rs) to leaf module

Critical path:

view.rs (1075 L)
    ↓
viewport.rs (538 L)
    ↓
geometry.rs (1968 L)
    ↓
tile.rs (303 L)
    ↓
cache.rs (716 L)
    ↓
scheduler.rs (849 L)
    ↓
tile_decode.rs (361 L)
    ↓
mvt_parser.rs (701 L)

Total lines on critical path: 6,511 lines (46% of codebase)

Problem: Changes to any module on the critical path can affect the entire application.

6.2 Critical Path Risks

Module	Lines	Risk	Impact
geometry.rs	1968	HIGH	Changes affect 17 modules
view.rs	1075	HIGH	Entry point, god object
scheduler.rs	849	MEDIUM	Network + scheduling logic
cache.rs	716	MEDIUM	State management
mvt_parser.rs	701	LOW	Isolated parsing logic
viewport.rs	538	LOW	Isolated state management
tile_decode.rs	361	LOW	Orchestration only
tile.rs	303	LOW	Type definitions only

6.3 Critical Path Mitigation

Recommendations:

1. Split geometry.rs into smaller modules (projections, tessellation, transforms)
2. Split view.rs into Controller + Renderer + Network
3. Extract TileAction enum to separate module
4. Add integration tests for critical path modules
5. Document critical path in architecture documentation

---

7. Dependency Hotspots

7.1 Hotspot Definition

Hotspot: Module with high dependency count AND high change frequency

Assumption: Modules with more dependencies are more likely to change.

7.2 Hotspot Analysis

Rank	Module	Dependencies	Dependents	Total	Hotspot Score
1	view.rs	18	0	18	CRITICAL
2	geometry.rs	0	17	17	CRITICAL
3	tile.rs	1	15	16	HIGH
4	label.rs	2	7	9	MEDIUM
5	style.rs	1	7	8	MEDIUM
6	cache.rs	2	5	7	MEDIUM
7	renderer.rs	7	2	9	MEDIUM
8	render_graph.rs	7	1	8	MEDIUM

Hotspot Score Formula: dependencies * 2 + dependents

7.3 Hotspot Mitigation

CRITICAL hotspots:

1. view.rs - Split into smaller components
2. geometry.rs - Split into smaller modules

HIGH hotspots: 3. tile.rs - Extract types to separate module

MEDIUM hotspots: 4. label.rs - Split into extraction + placement 5. style.rs - OK as-is 6. cache.rs - OK as-is 7. renderer.rs - OK as-is 8. render_graph.rs - OK as-is

---

8. Recommendations

8.1 Immediate Actions (Phase 1)

1. Break circular dependencies

   • Extract TileAction enum to actions.rs
   • Extract shared types to types.rs
   • Extract RenderContext to context.rs

2. Document dependencies

   • Add module-level documentation
   • Create dependency diagrams
   • Document circular dependencies

8.2 Short-term Actions (Phase 2)

1. Split large modules

   • Split geometry.rs into 4 modules
   • Split style_json.rs into 3 modules
   • Split label.rs into 3 modules
   • Split view.rs into 4 components

2. Flatten dependency graph

   • Reduce maximum depth from 7 to 3
   • Reduce average dependencies per module from 4.2 to 2.5

8.3 Long-term Actions (Phase 3+)

1. Add architectural tests

   • Test for circular dependencies
   • Test for maximum dependency depth
   • Test for maximum module size

2. Regular dependency reviews

   • Quarterly dependency analysis
   • Track dependency growth over time
   • Identify new hotspots

---

9. Metrics Dashboard

9.1 Current Metrics

Total modules: 19
Total lines: 14,182
Average lines per module: 746
Median lines per module: 496

Total dependencies: 80
Average dependencies per module: 4.2
Median dependencies per module: 3

Maximum dependency depth: 7
Average dependency depth: 2.2
Median dependency depth: 2

Circular dependencies: 3
Critical hotspots: 2
High hotspots: 1
Medium hotspots: 5

9.2 Target Metrics (After Phase 2)

Total modules: 30 (+58%)
Total lines: 14,182 (same)
Average lines per module: 473 (-37%)
Median lines per module: 350 (-29%)

Total dependencies: 60 (-25%)
Average dependencies per module: 2.0 (-52%)
Median dependencies per module: 2 (-33%)

Maximum dependency depth: 3 (-57%)
Average dependency depth: 1.5 (-32%)
Median dependency depth: 1 (-50%)

Circular dependencies: 0 (-100%)
Critical hotspots: 0 (-100%)
High hotspots: 0 (-100%)
Medium hotspots: 3 (-40%)

9.3 Metrics Tracking

Tool: Custom script to analyze dependencies

Frequency: Weekly (during Phase 2), Monthly (after Phase 2)

Alerts:

• Circular dependency detected → CRITICAL
• Maximum depth > 5 → HIGH
• Module size > 1000 lines → MEDIUM
• Dependencies per module > 5 → LOW

---

10. Conclusion

The Makepad map codebase has complex interdependencies with several critical issues:

1. 3 circular dependencies that make testing and refactoring hard
2. Maximum dependency depth of 7 (view.rs)
3. 2 critical hotspots (view.rs, geometry.rs)
4. 4 massive modules (> 1000 lines)

However, the dependency structure is salvageable with systematic refactoring:

1. Break circular dependencies by extracting shared types
2. Split large modules into smaller, focused modules
3. Flatten dependency graph to maximum depth 3
4. Reduce average dependencies per module from 4.2 to 2.0

Estimated effort: 4 weeks (Phase 2 of execution plan)

Expected outcome:

• 0 circular dependencies
• Maximum depth 3 (down from 7)
• Average dependencies 2.0 (down from 4.2)
• 0 critical hotspots

---

Appendix A: Dependency Graph (DOT Format)

digraph dependencies {
    rankdir=TB;
    node [shape=box, style=filled, fillcolor=lightblue];
    
    // Modules
    view [label="view.rs\n(1075 L)", fillcolor=red];
    viewport [label="viewport.rs\n(538 L)"];
    cache [label="cache.rs\n(716 L)"];
    scheduler [label="scheduler.rs\n(849 L)"];
    geometry [label="geometry.rs\n(1968 L)", fillcolor=red];
    label [label="label.rs\n(1098 L)", fillcolor=orange];
    style [label="style.rs\n(496 L)"];
    style_json [label="style_json.rs\n(3242 L)", fillcolor=red];
    mvt_parser [label="mvt_parser.rs\n(701 L)"];
    overpass_parser [label="overpass_parser.rs\n(282 L)"];
    tile_decode [label="tile_decode.rs\n(361 L)"];
    renderer [label="renderer.rs\n(255 L)"];
    render_graph [label="render_graph.rs\n(418 L)"];
    sprite [label="sprite.rs\n(433 L)"];
    tile_disk [label="tile_disk.rs\n(204 L)"];
    tile [label="tile.rs\n(303 L)"];
    asset_loader [label="asset_loader.rs\n(124 L)"];
    tessellation [label="tessellation.rs\n(595 L)"];
    label_state [label="label_state.rs\n(487 L)"];
    
    // Dependencies
    view -> viewport;
    view -> cache;
    view -> scheduler;
    view -> geometry;
    view -> label;
    view -> style;
    view -> style_json;
    view -> mvt_parser;
    view -> overpass_parser;
    view -> tile_decode;
    view -> renderer;
    view -> render_graph;
    view -> sprite;
    view -> tile_disk;
    view -> tile;
    view -> asset_loader;
    view -> tessellation;
    view -> label_state;
    
    viewport -> geometry;
    viewport -> tile;
    
    cache -> geometry;
    cache -> tile;
    
    scheduler -> viewport;
    scheduler -> cache;
    scheduler -> tile;
    
    label -> geometry;
    label -> tile;
    
    style -> geometry;
    
    style_json -> style;
    
    mvt_parser -> geometry;
    mvt_parser -> label;
    mvt_parser -> tile;
    
    overpass_parser -> geometry;
    overpass_parser -> label;
    overpass_parser -> tile;
    
    tile_decode -> geometry;
    tile_decode -> label;
    tile_decode -> style;
    tile_decode -> mvt_parser;
    tile_decode -> overpass_parser;
    tile_decode -> tile;
    
    renderer -> cache;
    renderer -> geometry;
    renderer -> label;
    renderer -> style;
    renderer -> tile;
    renderer -> tessellation;
    renderer -> label_state;
    
    render_graph -> cache;
    render_graph -> geometry;
    render_graph -> label;
    render_graph -> style;
    render_graph -> renderer;
    render_graph -> tile;
    render_graph -> tessellation;
    render_graph -> label_state;
    
    sprite -> geometry;
    sprite -> tile;
    
    tile_disk -> tile;
    
    tile -> geometry;
    
    asset_loader -> tile;
    
    tessellation -> geometry;
    tessellation -> tile;
    
    label_state -> geometry;
    label_state -> label;
    label_state -> tile;
    
    // Circular dependencies (red edges)
    edge [color=red, style=bold];
    view -> cache [label="circular", dir=both];
    scheduler -> cache [label="circular", dir=both];
    renderer -> render_graph [label="circular", dir=both];
}

Visualization: Use Graphviz to render:

dot -Tpng dependencies.dot -o dependencies.png

---

Appendix B: Dependency Analysis Script

#!/usr/bin/env python3
"""
Analyze module dependencies in Makepad map codebase.
"""

import os
import re
from collections import defaultdict, deque
from typing import Dict, List, Set, Tuple

def find_modules(src_dir: str) -> Dict[str, str]:
    """Find all Rust modules in src directory."""
    modules = {}
    for root, dirs, files in os.walk(src_dir):
        for file in files:
            if file.endswith('.rs'):
                module_name = file[:-3]
                module_path = os.path.join(root, file)
                modules[module_name] = module_path
    return modules

def extract_dependencies(module_path: str) -> Set[str]:
    """Extract dependencies from a Rust module."""
    dependencies = set()
    with open(module_path, 'r') as f:
        content = f.read()
    
    # Find use statements
    use_pattern = r'use\s+(?:super::)?(\w+)'
    for match in re.finditer(use_pattern, content):
        dependencies.add(match.group(1))
    
    return dependencies

def build_dependency_graph(modules: Dict[str, str]) -> Dict[str, Set[str]]:
    """Build dependency graph from modules."""
    graph = defaultdict(set)
    for module_name, module_path in modules.items():
        dependencies = extract_dependencies(module_path)
        graph[module_name] = dependencies
    return graph

def find_circular_dependencies(graph: Dict[str, Set[str]]) -> List[List[str]]:
    """Find all circular dependencies in the graph."""
    circular = []
    visited = set()
    path = []
    path_set = set()
    
    def dfs(node: str):
        if node in path_set:
            # Found circular dependency
            cycle_start = path.index(node)
            circular.append(path[cycle_start:] + [node])
            return
        
        if node in visited:
            return
        
        visited.add(node)
        path.append(node)
        path_set.add(node)
        
        for neighbor in graph.get(node, []):
            dfs(neighbor)
        
        path.pop()
        path_set.remove(node)
    
    for node in graph:
        dfs(node)
    
    return circular

def calculate_dependency_depth(graph: Dict[str, Set[str]]) -> Dict[str, int]:
    """Calculate dependency depth for each module."""
    depths = {}
    
    def get_depth(node: str, visited: Set[str]) -> int:
        if node in depths:
            return depths[node]
        
        if node in visited:
            return 0  # Circular dependency
        
        visited.add(node)
        
        if not graph.get(node):
            depths[node] = 0
            return 0
        
        max_depth = 0
        for neighbor in graph[node]:
            depth = get_depth(neighbor, visited)
            max_depth = max(max_depth, depth + 1)
        
        depths[node] = max_depth
        visited.remove(node)
        return max_depth
    
    for node in graph:
        get_depth(node, set())
    
    return depths

def main():
    src_dir = 'crates/apps/map/src'
    modules = find_modules(src_dir)
    graph = build_dependency_graph(modules)
    
    print(f"Total modules: {len(modules)}")
    print(f"Total dependencies: {sum(len(deps) for deps in graph.values())}")
    
    circular = find_circular_dependencies(graph)
    print(f"\nCircular dependencies: {len(circular)}")
    for cycle in circular:
        print(f"  {' -> '.join(cycle)}")
    
    depths = calculate_dependency_depth(graph)
    print(f"\nMaximum dependency depth: {max(depths.values())}")
    print(f"Average dependency depth: {sum(depths.values()) / len(depths):.2f}")
    
    # Find hotspots
    dependency_counts = {node: len(deps) for node, deps in graph.items()}
    dependent_counts = defaultdict(int)
    for node, deps in graph.items():
        for dep in deps:
            dependent_counts[dep] += 1
    
    print("\nTop 5 hotspots:")
    hotspots = sorted(
        modules.keys(),
        key=lambda m: dependency_counts.get(m, 0) * 2 + dependent_counts.get(m, 0),
        reverse=True
    )[:5]
    for module in hotspots:
        deps = dependency_counts.get(module, 0)
        dependents = dependent_counts.get(module, 0)
        print(f"  {module}: {deps} dependencies, {dependents} dependents")

if __name__ == '__main__':
    main()

Usage:

python3 analyze_dependencies.py

---

END OF PHASE 0: MODULE DEPENDENCY GRAPH