Keeping Hive healthy

After reading this page you'll know how your reviews and your Hive edits shape what every future bee does, and which parts of that loop you have to close by hand today.

Quality in, quality out

Every run starts by reading. Before a bee plans anything, it pulls the Space's Hive context (the overview, architecture, and dev-workflow pages, plus recent decision-log entries) and then reads the repo itself. It treats both as ground truth about how your project works.

That means two things teach the swarm: what's written in Hive, and what's merged into the repo. You control both. Merge a sloppy PR and the damage doesn't stop at that PR: the next bee reads the codebase, finds the pattern, and extends it as house style. Approve sloppy work and the swarm learns sloppy.

The product contract cuts both ways: No human writes code. A human always reviews. Since no human writes the code, your review is the only point where quality enters the system.

Review to the human bar

Hold a bee PR to exactly the standard you'd hold a colleague's PR. Reviewing a bee PR covers the mechanics; the behavioural asks are:

• Reject wrong patterns even when they work. "It passes CI and I'm busy" is how a wrong abstraction becomes the reference implementation for the next ten runs.
• Give reasons when you bounce. Your @cube-bees comment is the task for the follow-up run: a vague bounce ("this isn't right") produces a vague fix. A specific one ("assert on the error code, not the message string") produces the fix you wanted. And a written reason is something you can then put in Hive, where it helps every future run instead of one.
• Close rather than steer a fundamentally wrong PR. Runs are cheap; your review time isn't.

What flows to Hive automatically, and what doesn't

Be clear-eyed about the mechanism, because most of it is manual today.

Automatic: the read side. Every run fetches the Space's Hive pages and recent decisions, and can search Hive during planning. Whatever is in Hive shapes every run, immediately, with no extra step. Run outcomes (success, rejected, failed, PR URL, verdict) are also recorded automatically, but to the dashboard's ledger, not to Hive.

Not automatic: the write side. Swarm has best-effort write calls (hive_append, hive_propose_pattern) designed to push durable lessons into Hive at run completion, but the Hive server doesn't implement those tools yet, so those writes soft-fail and nothing lands. Your merge, your bounce-back, and your review comments do not reach Hive on their own.

So today, "training the swarm" is a two-step human job: review well, then write down what the review taught you.

Close the loop by hand

When a bounce-back reveals a rule the bee couldn't have known (a naming convention, a forbidden dependency, a deploy constraint), put it in the Space's pages in Hive: the dev-workflow page for process rules, the architecture page for structural ones, the decision log for choices with rationale. One sentence there is read by every future run; the same point made as a PR comment helps exactly one.

A useful habit: if you've made the same review comment twice on bee PRs for the same project, that's a Hive edit, not a third comment. See how a run uses Hive for exactly where each page lands in a run's context.