Moved out of .run/ (where the blanket ignore would have lost it) into tools/ per R3, and generalised
from regalloc to any docs/gcc-2.7.2-map/* audit.
The check an LLM audit of a source-derived document cannot do for itself: agents return
{real_file, real_line, source_quote}; this re-opens each file at each line and compares the verbatim
quote to what is actually there. Whitespace-normalised, +/-40-line search window, and it reports
NEAR (quote real, line wrong) SEPARATELY from FABRICATED (text appears nowhere) — because with the
2.8.1->2.7.2 drift reaching +611 lines in reload1.c, a wrong lookup lands INSIDE A DIFFERENT FUNCTION
and every sentence built on it still reads plausibly.
Used on the T34 regalloc.md audit: 184 findings, 0 FABRICATED.
26 agents (5 derive + 21 adversarial refute), 1.73M subagent tokens. Two guards, because a false
REFUTED deletes a working lever and is worse than a stale line number:
- MECHANICAL FABRICATION CHECK (.run/verify_regalloc_findings.py, NEW): every claim had to carry a
verbatim source_quote + file + line; I re-opened each file at each line and compared. 184 checked,
**0 FABRICATED** (27 exact, 153 NEAR = quote real but line arithmetic off by +2..+19, 4 declared
unverifiable). Distinguishes NEAR from FABRICATED because the 2.8.1->2.7.2 drift (+300..+600 in
reload1.c) can land a lookup inside a DIFFERENT function and still read plausibly.
- ADVERSARIAL SECOND STAGE: every REFUTED claim went to an independent agent told to refute the
refutation, defaulting to upholding the map. **Of 21 REFUTED, 14 OVERTURNED, 7 stand.** The raw
audit output would have deleted 14 CORRECT levers (RC-6's verdict, the decoy-qty lever, the
<=3-qty creation-order rule, the keepalive-read lever).
FINAL: 119 CONFIRMED / 40 LINE-DRIFT / 7 REFUTED-upheld / 4 UNVERIFIABLE. The model is sound.
The 7, marked [A23] inline:
1. K4 flag_caller_saves is ON (toplev.c:3387-3394 at -O2), BYTE-PROVEN on the real cc1 — a
call-crossing value is not confined to $s0-$s7-or-spill. Added the missing diagnostic:
caller-save slots are 4-BYTE-PACKED vs reload spill slots 8-ROUNDED (misreading one as the other
sends you to RC-1 + decl reordering, the wrong lever entirely).
2. RC-7's premise false: a frame address is never CONSTANT_P (rtl.h:237-240 excludes PLUS), so it
gets a real slot + lw. THIS EXPLAINS T31's byte-tested failure today — cse_expr.md §2's remat
recipe could not dissolve func_80132F40's hoist (47->40, never 0) because the promised mechanism
does not apply to frame addresses. Independent audit and live byte-test converged.
3. The "init MOVED to just before its use" pass is 2.8.1-only; 2.7.2 deletes the init instead.
4. K2 refs are LOOP-DEPTH-WEIGHTED (reg_n_refs += loop_depth), not per-insn-mention.
5. K1 qty numbers come from BIRTH order, not regno order.
6. RC-15/K2: allocno_live_length is the DENOMINATOR — priority is a density.
7. Pins do NOT kill the S2 boost — independently reproducing yesterday's sched.md finding from a
different agent/section, plus the decisive detail that sched.c:423 DOES add the pseudo guard
where it wants one, so the omission at :2478 is deliberate.
NOT applied: the 40 LINE-DRIFT fixes wholesale — generic quotes match several places, so publishing
all 40 risks replacing 2.8.1 drift with fresh 2.7.2 drift. Header carries 12 hand-verified anchors +
an instruction to grep before citing. Struck text preserved, not deleted (H5).
Docs-only: no src/ or config/ touched, R22 not re-run and not claimed.
- 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.
NOTHING BANKED — no draft reached closeness 0. Recorded as such (P9). No src/ or config/ change,
so the fleet is untouched at HEAD's verified 140/140; R22 deliberately NOT re-run and NOT claimed.
- VERIFIED the checkpoint's six closeness numbers against the bytes (R14/R35): 217/10/11/6/7/9 all
reproduce EXACTLY through match_one --json, with asm_subdir/-O0 DERIVED from wave22_targets.json
rather than guessed. All six are reach-138 cores = ~135,516 templated ins (~1.04pp) if cracked.
Reproducer .run/near6_measure.py.
- PERMUTER (only 2 of 6 are §60a-admissible): func_80177B5C 11->7, func_80140958 10->6, both
re-measured with match_one — an oracle INDEPENDENT of the permuter's scorer (R34) — agreeing
exactly. Both plateaued after cycle 1. Seeds preserved + allowlisted.
- THE FINDING: residual_class routes ADDRESSING -> permuter, but gcc-2.7.2-map/cse_expr.md §2
documents that exact class (hoist-vs-remat) as STEERABLE by a byte-proven C recipe. The tool
spends CPU searching for what the map says has a deterministic fix, and both ADDRESSING targets
plateaued exactly as that predicts. R35-shaped instrument defect, not a compiler wall.
- NEGATIVE RESULT, byte-tested on func_80132F40 (6 variants): the §83d CSE fork is REAL (s32 fixes
the min-block opcodes but hoists &v[0] into a 5th callee-saved reg, 47 mism), and the §2 kill
moves it (47->40) but does NOT dissolve it in 3 placements. §2 has an unstated boundary: proven
where the address's only uses are call arguments; a STRUCT-COPY source address survives the kill.
close=6 (s16) remains the best known state — the wave agent's verdict, independently re-earned.
- NEW DIAGNOSIS: func_80140958's post-permuter residual is not scheduling — my draft CONSTANT-FOLDED
a loop value the target keeps live (li v0,3 / li a3,3 / li t3,12 vs addu/sll from $v1). Untried.
- NOT SPENT, deliberately: func_80176734 (already a no-bank Fable5 pass, §H), func_80140D68 (~200
compiles already), func_8012E364 (~2500 variants already).
- tools-health exit 0 (green, fail-closed) at preflight.
CAUGHT BY VERIFYING THE CHECKPOINT INSTEAD OF ASSERTING IT. `.run/wave22/` was covered by the blanket
`/.run/*` ignore, so the 13 UNBANKED drafts — 6 NEAR with precise residual diagnoses and 7 that
reached match_one MATCH but did not bank whole-binary — existed only on disk. My own checkpoint's
"START HERE" list names them as next-session fuel, and they cost ~2.59M subagent tokens to produce.
One `git clean -fdx` would have destroyed them: exactly the exposure the .run/giants Fable5 cracks
had before Phase 27 curated them (R20).
Now allowlisted: .run/wave22/*.c + .run/wave22_targets.json (the per-target canonical callee/data
declarations resolved from the real TU scope — the §17a-1 lever the wave was built on).
Also commits docs/family-hseq.md, regenerated by this session's family_hseq runs.
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.
Same error as commit commit:1103 this morning, which I recorded as a lesson and then repeated: I scoped
`git add` to src/ and docs and omitted config/, leaving the jtbl carve that func_80171B4C's bank
depends on (its `- [0x499f4, c, …]` split + `.rodata` carve + the JTBL_INTERLEAVE order) uncommitted.
harvest_verify KEEPS a carve on success, so it is part of the banked state, and the R22 140/140 I
reported was verified WITH these files present.
Caught by jtbl_family_bank's dirty-tree precondition again — not by me, not by any gate. That is now
twice in one session that a tool's precondition was the only thing standing between a partial commit
and a broken HEAD.
THE REAL LESSON, and it is not "be more careful": a scoped `git add` is an UNVERIFIED ASSERTION about
a change set's boundary, and nothing in this project checks it. R32 says a claim like that needs an
assertion. The concrete guard: before committing banked work, `git status --porcelain config/` must be
empty or its contents must be part of the same commit. Recorded for the next session rather than
bolted on at the end of a long one.
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.
THE BLOCKER: the SC07 quartet (ov_SC07_006/007/010/011) refused two families with
`conflicting types for D_800AF634`. Both sides read `S_AF634 []` — the SAME type STRING — so it is a
type-IDENTITY collision: the templated body carries its OWN block-scope `typedef struct {…} S_AF634;`
while the TU's declaration of D_800AF634 comes from a MACRO-INJECTED one (§8c), making two DISTINCT
types with one name. cdecl.compatible cannot see this and correctly answers "compatible".
THE FIX: if the TU already declares the symbol above the insertion point, DROP ours instead of
keeping it. A redeclaration we do not emit cannot collide — with anything, identity or type — and the
TU's own declaration is in scope and authoritative. Strictly better than the previous behaviour,
which was a hard compile error; the whole-binary byte-gate still arbitrates if the TU's type implies
a different access.
AND IT HAD TO REACH BLOCK SCOPE, not just column 0. §8d demotes these externs on the way in, so by
the time a sibling draft is STAGED they are already indented — a col-0-only scan (my first cut) saw
nothing to do on exactly the drafts that needed it. C requires a block-scope `extern` to agree with a
file-scope declaration in scope, so a redundant redeclaration conflicts at ANY scope.
VERIFIED on the failing member: D_800AF634's declaration is removed from the staged draft, and the
re-sweep's error moved past it. HONEST STATUS: the quartet is NOT yet banked — the next conflict is a
FUNCTION decl (`conflicting types for func_80024054`), a different axis (§58c / cast_call_sites)
which the sweep's member staging does not currently run. Not peeled further here: §95's law says
splice once and dump EVERY cc1 error rather than one per gate cycle. Tree clean, nothing banked.
SESSION-20 measured serial family-sweep gating as "roughly an 8-16x throughput loss on a 32-thread
box" and BUILT tools/sweep_parallel.py for it — but only reachable via a manual `--stage-only`
two-step, so this path stayed serial and three sweeps in SESSION-22 (133 + 273 + 137 members) ran
serially for no reason. §101, the stale-default class.
SHAPE OF THE CHANGE — deliberately minimal after two failed attempts earlier today. A parallel
PRE-PASS (phase 2a) runs only the per-group `harvest_verify` subprocess; phase 2b then consumes the
results IN THE ORIGINAL SERIAL ORDER, so every line of post-processing (the MISMATCH backstop, the
zero-bank restore, the counters, the prints) is untouched and output stays deterministic. No closure
restructuring — that is exactly what broke it twice before.
SAFETY, not a new claim: the Makefile already builds binaries concurrently (check-all/extract-all use
`xargs -P$(JOBS)`, JOBS=16) and bulk_harvest's farm does the same with a per-binary lock. The §28
hazard is two makes racing on the SAME artifacts, prevented by the per-overlay lock (two splits of
one overlay build the same binary and therefore serialise).
NEGATIVE-CONTROLLED BOTH WAYS: `--stage-only` stages identically under -j1 and -j12 (4 groups each);
a full gate returns IDENTICAL tallies (0 banked / 4 failed) parallel vs serial; tree clean after both.
HONEST MEASUREMENT: on the only sample available (4 groups, and they fail FAST on a compile error
rather than running full builds) parallel was 4s vs serial 6s — ~1.5x, NOT the 8-16x. That figure
needs a large family (137 groups of full builds) to show, and every such family was already banked
today. The wiring is proven correct here; the throughput claim remains SESSION-20's measurement, not
mine. `-j 1` restores the old behaviour.
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 guard skipped any exemplar carrying a `register __asm__("$N")` pin because templating it
cc1-CRASHED the sibling TUs (§42e). Phase 27 BYTE-PROVED that SIGABRT was `extract_unit` dropping the
body's file-scope macros — OUR bug — and fixed it (_carry_macros); its own roadmap delta then put the
PINS class "back on the mechanical-harvest table". The cause was removed and the default never
changed, so the guard kept skipping real work.
MEASURED THIS SESSION on one family: func_80175AB8 reported `skipped {'pinned-exemplar': 137}` and
then banked 133/137 the moment it was bypassed (R22 140/140). A protection whose cause is gone is not
free — it is a silent skip (R32) wearing a safety label, and the whole-binary byte-gate was always the
real arbiter here.
--allow-pins kept as an accepted no-op so existing recipes/docs keep working; --no-pins restores the
old behaviour. Negative control: --no-pins still reports `pinned-exemplar: 4`; the default stages them.
This is the THIRD stale default found today, after sweep_parallel being opt-in (8-16x throughput left
on the table) and conform_decls refusing a remedy it could perform. Same shape each time: correct when
written, cause since removed, still the default, opt-out only if you remember the flag.
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.
MEASURED, not assumed. Baseline ~18s/sibling (92 siblings in 27:37). Profiling a realistic cold
cycle: `make extract` 3s + `make build` 2s = ~5s of the 16s, so MAKE IS NOT THE BOTTLENECK and -j
cannot be the 8-16x lever. Confirmed end-to-end on one sibling: 16s -> 14s.
Where the rest goes: the per-sibling loop tries up to FOUR stages (raw -> scoped -> recovered ->
reconciled) and EACH runs its own `make build`, plus jtbl_carve and remap/canon_sig_reconcile.
WHY THE REAL LEVER IS NOT DONE HERE. Cross-sibling parallelism is worth ~8-16x on this 32-core box
(each sibling is an independent binary, and the Makefile already proves per-binary parallel builds
safe: check-all/extract-all run `xargs -P$(JOBS)` at JOBS=16). It is blocked on a specific hazard,
not on effort: `revert()` restores config/ from git, and `config/overlays.mk` is SHARED, so a
concurrent revert would clobber peers' carve entries — the same "revert-from-HEAD eats another
worker's state" failure this tool's own precondition check warns about. Safe parallelisation needs
line-scoped + locked + atomic edits to overlays.mk and a revert that never wholesale-restores shared
paths. Designed, not built.
ALSO REVERTED THIS SESSION: an attempt to make parallel gating the default in family_sweep. The
adapter for it already exists (tools/sweep_parallel.py, built SESSION-20 after measuring the same
8-16x loss) but is only reachable via the manual `--stage-only` two-step, so the default path stayed
serial — and three sweeps today (133 + 273 + 137 members) ran serially for no reason. Wiring it is
right, but my patch broke the tool twice (missed import, then a closure-scope error) and family_sweep
banked 543 members today. Restructuring a proven tool with blind string replaces at the end of a long
session is how a working thing gets broken; reverted and left as a specified next-session task.
MY ERROR: the previous commit scoped `git add` to src/ and tools/ and omitted config/, leaving the
jtbl carve's config (overlays.mk + splat.ov_SC01_077.yaml) uncommitted. harvest_verify KEEPS a carve
on success, so that config is part of the banked state — HEAD was an incomplete change set, and the
R22 140/140 I reported was verified WITH these files present, not without them.
CAUGHT BY jtbl_family_bank's precondition check ("config/ or src/ has uncommitted changes"), not by
me and not by any gate. A build without them appeared byte-identical, but that was an INCREMENTAL
build reusing objects — the same trap that produced a false all-clear earlier today — so it is not
evidence either way. Committing what R22 actually verified removes the ambiguity rather than
reasoning about it.
Lesson, same shape as R32 pointed at commit hygiene: a scoped `git add` is an assertion about the
change set's boundary, and nothing checks it. The tool preconditions are the only thing standing
between a partial commit and a broken HEAD.
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.
A 15-draft harvest_verify batch reported CC1-FAIL=4 and `final SHA None`. Three of the four were the
HARNESS, not the compiler. Checked the tree FIRST (the MISMATCH is a tree alarm, not a result),
reverted to the committed baseline rather than reasoning about a half-applied state, rebuilt ->
d19c9580 BYTE-IDENTICAL. No banked result was ever at risk: the byte-gate cannot manufacture a match,
but it CAN manufacture a verdict — and verdicts are what the backlog and roadmap are built from.
ORDERING PROVED THE CASCADE (R14): items 1-11 are real (9 PLUMBING, 2 DIFF), all before item 12 —
jtbl_carve REFUSING func_8013B83C (§59(3) non-contiguous same-subseg table). Items 13-16 are four
CC1-FAILs on the SAME ov_SC01_077_o0.o = one refused carve counted four times.
THREE DEFECTS FIXED:
1. `_ok` was computed and IGNORED — a refused carve was spliced and built anyway into a guaranteed
Error 33, filed as CC1-FAIL. Now a named CARVE-REFUSED class, skipped (one build cheaper).
2. attempt() never restored on failure, so the tree was dirty BETWEEN drafts — and _jtbl_snapshot()
snapshots the tree AS IT FINDS IT, so a later carve captured an earlier FAILED draft's splice and
its undo faithfully RE-APPLIED it, after the final _write(baseline). That is the entire
`final SHA None` mechanism. Invariant restored: the tree is at baseline except while a draft is
under test (atomic AND bisect branches).
3. The recovery's own `make extract` rc was unchecked (_sh does not raise — §93's sibling). Now loud.
Plus an R32 assertion on the cleanup: at 0 verified a non-empty git status is residue, not a result;
it names the files and the recovery command. It fired correctly on its first real run.
MEASURED RECOVERY (same drafts, clean tree): func_8013B83C -> CARVE-REFUSED; func_801789AC ->
PLUMBING (actionable); func_8017C974 -> DIFF (corroborates its agent's global_alloc spill diagnosis);
func_80140958 -> CC1-FAIL (genuinely its own). final SHA None -> d19c9580; tracked diff empty.
BLAST RADIUS OF §96, HONESTLY: the reconcile_tu span fix unblocked func_80176218 (banked, swept
133/137) and no other draft in the batch. 7 of the 9 PLUMBING are `conflicting types for <the
function itself>` = the DEF-side self-decl axis conform_decls owns — the next lever, now a measured
target list rather than a guess. cookbook §97.
+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 DEFECT (on the banking path — gate_stage runs reconcile_tu): its rewrite replaced the draft's
declaration LINE with the TU's declaration of the ONE conflicting symbol. A statement can declare
several: 'extern u16 D_80078EB2, D_8011F82A, D_8011F82C, D_80078EB4, D_8011F8C4;' where only EB4
conflicts became 'extern s16 D_80078EB4;' — four symbols silently gone.
WHY IT HID: the draft does not fail at the declaration. It fails later with 'D_8011F82A undeclared'
at a USE, several conflicts down a peeling chain, nowhere near the cause. I peeled four separate
'next conflicts' out of func_80176218 before dumping ALL cc1 errors in ONE build and seeing three
undeclared symbols that the tool itself had removed.
FIX: group the plan by STATEMENT rather than by symbol; re-emit EVERY declarator (TU's version for
the conflicting ones, the draft's own for the rest); note multi-declarator statements; and when a
statement cannot be re-parsed, say so loudly instead of emitting only the planned symbols.
VERIFIED: all 5 declarators survive, and the same draft now reconciles 3 symbols instead of 2 —
the dropped ones had been hiding a further conflict.
cookbook §95. The law (R32 again): a transform that REPLACES a syntactic unit must account for
everything that unit contained — the STATEMENT, not the line, is the unit of a C declaration.
Diagnostic: when a draft fails in a chain, stop peeling one error per gate cycle; splice once and
dump every cc1 error, because the shape of the whole set names the cause.
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.
CHECKPOINT HYGIENE: between T11 and T12, wave 2 + a bank + a new tool guard were recorded ONLY in
commit messages — CURRENT_PHASE.md and the cookbook were stale for that stretch. The quiet periods
were background sweeps/R22 (~2h each) during which the tree cannot be touched, but that does not
excuse leaving the durable record behind: a stale checkpoint is worse than an absent one. Closed.
cookbook §92 — conforming a DECLARATION: pointer changes are caller-neutral, scalar-WIDTH changes
are NOT. Byte-proven both ways (func_80179B74: 1,600 sites / 523 files / 3 forms, banked, R22
140/140; func_80175DA8: PLUMBING before the conform, DIFF after — the conform did not fix the draft,
it changed the callers). Plus the arity case that broke 138/140, and the counting lesson:
func_8015B950 looked like ~926 call-site casts and needed ONE — its only 0-arg call sits in an
engine_core.h DEFINE macro the preprocessor expands 926 times. Count SITES, not expansions.
cookbook §93 — `set -o pipefail` attributes a pipeline failure to the LAST stage, not the failing
one: cc1 exit 33 reads as an assembler error because `as` ends the recipe. The 2-minute fix is to run
the stages by hand printing each rc, then re-run the failing one with stderr visible. Turned an
opaque Error 33 into a one-line fix twice today. Corollary (§88e, earned): hand a stuck function over
as an UNDIAGNOSED observation, never as a named cause — flagged that way, the agent found the true
cause (cc1 `conflicting types for 'Ent'`) immediately.
func_8014D820 family swept 137/137. func_8016B6BC 0/137 reproducibly — recorded as a DIAGNOSIS task
per §59 (a sweep 0/N is a per-sibling integration signal, not a codegen verdict), never as a wall.
Checkpoint fn-count corrected 89.88 -> 89.80 against the measured report; stray a.out removed (R12).
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.
Drew T