Bitfield Docs

Build starts with a product moment: somebody opens a screen, sees real data, presses something, and the product changes without turning your software into a tangled mess.

The Build tab is the map for that moment. Runtime Kit teaches the public primitives. Build shows how those primitives become a product shape you can keep extending.

Declare the durable records, package-owned files, and callable slots your feature owns.

→

Render named data reads and send requests through named public actions.

→

Place surfaces in navigation and layout without teaching the shell product logic.

→

Run the same product shape across activated devices with account-owned access.

The build loop

Step	What you decide	Where to go
Shape the product screen	What the user sees, what data it needs, what actions it can request	App surfaces
Shape the package	Which records, package-owned files, and callable slots belong to the feature	Package authoring
Shape the target	Which named request changes something or starts work	Target design
Shape the shell	Where the surface appears and how the user moves between surfaces	Product shells
Shape the rollout	Which devices can run it and what the account/key path looks like	Device and deployment shape
Shape another SDK	Which tiny public functions app code should call	SDK boundary

What this section is not

This section does not replace the Runtime Kit manual. Runtime Kit is the contract layer. Build is the product composition layer.This section also does not ask the shell to become smart. The shell should own placement, navigation, account state, and device state. The package surface should own the feature UI and data it renders. The callable target should own the requested action.

Example product path

You are making a small customer dashboard.

The package owns customer records and a package-owned formatter file.
The surface reads a prepared customer list.
The surface sends customer.archive when the user archives one customer.
The shell places the surface in a dashboard region.
The account key activates the runtime identities that can trigger Bitfield.

The same shape should scale from a tiny private tool to a product with many features because each feature keeps its package file, surface, and action reply shape clear.

Common build mistakes

Mistake	Why it hurts	Fix
Put product action logic in the shell	Every screen starts depending on one growing layout file	Move the action behind a package target and let the shell place surfaces
Read raw package material in app code	The app depends on storage layout instead of a public data name	Use named data reads through the public Runtime Kit surface
Make one target do every action	Payloads become a secret command language	Give each product action a named target and a small payload
Treat account activation as an afterthought	The build works locally but fails when real devices arrive	Decide the runtime/device trigger path before launch

Start with App surfaces, then copy a complete shape from the Runtime Kit Cookbook.

Build a product

Activation

Build with Bitfield

The build loop

What this section is not

Example product path

Common build mistakes

Next

​The build loop

​What this section is not

​Example product path

​Common build mistakes

​Next

The build loop

What this section is not

Example product path

Common build mistakes

Next