Why a Finished Run Refuses Your Edits
Completing a test run locks it — 409, no edits of any kind. But the lock has deliberate holes: notes, evidence and defects stay open, because triaging a red run is exactly what those are for.
Someone spots a typo in last month’s run. One case is marked Blocked that should have been Failed — an honest slip, made at 6pm on a release night, and it’s been sitting in the record ever since.
They open the run and change it. The server returns 409 and refuses.
That refusal is the whole feature. What took actual thought wasn’t building the lock — it was deciding precisely what it should refuse, because a lock that refuses everything turns out to be almost as bad as no lock at all.
Completion is a state, not a label
In a lot of tools, “completed” is decoration. It moves the run into a different list, greys the row, and changes nothing about what you can do to it. The data stays exactly as editable as it was an hour ago.
That makes the completion date meaningless. If the results can move afterwards, then “completed on the 14th” tells you when someone clicked a button, not when the testing stopped. Every downstream artefact — the sign-off, the release verdict, the audit answer — is resting on a claim the system isn’t holding up.
If the record can still change, the date it was finished is trivia.
So in Hawzu, completing a run flips a state the write path actually checks. The endpoints that record results — final status, step status — refuse outright once that state is set. Not a hidden button. A refusal, from the server, with a reason you can read.
The lock has deliberate holes
Here’s where it stops being simple.
The first version of a lock like this locks everything, because that’s the obvious reading of “finished”. And it’s wrong, in a way you find out about within a week: a run finishes red, and now the team needs to work out why. They need to attach a screenshot someone took. Add a note about the environment. Raise a defect. Reassign the follow-up.
None of those change what happened. All of them were blocked.
- Final status
- Step status
- Notes
- Evidence
- Defect links
- Assignment
- Time spent
So the lock is scoped to the thing that actually needs protecting — the verdict — and explicitly leaves open the parts that exist to make sense of it. Assignment, notes, evidence, defect links and time-spent all stay writable after completion. Triaging a red run is exactly what those fields are for, and a run being finished is precisely when triage starts.
That’s the distinction worth stealing even if you never use Hawzu: lock the claim, not the conversation about the claim. The result is a fact about the past. The discussion is ongoing work.
Automated runs are locked harder, for a different reason
There’s a second lock, and it’s stricter.
When a run’s results come from a CI pipeline, the results endpoints refuse human edits regardless of whether the run is complete. Not because the run is finished — because the results aren’t yours to write. An automated run’s results belong to its pipeline. If a person can overwrite them, the run stops being a record of what the build did and becomes a record of what someone thought the build should have done.
The comment in that guard makes the point better than the guard does:
This is the part teams tend to get wrong. Disabling a button is a courtesy to the person in front of the screen. It isn’t a rule. Anything that matters has to be refused by the server, or it isn’t refused at all.
And the same exemptions apply: on an automated run you still can’t touch the verdicts, but notes, evidence, defects and assignment stay open — because a red CI run is the single most likely thing in the product to need triage.
A lock you can’t open is damage, not safety
The last decision is the one that keeps this from being obnoxious.
Completion is reversible. A run can be resumed, which flips the state back and makes it editable again. That typo can be fixed — deliberately, by someone who had to reopen the run to do it, leaving a trace that it happened.
This matters more than it sounds. An irreversible lock doesn’t stop mistakes from entering the record; it just guarantees they stay there. What you want isn’t “nothing can ever change” — it’s “nothing changes casually”. The friction is the feature, not the refusal.
Resuming does one more thing, and it’s the detail that shows the locks aren’t independent: it deletes the frozen defect snapshot the run took when it completed. If the run is open again, the numbers are live again, and a snapshot claiming to be the state at sign-off would be lying about a sign-off that’s been withdrawn.
What the lock is really protecting
None of this is about preventing fraud. Nobody is maliciously editing test results. The realistic failure is much duller: an honest correction, made months later, with the best intentions, that quietly changes what a release was signed off against.
A run’s value is that it’s a record of a specific afternoon. That value doesn’t survive the record staying editable forever — which is the same reason the run holds a frozen copy of the test case rather than pointing at it. The copy stops the case from drifting underneath the verdict. The lock stops the verdict from drifting on its own.
Lock the claim. Leave the conversation about the claim wide open.
What changes when a run completes
