docs(playbook): document how the sdks release actually publishes

[codyborn]

Documents how the sdks release actually publishes, so Phase 2 can't silently stall.

Why

Phase 2 said "Publish a standard @uniswap/uniswapx-sdk release" as a single bullet, which reads as one merge. It isn't necessarily.

The monorepo releases via changesets (.github/workflows/semantic-release.yaml). On every push to main the workflow picks its mode by asking one question — are there any .changeset/*.md files left?

changesets pending	what happens
yes	creates/updates the chore(sdks): Version Packages PR. Nothing is published.
no	runs changeset publish — pushes every package whose package.json version isn't already on npm

So publishing needs both conditions in the same push to main: no pending changesets, and a package.json version npm doesn't have yet.

Two legitimate routes

• Bot route (default) — your PR carries only a changeset. Merging it publishes nothing; merging the follow-up Version Packages PR is what publishes. Two merges, and the second is easy to forget because your PR is already green.
• Self-contained route — your PR runs changeset version itself, so it carries the bumps, CHANGELOGs, and the changeset deletions. One merge, publishes directly.

And the ways to do half of either

• Bumping package.json while leaving your changeset in place publishes nothing — the workflow stays in mode 1.
• Taking the self-contained route while a Version Packages PR is open strands it: same bumps and CHANGELOG lines, so it goes conflicted, and merging it later can regress a package whose version has since moved on.
• The self-contained route consumes every pending changeset, not just yours — so it publishes other people's packages too. Title it as the release it is; a release disguised as a one-line fix is a real review hazard.

Also in this PR

• Phase 2's exit criterion is now npm view @uniswap/uniswapx-sdk version returning the new version, rather than "the PR merged".
• The state diagram names the publishing step instead of a generic "publish a release".
• New Correction G — why this blocks Phase 3 rather than merely delaying it. getPermit2, getReactor, and UniswapXOrderQuoter's constructor all throw MissingConfiguration for an unmapped chain, so wiring a chain into a service before the SDK publishes turns "chain unsupported" into "chain accepted, then 500s". Hence the rule it records: never split the chain-enum addition and the SDK bump across two PRs, because adding a chain to a request validator makes those requests reachable the moment it deploys.

Not included

§3.4 is separately stale for parameterization-api and will get its own PR: lib/config/chains.ts no longer exists (so "Correction C" is obsolete — lib/util/chains.ts is now the documented single source of truth), V3_BLOCK_BUFFER and getBlockTimeSecs no longer exist (block time moved to sdk-core's secondsToBlocks), and per-chain RPC_<chainId> env vars were replaced by a single RPC_PREFIX_URL.

🤖 Generated with Claude Code