Bitfield Docs

Runtime Kit keeps customer-visible Bitfield state under ~/.bitfield on the device.

What this is

Local state is the device-side home for Bitfield’s durable data area, package material, local runtime state, and activation files.This page explains the public folder meanings. It does not document proprietary storage layouts, binary encodings, or private recovery mechanics.

The mental model

Bitfield is built around local truth. That means your device has local state it can use without making every read depend on a remote service.Runtime Kit keeps that state in one predictable place. Some folders hold durable product data. Some folders hold package material. Some folders hold files used by the activation path when this runtime identity triggers Bitfield. You usually do not edit any of them by hand. Runtime Kit and the account portal should do that work.Local state also explains billing language. A runtime identity counts when Bitfield is actually triggered there in the billing window. A visitor reading static web output is not editing this state and is not triggering Bitfield runtime access.

Top-level shape

~/.bitfield/
  stored-data/
  runtime-kit/
  check-license/

What each area means

Area	Meaning	What you should do
`stored-data/`	The durable Bitfield data area.	Do not edit by hand.
`runtime-kit/`	Package sets, active package material, and local runtime state.	Use Runtime Kit package flows.
`check-license/`	Device permission files for this machine or runtime identity.	Use the account portal for activation, replacement, or revocation.

Runtime Kit area

~/.bitfield/runtime-kit/
  package-sets/
  running-now/

Area	Meaning
`package-sets/`	Active package material grouped by package set.
`running-now/`	Local process state for the current Runtime Kit session.

A package set separates one product or project from another. Package names can repeat across package sets without colliding.

Activation area

~/.bitfield/check-license/

This area is where Runtime Kit keeps device permission material. A normal user should manage activation from the account portal, not by editing files here.

What is safe to inspect

You can look at folder names when support asks you to confirm whether local state exists.You should not:

Edit files by hand.
Delete activation files to “reset” an account.
Copy one device’s local state to another device.
Treat local state as a public backup format.
Publish local state contents in a support ticket or public issue.

Privacy and offline behavior

The point of local state is that Bitfield can keep useful product truth close to the device. That supports offline and local-first product flows.Local-first does not mean every file in ~/.bitfield is safe to share. Treat this folder like product data and device permission material.

Before / after

Before clear local state	With Runtime Kit local state
Product data, package files, and device permission files are scattered.	They live under one predictable device folder.
Debugging starts with guessing where things are.	Support can ask for the top-level area that matters.
A package name can collide across projects.	Package sets separate project/package material.
Users try to hand-edit state.	The docs make clear what Runtime Kit and the account portal own.

Common mistakes

Editing stored data by handDo not edit files under stored-data/. Use Runtime Kit and product/account flows.Deleting device permission files without understanding activationUse the account portal when you need to replace or revoke a device.Copying local state between devicesDevice permission material belongs to a runtime identity. Copying folders is not the same as activating a new device.Publishing local stateDo not paste local state contents into public docs, issues, chats, or social posts.

Quick reference

~/.bitfield/stored-data/    durable Bitfield data area
~/.bitfield/runtime-kit/    package sets and local runtime state
~/.bitfield/check-license/  device permission material

If something is broken, start with the account portal for activation/account issues and Runtime Kit package flows for package issues.For public-page and billing guidance, read Use Runtime Kit where it should run.

Now build the bigger version

Make local-state debugging support-safe.When a user reports a problem, ask for high-level facts only:

Does ~/.bitfield exist?
Does ~/.bitfield/runtime-kit exist?
Which package set name were you using?
Does the account portal show this device as active?
What visible error did the app show?

Do not ask them to paste local state contents. Do not tell them to copy folders between devices. Device replacement should go through account-managed activation, and package issues should be debugged by package set and package name first.That keeps local-first speed and offline usefulness without turning local state into a public backup format or support pastebin.

Use Runtime Kit

Understand Runtime Kit

Build without tangled code

Runtime Kit Cookbook

Reference

Local state

What this is

The mental model

Top-level shape

What each area means

Runtime Kit area

Activation area

What is safe to inspect

Privacy and offline behavior

Before / after

Common mistakes

Quick reference

Now build the bigger version

​What this is

​The mental model

​Top-level shape

​What each area means

​Runtime Kit area

​Activation area

​What is safe to inspect

​Privacy and offline behavior

​Before / after

​Common mistakes

​Quick reference

​Now build the bigger version

What this is

The mental model

Top-level shape

What each area means

Runtime Kit area

Activation area

What is safe to inspect

Privacy and offline behavior

Before / after

Common mistakes

Quick reference

Now build the bigger version