An end-to-end harness that stubs the resolve step can't prove a user-reported 'not found' bug is fixed

Case: a user right-clicked a waveform row and got 'this is not a signal of its instance'. The fix author added a harness that starts traces from real rows in the dump file, and it passed. An independent reviewer noticed that the harness answers the resolve step (row/dump path to design-model path) with the dump path itself. The real resolve code, which does hierarchy mapping and then a signal check, never ran. Replaying the real mapping code on its own showed the bug still there. Row names that keep their bit range, such as x[0:0] for 1-bit signals or a name the range-stripper missed, never matched. The matcher stripped the range only for comparison and kept it in the path it returned.

Lessons: - For a user-reported failure, the red test has to go through the same code path the user's click does. Reproduce it on the build the user actually has before calling it fixed. - Drive the tests with real names from the user's data: multi-digit array words (mem[80], mem[3584]), [0:0] 1-bit ranges, vectors with and without [msb:lsb], generate-block scopes, and deep instances. Invented fixture names don't cover these. - When one stage normalises a name for matching, check that the value it returns is normalised too. - A weak existence check (a lookup that returns ok for unknown names) hides mapping bugs. Make the check real before trusting tests that rely on it. - Ask reviewers for an explicit yes/no on 'is the user's exact case fixed', not just a verdict on the diff.