---
title: Shared baseline, workers and integration
---

# 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](./package.json) and [package-lock.json](./package-lock.json) identify the source cohort. Each copied starter installs exact manifest pins and keeps its own lockfile. [customer.mjs](./customer.mjs) uses Stripe's real SDK. [receipt.mjs](./receipt.mjs) shows the current World, configured remotes, tracked origin, unpushed work and each changeset's actual destination.

## Make the baseline

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

```console
$ 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:

```console
$ ./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 workers

Create three more copies in the same parent folder:

```console
$ 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:

```console
$ 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 change

```console
$ 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 result

```console
$ 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 deliberately

This exercise integrates changesets. [Isolated CI workers](../ci-workers/README.md) 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](../../docs/guides/team-onboarding.md) owns platform sign-in and scoped access. [Share a World](../../docs/guides/share-a-world.md) 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](./public-files.json) identify the starter. This page is a source walkthrough, not evidence that a multi-machine or hosted integration has run.