
Beadhive
io.github.beadhivev0.24.1更新於 Oct 9, 2026
Manage cross-repository beads work, hive status, and Beadhive workflows through bh-mcp.
概覽
讓助理透過 bh-mcp 伺服器管理跨儲存庫的 beads 問題追蹤、hive 狀態與 Beadhive 工作流程。
- 功能
- Beadhive(bh)是一個 CLI,用來跨多個儲存庫編排 beads 問題追蹤,每個儲存庫都是自己的 beads 資料庫,稱為 hive,並帶有簡短穩定的前綴。它可以納入儲存庫、讓標籤保持一致、在一個或全部 hive 上執行 bd 與 git 指令,並把所有 hive 彙整成單一的跨儲存庫檢視,即使程式碼未檢出也可以。bh-mcp 伺服器把這些工作、hive 狀態與 Beadhive 工作流程提供給助理。
- 適用情境
- 當助理需要處理分散在多個儲存庫中的 beads 問題追蹤、查看 hive 狀態,或從單一跨儲存庫檢視驅動 Beadhive 工作流程時使用。它適合已經使用 Beadhive CLI 及其慣例的團隊。
- 執行需求
- 以本機程序在使用者機器上執行(僅桌面端,stdio 傳輸),從 PyPI 安裝為 beadhive,並以 uvx 執行。它是 bd、git、git-workspace、dolt 與 docker 之上的輕量編排器,因此這些工具必須存在;建議的受管路徑使用 nix 對它們進行版本固定。設定與執行時狀態位於 ~/.beadhive/ 下。未宣告驗證、環境變數或標頭。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Beadhive,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
Beadhive (bh)
[PyPI version] [Python versions] [GitHub tag] [License: MIT] [GitHits index status] [Ask DeepWiki]
bh is a single CLI for managing beads issue tracking across many repositories. Each
repo is its own beads database (a hive) with a short, stable prefix; bh onboards them,
keeps their labels consistent, runs bd/git across one or all of them, and aggregates
every hive into one cross-repo view — even hives whose code isn't checked out.
It's a thin orchestrator over bd, git, git-workspace, dolt, and docker: bh
encodes the conventions, the registry, validation, and routing. Config and runtime state live
under ~/.beadhive/; no issue data lives there — each hive's issues live in its own Dolt
DB under refs/dolt/data on that repo's own git remote.
bh is the CLI of Beadhive, a bead-machine — a software factory that uses beads.
The process it drives is documented in docs/AGF.md.
This repo is the CLI's source (Python package beadhive on PyPI, command bh). For what
Beadhive is conceptually, rather than how to drive it, see beadhive.ai.
Install
Agents: point your agent at INSTALL.md — the preferred install path. It
carries a structured install: frontmatter block (the agent reads it, discloses the plan,
and asks before each command) plus a prose fallback any agent or human can follow.
Doing it by hand? There are two routes, in this order.
Managed path (recommended)
bh doesn't work alone — it drives bd, dolt, gh and git-workspace. This is the only
route that installs and version-pins all of them with it, from flake.lock:
--force and that third line are both load-bearing, not decoration: unforced, uv tool install no-ops on a machine that already has bh and still exits 0. Measured on macOS
with 0.7.1 installed, it reported "Installed 2 executables: bh, bh-mcp" and bh --version
still said 0.7.1. This step is done when the version is right, not when the install exits 0.
latest is a release channel branch, not a version: CI moves it onto each release's commit
once that release publishes, so this line never carries a version and never needs a release-day
edit. Don't shorten it to github:beadhive/beadhive#default — that resolves the default
branch, which is not the latest release.
The one precondition is nix, which needs root — a system daemon, and an APFS volume on macOS.
INSTALL.md carries the one-time installer, the ~130s
/ 2–3 GB cold cost, the platform limits (macOS: Apple Silicon only) and the nix ≥ 2.30 that
nix profile add needs.
PyPI route (fallback, not recommended)
For machines where you can't install nix, or won't. It works, and it's genuinely one command
— but it installs bh alone, leaving the other four tools to whatever the machine happens
to have, including a bd you then install from HEAD by hand:
See INSTALL.md for what that leaves you to keep
matched by hand, and for the Docker route.
First run — rung 1
One laptop, local-only. From a fresh install to a ready list:
Run bh setup guide to finish setup — a guided, probe-first walk from a bare install to a
configured workspace. It covers the sequence above plus the parts that aren't one command
(orgs, providers, git-workspace), checking each step's state before it acts, so it is also
safe on a machine that is already half-configured. Reach for it if you installed via
brew, pip or a copy-pasted command and never saw INSTALL.md.
What that costs: HQ is local — no backup, and no second machine yet. That's the posture,
not an omission; wiring a remote is rung 2. See docs/ADOPTION.md for the
four rungs, what each buys, and what staying on this one costs.
Agent harnesses
bh furnishes seats for Claude Code (--claude) and OpenCode (--opencode) —
pass either to bh hive onboard <provider>/<org>/<repo>. docs/AGF.md carries the
per-harness support matrix, including what does and
doesn't apply for codex. On Claude Code, the bh claude-plugin vends the seat agent defs
and role skills:
Going further
One line each, and who it's for:
-
docs/MCP-PUBLISHING.md— MCP registry and directory upkeep. -
Context7 — library documentation for agents.
-
docs/ADOPTION.md— it works; what's the next rung? The four rungs, what each buys, and what staying on yours costs. -
INSTALL.md— picking a route. Managed path, PyPI and Docker, and the tradeoffs between them. -
docs/ONBOARDING.md— fresh machine, step by step. Zero to a configured AGF workspace with registered hives. -
docs/UPGRADING.md— moving between versions, or between routes. -
docs/HQ.md— Factory HQ. What it is and what it stores. -
docs/OPERATOR-UI.md— first local operator UI. Start and troubleshoot the loopback-only, unauthenticated, read-only profile. -
docs/COMPLEXITY-ROUTING.md— capability-first dispatch. Complexity labels, late-bound model selection, availability, and migration recovery. -
docs/HIVES.mdand the multi-host ADR — more than one host. Hive kinds, leases, and host roles. -
beadhive.ai — what Beadhive is, conceptually, if you want the shape before the commands.
-
docs/OVERVIEW.md— everything else. Design and reasoning, configuration, the full command surface, component by component.
Questions / feedback
General questions, feedback, and bug reports go through
GitHub Issues. For security vulnerabilities,
see SECURITY.md instead of filing a public issue.
Develop
Developing bh itself
You don't need any of this to use bh — it's for working on the CLI's own source.
just install and just build stamp the artifact with a PEP 440 local
segment — 0.11.5+local.g790ef0d, plus .dirty when the checkout had
uncommitted changes — so bh --version distinguishes your build from the
release it was built from, and the wheel filename says what is under test. PyPI
forbids local segments, so a local build can never be published by accident;
just build-release is the deliberate opt-out that produces a publishable
artifact (and is what CI runs on a v* tag).
See CONTRIBUTING.md for the plain-git contributor path — setup, tests,
and how to submit a change.
Collapsed on purpose, not by oversight. It pairs with "Manual install" on beadhive.ai: both are real content that simply isn't what most readers came for, so it is disclosed rather than deleted. Please leave it closed.
來源:README.md,提交 898aa62
工具
0版本歷史
1- v0.24.1最新Oct 9, 2026

