Separate Python production deps from dev deps

The PEP 735 `[dependency-groups]` parser fix (PR #199) reads all dependency groups into a flat list that feeds framework, database, and auth detection. Test dependencies from `[dependency-groups]` contaminate stack identity: fastapi shows `framework=Flask` + `auth=JWT`, pydantic shows `database=SQLAlchemy`, reflex shows `framework=FastAPI` (all from dev deps, none production). This is a regression — we made Python scanning worse in an attempt to make it better. Must ship before 1.1.3 bump.

verdict PASSscore 19 / 19findings 5 (1 risk · 1 debt · 3 obs)duration 41mrejection cycles 0shipped May 22, 2026surface cli

Pipeline timeline

Intent to proven code in 41m across Think, Plan, Build, and Verify.

Think
6m
Plan
6m
Build
8m
Verify
6m

Assertion ledger

19 claims, each independently verified. Showing 8 — show all →

IDSaysMatcher
A001PEP 621 production dependencies land in the production bucketverifiedok
A002PEP 735 dependency-groups land in the dev bucket, not productionverifiedok
A003PEP 735 dependencies never contaminate the production listverifiedok
A004Optional dependencies are production extras, not devverifiedok
A005Poetry main dependencies land in productionverifiedok
A006Poetry group dependencies land in production (deferred split)verifiedok
A007The combined reader provides both production and all-deps viewsverifiedok
A008All-deps includes both production and dev dependenciesverifiedok

Findings 5 total

debtpackages/cli/src/engine/scan-engine.tsmonitor
readPythonDependencies called twice for Python projects — line 673 (production) and line 76 inside detectNonNodeTesting (all), both performing fresh filesystem reads of the same pyproject.toml
obspackages/cli/src/engine/parsers/python/pyproject.tsclosed
Strategy execution order in pyproject.ts is 1,2,5,3,4 — Strategy 5 (dependency-groups → dev) placed between Strategy 2 and 3, breaking numeric sequence
obsclosed
Spec predicted Strategy 1 cross-match for dependency-group named 'dependencies' but match() returns only first occurrence — no cross-match occurs. Spec Gotchas section is inaccurate.
riskpackages/cli/src/engine/parsers/python/pyproject.tsclosed
TOML inline comments after closing bracket (e.g., `] # end`) would break `]\s*$` anchor — still present from prior cycle
obspackages/cli/tests/engine/parsers/python.test.tsclosed
A013 tested at two levels — parsePyprojectToml checks result.dev (proxy), readPythonDependencies checks result.all (direct). Both pass but the parser-level test is indirect.

Integrity seal

scopesha256:0f87aa0e213e3...
contractsha256:ed8c7fe47c207...
plansha256:3923e75bd8db7...
specsha256:5cd3ea6f8ce2a...
build-reportsha256:3c6e6ff018ceb...
build-datasha256:90d66986a418b...
verify-reportsha256:4790b4636d8e6...
verify-datasha256:0beecdef314ca...
audit cmd$ ana proof audit fix-python-dep-separation   → all hashes match