The store: one directory, nothing hidden.

Precious things (config, trust pins, and keys) sit next to re-derivable things (runtimes, payloads, and registry caches), so a backup policy and a cleanup policy are both obvious. Every downloaded artifact carries its own trust anchor beside it.

Figure 1 — The ~/.tebako store layout: runtimes, payloads, shims, registries, config, keys, trust, journal, locks, and tmp — with the house rules beside them.

Double-clicking a package, or executing it in a terminal, runs it: the loader resolves the runtime (downloading it once if needed, which is runtime resolution, shared infrastructure, not installation) and starts the program. Nothing from the package’s payload slots enters the store.

tebako install is the explicit verb: it brings a payload into the store, downloaded to a temporary location, verified against its published SHA-256, and renamed into place read-only, and it registers a shim for every command the payload declares. Registry installs always register shims, and installing a local package file registers them only when the caller passes --shims. tebako uninstall removes the shims and the cache entry.

The store itself is versioned: a single integer marks its layout generation. A newer store refuses an older tool with a named error instead of a silent mix, and an older store is migrated by name, never silently rewritten.

A runtime install does not wait for the whole env image. The install fetches and pins the image’s block-checksum sidecar, and the image’s 4 MiB block groups arrive on demand — a run touches only the groups it reads — while a background seal completes the entry into the same bytes a whole-image install would have produced. A sealed entry is byte-identical in both modes, which makes the mode a scheduling decision rather than a format. A release that does not serve the lazy wire installs eagerly, with a loud notice, and TEBAKO_RUNTIME_LAZY=0 — or runtime_lazy: false in config.yaml — restores the whole-image install for the machine.

The cache is available for inspection and pruning. Everything here is read-only against the store, and nothing fetches.

Pruning only ever removes re-derivable artifacts, and the next run that needs one downloads and verifies it again. Config, keys, and trust pins are never pruned.

The reason is that the store contents are the authority. Every artifact carries its own proof (the sidecar), its own provenance (the origin marker), and its own manifest mirror, so the store is auditable with ordinary tools, repairable by deleting things, and portable by copying it. The registry caches are the only derived state, and they rebuild themselves on a 24-hour cycle or on tebako update-registries.