Release packages and clean-consumer acceptance

The current Beta candidate contains twenty publishable packages synchronized at version 1.0.0-beta.10. 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; source-free Node Native five-tool replay, independent resource reconstruction and corrupt-closure rejection; generic multi-owner resource closure on installed Node Native/JavaScript after source removal; plus 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.

The context application has a separate exact-installed local acceptance task:

PULSE_FASTLY_BIN=/path/to/fastly PULSE_VICEROY_BIN=/path/to/viceroy \
  node wasm/scripts/run-wasm-tests.cjs --task mcp-fastly-local-installed

This task requires both tools and invokes the actual Fastly CLI with the selected Viceroy binary. It uses the standard package candidates, an unrelated installed consumer and its shipped fastly-native profile. Independent expectations cover all five tools, complete read/search pagination, citations, admission failures and repeated requests. Separately identified growth, deadline and generic resource fixtures exercise the admitted row ceiling, UTF-8/bounds behavior, deduplication, unused resource elimination, workspace lifetime and cumulative allocation failure. No configured backend or JavaScript fallback participates in these requests.

Receipts retain package, source, configuration, context-manifest and module hashes, tool versions, HTTP outcomes, latency and the module's declared memory bounds. Host RSS is sampled only when observable; live guest allocation counts and peak heap remain unknown. Failed runs remain failed. This standalone development task does not extend the release selection or authorize deployment. Final release use requires a fresh run bound to the selected immutable candidate.

The task requires generic workspace/resource bounds failures to produce HTTP 500, not an empty success response. The provider's terminal response preserves the original failure diagnostics while body, transport and deadline handlers retain their specific responses. Failed historical runs remain failed; allocation trapping and subsequent healthy requests are recorded separately. A new complete run is required after a provider repair before claiming local acceptance.

Pinned client qualification of the installed Native endpoint is a separate task:

PULSE_FASTLY_BIN=/path/to/fastly PULSE_VICEROY_BIN=/path/to/viceroy \
  node wasm/scripts/run-wasm-tests.cjs --task mcp-fastly-clients-installed

It reuses the exact-package installation and actual local host lifecycle above. The shipped application keeps its default 2026-07-28 profile. A separately hashed fixture enables 2025-06-18 explicitly through the existing binding option. The frozen official SDK 2.2.0 exercises both profiles, Claude Code 2.1.292 exercises 2026-07-28, and Codex 0.160.1 exercises 2025-06-18. Host controls make explicit calls without model turns or operator accounts. A loopback recording relay forwards request/response bytes to Viceroy without MCP translation.

Each client/profile has a terminal receipt binding its frozen lockfile, installed client files, application source/configuration, build receipts and Wasm identity. All five tools are compared with independent expectations. Separate wire checks cover IDs, notifications, protocol errors, disabled capabilities, admission and recovery. Malformed modern requests must fail even on the explicitly compatible variant. Dependency failures remain blockers, other row failures remain failures, and unexecuted rows cannot pass. Existing root/Node adapter qualification remains separate. This task adds no transport, deployment or release-selection authority.

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.

The v3 source-check receipt includes an independent, read-only reconstruction of the context corpus, vectors and generated application through the existing context builder. It binds the clean candidate tree, producer source/configuration, allowlist, lockfile, manifest, generated output hashes and complete release and installed-feature selections. Missing, stale, extra or corrupt context outputs fail before packaging; checks never regenerate candidate files.

Packing compares every file in the CLI-shipped context application against this verified inventory, then records its freshness digest alongside the exact package closure. Standalone packing performs its own reconstruction, including with --skip-build. The controller requires the complete installed-feature runner, the mcp-installed receipt and matching tarball hashes before recording pulse.release-context-qualification.v1. Evidence aggregation rechecks retained receipt and tarball bytes and copies the source-check receipt, pack manifest and installed runner into the bundle. It does not refresh data after sealing. Fast PR checks remain development evidence; they do not replace installed qualification.

Every resume runs fresh source checks before attempting checkpoint reuse. The controller validates that receipt against the current candidate immediately, rechecks its pinned bytes before package admission, and binds the stable context freshness digest as the shared-pack checkpoint prerequisite. Receipt duration and attempt-local metadata do not invalidate an identical proof; candidate, producer, configuration, lockfile, generated bytes and complete selections do. Missing, invalid or changed current receipts stop before reuse. Expired or damaged retained package proofs cause repacking and invalidate their dependent task proofs; missing installed receipts rerun their owning tasks. Only the explicitly selected prior attempt supplies checkpoints. Failed attempts are retained unchanged, and a resume must still finish both complete canonical selections.

The release-recovery task includes a deterministic context-specific controller matrix with heavy product commands mocked. It covers receipt faults, source/input identity changes, expiry, changed package bytes, interrupted execution, complete resume and rejection of unselected historical passes. This proves recovery control flow and receipt admission, not installed product behavior or release qualification.

Before freezing the integrated MCP/resource candidate, run docs:sync, then context:build with the pinned producer Node, then docs:sync and context:check. Commit all canonical and installed mirrors together. A source citation or workflow edit can change corpus, vector and Wasm identities even when the encoder is unchanged. Freeze only after regeneration; subsequent edits, including evidence commits, describe a new source revision and require a new candidate selection. Never copy old receipts into that selection as fresh passes.

The integrated handoff must record the clean revision/tree, complete expansion of the release profile, all REQUIRED_TASKS from scripts/release-feature-acceptance.cjs, package manifest and tarball hashes, source-check/context inventory, lockfile and tool identities, terminal statuses, failed attempts and remaining external gates. Use the existing controller with --require-fastly; explicitly retain the separate mcp-fastly-local-installed and mcp-fastly-clients-installed receipts as well. Those two MCP gates are not silently included by the aggregate profile. Preserve the separate KV/deployed-provider dispositions and unresolved report-integrity observations. A passing local provider receipt is not deployed proof.

B10-09 / #382 owns the full integrated qualification. The documentation handoff does not run or approve that seal. Resource issues #412 and #381 require real-workload, generic-resource, installed, reporting and provider evidence reconciled to the selected candidate; implementation history alone does not close them. No release, merge or deployment is authorized by a completed documentation or development gate.

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. New v2 package qualification retains source-only documentation evidence alongside the exact package candidate; it does not build or retain a website. Historical v1 qualification still requires its original validated site and rejects missing or changed bytes. 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.