- ROOT CAUSE: classify_fail took errs[-1], and make prints its own summary
`make: *** [Makefile:N: build/src/<ov>/<tu>.o] Error N` LAST, always — so the wrapper won
every time and the label carried only the TU name the record already stores. Each CC1-FAIL
therefore cost a manual splice-and-rebuild to learn what cc1 actually said (3x in S42 alone).
- MEASURED (R37, over the committed .classified.txt corpus): ~3,000 of ~4,000 CC1-FAIL labels
are that wrapper; a further 1,019 are bare CC1-FAIL with no message at all.
- FIX: _MAKE_WRAP guard excludes make's summary lines; the FIRST real diagnostic wins (cc1
cascades — error #1 is the root cause); nothing-but-wrapper is now labelled
CC1-FAIL(no-diagnostic) rather than disguised (R32). Same family as the §58 warning
red-herring guard directly above it: a label identical for every input carries no information.
- VERIFIED on the exact branch (exec'd the real source, see hazard below):
"CC1-FAIL: make: *** [...] Error 33" -> "CC1-FAIL: src/…/tu.c:2240: error: too few arguments
to function `gte_ldv3'". DIFF/SKIP/PLUMBING paths unchanged.
- HAZARD DOCUMENTED (mine): harvest_verify.py has NO `if __name__ == '__main__'` guard — the
whole gate is module-level, so `import harvest_verify` PARSES argv, RUNS A BUILD and overwrites
.run/harvest_*.txt. Tripped it unit-testing classify_fail (resident stayed 8e17e02f, 0 banked,
tree clean, no damage). Nothing imports it today, so it is flagged in the file header rather
than fixed by a risky 500-line refactor of our most load-bearing gate.
Drew T
50c6f61056