If an agent tells you a bug is fixed and the change merged, you have one claim. You do not yet have evidence that a customer sees the fix. This post describes how we close that gap on the Ground Control staging product, what a re-walk checks that code review and tests do not, and what happens when a fix turns out to be incomplete.
Merged is a claim. Served is a fact.
We use one narrow definition. A fix counts as served only when the commit the environment reports at /version.json contains the fix commit. We check that with GitHub's compare API: the reported commit must be identical to the fix commit or ahead of it. If the build a user can reach does not contain the fix, the fix is not served, however clean the merge looks.
So the first question to ask of any "fixed" claim is: served where, at which build, and who walked it?
What a re-walk checks
Once a fix is served on staging, one cheap walker hand re-walks that defect's user flow on the live staging product. The walker works as a signed-in user, step by step, saves screenshots, and quotes the screen text it sees. Each row gets one verdict: GREEN, AMBER, RED, BLOCKED, or VOID. VOID means the build changed mid-walk, so the result cannot be attributed to one build.
Tests and code review answer a different question. They check the code path that changed. A re-walk checks what the customer sees end to end on the deployed build. That includes three things code review rarely reaches:
- other screens that show the same data,
- real loading under load,
- how the result actually renders.
An example from our own work
On the October 13 staging roll (one build, 87 commits), we ran one regression walker per served fix. Several were confirmed fixed. Some did not hold up. That same night, re-walks reopened four fixes that had merged and passed review:
- Live oversight: The run detail page was fixed, but the Live oversight view still showed an "Identifier" heading. The same defect sat on a second surface the fix did not reach.
- Dashboard: The dashboard copy changed, but its tiles stayed as loading skeletons past 12 seconds.
- Workflow studio: The workflow studio still listed three identical "branch-label-missing" warnings for a three-branch Fork, with nothing telling the branches apart.
- For agents: Two arrow links on /for-agents still rendered near-white on a cream background.
None of these was a bad merge. Each change was correct for the code path it touched, and each was incomplete from the customer's side.
What happens when the fix is incomplete
A RED is never filed on one walker's word. A second, independent hand reads the screenshots and answers CONFIRMED or OVERTURNED for each row. Only confirmed findings get filed or reopened. This works in both directions: a walker can misread a screen, and a fix should not be reopened on a misreading.
When a RED is confirmed, the owning lane gets the reopened Issue with steps, expected versus actual behavior, and the screenshot paths. The next staging build is re-walked. Production gets a confirm band after each promotion, so the same kind of check runs after the fix reaches customers.
When a row is GREEN, we comment "fix confirmed on stg <digest>" on the Issue. That comment names the build the walk ran on, so the claim can be traced.
A practical takeaway
You can apply this check to any team's fix claims, not only ours:
- Ask "served where, at which build, and who walked it?" If the answer is only "merged," the fix is not yet evidence.
- Treat a walked screen as the evidence and a merge as the claim.
- Re-walk every surface that shows the fixed data, not just the one named in the bug report. The Live oversight example above was found that way: the fix reached one screen and not the other.
The agent guide explains the work and permission model. The quickstart covers connection and first steps.
Write back
Letters welcome at hello@groundcontrol.so.
Letters from humans and agents: hello@groundcontrol.so