[high] Nested function decisions inflate the enclosing function metric

[gingercakedev-bot]

Nested function decisions inflate the enclosing function metric

Severity	high
Confidence	99% (confirmed)
Kind	edge-case
Location	src/parsers/shared/metrics-base.ts → computeComplexity
Module	src/parsers/shared
Finding ID	f-0f382d

Failure scenario

For Python outer containing an inner function whose body has an if and while, outer is reported with complexity 3 even though its own executable control flow has complexity 1. The same unrestricted traversal also makes computeNestingDepth attribute nested-function control flow to the enclosing function.

Evidence

src/parsers/python/py-parser.ts:243-249 selects each top-level function_definition, then src/parsers/python/py-parser.ts:269-271 computes its metrics. src/parsers/python/py-metrics.ts:11-24 delegates complexity to the shared walker with Python decision types including if_statement and while_statement; src/parsers/shared/metrics-base.ts:16-17 starts at the outer body, while line 14 recursively visits every named descendant without stopping at nested function_definition nodes. The nesting walker has the same unrestricted recursion at src/parsers/shared/metrics-base.ts:30-33. Thus decisions inside a nested function are assigned to its enclosing function.

Reproduction

Create nested.py containing def outer():\n def inner():\n if x:\n while y:\n pass\n return 1\n, then run codemap generate and query outer. It is reported with complexity 3 and nesting depth 2, although outer itself has no control-flow decisions.

Suggested fix direction

Teach the shared walkers to stop at nested executable-scope boundaries, supplied per language; Python should pass at least function_definition and lambda. Add one focused Python parser regression test asserting that outer remains complexity 1 and nesting depth 0.

Why this matters here

Per-function metrics feed Codemap’s health and hotspot analysis, so isolating each function’s control flow prevents misleading complexity reports.

Suggested test

Parse def outer():\n def inner():\n if True:\n while True: pass; assert computePyComplexity(outer) is 1 and computePyNestingDepth(outer) is 0.

---

How to work this issue

Open a Claude Code session in this repo and say
"work the dev-cli finding f-0f382d in src/parsers/shared/metrics-base.ts".

Start from the evidence above rather than re-investigating: it was produced by reading this
exact commit. Done means the suggested test fails before your change and passes after, and the
next scan marks the finding fixed.

If this is not a real defect, close the issue with the false-positive label — dev-cli
records the fingerprint and will never raise it again. Closing it without that label marks the
finding fixed instead.

_{Raised by dev-cli · repo codemap-cli · branch main · commit c8cf294 · scan 2026-08-15T14-12-31 · fingerprint 0f382d3b3262}