A neat list of issues is not enough for me. I wanted provenance. I wanted to know where the result came from, what checked it, what evidence was captured, and whether I was looking at engine output, a product rule, a runtime check, manual review guidance, or optional AI help.
That is why the contracts in the project matter so much. The command reference includes the result envelope, source attribution contract, trust classification contract, and evidence bundle export shape. Those pieces are dry on paper, but they are doing serious work.
Without that structure, handoff gets sloppy very quickly. Engineers question the findings, QA cannot reproduce them cleanly, and managers treat every issue as if it is equally proven. Once the seams are visible, the output becomes much harder to misread.
I think this is one of the more revealing parts of the project. It shows that I was not trying to make the product look clever. I was trying to make it accountable.
Documentation trail
TECHNICAL_GUIDE.mdCOMMAND_REFERENCE.md
