Release packages and clean-consumer acceptance

The current Beta candidate contains twenty publishable packages synchronized at version 1.0.0-beta.9. The product-facing packages are:

@pulse-compute/pulse
@pulse-compute/runtime
@pulse-compute/cli
@pulse-compute/provider-fastly
@pulse-compute/grip
@pulse-compute/assets
@pulse-compute/crypto
@pulse-compute/jwt
@pulse-compute/entities
@pulse-compute/s3

The CLI and providers depend on additional @pulse-compute/wasm-* implementation packages. Those packages are installable transitive dependencies, not the handler authoring surface. The generated package support policy defines the tier, audience, direct-install guidance, and supported entry points for all 19 artifacts.

S3 candidate acceptance

The S3 package root supports bounded head, getText and putText on Node Native, Node JavaScript and Fastly Native. The clean-consumer gate owns the release read and write failure corpus using installed package exports, packaged lowering and provider builds. It type-checks the public declarations and compares every installed Pulse package file against its exact tarball both before and after execution. Full workspace replays remain directly selectable for development. No workspace links or installed dependency edits are permitted. The report s3-packed-acceptance.json includes all tarball SHA-256 identities and target execution counts in the acceptance task directory. The retained clean-machine-*/corpora.json report also records every internal corpus result and duration. See testing for the complete shared corpus ownership map and the workspace-only multifile assertion owner.

Fastly's host ABI fixture supplies the platform to compiled Wasm; no workspace product implementation is loaded by the packed consumer. Fastly JavaScript S3 remains ineligible for its documented raw-header limitation. Local acceptance does not claim live Object Storage behavior. That separate evidence follows infrastructure setup (T2); package promotion does not publish npm artifacts or change the existing registry bootstrap and release approval gates.

Installed feature acceptance

The aggregate release profile intentionally excludes independent installed feature proofs. The release seal now runs them as a separate mandatory step:

node scripts/release-feature-acceptance.cjs

Run from a clean, committed candidate after restoring lockfile-pinned dependencies and building the workspace. The command selects all eleven gates through the registered runner with fresh report paths. Within a recovery-aware seal, verified same-candidate checkpoints may supply completed gates; every result records whether it executed or was reused. It requires complete terminal passing coverage, matching source revisions, clean source, oracle digests, and exact installed package versions and tarball hashes. Shared package hashes must agree across proofs. The report is wasm/.test-results/release-feature-acceptance.json; its summary is retained in the release seal and checked by the evidence authority. Missing, partial, failed, dirty or stale reports fail acceptance. A later source change requires another replay on the new candidate.

Gate	Required installed acceptance
node01-installed	Finite production Node HTTP, artifact/ABI/version failures, overload, draining and secret-safe diagnostics
arc01-installed	Package-owned Entities execution and provider loading without workspace product modules
jwt-installed-workflow	Signing/verification, rotation, cleanup and explicit composition rejection
str02-installed, str02b-installed	Node JavaScript/Native request forwarding, ownership, cancellation and real incremental HTTP
str03b-installed	Enabled experimental Node generated output, slow writers and disconnects; no support promotion
ast01-installed	Assets signing facade and installed declarations
ast02b-installed, ast02d-installed	Embedded binary Assets on JavaScript and Native, bounds, HTTP subsets and deterministic manifest identity
mcp-installed	Exact CLI-shipped context app and public MCP package; production Node host, pinned official client/Codex onboarding and client-side starter CLI proof
s3-body-installed	S3 binary bodies, GET/HEAD, range/conditional outcomes, length failures, cancellation and cleanup on Node Native/JavaScript and Fastly Native ABI fixtures

These gates qualify their existing target cells. They do not expand production Node launcher support to forwarding/output/transforms/S3-body/blob applications, qualify Fastly JavaScript S3, or establish live-provider behavior. Fastly ABI fixtures remain injected evidence, distinct from local-engine and deployed proof.

Separate coverage	Disposition
str03c-bounded-transforms	Experimental workspace Native/JavaScript proof in the aggregate profile; installed transform qualification remains pending
kv-conditional-acceptance	Separately mandatory local K4 proof plus deployed Pulse cross-location evidence, as described below

The generic seal and installed feature report do not waive K4. Independent MCP SDK and generic intended-client/auth proofs remain explicit selections. The installed context journey includes pinned official-client and Codex calls in its one mandatory release owner above. Fast PR CI keeps its existing bounded selection; these dependency-bound installs belong to release acceptance.

Conditional KV acceptance

Conditional KV has additional required acceptance beyond the aggregate release profile and the generic Fastly Compute reality task:

• node wasm/scripts/run-wasm-tests.cjs --task kv-conditional-acceptance --no-report installs exact candidate tarballs and executes the Native consumer through Fastly CLI/Viceroy. An unavailable engine or undispositioned failure fails this gate. The exact documented missing-key CAS discrepancy on Viceroy 0.21.0/0.21.1 is non-blocking by explicit human release direction on October 4, 2026.
• Full deployed Pulse cross-location acceptance uses the reviewed isolated environment and probe driver described in the K4 acceptance record.

The retained Viceroy 0.21.0 run fails missing-key CAS. The October 4 B6-05 replay on clean merged latest, using official Fastly CLI 16.1.0 / Viceroy 0.21.1, reproduced that failure twice with unchanged assertions and identical module/package identities. Its machine record and handoff retain the raw failure evidence and the deployed handoff. The standalone deployed Rust SDK probe confirms rejection for never-created and deleted keys in its tested cases, but does not satisfy either required Pulse acceptance gate. Full Pulse deployed cross-location evidence remains pending the isolated environment.

Report these gates separately even when release:seal -- --require-fastly passes: that command does not include the dedicated K4 acceptance task or its deployed runner. The local task retains raw status: failed when the known Viceroy discrepancy is reproduced and adds acceptance.status: accepted-with-known-viceroy-discrepancy with acceptance.releaseBlocking: false. All other assertions and exact-installed checks still block. This disposition relies on the retained local reproduction and standalone live missing-key comparison; neither is relabeled as passing deployed Pulse acceptance. The pending full deployed requirement remains separate. Production CAS semantics are unchanged.

Event experimental candidate

Before changing release identity or package composition, the event surface has its own evidence-only package and consumer seal:

node wasm/scripts/run-wasm-tests.cjs --task events-candidate-seal --no-report

That task packs @pulse-compute/pulse, @pulse-compute/runtime, and their public contract dependency, installs the exact tarballs without network access, type-checks both application and host-maintainer event consumers, checks legal and dependency closure, and compares a second pack byte-for-byte. It also emits the event candidate decision and a blocker ledger under wasm/.test-results.

Passing this focused seal means the event-facing package closure is internally consistent. It does not authorize publication or claim Fastly/browser/ESP32 event support.

Check documentation release integrity

pnpm docs:check
node scripts/documentation-release.cjs

The documentation checks verify:

• generated documentation/package files and source-bound Markdown blocks are synchronized;
• canonical repository, installed-package, and exact-version hosted links and anchors resolve;
• every package has one generated status block and required repository metadata derived from the release manifest;
• each advertised supported package entry point exists in exports or bin;
• every public diagnostic has one real anchor and an exact-version docs URL;
• installed help, the public reference, the machine-readable command specification, and three shell completions agree on the public command and option set;
• public project, schema, development, test, and Fastly configuration fields and runtime rules agree with the shared schema and runtime normalization;
• the Fastly provider schema agrees with provider defaults and the compiled package payload;
• recognized environment variables agree with their generated scope reference;
• public plugin claims remain blocked until all six trust, discovery, compatibility, loading, and security prerequisites are implemented;
• contributor and governance pages carry valid owner, status, review, and stale-date metadata;
• the exact-version documentation site contains release banners, local search, and version navigation.

Maintainer-only task and report controls remain available to repository truth suites but are absent from installed help and the public CLI reference.

Pack a release candidate

From the source workspace:

pnpm release:pack

This builds the workspace and writes twenty package tarballs plus pulse-release-manifest.json under .pulse-release/. It prepares release artifacts; it does not publish them to a registry.

Packing fails when:

• a package is private or versions diverge;
• a packed dependency retains workspace:;
• repository-only tests or internal documentation leak into a tarball;
• required API/CLI reference files are absent;
• a Markdown link or anchor is dead after extraction;
• a link escapes its package root;
• an exact-version Pulse documentation URL does not map to a real file and anchor in the packed release set.

@pulse-compute/runtime ships its canonical API and preview-scope references. @pulse-compute/cli ships the public documentation hierarchy, API/CLI/config/diagnostic/package references, bounded compatibility material, and runnable example sources.

Clean-consumer acceptance

node wasm/scripts/run-wasm-tests.cjs --task clean-machine-acceptance --no-report

The release task creates an isolated npm home and cache, installs exact packed candidates rather than workspace links, and validates:

install
→ pulse init
→ npm install
→ pulse doctor
→ pulse inspect
→ pulse test
→ pulse dev --once
→ pulse build

It runs that workflow for new Native and JavaScript Node/Fastly projects, verifies a real Fastly Native bin/main.wasm, and installs/builds the canonical GRIP and Router examples from the packed package set. The two JavaScript projects prove packed inspect, passing doctor, test, one-request dev, provider-neutral compile, and deterministic build. Their executable source packages contain exact reachable dependencies, no Native planning artifacts, and automaticFallback: false. The Node target satisfies all 12 support gates; the Fastly target satisfies all six support gates, emits source/deployment manifests with provider reality and deployment still false, and does not install the downstream Fastly compiler into an ordinary Pulse consumer.

Offline deployment candidates

npm run release:candidates

This gate builds the representative Fastly Native and Fastly JavaScript targets twice from the same output location. Native output, including bin/main.wasm, must be byte-identical. Fastly JavaScript source, deployment metadata, and exact toolchain closure must be byte-identical; one closure is then compiled by the pinned @fastly/js-compute runtime compiler into bin/main.wasm.

The downstream Wizer snapshot is recorded by exact SHA-256 but is not presented as byte-reproducible. The candidate report distinguishes that toolchain-owned property from Pulse-owned deterministic input and metadata. It also records zero provider-reality runs, zero deployments, and zero publications.

The task owns the twenty publishable Pulse packages, not the packages in the development installation. It installs every exact Pulse tarball into clean consumer projects and verifies the installed name, version, and real path. An ephemeral server bound to 127.0.0.1 is the fail-closed registry for the @pulse-compute scope, so an undeclared or missing Pulse candidate cannot fall through to a previously published package. Third-party dependencies resolve from the canonical npm registry according to the packed manifests; the release gate does not repack or assume ownership of assemblyscript, long, esbuild, or other external packages. Lockfile and dependency evidence remain separate workspace inputs.

External Fastly Compute execution is also separate:

PULSE_FASTLY_BIN=/path/to/fastly \
node wasm/scripts/run-wasm-tests.cjs --task provider-fastly-compute-reality --no-report

The task records the Fastly CLI version, invokes fastly compute serve --file, and lets the CLI own its local Compute engine. It then sends real HTTP requests through the generated native module. PULSE_VICEROY_BIN remains available only as an explicit lower-level reproduction override. The fixture covers schemas, configuration, secrets, KV persistence, named-backend fetch, opaque bytes, repeated headers, and GRIP hold/publish. It does not deploy or activate a Fastly service.

Aggregate seal and evidence

Testing Pulse owns execution, deadlines, shared packing, recovery and cleanup. The seal runs source checks before the TypeScript build, the complete release profile, mandatory installed features, and external Fastly proof when required. Workspace and installed checks cannot be pooled manually into a passing release claim.

Complete example workflows include default and experimental Native-size assertions. Run the size-only command for diagnosis, not as a replacement:

node wasm/test/docs/assert-executable-documentation.cjs --section sizes

The seal refreshes vulnerability and license evidence. Mutable npm publisher settings, GitHub environments and production documentation availability remain blocking where those authorities are used, at publication or deployment.

With a clean passing seal, create the release evidence delivery:

npm run release:evidence -- \
  --base <accepted-source-ref> \
  --head HEAD \
  --label <delivery-name> \
  --out <new-output-directory>

The evidence authority checks that all reports belong to the exact head revision and cover the complete ordered selection. For recovery-aware seals it uses the attempt-local report/artifact paths and validates their sealed hashes, checkpoint provenance and successful cleanup. Focused or manually pooled reports do not qualify. It aggregates sixteen passing shards, creates source and binary-patch artifacts, independently applies the patch to the accepted source archive, and compares path, mode, and bytes with the sealed head. The resulting bundle is offline evidence only; merge, tagging, deployment, activation, and publication remain human-authority operations.

Publication workflow

The npm publishing runbook owns release preparation, pre-main qualification, merge/tag binding, package-name bootstrap, protected publication, retries and registry verification. It consumes the exact qualified tarballs; a local acceptance run alone does not authorize publication.

Publication hold points

Before publication, confirm the repository, final documentation host/base path, package policy, and issue-tracker values centralized in release/pulse-release-manifest.json. Pulse is licensed under Apache-2.0: the release gate requires the exact root LICENSE, SPDX metadata in the workspace and all twenty publishable packages, and the same license text in every npm tarball. A dependency-license audit and its dispositions remain separate release evidence.

A human release authority must approve npm-publish. Codex may diagnose or prepare a patch but cannot publish, approve the environment, bootstrap package names, or mutate dist-tags.

Versioned documentation artifact

The documentation update loop owns source and hosted-site checks. Qualification retains the validated versioned site alongside the exact package candidate. The deployment runbook owns immutable Object Storage uploads, registry gating, promotion and public URL verification. The versioning procedure owns preserved history.

Release packing also checks the installed CLI command specification, configuration schema bundle, release/version manifests, shell completions, current architecture and plugin-readiness records, maintenance policy, and publication/deployment references.