Client Website QA Punch List: Every Item Verified 3 Times at a Pinned Git Commit Before the Reply Ships
The client sent a numbered fix list. The response that went back had every item re-tested three separate times against the same pinned commit, with verdicts that did not move.
What was getting in the way.
A client reviews a rebuilt site and sends back a numbered punch list. The standard agency reply is a wall of "fixed!" lines written from memory, and the client finds half of them not actually fixed, which costs more trust than the original defects did. Verifying properly is slow: each item needs a live test, the site keeps changing under you while you test, and a claim that was true on Tuesday's build may be false on Thursday's. Nobody re-tests a list three times by hand.
Context
A client partway through a website migration, holding the agency to a written punch list. The pattern applies to any team answering a client QA list: the reply should arrive at forward-ready reliability, or it should not arrive.
How the work runs.
- 01
Pin the commit first.
All verification runs against one git sha, verified unchanged between passes, so every verdict refers to the same build and cannot be drifted out from under.
- 02
Test every numbered item live.
Each fix-list item gets a live check against the published build: page loads, form behavior, redirects, metadata, the actual thing the client complained about.
- 03
Run independent re-verification passes.
The full list was verified three separate times. The third pass produced one measured delta and zero verdict changes, which is what "stable" means in practice.
- 04
Label what is not a PASS honestly.
Final tally: 23 PASS, 1 FAIL that traced to the hosting platform (vendor ticket filed, escalation documented), 2 items needing a client decision, and the untestable-until-launch items flagged as exactly that.
- 05
Deliver in the client's own numbering.
A 13-page response keyed to their item numbers, with annotated review pins tied to each item and a machine-readable appendix, handed to a human for the send decision.
Evidence from the workflow.
Each system has a role.
record of truth (the pinned sha every verdict refers to)
Git
verification surface (live checks per item)
Published site
review pins annotating each verdict on the actual pages
Pastel
action (the 13-page response in the client's numbering plus a machine-readable appendix)
Document pipeline
Why this is Coworker.
Takes assignments and reports back. You hand it work, it prepares and returns a result.
- 01
Verification is read-only against the published build. The pinned sha is recorded so any verdict can be reproduced. The response document is always reviewed and sent by a human; the agent never sends client-facing deliverables itself.
Impact / Outcomes
Every line in the client response was a tested claim at a pinned commit, re-verified across three passes with zero verdict changes on the final pass.
The one genuine FAIL was traced to the hosting platform and escalated with a vendor ticket, instead of being buried in a wall of green.
Items needing client decisions were surfaced as decisions, not silently resolved in the agency's favor.
The response went out in the client's own numbering, so their reviewer could check it against their original list line by line.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.