Skip to content
hiveDOCS
GITHUB ↗v1.0.0-rc.1
Ask Beenot connected

Bee will answer questions from these docs once it has a backend that can answer honestly. It isn't connected yet, so nothing you type here goes anywhere.

integration point
ASK_BEE_ENDPOINT = unset
MEANWHILE
Hand the docs to your own agent

Help me understand and set up Hive. Read https://hive.admir-saheta.com/agent-guide.md first, then walk me through it step by step.

RFC 0001: The Roadmap After 1.0.10

The proposed roadmap after the 1.0 train, open for comment.

  • Status: Proposed. Open for comment; the council decides after the discussion period (process).
  • Authors: the maintainers
  • Discussion: the pull request that adds this file
  • Affects: ROADMAP.md

Summary

The 1.0 train (M10 to M19) added the plugin store, images, Windows, observers, the web and mobile observers, local discovery and the desktop app. M19 then reviewed it for release quality. This RFC proposes the 1.x train, eleven milestones (M20 to M30), one minor release each, now written out in ROADMAP.md:

Milestone Release Theme
M20 Trusted Distribution v1.1.0 Verified installs, provenance, release gates, official plugins
M21 Desktop App 1.0 v1.2.0 Signed packages, verified in-app updates, native performance
M22 Parallel Agent Orchestration v1.3.0 Tasks and plans with dependencies, limits, results and approvals
M23 Git-Native Development v1.4.0 Branch lifecycle, conflicts, review, validation gates
M24 Workflow Automation v1.5.0 Triggered, deterministic, restart-safe workflows; CI mode
M25 Agent Insights v1.6.0 Time in state, reported usage and budgets, local only
M26 Plugin Ecosystem 2 v1.7.0 Registry schema 2, isolation by default, pane views, publishing
M27 Team Collaboration v1.8.0 Roles, shared workspaces, audit, over ssh
M28 Runtime Fleet Management v1.9.0 Inventory, rolling upgrades, policies, 50 machines
M29 Hosted Foundations v1.10.0 An optional control plane, in private beta
M30 1.x LTS and the Road to 2.0 v1.11.0 An LTS release, the 2.0 RFC, hive migrate

First, close the gaps 1.0 left open (M20, M21). Then the agent workflows the runtime is built for (M22 to M25), then the ecosystem (M26), then working with others and more machines (M27 to M29), and last the road to 2.0 (M30).

We are asking for comment on the order, on what is missing, and on the open questions at the end.

What we observed

Hive sends no telemetry, so this is what can be seen without it:

  • Releases. Only v1.0.0-rc.1 is tagged. M10 to M18 are on main untagged, so users of the stable channel have no 1.0 release yet. This is the largest gap between the roadmap and what users can install.
  • Plugins. The registry lists two official plugins. Their release tags share hive’s tag namespace, and the official catalog is not seeded with installable releases (M10’s open items).
  • The desktop app works and is tested, but its packages are not signed, and it has no in-app update or measured latency in the native webviews (M18’s open items).
  • Reliability. The nightly soaks, budgets and fuzzing pass. The 72-hour chaos gate and a cross-user connection test need a self-hosted runner, which does not exist yet.
  • Security. The M19 review fixed ten findings and left six open items (docs/security-review.md).

Proposal

Each milestone’s scope and acceptance criteria are in ROADMAP.md. Why this order:

  1. Tag the train first. Cut v1.0.10 from main as the first stable 1.0 release, once M19’s release checklist (GOVERNANCE.md) passes. Users on v1.0.0-rc.1 upgrade straight to it; the upgrade test covers that path.
  2. Trust before features (M20, M21). The gaps the review found, an unverified first install, release gates without hardware, official plugins in hive’s tag namespace and an unsigned desktop app, are what stands between Hive and users who cannot afford surprises.
  3. The core job next (M22 to M25). Hive exists to run many agents. Orchestration, Git-native work, workflows and insight into time and cost build directly on what agents already use (agent start --worktree, prompt --wait, MCP, events). Each adds wire API, so each starts with its own RFC.
  4. The ecosystem when there is more to extend (M26). Plugin views, workflow steps and forges need M22 to M24 to exist first. Isolation by default answers the review’s plugin findings.
  5. Others and more machines last (M27 to M29). Team, fleet and hosted features need demand to justify them. Each is local-first, and the hosted service is optional and in private beta.
  6. A calm 2.0 (M30). An LTS release to stay on, every removal announced ahead, and a tool that says what a setup must change.

Not proposed

  • No breaking changes in 1.x. Nothing is removed before 2.0.
  • No telemetry. Agent insights (M25) stay on the machine, and any usage data would need an RFC of its own, and opt-in.

Compatibility

Everything proposed is additive until 2.0. The task model (M22), branch lifecycle (M23), workflows (M24), insights (M25), registry schema 2 and plugin API 2 (M26), roles (M27) and policies (M28) each need their own RFC. A registry schema change in particular must keep releases before 1.0.10, which reject unknown catalog fields, working (see docs/compatibility.md).

Open questions

  1. Tagging. Should the train be released as v1.0.10 directly (the proposal, matching the roadmap’s labels and these docs), or as v1.0.0 with the milestones following as patches?
  2. Order. Is orchestration (M22) or Git-native work (M23) more useful first? Should agent insights (M25) come earlier?
  3. Scope. Is the hosted service (M29) wanted at all, or should the train end with fleet management?
  4. What is missing? Which problems running agents with Hive are not on this list? Plugin authors: what does plugin API 1 lack?
  5. Windows arm64. Is it wanted enough to add once CI can run it?

Decision

Pending the discussion.