Shared baseline, workers and integration

Give two workers the same Stripe baseline, let them change different existing customers in isolated Worlds, then send their changesets to a separate integration World. This local example needs Node 22.6+, npm and registry access during preparation. It requires no platform account, shared host or real vendor key.

package.json and package-lock.json identify the source cohort. Each copied starter installs exact manifest pins and keeps its own lockfile. customer.mjs uses Stripe's real SDK. receipt.mjs shows the current World, configured remotes, tracked origin, unpushed work and each changeset's actual destination.

Make the baselineCopy Anchor Link

Use an empty parent folder. Create the baseline starter there:

$ npx @volter/world@3.0.158 example integration-branches --dir baseline
$ cd baseline
$ npm install
$ ./node_modules/.bin/volter world init --name baseline --twins stripe

Review the selected vendor, then create Ada and Grace through the SDK:

$ ./node_modules/.bin/volter world up
$ ./node_modules/.bin/volter world clock set 2026-01-15T12:00:00Z
$ ./node_modules/.bin/volter world run -- node customer.mjs create Ada
$ ./node_modules/.bin/volter world run -- node customer.mjs create Grace
$ ./node_modules/.bin/volter world run -- node customer.mjs read
$ ./node_modules/.bin/volter world down
$ cd ..

The stopped baseline retains its history and can supply local path remotes. Default synthetic records may also be present; identify this example's customers by their names and @example.invalid emails rather than counting all records.

Prepare integration and two workersCopy Anchor Link

Create three more copies in the same parent folder:

$ npx @volter/world@3.0.158 example integration-branches --dir integration
$ npx @volter/world@3.0.158 example integration-branches --dir worker-a
$ npx @volter/world@3.0.158 example integration-branches --dir worker-b

In integration, then worker-a, then worker-b, install dependencies and initialize with the folder's name. Before a first boot or app write, link and pull the baseline:

$ cd integration
$ npm install
$ ./node_modules/.bin/volter world init --name integration --twins stripe
$ ./node_modules/.bin/volter remote add origin ../baseline
$ ./node_modules/.bin/volter world pull
$ ./node_modules/.bin/volter world clock set 2026-01-15T12:00:00Z
$ cd ..

Repeat that block in each worker, replacing both occurrences of integration with its folder name. Pull boots a fresh World without a competing local seed and brings in the baseline history. Each vendor has its own log positions; a combined timestamp timeline is not a cross-vendor causal sequence.

Deliver worker A's changeCopy Anchor Link

$ cd worker-a
$ ./node_modules/.bin/volter world run -- node customer.mjs rename Ada Ada-worker-A
$ ./node_modules/.bin/volter world changeset worker-a-change -m "Worker A renames Ada"
$ ./node_modules/.bin/volter remote add integration ../integration
$ ./node_modules/.bin/volter world push worker-a-change --remote integration
$ ./node_modules/.bin/volter world run -- node receipt.mjs
$ ./node_modules/.bin/volter world down
$ cd ..

The delivery receipt names integration. The worker's tracked origin still names baseline; delivery to another remote does not advance that cursor or mark the change as sent to baseline. The positional argument after push is a changeset name. The remote is always selected by --remote; omitting it selects origin.

Deliver worker B's change and read the resultCopy Anchor Link

$ cd worker-b
$ ./node_modules/.bin/volter world run -- node customer.mjs rename Grace Grace-worker-B
$ ./node_modules/.bin/volter world changeset worker-b-change -m "Worker B renames Grace"
$ ./node_modules/.bin/volter remote add integration ../integration
$ ./node_modules/.bin/volter world push worker-b-change --remote integration
$ ./node_modules/.bin/volter world down
$ cd ../integration
$ ./node_modules/.bin/volter world run -- node customer.mjs read
$ ./node_modules/.bin/volter world run -- node receipt.mjs
$ ./node_modules/.bin/volter world down
$ cd ../baseline
$ ./node_modules/.bin/volter world up
$ ./node_modules/.bin/volter world run -- node customer.mjs read
$ ./node_modules/.bin/volter world down

Integration holds the two renamed customers. Baseline still holds Ada and Grace. This example deliberately changes distinct records. A named delivery binds to the destination head it reads and refuses a concurrent move; it does not provide an automatic semantic merge for two workers changing the same field. Read the integration diff and coordinate overlapping work before accepting it.

Choose the shared workflow deliberatelyCopy Anchor Link

This exercise integrates changesets. Isolated CI workers instead run independent disposable jobs and collect outcomes; those jobs do not push to a common mutable World. For a sequential shared-origin workflow, pull before writing and again when origin moves: only still-local entries should participate in rebase conflicts, including vendor-maintained counters.

For two people or machines, join a team's World owns platform sign-in and scoped access. Share a World owns a locally served endpoint, its tokens and the order in which a server and consumers start. Stop registered app consumers before stopping each World. Preserve a parent while children reference its history.

Source files identify the starter. This page is a source walkthrough, not evidence that a multi-machine or hosted integration has run.