--live installs the build you are serving on your sandbox project and prints the host URL, so
you see your widget where an owner would see it: the real page, the real date range, real data
for that project.
1
A dev install is created
On your vendor account’s sandbox project, with your local remote entry recorded against it
and every scope your manifest asks for granted. The host loads that URL for that install
only — no other project can. The first run also registers the extension with the Tap Store
under your vendor. An install an owner made on that project is left alone: the session stops
rather than rewrite its scopes.
2
Your working manifest becomes the draft release
The session sends the manifest you are editing, so a contribution you have not published
still renders. It overwrites the draft release only; a live or in-review release is never
touched. While a release is in review the CLI says so and the session runs against the
published contributions instead.
3
You edit, it reloads
Component changes reload. Manifest changes rewrite the types, and the contribution appears
or moves on the next reload.
4
Ctrl+C ends the session
The dev install is paused and its local URL cleared, so nothing points at a dead port
afterwards. A session you walk away from expires after twelve hours.
Your server during a live preview
This is where a procedure is first answered: the portal preview registers no server handler, so nothing there calls one. Tappify relays procedures, tools and actions from its own servers, and those cannot reachhttp://localhost. Give the session a URL Tappify can call:
--server, the relay uses your manifest’s server.sandboxBaseUrl, falling back to
server.baseUrl. The starter ships a placeholder there, so a first run without the flag shows
the widget’s error card rather than a number. An extension with no server does not need the flag.