.be blob → fsck fails
Pushing a beagle history to a BRAND-NEW / empty git remote produces an inconsistent pack: the committed root trees carry a .be entry (the store anchor — gitignored yet recorded in the tree object), but the pack walk (keeper/WALK.c DPATHVerify) deliberately SKIPS .be, so the blob the tree entry points at is never written. A fresh remote has no copy, so git fsck / git-receive-pack rejects the push with missing blob object. Against any remote that already holds the blob (every incremental fast-forward — the normal path) it is harmless, so it only bites a fresh or empty remote. Found while fixing POST-021 (the push BNOROOM); isolated there by using a .be-free synthetic history for the regression test, so it is unrelated to that fix and gets its own ticket.
The tree references a blob the pack refuses to ship.
.be entry (store anchor). It is gitignored but present in the committed tree object, so the tree has a dangling reference once the walk drops it.keeper/WALK.c DPATHVerify) skips .be, so its blob is omitted from the generated pack.git fsck/git-receive-pack: missing blob object. Existing remote (already has the blob) → harmless; hence only fresh/empty remotes fail.A fresh-remote push yields an fsck-clean pack — no dangling tree references.
.be in the committed tree (it is the gitignored store anchor; arguably never belongs in a tree), OR include its blob in the pack when the tree references it. Pick one and make tree-vs-pack consistent..be-bearing history to a FRESH bare git remote, assert exit 0 + git fsck clean + remote advances..be in the working tree. Couples to the store-anchor layout (SUBS .be/.dogs handling).
(pending — decide: drop .be from trees vs ship its blob)
.be becomes a tree entry (the commit/tree builder; keeper POST / DPATH) and why DPATHVerify skips it on the pack walk..be tree entry, OR pack-include it) and apply.git fsck test, confirm failing pre-fix.