@pulse-compute/cli 1.0.0-beta.1 → 1.0.0-beta.3

package/docs/maintainers/maintainer-charter.md

@@ -29,6 +29,13 @@ The human maintainer owns decisions that change what Pulse is:
 
 A direct task can authorize implementation, but approval must remain visible in the pull request when a protected boundary changes.
 
+Once that direction is supplied, Codex may complete the necessary implementation,
+tests, canonical documentation, regeneration and PR preparation within its scope.
+It records the authorization rather than requesting it again. A protected-path
+touch requires declaration and review; a semantic change beyond the authorized
+scope requires a new decision. Implementation direction does not authorize merge,
+publication, deployment or self-approval.
+
 ### Codex resident maintainer
 
 Codex provides first-line maintenance capacity:
@@ -48,12 +55,21 @@ Codex does not receive standing authority to expand scope. It does not merge or
 
 ### Preserve host sovereignty
 
-The guest receives bounded inputs and declared capabilities. Consequential authority remains with the host and is represented through explicit effects or bindings. A maintenance change must not introduce ambient filesystem, network, secret, store, provider SDK, or process authority into canonical user code.
+The Native guest receives bounded inputs and declared capabilities. Pulse host
+authority is represented through explicit effects or bindings. A maintenance
+change must not introduce ambient filesystem, network, secret, store, provider
+SDK or process authority into the Native guest or the Pulse handler context.
 
 ### Compile only what can be proven
 
 Unsupported behavior fails visibly. A convenience change must not add a hidden JavaScript fallback, reinterpret a rejected program under another runtime, or make provider behavior diverge silently.
 
+Explicit JavaScript targets retain the original source graph, resolved static
+imports and ordinary awaited calls while preserving canonical application and
+Pulse effect validation. Inspection describes recognized Pulse effects; it does
+not prove dependency internals, grant lowerer trust or imply sandbox enforcement
+for ordinary JavaScript. Native eligibility remains independent.
+
 ### Separate evidence from promises
 
 A reproduction, benchmark, experiment, or external use case can be valuable without becoming a roadmap item. Incoming evidence is recorded first. A compatibility or support promise requires an explicit scope decision.

package/docs/maintainers/maintenance-policy.json

@@ -1,8 +1,8 @@
 {
   "schemaVersion": "pulse.maintenance-policy.v2",
-  "policyVersion": 6,
-  "releaseVersion": "1.0.0-beta.1",
-  "reviewedAt": "2026-08-01",
+  "policyVersion": 7,
+  "releaseVersion": "1.0.0-beta.3",
+  "reviewedAt": "2026-09-13",
   "maintainerModel": {
     "residentMaintainer": "Codex",
     "architectureAuthority": "human",
@@ -435,6 +435,37 @@
       ],
       "risk": "critical"
     },
+    {
+      "id": "target-compilation",
+      "patterns": [
+        "wasm/packages/cli/src/project-execution.js",
+        "wasm/packages/compiler/src/canonical-api-compiler.js",
+        "wasm/packages/compiler/src/canonical-project-compiler.js",
+        "wasm/packages/compiler/src/canonical-native-plan.js",
+        "wasm/packages/compiler/src/javascript-application-plan.js",
+        "wasm/packages/compiler/src/project/router-module-linker.js",
+        "wasm/packages/compiler/src/spine/async-surface-normalizer.js",
+        "wasm/packages/compiler/src/spine/plain-handler-frontend.js",
+        "wasm/packages/compiler/src/spine/router-handler-frontend.js"
+      ],
+      "areas": [
+        "compiler",
+        "cli"
+      ],
+      "boundaries": [
+        "runtime-target-fluidity"
+      ],
+      "checks": [
+        "documentation",
+        "unit",
+        "native",
+        "javascript",
+        "conformance",
+        "cli",
+        "build"
+      ],
+      "risk": "high"
+    },
     {
       "id": "configuration",
       "patterns": [

package/docs/maintainers/maintenance-policy.md

@@ -5,9 +5,9 @@
 Pulse uses a machine-readable maintenance policy so repository automation and Codex receive the same scope boundaries. The policy is advisory about product direction and mandatory about process: Codex may analyze, review, and prepare bounded patches, while a human retains architecture, merge, repository-setting, and release authority.
 
 - **Policy schema:** `pulse.maintenance-policy.v2`
-- **Policy version:** `6`
-- **Release:** `1.0.0-beta.1`
-- **Reviewed:** `2026-08-01`
+- **Policy version:** `7`
+- **Release:** `1.0.0-beta.3`
+- **Reviewed:** `2026-09-13`
 - **Resident maintainer:** Codex
 - **Merge authority:** human-only
 - **Release authority:** human-only

package/docs/maintainers/npm-publishing.md

@@ -29,7 +29,7 @@ The machine-readable publication contract is the `publication` object in `releas
 Use the manifest-owned preparation policy instead of repository-wide version replacement:
 
 ```bash
-pnpm release:prepare -- 1.0.0-beta.2 --channel beta --replace-unpublished
+pnpm release:prepare -- 1.0.0-beta.3 --channel beta --replace-unpublished
 ```
 
 `--replace-unpublished` replaces the current candidate without inventing release history. After a version has actually shipped, use `--archive-current`; that mode requires the committed immutable documentation snapshot. The command updates only catalogued JSON, package, guest-metadata, and current-documentation owners, runs named generators, rejects newly changed paths outside its allowlist, and writes an ignored stale-version-token report for review.
@@ -44,8 +44,8 @@ For example:
 
 ```bash
 gh workflow run npm-publish.yml \
-  --ref v1.0.0-beta.1 \
-  -f release_tag=v1.0.0-beta.1 \
+  --ref v1.0.0-beta.3 \
+  -f release_tag=v1.0.0-beta.3 \
   -f operation=audit
 ```
 
@@ -66,10 +66,24 @@ environment: npm-publish
 ```
 
 The workflow publishes public packages directly under the dist-tag in the
-release manifest. OIDC is deliberately not combined with a post-publication
-`npm dist-tag` mutation. The protected script verifies the native GitHub tag ref
+release manifest, now explicitly `latest` for future releases. The release
+channel and prerelease version remain Beta; the npm tag determines what an
+unqualified `npm install` selects. Release preparation preserves this tag
+policy across version bumps. An explicitly configured channel tag remains
+supported for a release intended for a separate preview stream.
+
+The pinned npm CLI's trusted publishing does not support a separate
+post-publication `npm dist-tag` update. Each successful `npm publish --tag latest`
+therefore advances that package's default version as part of publication;
+the historical `beta` alias is not also advanced. The package set is published
+in dependency order, with the public CLI last, and promotion is not atomic
+across packages. The protected script verifies the native GitHub tag ref
 and SHA against the sealed candidate before the first publish.
 
+This policy applies to future candidate source. Finish an already-started
+release using its original tag, tooling, and sealed tarballs. Do not move that
+tag or rebuild the same published version to adopt a new publication policy.
+
 ## One-time package bootstrap
 
 An npm trusted publisher can be configured only after the package name exists under the intended owner. Before enabling production publication, run:
@@ -78,7 +92,7 @@ An npm trusted publisher can be configured only after the package name exists un
 npm run release:audit-npm
 ```
 
-The command derives every package name from the release manifest and writes a timestamped, manifest-digest-bound report to `.pulse-release-preflight/npm-catalog-audit.json`. That report is ignored source evidence: it never rewrites the canonical preflight policy and it performs no registry mutation. The audit is ready only when every name exists, `bootstrap` points to `0.0.0`, and `latest` is either absent or still points to the same inert `0.0.0` placeholder. A different `latest` target remains blocking and any required dist-tag remediation is an explicit human registry action.
+The command derives every package name from the release manifest and writes a timestamped, manifest-digest-bound report to `.pulse-release-preflight/npm-catalog-audit.json`. That report is ignored source evidence: it never rewrites the canonical preflight policy and it performs no registry mutation. Every name must exist with the inert `0.0.0` version and `bootstrap` tag. The `latest` tag may be absent, point to that placeholder, or point to a version both present in the registry and listed in `release/documentation-versions.json`. This preserves existing releases during the next bootstrap audit. Missing versions and unknown release targets remain blocking; any remediation is an explicit human registry action.
 
 Any missing package name requires a one-time human, 2FA-protected bootstrap publication through `scripts/npm_bootstrap.sh <package-name>`. After all names exist:
 
@@ -129,6 +143,20 @@ version present with different integrity
 
 This is resumable after a partially completed synchronized-package release without pretending npm publication is transactional. A same-version integrity mismatch cannot be repaired by overwriting the registry artifact; the human release authority must investigate and choose a new version if necessary.
 
+npm can accept an upload while the version is still being processed. After
+each successful publish, the script polls for up to ten minutes for both the
+sealed integrity and configured tag, using fresh registry reads and intervals
+capped at 30 seconds. Progress goes to stderr and identifies the package,
+attempt, elapsed time, and whether the version or tag is still pending.
+An observed integrity conflict stops immediately.
+
+If processing exceeds the deadline, wait for registry visibility and use
+**Re-run failed jobs** on the same workflow run. Keep the release tag and sealed
+candidate unchanged: matching published packages are skipped, and publication
+continues with the remaining packages. No new seal is required for that retry.
+If source changes and a tag is moved before any publication, start a new workflow
+dispatch instead; GitHub reruns retain the original event's commit SHA.
+
 ## Verification
 
 The protected publish job verifies each package immediately. A separate unprivileged job then confirms:

package/docs/maintainers/plugin-readiness.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": "pulse.plugin-readiness.v1",
-  "releaseVersion": "1.0.0-beta.1",
+  "releaseVersion": "1.0.0-beta.3",
   "publicPluginApi": false,
   "decision": "deferred",
   "requirements": {

package/docs/maintainers/plugin-readiness.md

@@ -4,7 +4,7 @@
 
 > **Decision:** Deferred. No public third-party plugin API is available in this release.
 
-Pulse 1.0.0-beta.1 keeps general plugin discovery and package lowering inside the synchronized trusted release. Provider bootstrap is explicit and exact. The current boundaries are:
+Pulse 1.0.0-beta.3 keeps general plugin discovery and package lowering inside the synchronized trusted release. Provider bootstrap is explicit and exact. The current boundaries are:
 
 - **Lowerers:** trusted first-party release packages only.
 - **Providers:** explicit package selection through pulse.provider-toolchain.v1; bare host IDs use the @pulse-compute/provider-<id> convention, scoped names are exact, and none is internal; no scanning or self-registration.

package/docs/maintainers/release-acceptance.md

@@ -7,8 +7,8 @@ pulse-doc-meta:end -->
 
 # Release packages and clean-consumer acceptance
 
-The current Beta candidate contains eighteen publishable packages
-synchronized at version `1.0.0-beta.1`. The product-facing packages are:
+The current Beta candidate contains nineteen publishable packages
+synchronized at version `1.0.0-beta.3`. The product-facing packages are:
 
 ```text
 @pulse-compute/pulse
@@ -20,13 +20,56 @@ synchronized at version `1.0.0-beta.1`. The product-facing packages are:
 @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](../packages/README.md) defines the tier, audience,
-direct-install guidance, and supported entry points for all 18 artifacts.
+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 repeats the
+same 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. 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.
+
+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.
+
+## 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 semantic failure fails this gate.
+- Full deployed Pulse cross-location acceptance uses the reviewed isolated
+  environment and probe driver described in the
+  [K4 acceptance record](https://github.com/pulse-compute/pulse/blob/latest/wasm/test/kv/K4.md).
+
+The retained Viceroy 0.21.0 run fails missing-key CAS. 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. Preserve the local failure and pending deployed requirement as
+release-readiness blockers. An explicit human-directed acceptance-policy change
+must specify any replacement evidence and update the owning gates and current
+contracts; a guidance update alone neither waives a gate nor changes CAS behavior.
 
 ## Event experimental candidate
 
@@ -79,7 +122,7 @@ From the source workspace:
 pnpm release:pack
 ```
 
-This builds the workspace and writes eighteen package tarballs plus `pulse-release-manifest.json` under `.pulse-release/`. It prepares release artifacts; it does not publish them to a registry.
+This builds the workspace and writes nineteen 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:
 
@@ -143,7 +186,7 @@ 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 eighteen publishable Pulse packages, not the packages in the
+The task owns the nineteen 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
@@ -216,7 +259,7 @@ Before the first trusted publication, every package name must exist and authoriz
 
 ## 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 eighteen publishable packages, and the same license text in every npm tarball. A dependency-license audit and its dispositions remain separate release evidence.
+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 nineteen 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.
 
@@ -228,7 +271,7 @@ The release owns a versioned hosted-documentation gate:
 pnpm docs:site:check
 ```
 
-The check builds the exact `v1.0.0-beta.1` site and `latest` tree in a temporary directory, creates one search entry per public page, validates local hosted links, verifies release/version manifests, and requires the search, version, owner, and review UI on every page.
+The check builds the exact `v1.0.0-beta.3` site and `latest` tree in a temporary directory, creates one search entry per public page, validates local hosted links, verifies release/version manifests, and requires the search, version, owner, and review UI on every page.
 
 The **Documentation** workflow repeats those checks for pull requests and `main`, seals a preview deployment manifest, and uploads artifacts without production credentials. It does not deploy to GitHub Pages.
 
@@ -236,7 +279,7 @@ Production delivery uses the manually dispatched **Documentation deployment** wo
 
 ```text
 build and seal
-→ upload/verify v1.0.0-beta.1 and its receipt immutably
+→ upload/verify v1.0.0-beta.3 and its receipt immutably
 → verify all matching npm packages and configured dist-tags
 → promote root and latest
 → verify representative URLs through Fastly

package/docs/maintainers/release-manifest.md

@@ -6,8 +6,8 @@
 
 ## Beta candidate
 
-- **Candidate:** Pulse 1.0.0-beta.1 — Beta
-- **Version:** `1.0.0-beta.1`
+- **Candidate:** Pulse 1.0.0-beta.3 — Beta
+- **Version:** `1.0.0-beta.3`
 - **Activation stage:** `documentation-release`
 - **License:** `Apache-2.0`
 - **Supported Node:** `^22.14.0 || ^24.0.0`
@@ -16,9 +16,9 @@
 - **Reproducible publication toolchain:** Node `24.18.0` with npm `11.15.0`
 - **Readiness register:** `release/release-preflight.json`
 - **Documentation inventory:** `release/documentation-inventory.json`
-- **Exact documentation:** `https://pulsecompute.io/v1.0.0-beta.1/`
+- **Exact documentation:** `https://pulsecompute.io/v1.0.0-beta.3/`
 - **Runtime targets:** 3
-- **Packages:** 18
+- **Packages:** 19
 
 The installed CLI ships the same machine-readable data as
 `release-manifest.json`. The atomic snapshot transaction aligns
@@ -66,23 +66,24 @@ scoped package name.
 
 | Package | Support tier | Canonical guide | Direct installation |
 |---|---|---|---|
-| `@pulse-compute/runtime` | Canonical application surface | [Guide](../packages/runtime.md) | Yes. Install it in every Pulse application. |
-| `@pulse-compute/pulse` | Canonical application surface | [Guide](../packages/pulse.md) | Yes. Install it in every conventional Pulse project. |
-| `@pulse-compute/cli` | Canonical application surface | [Guide](../packages/cli.md) | Yes. Install the package globally or as a project development dependency. |
-| `@pulse-compute/provider-fastly` | Supported provider/extension surface | [Guide](../packages/provider-fastly.md) | Yes, for Fastly projects. Node-only projects do not need to import it directly. |
-| `@pulse-compute/grip` | Supported provider/extension surface | [Guide](../packages/grip.md) | Yes, only when the application uses GRIP/Fanout behavior. |
-| `@pulse-compute/assets` | Supported provider/extension surface | [Guide](../packages/assets.md) | Yes, only when the application uses the assets capability. |
-| `@pulse-compute/crypto` | Supported provider/extension surface | [Guide](../packages/crypto.md) | Yes, when an application uses the crypto verification surface directly; JWT applications receive it transitively. |
-| `@pulse-compute/jwt` | Supported provider/extension surface | [Guide](../packages/jwt.md) | Yes, when an application verifies JWTs. |
-| `@pulse-compute/entities` | Supported provider/extension surface | [Guide](../packages/entities.md) | Yes, when an application declares entity operations. |
-| `@pulse-compute/wasm-build-support` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively where required. |
-| `@pulse-compute/wasm-compiler` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; use the pulse CLI. |
-| `@pulse-compute/wasm-guest-link` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is an internal synchronized compiler dependency. |
-| `@pulse-compute/wasm-contracts` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | Provider toolchain authors may install it for the versioned bootstrap contract; application projects receive it transitively. |
-| `@pulse-compute/wasm-host-runtime` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
-| `@pulse-compute/wasm-library-kit` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
-| `@pulse-compute/provider-node` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; select provider: node through the CLI. |
-| `@pulse-compute/wasm-runtime-core-as` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
-| `@pulse-compute/wasm-schema-json` | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; declare schemas in the selected .pulse/config.ts profile. |
+| [`@pulse-compute/runtime`](https://www.npmjs.com/package/@pulse-compute/runtime) | Canonical application surface | [Guide](../packages/runtime.md) | Yes. Install it in every Pulse application. |
+| [`@pulse-compute/pulse`](https://www.npmjs.com/package/@pulse-compute/pulse) | Canonical application surface | [Guide](../packages/pulse.md) | Yes. Install it in every conventional Pulse project. |
+| [`@pulse-compute/cli`](https://www.npmjs.com/package/@pulse-compute/cli) | Canonical application surface | [Guide](../packages/cli.md) | Yes. Install the package globally or as a project development dependency. |
+| [`@pulse-compute/provider-fastly`](https://www.npmjs.com/package/@pulse-compute/provider-fastly) | Supported provider/extension surface | [Guide](../packages/provider-fastly.md) | Yes, for Fastly projects. Node-only projects do not need to import it directly. |
+| [`@pulse-compute/grip`](https://www.npmjs.com/package/@pulse-compute/grip) | Supported provider/extension surface | [Guide](../packages/grip.md) | Yes, only when the application uses GRIP/Fanout behavior. |
+| [`@pulse-compute/assets`](https://www.npmjs.com/package/@pulse-compute/assets) | Supported provider/extension surface | [Guide](../packages/assets.md) | Yes, only when the application uses the assets capability. |
+| [`@pulse-compute/crypto`](https://www.npmjs.com/package/@pulse-compute/crypto) | Supported provider/extension surface | [Guide](../packages/crypto.md) | Yes, when an application uses the crypto verification surface directly; JWT applications receive it transitively. |
+| [`@pulse-compute/jwt`](https://www.npmjs.com/package/@pulse-compute/jwt) | Supported provider/extension surface | [Guide](../packages/jwt.md) | Yes, when an application verifies JWTs. |
+| [`@pulse-compute/entities`](https://www.npmjs.com/package/@pulse-compute/entities) | Supported provider/extension surface | [Guide](../packages/entities.md) | Yes, when an application declares entity operations. |
+| [`@pulse-compute/s3`](https://www.npmjs.com/package/@pulse-compute/s3) | Supported provider/extension surface | [Guide](../packages/s3.md) | Yes, when an application uses S3 object operations. |
+| [`@pulse-compute/wasm-build-support`](https://www.npmjs.com/package/@pulse-compute/wasm-build-support) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively where required. |
+| [`@pulse-compute/wasm-compiler`](https://www.npmjs.com/package/@pulse-compute/wasm-compiler) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; use the pulse CLI. |
+| [`@pulse-compute/wasm-guest-link`](https://www.npmjs.com/package/@pulse-compute/wasm-guest-link) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is an internal synchronized compiler dependency. |
+| [`@pulse-compute/wasm-contracts`](https://www.npmjs.com/package/@pulse-compute/wasm-contracts) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | Provider toolchain authors may install it for the versioned bootstrap contract; application projects receive it transitively. |
+| [`@pulse-compute/wasm-host-runtime`](https://www.npmjs.com/package/@pulse-compute/wasm-host-runtime) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
+| [`@pulse-compute/wasm-library-kit`](https://www.npmjs.com/package/@pulse-compute/wasm-library-kit) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
+| [`@pulse-compute/provider-node`](https://www.npmjs.com/package/@pulse-compute/provider-node) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; select provider: node through the CLI. |
+| [`@pulse-compute/wasm-runtime-core-as`](https://www.npmjs.com/package/@pulse-compute/wasm-runtime-core-as) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; it is installed transitively. |
+| [`@pulse-compute/wasm-schema-json`](https://www.npmjs.com/package/@pulse-compute/wasm-schema-json) | Implementation/transitive surface | [Guide](../packages/implementation-packages.md) | No for application projects; declare schemas in the selected .pulse/config.ts profile. |
 
 A package export that is absent from its manifest entry is not promoted to a supported application-author API merely because Node or npm can resolve it.

package/docs/maintainers/scope-policy.md

@@ -23,6 +23,12 @@ Every issue and pull request begins with one change class:
 
 The first four classes can normally move to implementation and human review. The last three require a separate human decision before implementation is treated as approved direction.
 
+A direct human task can supply that decision. Record its scope in the PR and
+continue the necessary implementation, tests, canonical documentation,
+regeneration and PR preparation. Do not ask again for the same direction.
+New semantics or authority outside that scope still require a new decision;
+implementation approval does not authorize merge, publication or deployment.
+
 ## Declare affected boundaries
 
 Path rules conservatively infer protected boundaries, including the public API, effects and capabilities, continuations, lowerer trust, provider registry, configuration contract, compatibility surface, package publication, maintenance control plane, and release authority.
@@ -44,6 +50,12 @@ Human decision: not-required
 
 Use comma-separated boundary IDs, or `none`. Use `required` when scope, architecture, or release authority needs an explicit decision.
 
+`Human decision: required` identifies the decision authority even when the human
+has already supplied direction. Keep the field accurate and describe the supplied
+direction and any outstanding question in prose. The classifier does not verify
+or grant approval. A protected-path match alone does not require this field to be
+`required` for a defect that preserves the existing contract.
+
 The `Maintainer scope / scope` check compares the declaration with changed paths. It has three outcomes:
 
 - **pass** — the declaration is present and consistent with the conservative path inference;
@@ -72,7 +84,7 @@ Run the classifier locally with a pull-request body saved to a file:
 
 ```bash
 node scripts/maintainer-scope.cjs \
-  --base origin/main \
+  --base <actual-pr-base-ref> \
   --head HEAD \
   --declaration-file /tmp/pulse-pr-body.md \
   --check

package/docs/maintainers/testing.md

@@ -39,6 +39,11 @@ node wasm/scripts/run-wasm-tests.cjs --task schema-codecs
 node wasm/scripts/run-wasm-tests.cjs --list
 ```
 
+`wasm/test/suite/registry.cjs` owns the exact task and profile IDs. Agent
+instructions, this guide, release acceptance commands and maintenance-policy
+commands are checked against it by `npm run maintainer:check`. Use explicit
+runner commands for named selections so stale references are detectable.
+
 The event mechanism has focused provider-neutral tasks, plus one project-level
 workflow task included in the `cli` and `release` profiles:
 
@@ -232,7 +237,7 @@ node wasm/scripts/run-wasm-tests.cjs --task deployment-candidates --no-report
 
 ## JWT and crypto proof seals
 
-The `1.0.0-beta.1` JWT/crypto packages build on the focused crypto seal,
+The `1.0.0-beta.3` JWT/crypto packages build on the focused crypto seal,
 which replays the
 configuration, JavaScript runtime, Native guest-source, shared cross-target
 corpus, and real Fastly Compute proofs. First record the one phase-boundary
@@ -279,6 +284,47 @@ anything.
 
 The runner writes `wasm/.test-results/last-run.json` atomically after every task and stores one log per task. When a task fails, task-owned `*.log` files such as npm debug logs are copied into that run's durable diagnostics directory before the temporary root is removed. On timeout it captures a Node diagnostic report, terminates the entire task process group, and reports any surviving descendants. The directory is ephemeral and should contain only evidence produced from the current tree.
 
+Before reporting a run as passed, verify process exit, terminal report status,
+the requested/selected task set, completed task count and each task result. A
+zero exit with a missing or incomplete expected report is unresolved. When
+`--no-report` is used, retain the terminal task results and aggregate summary;
+exit status alone does not establish coverage.
+
+Record the source revision and working-tree state alongside the toolchain,
+command and artifact identities. The runner's Git commit identity alone does not
+identify uncommitted changes. Label those runs as development evidence and retain
+the tested diff or tree digest. Preserve failures when retrying, identify why the
+rerun was bounded, and report the retry separately. Focused, split or resumed
+development runs do not substitute for the complete clean-candidate release
+replay or permit combining reports from different source trees.
+
+On an interruption or handoff, record the branch, base/head, uncommitted work,
+report/artifact paths, completed and running checks, blockers and the next action.
+A task handoff must distinguish implemented, validated, pushed and merged work.
+
+## Provider evidence boundaries
+
+| Evidence | Establishes | Does not establish |
+| --- | --- | --- |
+| Injected host or ABI fixture | Behavior under the modeled host outcomes | Real engine or deployed service behavior |
+| Fastly CLI/Viceroy execution | The identified artifact ran on the identified local engine | Deployed Fastly behavior |
+| Standalone live SDK probe | The tested service cases through that probe | Pulse package acceptance or untested concurrent/cross-location behavior |
+| Deployed Pulse acceptance | The identified Pulse artifact passed the bounded deployed corpus | Exhaustive consistency or guarantees outside that corpus |
+
+Report tool versions, artifact identity, execution/deployment identity where
+applicable, corpus scope and pass/fail/inconclusive status separately. Executing
+a real engine is not itself a passing semantic result. A caller-supplied Wasm
+hash is not deployed binary attestation.
+
+For conditional KV, the Fastly JavaScript SDK is incomplete capability mapping,
+not semantic canon or an acceptance gate for other targets. Keep provider docs,
+wire observations and executable behavior distinguishable when they disagree.
+Retain the discrepancy and the unchanged Pulse assertion; do not compensate with
+hidden retries, non-atomic prechecks or weaker expected results. Substituting one
+kind of evidence for a required gate needs an explicit human-directed acceptance
+policy change. See [conditional KV acceptance](./release-acceptance.md#conditional-kv-acceptance)
+for the currently unresolved gates.
+
 ## Redundancy policy
 
 - Add a task once to `wasm/test/suite/registry.cjs`; do not add a package script per test.

package/docs/packages/README.md

@@ -2,28 +2,29 @@
 
 <!-- Generated by wasm/scripts/sync-reference-docs.cjs. Edit the source catalog, not this file. -->
 
-Pulse 1.0.0-beta.1 publishes one synchronized 18-package release set. Publication does not make every package an application-author SDK: the support tier and listed entry points define the release promise.
-
-| Package | Support tier | Install directly | Release promise |
-|---|---|---:|---|
-| [`@pulse-compute/runtime`](./runtime.md) | Canonical application surface | Yes | Supported application authoring and execution contract. |
-| [`@pulse-compute/pulse`](./pulse.md) | Canonical application surface | Yes | Supported conventional application, project-configuration, and schema-authoring contract. |
-| [`@pulse-compute/cli`](./cli.md) | Canonical application surface | Yes | Supported Beta workflow and project-configuration contract. |
-| [`@pulse-compute/provider-fastly`](./provider-fastly.md) | Supported provider/extension surface | Yes | The listed entry points are supported for the Beta; all other exported subpaths are implementation-only. |
-| [`@pulse-compute/grip`](./grip.md) | Supported provider/extension surface | Yes | The package root has bounded JavaScript and Native HTTP-framing realization plus configured Node/Fastly broadcast; /pulsewasm remains compatibility-only. |
-| [`@pulse-compute/assets`](./assets.md) | Supported provider/extension surface | Yes | The package root is the supported JavaScript API and canonical Native authoring surface; /pulsewasm remains a compatibility subpath, while manifest/compiler subpaths are toolchain integration. |
-| [`@pulse-compute/crypto`](./crypto.md) | Supported provider/extension surface | Yes | The package root is the supported bounded verification contract; realization and Native integration subpaths remain toolchain-only. |
-| [`@pulse-compute/jwt`](./jwt.md) | Supported provider/extension surface | Yes | The package root is the supported provider-neutral verification contract; provider and compiler integration subpaths are not application APIs. |
-| [`@pulse-compute/entities`](./entities.md) | Supported provider/extension surface | Yes | The package root and first-party JSON-RPC adapter are supported Beta contracts; compiler integration subpaths remain toolchain-only. |
-| [`@pulse-compute/wasm-build-support`](./implementation-packages.md) | Implementation/transitive surface | No | Internal release-set interface; exported modules may change with compiler implementation needs. |
-| [`@pulse-compute/wasm-compiler`](./implementation-packages.md) | Implementation/transitive surface | No | Internal compiler interface; no application-author compatibility guarantee. |
-| [`@pulse-compute/wasm-guest-link`](./implementation-packages.md) | Implementation/transitive surface | No | Internal first-party prebuilt guest-link interface synchronized with the compiler; no application-author or third-party guest compatibility guarantee. |
-| [`@pulse-compute/wasm-contracts`](./implementation-packages.md) | Implementation/transitive surface | No | The provider toolchain contract is versioned and supported for the Beta; other protocol and proof interfaces remain internal. |
-| [`@pulse-compute/wasm-host-runtime`](./implementation-packages.md) | Implementation/transitive surface | No | Internal compiler/runtime interface synchronized with this release set. |
-| [`@pulse-compute/wasm-library-kit`](./implementation-packages.md) | Implementation/transitive surface | No | Internal package-lowering interface synchronized with this release set. |
-| [`@pulse-compute/provider-node`](./implementation-packages.md) | Implementation/transitive surface | No | The listed built-in toolchain entry is synchronized with the Beta bootstrap contract; other canonical Node provider interfaces remain internal. |
-| [`@pulse-compute/wasm-runtime-core-as`](./implementation-packages.md) | Implementation/transitive surface | No | Internal code-generation interface synchronized with this release set. |
-| [`@pulse-compute/wasm-schema-json`](./implementation-packages.md) | Implementation/transitive surface | No | Internal schema compiler interface synchronized with this release set. |
+Pulse 1.0.0-beta.3 publishes one synchronized 19-package release set. Publication does not make every package an application-author SDK: the support tier and listed entry points define the release promise.
+
+| Package on npm | Guide | Support tier | Install directly | Release promise |
+|---|---|---|---:|---|
+| [`@pulse-compute/runtime`](https://www.npmjs.com/package/@pulse-compute/runtime) | [Guide](./runtime.md) | Canonical application surface | Yes | Supported application authoring and execution contract. |
+| [`@pulse-compute/pulse`](https://www.npmjs.com/package/@pulse-compute/pulse) | [Guide](./pulse.md) | Canonical application surface | Yes | Supported conventional application, project-configuration, and schema-authoring contract. |
+| [`@pulse-compute/cli`](https://www.npmjs.com/package/@pulse-compute/cli) | [Guide](./cli.md) | Canonical application surface | Yes | Supported Beta workflow and project-configuration contract. |
+| [`@pulse-compute/provider-fastly`](https://www.npmjs.com/package/@pulse-compute/provider-fastly) | [Guide](./provider-fastly.md) | Supported provider/extension surface | Yes | The listed entry points are supported for the Beta; all other exported subpaths are implementation-only. |
+| [`@pulse-compute/grip`](https://www.npmjs.com/package/@pulse-compute/grip) | [Guide](./grip.md) | Supported provider/extension surface | Yes | The package root has bounded JavaScript and Native HTTP-framing realization plus configured Node/Fastly broadcast; /pulsewasm remains compatibility-only. |
+| [`@pulse-compute/assets`](https://www.npmjs.com/package/@pulse-compute/assets) | [Guide](./assets.md) | Supported provider/extension surface | Yes | The package root is the supported JavaScript API and canonical Native authoring surface; /pulsewasm remains a compatibility subpath, while manifest/compiler subpaths are toolchain integration. |
+| [`@pulse-compute/crypto`](https://www.npmjs.com/package/@pulse-compute/crypto) | [Guide](./crypto.md) | Supported provider/extension surface | Yes | The package root is the supported bounded verification contract; realization and Native integration subpaths remain toolchain-only. |
+| [`@pulse-compute/jwt`](https://www.npmjs.com/package/@pulse-compute/jwt) | [Guide](./jwt.md) | Supported provider/extension surface | Yes | The package root is the supported provider-neutral verification contract; provider and compiler integration subpaths are not application APIs. |
+| [`@pulse-compute/entities`](https://www.npmjs.com/package/@pulse-compute/entities) | [Guide](./entities.md) | Supported provider/extension surface | Yes | The package root and first-party JSON-RPC adapter are supported Beta contracts; compiler integration subpaths remain toolchain-only. |
+| [`@pulse-compute/s3`](https://www.npmjs.com/package/@pulse-compute/s3) | [Guide](./s3.md) | Supported provider/extension surface | Yes | The package root supports head, getText and putText on Node Native, Node JavaScript and Fastly Native. Fastly JavaScript is ineligible. Provider and lowering subpaths are toolchain-only; live origin acceptance is separate. |
+| [`@pulse-compute/wasm-build-support`](https://www.npmjs.com/package/@pulse-compute/wasm-build-support) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal release-set interface; exported modules may change with compiler implementation needs. |
+| [`@pulse-compute/wasm-compiler`](https://www.npmjs.com/package/@pulse-compute/wasm-compiler) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal compiler interface; no application-author compatibility guarantee. |
+| [`@pulse-compute/wasm-guest-link`](https://www.npmjs.com/package/@pulse-compute/wasm-guest-link) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal first-party prebuilt guest-link interface synchronized with the compiler; no application-author or third-party guest compatibility guarantee. |
+| [`@pulse-compute/wasm-contracts`](https://www.npmjs.com/package/@pulse-compute/wasm-contracts) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | The provider toolchain contract is versioned and supported for the Beta; other protocol and proof interfaces remain internal. |
+| [`@pulse-compute/wasm-host-runtime`](https://www.npmjs.com/package/@pulse-compute/wasm-host-runtime) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal compiler/runtime interface synchronized with this release set. |
+| [`@pulse-compute/wasm-library-kit`](https://www.npmjs.com/package/@pulse-compute/wasm-library-kit) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal package-lowering interface synchronized with this release set. |
+| [`@pulse-compute/provider-node`](https://www.npmjs.com/package/@pulse-compute/provider-node) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | The listed built-in toolchain entry is synchronized with the Beta bootstrap contract; other canonical Node provider interfaces remain internal. |
+| [`@pulse-compute/wasm-runtime-core-as`](https://www.npmjs.com/package/@pulse-compute/wasm-runtime-core-as) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal code-generation interface synchronized with this release set. |
+| [`@pulse-compute/wasm-schema-json`](https://www.npmjs.com/package/@pulse-compute/wasm-schema-json) | [Guide](./implementation-packages.md) | Implementation/transitive surface | No | Internal schema compiler interface synchronized with this release set. |
 
 ## Tier definitions
 
@@ -43,9 +44,9 @@ Installable as part of the synchronized release set, without an application-auth
 
 Every packed README begins with a generated status block covering audience, direct-install guidance, supported entry points, and stability. An export that is not listed in that block is not automatically a supported application-author entry point.
 
-## Extension and provider boundary in 1.0.0-beta.1
+## Extension and provider boundary in 1.0.0-beta.3
 
-Pulse supports the documented package-owned assets and GRIP facades and the documented Fastly provider entry points. Their implementation demonstrates the internal contract, but `1.0.0-beta.1` does **not** expose a general third-party plugin registry:
+Pulse supports the documented package-owned assets and GRIP facades and the documented Fastly provider entry points. Their implementation demonstrates the internal contract, but `1.0.0-beta.3` does **not** expose a general third-party plugin registry:
 
 - lowerer manifests are accepted only from trusted first-party release packages;
 - arbitrary external lowerer discovery and execution are not supported;

package/docs/packages/assets.md

@@ -7,7 +7,7 @@ The package root exposes the complete JavaScript asset implementation—local fi
 ## Install
 
 ```bash
-npm install @pulse-compute/assets@1.0.0-beta.1
+npm install @pulse-compute/assets@1.0.0-beta.3
 ```
 
 ## Portable lookup surface

package/docs/packages/crypto.md

@@ -4,7 +4,7 @@
 verification for Pulse applications and first-party capability packages.
 
 ```bash
-npm install @pulse-compute/crypto@1.0.0-beta.1
+npm install @pulse-compute/crypto@1.0.0-beta.3
 ```
 
 ## Verification surface
@@ -58,6 +58,13 @@ realization. Target probing and automatic fallback are prohibited.
 
 ## Boundary
 
+Native capability packages can also select `SHA-256` and `HMAC-SHA256` for
+internal byte output. Their exact `guest-source:pulse-hmac-as` realization uses
+32-byte output, at most 32 KiB of data and 8 KiB of HMAC key material. Crypto owns
+a reusable, wiped host staging frame. These operations are separate from JWT's
+32-byte minimum HMAC verification key; the application verification API retains
+its existing limits. JavaScript byte-output realization is not implemented yet.
+
 The package root is the supported application contract. Native integration,
 guest provenance, and realization records are toolchain-owned surfaces. JWT
 owns compact-JWS parsing, key selection, and claims semantics; this package

package/docs/packages/entities.md

@@ -4,7 +4,7 @@
 operations through the first-party JSON-RPC adapter.
 
 ```bash
-npm install @pulse-compute/entities@1.0.0-beta.1
+npm install @pulse-compute/entities@1.0.0-beta.3
 ```
 
 ## Declare an entity router