Skip to main content

Trusted npm publishing for contributors

The trusted-publishing rail lives under scripts/npm-publish/ and ships as .github/workflows/npm-publish.yml: dev publishes on every eligible push to main (pushes touching only docs/**, dev-docs/**, or root-level *.md files are skipped by the workflow’s paths-ignore); stable staging runs on workflow_dispatch and is auto-dispatched on release creation by the dispatch-stable-stage job in release-please.yml (the npm stage approve step stays human). Do not add a second publish path. Compatibility target: Node.js >=24.0.0. Planned publication jobs also require npm >=11.15.0. Current package version is 0.4.11 from package.json.

Publication contract

validateInvocation() accepts only that identity. Forks, pull requests, arbitrary branches, caller-selected package names, OTP inputs, and registry substitution fail before candidate work. Package order is fixed: Stable automation stages @wednesdayai/whatsapp and then wednesdayai in the same stable job, skipping any package already live at that version, and stops for human approval. A maintainer runs npm stage list, then approves each package for which a stage was created interactively with npm stage approve <stage-id> (one invocation per stage). Packages already live need no approval. After all created stages are approved, the maintainer dispatches npm-publish.yml with verify_approved=yes to verify both packages, including skipped packages, against the recorded pack integrities and installed pair. Core staging does not wait for WhatsApp approval. Dev publication publishes WhatsApp, then core, directly to the dev dist-tag.

release-check

pnpm release:check maps to scripts/release-check.ts. WhatsApp metadata required by the static check:
  • name @wednesdayai/whatsapp
  • not private
  • repository git+https://github.com/ExpansionX/WednesdayAI-core.git
  • extension entry ./dist/index.js
  • runtime deps @whiskeysockets/baileys and qrcode-terminal

Identifiers and versions

Shared identifier grammar is /^[a-z0-9][a-z0-9._-]{0,127}$/ plus a bounded colon campaign form. Dev versions use git describe --abbrev=40. Do not invent a shorter abbrev or a second grammar. Baseline verification is two-layer and nonrecursive: a semantic checksum plus separately downloaded durable metadata (Release ID, logical/physical asset names, physical SHA-256). Embedded self-hash durable is rejected. Artifact retrieval, hash verification of downloaded bytes, and receipt append belong to Task 025 / the CLI router. Do not add them to Task 013 or to release-check.

What not to do

Avoid:
  • Adding npm publish or npm stage publish outside npm-publish.yml.
  • Publishing a working directory instead of an exact sealed tarball.
  • Administering stages or dist-tags through OIDC.
  • Moving or reusing a release tag.
  • Treating NPM_TOKEN as the long-term publisher. Traditional credentials remain only until live canaries pass.

Deployment artifact parity and vendoring

Every deployment must reference a reproducible artifact: either a published immutable registry version, or a vendored tarball with a recorded provenance manifest. A bare source build with no record is not a parity-pinable deployment.
  1. Prefer registry artifacts. For stable deployments, install wednesdayai@<X.Y.Z> (immutable once published). For main-adjacent commits, install the dev dist-tag and confirm the artifact was built from the intended commit: tar -xOf wednesdayai-<v>.tgz package/dist/build-info.json and check commit equals the full SHA you expect.
  2. Otherwise vendor from the exact deployment commit. When no registry artifact matches (branch-built deployments), build at the pinned commit and record provenance:
    Record a provenance manifest: package name, canonical version, full source SHA, channel, tarball filename, integrity (sha512 from npm pack --json), size, and builtAt from dist/build-info.json. Pin downstream via the tarball path/URL plus its integrity — npm install <tarball> records the integrity in the lockfile, giving downstream pins the same immutability as a registry version. Docker source builds must pass GIT_COMMIT and OPENCLAW_BUILD_CHANNEL explicitly (.dockerignore excludes .git; an unset commit breaks provenance).
  3. Contract. The npm-parity scheduled watchdog flags tags without registry counterparts and a stalled dev rail, but it cannot see untracked hand-built deployments — the vendoring manifest above is the only sanctioned form for those.