@emdash-cms/registry-client@0.5.0

Minor Changes

• #2892 66aeecd Thanks @ascorbic! - Adds interactive package-profile setup for delegated plugin releases. emdash-plugin release setup now creates a missing profile or adds delegated-release settings to an existing valid profile before writing the GitHub Actions workflow. Run emdash-plugin profile setup to prepare only the profile.

  Interactive setup asks for the GitHub repository when it is absent from emdash-plugin.jsonc, lets you choose when releases require approval, and confirms the profile write. Non-interactive callers must pass --yes when a profile change is required.

  The release service returns PACKAGE_PROFILE_REQUIRED before accepting artifact uploads when the signed profile is missing, lacks delegated-release settings, or names a different GitHub repository. Existing release intents also terminate with an actionable reason if their authoritative profile becomes invalid.

• #2849 52fffdc Thanks @ascorbic! - Adds DirectPdsClient.getPackageRepository() for reading a package profile and every package release from one proof-verified AT Protocol repository export.

  Use the method when authorization or version selection requires a complete signed package snapshot:

  const { profile, releases } =
  	await directPdsClient.getPackageRepository("gallery");

  The client verifies the repository commit signature, record blocks, and complete Merkle search tree before returning records. Unsigned repo.getRecord and repo.listRecords envelopes cannot substitute or omit package data. Repository exports use the client's maxResponseBytes limit, which defaults to 5 MiB, and a missing export reports REPOSITORY_NOT_FOUND.

• #2747 3b124f2 Thanks @ascorbic! - Adds typed clients for the experimental delegated release service. ReleaseServiceClient submits, polls, and cancels GitHub OpenID Connect release intents; manages publisher workload policies and retained delegation; and lets publishers check whether profile-listed approvers have an active passkey and inspect publisher-scoped audit events through a publisher session. ReleaseServiceOperatorClient exposes the Cloudflare Access status and sanitized audit, sharded publisher and approver inventory, pause, suspension, revocation, cancellation, reconciliation, resumable encryption-key rotation, Workflow-backed fleet verification, audited key retirement, encrypted R2 archive, and fail-safe publisher restore and abort operations.

  ReleaseServiceClient can request, poll, list, and confirm GitHub workflow connections. The first permanent release run records GitHub's signed repository, workflow, ref, and environment as a pending request and returns a browser approval URL. The publisher must confirm those details before the service creates a workload policy. Tag-based connections can cover the current tag or all version tags while keeping the repository and workflow path exact.

  Both clients validate response envelopes and return stable ReleaseServiceError codes with retry metadata. Mutation helpers require idempotency keys, and workload polling requests a fresh token from the configured provider for each call.

  The plugin CLI adds emdash-plugin release dry-run, release submit, release status, and release cancel for GitHub Actions jobs. The first release submit requests browser approval for the permanent workflow and waits for confirmation before creating an intent. Dry-run verifies existing workload admission without creating a connection request, intent, consuming rate budget, or reserving a version. The commands request audience-bound OIDC tokens from the runner, support JSON output, and use the GitHub run identity as the default idempotency key where a mutation occurs.

  Delegated submissions use a URL-source release record: each package or listing-image artifact supplies a checksum-bound HTTPS URL and no blob. The service stages and uploads those bytes through the publisher's delegation, then creates a blob-only release record. Submit and dry-run reject mixed or blob-backed source inputs before requesting GitHub OIDC.

  Interactive release delegate, revoke, workload, enrol, approve, and reject commands print validated browser handoffs. Publisher application sessions, OAuth credentials, and passkey assertions remain at the release-service origin instead of entering the terminal process.

• #2749 920e1f3 Thanks @ascorbic! - Adds emdash-plugin release setup to create the permanent GitHub Actions workflow for delegated plugin releases. The generated workflow builds and attests the plugin, waits for first-run browser authorization, and uploads its exact bundle and provenance through GitHub OIDC before publishing.

  ReleaseServiceClient.uploadReleaseArtifact() supports custom workflows that need to stage checksum-bound bundle, image, or provenance bytes. Existing URL-source release submit workflows remain supported.

• #2848 e0e60ba Thanks @ascorbic! - Adds publisher-created workflow connection invitations to delegated releases. First-time or unmatched GitHub workflows must use a package-bound, single-use invitation before they can request publisher approval; connected workflows continue without one.

  Create the invitation in the publisher dashboard or with createWorkflowConnectionInvitation(), then save its value as the repository's EMDASH_CONNECTION_INVITATION GitHub Actions secret. The generated release workflow passes this secret to the release Action automatically. Custom workflows can pass invitationToken to requestWorkflowConnection(), and publishers can reject pending requests with rejectWorkflowConnection().

• #2746 c7b6fdf Thanks @ascorbic! - Adds DirectPdsClient for reading package profiles and releases with AT Protocol repository proofs, and updates experimental decentralized registry installs and updates to verify current signed records directly from the publisher's PDS.

  Aggregator record integrity

  Install and update reject aggregator-supplied profile or release metadata whose URI or CID does not match the publisher's signed records. The server returns AGGREGATOR_RECORD_MISMATCH before fetching the artifact or requesting consent.

  Publisher identity display

  The admin treats handle resolution as an advisory identity signal. It keeps the install button disabled while attempting to resolve the package DID back to a handle, then blocks installation when resolveDidToHandle() conclusively returns "invalid". An indeterminate result caused by a network failure, unsupported DID method, or missing handle displays the publisher DID and does not block installation.

  Install and update trust the publisher DID and the signed repository proofs for the profile and release records. A handle is display metadata and is not an authorization or record-integrity input.

  Provenance and release policy

  The installer applies the signed profile's release policy, independently fetches and verifies supplied Sigstore/SLSA provenance, and binds moderation labels to the exact profile or release CID. Missing required provenance and any supplied provenance that is unavailable, malformed, mismatched, or unsupported block installation and updates. Artifact checksums, archive paths, bundle limits, manifest identity, and version use the same verification rules as the registry release tooling.

  The verification package also exports inspectPackageReleaseRecords for validating signed records and policy before artifact and provenance evidence is available.

  Registry install and update consent now show the exact verified profile and release CIDs, signed publisher policy, and provenance status. Install consent uses permissions and MCP tools read from the verified bundle rather than the aggregator's record copy.

  Install, update, and delegated-release verification require lowercase base32 multibase sha2-256 multihashes for package artifacts and provenance documents. The plugin CLI already produces this format. The authenticated image-artifact proxy still accepts legacy bare hexadecimal SHA-256 checksums for display-only images.