Run evidence
Failures with names
Failed tasks, parsed test results, reports and bounded log tails arrive as structured evidence.
Self-healing CI
A red check can become a reviewed fix.
When an eligible check fails, Hive can wake a scoped coding agent with the run, logs, diff and test evidence already attached. The candidate returns on your branch and the next gate decides whether it worked.
Autofix is opt-in per check. Infrastructure failures and timeouts do not spend an agent run.
hive — run #4821, and why it failed
Run #4821, red: the failing step, the three named tests, and the dependency graph behind it.
Captured from the committed fixture set, not from production
- Trigger
- Eligible failed checks
- Delivery
- A candidate on your branch
- Authority
- Your next CI gate
The repair loop
Failure evidence travels with the work.
No log-pasting ritual and no detached chat. The run, the agent and the verifying gate are one traceable chain.
- 01 · Detect
A declared check fails
Hive classifies what failed and materializes a fixer only when that step opted in and policy allows it.
- 02 · Diagnose
The evidence is already there
The agent reads the failing task, bounded logs, named tests, the branch diff and prior verified fixes directly.
- 03 · Repair
A candidate is produced
The agent edits in an isolated workspace. The wrapper owns scope, budgets, verification and git delivery.
- 04 · Prove
The branch gate runs again
The pushed candidate triggers a fresh run. That run—not the agent’s prose—is the merge gate.
The opt-in, in code
A fixer is a step you declare. Nothing wakes one by default.
Two lines in the pipeline file, and they are the whole contract.
fix_step names a dormant agent step; on_failure attaches it to exactly one target. A step without on_failure never wakes an agent, and a pipeline with no fixer declared has no autofix — there is nothing to disable.
The fixer must exist, repair one task, and have no dependencies of its own. The pipeline language rejects anything else at evaluation, before a run is created.
.hive/main.starstarlark
fixer = fix_step(target = "test") # @hive//factory.star (agent, dormant)hive.pipeline(name = "pr-checks", on = [hive.on.pull_request(branches=["main"])], steps = [ hive.step(name = "test", image = CI, run = "go test ./...", on_failure = fixer), fixer, ])One repair, end to end
Three beats, one branch, nothing merged by the agent.
The same run the hero shows, followed through — captured from the committed fixture set, so it is a designed story rather than a customer’s branch.
01Run #4821 fails on test-2 with three named tests; the diagnosis panel says which and why.
02The fixer regenerates the stale order fixtures, re-runs pytest to 1262 passing, pushes, and opens a pull request with the root cause.
03The push triggers a fresh run on the branch head. That run — not the agent’s summary — is what turns the check green, and your merge policy still decides.
hive — run #4821, and why it failed
01Run #4821 fails on test-2 with three named tests; the diagnosis panel says which and why.
Captured from the committed fixture set, not from production
hive — the agent that fixed it
02The fixer regenerates the stale order fixtures, re-runs pytest to 1262 passing, pushes, and opens a pull request with the root cause.
Captured from the committed fixture set, not from production
Agent context
Give the model evidence, not a wall of text.
Hive compiles a bounded task brief from facts it already owns, then exposes narrow tools for the evidence the agent needs next.
Change evidence
The exact branch delta
The triggering SHA and diff keep the agent on the failure that actually happened.
Prior evidence
Verified fixes, not folklore
Similar prior outcomes are surfaced only when a later gate proved them green.
Narrow tools
Calls instead of copied pages
The agent can inspect the current run and selected checks through reviewed capabilities.
Policy
Budgets outside the prompt
Turn, token, scope and delivery rules are enforced by the wrapper the model cannot rewrite.
Verification
Evidence before delivery
A candidate must satisfy the lane’s configured verifier before the wrapper can ship it.
Control stays explicit
Self-healing does not mean self-authorizing.
The automation acts inside boundaries your pipeline and platform policy declare.
Opt-in
You choose which checks wake an agent.
A new step has no fixer by default. Runtime policy can suppress a misbehaving fixer without changing the pipeline.
Fail closed
The candidate still has to pass CI.
If the fixer fails, exceeds its bounds or cannot verify its work, the original failure stands.
Review
The normal branch workflow remains.
Hive pushes a candidate to the branch. Your required checks, review rules and merge policy stay authoritative.
Boundaries
What a fixer will not do.
Each line is a rule the wrapper enforces, not a promise the model is asked to keep.
- No opt-in, no fixer
- A step without on_failure never wakes an agent. The default for every new step and pipeline is no autofix, with nothing to switch off.
- Infrastructure
- Timeouts, runner loss and classified infrastructure failures never wake a fixer. Only a failure that looks like code work does.
- Its own commit
- A fixer’s push never wakes another fixer, so a wrong candidate cannot start a loop.
- Budget and persistent red
- Turn and token budgets are enforced outside the prompt, and a step that stays red across candidates stops spending agent runs.
- Operator override
- Runtime autofix policy can suppress a misbehaving fixer without a pipeline change, and re-enable it the same way.
Keep exploring
The repair loop is one lane in a larger agent system.
Private beta
Bring one repository. See the whole system work.
Start on your own runner, keep your existing CI beside it, and watch Hive turn the next eligible red check into a reviewable fix.