resolve-problem-report
Resolve a problem report
A report is not a bug and it is not a specification. It is somebody's account of a thing that surprised them, written in their words, usually with a cause already attached and often with numbers in it. Resolve the account and you have fixed whatever the reporter guessed. Resolving the report means finding out which parts of it are true first — and being willing to come back with "two of these three hold, and the third names a thing that does not exist."
The expensive failures here are quiet ones. The described symptom gets patched while the cause stays. The cause is asserted from a code reading when the claim was about production. The reporter's numbers travel into the resolution note unchecked. Three candidates are offered and all three propose doing something, because "this was fixed three weeks ago" is not a satisfying thing to say out loud. And the close rests on a green suite that never covered the surface.
Six gates. Each ends in a named artifact, and each one refuses to open until that artifact exists — not until it looks convincing. The gates run in order, the middle ones delegate to companions that own the work, and the pipeline can correctly terminate at any of them: a question is an outcome, and so is a refutation with no action.