Go live

Going live is two separate things, and confusing them is the usual source of “where is my app”. Deploying puts it to work for you and your workspace. Publishing lists it in the marketplace for other people. You can do the first and never do the second.

Deploy, then maybe publish

draft→gates→deployed→in your workspace

deployed→publish→review (first time)→in the marketplace

These two tracks are independent. An app can be deployed and running for your team forever without ever being submitted anywhere. Most internal apps should be.

Deploying

shell

claritty deploy

This runs the pre-flight gates, verifies the app, ships it, and starts it. It is hosted on its own, with a database, and it is reachable by you and your workspace. Building through the plugin or the app generator does this for you, with the same gates.

Poll claritty status afterwards to see where it got to. Use claritty deploy --dry-run first if you want the gates to tell you what is wrong before anything ships.

What the gates check

Check	What fails it
The manifest	Something declared in `intelligence.yaml` does not exist, or a workflow references a tool no agent may call.
Tenancy	A query that can return another user’s rows. Every row belongs to a user and every query has to say so.
Widgets	A widget that is not one of the three sizes, text under 12px, or a tap target under 44px.
It builds and runs	The frontend does not build, or the backend does not boot.

Tenancy is the check that most often fails late and hurts most. Every query must filter by the current user. A generated app does this already; code you add by hand is where it slips.

Publishing to the marketplace

shell

claritty publish

1
You publish. The app has to be validated first. Publishing takes an immutable snapshot, so what installers get does not change under them when you keep working.
2
First public publish is reviewed. Claritty looks at it once, by hand. Later releases of the same app do not wait for that again.
3
It is listed. Other workspaces can install it. Each installer connects their own accounts and sees only their own data.

Validated and published are different states and always have been. Validated means it works. Published means other people can find it. An app sits at validated and not submitted for as long as you like.

Before you publish

Worth having in order, because they are what a reviewer looks at:


A README	What the app does, in the words someone deciding whether to install it would use.
Sensible empty states	What a brand new installer sees before there is any data.
The connect list	Every integration the app declares, and why it needs each one.
A widget worth putting on a home screen	One clear thing at a glance, and one action.

NextWidgets →The rules the gates enforce Troubleshooting →When a deploy is refused