Release upgrade safety

Every hazard here is one an installed user pays for and you cannot take back. openbot.db is migrated in place with no backup, two dozen files under userData are rewritten by whichever build opens them last, a released Team API adapter is spoken by peers you will never update, and the account Worker's D1 migrations are applied before the Worker that needs them. A build that ships past one of these does not fail on your machine; it fails on someone else's, once, permanently.

Audit the diff since the last released tag against the eight gates below, then report a verdict. This runs before docs/RELEASING.md, which stays authoritative for the publish itself.

What this skill does and does not do

• It audits. It does not run bun run release:patch, commit a version bump, or push a tag unless you are separately asked to.
• It never runs bun run check, check:desktop, test, or build-storybook, each takes minutes, CI owns them, and the desktop suite flakes under load, so a red result would tell you nothing. Run the narrowest test file named by a gate and lint the changed files. Do not run the repo-wide bun run lint or bun run typecheck: the pre-commit hook and CI run them.
• If gate C or D fired, confirm the mobile typecheck passed. apps/mobile depends on @openbot/contracts, which is exactly what those two gates change. The pre-commit hook runs typecheck:mobile when a commit stages a file that mobile can see, such as one in packages/contracts, and the CI Surfaces job runs it on each pull request.
• It never runs bun run dev:seed or dev:reset, both destroy the developer's own profile, and never pkill -f, which kills other sessions' work mid-write.

Step 1, establish the range, then account for every file in it

git status --porcelain
git tag --list 'v*' --sort=-v:refname | head -1
git diff --name-status <tag>..HEAD