# Let'em Cook!

> Stop burning tokens on work your team has already solved.
>
> Empower forward deployed engineers to build
>
> *Let'em Cook!* converts one-off AI work into reusable, governed Tools your team can securely run and share. Each versioned recipe carries the context, inputs, permissions, execution policy, and proof people and agents need to call it again—without paying the token and engineering cost of rediscovery.

## What LEMC is

- *Let'em Cook!* (LEMC) packages one reviewed computation as a versioned recipe.
- A person can click it. An agent can call it with stock OpenSSH.
- LEMCSSH is the restricted LEMC command endpoint over OpenSSH. It is not a shell.
- The server owns auth, policy, isolation, and proof. Clients do not pick an execution mode.

## Hard rules

1. Discover first. Then inspect. Then run only a returned action ID.
2. Discovery is not permission. The server checks authority again on every job.
3. Never put secret values in prompts, YAML, args, logs, or artifacts.
4. Pin recipe images with `@sha256:...`. Do **not** use `:latest` or other mutable tags for hosted-untrusted runs.
5. Prefer small named recipes with explicit proof over one unbounded shell.
6. Cookbook YAML declares secret **names** only (`environment.secrets`). At job time LEMC injects each bound value as a process environment variable with that exact name (for example `$GCP_JUMP_HOST_KEY`). Recipe code may read the env var; it must never print, log, or write the value to artifacts.
7. Secrets resolve from the **original cookbook author's** write-only secret catalog—not from each end user who later runs the app. Callers receive the capability, not their own copy of the key.
8. Namespace secret names when one author or cookbook holds more than one credential of the same kind. Prefer `TEAM1_GCP_SERVICE_ACCOUNT_JSON` and `TEAM2_GCP_SERVICE_ACCOUNT_JSON` over a single generic name. Names match `[A-Z_][A-Z0-9_]*`; the `LEMC_` prefix is reserved.

## Key pages

- [Home](https://letemcook.dev/) - Product pitch, demo, and human/agent model
- [Documentation](https://letemcook.dev/docs/) - HTML field guide (same map as this file)
- [Contact](https://letemcook.dev/contact/) - Work together to scale your team with *Let'em Cook!*

## 1. Start here

- [What is *Let'em Cook!*?](https://letemcook.dev/docs/what-is-lemc/) - Cookbooks, pages, recipes, jailed jobs, durable output
- [Publish a cookbook and grant the team](https://letemcook.dev/docs/publish-cookbooks/) - First image, cookbook, app, secrets, ACLs
- [Tutorials](https://letemcook.dev/docs/tutorials/) - Seven ordered lessons with complete maintained source and cleanup proof
- [Advanced examples](https://letemcook.dev/docs/examples/) - Five maintained AWS and GCP Cookbooks with explicit teardown
- [First Development Image (Builder)](https://letemcook.dev/docs/publish-cookbooks/#first-builder-image) - Digest-pinned image via server-owned Builder
- [Secrets become environment variables](https://letemcook.dev/docs/publish-cookbooks/#secrets-as-env) - Declare names; author binds; inject as env
- [Operational use cases](https://letemcook.dev/docs/use-cases/) - Migrations, scans, labs, restore drills, Day-2 jobs
- [Deterministic computational units](https://letemcook.dev/docs/deterministic-units/) - What the recipe boundary guarantees

## 2. Humans and agents

- [MCP integration vs LEMC's operating model](https://letemcook.dev/docs/humans-and-agents/) - MCP standardizes AI integration; LEMC packages, authorizes, executes, distributes, and proves reviewed computation
- [LEMCSSH field guide](https://letemcook.dev/docs/lemcssh/) - Demo signup, discover, run, follow
- [Build through the governed boundary (Builder)](https://letemcook.dev/docs/lemcssh/#remote-builder) - Bounded stdin, jailed compile, digest pin; not a shell or Docker host

## 3. Runtime and output

- [Themes: install, select, and govern](https://letemcook.dev/docs/themes/) - Built-ins + managed bundle lifecycle; account admin select; no arbitrary CSS/JS upload
- [Architecture](https://letemcook.dev/docs/architecture/) - Fresh Firecracker guest, events, teardown, storage
- [Recipe state and LEMC verbs](https://letemcook.dev/docs/lemc-verbs/) - Hydrate, context, steps, artifacts, browser/LEMCSSH output
- [Verb wire format](https://letemcook.dev/docs/lemc-verbs/#wire-format) - `verb.name;payload` on stdout; no unknown→output fallback
- [Verb reference](https://letemcook.dev/docs/lemc-verbs/#verb-reference) - html/css/js/output/env/err families
- [Form fields → env](https://letemcook.dev/docs/lemc-verbs/#form-fields-to-env) - variable→UPPER_SNAKE; value not label; types and precedence
- [Declared secrets as env](https://letemcook.dev/docs/lemc-verbs/#declared-secrets-as-env) - names only in YAML; author catalog injects exact names

## Demo path (run a reviewed Tool)

Goal: call one approved Tool. Do not install a server.

Web UI: [https://demo.letemcook.dev/](https://demo.letemcook.dev/)

HTML: [LEMCSSH field guide](https://letemcook.dev/docs/lemcssh/) and homepage section `02` at [Home](https://letemcook.dev/#demo).

```sh
# 1) One distinct key (private stays local at 0600)
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/lemc-demo
chmod 600 ~/.ssh/lemc-demo

# 2) Host block: HostName demo.letemcook.dev, Port 22,
#    IdentitiesOnly yes, StrictHostKeyChecking yes
#    IdentityFile ~/.ssh/lemc-demo

# 3) Signup over stock OpenSSH (LEMCSSH endpoint, not a shell)
ssh -t demo.letemcook.dev

# 4) Verify, discover, inspect, run
ssh demo.letemcook.dev auth whoami --format=json
ssh demo.letemcook.dev apps list --format=json
ssh demo.letemcook.dev jobs surface app --uuid APP_UUID --scope individual --format=json
ssh demo.letemcook.dev jobs run app --uuid APP_UUID --action ACTION_ID --follow --render json
```

Confirm task ID, terminal status and reason, steps, logs, and artifacts.

In a Ralph-style iterative loop, re-run discovery each pass. Do not run a new app only because it appeared. Inspect the action contract first.

Contact: https://letemcook.dev/contact/ for customer-owned install help.

## Author path (first image, cookbook, app, and share)

Goal: publish a governed capability for the team.

HTML:
- [Publish a cookbook and grant the team](https://letemcook.dev/docs/publish-cookbooks/)
- [Tutorials](https://letemcook.dev/docs/tutorials/)
- [Advanced examples](https://letemcook.dev/docs/examples/)
- [First Development Image (Builder)](https://letemcook.dev/docs/publish-cookbooks/#first-builder-image)
- [Secrets become environment variables](https://letemcook.dev/docs/publish-cookbooks/#secrets-as-env)
- [LEMCSSH Builder boundary](https://letemcook.dev/docs/lemcssh/#remote-builder)
- [Form fields → env](https://letemcook.dev/docs/lemc-verbs/#form-fields-to-env)
- [Verb wire format](https://letemcook.dev/docs/lemc-verbs/#wire-format)
- [Documentation](https://letemcook.dev/docs/)

### 1. Create the first Development Image (Builder)

1. `ssh HOST help --all --format=json` then `ssh HOST builder images --help`
2. `ssh HOST builder images list --format=json`
3. Prefer `builder images compile-run IMAGE_UUID --expected-revision REVISION_UUID --idempotency-key REQUEST_UUID --follow`
4. Record the immutable digest. Cookbook YAML must pin that digest by SHA.
5. In recipe steps use `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.
7. Details: https://letemcook.dev/docs/publish-cookbooks/#first-builder-image and https://letemcook.dev/docs/lemcssh/#remote-builder

### 2. Create the first cookbook

1. One reviewable bundle: `cookbook.yaml`, image sources, optional `terraform/`, tests, README
2. Declare inputs, pages, recipes, timing (`now` / `in` / `every`), callbacks, and secret **names** only under `environment.secrets`
3. Every step `image:` is digest-pinned — always `@sha256:...`, never `:latest`
4. Namespace secret names for purpose and owner (for example `TEAM1_GCP_SERVICE_ACCOUNT_JSON`, not a bare shared key name when two teams need different keys)
5. Form fields use `variable`/`description`/`options`; LEMC injects uppercase env vars from option **values** (see https://letemcook.dev/docs/lemc-verbs/#form-fields-to-env)
6. Recipe steps emit `verb.name;payload` for UI and handoff (see https://letemcook.dev/docs/lemc-verbs/#wire-format)
7. A human reviews least privilege, network, idempotency, timeouts, teardown, and proof before promote
8. Cookbook authority (edit/publish) is separate from app run ACL

### 3. Create the first app from the cookbook

1. Promote the reviewed cookbook through the account publication workflow
2. The **cookbook author** binds each declared name in their write-only User Secrets catalog (AES-256-GCM at rest). LEMC returns only names, status, and audit metadata—never the value
3. At runtime the guest receives those values as env vars with the exact declared names. Recipe steps read `$NAME`. Do not print them
4. Install the app from that reviewed snapshot, not a local mutable tag. End users do not re-bind author secrets to run the app

### 4. Share with other users and agents

1. Grant only the run scope each teammate or agent needs
2. Run grant does not grant cookbook edit, image publish, secret read, or account admin
3. Callers use `apps list`, `jobs surface`, then `jobs run ... --follow`
4. Browser and LEMCSSH share the same task identity, steps, reason, logs, and artifacts
5. Secret values stay with the original author catalog; runners get capability + redacted proof only

### 5. Make more advanced apps

1. Prefer many small recipes (create, list, delete) over one shell recipe
2. Use callbacks and timed `in` / `every` jobs for cleanup and child work
3. Keep durable state under authorized `/lemc` mounts
4. Normalize form fields to uppercase underscore variables; keep `lemc.env` private to one job (non-secret handoff only)
5. Prefer named proof over multi-purpose tools
6. When one cookbook serves multiple teams or clouds, declare distinct namespaced secrets and document which recipe reads which name

Clients do not choose execution mode, runner, or isolation. The server owns those.

Accepted teams author through the reviewed account workflow. Public demo onboarding uses LEMCSSH through stock OpenSSH and never needs a server shell.