Beadhive

io.github.beadhivev0.24.1更新於 Oct 9, 2026

Manage cross-repository beads work, hive status, and Beadhive workflows through bh-mcp.

概覽

AI 產生的概覽

讓助理透過 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/ 下。未宣告驗證、環境變數或標頭。
安裝前請注意
它會驅動 bd、git、dolt、docker 與 gh,因此可能跨儲存庫執行指令並變更資料;README 指出受管安裝需要帶 root 的 nix,在 macOS 上還需要 APFS 卷宗,而 PyPI 路徑只安裝 bh,其餘工具取決於機器上已有的版本。README 也警告,未加 --force 的 uv tool install 可能什麼都不做卻仍以 0 結束,因此應核對版本,而不是相信結束碼。

安裝

在 SourceWeft 中

  1. 開啟 儀表板中的 Beadhive,將其新增到工作區。
  2. 為需要使用其工具的對話啟用該服務。

Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。

其他 MCP 客戶端

參照 儲存庫 中的啟動說明。

README

Beadhive (bh)

[Ship software, not slop.]

[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:

sh
nix profile add github:beadhive/beadhive/latest#default       # bd, dolt, gh, git-workspace, git, uv, justuv tool install --force 'beadhive[otel]'                      # bh itself (uv came from the line above)bh --version                                                  # must print the released version

--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:

sh
uv tool install --force 'beadhive[otel]'   # or: pipx install --force 'beadhive[otel]'brew install beadhive/tap/beadhive         # Homebrew — slower, builds native deps from sourcebh --version                               # same check, and for the same reasonbh setup check                             # reports which of the four tools you're missing

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:

sh
bh config init                              # scaffold ~/.beadhivebh mcp install                              # Claude Code: claude mcp add bh --scope userbh hq init                                  # local-only HQ; no remote wired, deliberatelybh hive onboard <provider>/<org>/<repo>     # zero-footprint by defaultbh work ready

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:

sh
claude plugin marketplace add beadhive/claude-pluginclaude plugin install bh@beadhive

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.md and 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.

sh
# On a NEW machine you do not have `just` yet — it is pinned in .mise.toml, not the Brewfile:brew bundle --file=Brewfile     # provides misemise exec -- just bootstrap     # mise installs the pinned just, then runs bootstrap
just bootstrap   # brew bundle + mise install + uv sync   (once per machine; needs just)just install     # build + install this checkout → ~/.local/bin/bhjust lint        # ruff checkjust fmt         # ruff formatjust test        # pytestjust build       # wheel + sdist into dist/  (stamped local)

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
  1. v0.24.1最新Oct 9, 2026