Procedure for proving that a claimed defect fix actually reached the build under test and actually works. Covers the merge-base ancestry check that proves the running build contains the fix commit rather than trusting a version label, the priority order for choosing which reproduction to re-run, and the VERIFIED / NOT FIXED / BLOCKED verdict table whose governing rule is that any ambiguous, flaky, or unreproducible result resolves to BLOCKED and is never guessed. Scoped to ISTQB confirmation testing (does this specific fix work?), not regression testing (did the fix break something else?), and not triage or severity assignment. Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.
99
94%
Does it follow best practices?
Impact
100%
1.03xAverage score across 10 eval scenarios
Passed
No findings from the security scan
{
"context": "Everything that usually justifies closing is present: the build demonstrably contains the fix, the spec written for this exact defect was run against that build, and CI reports exit code 0. The predicted unaided answer moves the ticket to Verified on the strength of 'the defect's own test passed on the fix build'. What that misses is that the spec has been quarantined since June with a 62% pass rate, is retried three times, and needed attempt 2 in this very run after attempt 1 timed out - so its green result is uncorrelated with whether the fix works, and would have appeared with or without c0b8f31. There is no other usable artifact today, so the honest output refuses to decide and names both routes to real evidence.",
"type": "weighted_checklist",
"checklist": [
{
"name": "Record delivered",
"description": "A file qa-record/BUG-2870.md exists and states a decision. Scores zero if absent.",
"max_score": 4
},
{
"name": "MUST NOT accept the retried, quarantined pass as confirmation",
"description": "MUST NOT. The record must not treat job 9931's green result as evidence the defect is fixed. Reporting Verified on that basis scores zero. Full marks require the rejection to be explicit and reasoned: the spec is quarantined, retried, and a pass under retry says nothing about the fix.",
"max_score": 30
},
{
"name": "Cites the specific flakiness facts, not a general caution",
"description": "The record names concrete evidence from the fixtures - attempt 1 failed with a 30s timeout before attempt 2 passed, the spec has been quarantined since 2026-06-02, its 30-day pass rate is 0.62, and it is excluded from the required check. Two or more of these earn full marks; a generic 'the test is flaky so I am not sure' with no specifics scores at most half.",
"max_score": 18
},
{
"name": "Refuses to move the defect to Verified and leaves it where it is",
"description": "The decision is that the defect cannot move on the current evidence and stays in Fixed. Recommending Verified scores zero. Recommending a reopen or 'not fixed' also scores zero - nothing observed suggests the fix is wrong, only that the evidence is worthless.",
"max_score": 20
},
{
"name": "Gives the concrete action that would produce usable evidence",
"description": "The record names at least one specific route out: stabilise the spec and run it once without retries against build a4d0c92, or have someone with staging access walk the ticket's three written steps and attach the verbatim outcome. Full marks for a route stated concretely enough to hand to a named owner. 'Needs more investigation' or 'wait for the next nightly' scores zero.",
"max_score": 18
},
{
"name": "Does not substitute the unit tests for the reproduction",
"description": "tests/filterCounts.test.js is not offered as the confirming artifact. Those tests predate the fix, exercise recount directly rather than the deselect sequence the defect describes, and their green state is not a before-and-after. Citing them as evidence the defect is fixed scores zero.",
"max_score": 12
},
{
"name": "States that the build containment question is settled",
"description": "The record records that build a4d0c92 does contain c0b8f31, so the blocker is the quality of the reproduction and not a deployment gap. Blaming the deployment, or omitting the containment result entirely, scores zero.",
"max_score": 10
},
{
"name": "Leaves the quarantine configuration untouched",
"description": "ci/quarantine.json is unmodified and the record does not present de-quarantining as something already done. Editing it, or claiming the spec is now stable without any stabilisation work, scores zero.",
"max_score": 6
}
]
}