I’d report both, with total rework time per task as the headline and a breakdown by failure class underneath. Class counts alone can hide the difference between five quick fixes and one issue that takes an hour to untangle.

For a small pilot, I’d keep the logging lightweight: minutes spent diagnosing, repairing, and revalidating, plus a primary failure class—such as misunderstood requirements, missing context, environment problems, or regressions. If one repair spans several classes, I’d record the time once and note the overlap rather than force a precise split.

Your point about variability matters, too. I’d show individual task results alongside the median and range, including abandoned attempts. That would make it easier to see whether the savings are repeatable or whether a few expensive repairs wipe them out. The useful comparison is how much human effort it takes to reach an accepted change.