Nine building blocks, and how they fit together.

A package is one file that runs. It contains the bootstrap, one or more slices in numbered slots, and a table of contents at the end. Nothing requires installation, nothing is extracted, and nothing runs in the background; a file that can be attached to an email is the whole distribution unit.

The bootstrap is a small, static Rust binary, under 3 MB with the budget enforced in CI, that starts every package. It reads the table of contents, checks trust, finds or downloads the right runtime, mounts the slices, and starts the program. Downloads are built in, and it never shells out to curl, git, or anything else on the machine.

The runtime is Ruby today, and other languages follow the same model later. It is downloaded once per machine, verified, and shared by every tebako application. Upgrading the runtime never requires rebuilding an application, because applications declare a version range and the resolver picks the newest compatible runtime within it.

The executable slice is the application as one mountable image: code, dependencies, and a manifest that states what the slice provides (commands) and what it requires (a runtime range, other slices). Pure-language applications ship one universal image, and native extensions ship one image per platform.

The data slice is versioned content with its own release line, mounted read-only beside the application: fonts, schemas, dictionaries, and datasets. One copy on disk serves every consumer, and an update to the data touches no application binary.

The toolkit slice carries optional machinery that is too heavy for the core, cryptography first. The bootstrap stays under 3 MB precisely by not containing it; when verification is required, the toolkit downloads once and serves from then on. Capabilities are named, never guessed.

The shim system is one directory on PATH, one dispatcher binary, and one link per command. The dispatcher reads its invocation name, picks the pinned or newest compatible version, and launches it; the arrangement follows the busybox and rustup model, without shell scripts and their quoting and signal problems.

Everything lives under one home directory, ~/.tebako, where precious things (config, trust pins, keys) sit apart from re-derivable things (runtimes, slices, the register itself). The register is rebuilt from the store on demand: the store contents are the authority, and the register is a cache rebuilt from them.

There is no central server, ever. A registry is a YAML index hosted anywhere a file can live: GitHub releases, any git host, or any HTTPS path. Publishers sign, and users pin the key on first contact. Deleting a registry costs nothing, because the slices are the product and the index is a convenience over them.

Each block has its own page in the repository documentation, with the same structure used here: what it is, what it is for, and how it works; see docs/blocks.