Background

This reframes the original "add a pnpr publish test harness" ask. Investigating pnpr shows the blocker is not (only) test infrastructure — pnpr is missing the server-side authentication capabilities that pacquet publish (#12691) exercises. A harness cannot drive an OIDC token exchange or an OTP challenge the registry doesn't serve. So the integration tests are a downstream requirement that depends on these capabilities existing first — which is also why publish integration tests were originally deferred.

What pnpr already supports

pnpr already accepts token-authenticated publishes: PUT /:pkg (publish_package) and batch PUT /-/pnpm/v1/publish (serve_batch_publish), with publish-doc validation, version merge, and tarball storage, plus a token auth store (the app_with_token test helper). So the plain publish + recursive-publish happy path (static _authToken, no OTP/OIDC) can be integration-tested against pnpr today — that part needs no new pnpr capability.

What pnpr is missing (the actual work)

pnpr has no OIDC / OTP / web-auth / visibility / provenance endpoints. To exercise the publish trusted-publishing and 2FA paths end-to-end, pnpr must implement the registry server contract npm/pnpm expose and both pnpm and pacquet already speak:

• OIDC trusted publishing — POST /-/npm/v1/oidc/token/exchange/package/:name (CI id-token → short-lived registry token).
• Package visibility — GET /-/package/:name/visibility (the provenance-eligibility probe).
• OTP / 2FA challenge — answer a publish lacking OTP with 401 + WWW-Authenticate: OTP (or a one-time-pass body), and accept the npm-otp header on retry.
• Web-auth login — the authUrl / doneUrl polling flow (npm loginWeb / adduserWeb).
• Provenance attachment — accept and store the .sigstore bundle attachment on publish (pairs with the client-side signing seam in test(pacquet): cover generate_provenance / sigstore signing in pacquet publish #12739).

Requirements for implementers

1. Implement the capability in pnpr (matching the npm/pnpm registry contract pacquet already speaks) — the primary deliverable.

2. ⚠️ Add end-to-end integration tests for BOTH stacks, in the same PR (very important):

   • pnpm publish (TypeScript) — integration tests against the new capability.
   • pacquet publish (Rust) — pnpr-backed integration tests against the same capability.

   Today both stacks cover these flows only with unit tests using the dependency-injection mock pattern — Rust uses fake Sys capability providers; TypeScript uses createMockContext / an injected fetch + enquirer. Neither has any end-to-end coverage, because until now no test registry served OIDC / OTP / web-auth. Implementing the pnpr capability is precisely what finally makes real integration tests possible, so the implementer of this issue owns adding them to both pnpm and pacquet, per the repo's "keep pnpm and pacquet in sync" rule. These integration tests are a required deliverable of the capability work, not a follow-up.

Each capability above can land as its own PR (with its own pnpm + pacquet integration tests). The token-auth publish happy path can be integration-tested independently and immediately, since pnpr already supports it.

Refs: PR #12691, client-side provenance signing #12739, roadmap #11633.

Written by an agent (Claude Code).