feat(manifest): attribute direct JVM dependencies to subproject build files

[Jeppe Fredsgaard Blaabjerg (jfblaa)]

LLM Description written by Claude Code:claude-opus-5-5

REA-884. Lets the dashboard answer "which module pulled this in?" for multi-module Maven, Gradle and sbt builds, still with one .socket.facts.json per build.

Requires Coana's REA-883 handling of these marks in socket fix, which ships in @coana-tech/cli 15.12.1, already on v1.x and merged into this branch.

What changes

• Every component that is a direct dependency of at least one subproject gets manifestFiles: {file: ".socket.facts.json"} first, then the build files of the subprojects it is direct in, relative to the facts file (depscan's SF_ManifestReferenceSchema shape). Transitive-only components get no field and keep depscan's default attribution.
• A mark means "pulled in via this subproject", not "declared in this file". Build tools don't report the declaring file, and versions are often inherited, e.g. from a parent POM.
• Build files per tool:
  • Maven: the module's MavenProject.getFile().
  • Gradle: Project.buildFile, only when it exists.
  • sbt: the files inside the build where sbt recorded the project's own settings as defined (setting source positions). A subproject defined in the root build.sbt is marked with it; a root .sbt that only sets ThisBuild values is not.
• A Gradle subproject without its own build file (configured from the root) adds no mark. Gradle records no position for configuration applied from elsewhere.

Compatibility

• The sidecar carries the new field. Coana ≥ 15.11.4 strips unknown keys on sidecar components rather than rejecting them.
• With --reach, Coana rebuilds the output facts from depscan's artifacts, so manifestFiles comes through as depscan resolved it.

Verification

• New assembler test, plus the manifest/scan/utils suites; pnpm run check passes.
• Real runs on small multi-module builds:
  • Maven: a test dependency declared only in the parent POM is marked [.socket.facts.json, a/pom.xml, b/pom.xml, pom.xml].
  • Gradle: only the subproject with its own build file is marked.
  • sbt: a subproject defined in the root build.sbt is marked with it, one with its own .sbt file with that file. On a real sbt 1.5 build, files under project/ that define project settings are marked too.
• Declaration spans (start/end) are out of scope: sbt's dependencyPositions misattributes appended modules. Tracked in REA-886.
• Not run: the build-tool compat matrix (run-compat.sh). Not verified end to end: dashboard display after depscan ingest.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes JVM manifest/SBOM shape and multi-tool record emission; downstream consumers must tolerate the new optional field (older Coana strips unknown keys).

Overview
Multi-module Maven, Gradle, and sbt Socket facts SBOMs now record manifestFiles on each direct dependency: .socket.facts.json first, then build-root-relative paths for subprojects that resolve that dep directly (e.g. a/pom.xml, build.gradle). Transitive-only components omit the field.

Build tools emit a new projectBuild line-protocol record and the assembler maps direct roots → subproject buildFiles → manifestFiles. Maven records each module POM; Gradle uses an on-disk buildFile only; sbt infers files from in-build setting source positions. Subprojects with no own build file contribute no extra path (facts file only when applicable).

A new assembler test and changelog entry document the behavior for dashboard / Coana socket fix module attribution (REA-883).

^{Reviewed by Cursor Bugbot for commit e8d15a6. Configure here.}