The audit was the right precondition: THREE of the six corrected functions were families already
queued for the item-3 sweep, and each would have failed 0/137 exactly the way five families did
earlier today.
SWEEP: 6 corrected functions, all non-jr families with 137 live stubs -> 685 BANKED / 137 failed.
Five families landed 137/137; func_80146750 failed on its own residual (undiagnosed).
GATES: R22 clean-fleet 140 passed, 0 failed of 140 — after the header batch alone AND after the
banks; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED, cdecl, audit-binaries, dedup 1886/0);
0 NON_MATCHING (G4).
METRICS: instr 86.3% -> 86.5% (11338739 -> 11372304 = +33,565 ins); fn-count 90.88% -> 91.08%
(321472 -> 322157 = +685); distinct-code 76.9% -> 76.9% (+0).
§111 GOT ITS FIRST PREDICTIVE TEST AND PASSED: all six families have a single h_exact class, so the
model predicted +0 distinct BEFORE the sweep ran, and +0 is what happened. The metric is modelled,
not mysterious.
THE TOOL (tools/audit_header_sigs.py, cookbook §112). A DEFINE_func_*() macro forward-declares the
functions its body calls, and that decl is visible in EVERY overlay instantiating the macro — so when
it disagrees with the byte-true definition the whole family becomes untemplatable and the failure
wears a compiler wall's clothes. Three such were found ONE AT A TIME earlier this phase
(func_80156044, func_8016163C, func_8014D610), each worth ~137 members, each costing a
diagnose/fix/re-sweep cycle. This audits all of them in one pass: parse every `extern func_X(...)` in
src/shared/*.h, find every DEFINITION in src/**/*.c (via §110's _def_head_at, not "ends in ;"),
compare with cdecl, and report only where NO definition agrees — one overlay disagreeing is loose
typing (§16/T49), all of them disagreeing means the header is the outlier.
RESULT: 3,043 decls across 1,023 functions; 265 have definitions; 61 contradict every one. The top 10
are full-fleet families (137/136/134 live stubs, 1,366 total), all with an unambiguous byte truth.
APPLIED: 6 functions / 11 decl sites, R22 clean-fleet 140 passed, 0 failed of 140 —
func_80138DE0, func_80146750, func_80161374, func_80161774, func_80161888, func_801778A8.
TWO PRECONDITIONS THE AUDIT DOES NOT YET CHECK, both found by gating rather than by reasoning:
1. ARITY. func_80144B14 / func_8013BD34 / func_8014358C declare (void) but are DEFINED with one
parameter. Correcting the header would break the macro's OWN call site (too few arguments), so
they need the §99 no-prototype treatment instead. Excluded before the batch, by measurement.
2. OTHER IN-SCOPE DECLS. The first batch of 7 FAILED the gate 2/140 with `conflicting types for
func_80147364` — the overlays' own TUs declare it the old way (9 header sites rewritten, but
src/ov_*/…:347 disagrees). A header correction is only safe when no other in-scope declaration
disagrees; that one additionally needs a conform_decls pass. Excluded; the other 6 then gated
140/140 clean.
The gate caught the bad batch immediately and the culprit was found by reading one object's real cc1
output rather than by a 7-way bisect (7 fleet gates = ~2.5h; one serial compile = seconds).
Item 3, and it banked the third family. extract_unit located a definition with "the line matches
<type> func_<addr>( and does not end in `;`" — wrong whenever ONE LINE holds both a declaration and a
definition, which the handwritten inline-asm wrappers do:
extern void func_80156044(int, int); int func_80155FF8(int, int) { __asm__ … }
The line does not end in `;`, so func_80156044 — appearing there only in the DECLARATION — was taken
as a definition head. extract_unit lifted the neighbouring WRAPPER instead of the real definition
seven lines below; every sibling already defines that wrapper via its shared DEFINE_ macro, so all
137 failed with `redefinition of func_80155FF8` and it read as a compiler wall.
FIX: ask what follows the PARAMETER LIST, not what ends the line (`_def_head_at`) — `;` is a
declaration, `{` or end-of-line is a definition. Plus the R32 assertion: a unit that defines a
function other than its target cannot template, so refuse LOUDLY (`_foreign_defs`).
TWO TRAPS HIT WHILE WRITING THAT ASSERTION, both caught by regression-checking against families known
to bank: (1) _def_head_at ALONE over-fires — a call whose args wrap has nothing after the `(` on its
line, which "end of line => definition" reads as a definition; it refused THREE families that had
just banked 137/137. (2) The type-prefix test ALONE under-fires — it is what missed the wrapper
originally. The predicate needs both: split the prefix on its last `;`, require the remainder to look
like a return type, then check what follows the parameter list. All five known-banking families
extract byte-identically before and after.
RESULT: func_80156044 0/137 -> 137/137, 0 failed.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.2% -> 86.3% (11328601 -> 11338739 = +10,138 ins); fn-count 90.84% -> 90.88%
(321335 -> 321472 = +137); distinct-code 76.7% -> 76.9% (67937 -> 68066 = +129).
cookbook §110.
Item 2, and the same story as item 1: the header correction WAS the fix. With engine_core.h
declaring the byte truth, the family swept 137/137 with zero failures — no draft change.
before (header wrong) 0/137 `conflicting types` / a param-retyped body that could not compile
after (header right) 137/137, 0 failed
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.1% -> 86.2% (11318463 -> 11328601 = +10,138 ins); fn-count 90.81% -> 90.84%
(321198 -> 321335 = +137); distinct-code 76.7% -> 76.7% (+0 — a SIXTH data point for the anomaly).
Same class as func_80156044 and func_8016163C: the shared header contradicted the byte truth. The
exemplar's banked definition is `s32 func_8014D610(s32 param_1, s32 param_2, u16 *param_3)`
(ov_SC07_006_jr_80140608.c:4576); DEFINE_func_8014D438 declared
`void func_8014D610(s32 a0, void *a1, void *a2)`.
That mismatch is what made --fix-def-sig retype param_3 to `void *` while the body does
`param_3[0]` -> `void value not ignored as it ought to be` (T61's param-use guard now refuses it,
naming the header as the real fix — this is that fix).
§85 sized first: 0 callers consume the return. The macro's call site passes `s16 buf1[4]`/`buf2`
into the s32/u16* params — same 4-byte values in $a1/$a2, so the retype is a warning, not a codegen
change.
Verified in two steps (T48 discipline): the header change ALONE, no src change, R22 clean-fleet ->
140 passed, 0 failed of 140. Fleet-shared (§61/§63), so R22 was mandatory.
NOTE: ov_SC07_006_jr_80140608.c:4529 records an earlier, DIFFERENT resolution of the same conflict —
a per-overlay de-macroized local decl ("do NOT re-macroize"). That remains correct and untouched;
this fixes the shared decl the other 137 overlays see.
Item 1. The header flip (commit:1163's sibling, committed just before) was the whole blocker: with
engine_core.h declaring the byte truth, the family swept 137/137 with ZERO failures — no draft
change, no new lever.
before (header wrong) 0/137 `conflicting types` / a --fix-def-sig-truncated draft
after (header right) 137/137, 0 failed
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.0% -> 86.1% (11307777 -> 11318463 = +10,686 ins, exactly 137 x 78);
fn-count 90.77% -> 90.81% (321061 -> 321198 = +137); distinct-code 76.7% -> 76.7% (+0).
The distinct-code anomaly now has FIVE data points (T52 +125, T57 +125, T56 +0, T58 +0, T63 +0) and
still no identified variable. Unchanged as the queued probe.
The shared header contradicted the byte truth. The exemplar's banked definition is
`s32 func_8016163C(s32 arg0, u32 arg1)`; both DEFINE_ macro decl sites said
`void func_8016163C(void *a0, s32 a1)`.
That mismatch is why the family could not template, and it is what made --fix-def-sig DEMOTE the
return to void — gcc then deleted the computation feeding it and the draft compiled to 58
instructions against a 78-instruction target (T62's self-inflicted SIZE-MISMATCH).
§85 sized first: conform_decls.consumers(func_8016163C) = 0 — both macro call sites discard the
return (`func_8016163C(a0, func_801615C4(a0, 0));`), so the return-axis flip is byte-neutral.
Verified in two steps (T48 discipline): the header change ALONE, no src change, R22 clean-fleet
`make clean && extract-all && check-all` -> 140 passed, 0 failed of 140. Fleet-shared edit
(engine_core.h reaches all 138 overlays), so R22 was mandatory (§61/§63).
The exemplar's own @stuck note asked for this (ov_SC01_077_jr_80154C24.c L1349-1350): the
handwritten func_80155FF8 wrapper calls func_80156044 via inline-asm `jal`, so nothing consumes
the return, and ov_SC01_077 already declares it `void` inline — the MACRO was the outlier.
§85 precondition measured before touching it: conform_decls.consumers(func_80156044) = 0 callers
consume the return, so the return-axis flip is byte-neutral.
Verified in two steps (T48 discipline): the header change ALONE, with no src change, R22 clean-fleet
`make clean && extract-all && check-all` -> 140 passed, 0 failed of 140. Fleet-shared edit
(engine_core.h reaches all 138 overlays), so R22 was mandatory (§61/§63).
Ran the batch with the T57 recipe (--band all --normalize-self-decls, live stubs derived from src/
not the stale map). 6 of 8 selected (two still filtered — selection line read this time).
821 candidate members across 6 families
BANKED 137 — func_8012A1BC (78 ins) 137/137
failed 684 — the other FIVE families banked 0 each
Attribution from git diff (137 x func_8012A1BC), not the per-group log lines whose split-name field
my first aggregation mangled.
THE SHAPE OF THE REMAINING FRONTIER — the finding. Across T56->T58 the per-family outcome is BINARY
and near-total: a family banks ~137/137 or ~0/137, nothing in between. And each 0/N so far has had
its OWN distinct cause — DATA decl scope (T56), FUNCTION decl scope (T57), jtbl table-count drift
(func_8014032C), plus five more undiagnosed here. The mechanical lever is done pulling by itself:
from here each family costs one diagnosis. A batch is now a DIAGNOSIS QUEUE, not a harvest, and the
next phase of this work should be planned on that economics.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 86.0% (11297091 -> 11307777 = +10,686 ins); fn-count 90.73% -> 90.77% (+137);
distinct-code 76.7% -> 76.7% (+0).
The distinct-code anomaly now has FOUR data points and still no explanation: T52 +125, T57 +125,
T56 +0, T58 +0. All four families are PURE; the exemplar overlay does not separate them either (T56
and T57 both templated from ov_SC01_077 and disagree). Two behaviours, no identified variable.
Still not guessed at — it stays the queued probe.
First batch off the 64-family list. Fleet crosses 86.0% instr-weighted.
TWO OF MY OWN ERRORS, both caught by measuring:
1. Three of five targets never ran — --band defaults to `substantial` (nins>=80) and I picked three
at 79/78/78. The tool printed "2 matched-exemplar families" and I nearly read that as "5
attempted, 3 refused". Read the SELECTION line, not the intent.
2. Stale map: .run/family_hseq.json was regenerated in T55, BEFORE T56 banked func_80144090, so it
still listed 134 live stubs for a now-complete family. Membership is stable (h_seq over original
bytes); only the matched/unmatched split rots. Filter live stubs from src/, not from n_matched.
THE FIRST RUN WAS 0/268 — AND IT WAS A SECOND OPT-IN LEVER, NOT A WALL. Diagnosed one sibling past
the -j16 interleave and the §58 warning noise: `conflicting types for func_80133AB0` (spliced def at
2688 vs a decl at 2429) — the FUNCTION decl-conflict class, not the DATA one T56 fixed. That is
exactly what --normalize-self-decls exists for (the sibling's own caller declares the member in a
different C form than the exemplar's, which used a fn-ptr cast) — and it is OPT-IN, so it never ran.
Re-ran the identical two families with it: 0 -> 132 banked.
0x80133ab0 (137 ins, jr_8012ACE0) 132/132 BANKED
0x80143d28 (80 ins, jr_80140608) 0/136 — a different, undiagnosed blocker
THE PATTERN, TWICE IN A ROW: T56 the DATA decl lever was unreachable from the sweep path; T57 the
FUNCTION decl lever is reachable but OFF BY DEFAULT. Both present as a flat 0/N that reads exactly
like a compiler wall. A 0/N from a sweep is a statement about which levers were enabled, not about
the code.
GATES: R22 clean-fleet 140 passed, 0 failed of 140; tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, dedup 1886/0); 0 NON_MATCHING (G4).
METRICS: instr 85.8% -> 86.0% (11279007 -> 11297091 = +18,084 ins); fn-count 90.69% -> 90.73% (+132);
distinct-code 76.4% -> 76.7% (67812 -> 67937 = +125).
SHARPENS the T56 anomaly rather than resolving it: 132 banked here moved distinct-code +125, and
T52's 132 also moved it +125 — but T56's 136 moved it +0. Three PURE families, two behave one way
and one the other. Still unexplained, still not guessed at.
T55's two-part next step as one job. +20,944 instructions banked.
1. THE LEVER WAS UNREACHABLE FROM THE PATH MOST FAMILIES USE (cookbook §107)
§103 was wired into jtbl_family_bank only (T53), and that tool runs for has_mid_jr families.
Everything else sweeps through family_sweep, which gates via PLAIN harvest_verify by design — so
the lever existed, was byte-proven, and most families could not reach it. The symptom was
indistinguishable from a compiler wall: func_80144090 swept 0/136 with `conflicting types for
D_800A651C`.
Why it does not violate the plain-harvest_verify rule: that rule exists because gate_stage's
transforms PERTURB A CORRECT DRAFT (§19/T3). The tu-scope never touches the draft — it moves a
DECLARATION IN THE TARGET TU. The test is not "is it a transform" but "does it change the draft?"
Reused the existing undo instead of inventing one: family_sweep already snapshots TUs it edits at
staging time (--normalize-self-decls) and reverts on a final MISMATCH (not byte-neutral) AND on a
zero-bank group (§61 undo law — no dead diff). The tu-scope shares that dict and inherits both
backstops; renamed nsd_snapshots -> tu_snapshots. Default ON with --no-tu-scope to A/B it (the T24
--allow-pins precedent): byte-neutral by construction, a no-op when nothing collides, auto-reverted
when it buys nothing.
2. THE DUPLICATE-DECL REFUSAL RELAXED — AND IT DID NOT MATTER
scope_tu_externs refused N>1 file-scope decls as "ambiguous"; duplicate-IDENTICAL externs are legal
C, so N identical decls are one decl written N times. Now compares whitespace-collapsed forms and
refuses only on genuine disagreement. MEASURED, and my hypothesis was WRONG: D_800B9A02 is 3 decls
in 2 DIFFERENT forms, so it was correctly refused all along — the family banked 136/136 without it.
RESULT: func_80144090 0/136 -> 136/136, 0 failed, with NO change to any draft.
GATES: R22 clean-fleet 140 passed, 0 failed of 140. tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED,
cdecl, audit-binaries, report/lint/dedup 1886/0). 0 NON_MATCHING (G4).
METRICS (reconciled against make report):
instr-weighted 85.7% -> 85.8% 11258063 -> 11279007 = +20,944 ins
fn-count 90.65% -> 90.69% 320656 -> 320792 = +136
distinct-code 76.4% -> 76.4% +0 (67812 unique, UNCHANGED)
FLAGGING the third row rather than explaining it away: 136 banked functions moved distinct-code by
ZERO, where T52's 132 moved it by +125, and both families are classed PURE. I do not have a verified
cause and will not invent one — either a real property of this family or a gap in the metric. Worth
one probe before that number is quoted again.
T51's payoff. The invocation is IDENTICAL to the T49/T50 runs; the only variable is T51's decl
scoping.
T49/T50 (pre-T51) 4 banked / 133 gate-fail (and all 4 were SC07 — a different cause)
T52 sample (8) 8 BANKED / 8 52s
T52 rest (124) 124 BANKED / 124 13m04s
TOTAL 132 / 132, ZERO failures
So the 133 "gate-fails" were never a codegen wall — they were one file-scope declaration per sibling
TU. Fifth time this phase a wall has resolved to tooling/plumbing.
GATES (from a genuinely clean tree): R22 clean-fleet `make clean && extract-all && check-all` ->
140 passed, 0 failed of 140. `make tools-health` OK — corpus 0 PHANTOM + 0 TRUNCATED, cdecl,
audit-binaries, report/lint/dedup 1886 validated / 0 failed (C1 239604/239604). 0 NON_MATCHING (G4).
METRICS (reconciled against make report, not asserted):
instr-weighted 85.5% -> 85.7% 11240111 -> 11258063 = +17,952 ins
distinct-code 76.1% -> 76.4% 67687 -> 67812 unique fns (+125)
fn-count 90.62% -> 90.65% 320524 -> 320656 = +132 functions
INCLUDE_ASM stubs 33189 -> 33057 = -132
+17,952 templated instructions against T50's ~18,000 estimate. distinct-code gains 125 not 132
because seven siblings are byte-identical to code already counted unique.
ALSO SETTLED:
- item 3 is now byte-confirmed, not just inspected: [gather_externs] warned "func_80135D20 ... the
sibling will not compile" on ALL 132, and all 132 BANKED. A 100% false-alarm rate on this family,
actively masking real causes. cdecl._mask is the fix (T51 used exactly that).
- the T51 pre-pass is now worth folding into jtbl_family_bank; T51 withheld that pending a measured
payoff, and 4/137 -> 137/137 is it. Next task.
config/ (per-overlay splat.*.yaml + overlays.mk, written by the carve) is staged alongside src/ —
the `git add -A src/` omission this phase already recorded once.
Bounded sample before scaling (the standing validate-on-a-sample invariant). The ONLY variable vs
the T49/T50 runs is T51's decl scoping; the invocation is identical.
T49/T50 (pre-T51): 4 banked / 133 gate-fail (and all 4 were SC07, a different cause)
T52 sample: 8 BANKED / 8 in 52s
Committed here only because jtbl_family_bank's precondition refuses to run on a dirty config//src/
(its per-sibling revert restores from HEAD, so uncommitted banks would be silently wiped). The
remaining 124 follow in the next commit; R22 clean-fleet gates the whole task at the end.
Both config/ (the jtbl carve + overlays.mk) and src/ are staged — the omission this file already
warned about after a prior `git add -A src/`.
Also confirms item 3 empirically: [gather_externs] warned "func_80135D20 ... the sibling will not
compile" on every one of the 8, and every one BANKED. Comment-scanning false positive, as T50 said.
Item 1 off the SESSION-23 list. T48 proved the lever by hand on the exemplar, T50 located the same
blocker in every sibling; this builds the tool, measures the population, applies it fleet-wide, and
gates it. It BANKS NOTHING — it removes the blocker. The sweep is the next task.
MEASURED BEFORE BUILDING (R35). The blocker census over all 132 still-stubbed siblings is perfectly
uniform: 132/132 carry it, 3 contested symbols each, EXACTLY ONE file-scope decl statement per
(TU, sym), ZERO file-scope references below the decl (so the deletion is always safe), 660
block-scope re-declarations needed.
THE TOOL: tools/scope_tu_externs.py — the TU-side complement of scope_data_externs.py (§8d). §8d
fixes the incoming DRAFT and has a give-up branch that DROPS the draft's own decl when the TU already
declares the symbol at file scope. Right when the types agree; fatal when the byte-true draft needs a
different one — which is exactly how 132 byte-true siblings gate-failed wearing a codegen wall's
costume. This moves the TU's OWN file-scope decl down into every later function that references the
symbol and lacks its own block-scope decl, then deletes the file-scope line.
FILE(u8 D_x) ... then BLOCK(u16 *D_x) below it -> conflicting types (the 132 failures)
(no file-scope decl) ... BLOCK(u8) ... BLOCK(u16 *) -> builds; each fn owns its own view
- contested set DERIVED, never hand-listed (R33): the remapped draft's block-scope D_ externs
intersected with the TU's file-scope decls above the splice point; --family does it per sibling
- built on cdecl.split_statements/_mask (R33), not a 7th regex: depth-0 spans (a fn definition
flushes at its closing '}' — a column-0 test is NOT a file-scope test, m2c emits goto labels at
column 0 inside bodies) + length-preserving comment/string masking. That masking is what kills the
comment-scanning false-positive class still open as item 3.
- REFUSES LOUDLY, never skips silently (R32): >1 file-scope decl above the splice point; a
file-scope statement below the decl referencing the symbol; an unlocatable body brace
- coverage asserted as a DELTA (R32): file-scope -1, block-scope +len(consumers). An absolute
"a block-scope decl exists" check would have passed VACUOUSLY — these TUs already carry ~18
legitimate block-scope decls of the same symbols
VERIFIED IN TWO STEPS (T48's structure — why a 132-file edit was safe to make):
1. the move ALONE on ov_SC01_000 -> make build -> 9052dc0e BYTE-IDENTICAL, then reverted
2. fleet-wide -> R22 clean-fleet (make clean && extract-all && check-all) -> 140 passed, 0 failed
of 140; make tools-health OK (corpus 0 PHANTOM + 0 TRUNCATED, cdecl, audit-binaries,
report/lint/dedup 1886/0). Metrics UNCHANGED at 85.5% instr / 76.1% distinct / 90.62% fn-count
— the correct result for a declaration-only change.
The diff is uniform to the line: all 132 files +11/-3. A second --family run reports 132
nothing-to-do, 0 refused (idempotent).
Deliberately NOT done: wiring this as an automatic jtbl_family_bank stage. That waits until the
sweep measures the payoff — folding an unproven pre-pass into the gate is the same unmeasured
premise this phase keeps catching.
Also preserves .run/near6/g5260_a.c (the T48 raw crack body, allowlisted) — the sweep may need it
for --raw.
cookbook §103 + SETUP tool-inventory row (R21).
The §53 carve path banked only 4 of 137 siblings, ALL of them SC07 — the exact signature
func_80177DA8 showed before its §99 fix, so the same lever applies.
- jtbl_family_bank func_80135260: 4 BANKED / 133 gate-fail. The 4 are SC07 overlays.
- conform_decls dry run confirmed the class: byte-true def is
`s32 func_80135260(s32, s32, s16 *, s16 *)` but 3,744 declaration sites say
`(s32, s32, s32, s32)` — params 3 and 4 declared s32 where the byte truth is s16 *.
Return type agrees, so the §85 return-axis precondition does not fire.
- Applied: 3,744 sites rewritten across 2,021 files; the tool's R32 assertion reports
"non-canonical declarations remaining: 0 OK (axis complete)". It correctly SKIPPED the 5
DEFINING TUs (the 4 SC07 banks + ov_SC01_077) — a defining TU owns its own declarations, since
per-overlay byte-true signatures legitimately differ under §16 loose typing.
- This touches src/shared/engine_core.h, so it is FLEET-SHARED and R22 was mandatory (§61/§63):
R22 clean-fleet 140 passed, 0 failed of 140.
Also recorded: jtbl_family_bank's [gather_externs] warning named func_80135D20 as an undeclared
referenced symbol, but that symbol appears ONLY in the draft's header COMMENTS (lines 3 and 29) —
a comment-scanning false positive, same class as the Phase-19 gen_harvest_targets garbled-hint bug.
It was not the cause of the 133 failures.
Next: re-run the carve path for the remaining 133 siblings now that the decl axis is conformed.
The T45 probe re-filed this as a crack target; it turned out to be a SCOPE problem, and the fix is a
new reusable lever.
DIAGNOSIS. The draft MATCHes standalone (136 ins) with block-scope `extern u16 *D_801870AC/B0/B8`,
which are byte-TRUE (they produce the target's 4-byte pointer loads). The TU carries FILE-scope
`extern u8 D_801870B0/AC/B8; extern s16 *D_801870B4;` at lines 3433-3436 — the preamble of the
already-banked func_80135168 — and a file-scope decl constrains EVERY LATER function in the TU, so
the draft's pointer decls became "conflicting types". Ordering is what makes this asymmetric: the
TU's own block-scope `extern u16 *D_801870B0;` at L2829 precedes the file-scope u8 decl and only
WARNS; a block-scope decl AFTER it is an ERROR.
TWO WORKAROUNDS MEASURED AND REJECTED, both +3 instructions with a rotated callee-saved bank:
reconcile_tu (conform to the TU) -> 139 ins vs 136, 123 mismatched
cast-at-use (*(u16 **)&D_x) -> 139 ins vs 136, 123 mismatched
So the byte-true code genuinely REQUIRES the pointer-typed declaration; the decls had to move.
THE FIX (move the decls, never the draft — §85 applied to DATA): scoped those four file-scope externs
into their only two consumers (func_80135168 and func_80135480, both of which already use the
cast-at-use idiom). Verified in two steps: (1) the decl move ALONE rebuilds ov_SC01_077 byte-identical
d19c9580 — declaration-only, no codegen change; (2) the original byte-true draft then banks clean,
verified 1 / failed 0. R22 clean-fleet 140 passed, 0 failed of 140.
THE REUSABLE LEVER: a FILE-scope extern in a shared overlay TU is a global constraint on every later
function in that TU. When a byte-true draft needs an incompatible type for the same symbol, scope the
existing decl to its consumers rather than bending the draft — bending it cost +3 here, twice.
Family sweep is NEXT and needs the §53 carve path (has_mid_jr: true, 137 siblings, PURE) —
family_sweep correctly refused it.
The §99 conform_decls pass REFUSED this one (§85: 414 callers consume the return), so it was solved
from the DRAFT side. Three blockers, each measured:
1. §94 type-carry, and the draft's own header asserted something FALSE — it claimed both typedefs
already exist in engine_types.h. Measured: Hw4 1 hit, Prim4 1 hit, Env_800D29F8 ZERO. So in the
real TU the #ifndef guard is DEFINED and the typedef vanished -> "parse error before D_800AE7BC".
2. Signature axis: conformed the DRAFT to the fleet's declared `s32 *` return, then param 2
(s16 * -> Prim4 *). Byte-neutral because `src` is used EXACTLY once, as (s32)src. The error
("argument `src' doesn't match prototype") is again printed with NO "error:" prefix.
3. The family sweep went 0/137 TWICE before 137/137.
THE REUSABLE FINDING — a 0/N sweep whose exemplar banks cleanly is the signature of an extract_unit
carry gap. Measured on the staged member drafts:
file-scope extern -> CARRIED
file-scope #define -> CARRIED, but only while its expansion's deps stay file-scope
file-scope typedef -> NOT carried (silently dropped)
#define whose expansion references a BODY-LOCAL extern -> NOT carried
RECIPE: make the draft SELF-CONTAINED — body-local typedefs survive (PTag_80140D68 in this same
draft was the proof all along), and if that pushes a macro's dependency body-local, inline the macro
at its use sites. 0/137 -> 0/137 -> 137/137, 0 failed, each step byte-measured.
R22 clean-fleet 140 passed / 0 failed of 140; dedup-check 1886/0.
Fleet 85.5% instr, 76.1% distinct, 90.57 -> 90.61% fn-count.
§99 arc total (T41-T43): 133 + 1 + 137 = 271 functions. Both blockers Drew green-lit are CLOSED.
Drew green-lit the fleet-shared change. One function at a time from a committed-clean baseline, dry
run first, R22 after each step — the discipline the T39 shared-state hazard earned.
- conform_decls --fn func_80177DA8 --apply: byte-true def `void func_80177DA8(u8 *p, u32 v, s32 idx)`;
268 declaration sites rewritten across 268 files; the tool's own R32 completion assertion reports
"non-canonical declarations remaining: 0 OK (axis complete)" (§85 all-or-nothing as a COUNT, not a
hope). Nothing under src/shared, config or include. R22 -> 140/140: the decl axis is byte-neutral.
- Re-sweep: BANKED 133 / 0 failed, skipped {not-stub: 4} => the family went 4/137 -> 137/137, exactly
reversing T40's failure. R22 -> 140/140. dedup-check 1886/0.
- Fleet 85.4 -> 85.5% instr, 76.0 -> 76.1% distinct, 90.54 -> 90.57% fn-count.
T42 func_80140D68 — the pass correctly REFUSED it (414 callers consume the return, so widening the
return type is not byte-neutral, §85). Diagnosed in the real TU instead (rtu_match + reading ALL
stderr per §95 — gcc-2.7.2 prints hard errors with NO "error:" prefix, so grepping for "error" finds
nothing):
1. parse error before D_800AE7BC = a §94 TYPE-CARRY defect, and the draft's header asserts something
FALSE: it claims Hw4 AND Env_800D29F8 both already exist in engine_types.h. Measured: Hw4 1 hit,
Prim4 1 hit, Env_800D29F8 ZERO. FIXED by keeping Hw4 guarded (it does exist) and moving
Env_800D29F8 outside the guard, draft-local per §100. Still MATCH (65 ins).
2. conflicting types — conformed the DRAFT's return to the fleet's declared s32 * (still MATCH).
Only remaining delta: param 2 byte-true `s16 *` vs declared `Prim4 *`. conform_decls still refuses
(its return-axis precondition fires regardless). OPEN, with the next probe named.
family_sweep --hseq --band all --only <4 cores> -j12 -> 143 banked / 405 failed. R22 clean-fleet
140 passed, 0 failed of 140; dedup-check 1886/0. Fleet 85.3 -> 85.4% instr, 75.8 -> 76.0% distinct,
90.50 -> 90.54% fn-count.
Unlike T33's 548/548, this sweep mostly failed — so the failures were DIAGNOSED, not accepted:
- func_80138C60 swept 137/137 clean.
- func_8013B6A0 / func_8013B598 swept 1/137 each — EXPECTED, not a regression: Phase 20 byte-proved
the -O0 cluster is OVERLAY-LOCAL, so their siblings need per-overlay _o0 carves that do not exist.
- func_80177DA8 swept 4/137 — ROOT CAUSED: its banked def is K&R and its own TU declares it no-proto,
but NON-SC07 overlays declare a PROTOTYPE (extern void func_80177DA8(s32,s32,s32)), so the remap
conflicts. The 4 successes are SC07 overlays, which declare it not at all.
THE SYNTHESIS: that is the SAME §99 K&R-vs-prototype class as item 3's func_80140D68 (K&R def vs 138
prototype callers). ONE conform_decls pass unlocks both — ~17,000 instructions. conform_decls exists
for exactly this ("the draft's signature is byte-TRUTH; move the DECLS, never the draft"). NOT run:
it is a fleet-shared 138+-declaration change and this session already tripped one shared-state
hazard, so it wants an explicit go-ahead (P5).
MY ERROR, recorded: I read a `head -6` list of modified dirs as the complete set and briefly thought
the sweep's count did not reconcile. Measured properly it does — 143 stubs removed across 142 files.
Same class as grepping the wrong field earlier today: truncated output is not exhaustive output.
Worked Drew's order 1->2->3->4 at xHigh (no fan-out).
ITEM 1 func_80176734: permuter COMPLETELY FLAT at 13 (8 cycles x 240s, regalloc profile chosen over
the classifier's cse because the residual is 3 register 2-swaps). Not one improving waypoint in 32
min. THIRD ADDRESSING-bucketed target in a row where the permuter under-delivers (11->7, 10->6,
now 13->13 flat) — the T31 routing finding is now well evidenced. Remaining: the reg_renumber-swap
gdb oracle; feasibility confirmed (cc1 unstripped, reg_renumber @0x82d4330, prior-art .gdb exists)
but it needs a .greg pseudo-identification pass, so not started.
ITEM 2: 4 of 7 banked — func_80177DA8, func_8013B6A0, func_8013B598, func_80138C60. THE BARE GATE
WAS THE UNLOCK: gate_stage reported failed:2 on the _o0 pair while bare harvest_verify reported
verified 2/failed 0 on the SAME drafts, and rtu_match independently confirms func_8013B6A0 matches
in the real TU. That gives the carried "ladder-vs-bare-gate asymmetry" defect a REPRODUCTION — the
ladder is destroying good drafts, not diagnosing them. All 4 are reach-138 PURE families =
35,604 templatable instructions.
SHARED-STATE HAZARD hit and repaired: the failed func_80135260 attempt left fix_arity_callers
--any-proto edits in 17 TUs holding none of my banks (the bare gate has no snapshot/restore, unlike
the ladder after the Task-14 incident). Caught by diffing the tree, not by the tool's report.
Reverted the 17, kept the 3 bank-bearing files, re-verified R22 clean-fleet 140/140. Nothing under
src/shared, config or include was touched, so blast radius was ov_SC01_077-local (§63).
ITEM 3 func_80140D68: fails even bare-gated, and the PREDICTED CAUSE WAS WRONG — there is no
DEFINE_func_80140D68 macro. Real conflict is §99 K&R-vs-prototype: draft is K&R `u32 *`, 138 callers
declare `extern s32 *func_80140D68(s32 *, Prim4 *, s32, s32, s32);`. Lever exists (§99 did this at
1,072-decl scale today) but it is a fleet-shared 138-decl change. Scoped, not attempted.
ITEM 4 func_80178004 biv-init wall: RE-PROBED and UPHELD — my own hypothesis refuted. The cited
mechanism (loop.c:3803/3823, benefit->0 eliminates emit_iv_add_mult) is verbatim present in real
2.7.2 inside strength_reduce (3214); loop.md's flagged version difference is in combine_givs, which
this verdict does not rest on. The wall stands.
- family_sweep --hseq --band all --only <4 cores> -j12 -> BANKED 548 member-matches / 0 failed
across 137 overlays. Preconditions CHECKED not assumed: map regenerated first (sig-overlays +
family_hseq) so the exemplars read matched-ov077 not the stale draft-ov077; all 4 families
has_mid_jr=false (§53 carve law) and diff_class PURE 137/137; --band all because two cores are
`mid` and the default `substantial` band would have silently dropped them; --reconcile-raw avoided.
- R22 clean-fleet after the sweep: 140 passed, 0 failed of 140. dedup-check 1886 validated / 0
failed, C1 coverage 239604/239604, 0 NON_MATCHING in any default build (G4).
- SESSION ARC: instr 84.8 -> 85.3%, distinct-code 74.7 -> 75.8%, fn-count 90.34 -> 90.50%.
552 functions banked (4 exemplars + 548 members) ~= 74,802 templated instructions.
- sched.md SOURCE-VERSION CORRECTION: the map declares its source as gcc-papermario, which Phase 23
established is gcc 2.8.1 — not our 2.7.2 — and it was never re-derived. Citations are correct for
the WRONG compiler. One claim is byte-refuted and load-bearing: §1.7/§S12 said the S2 birthing
boost needs SET(REG_pseudo,...) so pins must be removed ("Unpin first"); real 2.7.2
birthing_insn_p (sched.c:2469) tests only GET_CODE(SET_DEST)==REG with NO pseudo check and gates on
reg_n_sets==1 (2490) — hard-reg dests ARE boosted. Corrected in place (old text struck, not
deleted) + a hand-verified 2.7.2 cross-reference table and a warning block.
DRIFT IS NOT UNIFORM: ~+27 in sched.c but +103/+377/+611 in local-alloc.c/reload1.c — big enough to
land inside a different function. ~44 drifted citations across sched/regalloc/loop .md (a screen,
a lower bound). regalloc.md is worst and is NOT yet re-derived — named as next.
- All line numbers verified by me against tools/reference/gcc-2.7.2, not taken from the agents.
Ultracode fan-out (12 agents, 1.70M subagent tokens): 6 crack agents, one per NEAR target, each
carrying its byte-measured residual + T31's disproved routes, then a distill agent per target that
adversarially re-checks the claim.
- BANKED ×1 (whole-binary gate, gate_stage --no-propagate per §55b law 1): func_80140958 (260 ins),
func_80177B5C (147), func_80132F40 (72), func_8012E364 (67). Every agent MATCH claim was
RE-MEASURED BY ME with match_one before it was believed (G3/P9: match_one is a candidate, a bank
is the whole-binary gate), and verified against the SOURCE not gate_stage's accumulating
verified-list (§55b trap 4). R22 clean-fleet: 140 passed, 0 failed of 140.
- engine_core.h moved by exactly one byte-neutral arity fix (void -> no-proto) = fleet-shared, so
R22 was mandatory (§61/§63), not the per-binary gate.
- func_80140D68 MATCHes standalone but NOT whole-binary — the §30a integration class; its distill
agent named the likely cause in advance (DEFINE_func_* extern must return u32*, not void).
- func_80176734 217 -> 13 with the instruction count now EXACT (371/371). cse_expr.md §H's "no bank,
5 permuter-shaped clusters" is BYTE-REFUTED: 4 of 5 were steerable from C; the -1 length delta was
a combine/LOG_LINK effect (flow.c links a SET only to the next use in the SAME bb), not frame
pressure. Two coupled allocator/sched ties survive.
- FOUND: docs/gcc-2.7.2-map/sched.md cites gcc-2.8.1 line numbers (birthing_insn_p 2498->2469,
adjust_priority 2534->2507, potential_hazard 1345->1318, schedule_select 2646->2616) — surviving
papermario numbers Phase 23's source-version correction never swept. One is LOAD-BEARING: §1.7 and
§S12 claim the S2 boost needs SET(REG_pseudo,...) so pins must be removed; sched.c:2477 tests only
GET_CODE(SET_DEST)==REG with NO pseudo check, discriminator is reg_n_sets==1 (2490). Verified by me
against tools/reference/gcc-2.7.2, not taken from the agents. Map edits owed (next task).
- MY DEFECT: all 6 agents shared one scratch dir (1,452 files); deliverables are uniquely named and
verified intact, but short-named scratch could collide. Per-agent subdirs next wave.
137/137 banked via jtbl_family_bank (jr family, carve-aware path). R22 clean-fleet 140 passed /
0 failed of 140. MEASURED: fn-count 319,412 -> 319,549 (+137); instr-weighted 84.7 -> 84.8%
(+9,590 ins); distinct-code 74.5 -> 74.7% (+130 unique fns).
WAVE22 COMPLETE: 18 targets drafted (12 MATCH / 6 NEAR / 0 FAIL, 2.59M subagent tokens) ->
5 exemplars banked -> 685 members swept -> 690 functions total.
This commit stages config/ EXPLICITLY. Twice today I omitted it and left a carve uncommitted, both
times caught by jtbl_family_bank's dirty-tree precondition rather than by me or any gate.
4 families x 137 members: BANKED 548 / 0 failed. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,859 -> 319,412 (+553); instr-weighted 84.4 -> 84.7% (+36,640 ins);
distinct-code 74.4 -> 74.5% (+134 unique fns).
TODAY'S PARALLEL GATE WIRING PROVED AT SCALE: this run reported `gating 411 group(s) across distinct
binaries, -j12`. When I shipped it earlier I could only smoke-test 4 fail-fast groups and said
explicitly that the 1.5x measured there was NOT the 8-16x claim; 411 full build-and-gate cycles is
the shape the claim was about.
A PERFECT 548/548 also says the wave's exemplars were right for the right reasons — a body that
templates across 137 byte-variant siblings with zero rejections is not a marginal match.
BAND NOTE: the first sweep attempt used --band substantial and staged NOTHING; these exemplars are
60-76 ins, i.e. the MID band (substantial is >=80). The tool reported that honestly
("0 matched-exemplar families (band=substantial); 0 candidate members") rather than returning a
clean-looking 0 banked — the skip-vs-result distinction this session kept running into.
THE WAVE: 18 h_seq family exemplars (~255k templated instructions), one agent each, drafting from
cached Ghidra-C + the target .s with canonical callee/data decls resolved from the real TU scope.
Result 12 MATCH / 6 NEAR / 0 FAIL (2.59M subagent tokens). No agent touched the tree — the
draft-only constraint held (verified: git status clean across src/config/tools/include).
BANKED 5: func_80148E54, func_80171B4C, func_8014A738, func_8012A328, func_80163534.
R22 clean-fleet 140 passed / 0 failed of 140.
A BUG I INTRODUCED EARLIER TODAY, FOUND BY WORKING THE 12->5 GAP. My block-scope descent in
reconcile_tu fed ordinary STATEMENTS to cdecl.parse; some parse without raising into a declarator
with an EMPTY base type and the statement's symbol as its name. That fake row overwrote the genuine
plan entry for the same symbol, so the span rewrite landed on a statement instead of the declaration
— and my own R32 completion assertion still PASSED, because the conformed text appeared somewhere.
Byte-witnessed on D_80126B5C: planned twice ("draft 's32'" and "draft ''"), output unchanged, gate
PLUMBING. Now block-scope rows are accepted only from a real `extern` with a non-empty base type.
TWO BANKS CAME FROM TODAY'S OWN FINDINGS:
- func_8012E014's single 0-arg call site took --cast-zero-arg-calls (built this morning for
func_801789AC's 138 sites).
- §99 HELD A THIRD TIME: K&R conversion dissolved func_80163534's s32->u16 narrowing across 1,072
declarations, leaving only a caller-neutral pointer change on the last param.
STILL UNBANKED (measured blockers, not guesses): func_8013B6A0 + func_8013B598 CC1-FAIL in the _o0
split; func_80133298 + func_80135260 + func_8012E014 genuine DIFF (match_one MATCH did not hold
whole-binary = TU-context); func_80138C60 parse-order (an extern referencing a body-local typedef
declared after it); func_80177DA8 prototype-vs-K&R mismatch.
Its 0/137 was the §94 TYPE-CARRY signature: the draft defines `typedef struct {…} Sp_80175DA8;` at
FILE scope, and remap_hseq templates the BODY but not the type, so every sibling compiled without it.
§94's remedy is the shared engine_types.h lift (right for func_8016B6BC, whose four types were
transitively referenced). But the cheap remedy was already in the same draft: it carries S_AF634 at
BLOCK scope and that templates fine, because a type declared in the body travels WITH the body.
Sp_80175DA8 is used by that function ONLY (7 mentions, 6 inside the body, 0 elsewhere), so moving it
into the body is byte-neutral (d19c9580 unchanged), T0, zero blast radius — versus editing a header
included by 140 binaries with uniquify/collision care and an R22.
Re-swept: 137/137, 0 failed. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,720 -> 318,857 (+137); instr 84.2 -> 84.4% (+31,647 ins); distinct-code
73.9 -> 74.4% (+129 unique fns).
§99 AND §100, AN HOUR APART, ARE THE SAME LESSON: both times the cookbook's named remedy was the
expensive fleet-wide one (524-site decl conform / shared-header lift) and the correct fix was
DRAFT-LOCAL (K&R definition / block-scope typedef). Before editing anything shared, ask what the
smallest scope is that still travels with the body.
The first sweep returned "banked 0 / skipped {'pinned-exemplar': 137}" — a SKIP, not a failure. The
§42e guard refuses pinned exemplars to avoid a cc1 SIGABRT, but Phase 27 BYTE-PROVED that crash was
extract_unit dropping file-scope macros (a TOOL bug, fixed by _carry_macros), not a compiler limit.
Re-run with --allow-pins: 133/137 BANKED. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,585 -> 318,720 (+135); instr 84.0 -> 84.2% (+25,423 ins); distinct-code
73.4 -> 73.9% (+127 unique fns).
THE GUARD IS NOW COSTING BANKS — the same shape as sweep_parallel being opt-in: a protection that was
correct when written, whose cause was later removed, still defaults ON. Measured cost on ONE family:
137 skipped, 133 bank fine. Phase 27's roadmap delta already said the PINS class was back on the
table; nothing changed the default. Flipping it is a one-line change, deliberately deferred to a
fresh session — that is exactly how family_sweep got broken twice today.
SC07 QUARTET, third occurrence today, now named: ov_SC07_006/007/010/011 refused again (same four as
func_80176218). NOT broken — func_8014CF04, func_8015D1B8 and func_801789AC all swept them cleanly.
The correlation is the sibling TU (_jr_8016AE5C.c, a different carve layout; these 4 were onboarded
in Phase 27 with code at PAC entry 1). §59: read ONE sibling's real gate result before concluding.
func_80175DA8 0/137 is the §94 TYPE-CARRY signature (local typedef Sp_80175DA8 templated as a body
but not as a type) — the same shape that took func_8016B6BC 0/137 -> 137/137 today. Named next step,
31,878 templated instructions.
func_80175AB8 + func_80175DA8 both banked. R22 clean-fleet 140 passed / 0 failed of 140.
§92 SAID these need "the §17a-1 caller pair, NOT a bare conform" — the diagnosis was right (conforming
a narrow param changes argument promotion at every call site, measured PLUMBING -> DIFF) but the
remedy was the expensive one. The actual fix touches NO declaration: convert the DEFINITION to K&R,
where a narrow param PROMOTES to int (C89 6.3.2.2) and is therefore already compatible with the
fleet's existing `s32` prototype, while still emitting narrow-param codegen. §43 applied to the def
side. T0 draft-only, ZERO blast radius, versus a 524-site fleet conform.
THREE reconcile_tu BUGS SURFACED, ONE OF THEM MINE:
(a) BLIND TO BLOCK SCOPE. split_statements is depth-0 BY DESIGN, and §8d deliberately demotes data
externs into the function body — so the tool saw one statement and no declarations, printing
"reconciled: 0 draft(s), 0 data symbol(s); coverage defects: 0" for a draft cc1 rejected with
`conflicting types for D_8011F7BC`. A silent skip (R32). Fixed: descend one level.
(b) MY BUG, introduced by (a): descending into ANY `{` also enters struct/union/enum definitions, so
MEMBERS parse as declarations and get conformed — `u32 code;` became the TU's
`typedef void (*code)(unsigned short*);` INSIDE the struct, and `p->code` became
`p->(*(u32 *)&code)`. Caught by DIFFING THE TOOL'S OUTPUT AGAINST ITS INPUT before trusting it;
the byte-gate would have said PLUMBING and explained nothing. Guard: function bodies only.
(c) LATENT since the tool was written: _cast_sub matched bare identifiers and rewrote MEMBER ACCESSES
as globals. Unreachable until (a) existed. Guard: (?<![.\w])(?<!->).
cookbook §99.
137/137 banked, 0 failed via jtbl_family_bank. R22 clean-fleet 140 passed / 0 failed of 140; report
fail-closed green (dedup 1886/0, C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,447 -> 318,585 (+138); instr-weighted 83.9 -> 84.0% (+12,558 ins);
distinct-code 73.2 -> 73.4% (+131 unique fns — byte-VARIANT members, so unlike func_801330E0's
byte-identical family this one moves the distinct number too).
Closes the function REFUSED since SESSION-21 — correctly refused, since conforming its 660
declarations without first casting its 138 zero-arg call sites would have broken 138 binaries.
Also logged (T21): the sweep-throughput measurement. Drew was right that parallelism was proven and
adopted (Makefile JOBS=16; sweep_parallel.py -j12 built SESSION-20 after measuring an 8-16x loss),
but NEITHER sweep tool calls it — the adapter is reachable only via a manual --stage-only two-step,
so three sweeps today ran serially for no reason. The -j theory was wrong and measurement said so:
make is ~5s of the 16s per sibling (the loop runs up to FOUR builds per sibling), so -j16 is a 12%
win, kept but minor. The real 8-16x lever is blocked on revert() restoring the SHARED
config/overlays.mk from git — designed, not built. An attempt to wire family_sweep's parallel default
broke it twice and was reverted rather than committed.
STUCK SINCE SESSION-21, and conform_decls was RIGHT to refuse it: the byte-true signature takes a
parameter while 138 zero-arg CALL SITES exist across 138 files, so conforming the declarations alone
would turn every one into `too few arguments` — a fleet-wide compile break the per-binary gate cannot
see. The tool printed the exact remedy in its refusal message and could not perform it, so the
function sat blocked for two sessions.
NEW --cast-zero-arg-calls: cast every 0-arg call site to ((s32 (*)(void))func_801789AC)() — gcc folds
the cast of a known symbol to a direct jal, so caller bytes are unchanged — then re-run the conform
normally. PLAN -> VALIDATE -> WRITE like the decl axis, because a partial cast set is itself a
fleet-wide compile break. Not a macro this time (unlike func_8015B950's single shared site): 138
genuine per-overlay call sites, one each.
VERIFIED IN STAGES, not all at once: the 138 casts ALONE are byte-neutral (d19c9580); then the
660-site declaration conform (axis complete, 0 remaining); then the gate -> verified 1 / failed 0;
then R22 clean-fleet 140 passed / 0 failed of 140.
Reach 138 x 91 ins = 12,558 templated instructions unlocked for the sweep.
137/137 banked, 0 failed. R22 clean-fleet 140 passed / 0 failed of 140.
MEASURED: fn-count 318,309 -> 318,447 (+138), crossing 90.03%; instr-weighted 83.8 -> 83.9%
(+15,180 ins); distinct-code +1 unique fn.
AN HONEST NUANCE: distinct-code moved only +1 here vs +126 for func_80176218's family, because these
137 members are byte-IDENTICAL (h_exact) and collapse to one distinct function, while func_80176218's
were genuine byte-VARIANTS. Both are real work; they move different metrics. The 3-metric dashboard
exists so one number cannot flatter the other.
This family banked only because conform_decls learned to read K&R definitions an hour ago: one tool
gap, unblocked, became 138 functions.
SESSION-22 TOTAL: 6 exemplars + 680 members = 686 functions.
THE GAP: conform_decls could not parse a K&R definition at all — it exited "no DEFINITION found,
refusing to guess". Honest, but §43 (a narrow param declared K&R-style, producing the in-place
`sll $a2,$a2,16` tell) is a documented, load-bearing idiom here for exactly the narrow-param class.
So the tool was silently refusing the drafts that most need it: a whole idiom family read as
"nothing to conform" (R32 coverage).
THE SUBTLE PART IS PROMOTION (C89 6.3.2.2). A K&R definition promotes each narrow parameter, so a
prototype in scope must declare the PROMOTED type or gcc rejects the pair with `argument 'x' doesn't
match prototype`. That is why the fleet prototype reads `s32 a2` for a parameter the definition
declares `s16` — and why emitting the declared (unpromoted) type would RE-CREATE the narrow-param
conflict this tool exists to remove. The parser now promotes s8/u8/char/s16/u16/short -> s32 and
float -> f64, pointers untouched, and reports (R32) any K&R param with no declaration.
RESULT: byte-true signature read as `void func_801330E0(void *, s16 *, s32)`; the only real change
vs the fleet's 973 declarations was param_1 `s16 *` -> `void *` (a pointer shape, caller-neutral).
973 sites / 973 files rewritten, axis complete. Gate: verified 1 / failed 0, d19c9580 BYTE-IDENTICAL.
R22 clean-fleet 140 passed / 0 failed of 140.
Reach 138 x 110 ins = 15,180 templated instructions unlocked for the family sweep.
The largest single family on the census: 137 siblings x 289 ins. Per sibling — jtbl_carve -> make
extract -> remap_hseq + canon_sig_reconcile -> whole-binary gate, revert-on-fail. 137/137 BANKED,
0 failed. R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0,
C1 coverage 239604/239604, 0 NON_MATCHING).
MEASURED: fn-count 318,171 -> 318,309 (+138); instr-weighted 83.4 -> 83.8% (+39,882 ins);
distinct-code 72.5 -> 73.2% (+131 unique fns).
TWO TOOL REFUSALS MADE THIS BANK POSSIBLE, and both deserve recording:
- family_sweep REFUSED the family (has_mid_jr): §53's carve law says a carve-less sweep there returns
"a 0% that is a TOOL artifact, not a wall". Overriding with --allow-jr would have yielded 0/137 and
plausibly filed the highest-value family on the board as a wall.
- jtbl_family_bank REFUSED a dirty tree: its per-sibling revert restores from HEAD, so the
uncommitted 414-file decl axis would have been destroyed. H4 enforced in code.
This is the inverse of the session's earlier failures, which all came from tools that ANSWERED
instead of refusing.
SESSION-22 TOTAL: 5 exemplars + 543 members = 548 functions.
Fleet: 82.9 -> 83.8% instr, 71.5 -> 73.2% distinct-code.
The largest target on the T14 census: 138 members x 289 ins = 39,882 templated instructions at stake.
conform_decls --check showed 418 sites in 3 forms, pointer-type-only with NO narrowing warning and no
return-type change — the func_80179B74 shape that banked 137/137. Applied (418 sites / 414 files),
gated (jtbl carve succeeded first try), R22 clean-fleet 140 passed / 0 failed of 140.
Committed BEFORE the family bank because jtbl_family_bank refuses to run on a dirty tree — its
per-sibling revert restores from HEAD, so an uncommitted axis would be destroyed. The tool enforcing
H4 in code, correctly.
Also recorded: family_sweep REFUSED this family rather than returning 0/137 — func_80135EB0 is
has_mid_jr, and §53's carve law says a carve-less sweep there yields "a 0% that is a TOOL artifact,
not a wall". That refusal is the good version of today's pattern: every false wall untangled this
session (func_8016B6BC 0/137, the 4 fabricated CC1-FAILs, Phase-28's B2 0/8) came from a tool that
ANSWERED instead of refusing.
BANKED 273 member-matches / 0 failed across 137 overlays (func_8014CF04 136 + func_8015D1B8 137).
R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0, C1 coverage
239604/239604, 0 NON_MATCHING).
MEASURED from the committed digests, not projected: fn-count 317,898 -> 318,171 (+273);
instr-weighted 83.2 -> 83.4% (+26,770 ins); distinct-code 72.3 -> 72.5% (+129 unique fns).
A USEFUL NEGATIVE RESULT: both families swept cleanly across ov_SC07_006/007/010/011 — the same four
overlays that refused func_80176218's sweep earlier today. So that set is not broken; the 4/137
refusal is family-specific (the _jr_8016AE5C.c carve), which is the per-sibling INTEGRATION signal
§59 describes rather than a codegen or overlay-level wall. Carried, still not concluded.
SESSION-22 total: 3 exemplars + 406 members = 409 functions.
THE BANK: the T14 PLUMBING census showed func_8014CF04 blocking THREE drafts at once. Conforming its
decl axis banked func_8014CF04 + func_8015D1B8 (func_80135260 is a genuine DIFF, agreeing with its
independent SESSION-21 diagnosis). R22 clean-fleet 140/140; report fail-closed green (dedup 1886/0,
0 NON_MATCHING). fn-count 317,896 -> 317,898; distinct 66,110 -> 66,111.
BUT THE AXIS WAS A 1,748-FILE T2 WRITE SET (the --check per-form counts read "1"), and R22 came back
139/140 -- TWICE -- on a change the per-binary gate called BYTE-IDENTICAL. Three defects (§98):
1. THE REGEX CROSSED NEWLINES. `[^;]*` matches '\n', so a match starting at a DEFINITION line ran
past the `{` to the first `;`, swallowing `s32 func_8014CF04(...) {` PLUS the register pin on the
next line and replacing both with a prototype -> undefined reference. Fixed to `[^;{\n]*`: a
definition is now unmatchable by construction.
2. IT REWROTE INSIDE COMMENTS (H5, 3 lines). Now scans cdecl._mask() and rewrites by SPAN (R33 --
that length-preserving primitive already existed for exactly this).
3. THE REAL CAUSE -- IT ASSUMED ONE SIGNATURE FITS THE FLEET. ov_SC07_006 carries its own banked
definition with a DIFFERENT byte-true signature ((s32,s32,void*) vs (s32,void*,void*)), under a
decl marked "per-overlay-local decl (byte-true sig); do NOT re-macroize". That is the Phase-16
loose-typing wall inside a tool that structurally assumes it away. NEW RULE: a TU that DEFINES the
function owns its own declarations; a fleet axis is meaningful only for CONSUMING TUs. This grows
more common as banking proceeds -- every overlay that banks a function becomes an exception.
Then the R32 completion assertion cried wolf on its own by-design skip ("HALF-AXIS -- DO NOT BUILD"
for a complete rewrite): an assertion must be exact about its DOMAIN, not just its condition. Scoped
to consuming TUs -> 1,747 sites, 1 excluded by design. Also hardened to PLAN -> VALIDATE -> WRITE;
the refusal path had aborted mid-write while claiming nothing was modified, creating the very
half-axis §85 calls a guaranteed break.
META (R22's premise, re-earned): after fixing defect 1 I EXPECTED R22 to pass; it failed again for an
unrelated reason, and an individual `make build` of the failing binary SUCCEEDED by reusing objects
the clean run rebuilds. An incremental pass does not refute a clean-tree failure.
+134 functions banked total for this exemplar (1 + 133 members). Measured from the committed
progress.fleet.md, not projected: fn-count 317,762 -> 317,896; instr-weighted 82.9 -> 83.2%
(+43,818 ins); distinct-code 71.5 -> 72.3% (+126 unique fns — these members are genuine byte-
VARIANTS that each count distinctly, not free dedup).
VERIFY: R22 clean-fleet (make clean && extract-all && check-all) -> 140 passed, 0 failed of 140.
make report fail-closed green: dedup-check 1886 validated / 0 failed, C1 coverage 239604/239604,
0 NON_MATCHING in any default build (G4).
THE 4 FAILURES ARE CARRIED, NOT CONCLUDED. All four are ov_SC07_006/007/010/011 and all four differ
from the other 133 in exactly one way: their sibling TU is _jr_8016AE5C.c, not _jr_801734BC.c —
carved under func_8016AE5C, which was banked and swept in SESSION-21. That is the SAME four overlays
and the SAME carve the SESSION-21 checkpoint flagged as "worth checking first" for func_8016B6BC's
0/137, which turned out to be a transitive type-carry (§94) rather than a wall. Each sibling reverted
its byte-neutral self-decl edit cleanly, so no dead diff is left behind. Per §59 a sweep failure is a
per-sibling INTEGRATION signal, not a codegen verdict — read one sibling's real gate result
(COMPILE-fail vs byte-DIFF) before concluding.
THE DRAFT was failing in a CHAIN, one "next conflict" per gate cycle. Applied §95's own diagnostic
law instead — splice once, dump EVERY cc1 error — and the whole set named the cause immediately:
three errors on TWO axes (one data decl, two callee decls), not three problems.
THE DATA ERROR WAS reconcile_tu AGAIN, ONE SHAPE DOWN (§96). split_statements returns comment-
STRIPPED text WITH SPANS; the rewrite re-found each planned statement by comparing that text to a raw
LINE, so `extern u8 D_80078E78; /* cur base ($s5) */` never matched. The decl was left unconformed
WHILE THE USE-CAST PASS STILL FIRED -> a draft whose uses are cast for the TU's storage against the
draft's own declaration -> cc1 reports `conflicting types` AT THE VERY DECL THE TOOL JUST CLAIMED TO
FIX, exit 0, "reconciled: 3 symbols".
FIX: rewrite by SPAN (the primitive existed — its docstring says spans are preserved *because drafts
get rewritten*). Plus the R32 assertion the old code was missing: it had a dropped_check counter
incremented in two places and NEVER COMPARED — "a loud failure nobody counts is exactly as invisible
as a silent one" in miniature. Now declarators-in vs -out AND a per-symbol check that each planned
tu.declaration() actually landed, both as `!!` notes so --strict exits non-zero.
MEASURED: 3 -> 4 data symbols reconciled on the same draft; trailing comments preserved (H5).
THE TWO CALLEE CONFLICTS were the other axis (reconcile_tu skips kind=='func' by construction):
cast_call_sites (§20) conformed func_80177AD4 (TU `void (int, unsigned int)`) and func_80178298
(TU `(u32*, u8*, short, short)`) and cast each call site to the draft's intended widths.
GATE: verified 1 / failed 0, d19c9580 BYTE-IDENTICAL. Write set is one overlay-local TU = T1 per the
§63/§85 blast-radius taxonomy, so the per-binary gate is sufficient; the ×137 sweep is the T2 case
and takes a full R22.
The family that failed its sweep twice (once in the 274-member batch, once after the §91 guard) and
looked like the §86 bimodal 'some families just don't template' case. It was not.
DIAGNOSIS (§59 + §93): spliced ONE sibling and read cc1 directly. It reported `c`, `v`, `off`
undeclared — ordinary locals that ARE declared in the remapped body. cc1 says 'undeclared' because it
aborted the declaration block at an unknown TYPE and every later declaration fell out with it. Read
the FIRST error, not the loudest: a visibly-declared variable reported undeclared means suspect its
type.
THE LIFT MUST BE TRANSITIVE. Lifting the type the body names directly (M8_8016B6BC) changed nothing —
still 0/137. The real set was four, found by following each definition's own references:
M8_8016B6BC -> Prim_8016B6BC -> Vtx_8016B6BC (named only inside Prim's body) -> DVec_8016B6BC.
lift_types.py --apply, byte-gated ALONE first (neutral, d19c9580 unchanged), then swept.
RESULT 0/137 -> 137/137, zero failures. R22 clean-fleet 140/140. cookbook §94.
Cost of not diagnosing: this family sat recorded as 'doesn't template' across two sessions. Pointed
at one sibling's real stderr it took under an hour and was worth 137 members.
WAVE 2 (9 never-drafted exemplars, ultracode): 9/9 returned, 5 MATCH / 4 near, 2.25M tokens.
BANKED: func_8014D820 (304 ins ×138) — and its agent ROOT-CAUSED the failure I left undiagnosed.
It was never an assembler problem: cc1 exit 33, `conflicting types for 'Ent'` vs
engine_types.h:434, surfaced by the recipe's `set -o pipefail` and MISATTRIBUTED to `as` because
`as` is the last stage in the pipe (Makefile:560). Fixed by moving V4/Desc/Ent to BLOCK scope —
byte-neutral and collision-proof across all 138 member TUs. Vindicates flagging it to the agent as
UNVERIFIED rather than passing my own guess forward as fact (§88e).
R22 clean-fleet 140/140.
NEW GUARD — SCALAR NARROWING IS NOT CALLER-NEUTRAL (byte-proven, and it cost 3 gate cycles):
conform_decls treated all decl type changes alike. A POINTER change is caller-neutral (func_80179B74
conformed 1,600 sites s16*/short* -> u16* and stayed byte-identical fleet-wide). A SCALAR WIDTH
change is NOT: narrowing `s32 a0` -> `u16 param_1` changes argument promotion at every call site.
MEASURED on func_80175DA8: decls reverted -> gate says PLUMBING; conform applied -> gate says DIFF.
The conform did not fix the draft, it changed the CALLERS. Now warned explicitly (not refused — the
draft's sig is still byte-truth for the callee and the gate arbitrates), with the instruction that a
DIFF after this conform means examine the callers (§17a-1 pair), not the body.
Verified the guard discriminates: fires on func_80175DA8 (s32->u16), silent on func_80179B74.
STILL OPEN from wave 2: func_80176218 + func_80175AB8 (DATA-symbol conflicts, D_80078EB4 /
D_8011F7BC -> reconcile_decls) · func_80175DA8 + func_80135EB0 (need the §17a-1 caller pair, not a
bare conform) · 4 near-misses with precise residuals recorded (func_80176734 129 length-drift,
func_80140958 49 inverted-hoist, func_80177B5C 19 sched tie, func_8017C974 83 -> permuter).
134/134 BANKED on the remainder after 3/3 on the probe — the FOURTH full-family sweep this session,
all four unblocked by the --like role guard, three of them 100%.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
1,600 decl sites across 523 files, in THREE different forms (s16 *a0 / short * / short *p),
conformed to the byte-true 'void func_80179B74(u16 *p)'. conform_decls ALLOWED this one: the arity
is unchanged, so no 0-arg call site can break, and the return is unchanged, so §85's precondition
does not apply. Gated BYTE-IDENTICAL; R22 clean-fleet 140/140.
The tool has now refused one axis (func_8015B950, correctly — it would have broken 138 binaries)
and cleared another (this one, correctly). Both verdicts held under R22.
133/134 BANKED on the remainder after 3/3 on the probe. ONE sibling refused (ov_SC03_108,
gate-fail) and is left as a stub rather than forced — a 136/137 recorded honestly beats a 137/137
that needed a shortcut. Third full-family sweep this session, all three unblocked by the --like
role guard.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
134/134 BANKED on the remainder after 3/3 on the probe — the second clean full-family sweep this
session, both unblocked by the --like role guard. func_8015B950 is stubbed in NO overlay.
R22 clean-fleet: extract-all 139/139, check-all 140 passed / 0 failed.
At 271 ins x 137 members this is the session's largest single family by instruction weight.
Drew T