A recipe describes a unit of work. A pack is the installable capability bundle that can carry recipes, compositions, dependencies, and the access they need.
#Browse recipes, install capabilities
Recipes stay individually visible in the marketplace so people can understand the outcome before installing anything. When a recipe belongs to a bundle, its install action resolves the owning pack and opens the pack setup flow.
This preserves two useful views:
- Recipe view: what the automation does and what result it produces.
- Pack view: what is installed together and which capabilities receive access.
#Recipe-only packs
A bulk pack may contain only recipes. That is still useful: the pack pins a coherent set of versions and gives users one review and install action. The pack detail page should emphasize the bundled workflows instead of showing empty capability sections.
#Dependencies
A recipe can depend on a capability pack. During setup, Recued shows missing known packs and lets the user co-install them before the recipe. Installed packs remain visible but are not installed a second time.
For the JSON shape behind recipe pins, typed contents, and prerequisite versions, see the pack manifest reference.
#Access and audience
Connection-backed packs expose two separate choices:
- Access — which operations the pack may use, such as read or read and write.
- Audience — who may use those grants, starting with the owner-only default.
The selected grant is attached to the installed pack. Individual recipes do not silently widen it.
#Risk and approval for an operation
Install-time access decides which operations a pack may use. Two authoring fields on each operation decide how it behaves once it runs:
risk_tier— how consequential the operation is:read,write,admin, ordestructive. See the ingredient manifest reference for what each tier means.approval— when Recued pauses for your confirmation before it runs:never,ask, oralways.
The risk tier sets a sensible default; approval lets the author override it.
Both are authored per operation — as the risk and approval fields on a pack's
composition rows, and as the Risk and Approval dropdowns on each
operation card in the Kitchen ingredient builder.
#Ask me every time
If an operation is consequential but not dangerous — it spends real money, starts an expensive render, sends something on your behalf — you usually want Recued to stop and confirm every time it runs, even when you are the one driving. The direct way to say that is to keep an honest risk tier and set approval to always:
{ "risk_tier": "admin", "approval": "always" }approval: "always" means the operation is never waved through by standing
trust — it surfaces for confirmation on every run. You can still approve it for
the current chat session or burst so you are not clicking the same button
repeatedly; turning it into a permanent, unattended rule stays a separate,
deliberate step. admin is a good base tier here because it reads as "touches
billing or spend" and never quietly becomes a standing rule on its own.
#Costly vs irreversible
destructive also pauses every time — but it means something stronger: an
operation you cannot take back (deletes, bulk-updates). It asks every time
and can never be trusted away, and its confirmation says "cannot be undone."
Reserve it for genuinely irreversible operations, not merely expensive ones.
So keep the two ideas distinct: use approval: "always" for a costly-but-reversible
action (spends money, an expensive render — the owner can still trust it away for
a session), and reserve destructive for irreversible ones — so a "cannot be
undone" confirmation always means exactly that. What each looks like from the
owner's side — the approval card, session grants, standing-rule suggestions — is
covered in Grants and approvals.
#Watchers spanning multiple sources
A watcher that coordinates several unrelated pack sources does not need to pretend that one bundle owns all of them. It can remain a standalone recipe for manual installation, while each capability pack keeps its own install and grant boundary.