> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bitfield.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Runtime Kit Cookbook

> Complete public Runtime Kit recipes for package files, named data reads, action requests, and placeable surfaces.

<div className="bf-article">
  <p className="bf-lead">
    Runtime Kit Cookbook entries are recipes, not loose snippets. Each recipe starts with the Runtime Kit product moment, shows the package files or app surface you own, gives the public Runtime Kit boundary, and ends with a check you can use to prove it worked.
  </p>

  Use these when you want to copy a Runtime Kit shape and adapt the names. The examples stay on the public side of the wall: package files, package-owned content, callable slots, named data reads, action requests, and placeable surface descriptors.

  This is not the whole-product Bitfield Cookbook. That future cookbook can own product-level recipes across account, proof, deployment, and operations. This section is only the Runtime Kit Cookbook.

  The full examples live in `examples/` and are indexed by `cookbook-examples.json`. The docs check makes sure the snippets shown here match those files exactly.

  ## How to use the Runtime Kit Cookbook

  Every recipe should answer the same questions:

  | Recipe question                   | Why it matters                                                |
  | --------------------------------- | ------------------------------------------------------------- |
  | When should I use this?           | Prevents copying the wrong pattern.                           |
  | What will I build?                | Gives the reader a product scene before the code.             |
  | Which files do I own?             | Keeps package files, app surfaces, and shell code separate.   |
  | What is the Runtime Kit contract? | Names data names, targets, payloads, replies, and boundaries. |
  | How do I check it worked?         | Gives every builder a pass/fail point.                        |
  | What breaks most often?           | Turns debugging into a known path instead of guessing.        |
  | How do I extend it?               | Shows the next move without changing the primitive.           |

  If a recipe does not answer those questions yet, it is not finished.

  <div className="bf-flow" aria-label="Runtime Kit Cookbook recipe flow">
    <div className="bf-flow-node">
      <span className="bf-flow-step">scene</span>
      <strong>Product moment</strong>
      <p>Start with the screen, package, or action the user is trying to build.</p>
    </div>

    <div className="bf-flow-arrow" aria-hidden="true">→</div>

    <div className="bf-flow-node">
      <span className="bf-flow-step">files</span>
      <strong>Owned files</strong>
      <p>Name package files, app surfaces, descriptors, or shell files.</p>
    </div>

    <div className="bf-flow-arrow" aria-hidden="true">→</div>

    <div className="bf-flow-node">
      <span className="bf-flow-step">contract</span>
      <strong>Public names</strong>
      <p>Name data names, targets, payloads, replies, and boundaries.</p>
    </div>

    <div className="bf-flow-arrow" aria-hidden="true">→</div>

    <div className="bf-flow-node">
      <span className="bf-flow-step">check</span>
      <strong>Verification</strong>
      <p>End with a concrete pass/fail point and common failures.</p>
    </div>
  </div>

  ## Recipes

  <div className="bf-grid">
    <div className="bf-card">
      <strong>Package set with one record</strong>
      Create the smallest complete package: one package, one record, one stable address, and one check.
    </div>

    <div className="bf-card">
      <strong>Package-owned file</strong>
      Attach package-owned text, JSON, image, or other bytes without letting the package read outside itself.
    </div>

    <div className="bf-card">
      <strong>Callable package slot</strong>
      Declare a named callable target so app code can ask for work without importing the implementation.
    </div>

    <div className="bf-card">
      <strong>React surface for package data</strong>
      Read named data, render every state, and send an action request from one surface.
    </div>

    <div className="bf-card">
      <strong>Placeable surface product loop</strong>
      Compose package data, targets, surface descriptors, a dumb shell, and surface bodies.
    </div>
  </div>

  ## Start here

  * [Package to screen](/runtime-kit/package-to-screen) if you have not built the full chain yet.
  * [Package set with one record](/runtime-kit/cookbook/package-set-with-one-record) if you want the smallest complete package recipe.
  * [Package-owned file](/runtime-kit/cookbook/package-owned-file) if your package needs to bring bytes with it.
  * [Callable package slot](/runtime-kit/cookbook/callable-package-slot) if your package needs a target that can answer requests.
  * [React surface for package data](/runtime-kit/cookbook/react-surface-for-package-data) if your app needs to show data and trigger work.
  * [Placeable surface product loop](/runtime-kit/cookbook/placeable-surface-product-loop) if you want package-to-shell composition.

  ## Choose by job

  | Your job                            | Recipe                                                                                 | What it proves                                                                     |
  | ----------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
  | Build the full first feature.       | [Package to screen](/runtime-kit/package-to-screen)                                    | Package file, named data read, action request, React surface, and debugging chain. |
  | Declare one durable package record. | [Package set with one record](/runtime-kit/cookbook/package-set-with-one-record)       | Stable package-owned data address and payload update path.                         |
  | Ship package-owned bytes.           | [Package-owned file](/runtime-kit/cookbook/package-owned-file)                         | Package-local file ownership and path safety.                                      |
  | Add a callable target.              | [Callable package slot](/runtime-kit/cookbook/callable-package-slot)                   | Action name, method list, artifact path, and app request boundary.                 |
  | Render package data in React.       | [React surface for package data](/runtime-kit/cookbook/react-surface-for-package-data) | Read states, request states, public imports, and review checks.                    |
  | Compose a product shell.            | [Placeable surface product loop](/runtime-kit/cookbook/placeable-surface-product-loop) | Descriptors, dumb shell, surface bodies, data names, and targets.                  |

  ## Recipe review contract

  When a recipe is used to build a feature, include this instruction:

  ```text theme={null}
  Use the public Runtime Kit recipe. Do not import private Runtime Kit paths.
  Name the package set, package, data names, targets, request payloads, reply payloads, and files changed.
  Render loading, error, empty, and success states for React reads.
  Call targets with sendRequestToBitfieldTarget(...), not by importing implementation code.
  ```

  Then require this explanation back:

  ```text theme={null}
  I changed these files:
  I used these public imports:
  The data names are:
  The targets are:
  The request/reply shapes are:
  The verification step is:
  ```

  That answer is how you catch boundary violations before they become product architecture.

  ## What is not here yet

  Account login, credential recovery, key rotation, account portal flows, billing, support escalation, deployment, and proof workflows are not in the Runtime Kit Cookbook lane. Those belong in account, operations, proof, or a future whole-product Bitfield Cookbook.
</div>