Store: one flat object pool per project, branches as refs

A store is a directory (.be/) holding one or more project shards; each shard is one flat object pool for all of a project's branches, tags, and remotes. The goal is a repo almost impossible to break — your own little GitHub in ~/.be — with cheap parallel worktrees and submodules. The method: multi-project shards, one flat object pool per project, branches and tags as pure ref rows (no per-branch object dirs), and ff-only branch trees that keep trunk linear while mess sinks into leaves.

Why multi-project, repo-per-store

A store hosts many projects, so the idiomatic setup is one ~/.be GitHub of your own; a store is hard to break where a worktree is easy, so worktrees stay cheap.

Branch-tree model

Branches form a tree (feature/fix1) of ff-only tips, so churn lives deep in the tree while trunk and its neighbors stay clean; staging and stash become short dirty branchlets.

Repo dir layout

Each project is one flat object pool: a single shard dir holds the packs, indexes, and refs for ALL its branches, tags, and remotes, so object retrieval consults exactly one dir with no trunk→leaf fan-out.

Remote resolution by reverse reflog grep

A short //host ref resolves with no ALIAS file and no registration step: every remote URI touched is logged to the project reflog on first contact, and a later short form reverse-greps that log newest-first for the most recent matching row.

Worktrees and the anchor

A worktree is a separate on-disk checkout with its own .be/wtlog; row 0 pins the project store, and the branch is the latest get/post row's ?branch, never the anchor.

Garbage collection

GC is epoch-based and out of band: a dropped branch's objects simply linger, and a major release recompacts by copying the reachable closure into a fresh project id.