07 · Hives → HQ

A fleet of hives, one Head Office

Each hive owns its issues; the workspace owns the view. bh sync aggregates every registered hive — cloned ones by local path, uncloned ones via a blobless minimal-clone cache — so bh hq bd ready answers "what's actionable anywhere?" even on a machine with no code checked out.

$GIT_WORKSPACE — EACH REPO IS A HIVEhivegithub/acme/api.beads/ (Dolt) + codehivegithub/acme/webprefix: acme-web-Nhivegitea/lab/protonot even cloned herebd dolt pushrepo's own git remoterefs/heads/* · code, PRsrefs/dolt/data · issue historyrepo's own git remoterefs/heads/* · code, PRsrefs/dolt/data · issue historyrepo's own git remoterefs/heads/* · code, PRsrefs/dolt/data · issue historyno central server — issue data rides the repo's own remote,in a ref namespace branches and PRs never seebh synccloned → by local pathuncloned → blobless cache + bd bootstrapHQ / hub~/.beadhive/hq · ~/.beadhive/hubone aggregated beads DBread cache — hives stay authoritativebh hq bd readyactionable work, anywherebh hq intakedirector's fleet-wide inboxHead Office — ~/.beadhive/config.yamlthe partitioned workspace registry · least-privilege writessupervisor → policy · director → fleet membershipcustodian → hive config + secrets · controller → read-only
The hub (personal scale) and Factory HQ (shared scale) use the same aggregation mechanism; when an HQ is registered, bh hq and bh sync use it. The prefix is permanent and derived from org + repo; the provider — the thing most likely to change — lives in a label, so a host migration is a label edit, not data surgery.

Keeping the fleet in sync

bh hive sync reconciles a hive against the fleet in both directions. Where the two disagree it surfaces the disagreement as data rather than picking a winner quietly — a conflict is something you read and decide, not something a sync resolves silently while you're not looking. bh sync is the fleet-wide pass: it adds every registered hive, clone-caching the ones that aren't checked out locally.

Fielding what comes in

Work also arrives from outside the plan. bh report files a bug or request into any hive you own — including from a different hive entirely, which is how one repo tells another that something it depends on is broken. bh escalate is the lighter move: name a tool problem, hand it up, and keep working rather than stopping to route it yourself.

Both land in one queue. bh work intake is the per-hive view andbh hq intake the fleet-wide inbox, and the queue is source-agnostic — a cross-hive report, an imported GitHub issue, and a legacy import all triage the same way, with duplicate detection running on entry and again at triage so a colliding request doesn't bury the queue. Four verbs dispose of anything in it:

  • bh work accept — real work: set type and priority, clear it into the backlog, where it flows through the ordinary ready/dispatch loop.
  • bh work reject — not a bug, or won't do: close it with a reason the reporter can actually read.
  • bh work reroute — filed against the wrong hive: re-file it into the right one, or bounce it up when it's genuinely ambiguous.
  • bh work promote — too big to simply accept: hand it to the planner, which adopts it into a gated molecule instead of letting it sit as an oversized ticket.
08 · Go deeper

Where the source of truth lives

DocCovers
docs/AGF.mdThe tenets, naming, container branches, dispatch depth, role modes — the process overview.
docs/DESIGN.mdHives, prefixes, labels, identity-over-time, git-native hosting — the why.
docs/WORK.mdEvery bh work verb, refine plans, validation modes, conflict ladder, batches, PR-governed landing.
docs/PLANNING-PLANE.mdThe two gates, fidelity tiers, spike loop, replan vs groom.
docs/CONTROL-PLANE.mdThe four control seats, Head Office partitions, the commissioning loop.
docs/ASSURANCE.mdThe warden, the security:* gate, the verifier lens.
docs/HUB.md · docs/HIVES.mdThe cross-hive aggregate, onboarding, hive kinds and identity.