feat(sbom): add the sbom-pipeline contract

.github/labeler.yml

@@ -533,6 +533,12 @@ contract:report-relay:
           - any-glob-to-any-file:
               - 'tools/forwarder-relay/**'
 
+contract:sbom-pipeline:
+  - any:
+      - changed-files:
+          - any-glob-to-any-file:
+              - 'tools/sbom-pipeline/**'
+
 contract:scan-format:
   - any:
       - changed-files:

docs/labels-and-capabilities.md

@@ -149,6 +149,7 @@ framework substrate:
 | `contract:security-tracker` | contract | Where the security skills keep embargoed reports: body fields, status rollup, attachments, a confidentiality guard, and a publish step for working-copy backends (GitHub, local files, private Jira). |
 | `contract:body-field` | contract | How the `### <Name>` fields of a tracker issue body are found, read and rewritten: field boundaries, closed code blocks, the refusals, and a language-neutral conformance suite every implementation passes. |
 | `contract:hook-manager` | contract | Git-hook managers (prek, pre-commit, lefthook, husky, …) under the secure agent setup: where a manager's install puts its hook, and how its home is split between sandboxed and host runs. |
+| `contract:sbom-pipeline` | contract | SBOM generation in a project's build: one CycloneDX 1.7 SBOM per distributable artifact, with the same meaning whatever ecosystem produced it, and content from other ecosystems embedded as assemblies. |
 | `substrate:analytics` | substrate | Read-only metrics / dashboards / renderers. |
 | `substrate:sandbox` | substrate | Agent isolation, egress control, settings audit. |
 | `substrate:action-guard` | substrate | Deterministic pre-tool-use command guards. |
@@ -393,6 +394,7 @@ or a contract-free mix of substrates (e.g. `tools/spec-inventory` is
 | [`tools/vcs`](../tools/vcs/) | `contract:source-control` | Backend-dispatching implementation of the source-control (VCS) capability ([`tools/github/source-control.md`](../tools/github/source-control.md)); complete Git, Mercurial (Hg), Fossil, and Subversion (SVN) backends |
 | [`tools/sourcehut`](../tools/sourcehut/) | `contract:tracker` + `contract:source-control` + `contract:mail-archive` | SourceHut (sr.ht) forge bridge: todo.sr.ht, lists.sr.ht, builds.sr.ht, and git/hg repository reads |
 | [`tools/hook-manager`](../tools/hook-manager/) | `contract:hook-manager` | Contract for git-hook managers under the secure agent setup: the install-target and home rules, and the registry of adapters (prek, overcommit, lefthook and captainhook today) that the hook-manager shim, the whole-user dispatcher and `sandbox-lint` are generated from |
+| [`tools/sbom-pipeline`](../tools/sbom-pipeline/) | `contract:sbom-pipeline` | Contract for SBOM generation in a project's build: the format, subject, component, assembly, reproducibility and distribution rules, the pipeline operations and conformance checks, and the per-ecosystem adapters (Maven, Gradle, JS, Python, Go, Rust; all planned) |
 | [`tools/tracker`](../tools/tracker/) | `contract:tracker` | Interface spec for the tracker contract's read-only contributor-activity queries (issues filed, triaged and commented on; issues created; first maintainer reply). Pure interface spec; GitHub and Jira implement it, and the rest of the contract is described by `tools/github/tool.md` |
 | [`tools/body-field-contract`](../tools/body-field-contract/) | `contract:body-field` | The body-field contract: how every reader and writer finds a tracker body's `### <Name>` fields, with a language-neutral conformance suite run against every implementation. Pure interface spec; implementations: `tools/github-body-field/` (reference), `tools/vetted-ops/`, `tools/local-tracker/`, `tools/jira/` |
 | [`tools/security-tracker`](../tools/security-tracker/) | `contract:security-tracker` | Adapter contract for the security tracker the `security-*` skills read and write, selected by `tracker.platform`. Pure interface spec; backends: `tools/github/` (default), `tools/local-tracker/`, `tools/jira/` |

docs/vendor-neutrality.md

@@ -582,7 +582,7 @@ generated block below.
 
 <!-- BEGIN vendor-neutrality-score — generated by `uv run --project tools/vendor-neutrality-score vendor-neutrality-score --markdown`; do not edit by hand -->
 
-**Overall vendor-neutrality score: 16/18 capability contracts (89%).** Generated by [`tools/vendor-neutrality-score`](../tools/vendor-neutrality-score/); re-run it to refresh this section.
+**Overall vendor-neutrality score: 16/19 capability contracts (84%).** Generated by [`tools/vendor-neutrality-score`](../tools/vendor-neutrality-score/); re-run it to refresh this section.
 
 | Capability contract | Neutral? | Class | Backends today | Basis |
 |---|---|---|---|---|
@@ -604,6 +604,7 @@ generated block below.
 | `contract:security-tracker` | ✅ | vendor-backed | Atlassian, agnostic | 2 backend vendors: Atlassian, agnostic; partial foundation, not counted: asf-security-dash |
 | `contract:body-field` | ✅ | agnostic | Atlassian, GitHub, agnostic | vendor-neutral by construction — one spec serves every backend |
 | `contract:hook-manager` | ❌ | vendor-backed | — | no backend implemented yet |
+| `contract:sbom-pipeline` | ❌ | vendor-backed | — | no backend implemented yet |
 
 **Per-skill assessment: 83/83 skills carry no vendor lock-in.** A skill is *capability-pure* when it names no backend at all, *portable* when every backend it names has an alternative (its contract is green), and *vendor-coupled* only when it reaches for a backend that is the sole implementation of a capability.