audit: DESC-05 reports 0 direct dependencies — PEP 621 [project].dependencies not parsed

[ArtRomanov]

Summary

DESC-05 (direct-dependency count) reports 0 direct dependencies for a project whose pyproject.toml declares 14. The manifest is found and listed — only the parse of its contents returns nothing.

Observed on a full audit run of provectus-barhopping/wort (engine output committed in that repo under context/audits/2026-07-13_17-44-33/).

Evidence

descriptors.json — DESC-05:

{
  "check_id": "DESC-05",
  "status": "INFO",
  "method": "computed",
  "value": {
    "total_direct_deps": 0,
    "by_manifest": { ".../wort/pyproject.toml": 0 }
  },
  "evidence": ["0 direct dependencies across 1 manifest"]
}

Ground truth — wort/pyproject.toml:

[project]
dependencies = [
    "fastapi>=0.136,<1",
    "uvicorn[standard]>=0.44,<1",
    "sqlalchemy[asyncio]>=2.0,<3",
    "asyncpg>=0.31,<1",
    "alembic>=1.18,<2",
    "pydantic-settings>=2.13,<3",
    "slack-bolt>=1.28,<2",
    "aiohttp>=3.13,<4",
    "boto3>=1.42,<2",
    "structlog>=25.5,<26",
    "httpx>=0.28,<1",
    "fastmcp>=3.2,<4",
    "pymupdf4llm>=1.27,<2",
    "python-docx>=1.2,<2",
]

14 entries under PEP 621 [project].dependencies, plus a 6-entry PEP 735 [dependency-groups].dev. The manifest path resolved correctly, so discovery works and extraction is what fails. Worth checking whether the parser only looks at Poetry-style [tool.poetry.dependencies] and misses [project].dependencies.

Downstream impact

Three different dependency counts appear in one audit run, all derived from the same single manifest:

Location	Count
DESC-05 value + report.md "Code Scale"	0
SCS-03 recommendation text	8
Actual pyproject.toml	14

Two consequences beyond the wrong number:

1. report.md publishes it. The Code Scale section renders **Direct dependencies:** 0 direct deps, which reads as "vendored / no third-party code" for a service built on FastAPI, SQLAlchemy and boto3.
2. SCS-03 is materially wrong, not just miscounted. The recommendation states "all 8 direct dependencies use open-ended version ranges in pyproject.toml … a dependency can silently re-resolve to a newer version between builds" and is filed P1. Every one of the 14 declarations is upper-bounded (>=0.136,<1), so the described failure mode cannot occur across a major boundary. The check appears to be reasoning about a dependency set it never successfully read.

If SCS-03 consumes DESC-05's output, fixing the parser may resolve both. If it parses independently, they are two bugs with a shared root cause.

Suggested handling

• Parse PEP 621 [project].dependencies and PEP 735 [dependency-groups] in addition to whatever is currently matched.
• Consider failing loudly rather than emitting 0: a manifest that is located but yields zero dependencies is far more likely a parser miss than a genuinely dependency-free project. An INFO check that silently reports 0 propagates into narrative text with no signal that it is unverified.

Secondary note

DESC-05.by_manifest keys on an absolute filesystem path from the machine that ran the audit (/Users/<name>/provectus/provectus-barhopping/wort/pyproject.toml). Since audit artifacts are intended to be committed, this leaks a local username and directory layout into version control. Repo-relative paths would avoid it. Happy to split this into its own issue if preferred.

Environment

• Engine version: whatever produced the 12-dimension / JSON output (newer than the marketplace 2.1.0 cached locally, which is 9 dimensions and Markdown-only)
• Audited project: Python, single pyproject.toml, uv-managed, uv.lock present

[ArtRomanov]

Located the exact cause on current main (a98d515) — the check still reproduces at 2.4.2.

skills/ai-readiness-audit/metrics/dependency_count.ts, in parsePyprojectToml:

if (trimmed.startsWith('[')) {
  inDepsSection =
    trimmed === '[project.dependencies]' ||
    trimmed === '[tool.poetry.dependencies]' ||
    trimmed === '[tool.poetry.dev-dependencies]' ||
    trimmed === '[project.optional-dependencies]';
  continue;
}

PEP 621 is handled, but as a table header. It is not one — dependencies is an array-valued key inside the [project] table:

[project]
name = "wort"
dependencies = [
    "fastapi>=0.136,<1",
]

[project.dependencies] never appears in a PEP 621 manifest, so the branch cannot match. Worse, the literal [project] header hits the same if and sets inDepsSection = false, so every dependency line that follows is skipped by the if (!inDepsSection) continue; guard. Result is a silent 0.

Same applies to [project.optional-dependencies]: that one is a real table, but its values are arrays keyed by group name, so the current line counter would count group headers rather than dependencies. PEP 735 [dependency-groups] is not matched at all.

This means the metric only works for Poetry-style manifests. Any project on modern uv / hatch / pdm / setuptools-with-PEP-621 reports 0 direct dependencies.

Suggested fix: parse the file as TOML rather than line-scanning, then read project.dependencies (array), project.optional-dependencies (table of arrays), and dependency-groups (table of arrays) alongside the existing Poetry paths. Corrects the count and removes the header/key ambiguity that caused this.

Correcting my own framing in the issue body above: I originally guessed the parser only looked at [tool.poetry.dependencies]. It does attempt PEP 621 — the bug is that it looks for it in the wrong shape.

[ArtRomanov]

Filed #163 for the sibling defect in detectors/supply_chain_security.ts (SCS-03). Different parser, different failure — that one handles PEP 621 correctly and then truncates the dependency array at the first ], which is the one closing an extras marker like uvicorn[standard].

Both would be resolved by the same change: parse the manifest as TOML and share one reader between the two checks, rather than maintaining two independent line scanners that disagree with each other and with the file.

[ArtRomanov]

Split the absolute-path note out of this issue into #165, since it is about the by_manifest key rather than the dependency count, and can be fixed independently of the PEP 621 reader.