How Gallabox guards a nine-stage Linear pipeline
Gallabox ships a WhatsApp messaging platform to customers who notice breakage immediately, so their Linear workflow is deliberate: Dev Complete → Testing Inprogress → Bug Fixing → QA Signoff → Ready for stage → Moved to Staging → Staging Signoff → Moved to Production → Done.
Nine states, written down and agreed. And, before LineGuard, routinely skipped.
The skip that actually happens
Nobody sets out to bypass QA. What happens is smaller: an issue is finished, the author knows it is fine, and Linear’s status dropdown puts Done a few rows below Dev Complete. One click and the issue has jumped six states.
Nothing about that looks wrong at the time. It shows up later, as a staging deploy containing work nobody signed off, or a cycle report where half the issues have no QA record.
Gallabox’s answer is nine rules, one per boundary.
One rule, read out loud
Trigger — Issue leaves state Dev Complete. Conditions — the new state is Bug Fixing, or QA Signoff, or Ready for stage, or Moved to Staging, or Staging Signoff, or Moved to Production, or Done. Actions — revert, and comment saying why.
Notice what is not in that list: Testing Inprogress, the one legal destination. The rule enumerates every illegal one instead, which is more typing but says something the inverse doesn’t — these are the seven shortcuts people actually take, and each is a line you can delete when it stops being true.
What thirty days looked like
Nine rules active, 1,200 triggers fired, 202 corrected — 17% of runs. The interesting part is how unevenly those 202 are spread:
| Rule | Ran | Guarded |
|---|---|---|
| Dev Complete → Testing Inprogress | 149 | 65 |
| Moved to Staging → Staging Signoff | 174 | 41 |
| QA Signoff → Ready for stage | 98 | 38 |
| Testing Inprogress → Bug Fixing / QA Signoff | 72 | 13 |
| Ready for stage → Moved to Staging | 58 | 6 |
| Bug Fixing → QA Signoff | 22 | 6 |
| Staging Signoff → Moved to Production | 119 | 1 |
Read the top and bottom rows together. The Dev Complete gate corrects 44% of the transitions it sees — the boundary the team genuinely struggles to hold, and the one where a skip does the most damage, because everything downstream of it is the verification being skipped. The Staging Signoff gate corrected one transition in 119. By the time work has survived seven states, nobody is cutting corners.
Same design, same effort to write; one is load-bearing, the other nearly decoration. No amount of process discussion would have sorted them. Six weeks of counting did.
One rule also shows an action failure, flagged in red — LineGuard reporting that a correction it attempted did not land. That belongs on the dashboard next to the successes, for the same reason the counts do: a guard you cannot see failing is a guard you are trusting on faith.
What transfers
Enumerate the illegal destinations, not the legal one. Each condition is a shortcut someone took, and pruning the list over time keeps the ruleset honest about the process rather than the aspiration.
Expect an uneven distribution, and leave the quiet rules alone. A rule that guards once in 119 runs costs nothing, and its silence is the evidence that the late stages hold — which is only interesting because the early ones so visibly don’t.
The shorter argument for why this is transition rules and not required fields is in the previous post, and required fields for Linear sets out what Linear enforces without any of this.