Recipe library

Recipes are additive manifest rewrites — see the recipe model concept doc for the why.

v1 catalog

Both recipes:

• run npm run dev (Vite) / npm run dev -- -p $PORT (Next.js) in the chosen folder
• ask the orchestrator to allocate a port and pass it through $PORT
• declare [runtime.node] with version 22 (skipped on apply if the project already has a node runtime pinned)

Applying

unibench recipes apply <recipe> [<project>] [--service-name <n>] [--cwd <p>]

• <project> defaults to the current directory.
• --service-name defaults to the recipe's default; override to land the same recipe twice in one project.
• --cwd defaults to the recipe's default; override to point at a non-standard folder layout.

Examples:

# add a frontend at ./frontend
unibench recipes apply frontend-vite

# add a second frontend at ./apps/admin called "admin"
unibench recipes apply frontend-vite \
    --service-name admin --cwd ./apps/admin

# apply to a project that isn't pwd
unibench recipes apply frontend-nextjs ~/Documents/unibench/my-rag

When apply fails

Apply errors are deliberately specific:

• Service name already exists. Pick a different --service-name. The manifest is untouched on failure.
• No unibench.toml at the target. Recipes don't scaffold projects — use unibench samples new first.
• Conflicting [runtime.<lang>]. Same lang, different version — we leave your pin alone. The recipe will still apply (the runtime block isn't strictly required) but you may need to update your package.json's engines if the version skew matters.