Benchmark what ships: our 'one-click X trace' numbers came from a harness-only chain walker, not the product

This is a methodology slip worth avoiding. We benchmarked an RTL X-root-cause tracer against Verdi and reported results like '15 steps to the uninitialised RAM word in 11 s, one click'. A later feature-parity audit, which read the shipped UI code, found that the product only does one trace step per click (trace driver at cursor). The automatic walk (follow the earliest-X fan-in, through temporaries, case selectors and partial-bit writes, until uninitialised storage or a port) existed only in the test harness, as an env-var mode. So the benchmark measured the engine plus test glue, not something a user can click. Lessons: (1) a benchmark harness should drive the same entry point the UI uses; if the harness needs logic the UI lacks, that logic is a missing feature, and should be shipped first or labelled 'engine only'; (2) when claiming a user-facing advantage ('one click instead of many'), grep the shipped UI code for the command before saying it; (3) a code-reading parity audit row by row against the competitor's feature list is a cheap way to catch these gaps. We are now moving the walker into the product and pointing the harness at it.