ReleaseOrigin

SM Fictional public sample

Inspect the handoff without publishing anything.

This sample uses a fictional package and company. It is not client work, a registry finding, an endorsement, or a runnable release workflow. It demonstrates the structure of a bounded ReleaseOrigin pilot.

01 / Illustrative evidence card

Record only what public metadata can support.

Package@northstar-labs/widget-kit — fictional
Current version1.8.0 — illustrative value, not a registry observation
Attestation metadataSample state only; a paid handoff records present or not returned with date and version
Declared repositoryOne fictional public GitHub repository
Workflow signalOne illustrative release workflow path

A missing metadata field is a review signal only. It does not establish insecurity, a vulnerability, negligence, or noncompliance.

02 / One-path fit map

Bind the work to one release lane.

PackageOne npm package only
RepositoryOne package-declared public repository
WorkflowOne owner-selected release workflow
Hosted CIOne provider path confirmed against current npm documentation
PublisherCustomer’s authorized maintainer retains every account and release control

03 / Non-runnable patch outline

Show the intended change without hiding a release command.

# DOCUMENTATION OUTLINE — NOT A RUNNABLE WORKFLOW
provider: customer-confirmed hosted CI
package: one accepted npm package
permissions:
  repository_contents: read
  identity_token: owner-reviewed requirement
checks:
  - static workflow structure review
  - package metadata consistency review
  - owner-run controlled-environment checklist
publish_step: deliberately omitted from public sample
account_configuration: authorized owner only

The accepted pilot may include a PR-ready workflow patch when compatible. The public sample cannot publish, requests no token, and contains no executable package lifecycle command.

04 / Static validation record

Separate observed structure from owner-run behavior.

Static syntaxRecord parser or linter result for the proposed workflow file
Permission surfaceRecord only the minimum documented permissions in the proposed patch
Secret referencesFlag release-token references for owner review; never collect their values
Package scriptsList relevant script names as text; do not install dependencies or execute package code
Owner-run checkProvide a checklist the customer may run in its own controlled environment after review

05 / Owner-only checklist

The publisher performs every state-changing step.

  1. 1

    Confirm the accepted package, repository, workflow file, hosted CI provider, and authorized maintainer.

  2. 2

    Review the proposed workflow diff and minimum permissions in the customer’s normal code-review process.

  3. 3

    Configure the trusted-publisher relationship inside the customer-controlled npm account using current npm instructions.

  4. 4

    Run any dry-run or release rehearsal only in the customer’s controlled environment after review.

  5. 5

    Merge and trigger publication only when the authorized publisher chooses to do so.

  6. 6

    Inspect the resulting registry record and keep or revert the reviewed change.

06 / Rollback notes

Define the exit before the change is merged.

  • Preserve the last reviewed workflow revision in version control.
  • Record which trusted-publisher relationship the owner would remove if the migration is abandoned.
  • Do not delete an existing release path until the owner has verified the replacement under its own controls.
  • Revert the workflow change through the repository’s normal review process if the new path is not accepted.

These are illustrative rollback categories, not instructions for a specific package. A paid handoff records the exact accepted path and known constraints.