# Publish a cookbook and grant the team

## The authority split

> [!IMPORTANT] A run grant does not grant cookbook edit, image publication, secret retrieval, or account administration.

## Prepare one reviewable bundle

Keep the operating contract readable in one source bundle. An agent can draft it from a natural-language brief, but a human reviews the inputs, images, callbacks, ACLs, cleanup, and proof before publish. The public access path does not require a local client installation.

cookbook.yaml
Dockerfile
terraform/
tests/
README.md

Declare secret names only under environment.secrets. Keep the protected file outside Git, the agent prompt, YAML, command arguments, logs, artifacts, and rendered output. Names use [A-Z_][A-Z0-9_]*; the LEMC_ prefix is reserved.

cookbook:
  name: GCP Server Lifecycle
  canonical_name: gcp-server-lifecycle
  environment:
    secrets:
      # Author-owned catalog names. Namespace when one author holds more
      # than one key of the same kind (two teams, two projects, two clouds).
      - GCP_SERVICE_ACCOUNT_JSON
      - TEAM1_GCP_SERVICE_ACCOUNT_JSON
      - TEAM2_GCP_SERVICE_ACCOUNT_JSON
  pages:
    - page: 1
      name: Timed GCP server
      recipes:
        - recipe: Create a server
          canonical_name: create-server
          callbacks:
            before_run:
              steps:
                - name: Destroy if present
                  image: gcp-server-destroy@sha256:REVIEWED_DIGEST
          now:
            steps:
              - name: Apply the declared server
                image: gcp-server-create@sha256:REVIEWED_DIGEST
          in:
            duration: 24.hours
            steps:
              - name: Destroy after TTL
                image: gcp-server-destroy@sha256:REVIEWED_DIGEST
        - recipe: Destroy the server now
          canonical_name: destroy-server-now
          now:
            steps:
              - name: Destroy the tracked server
                image: gcp-server-destroy@sha256:REVIEWED_DIGEST

## Secrets become environment variables

LEMC does not put secret values in the cookbook, the app snapshot, or the end user’s form. The flow is:

1. Declare each name in cookbook or recipe YAML under environment.secrets.
2. Bind the value once in the original cookbook author’s write-only User Secrets catalog (AES-256-GCM at rest). List and inspect surfaces return only names, status, description, and audit metadata.
3. Resolve at job admission as original author user ID + exact name. The runner who clicks the app does not supply a different secret catalog for those author-owned names.
4. Inject each accepted value into the recipe process environment under that exact name for the duration of the job. Recipe code reads ordinary env vars such as $GCP_SERVICE_ACCOUNT_JSON or $TEAM1_GCP_SERVICE_ACCOUNT_JSON.
5. Redact and discard after use. Never print secrets to stdout, stderr, LEMC verbs, logs, artifacts, or workspace files. LEMC redacts exact values on managed streams as defense in depth; reviewed recipe code still must not emit them.

# Recipe step: use the injected env var. Do not echo it.
test -n "${GCP_SERVICE_ACCOUNT_JSON:-}"
gcloud auth activate-service-account --key-file=... # write key only to ephemeral path if required
# Prefer tools that accept the value from the environment without logging it.

# When one cookbook holds more than one GCP key, pick the namespaced name
# the recipe was written for—never a shared generic binding for two teams.
test -n "${TEAM1_GCP_SERVICE_ACCOUNT_JSON:-}"
test -n "${TEAM2_GCP_SERVICE_ACCOUNT_JSON:-}"

> [!IMPORTANT] Author secrets are global to the cookbook author’s catalog, not to each teammate you empower. Namespace names by team, project, or purpose so two keys never collide under one bland name. A run grant still does not grant secret retrieval or catalog admin.

## Create the first Development Image

Before a recipe can run hosted-untrusted work, it needs a digest-pinned image that entered LEMC’s managed path. Accepted teams use the server-owned Builder over LEMCSSH so the agent never gets a Docker socket or host shell.

1. Authenticate and inspect contracts: ssh HOST help --all --format=json, then ssh HOST builder images --help.
2. List existing images: ssh HOST builder images list --format=json.
3. Compile and test through the Builder, for example ssh HOST builder images compile-run IMAGE_UUID --expected-revision REVISION_UUID --idempotency-key REQUEST_UUID --follow, sending Dockerfile or source on bounded stdin.
4. Record the immutable digest the Builder returns. That digest is what cookbook YAML pins later.
5. In recipe steps, write image: registry/.../name@sha256:REVIEWED_DIGEST (or the managed-digest form LEMC returns). Do not use :latest, :main, floating branch tags, or any other mutable tag.
6. Prefer a multi-stage or minimal runtime image so compilers and package indexes do not ship in the final layer.

> [!IMPORTANT] Hosted-untrusted jobs require a digest-pinned image (@sha256:…). A local Docker tag, remote :latest, or other mutable ref is not production-ready; LEMC fails closed when the cookbook still points at an unauthorized or non-digest image. The Builder path is server-owned: bounded stdin in, jailed compile in a fresh guest, managed digest out—not a shell or Docker host for the agent. See also the LEMCSSH Builder notes.

## Create the first cookbook

1. Assemble the reviewable bundle above (cookbook.yaml, images, optional Terraform, tests, README).
2. Declare pages and recipes as separate capabilities. Prefer create / list / delete / launch-from-image style recipes over one shell surface.
3. Pin every step image: to a Builder or reviewed managed digest as …@sha256:<hex>. Never publish a cookbook that still says :latest.
4. Declare secret names only. Keep the protected file outside Git and outside the agent context. Namespace multi-team or multi-cloud keys (for example TEAM1_… / TEAM2_…).
5. Document expected form inputs, timeouts, cleanup, which env var each step reads, and proof so a reviewer can approve without reverse-engineering the container.

Form fields are not a separate template product. Each field’s variable (or compatibility name) becomes an uppercase environment variable; the container receives the option value, not the display label. Use lemc.env;KEY=value only for non-secret next-step handoff inside one job. Full types, conversion, and precedence live under Form fields become environment variables and LEMC verb wire format.

## Review, bind secrets, and create the first app

1. Review. Confirm declared inputs, least-privilege credentials, digest-pinned images, callback order, idempotency, timeouts, network boundary, and teardown proof.
2. Bind. The original cookbook author supplies each secret through the write-only server binding (User Secrets catalog). LEMC stores the value separately and returns only names, status, and audit metadata. Those names become env vars inside later jobs.
3. Promote. The account-controlled publication workflow validates the bundle, records the immutable image digests, and creates the app snapshot.
4. Install. The app owner installs the reviewed cookbook snapshot as an app surface people and agents can discover.
5. Grant. The app owner grants only the teammate or agent scope that should run the action. Runners do not re-bind author secrets to use the app.

> [!NOTE] LEMCSSH is the public remote command path for discovery, secret status, Builder work, and job execution. Cookbook creation, app creation, publication, and ACL mutation remain explicit reviewed account operations unless the remote contract exposes that operation.

## Share the app with other users and agents

Grant authorship to authors and execution to runners. Expanding the run ACL is how teammates and agents discover the same Tool without receiving secret values or cookbook edit rights.

1. Add only the people or agent identities that should run the action.
2. Prefer Individual scope for personal workspaces and Shared or ACL scopes when the contract is intentionally multi-user.
3. Tell callers to re-run discovery: apps list, then jobs surface, before jobs run.
4. Remind them that discovery is not permission; admission re-checks authority on every job.

## Grow into more advanced apps

• Add pages for distinct operator workflows instead of one overloaded form.
• Use before_run callbacks and timed in / recurring every recipes for destroy-after-TTL and cleanup proof.
• Keep durable Terraform state under authorized /lemc workspace mounts so later jobs hydrate reviewed state.
• Ship governed child jobs for page/recipe callbacks with preflight, idempotency, and browser/LEMCSSH parity.
• Keep each recipe a bounded computational unit: declared inputs, pinned images, policy, and observable proof.

For workspace variables, mounts, and LEMC verbs, continue with Recipe state and LEMC verbs.

## Let an agent draft the work

Give Codex, Claude, Grok, Gemini, or another approved agent the operating contract. Ask it to inspect the LEMCSSH help manifest before it writes source, and keep the real credential outside its context. Point it at llms.txt for the machine-readable map.

Contact me to work together.
Register the invited SSH key for demo.letemcook.dev.
Fetch https://letemcook.dev/llms.txt
Run: ssh demo.letemcook.dev help --all --format=json
Inspect builder, secret, and job contracts.
Draft the cookbook, containers, Terraform, tests, and ownership checks.
Never request or read GCP_SERVICE_ACCOUNT_JSON or other secret values.
Leave publication and secret binding to the original cookbook author.
Namespace multi-team keys (TEAM1_…, TEAM2_…) in YAML names only.

The agent may use LEMCSSH to inspect names-only binding status, compile a server-owned Development Image, and submit a reviewed action. LEMC resolves author-owned secrets into the job environment by declared name and returns redacted events and proof.

## Let a teammate or agent run it

After registration and a run grant, the caller uses the same action contract as the browser:

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

Both callers receive the same task identity, system and recipe steps, live events, terminal reason, logs, artifacts, and cleanup proof.

## What the central authority proves

• the author was authenticated and authorized to edit the cookbook;
• the image entered an account- and cookbook-scoped publication path;
• the recipe points to immutable digests with recorded ownership;
• the app binds a reviewed cookbook snapshot;
• the caller passed current account and app checks before admission;
• browser and LEMCSSH callers observe one durable execution record.