SS94 said treat a family 0/N as a TYPE-CARRY failure until proven otherwise. It was one.
MECHANISM (read from the source, not inferred - SS125 rule 1): E_13C08C was a MULTI-LINE
typedef at FILE scope. extract_unit's preceding-decl backscan walks back over
extern/comment/blank/typedef lines, but a multi-line typedef presents its CLOSING line
(`} E_13C08C;`) first, which matches none of those prefixes. The scan stopped there, so every
templated sibling received the body WITHOUT its type and all 137 failed to compile.
FIX = SS100 (prefer the DRAFT-LOCAL form): a type only one function uses belongs in its BODY,
where it is part of the unit by construction. Byte-neutral (a type declaration emits no code),
gated on ov_SC01_077 before and after.
family_sweep --hseq --only 0x8013c08c --band all -j8 -> 137 BANKED / 0 failed
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140
WHY THE DIAGNOSIS WAS REDONE FROM SCRATCH (R35): the first pass concluded "the type is not
defined anywhere" - because grep was SILENTLY SKIPPING the file (SS128, the raw-NUL defect fixed
at commit:1284). That conclusion pointed the same direction by luck, but it came from a broken
instrument and none of it was trustworthy. With grep working, the typedef was visible at
ov_SC01_077_o0.c:137 immediately.
A FRESH TRAP FOUND WHILE FIXING IT: my explanatory comment contained a literal `}`, and
extract_unit's forward brace-scan does NOT strip comments - it decremented depth and TRUNCATED
the extracted unit. Caught only because I verified the unit was complete instead of assuming
the edit worked. Comment reworded to contain no brace characters, with an in-place note saying
why. That hazard is now also documented in the body itself for the next reader.
Drew T
197004fb5b