Remote execution

Run from the standalone worldseq package root. The remote machine needs its own qualification results: moving from Linux ARM64 to Linux x86_64 changes the execution identity. Preserve the registered task IDs, instance IDs, seeds and budgets through the operator’s reviewed revision workflow; existing certificates do not become valid on the new platform by copying them.

Transfer a source snapshot

After the source and toolchain are frozen, build a new standalone release directory:

bun run release:package --out /tmp/worldseq-release
shasum -a 256 /tmp/worldseq-release/source.tar.gz
tar -tzf /tmp/worldseq-release/source.tar.gz

Choose a fresh output path for another build. Transfer source.tar.gz and its handoff.json through the operator’s authenticated channel, compare the archive’s SHA-256, then extract it into a new directory and enter source. The archive contains the application and its locked dependencies without relying on the surrounding repository or a home directory.

Review the archive listing before transfer. Keep private instances, seed stores, database dumps, environment files and SSH credentials outside the source archive. Transfer any authorized private instance store separately into a restricted operator directory.

The packaging copier also excludes .runtime, .git, .env*, installations, caches and previous dist output, and rejects symbolic links. Its exclusions do not replace review of newly tracked files. Keep runtime/private stores outside src, data, tests and other shipped input directories.

Native toolchain and isolated services

Use actual Bun 1.3.14, Node 24.13.0 with npm/npx, uv, Git and the standard Linux CA certificates, C++ runtime and xz tools. The operator bootstrap is packaging/bootstrap-ubuntu.sh --qualification --postgres; inspect its --plan first and source its generated tool environment explicitly. Run Bun directly; an npm wrapper around Bun can change nested npm command resolution. Install the frozen dependencies:

bun install --frozen-lockfile --ignore-scripts
bun run sdk:install

The Python SDK uses its frozen uv lock, strict mypy and Ruff checks. Its test matrix installs Python 3.11–3.14. Installed TypeScript consumers also exercise Node 22.22.0, Node 24.13.0 and Bun. Allow the corresponding package/runtime downloads; caches can be warmed, but must not replace locked installation or clean installed-package tests. Keep caches separate from immutable source and public archives.

Provide WORLDSEQ_TEST_DATABASE_URL for a disposable PostgreSQL test database and WORLDSEQ_DATABASE_URL where the ordinary CLI needs its configured database. Use the operator’s protected environment rather than putting credentials in commands, archives or logs. Tests may create and clean their own database records; do not point them at a user’s production database.

For a host with a working Docker daemon, the existing image preparation retains the source and all pinned publisher image references:

bun scripts/release-linux.ts --out /qualification/new-build-context
docker build --platform linux/amd64 -t worldseq-qualification:SELECTED_COMMIT /qualification/new-build-context

Choose the host’s native platform (linux/amd64 for x86_64 or linux/arm64 for ARM64). The qualification entrypoint checks frozen source, release inputs and declared runtime images. Record the built image ID and actual runtime identity. The OCI pins are in packaging/qualification.ts; their publisher indexes contain both Linux amd64 and arm64 variants. Do not substitute floating image tags. A native installation can run the same gate commands without an image, with its actual runtime recorded in the release manifest.

Both the Harbor gate and the standalone gate need an accessible real Docker daemon. Harbor runs both container test files; standalone also starts a runtime image. A container without permission to run Docker must leave those gates pending until an operator provides a suitable daemon. A remote Docker daemon is not automatically equivalent: its execution architecture, image availability, mount semantics and network access must be checked before claiming a matching-runtime result. The Harbor adapter copies inputs/logs and rejects host bind mounts, which permits investigation of a remote daemon without sharing source directories. For an ARM64 daemon serving an x86_64 qualification, explicitly selecting DOCKER_DEFAULT_PLATFORM=linux/amd64 is a prerequisite, not proof of compatibility; run both tests and verify their runtime identity. Do not disable either check to finish qualification.

Run complete registered gates

Reserve an exclusive qualification window before starting the runner. It runs one registered gate at a time; some whole-suite gates create their own concurrent worlds. Do not run a certification campaign or another release runner against the same mutable installation while these gates execute. Increasing campaign parallelism is a separate operator resource decision, not a reason to narrow test arguments.

Create a new release directory after the source and toolchain are settled:

bun src/cli.ts release init --out /qualification/release
bun scripts/remote-release.ts --release /qualification/release --phase host

The host phase runs the 13 gates that do not require Docker, including the entire bun run check, SDK matrices, mutation checks, submissions and dashboard tests. It explicitly reports releasePassed: false while other gates are missing. When Docker is available, run:

bun scripts/remote-release.ts --release /qualification/release --phase qualify

This covers all 15 qualification gates and reuses only passed receipts whose frozen binding and retained artifact bytes still verify. It runs the unchanged real Harbor command:

WORLDSEQ_HARBOR_DOCKER_TEST=1 bun test tests/harbor-container.test.ts tests/harbor-certified-container.test.ts

The command above documents the gate payload; the runner invokes it through runReleaseGate, which retains the authoritative attempt receipt. The runner builds and checks the normal dist/release packages before standalone smoke. If an old or failed package directory exists, retain it under a different archival location and use a clean checkout/output; the runner never overwrites an existing handoff with different bytes.

A failed gate stops the phase and preserves its attempt. Fixes that change shipped inputs require a new frozen manifest and fresh qualification. Do not edit a receipt to mark it passed. Resuming an unchanged run rechecks receipts; dependencies remain mandatory.

After the separately coordinated campaign has completed all required instances under the same native execution, run:

bun scripts/remote-release.ts --release /qualification/release --phase finalize --private-directory /operator/certified-instances --workers 8 --heavy-workers 4
bun src/cli.ts release check /qualification/release

The example bounds certificate replay to eight concurrent instances, at most four of them long-horizon. Select limits from measured memory and CPU capacity; do not overlap this replay with the preparation campaign. Finalization invokes the registered certificate check and then the handoff check. It does not create instances, resample seeds, issue solver decisions or promote historical certificates. All 17 registered gates must verify before the release passes. Keep the private directory operator-only; public packages and progress summaries must not contain seed values or witness answers.

Retain and deliver

Keep /qualification/release/manifest.json, every gate’s receipt.json, and its referenced attempt logs/artifacts. dist/release/handoff.json binds the complete package contents and SHA-256 of:

• dist/release/source.tar.gz: standalone source with its lockfiles;
• dist/release/runtime.tar.gz: runtime source and prebuilt dashboard;
• dist/release/sdks.tar.gz: TypeScript package plus Python wheel and source distribution.

Copy these public artifacts and the handoff manifest to a fresh versioned delivery directory. Keep earlier archives unchanged. The packages can be built before certificate completion, but package existence and a partial qualification phase do not establish release acceptance. See standalone installation and private instances for the consumer and operator boundaries.