Tests pass is a sentence with the evidence erased. I want the actual numbers — how many ran, how many passed, how many were skipped — and the exact command that produced them.
"Tests pass" is one of the least trustworthy sentences an agent can write, and I have started reading it as a yellow flag rather than a green one. It is a summary, and summaries are exactly where the gap between what happened and what is reported opens up. A suite can have failing tests that were quietly skipped, a filter flag left on from earlier debugging that only runs a fifth of the file, or a config change that silently excludes the directory where the actual regression lives — and "tests pass" is true in every one of those cases, because the sentence describes the outcome of whatever ran, not whether what ran was the right thing.
What I ask for instead is the actual numbers: how many tests ran, how many passed, how many failed, how many were skipped, and the exact command that produced those numbers. Something like two thousand, one hundred and forty-two passed, zero failed, is a claim I can check — I can run the same command myself and get the same numbers back, or notice that the count is suspiciously low for a suite I know has more tests in it than that. "Tests pass" gives me nothing to check against. It is a conclusion with the working erased.
The skipped-suite failure mode is the one I have seen most often and trust least, because it produces a report that is technically true and practically useless. A suite with three hundred tests, a dozen of which are marked skip because they were flaky last month and nobody removed the marker, reports "all tests pass" honestly, while quietly not testing the things that were skipped for a reason nobody remembers any more. Nobody wrote that sentence to deceive me — it is simply what the test runner printed, and the agent repeated it faithfully. The count exposes the gap immediately — three hundred tests, two hundred and eighty-eight run, twelve skipped — where the summary sentence hides it completely.
Filtered runs are the second failure mode, and they are worse because they are often accidental rather than deliberate. An agent debugging one failing test adds a filter flag to isolate it, fixes the test, and then reports "tests pass" from the same filtered command without ever widening it back out to the full suite. Every other test in the project is simply absent from that run, and the sentence describing the result does not say so. The count would: one test ran, one passed, and one test passing is obviously not the same claim as a suite passing.
I extend the same standard to build output, not just test suites. "Build succeeded" without the actual build log, or a deploy report that says everything is running without the process list and port that prove it, gets the same scepticism as "tests pass" with no numbers. The pattern is identical: a summary sentence is chosen because it is shorter and sounds more finished than the evidence, and the evidence is exactly the part I need to see, because the summary is generated by the same process I am trying to verify.
None of this is about distrusting agents more than I distrust myself under the same pressure — I have written "should be fine" about my own code plenty of times, meaning I had not actually checked. It is about refusing to let a fluent sentence substitute for a number that can be independently reproduced, because a number I can rerun is a claim I can hold someone to, and a sentence is not. Show the counts, name the command, and let the summary be something I read after I have already seen the evidence, not instead of it.