Bitfield Docs

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.

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.

scene

Start with the screen, package, or action the user is trying to build.

files

Name package files, app surfaces, descriptors, or shell files.

contract

Name data names, targets, payloads, replies, and boundaries.

check

End with a concrete pass/fail point and common failures.

Recipes

Package set with one record Create the smallest complete package: one package, one record, one stable address, and one check.

Package-owned file Attach package-owned text, JSON, image, or other bytes without letting the package read outside itself.

Callable package slot Declare a named callable target so app code can ask for work without importing the implementation.

React surface for package data Read named data, render every state, and send an action request from one surface.

Placeable surface product loop Compose package data, targets, surface descriptors, a dumb shell, and surface bodies.

Start here

Package to screen if you have not built the full chain yet.
Package set with one record if you want the smallest complete package recipe.
Package-owned file if your package needs to bring bytes with it.
Callable package slot if your package needs a target that can answer requests.
React surface for package data if your app needs to show data and trigger work.
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	Package file, named data read, action request, React surface, and debugging chain.
Declare one durable package record.	Package set with one record	Stable package-owned data address and payload update path.
Ship package-owned bytes.	Package-owned file	Package-local file ownership and path safety.
Add a callable target.	Callable package slot	Action name, method list, artifact path, and app request boundary.
Render package data in React.	React surface for package data	Read states, request states, public imports, and review checks.
Compose a product shell.	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:

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:

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.

​How to use the Runtime Kit Cookbook

​Recipes

​Start here

​Choose by job

​Recipe review contract

​What is not here yet