release: attach an artifact-scoped component and license inventory to shipped distributions #4343

Priority / classification

P2 · supply-chain traceability proposal. No license violation, vulnerable dependency, or missing legal obligation has been established. The problem is that consumers cannot readily inspect the complete component set of a distributed multi-language binary from the release outputs reviewed here.

Evidence and scope

At 4a7b39b273dac52ebc09c21c3e8f47c091de1daf:

• Root Cargo.toml combines registry dependencies, pinned Git sources (asupersync/Grafeo/grammars), and a local grammar-bundle patch.
• Dashboard package.json adds React, chart/layout libraries and bundled font families.
• CLI build.rs embeds the frontend assets into the binary.
• The inspected beta publication path publishes native archives, MCPBs, SHA256SUMS and install.sh; it does not explicitly emit a component inventory. Repository searches for sbom found no existing implementation or issue, but absence in search is not proof that no external inventory exists.

Implementation design

1. Inventory the actual shipping artifact graph, not every development dependency in Cargo.lock/pnpm-lock. Use the selected Bazel target, platform and feature/language tier as scope; include bundled JavaScript/CSS/fonts, vendored/adapted source and exact Git revisions.
2. Before adding a generator, look for existing release/license tooling and reuse it. Select one established machine-readable format (SPDX or CycloneDX) and keep a small adapter for repository-specific embedded assets. Do not build a compliance platform or maintain a second hand-written dependency registry.
3. Record component identity/version/source, license expression or explicit unknown status, checksums where obtainable, and artifact/source revision. For a fork, retain the actual fork URL/revision instead of falsely labeling it as only the upstream registry release.
4. Incorporate the repository's existing LICENSE/NOTICE/adapted-source information without declaring unsupported legal conclusions. Unknown/custom license metadata becomes an actionable review item, not silently 'MIT'. Separate build-only tooling from distributed content.
5. Publish the inventory as a release asset linked to each relevant final archive/MCPB digest, or include it inside the package before final hashing. Avoid circular self-digest requirements: a detached inventory can reference final packages and be separately attested.
6. Preserve immutable-source/recovery behavior. Regenerating an inventory for an older release must use that release's source and build scope, not today's lockfiles or default branch. Do not mutate retained package bytes to retrofit it.

Verification / acceptance

• A production target inventory distinguishes shipped components from tests/build tooling and includes at least one registry crate, pinned Git crate, bundled npm component, font and vendored/adapted source when present.
• Changing a relevant dependency revision or embedded asset changes the inventory; a dev-only change does not falsely become a shipped component.
• Missing/unknown license/source metadata is explicit and reviewable; no inferred 'all dependencies are compliant' result.
• Repeated generation from the same immutable inputs is deterministic.
• Release consumers can associate the inventory with exact downloaded package digests.
• Existing checksums, provenance verification and missing-target recovery still work.

Delivery boundaries

Land reporting first, review real gaps, then decide which failures should gate releases. Keep signing completion (#4341), general dependency upgrades and runtime refactors separate. The implementation must remain a small extension of the existing packaging workflow; do not increase ordinary PR build cost with a second full release matrix.

Static review only; no SBOM/license scanner was executed while filing.