Ticket-to-fix pipeline
Bugflow · BB IDE plugin
One click turns a ticket into a gated, spec-driven agent run that proves the fix red-then-green and stops for a human before anything ships.
Problem
Every bug started with the same manual ritual: a long prompt, attachments copied across, the ticket moved by hand, and no guarantee the agent would diagnose before fixing or keep its hands off the remote.
Constraints
- The tracker is reached only through the engineer's existing CLI login; the plugin stores no credentials.
- Nothing may be committed or pushed before the single human gate.
How it works
- Pick a work item in the panel; the plugin fetches it, moves it to in progress and uploads its attachments.
- A thread is spawned with the pipeline prompt and a per-stage model plan.
- Stage 0 sets up git. Stage 1 diagnoses, consults the knowledge base, then writes the green condition and the allowed scope.
- Stage 2 implements against the spec. Stage 3 is the single human approval gate. Stage 4 prepares the ship notes and never pushes.
- An optional review thread, run by a different model, reads the ship notes.
Decisions
- The check is written before the code and must be red now.
- Earlier fixes are looked up only after a root-cause hypothesis exists, and never copied.
- Each stage can be delegated to the model that fits it.
- The plugin learns project codes from ticket titles to suggest the right repository.
- After three failed corrections the run goes back to the spec, because by then the fault is in the plan.
Trade-offs
- Writing a failing check before the fix costs time on trivial bugs; the pipeline accepts it to rule out unproven fixes.
- One approval gate keeps the human cost to a single review, which then covers the whole change.
Safeguards
- One approval gate, opened only after the check is re-run and its real output pasted.
- Never stages everything, never commits at the gate, never pushes.
- Allowed scope is enforced by a hook; the agent asks instead of widening it.
- The plugin holds no credentials: tracker access goes through the user's existing login.
Limits
- It talks to one work-item tracker through its CLI; another tracker needs a new adapter.
In numbers
- 5 stages plus 3 sub-stages
- 5 flow types
- 99 tests
- About 3,770 lines including two skills