Publishing

What publishing is for

A process you built works against your accounts. Publishing lets another workspace run the same process against theirs. What travels is the shape of the work — the script, the order of its steps, the arguments it takes, and which kind of source each step needs. What does not travel is any credential, any connection, or any data.

Publishing is done on the Publish page. A workspace has to be a registered publisher first; that involves verification and payout setup, so an operator creates it, and until then the page says so rather than offering a button that cannot work.

Listings and versions

A listing is the thing that appears in the catalogue: a name, a one-line summary, an optional description. A listing holds versions, and one version at a time is the one new installs get.

A version is one of your own saved tools, frozen. Published versions are immutable — a fix is a new version, and existing installs keep the version they have. An app you added from the catalogue cannot be republished: passing on somebody else’s package is not yours to do.

A listing starts as a draft and is invisible until you offer it. Offering needs a current version, because a listing nobody can install is worse than no listing. Listings created on this page are free; charging needs payout setup, which is not built yet.

What the installer sees

When you publish a version, Inline reads the script and works out which governed tools it calls and which source each of those came from. Tool names carry their origin, so this map is derivable, and it is shown to you before anything is published — a name whose origin was guessed is a name every installer would bind wrongly.

Each distinct source in that map becomes a role. The installer never sees your sources; they see the roles, and point each one at a source of their own.

Installing one

Adding an app from the catalogue is three decisions, on the Apps page, and none of them is implied.

1. Connect. What the app needs, against what this workspace has. Anything missing is connected on Sources first.
2. Bind. Point each role at one of your sources. Inline never chooses for you, even when exactly one of your sources matches the name — a name match is a hint, and binding is recorded as a person’s own act.
3. Allow. Reading is on; every write is yours to tick.

Step three cannot be drawn before step two is answered, and that is not a matter of layout. Whether an operation reads or deletes is decided by the bound source’s own specification, so it is a fact about your systems rather than a claim in the package. The preview recomputes it once the roles are bound. Anything the package could not classify is listed as unresolved, and nothing is granted for an operation nobody could classify.

Finally you give the app the name your agents will call it by.

An installed app runs on your accounts, under the grant you ticked, and never with more than the person calling it already holds. It is subject to the same rules and approvals as anything else, and every call it makes is in Activity.

Removing one

Removing an installed app stops it being callable straight away, including for a run already in progress, because the grant is read fresh on every call. What it did is kept: its history in Activity and its blast-radius report are untouched, since an app being gone is when you most want to ask what it did.