ASP Project — Code Analysis Report

Auto Service Planning domain engine · Generated 2026-04-29 · 801 commits · main branch · Excludes fixtures, docs, migrations, data files, markdown, config (TOML/YAML/JSON), Dockerfiles

Language Breakdown

Language	Files	Code	Comments	Blanks	Total	Complexity	Share
Python	358	74,979	16,925	9,109	101,013	3,549	70.9%
TypeScript	162	24,810	1,433	2,820	29,063	2,916	23.5%
HTML	38	4,080	123	423	4,626	0	3.9%
JavaScript	9	1,052	115	97	1,264	167	1.0%
CSS	2	515	67	90	672	0	0.5%
Makefile	2	158	184	53	395	81	0.1%
BASH	1	159	46	38	243	49	0.2%

Module Breakdown

Module	Files	Code	Comments	Complexity	Comment Ratio	Share
Domain Engine (asp/)	107	13,792	7,953	1,255	36.6%	13.0%
Test Suite (tests/)	113	30,899	3,140	717	9.2%	29.2%
Django Server (server/)	167	32,454	5,688	1,614	14.9%	30.7%
Workbench Frontend	142	22,699	1,111	2,731	4.7%	21.5%
Scripts & Audits	7	1,229	305	130	19.9%	1.2%

Complexity Analysis (per function)

Cyclomatic complexity measures the number of independent paths through a function — each if, for, except, or case adds one path. Lower is simpler. This project enforces a per-function limit of 10 (McCabe / NIST standard) via radon. Measured across 2,005 production Python functions (tests and seeders excluded — assertion-heavy and linear field population by design).

99.1%

Functions ≤10

McCabe/NIST threshold

2.8

Average Complexity

2,005 functions

Median Complexity

50th percentile

95th Percentile

Hotspot indicator

Highest Function

_assemble_reservation_intents

≤10

Per-Function Limit

Enforced by radon

Grade	Complexity Range	Description	Functions	Distribution
A	1-5	Simple	1732	86.4%
B	6-10	Well-structured	255	12.7%
C	11-15	Moderate	18	0.9%
D	16-20	Complex	0	0.0%
E	21-50	High risk	0	0.0%
F	51+	Unmaintainable	0	0.0%

How to Read This Section

What this measures:
Each number is the cyclomatic complexity of a single function or method, measured by radon (the industry-standard McCabe implementation for Python — same algorithm used by SonarQube, Code Climate, and NDepend). The McCabe/NIST recommended threshold is ≤10 per function — this project enforces it via radon on every commit (pre-commit hook). Grades follow radon’s standard scale: A (simple) through F (unmaintainable).

Why per-function, not aggregate:
Some tools report a project-wide total (e.g. “5,053”) — this is misleading because it grows with codebase size regardless of quality. The industry standard (SonarQube, Code Climate) is to report the distribution: what percentage of functions fall under the threshold, plus median and 95th percentile to identify hotspots.

Key Ratios

2.2:1

Test-to-Domain Ratio

18%

Comment Density

184

Avg LOC / File

99.1%

Functions ≤10 Complexity

30% / 70%

Domain / Server Split

2.0:1

Backend : Frontend

Development Cost & Effort Estimation

Based on the Basic COCOMO model (organic mode, Boehm 1981). COCOMO is an industry-standard formula that estimates the effort, time, and cost to build software from scratch based on its size in lines of code. 📖 What is COCOMO? (Wikipedia) 🎓 COCOMO Explained (GeeksforGeeks)

$3.61M

Estimated Total Cost

Fully-loaded cost iSalary ($56,286/yr) multiplied by 2.4× to cover the real cost of employment: benefits, office space, equipment, management, HR, training, and admin overhead. Industry standard — total cost is typically 2–3× base salary.

22.4 months

Schedule Estimate

Elapsed calendar time

320.4 months

Person-Months Effort

~26.7 person-years

14.3

Team Size Required

Average developers

Estimated Cost by Module

Effort & Team Size by Module

Module	SLOC iSource Lines of Code — actual code lines, excluding blanks and comments. This is what COCOMO uses as input.	Est. Cost iEstimated cost to build from scratch, using average salary ($56,286/yr) multiplied by 2.4× overhead (benefits, facilities, management, equipment, HR).	Schedule iCalendar months of elapsed wall-clock time. Not additive — modules are built in parallel by a team.	Person-Mo iPerson-Months — total human effort. If 3 developers work for 4 months, that equals 12 person-months. This IS additive across modules.	Team Size iAverage number of developers needed simultaneously. Calculated as Person-Months ÷ Schedule.	$/SLOC iCost per source line of code. Roughly consistent (~$30) because COCOMO scales nearly linearly at this codebase size.	Share
Domain Engine	13,792	$424,819	9.93	37.74	3.80	$30.80	13.0%
Test Suite	30,899	$990,916	13.71	88.03	6.42	$32.07	29.2%
Django Server	32,454	$1,043,343	13.98	92.69	6.63	$32.15	30.7%
Workbench Frontend	22,699	$716,807	12.12	63.68	5.25	$31.58	21.5%
Scripts & Audits	1,229	$33,545	3.79	2.98	0.79	$27.29	1.2%
Total	105,753	$3,606,639	22.39	320.42	14.31	—	100%

Understanding These Estimates

What is COCOMO?
COCOMO (Constructive Cost Model) is the most widely-used software cost estimation model, created by Barry Boehm in 1981. It takes the number of lines of code and applies empirically-derived formulas to estimate how many person-months of effort, calendar months, and developers it would take to build the software from scratch. The “organic” mode used here assumes a small-to-medium team working with familiar technology.

The formulas (COCOMO Basic, organic mode):
Effort = 2.4 × (KSLOC)^1.05 person-months
Schedule = 2.5 × (Effort)^0.38 months
Team = Effort ÷ Schedule
Cost = Effort × ($56,286/yr salary × 2.4× overhead)
KSLOC = thousands of source lines of code

Why Schedule = 2.5 × Effort^0.38?
Development time grows with effort, but not in a straight line. Why not just Time = Effort ÷ People? Because that assumes work is perfectly divisible — which software work is not. Just as 10 chefs cannot cook a meal in 1/10th the time (they’d be tripping over each other in the kitchen), adding developers speeds things up but also adds communication overhead, coordination delays, and dependencies between tasks. The 0.38 exponent captures this: as effort goes up, time goes up too — but slower, because some work runs in parallel. The 2.5 constant is a calibration factor derived by Barry Boehm from 63 real projects, anchoring the formula to match observed durations.

What is the 2.4× overhead?
The COCOMO model multiplies raw salary by 2.4× to reflect the fully-loaded cost of employment. This covers: office space and facilities, health insurance and benefits, management and HR, equipment and software licenses, training, recruitment, and administrative overhead. The 2.4× multiplier is a standard industry figure — in practice, the total cost of a developer to a company is typically 2–3× their base salary.

What it doesn't capture:
AI-assisted development, domain expertise ramp-up, data fixture creation, deployment infrastructure, or the 801 commits of iterative refinement and domain expert consultation across the project lifetime.

Actual vs estimated:
This 105,753 SLOC codebase was built by 1 developer + AI in ~35 days (801 commits since 2026-03-25). COCOMO estimates 14.3 developers over 22.4 months — demonstrating significant productivity leverage from AI-assisted domain-driven development.

Productivity Metrics

801

Total Commits

Since 2026-03-25

~35 days

Actual Dev Time

vs 22.4 months with 14.3 devs

3,021

LOC per Day

Code lines only

22.9

Commits per Day

Atomic commits

132

Avg LOC / Commit

Code lines only

~274x

Productivity Multiplier

vs COCOMO baseline

Top 25 Largest Files

#	File	Lang	Code	Comments	Cmplx
1	server/core/admin.py	Python	3,163	98	64
2	server/network/sinks.py	Python	2,559	536	91
3	server/sandbox/views.py	Python	2,286	154	138
4	tests/django/network/test_network_seeder.py	Python	2,197	408	111
5	tests/domain/p2p_planning/test_regen_services.py	Python	1,831	222	31
6	tests/django/django_models/test_django_repositories.py	Python	1,550	192	21
7	tests/domain/architecture_classification/test_services.py	Python	1,404	99	40
8	tests/django/django_models/test_dual_repo_parity.py	Python	1,320	36	5
9	server/engine/test_contract.py	Python	1,190	55	23
10	tests/domain/equipment/test_services.py	Python	1,180	29	3
11	asp/p2p_planning/infrastructure/django_repositories.py	Python	1,078	102	38
12	workbench-v2/frontend/src/components/PlanDetailPage.tsx	TypeScript	1,038	2	139
13	tests/django/django_models/test_core_models.py	Python	902	24	18
14	workbench-v2/frontend/src/__tests__/fixtures.ts	TypeScript	893	17	0
15	server/network/baseline_ort.py	Python	845	571	54
16	asp/equipment/infrastructure/django_repositories.py	Python	833	221	77
17	workbench-v2/frontend/src/components/Graph.tsx	TypeScript	805	64	164
18	tests/domain/p2p_planning/test_services.py	Python	804	36	10
19	server/engine/django_seeder.py	Python	796	94	20
20	server/engine/sandbox_response_shapes.py	Python	771	55	0
21	workbench-v2/frontend/src/components/delivery-view/deliveryPageTransform.ts	TypeScript	767	23	255
22	tests/domain/p2p_planning/test_intra_routing_walker.py	Python	732	23	3
23	asp/p2p_planning/domain/regen_slice_walker.py	Python	728	194	55
24	server/network/baseline_builder.py	Python	728	194	19
25	workbench-v2/frontend/src/types.ts	TypeScript	728	25	0