MVP pipeline simplification:
- render_rollups() now produces ONLY summary.md + AUDIT_REPORT.md
- run_audit() now produces only per-aggregate .md (no .dsl/.tree)
- New src/code_path_audit_gen.py generates the single coherent report
Stale artifacts moved to _stale/ subdirectory (preserved for history):
- 13 per-aggregate .dsl files (redundant with .md)
- 13 per-aggregate .tree files (redundant with .md)
- 9 old top-level rollups (cross_audit_summary, decomposition_matrix,
candidates, field_usage, call_graph, hot_paths, dead_fields,
ssdl_analysis, organization_deductions - all superseded by sections
inlined in AUDIT_REPORT.md)
- _stale/README.md explains what happened
Meta-audit updated to check .md files (14 required H2 sections per
aggregate) instead of .dsl files. 0 violations on 10 real profiles.
Tests: 131 passing. New MVP report: 5000+ lines.
Three real bugs fixed:
1. FunctionRef always used line=0. Now passes node.lineno from AST.
2. P3_pass results were discarded with bare pass. Now stored in
ProducerConsumerGraph.field_accesses.
3. Field-access detector only saw entry['key']; missed entry.get('key')
which is the dominant pattern in this codebase. Now handles both.
Plus _extract_type_name() helper handles Optional[T], dict[str, T],
list[T], Result[T], Union[T, ...], and T | None (PEP 604) so P1/P2
catch more annotation patterns.
Real numbers (Metadata aggregate):
- producers: 77 -> 117
- consumers: 35 -> 66
- field-access sites: 130 -> 173
- line numbers: all real (line 1281, 1746, etc.)
AUDIT_REPORT.md grew 2009 -> 3140 lines with real evidence.
Total audit output: 5176 lines / 50 files (was 2415 / 49).
All 131 tests still passing.
The 272-line report was a summary, not a report. The user wanted
the actual evidence inlined. This version embeds:
- Full per-aggregate .md profiles (15 sections each)
- Full SSDL analysis rollup
- Full organization deductions
- Full call graph
- Full hot paths
- Full field usage
- Full decomposition matrix
- Full cross-audit summary
- Full dead fields
- Full candidates
- Full top-level summary
Total: 2009 lines. The user can read it as a single document or
grep for specific aggregates/sections.
The audit output is a database dump (49 files, 3 redundant formats
each). The user wanted ONE thing they can read. This is the
narrative version: 1 file that opens with the verdict, walks
through findings by severity, gives the Metadata deep dive, and
ends with prioritized restructuring routes.
Original 49 files (10 top-level rollups + 13 aggregates x 3 formats)
preserved as supporting detail. See Section 10 'See Also' for
the full artifact inventory.
The previous code did Path(src_dir) / function_ref.file, which
double-prefixed (e.g. src/src/project_manager.py) and silently
returned empty. Fixed: if function_ref.file exists as
CWD-relative, use it directly. Only join if it doesn't exist.
Now 130 real field accesses detected across 35 Metadata consumers
in the 2026-06-22 audit output (was 0 before).
The aggregate_findings function now does 3-tier mapping:
1. Function lookup (find_enclosing_function) -> exact match
2. File-level fallback: if the finding's file has any
producer/consumer of the aggregate, bucket it there
3. Unbucketed (the file has no aggregate refs)
Handles both 'file' and 'filename' keys (v1 audit scripts use
'filename'; spec fixtures use 'file'). Path normalization
for Windows paths.
Generated the 6 real audit_inputs from scripts/audit_*.py
against real src/. The Metadata aggregate now shows:
- 1 unique weak_types finding (1 site, from ai_client.py:159)
- 1 unique exception_handling finding (76 sites from PARAM_OPTIONAL)
mcp_client.py shows 0 because no Metadata producer/consumer
exists in the PCG for mcp_client (P1/P2 only detect typed
parameter signatures, not internal field access). The next
gap is expanding P3 to capture internal field use.
Loops over audit_weak_types + audit_exception_handling from
the 6 audit_inputs, calls aggregate_cross_audit_findings per
audit, sums the buckets per profile.
Cross-audit aggregation is per-aggregate-flat (all findings go
into 1 bucket per audit). The 3-tier finding-to-aggregate
mapping (find_enclosing_function + type registry + file
heuristic) is the next gap - requires per-finding site
classification.
13 aggregate profiles (10 real + 3 candidate placeholders)
+ 4 top-level rollups. Per the spec, the 3 candidate
aggregates (ToolSpec, ChatMessage, ProviderHistory) are
forward-compat placeholders for any_type_componentization_20260621
(NOT on master); the audit's report includes them with
is_candidate: True.
ed