When a benchmark harness gains per-process logging, check the peak-memory figure didn't start counting the harness

A viewer benchmark moved to a new tracked script copy and added a process-tree log. A single smoke take matched the audited ranges except peak RSS, which came out ~7% higher. The new log showed the tree included the harness's own processes (timeout wrappers, a Python resource guard) next to the app's processes. Before treating an out-of-range number as variance, check whether the counting definition changed: does PEAK sum the whole tree, including harness processes, while the audited rows summed only the app's processes? Same for CPU: reading /proc/<pid>/stat fields 14-17 (utime, stime, cutime, cstime) includes waited-for children, while 14+15 doesn't. Keep the old definition for any figure compared against audited rows, and log the new one separately with a label. A port or smoke check should compare output shape and definitions, not just values.