A recipe is a list of steps. It describes one job. A pack is a box you install. The box can hold recipes, compositions, other packs it needs, and the access those things need.
#Browse recipes, install capabilities
Each recipe stays visible on its own in the marketplace. That way you can see what it does before you install anything. Some recipes belong to a pack. When you install one of those, Recued finds the pack that owns it. Then it opens that pack's setup screen.
This keeps two useful views:
- Recipe view. What the recipe does, and what result it gives.
- Pack view. What gets installed together, and which capabilities get access. A capability is one thing a pack can do.
#Recipe-only packs
A bulk pack may hold only recipes. That is still useful. The pack pins one set of recipe versions that fit together. You review and install them in one go. The pack page should show off those recipes. It should not show empty sections about capabilities.
#Dependencies
A recipe can need a capability pack. During setup, Recued shows you which known packs are missing. You can install them first, together with the recipe. Packs you already have stay visible. They are not installed a second time.
Do you want the JSON for recipe pins, typed contents, and needed versions? See the pack manifest reference.
#Programs a pack runs
Some packs run a program on your server, like ffmpeg or opencode.
Recued does not install the program for you. You install it.
The pack's page has a Programs block. It lists each program the pack runs. It says if the program is there, and which version you have.
Is a program missing? If the pack says how to install it, the block shows the command. Press Copy, then run the command yourself. Recued never runs it. When you are done, press Check again.
The packs list puts a badge on a pack when a program needs you:
- Needs ffmpeg. The program is not installed. The pack's actions fail until you install it.
- ffmpeg does not start. The program is there, but it does not start. The pack's actions are refused until it starts.
- opencode 2.0.1 not tested. The pack was not tested with your version. See the next section.
The badge is red only when the program stops the pack's actions.
#When a program's version was not tested
A pack can say which versions of a program it was tested with. Before an action runs, Recued checks the version you have. Is it outside those versions? Or can Recued not read it? Then one of two things happens:
- Refuse. The action does not run. Install a tested version, or choose Warn.
- Warn. The action runs anyway. Its log says which version it used.
The pack picks one as its default. You can choose for yourself. Look on the pack's page, under When the installed version is not tested. To go back, press Use the pack's default.
The check points you to a well-tested version. You can still run another one. Choose Warn to do that.
Your choice is for the versions the pack tests now. An update can test other versions. Then a Warn you chose no longer counts, and the pack's default applies again. A Refuse you chose stays. If an update changes what happens, its screen tells you first, under Programs this update changes.
#Access and audience
A pack that uses a connection asks you two things:
- Access. Which operations the pack may use. For example, read only, or read and write.
- Audience. Who may use those grants. The default is only you, the owner.
The grant you pick attaches to the installed pack. A single recipe cannot quietly make it bigger.
#Risk and approval for an operation
The access you pick at install time decides which operations a pack may use. Two more fields on each operation decide how it acts when it runs:
risk_tier. How serious its effect is:read,write,admin, ordestructive. The ingredient manifest reference says what each tier means.approval. When Recued stops and asks you before it runs:never,ask, oralways.
The risk tier picks a sensible default. The approval field lets the author
change it. You write both on each operation. In a pack's composition rows,
they are the risk and approval fields. In the Kitchen ingredient builder,
they are the Risk and Approval dropdowns on each operation card.
#Ask me every time
Some operations matter but are not dangerous. They spend real money. They start a costly render. They send something in your name. For these, you usually want Recued to stop and ask every time it runs. Even when you are the one pressing the button. 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 standing trust never waves this operation
through. It asks you on every run. You can still say yes for the current
chat session or for a burst. That way you are not clicking the same button
over and over. Turning it into a permanent rule that runs with nobody
watching is a separate, deliberate step. admin is a good base tier here. It reads as
"touches billing or spend". And it never quietly turns into a standing rule
on its own.
#Costly vs irreversible
destructive also pauses every time. But it means something stronger. It
means an operation you cannot take back, like a delete or a bulk update.
It asks every time, and you can never trust it away. Its question says
"cannot be undone". Save it for things that really cannot be undone. Do not
use it just because something is costly.
So keep the two ideas apart. Use approval: "always" for an action that
costs money but can be undone, like a costly render. The owner can still
trust that away for one session. Save destructive for things that cannot
be undone. Then "cannot be undone" always means exactly that. What the owner
sees is covered in Grants and approvals:
the approval card, session grants, and standing-rule suggestions.
#Watchers spanning multiple sources
A watcher is a recipe that keeps checking for something. Some watchers use several packs that have nothing to do with each other. Such a watcher does not need to pretend one pack owns them all. It can stay a recipe on its own. You install it by hand. Each capability pack keeps its own install and its own grants.