diff --git a/README.md b/README.md
index 79f931211..f8df786b6 100644
--- a/README.md
+++ b/README.md
@@ -727,19 +727,24 @@ gate-keeper that reads each change before it lands, are jobs your harness gives
    git worktree add -b upg100/work  ../dx-maps-upg100  origin/main
    cd ../dx-maps-regions && bun install --frozen-lockfile
    ```
-4. **One preview server per agent, each on its own port:**
+4. **One preview server per agent on your own machine, each on its own port** (in the cloud, the one
+   pilot server below takes this role):
    ```bash
    bun x vite --port 5301 --strictPort    # the next agent uses 5302, and so on
    ```
-5. **Land on the pilot one at a time, through a lock.** Inside the lock, merge the pilot branch into
-   your PR branch, run the checks, and push only if nothing fails (`gates:pre` exits non-zero when a
-   check fails, so the push never runs then):
+5. **Land on the pilot one at a time, through a lock.** Inside the lock, merge your PR branch into a
+   throwaway copy of the pilot branch, run the checks, and push that merge only if nothing fails
+   (`gates:pre` exits non-zero when a check fails, so the push never runs then). Your PR branch itself
+   stays one feature on the landing branch; only the pilot gets the merge:
    ```bash
    flock /tmp/dx-maps-development.lock sh -c '
-     git fetch origin && git merge --no-edit origin/development &&
-     bun run gates:pre && git push origin HEAD:development'
+     git fetch origin && git switch --detach origin/development &&
+     git merge --no-edit regions/work &&
+     bun run gates:pre && git push origin HEAD:development
+     git switch regions/work'
    ```
-   `flock` guards one machine. Agents on several machines need a shared lock, such as one your
+   If the merge stops on a conflict, run `git merge --abort`, fix the clash on your PR branch and land
+   again. `flock` guards one machine. Agents on several machines need a shared lock, such as one your
    harness provides.
 6. **One agent owns the full build**; the others build only their own plugin:
    ```bash
@@ -762,7 +767,8 @@ gate-keeper that reads each change before it lands, are jobs your harness gives
 Keep the repository on a forge you host yourself: a swarm pushes often, and on a public host one wrong
 push publishes work you did not mean to share. Give each app two servers: a **pilot server** that
 follows the pilot branch with hot reload, and a **landing server** that rebuilds from the landing
-branch. The cloud container in `deployment/cloud/` runs both today. One pilot server per app, rather
+branch. The cloud container in `deployment/cloud/` runs both today (set its `BRANCH` to `development`
+for the pilot server; the default is `main`). One pilot server per app, rather
 than one per pull request, keeps the memory the same however many pull requests are open. Each
 developer can still build on their own machine with the Plugin Studio and push their branch.