Scenario · The bigger jobs
Is this ticket actually done?
“Is this ticket actually done?” The check between closing a ticket and trusting that it's clean.
A ticket gets marked done because the work happened, not because anyone actually re-checked that it landed clean — and that gap is where the same problem quietly reopens a week later. This takes a completed ticket, runs the specific checks that actually fit what it was about, and returns one clear verdict alongside the written procedure for that kind of work, so closing it out is a decision made on real evidence rather than on trust that the work was done right.
What to ask for
See it work
A real run of Ticket QA orchestrator:
Ticket QA orchestrator · ticket-qa-orchestrator — Content edit
domain: toolkit-tests.pages.dev
category: Page(s) - Add/Edit/Remove Content
procedure: scenarios/copy-needs-changing.md
[REVIEW] Smoke test (critical-path-smoke-test) <n>ms
[INFO] Stack fingerprint (wordpress-inspector) <n>ms
[FAIL] Content quality (content-quality) <n>ms
[REVIEW] Spelling (spelling-check) <n>ms
[FAIL] Broken links (link-and-image-checker) <n>ms
Verdict: FAIL — needs review
5 check(s) ran — 2 FAIL · 2 REVIEW · 1 INFOSeen in the wild
Signed off as done. 15 contrast failures still live.
Ticket #12628closed
Update a bio on the “meet the team” page
QA Done — all items have been checked and verified.
What the re-check pulled back
| Contrast failures | 15 |
|---|---|
| Links with no name | 1 |
| Pinch-zoom | disabled |
| Largest paint | poor |
| Verdict | FAIL |
What that means on a medical site
- Text unreadable in 15 separate placesADA risk
- A link a screen reader cannot nameADA risk
- Zoom blocked for low-vision usersADA risk
- Main content is slow to appear at allSpeed
Nobody was careless. The person checked the thing they were asked to change, and the bio was correct. What they had no way to check was whether the page was still healthy — and three of those four are accessibility-exposure items, not cosmetic ones.
Seen in the wild
The page URL on this QA card returns 404.
Card 123234978547 · Ready for QA
A new breast-augmentation procedure page
The developer marked this one finished yesterday and moved it into the QA lane, where it is now waiting for a specialist to open the link and check the work. Before that happens, the link itself was fetched.
What the check pulled back
| Page URL on the card | 404 |
|---|---|
| With www | 404 |
| With a trailing slash | 404 |
| The home page | 200 |
| URLs the site publishes | 101 |
| Matching this one | none |
Every page on that site ends in .php; the address on the card has no extension. The site map was read in full and holds no page for this procedure at any path.
What a person is about to walk into
- The page the card points to 404sBroken
- Not in the site map, at any pathNot found
- The row names a different domainData
- Nobody has opened the link yetUnseen
The honest reading: this is most likely built somewhere that is not live yet, or the address was typed from a staging path. Both are ordinary. What is not ordinary is that a row can sit in a queue overnight in a state where nobody — the developer who moved it, the specialist about to pick it up, or the strategist watching the board — knows which of the two it is.
Seen in the wild
The same head-tag defect on 6 of 13 completed pages.
Board3 · Completed
The twenty most recently completed cards
The previous issues each took one card. This one takes the last twenty to reach Completed and runs the same check across all of them at once — because a defect that shows up on one page is somebody’s afternoon, and the same defect on six is a template.
What the batch returned
| Cards checked | 20 |
|---|---|
| Pages actually read | 13 |
| Blocked by bot protection | 7 |
| Clean | 4 |
| Worth a look | 9 |
| Two <head> tags | 6 |
| Two <h1> tags | 3 |
The seven that could not be read are reported as unknown, not as passes. They sit behind a bot challenge that answers an automated request with a 403, which is a finding about our own access, not about those pages.
What repeats across the batch
- 6 of 13 pages ship two head tagsConfig
- Three of them declare two H1 tagsSearch
- The same defect, different clientsConfig
- Seven could not be fetched at allUnseen
A second <head> is invalid markup that browsers quietly recover from, so it is invisible to anyone checking the page by eye. It matters because anything that injects into “the head” — a tag manager, an SEO plugin, a page builder — can end up writing into the wrong one, and because the tools that read a page for a search engine have to guess which one counts.
The gap this closes: a ticket gets marked done because the work was performed, not because anyone re-checked that it landed clean. This is the bridge between those two — point it at a completed ticket’s category (or the ticket itself, read from the helpdesk), and it runs the checks that category actually needs.
- Give the ticket checker the ticket’s category and target domain — or the ticket itself, if it’s available from the helpdesk directly, which also gives it the subject and customer for the report.
- Read the single verdict together with the specific checks it ran for that category. Every route also names the written procedure for that category, if one exists — read that too; a clean set of checks is not the same as having followed the procedure.
- [manual] Compare the result against what the ticket actually asked for. A clean technical verdict cannot prove the original request was understood correctly — only a person reading both can catch that.
- [manual] Mark the ticket done only once satisfied, or reopen it naming the specific failed or missing evidence — never “looks fine,” always the specific row that didn’t pass.
The verdict and the procedure are two different proofs
Passing checks proves the site is in a good state now. It does not prove the procedure for that kind of ticket was actually followed — the disposition table got built, the approval happened, the right person signed off. Both are worth having; neither substitutes for the other.
What this does not cover
What the ticket meant. It routes to the checks that fit the ticket's category and returns one verdict; it cannot read intent, so a ticket that asked for the wrong thing, or was misfiled under the wrong category, can still come back clean. 8 of the desk's 52 live categories are deliberately unrouted — catch-alls like "Client Question," or work that isn't website-facing at all.