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