Ship

1. Confirm the branch and diff exactly match the reviewed scope. Then run node scripts/ship-rebase.mjs --pr <number> --if-needed --push, also for one pull request. Do not rebase by hand. The required checks of main do not require an up-to-date branch, so a rebase is only necessary when a squash merge is not safe as it is. With --if-needed, the script rebases only when the merge into main conflicts, when the branch changes CHANGELOG.md, when the branch and main both change a generated file, or when the merge loses a version bump of the branch. Otherwise it prints the merge command for the current head, and no new CI run is necessary. The checks of the pull request then ran against an older main. A change on main that breaks the branch without a text conflict shows only in steps 6 and 7. After a rebase, the script compares the result with a merge and checks each version constant. A failed manual rebase --continue leaves commits on a detached HEAD. For a stacked branch after a squash merge of its parent, add --upstream (see "Serial merge of many pull requests").

2. Re-run the required checks from docs/development/quality-gates.md.

3. Verify that public contracts and generated files are pushed. Merge each companion change into the default branch of its repository (for example fallow-docs main). A pushed feature branch is not enough: the release then must merge it. When the merged change touches npm/fallow/skills, run node scripts/sync-skills-companion.mjs --pin <merge commit> right after the merge. Publish its commit with the commands that it prints. ship-wait-checks.mjs prints this step for such a change.

4. Create signed conventional commits only.

5. Merge with pinned auto-merge. Do not wait for the checks in the foreground:

   gh pr merge <number> --auto --squash --match-head-commit <reviewed sha> --subject "<type>: <summary> (#<number>)"