live or in_review.
What the command does, in order
1
Asks
Without
--notes it asks what changed in this release, then names the extension and waits
for a yes before anything is sent. --notes and --yes answer both, which is what a
script wants.2
Builds
Runs your
build script. A failing build publishes nothing, and a missing dist/ stops
the command before the zip.3
Checks
Runs
doctor without rebuilding, and without your
typecheck, lint, tests or accessibility pass — the build has just run. Any failure stops
the publish and prints the checklist. --skip-doctor skips this; the second output line
says which happened.4
Packs
tappify.extension.json, package.json, dist/, your icon, your screenshots, every
schema a $ref names, and any knowledge or skill markdown. At most 5 MB.5
Uploads and validates
Tappify re-runs the manifest and bundle checks against the zip itself, then asks
<base url>/tappify/health for a 200 within three seconds on every base url your
manifest declares. A redirect counts as a failure.6
Decides
Live, or in review. The rule is on Releases.
dev --live session
already did, and says so. An id is immutable after that, so a later publish whose manifest
carries a different id is refused rather than creating a second extension. Every other field
is yours to change: a new name, description or category reaches the store card with the
release that goes live.
What comes back
An
unlisted extension comes back live: its release is opened for review and approved by
the automated checks in the same request.
Review and what gets checked
Every check, what it looks at, and how to fix it.
Releases, rolling updates, and release notes
When a publish goes straight to live.