[P06] Live M1 dogfood

Scope

Execute real M1 publication from the selected caller repository and record actual evidence in docs/dogfood/npm-m1.md.

Contracts

Full npm profile; ADR confirmations 0073 and 0076

Dependencies

F00, P05

Blocking issues: [F00] #7; [P05] #29.

Executable QA

`gh run list --repo "$DOGFOOD_REPO" --workflow release.yml --branch "$DOGFOOD_TAG" --limit 1 --json databaseId,conclusion,headSha` must return one run with `conclusion:"success"`. `gh run watch "$RUN_ID" --repo "$DOGFOOD_REPO" --exit-status` must exit 0. `npm view "$DOGFOOD_PACKAGE@$DOGFOOD_VERSION" name version dist --json` must return exact name/version, nonempty `dist.integrity`, `dist.shasum`, and attestation metadata. `go run ./cmd/slsa-builder-internal verify-attestation --npm-package "$DOGFOOD_PACKAGE" --version "$DOGFOOD_VERSION" --expected-run-id "$RUN_ID" --mode online` must exit 0 with `result:"pass"` and matching `run_invocation`. A same-run retry must conclude success without a second publish; a new run for the same version must fail with `foreign-conflict`.

ci(publish): Replace SLSA generator with token-based npm bootstrap (#34)

ci: publish releases via the slsa-builder npm SLSA3 reusable workflow (…

chore(release): v0.1.2 (#41)

Dogfood attempt 1 (12026-08-12): FAIL-CLOSED as designed — no mutation occurred.

Run: https://github.com/windlasstech/vers-js/actions/runs/31622651874 (v0.1.2 tag push)

Outcome: verify job success → build job failed at 'Build and pack selected package' → provenance-sign skipped → publish skipped. Zero registry mutations.

Failure diagnostic: windlass.verify.error.package-resolution-invalid — 'The package directory does not resolve to exactly one package inside the repository.'

Root cause (spec gap identified): vers-js carries a settings-only pnpm-workspace.yaml (policy settings: minimumReleaseAge, trustPolicy, etc.) with NO packages: member. The current build-pack spec (js-ts-npm-build-pack.md, malformed-metadata clause) treats a pnpm-workspace.yaml whose packages member is missing as malformed workspace metadata and fails closed. In the real pnpm ecosystem, settings-only pnpm-workspace.yaml is a valid and common shape (modern pnpm stores policy settings there); the N01 fixture corpus had no such fixture, so the gap passed CI.

Assessment: slsa-builder-side spec/implementation gap, NOT a caller readiness issue (F00 verified GO separately). Resolution: new ADR to treat a missing packages member as standalone-root-package mode (zero patterns, root package only) rather than malformed metadata, plus N02 fix, new fixture, and spec sync. Work starts immediately.

Retry plan: after the ADR + fix merge, re-run via workflow_dispatch release_tag=v0.1.2 (idempotency: no version conflict occurred since nothing was published).

ADR 0078 is drafted in #79: #79

It records the dogfood finding from https://github.com/windlasstech/vers-js/actions/runs/31622651874 and specifies that a settings-only pnpm-workspace.yaml with no packages member selects the standalone root package rather than failing as malformed. The N02 implementation, accepted/rejected fixtures, and release_tag=v0.1.2 dogfood retry remain the follow-up after this docs-only PR merges.

docs(decisions): Treat settings-only pnpm workspace as root package (#79

ci: bump slsa-builder pin and wire source-ref for release retries (#42)

P06 verification-procedure decision (12026-08-14): the executable-QA verification step is performed with the existing reference procedure from docs/architecture/verification-policy-and-fixtures.md (§ Reference commands), not a new online mode of the internal verify-attestation subcommand. The QA string in this issue maps to that procedure as follows:

QA element (this issue)	Execution under the reference procedure
`gh run list ... conclusion:"success"` / `gh run watch --exit-status`	Unchanged — run observation.
`npm view "$DOGFOOD_PACKAGE@$DOGFOOD_VERSION" name version dist --json`	Unchanged — exact name/version, nonempty `dist.integrity`, `dist.shasum`, attestation metadata.
`verify-attestation --npm-package ... --expected-run-id "$RUN_ID" --mode online` (not an implemented/spec'd command surface)	Spec reference procedure, online mode: (1) resolve online verification mode (no offline pin fallback; `verification-mode-invalid` on ambiguity); (2) strict-parse policy/expectation/bundle with duplicate-member rejection; (3) acquire the online TUF trust root; (4) `gh attestation verify "$ARTIFACT" --bundle "$BUNDLE" --repo windlasstech/vers-js --signer-workflow <SHA-pinned reusable workflow ref> --cert-oidc-issuer https://token.actions.githubusercontent.com --format json` with all constraints supplied; (5) JSON/X.509 post-processing for the claims `gh` cannot check (Fulcio numeric repository/owner IDs, runner environment, source ref/revision, Run Invocation URI). `gh attestation verify` success is necessary but not sufficient. The `--expected-run-id` element maps to comparing the signed Statement's `runDetails.metadata.invocationId` with `https://github.com/windlasstech/vers-js/actions/runs/<RUN_ID>`.
Registry attestation read-back + pacote consumer verification (ADR 0077 production-signer gate)	Read back the registry-side attestation bundle for the published version and byte-compare it with the preserved signed bundle; verify the published package and provenance through npm's consumer path (pacote). Dry-run does not satisfy this gate.
Same-run retry converges without a second publish; new run for the same version fails with `foreign-conflict`	Unchanged — observed via dispatch re-run attempts after the successful publish.

Additional evidence to record during the run (unchanged): ADR 0076 early npm OIDC exchange preflight outcome; ADR 0073 attestation propagation measurements (publish completion timestamp, every attestation observation timestamp, first authenticated visibility, total convergence time, request count) — one observation does not tighten the bound; issue #81 acceptance (Statement source revision = the tag's commit SHA while run_invocation.ref remains refs/heads/main); issue #22 acceptance (settings-only pnpm root-package resolution passes). All actual values are recorded in docs/dogfood/npm-m1.md after the run.

docs(dogfood): Add npm M1 verification procedure (#87)

Second dogfood attempt (12026-08-13/14): blocked pre-mutation, root cause identified, remediation in progress

Run: 31737001312 — workflow_dispatch from main (7851c5f8) with release_tag=v0.1.2, reusable workflow pinned at 496e40e5 (includes the #86 source-ref fix). Conclusion: failure. No publication occurred — @windlass/[email protected] remains absent from the registry (E404) and the attestations endpoint returns 404.

Timeline and failure point

Time (UTC)	Event
19:40:16	Dispatch accepted (Phase 0 pre-checks all green: version absent, tag object `518569c6` → peel `68e6f001`, caller pin verified)
19:42:17	`Build npm package` ✅ — settings-only pnpm resolution passed (closes #22), tag content built, handoffs produced
19:43:30	`Sign npm provenance` ❌ — step "Sign and verify exact npm provenance Statement" failed
19:44:14	`Publish npm package` reported success but every mutation step was skipped (bundle handoff absent) — the no-mutation-on-failure property held end to end

What failed and why

npm-profile-sign ran the ADR 0076 early npm OIDC exchange preflight. The registry returned HTTP 201 — the exchange succeeded (trusted-publisher configuration valid, publish token minted) — but the client's strict response decoder rejected the body, failing closed with windlass.verify.error.npm-oidc-exchange-indeterminate ("malformed response"). No token fallback was attempted; no mutation followed.

This is the ADR 0076 confirmation event (standing item): the early-exchange preflight was empirically exercised on the live registry, classified an unreadable-by-contract surface, and blocked the mutation as designed.

Root cause (empirically pinned)

The expected response shape (created/expires as RFC 3339 strings) existed only in the P03 implementation and its fixtures — neither the spec nor ADR 0076 pins the exchange success body. A mutation-free probe (temporary publish.yml on a throwaway vers-js branch, run 31794210985, branch deleted afterwards) captured the real 201 body:

{ "created": 1786705013, "expires": 1786705913, "token": "<375-char string>", "token_type": "oidc" }

Keys are exactly the four documented fields — but created/expires are epoch-second numbers, not the RFC 3339 strings shown in the npm API docs example. Docs/implementation drift on npm's side; our strictness caught it.
Observed token TTL is exactly 900 s (15 minutes), contradicting the "typically 1 hour" documentation ADR 0076 cites. Timing assumptions must follow the observed 15-minute lifetime.
npm CLI and pnpm both read only token and ignore everything else, which is why the drift is invisible to the ecosystem.

Resolution path (approved)

Follow-up ADR pinning the empirically observed exchange response contract (union of epoch-number and RFC 3339 timestamps; strict semantic validation retained; unknown-field rejection retained) and correcting the TTL assumption — draft in progress.
Spec amendment in js-ts-npm-provenance-publish.md (exchange response contract section), then a TDD decoder fix with the observed-shape fixture.
After merge: bump the vers-js caller pin and re-dispatch the dogfood, then execute the verification runbook (docs/dogfood/npm-m1-verification-procedure.md) phases 1–6.

Partial acceptances recorded in this attempt

[N02] Package and manager selection #22 closed (settings-only pnpm resolution proven live).
feat(npmprofile): support building a caller-specified source ref for dispatch retries #81 closed (source-ref plumbing carried refs/tags/v0.1.2 / 68e6f001 to the signer with invocation context on main; live Statement field observation rolls into the next run's acceptance here).
ADR 0073 propagation measurement and phases 2–6 were not applicable to this run (nothing was published).

docs: close satisfied ADR 0076 early-exchange standing item

ci: Bump slsa-builder pin for Corepack distribution capture fix (#74)

Seventh dogfood attempt (12026-11-02): fail-closed at publish read-back — Corepack keying fix verified live, the publish mutation never committed

Run: 41427318706 — workflow_dispatch from main (02dfb25b) with release_tag=v0.1.3 (tag object ede69038 → peel ae5bb155, unchanged), caller publish.yml blob d566674f, reusable workflow pinned at 643077b (carries the #140 Corepack plain-version keying fix). Conclusion: failure. No publication occurred — post-run the packument returns version not found: 0.1.3 and the attestations endpoint returns HTTP 404.

Timeline and failure point

Time (UTC)	Event
10:15:23	Phase 0 pre-checks green: version E404, attestations 404, tag object `ede69038` → peel `ae5bb155`, caller blob `d566674f`, pin `643077b` verified at caller line 144; dispatch accepted
10:15:29–10:16:19	`Verify release` ✅
10:16:19–10:17:27	`Build npm package` ✅ — Corepack acquisition capture passed with the integrity-suffixed descriptor `[email protected]+sha512.f6988a32...`, the exact point that killed attempt 6
10:17:27–10:18:35	`Sign npm provenance` ✅
10:18:35–10:34:55	`Publish npm package` ❌ — hardening, trusted-builder checkout, Node 24.22.1 provision/bind/assert, npm 11.21.1 provisioning, config diagnostics, and both digest-bound handoff downloads all ✅; `Publish with trusted-publisher convergence` ❌ at 10:34:50 with `windlass.verify.error.registry-linkage-mismatch` (`npm.publish.readback`, "publication outcome is indeterminate", exit 1)

What passed that previously failed

The #140 plain-version keying fix passed live at exactly the attempt-6 failure point: the Installing-line and cache-path capture now keys on the plain version while .corepack locator.reference retains the full descriptor, and the build proceeded through install/build/pack to hand off a verified tarball and a signed provenance bundle. The publish mutation stage was reached for the first time since attempt 4.

What is confirmed about the failure

The publish step invoked the npm mutation at 10:19:39 and the read-back then polled the packument and the attestation surface until the 15-minute budget exhausted at 10:34:50. The report's check (npm.publish.readback) confirms the entry revalidation and the npm invocation itself were reached and cleared.
0.1.3 never appeared in the packument during the entire budget and remains absent now; the attestation surface is likewise empty. The mutation never committed; zero registry mutation occurred, and the fail-closed property held again.
The npm-side failure class is not yet evidenced: the step log carries no npm output between invocation and the final report, and the failure report records only the read-back classification. Only ENEEDAUTH/E404/E401/E403 map to definitive pre-commit rejections; any other npm failure class falls through to read-back polling, consistent with the observed budget exhaustion. Pinning the actual npm failure class is the next diagnostic step.

Attempt 7 follow-up: bundle verification passes; registry predicate rejection is the leading hypothesis, not a confirmed root cause

This follow-up records the additional evidence gathered after the previous attempt-7 report and narrows one statement in that report. It does not claim that the original failure has been reproduced or definitively classified.

1. The real artifacts pass npm 11.21.1 client-side provenance verification

The attempt-7 tarball and Sigstore bundle were downloaded and checked with the pinned npm 11.21.1 / Node.js 24.22.1 toolchain. The package binding was also checked independently: the expected subject is pkg:npm/%40windlass/[email protected], and the subject's SHA-512 digest matches the tarball.

Deliberately corrupted controls failed for the intended reasons:

RED-name=Provenance subject ... does not match the package
RED-digest=Provenance subject digest does not match the package
REAL=PASS mediaType=application/vnd.dev.sigstore.bundle.v0.3+json

This makes the following causes unlikely for attempt 7:

package PURL / subject mismatch;
tarball SHA-512 mismatch;
multiple-subject rejection;
local sigstore.verify() rejection;
the [BUG] Trusted publishing auto-provenance silently discards the --provenance-file bundle npm/cli#9879 provenance-file problem, whose fix shipped in npm 11.20.0 and is present in 11.21.1.

This is client-side evidence only. It does not prove that the registry accepted the same bundle or predicate.

2. The statement overlaps the registry's documented workflow/GitHub consistency checks

The attempt-7 statement has this shape:

Field	Attempt-7 statement
`externalParameters.workflow.ref`	absent
`externalParameters.workflow.repository`	absent
`externalParameters.workflow.path`	reusable builder workflow path, not the caller workflow path
`internalParameters.github`	empty object

The certificate instead carries GitHub's invocation/source claims. In particular, the source identity is the dispatch invocation on main at 02dfb25b, not the built tag. The built source v0.1.3 / ae5bb155 is recorded separately through the signed source binding, as designed in ADR 0080. Therefore refs/tags/v0.1.3 must not be substituted into externalParameters.workflow.ref merely to fill the missing field.

slsa-framework/slsa-github-generator#2499 provides a directly relevant registry rejection case. npm returned 422 Unprocessable Entity while checking values including:

externalParameters.workflow.ref against the certificate source-repository ref;
externalParameters.workflow.repository against the certificate source-repository URI;
externalParameters.workflow.path against the build-config URI;
internalParameters.github.event_name, repository ID, and owner ID against GitHub claims.

A later report in the same issue says the custom buildType / builder.id rejection was relaxed while workflow and internalParameters mismatch errors persisted.

Current leading hypothesis: the registry rejected the Windlass SLSA v1 predicate because its workflow/GitHub fields were absent or inconsistent with the certificate, plausibly with E422. This is more specific than attributing the failure to the custom buildType alone, but it remains a hypothesis.

3. What remains possible

The evidence does not currently distinguish among all of these execution paths:

Candidate	Current assessment
Registry provenance predicate consistency rejection	Leading hypothesis, based on the statement shape and #2499
Publish-time OIDC exchange failure	Still possible; no exchange result was preserved
Network, Sigstore trust-root, or npm process failure	Still possible; process and request evidence was discarded
Custom `buildType` alone	Lower priority after the upstream relaxation report, but not independently excluded for this run
Reusable-builder SAN, bundle v0.3, or repository URL handling	Not proven or excluded by the local verification result
Publish committed and only read-back failed	Not supported by the currently visible registry state, but historical request handling is unavailable

4. Correction to the previous comment

The previous comment said “zero registry mutation occurred.” That was too strong.

The current packument and attestation 404 responses establish that no 0.1.3 publication or attestation is visible now. They do not, by themselves, prove whether a registry PUT occurred, whether npm returned E422, or how every historical request was processed. The accurate statement is: no publication is currently visible, and the original mutation outcome is indeterminate from the preserved evidence.

5. Evidence still missing from the original run

The following cannot be reconstructed reliably from the retained workflow log:

whether the npm process started successfully;
npm exit code, signal, and duration;
publish-time OIDC exchange outcome;
whether a registry PUT occurred;
HTTP status/body, including whether the response was actually E422;
which predicate field, if any, the registry rejected;
the historical commit outcome of every registry request.

Further guessing will not resolve those unknowns. Before another publish retry, the trusted-core diagnostics need to preserve a bounded, secret-safe execution timeline: stage transitions, process start/exit, normalized npm error code, HTTP status and request phase, allowlisted predicate mismatch field paths, and bounded read-back observations. Raw environment values, JWTs, token-exchange responses, and unfiltered npm debug logs must remain excluded.

feat(npmprofile): Add redacted operational diagnostics (#141)

ci: Bump slsa-builder pin for redacted publish diagnostics (#75)

Eighth dogfood attempt (12026-11-02): fail-closed at publish — npm E422 captured, registry predicate compatibility gap is the leading cause

Run: 41488152839 — workflow_dispatch from main (3687faf7) with release_tag=v0.1.3 (tag object ede69038 → peel ae5bb155), caller publish.yml blob 40fa08ef, reusable workflow pinned at 03357579 (carries PR #141 redacted operational diagnostics). Conclusion: failure. No publication became visible — @windlass/[email protected] remains absent from the packument (E404), and the attestation endpoint returns HTTP 404. No blind retry was attempted.

Timeline and failure point

Time (UTC)	Event
17:07:44	Dispatch accepted after Phase 0 checks: version E404, tag object `ede69038` → peel `ae5bb155`, caller blob `40fa08ef`, pin `03357579` verified
17:07:48–17:08:25	`Verify release` ✅
17:08:28–17:09:59	`Build npm package` ✅ — pinned Node.js 24.22.1, toolchain pair assertion, Corepack acquisition capture, build, pack, and handoffs all passed
17:10:02–17:11:24	`Sign npm provenance` ✅ — Windlass-signed SLSA v1 bundle produced and verified
17:11:37–17:28:08	`Publish npm package` ❌ — pinned npm 11.21.1 provisioning and both digest-bound handoffs passed; `Publish with trusted-publisher convergence` failed after read-back exhaustion
17:12:35–17:12:38	The actual npm publish command exited 1 after 2.93 seconds with `E422` / HTTP 422
17:12:47–17:27:47	Post-mutation read-back made 61 observations over 15 minutes; the version and attestation sets never changed, so the state machine correctly returned `indeterminate`

What the new diagnostics established

PR #141's redacted operational diagnostics captured the evidence that attempt 7 lacked:

windlass operational: readback after_mutation=false observations=1 changes=0 first="package=present version=absent integrity=unknown attestations=absent errors=none" final="package=present version=absent integrity=unknown attestations=absent errors=none" decision=absent
windlass operational: operation=npm started=true outcome=exit exit=0 elapsed=68.199448ms output_truncated=false success=true
windlass operational: operation=npm started=true outcome=exit exit=1 elapsed=2.932497713s output_truncated=false success=false
windlass operational: npm_failure code=E422 http_status=422
windlass operational: readback after_mutation=true observations=61 changes=0 first="package=present version=absent integrity=unknown attestations=absent errors=none" final="package=present version=absent integrity=unknown attestations=absent errors=none" decision=indeterminate

The preserved outcome report is windlass.verify.error.registry-linkage-mismatch (npm.publish.readback, "publication outcome is indeterminate", exit 1). The registry state therefore remains fail-closed and non-committed from the caller's perspective.

Artifact and signer verification

The preserved attempt-8 tarball and Windlass-signed bundle passed online GitHub attestation verification with the exact tarball, caller repository, issuer, SLSA v1 predicate type, and SHA-pinned signer workflow. This separates npm registry admission from bundle signature validity.

Tarball SHA-256: e3de6be684ff97651c09361d67680fddf1d5fe96d673433a88e2ddd3c03fa898
Tarball SHA-512: e89f2c710fb587775984e7365bd80018df6d9b00a78b35c0838fe088b09f08747c6b04e568df06f48820b60c4ffb98d4897dc91a75ad741eabe89919dc5955af
Bundle SHA-256: 38cde7fbfb4e036991a8905b2af386fd298d604b6e8284d1cc2206d14d93da02

The signing certificate carries the public GitHub claims npm can compare against: source repository https://github.com/windlasstech/vers-js, source ref refs/heads/main, build config https://github.com/windlasstech/vers-js/.github/workflows/publish.yml@refs/heads/main, trigger workflow_dispatch, repository ID 1261293345, owner ID 257660296, and runner environment github-hosted.

Root-cause assessment

The exact registry response body was not retained, so the final server-side message remains unobserved. The evidence nevertheless narrows the leading cause to npm's certificate-to-predicate consistency validation for GitHub workflow fields.

Comparing the registry-accepted npm-generated provenance for @windlass/[email protected] with the rejected attempt-8 Windlass bundle shows:

Field family	Registry-accepted 0.1.2 bundle	Attempt-8 Windlass bundle
`buildDefinition.externalParameters.workflow.ref`	`refs/heads/main`	absent
`buildDefinition.externalParameters.workflow.repository`	`https://github.com/windlasstech/vers-js`	absent
`buildDefinition.externalParameters.workflow.path`	`.github/workflows/publish.yml`	`.github/workflows/js-ts-npm-package-slsa3.yml`
`buildDefinition.internalParameters.github`	event, repository ID, and owner ID present	`{}`
Subject digest algorithms	`sha512`	`sha256` and `sha512`
`buildDefinition.buildType`	GitHub workflow build type	Windlass npm package build type
`runDetails.builder.id`	`https://github.com/actions/runner/github-hosted`	SHA-pinned Windlass reusable workflow

The leading hypothesis is that npm rejected the custom SLSA v1 predicate because the workflow/GitHub projection was absent or inconsistent with the certificate. Upstream evidence in slsa-github-generator#2499 records npm returning E422 for this field family. The extra SHA-256 digest and the custom Windlass buildType / SHA-pinned builder.id remain lower-confidence hypotheses; npm 11.21.1's client-side custom-provenance path checks digest.sha512 and does not reject additional digest algorithms, and the upstream thread records that npm relaxed its earlier builder/build-type checks.

Follow-up issues and next step

[P06] Classify npm publish rejection details safely #142 tracks the safe diagnostics improvement needed to classify the exact registry rejection family and allowlisted field identifiers without logging raw registry bodies or secrets.
[P06] Add npm GitHub workflow provenance compatibility projection #143 tracks the proposed npm GitHub workflow provenance compatibility projection.

The next implementation step should be the normal observe → ADR → spec → TDD path for #143, while preserving the immutable Windlass builder identity and the signed distinction between the built source tag and the dispatch invocation ref. No further publish retry should occur until that contract change is decided and implemented, or until #142 provides a more precise rejection classification.

docs(dogfood): Record npm M1 attempts 7 and 8 (#144)

feat(npmprofile): Relay filtered external-process stderr with rejecti…

fix(npmprofile): Shorten the post-publish read-back budget to five mi…

ci: Bump slsa-builder pin for stderr relay and read-back budget (#76)

Ninth dogfood attempt (12026-11-03): fail-closed at publish — full registry rejection captured via the ADR 0101 stderr relay

Run: 41666974638 — workflow_dispatch from main (bd8b7ab1) with release_tag=v0.1.3 (tag object ede69038 → peel ae5bb155), caller publish.yml blob 21f17485, reusable workflow pinned at e7c55d91 (carries PR #145 stderr relay + family enrichment and PR #146 five-minute read-back budget). Conclusion: failure. No publication became visible — post-run npm view @windlass/[email protected] returns E404 and the attestations endpoint returns 404; because the publish call was attempted, the outcome remains indeterminate by design.

What happened

Verify release, build, and provenance-sign jobs passed; the publish job passed pinned runtime/npm provisioning and both handoff verifications, then failed at Publish with trusted-publisher convergence with E422 after 2.83 seconds. Post-mutation read-back made 21 observations over the new five-minute budget and returned indeterminate (windlass.verify.error.registry-linkage-mismatch). Run wall time was ~9m46s, down from attempt 8's 20m25s.

The registry's complete rejection message (first first-party capture)

The PR #145 relay carried npm CLI's rendered stderr into the log with no instrumentation change, satisfying ADR 0101's confirmation criterion:

npm error code E422
npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/@windlass%2fvers-js - Error verifying sigstore provenance bundle: Invalid GitHub Actions SLSA v1 provenance predicate:
npm error buildDefinition.externalParameters.workflow.ref: <empty> does not match expected value for SourceRepositoryRef: refs/heads/main,
npm error buildDefinition.externalParameters.workflow.repository: <empty> does not match expected value for SourceRepositoryURI: https://github.com/windlasstech/vers-js,
npm error buildDefinition.externalParameters.workflow.path: .github/workflows/js-ts-npm-package-slsa3.yml does not match expected value for BuildConfigURI: .github/workflows/publish.yml,
npm error buildDefinition.internalParameters.github.event_name: <empty> does not match expected value for BuildTrigger: workflow_dispatch,
npm error buildDefinition.internalParameters.github.repository_id: <empty> does not match expected value for SourceRepositoryIdentifier: 1261293345,
npm error buildDefinition.internalParameters.github.repository_owner_id: <empty> does not match expected value for SourceRepositoryOwnerIdentifier: 257660296,
npm error buildDefinition.resolvedDependencies[0].uri: git+https://github.com/windlasstech/vers-js@ae5bb155d447bbaeeab2c40f79434d4760440546#pnpm-lock.yaml does not match expected value for SourceRepositoryURI: git+https://github.com/windlasstech/vers-js@refs/heads/main,
npm error buildDefinition.resolvedDependencies[0].digest.gitCommit: <empty> does not match expected value for SourceRepositoryDigest: bd8b7ab116046e2c9bf8ee8682606ce643452c26

Findings

Eight expected-value mismatches; <empty> confirms the fields are absent from our statement rather than mismatched.
Two previously uncatalogued requirements: resolvedDependencies[0] must track the invocation source — URI git+<SourceRepositoryURI>@<SourceRepositoryRef> with no lockfile fragment, and digest.gitCommit equal to the invocation head commit (bd8b7ab1, not the peeled tag commit).
workflow.path must equal the certificate BuildConfigURI's caller workflow path (.github/workflows/publish.yml), not the reusable workflow's own path; workflow.ref is the invocation ref (refs/heads/main), not the built tag.
buildType and builder.id are absent from the complaint — suggestive of the post-12023-08 relaxation, but not proof of acceptance until a conforming run reaches the registry.
The recognizer emitted code=E422 http_status=422 but no family=: the live form's two resolvedDependencies[0] lines are outside its binding table, so the complete-template matcher declined. The relay carried the full text regardless — the ADR 0101 enrichment fallback working as designed. Template widening is tracked in [P06] Classify npm publish rejection details safely #142.
The canonical outcome report kept its sealed shape (no external text): registry-linkage-mismatch, indeterminate, exit 1.
The attempt-9 tarball digests (SHA-256 e3de6be6…, SHA-512 e89f2c71…) are byte-identical to attempt 8's, reconfirming deterministic build reproduction.

[P06] Classify npm publish rejection details safely #142: widen the rejection-family template with the two resolvedDependencies[0] lines.
[P06] Add npm GitHub workflow provenance compatibility projection #143: the projection is now evidence-complete, including the resolvedDependencies[0] invocation-source requirement.
Full evidence record: PR docs(dogfood): Record npm M1 attempt 9 #147 (docs/dogfood/npm-m1.md, attempt-9 section).

docs(dogfood): Record npm M1 attempt 9 (#147)

feat(npmprofile): Classify E422 publish rejections under a reduced re…

feat(npm)!: Implement final npm provenance contract per ADR 0103-0112 (…

ci: Bump slsa-builder pin for npm provenance compatibility projection (…

[P06] Live M1 dogfood #30

Description

Scope

Contracts

Dependencies

Executable QA

Activity

yunseo-kim commented on Aug 12, 2026

Dogfood attempt 1 (12026-08-12): FAIL-CLOSED as designed — no mutation occurred.

yunseo-kim commented on Aug 12, 2026

yunseo-kim commented on Aug 13, 2026

yunseo-kim commented on Aug 14, 2026

Second dogfood attempt (12026-08-13/14): blocked pre-mutation, root cause identified, remediation in progress

Timeline and failure point

What failed and why

Root cause (empirically pinned)

Resolution path (approved)

Partial acceptances recorded in this attempt

22 remaining items

yunseo-kim commented on Nov 2, 2026

Seventh dogfood attempt (12026-11-02): fail-closed at publish read-back — Corepack keying fix verified live, the publish mutation never committed

Timeline and failure point

What passed that previously failed

What is confirmed about the failure

yunseo-kim commented on Nov 2, 2026

Attempt 7 follow-up: bundle verification passes; registry predicate rejection is the leading hypothesis, not a confirmed root cause

1. The real artifacts pass npm 11.21.1 client-side provenance verification

2. The statement overlaps the registry's documented workflow/GitHub consistency checks

3. What remains possible

4. Correction to the previous comment

5. Evidence still missing from the original run

yunseo-kim commented on Nov 2, 2026

Eighth dogfood attempt (12026-11-02): fail-closed at publish — npm E422 captured, registry predicate compatibility gap is the leading cause

Timeline and failure point

What the new diagnostics established

Artifact and signer verification

Root-cause assessment

Follow-up issues and next step

yunseo-kim commented on Nov 3, 2026

Ninth dogfood attempt (12026-11-03): fail-closed at publish — full registry rejection captured via the ADR 0101 stderr relay

What happened

The registry's complete rejection message (first first-party capture)

Findings

Next

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions