ARCHITECTURE · BLOCKS

Nine parts, no moving pieces left over.

Every concept in tebako is exactly one of these. Once you can name them, the whole system — packaging, distribution, trust, version management — reads as their combinations.

 author                          distribution                     user machine
──────────────────────────────────────────────────────────────────────────────────
 source code ──press──► slices ──publish──► registry ──download──► local store
                 │                                   │
                 └──stack──► package ◄────────────────┘
                              │
                              ▼  user runs it
                    bootstrap → runtime → mounted slices → the program runs

The package

THE ARTIFACT

One file that runs. It contains the bootstrap, one or more slices in numbered slots, and a table of contents at the end. Nothing to install, nothing to extract, nothing running in the background — a file you can email is the whole distribution unit.

The bootstrap

THE LOADER

A small, static Rust binary (under 3 MB, 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 your program. Downloads are built in — it never shells out to curl, git, or anything else on the machine.

The runtime slice

THE INTERPRETER

Ruby today, other languages on the same model tomorrow. Downloaded once per machine, verified, and shared by every tebako application. Upgrading the runtime never requires rebuilding an application — applications declare a version range, and the resolver picks the newest compatible one.

The executable slice

THE APPLICATION

Your app as one mountable image: code, dependencies, and a manifest that says what it provides (commands) and what it requires (a runtime range, other slices). Pure-language apps ship one universal image; native extensions ship one image per platform.

The data slice

THE CONTENT

Fonts, schemas, dictionaries, datasets — versioned content with its own release line, mounted read-only next to the application. One copy on disk serves every consumer; an update to the data touches no application binary.

The toolkit slice

THE CAPABILITY

Optional machinery 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 is used from then on. Capabilities are named, never guessed.

The shim system

THE PATH SURFACE

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

Install & the local register

THE STORE

Everything lives under one home (~/.tebako): precious things (config, trust pins, keys) kept apart from re-derivable things (runtimes, slices, the register itself). The register is rebuilt from the store on demand — the tree is the truth, the index is a cache of it.

The remote registry

THE FINDING MECHANISM

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

Go deeper.

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