fix(coverage): Stop claiming complete coverage on symbol-level languages

[JordanCoin]

First of the Graph accuracy milestone (#172). Fixes #148.

What was wrong

Coverage was derived from one question: did the scanner run? ast-grep parses Swift fine — #148 notes 1068 functions extracted correctly — so the source came back authoritative and coverage came back complete.

But the edge model is what doesn't apply. In Swift, Kotlin, Java, C# and Scala an import names a module, package or namespace, never a file, and two files in the same package reference each other with no import statement at all. So resolving imports yields SwiftUI, Foundation, System.Text — names belonging to no file in the project — and the graph comes back structurally empty rather than empty-by-accident.

Pairing that with complete is what makes it the worst of the bugs: a consumer reads "complete" beside zero dependents and concludes a change is isolated, when nothing capable of finding those edges ever ran.

The fixture that proves it

testdata/symbol-imports-swift/ — three Swift files where UserViewModel references User from Models.swift, with no import between them, exactly as Swift requires. On main today:

"coverage": {"status": "complete", "sources": [{"name": "ast-grep", "status": "authoritative"}], "issues": []}

Zero edges, full confidence. After:

"coverage": {"status": "partial", "sources": [
  {"name": "ast-grep", "status": "authoritative"},
  {"name": "symbol-imports/swift", "status": "unavailable",
   "detail": "Swift (3 files): imports name modules, not files, and same-package files need no import: intra-project edges need symbol-reference resolution and are not represented"}
]}

--importers inherits it, which also answers the shape of #138 — "No files import X" no longer stands alone when the graph cannot know:

No files import Sources/App/Models.swift.
Coverage: partial — Swift: imports name modules, not files, and same-package files need no import: …

testdata/file-imports-go/ is the counterpart guard, so this never becomes a blanket downgrade: Go imports do resolve to files, so an empty graph there is a real finding.

--importers pkg/user.go  ->  importers: ["main.go"]  (exact)  coverage: complete

TestSwiftFixtureNeverReportsCompleteCoverage is load-bearing — against unmodified filegraph.go it fails with coverage sources [{Name:ast-grep Status:authoritative Detail:}] omit a symbol-imports source naming Swift, which is the bug verbatim.

What changed

scanner/importmodel.go classifies languages by whether an import can resolve to a file. Presence of a symbol-level language downgrades coverage to partial and attaches one source per language with its file count — so the output names which slice it cannot see, rather than emitting a bare partial with nothing to point at. Wired into the graph's provenance, which is where --deps, --importers and blast-radius all read from, plus the newDepsProject default path.

The rule only ever removes confidence: coverage already partial or unavailable keeps its status, and languages with a file-level import model are untouched.

Per-ecosystem summary (for release notes)

Ecosystem	Before	After
Swift, Kotlin, Java, C#, Scala	complete with 0 edges	partial, naming the language and file count
Go, Python, JS/TS, Rust, C/C++, Dart, Ruby, PHP, Lua, Solidity, Bash, CUE	unchanged	unchanged

There is no CHANGELOG in the repo, so this table is the release-note text rather than a file I invented.

Two things I did not do, deliberately

• The false edges. --deps / --importers / blast-radius report coverage: complete on languages with no file-level imports #148's closing note about VendorSDK ───▶ src/Integrations/VendorSDK is real: Strategy 6 in fuzzyResolveWithWorkspace matches a normalized namespace against a directory name, and its comment says it exists for C#. So for these languages codemap can also emit a wrong edge, not just miss them. Removing that is a behavior change for current C# users and deserves its own PR and fixture — say the word and I'll do it next.
• Elixir is not classified. alias MyApp.Foo is module-level, but Mix conventions do map modules to paths, so suffix matching often works. I'd rather leave it resolvable than wrongly mark a working ecosystem degraded.

One side effect you should decide on

testdata/symbol-imports-swift/ contains real .swift files, so codemap . on this repo now reports partial with a Swift note. That statement is true — the repo does contain 3 unresolvable Swift files — but it's noise from fixtures. The natural fix is "exclude": ["testdata"], except .codemap/ is gitignored so it can't ship. The alternative is adding testdata to IgnoredDirs in scanner/walker.go alongside vendor and node_modules, which is a default-behavior change for every user — so I didn't make that call unilaterally. Happy to do either.

Verification

go vet ./... clean. go test ./... at the main baseline (only the three known root-environment permission failures). Fixture behavior verified end-to-end with a built binary for --deps, --deps --json and --importers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PEUvjGsJemDFSV8nbxvxBo

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[JordanCoin]

Pushed e0c07b7, folding in the --importers --json coverage field — it's asked for by both #148's spirit and #173 explicitly, and it turned out to be a bigger hole than "the field is missing".

ImportersReport.CoverageStatus was omitempty, and a complete graph's status is the empty zero value. So the common case emitted nothing, and on main today these two answers are byte-identical:

{"file":"pkg/user.go","importers":null,"importer_count":0,"is_hub":false}   // checked thoroughly, genuinely zero
{"file":"App/Models.swift","importers":null,"importer_count":0,"is_hub":false}   // could not check at all

Now:

{"file":"pkg/user.go",...,"coverage_status":"complete"}
{"file":"Sources/App/Models.swift",...,"coverage_status":"partial","coverage_notes":["Swift: imports name modules, not files, …"]}

One thing worth calling out, because it's a regression I introduced and then caught rather than something the change did cleanly: making the status always present broke TestBlastRadiusOmitsEmptyImporterSections (passes on main, failed with my change). Blast-radius decided whether an importer section was empty by rendering it and checking for whitespace — and now every report renders a Coverage: complete footer, so files with no importers stopped looking empty and started emitting sections. Fixed by deciding on the report's data (len(Importers) == 0 && len(HubImports) == 0) instead of its rendered text, which is the sturdier test anyway.

Full suite back at the baseline (only the three root-environment permission failures); go vet clean.

---

Generated by Claude Code