# Let'em Cook!

## Key pages

• Home — Product overview, sheriff field notes, and the human/agent action model.
• Documentation — This clickable HTML field guide.
• Contact — Reach out if you want help scaling your team with Let'em Cook!.

## 1. Start here

• What is Let'em Cook!? — Cookbooks, pages, recipes, steps, and shared execution.
• Publish a cookbook and grant the team — First Development Image, cookbook bundle, author-owned secrets as env vars, app install, team ACLs, and advanced multi-recipe apps.
• Tutorials — Seven ordered lessons with complete maintained source, expected output, and cleanup proof.
• Advanced examples — Five maintained AWS and GCP Cookbooks with explicit teardown and provider inventory proof.
• Operational use cases — BYOK WordPress migrations, corporate Nmap PDF reports, timed infrastructure, Terraform labs, restore drills, and Day-2 self-service.
• Deterministic computational units — The boundary, its limits, and why it helps agents.

## Use the public demo

When you only need to run an already-reviewed Tool, open the browser UI at https://demo.letemcook.dev, follow the stock OpenSSH path on the homepage, or use the LEMCSSH field guide. Machine-readable copy lives at llms.txt.

1. Prefer a browser? Open https://demo.letemcook.dev. Prefer stock OpenSSH? Register at demo.letemcook.dev. No beta request is required.
2. Create a distinct Ed25519 key, keep the private file at mode 0600, and register only the public half.
3. Verify the host-key fingerprint out of band, then confirm identity with ssh demo.letemcook.dev auth whoami --format=json.
4. List authorized apps, inspect an action surface, and run only a returned action ID with --follow.
5. Confirm task ID, terminal reason, system and recipe steps, logs, artifacts, and cleanup proof.

## Create your first governed capability

Accepted teams publish through the reviewed account workflow. The steps below are the product order of operations. The full role split, review checklist, and sample cookbook YAML live in Publish a cookbook and grant the team.

### 1. First Development Image (Builder)

1. Inspect remote contracts: ssh HOST help --all --format=json and ssh HOST builder images --help.
2. List images with builder images list --format=json.
3. Send a Dockerfile or source through the server-owned Builder over bounded stdin. Prefer builder images compile-run IMAGE_UUID --expected-revision REVISION_UUID --idempotency-key REQUEST_UUID --follow.
4. Record the immutable digest the Builder returns. Cookbook YAML must pin that digest by SHA, not by tag.
5. In recipe steps, reference the image as registry/.../name@sha256:<hex> (or the managed-digest form LEMC returns). Do not use :latest, :main, or any other mutable tag for hosted-untrusted runs.
6. The SSH host is not a shell or Docker host. Builds run in fresh jailed guests under LEMC policy. Details: Build through the governed boundary.

### 2. First cookbook

1. Keep one reviewable bundle: cookbook.yaml, image sources, optional terraform/, tests, and README.
2. Declare pages, recipes, form inputs, timing (now / in / every), callbacks, and secret names only under environment.secrets.
3. Point every step image: at a digest-pinned managed image from the Builder or a reviewed import path — always @sha256:..., never :latest.
4. Never place secret values in Git, YAML, agent prompts, command arguments, logs, or artifacts. Namespace multi-team keys (for example TEAM1_GCP_SERVICE_ACCOUNT_JSON / TEAM2_GCP_SERVICE_ACCOUNT_JSON).
5. A human reviews least privilege, network boundary, idempotency, timeouts, teardown, and proof before promote.

### 3. First app

1. Promote the reviewed cookbook through the account-controlled publication workflow so LEMC records digests and creates the app snapshot.
2. The cookbook author binds each declared secret through the write-only server binding (User Secrets catalog). LEMC stores values separately and returns only names, status, and audit metadata.
3. At job time LEMC injects each bound value as a process environment variable with that exact name. Recipe code reads $NAME; it must never print the value. End users do not re-bind author secrets to run the app.
4. Confirm the app installs against the reviewed cookbook snapshot, not an ad hoc local tag.

### 4. Share with users and agents

1. App owners grant only the teammate or agent scope that should run the action.
2. A run grant does not grant cookbook edit, image publication, secret retrieval, or account administration.
3. Callers discover with apps list and jobs surface, then run with jobs run ... --follow.
4. Browser and LEMCSSH share one durable task identity, step stream, terminal reason, logs, and artifacts. Author secrets stay in the author catalog; runners get capability and redacted proof.

### 5. More advanced apps

1. Split capabilities into separate recipes (create, list, delete, launch-from-image) instead of one unbounded shell surface.
2. Use callbacks and timed or recurring jobs for cleanup, TTL destroy, and governed child jobs with preflight and proof.
3. Keep Terraform or other durable state under authorized /lemc mounts so later jobs hydrate reviewed state. See Recipe state and LEMC verbs.
4. Expand form inputs carefully; keep private next-step handoffs inside one job with lemc.env, never as durable secrets or log noise. Secrets remain author-catalog names that inject as env vars.
5. Prefer small, named recipes with explicit proof over a multi-purpose tool that looks like a scanner shell.

## 2. Humans and agents

• MCP integration vs LEMC's operating model — Governed supply chain, dynamic authority, isolation, human/agent usability, and durable evidence.
• LEMCSSH field guide — Discover, submit, follow, inspect, and retrieve.

## 3. Runtime and output

• Architecture — Server-owned execution, isolation, event fanout, and storage.
• Themes — Operator-installed bundles, account-admin selection, agent authority, and the current no-upload boundary.
• Recipe state and LEMC verbs — Wire format verb.name;payload, form fields → env, secrets as env, durable workspaces, artifacts, and visible output.
• Form fields → env — Field types, variable vs name, value not label, and non-secret precedence.
• Builder over LEMCSSH — Bounded stdin, jailed compile, digest pin; not a shell or Docker host.

## Agent quick path

1. Fetch /llms.txt for the machine-readable map and both demo and author paths.
2. Authenticate with the target LEMC server.
3. List authorized apps, then inspect an action surface with ssh demo.letemcook.dev jobs surface ... --format=json.
4. Choose a returned action ID and supply only its declared form values.
5. Run it with ssh demo.letemcook.dev jobs run ... --action <action-id> --follow --render html.
6. Confirm task ID, terminal reason, steps, logs, and artifacts.
7. When authoring, follow the first-capability steps above and the publish guide before promoting digests or ACLs.

> [!NOTE] Execution mode, runner selection, and isolation policy are server/operator decisions. Clients do not choose them per request.