[P06] Add npm GitHub workflow provenance compatibility projection #143

Context

Attempts 7 and 8 of the live M1 dogfood reached npm publish and failed closed with windlass.verify.error.registry-linkage-mismatch / publication outcome is indeterminate.

• Attempt 7: https://github.com/windlasstech/vers-js/actions/runs/41427318706
• Attempt 8: https://github.com/windlasstech/vers-js/actions/runs/41488152839
• Diagnostics follow-up: [P06] Classify npm publish rejection details safely #142

Attempt 8 captured npm's immediate result as E422 / HTTP 422. The preserved Windlass bundle passed GitHub attestation verification, and the registry never exposed @windlass/[email protected] or its attestations. Comparing the rejected bundle with the registry-accepted npm-generated provenance for @windlass/[email protected] shows that the Windlass statement lacks npm's GitHub workflow compatibility projection:

• buildDefinition.externalParameters.workflow.ref
• buildDefinition.externalParameters.workflow.repository
• caller workflow buildDefinition.externalParameters.workflow.path
• buildDefinition.internalParameters.github.event_name
• buildDefinition.internalParameters.github.repository_id
• buildDefinition.internalParameters.github.repository_owner_id

The signing certificate already carries corresponding public claims: source repository, source repository ref, caller build config URI, build trigger, repository ID, owner ID, and runner environment.

Proposal

Add a narrowly scoped npm compatibility projection to the signed SLSA v1 provenance statement so npm's registry-side certificate-to-predicate consistency checks can find the GitHub workflow fields they expect.

The projection should preserve the existing Windlass semantics:

• Keep the immutable Windlass builder.id and build type.
• Keep both SHA-256 and SHA-512 subject digests unless a later evidence-based decision rejects the extra digest.
• Keep the built source tag (source.ref, source.revision) distinct from the invocation ref (source.invocation_ref, source.invocation_revision).
• Populate npm-compatible workflow fields from verified public GitHub/OIDC claims, not arbitrary environment text.
• Treat the projection as npm registry compatibility metadata, not as a replacement for Windlass source or builder identity.

Expected direction

Candidate mapping:

• workflow.ref <- certificate SourceRepositoryRef / invocation ref
• workflow.repository <- certificate SourceRepositoryURI
• workflow.path <- caller workflow path from certificate BuildConfigURI
• internalParameters.github.event_name <- certificate BuildTrigger
• internalParameters.github.repository_id <- certificate SourceRepositoryIdentifier
• internalParameters.github.repository_owner_id <- certificate SourceRepositoryOwnerIdentifier

The final mapping, trust boundary, and provenance-contract wording require an ADR and specification update before implementation.

Non-goals

• Do not remove SHA-256 speculatively.
• Do not replace the Windlass SHA-pinned builder identity with npm's runner identity.
• Do not log raw registry responses; detailed rejection classification remains [P06] Classify npm publish rejection details safely #142.
• Do not retry publication before the projection contract is decided and implemented.

Acceptance criteria

• ADR and architecture specs define the projection and its trust semantics.
• TDD covers the six compatibility fields and their certificate/claim bindings.
• Existing immutable builder identity and source-tag versus invocation-ref semantics remain intact.
• Generated provenance passes existing offline/online verification and npm client custom-provenance checks.
• A later dogfood attempt can determine whether npm accepts the projection or reports a remaining rejection family.