Publishing

Publishing makes a recipe or pack public under your namespace. A pack is how you ship custom ingredients alongside the recipes that use them. Browsing and installing never require an account; publishing requires a free one because the namespace needs an owner. What you publish is the readable JSON itself — that openness is the marketplace's trust model.

#Before you publish

Finish and test against your own server first. For an ingredient pack, save, review, preview, and install it locally from the Pack editor before opening the cloud publish flow. The metadata carries the listing, so it is worth getting right:

• Name, description, tags — how people find it.
• Platforms and variant group — lets cross-platform variants of one recipe collapse into a single marketplace card.
• Execution scope — badges where the recipe can run.
• Provenance flag — an opt-out of timeline links is shown to installers.
• Fork lineage — a published fork displays what it descends from.

#Submit a recipe for review

The publish surface consumes one exported JSON object; it validates and submits, but it is not an editor. Load a Kitchen handoff when your build offers one, upload the exported file, or paste the object:

1. Confirm that the artifact type is recipe.
2. Confirm the namespace: your local slug becomes publisher/slug.
3. Validation runs — schema errors, marketplace gates, and missing-dependency warnings, structured by field.
4. Submit. The slug is reserved for you while the review is pending.

#Review

A submission is pending until it is approved, rejected, or you cancel it. Approval produces the live listing. A rejection shows its reason and timestamp — revise in the Kitchen and resubmit; the record is status, reason, and time, nothing hidden. Reservations for rejected or abandoned submissions expire rather than squatting the namespace. Track all of it on the dashboard's Submissions page.

#Publish a pack manifest

Packs use a separate, direct publication path rather than the recipe review queue. The authenticated publisher must match the manifest's publisher. Recued validates the pack envelope and every by-value composition; a valid manifest is then published and appears in the dashboard activity feed.

Direct publication does not turn a pack into a trusted or preinstalled first-party artifact, and it does not prove every external pin will resolve on an installer's server. Installation still resolves the referenced versions, shows the permission and connection choices, and fails closed on an invalid composition. See the pack manifest reference for the two manifest versions and their validation boundaries.

#Versions

A new recipe version repeats the review submission. A new pack version repeats the direct pack-publication path and its validation gates. Listings keep their version history, and installers can stay pinned rather than following updates automatically.

#Forks

Forking is first-class, with a deliberate line between private and public:

• Local forks stay on your own setup — private, and running under the original ingredient author's credential scope.
• Published forks become their own artifact: your publisher handle, your own credential scope, and visible fork_of lineage back to the original.

Credential scoping is per publisher and install, so two same-named recipes from different publishers never share secrets.

#Unpublishing

Where policy allows, a listing can be unpublished from the dashboard — and restored. Unpublishing removes the listing from the marketplace; it does not reach into servers that already installed the content, because installs are local copies.

#Related

• Account and dashboard — the handle and the submission-tracking surface.
• Authoring recipes — writing the thing you are about to publish.
• Authoring ingredient packs — building, reviewing, previewing, and locally installing a custom capability.
• Recipes and packs — how listings are browsed and installed.
• Pack manifest — the direct-publish bundle, dependency, and install-disclosure shape.