Tracking issue for bringing @pnpm/pnpr to feature parity with verdaccio as a backend.

Scope

• In scope: every HTTP and on-disk capability a registry server needs in production — auth, ACLs, uplinks, caching, publish lifecycle, storage integrity, observability, config.
• In scope: a complete enough HTTP/JSON surface that an external project could build a browser UI on top of it.
• Out of scope: a built-in browser UI / web frontend. We might ship one but that is not part of this issue.
• Out of scope: verdaccio's plugin-as-npm-package model. If we add extensibility it will be compile-time Rust traits, not dynamic JS plugins. Decision required (see below).

Already done

• packument and tarball serving (full + abbreviated)
• publish, unpublish (full + per-version), dist-tag CRUD
• per-package glob policy ($all / $authenticated)
• htpasswd-style auth (bcrypt, persisted to disk), basic + bearer
• bearer tokens persisted to a SQLite database (SHA-256-hashed)
• uplink proxying with packument TTL cache
• local search (/-/v1/search)
• atomic writes, verdaccio-compatible on-disk layout
• integration tests covering the above

Required for verdaccio parity

Auth & user endpoints

• Persist htpasswd users to disk (pnpr: persist users and tokens to disk #11974, PR feat(registry): persist pnpr users and tokens to disk #11977)
• Token revocation (DELETE /-/npm/v1/tokens/token/:tok) — landed in feat(registry): add whoami, profile, and token CRUD endpoints #12011
• Token listing (GET /-/npm/v1/tokens) — landed in feat(registry): add whoami, profile, and token CRUD endpoints #12011
• Logout (DELETE /-/user/token/:tok) — landed in feat(registry): add whoami, profile, and token CRUD endpoints #12011
• GET /-/whoami — landed in feat(registry): add whoami, profile, and token CRUD endpoints #12011
• GET /-/npm/v1/user (profile) — landed in feat(registry): add whoami, profile, and token CRUD endpoints #12011
• Decide on pluggable auth (LDAP/OAuth/etc.) — interface or out of scope?

Access control

• $anonymous group — landed in feat(registry): enforce per-package access policy from YAML #12043
• Named groups, per-user group membership — landed in feat(registry): per-user access lists (verdaccio-style groups) #12048
• Wire policy fully from YAML — landed in feat(registry): enforce per-package access policy from YAML #12043

Uplinks & caching

• Forward auth.token / custom headers to uplinks feat(pnpr): forward uplink auth token and custom headers to upstreams #12186
• Conditional GET to upstream (ETag, If-Modified-Since) feat(pnpr): revalidate stale packuments with conditional GET to upstream #12239
• stale-while-revalidate semantics on packuments
• Multiple-uplink fallback ordering per package
• Per-uplink timeouts, max_fails, fail_timeout, cache: false
• Offline mode (serve cached only)

Storage & integrity

• SHA verification on tarball read (detect on-disk corruption)
• SHA verification on publish (hash payload, compare to packument integrity) — landed in fix(registry): verify tarball SHA on publish #11976
• Ownership / maintainer tracking per package
• Garbage collection of orphaned tarballs

Publish lifecycle

• npm deprecate (PUT packument with deprecated field on a version)
• Configurable strict mode: reject re-publish of an existing version
• Tarball format validation (gzip header, tar entries)
• Maintainer add/remove (PUT /-/package/:pkg/owner)
• Star / unstar endpoints (optional, npm-client uses them)

Admin / management API (surface for external UIs)

• User list endpoint
• Package metadata / sidebar endpoint suitable for a UI
• Audit endpoint (POST /-/npm/v1/security/audits) — proxy or local

Health & observability

• /-/ping
• Prometheus /metrics
• Structured access log (one line per request, configurable format) — landed in feat(registry): add logging support for requests #12033

Config

• ${ENV_VAR} substitution in YAML
• Schema validation with miette-style diagnostics
• Hot reload (SIGHUP)

Networking

• Decide: built-in TLS termination, or document reverse-proxy-only
• Trust-proxy / X-Forwarded-* handling for dist.tarball rewriting

Notifications

• Configurable webhooks on publish / unpublish / deprecate

Extensibility decision

• Decide whether pnpr exposes a stable Rust trait surface for auth / storage / middleware backends. If yes, define and document it; if no, document it as deliberately out of scope.

Non-goals (explicit)

• Verdaccio-style dynamic plugin loading from npm packages.
• A verdaccio.yaml drop-in compatibility guarantee. The config is verdaccio-shaped, not byte-identical.

Written by an agent (Claude Code, claude-opus-4-7).