- THE ALL-DRAFTS SCAN PAID (S4's law): .run/drafts-p30beh/func_8017EF68.c is a 969-ins draft that
scores "969 mismatched" against ov_SC03_007's 12-ins body — which is what every name+home scan
keyed on. Against its OWN body (ov_SC06_000, 970 ins): DIFF 969/969, **2 mismatched**,
SCHEDULE-REORDER/2, everything else — registers, frame, spill map — already byte-exact.
- THIRD instance of today's address collision: 0x8017EF68 = 12 ins (SC03_007) AND 970 (SC06_000);
0x8017CE58 = 246 (SC02_000/003) AND 734 (SC03_092). The serial queue's own size annotations
("func_8017EF68 (969)", "func_8017CE58 (733x3)") are therefore unreliable — re-derive from bytes.
- THE VINDICATION: the draft's header ends "NEXT STEP: this is the permuter's exact profile", and
drafts-p30beh is one of the 63 GTE dirs S43-1 unblocked — this function sat ONE working permuter
run from a bank, with the note naming the permuter, for as long as the silent fallback existed.
- The residual is a 2-ins adjacent transposition (lw $v0,0($s3) <-> srl $a2,$a1,16), root-caused in
the draft to a sched2 INSN_LUID tie (§49) with ~20 hand variants recorded DO-NOT-RE-BUY.
Repaired-permuter ILS (schedule profile, 6x240s) reaches 2 and holds flat; a free 12x600s run is
queued. Logged to the backlog at closeness 2 with the correct binary.
- Queue triage: func_8017C974's 22 stored drafts are all far (best 812/947); func_8017CE58 has only
a CC1-FAILing Ghidra-C draft. Neither is a near-miss.
- func_8017C6F4 FINAL for this session: hand 63 -> ILS 42 (pin-free seed, masked 44, flat over 8
warm restarts) -> ILS 41 (pin-t5 seed, masked 43, flat over 5). Best draft
.run/s43/func_8017C6F4.ils43-pin.c (closeness 41), logged + allowlisted. Both basins are now
MEASURED FLAT — do not re-run the ILS on these seeds; next levers are §148-C by hand, then Fable5.
- .gitignore: allowlist .run/s43/*.py + *.json so the refutation evidence (probe_leftovers.py,
leftover_probe.json) is preserved, not one `git clean` from gone (R20, the S42 lesson).
- S43 checkpoint block refreshed at the top of the file: the four instrument defects as one table,
the one number that moved, the resume list (with "26 unpropagated members" struck as refuted),
the harvest_verify import hazard, and my four process errors.
- RE-DERIVED from the tree (R35): the S40 propagation banked 59 families; 22 still have open
members = 31 instances, not the carried 26.
- SCANNED all 31 (not sampled, S4's lesson): mechanical family_remap from EVERY binary where the
same fn is already matched (up to 4 sources each) fails 31/31 with gross reloc-count mismatches
(2!=15, 12!=2, 11!=20, 2!=0). Script + JSON: .run/s43/probe_leftovers.{py,json}.
- WHAT THEY ARE: structurally DISTINCT bodies sharing an address and a name — the func_8017C6F4
15-vs-948 collision one level down. family_hseq independently agrees (R34): these cluster into
families with matched=0, several n_members=1. No matched sibling => nothing to template from =>
the failures were NEVER plumbing. They are per-member drafting work, not deterministic fuel.
- SCOPE STATED (P9): what is refuted is mechanical remap from a matched sibling (0/31). An
h_seq-staged draft + recovery ladder is formally untested — but that path produced the original
CC1-FAILs, its labels were content-free until this session, and --hseq --only now stages 0
families for these addrs. Cost the next wave as agent work.
- cookbook §149: the four instrument defects of this session as ONE pattern (silent fallback =
"found nothing"; same addr != same body, ledger side; make's wrapper is not a diagnosis; carried
cheap fuel nobody probed) + the rules each one yields.
- ROOT CAUSE: classify_fail took errs[-1], and make prints its own summary
`make: *** [Makefile:N: build/src/<ov>/<tu>.o] Error N` LAST, always — so the wrapper won
every time and the label carried only the TU name the record already stores. Each CC1-FAIL
therefore cost a manual splice-and-rebuild to learn what cc1 actually said (3x in S42 alone).
- MEASURED (R37, over the committed .classified.txt corpus): ~3,000 of ~4,000 CC1-FAIL labels
are that wrapper; a further 1,019 are bare CC1-FAIL with no message at all.
- FIX: _MAKE_WRAP guard excludes make's summary lines; the FIRST real diagnostic wins (cc1
cascades — error #1 is the root cause); nothing-but-wrapper is now labelled
CC1-FAIL(no-diagnostic) rather than disguised (R32). Same family as the §58 warning
red-herring guard directly above it: a label identical for every input carries no information.
- VERIFIED on the exact branch (exec'd the real source, see hazard below):
"CC1-FAIL: make: *** [...] Error 33" -> "CC1-FAIL: src/…/tu.c:2240: error: too few arguments
to function `gte_ldv3'". DIFF/SKIP/PLUMBING paths unchanged.
- HAZARD DOCUMENTED (mine): harvest_verify.py has NO `if __name__ == '__main__'` guard — the
whole gate is module-level, so `import harvest_verify` PARSES argv, RUNS A BUILD and overwrites
.run/harvest_*.txt. Tripped it unit-testing classify_fail (resident stayed 8e17e02f, 0 banked,
tree clean, no damage). Nothing imports it today, so it is flagged in the file header rather
than fixed by a risky 500-line refactor of our most load-bearing gate.
- THE FLOOR MOVED: permuter_ils on the S42 draft -> masked 65->44 (cycle 1, flat over 5 warm
restarts); re-measured in match_one terms 63 -> 42 mismatched, 947/947 ins. First movement
after ~40 hand probes, and it came from repairing an instrument (S43-1), not from new C.
Draft preserved + allowlisted: .run/s43/func_8017C6F4.ils44.c; logged at closeness 42.
- THE S42 "rumour" CLAIM WAS WRONG (R14): the 2026-07-01 row HAS an artifact, it IS on disk,
and it reproduces exactly (14 mismatched of 15 target ins, SIZE-MISMATCH/redraft). It is a
near-worthless draft on a DIFFERENT BODY: 0x8017C6F4 is 15 ins in ov_SC03_010/011/013 and
948 ins in ov_SC03_126/003 + ov_SC04_021 + ov_SC05_019 (§148-E, ledger side).
- THREE ledger defects fixed: (1) load_best keyed on ADDRESS ALONE -> the two bodies merged and
the lower ABSOLUTE closeness won, so 14-of-15-wrong (7% correct) masked 63-of-947 (93%);
now sub-keyed by known nins, legacy rows unchanged. (2) binary=null defaulted to ov_SC01_077,
where the fn does not exist AT ALL, and "not an open stub" was read as "banked" -> today's
result was invisible to render/grinder/target-selection (absent != done, R32/R34); now derive
binary from the draft path + only drop when closed everywhere it exists. (3) `log` had NO
--binary flag -- the root cause of every null; added + derived in append_record.
- IMPACT DERIVED, NOT ASSERTED (R37): replaying the pre-fix selection = 836 -> 837, 1 appeared
(func_8017C6F4 nins=947), 0 vanished. One row today; the mechanism would eat every future one.
- PROBED AND NOT BUILT: relative-closeness ranking (only 24/836 rows carry closeness+nins, and
the two orderings agree 14/15 on those). Documented in the log instead.
- ROOT CAUSE (reproduced): make_base_c ran cpp_expand_macros BEFORE #include lines were
dropped, so `cpp -P -nostdinc -` died on `#include "common.h"` (rc=1, empty stdout) and the
`return c` fallback handed back the UNEXPANDED draft. hide_asm then ate the gte_* #define
block + the function itself -> "Function not found in base.c" -> decomp-permuter no-opped
in 0s, indistinguishable at the call site from "searched, found nothing".
- FIX: strip #include inside cpp_expand_macros (byte-neutral) + RAISE on cpp failure (R32/R35,
no silent fallback); NEW defines_fn() assertion in setup() guards the OUTPUT so it catches
every swallow cause (this, the §G comment class, future macro shapes); main() catches per-fn
so a bad draft is loud+counted but cannot abort a batch.
- VERIFIED: func_8017C6F4 base.c keeps the def, 0 gte_ macros left, 35 asm b64-carriers;
proxy validated over 388 stored drafts = 0 false alarms, 0 cpp raises (macro-free untouched);
permuter now loads at base score 65 and iterates (was a 0s no-op).
- BLAST RADIUS (14,899 drafts scanned): 63 carry `#define … __asm__` + `#include`, incl. the
behemoth renderer drafts — the permuter was silently dead on the highest-byte-weight targets.
- CONSEQUENCE (R14): §147/§148's ~40-probe floors were measured with the permuter UNAVAILABLE;
"the permuter also plateaus" was never actually tested on those functions. §148 note corrected.
Answering "did you bank the results": the two serial functions did NOT match, so there was nothing
to bank (G3 -- NEAR is not a match). Everything that DID match this session is already banked and
committed (7 from the S4 redo, 24 wave exemplars + propagations, both giants x138).
But the drafts were about to be LOST, which is worse than not banking them:
.run/s42/ov_SC01_077/func_8017C294.c NEAR(12) of 246 ~245k subagent tokens
.run/s42/ov_SC03_126/func_8017C6F4.c NEAR(63) of 947 ~434k subagent tokens
.run/s42/ov_SC03_126/func_8017C6F4.pin-t5.c NEAR(47), pinned variant
All three were gitignored -- one `git clean` from gone (R20: commit irreplaceable work). Added a
curated /.run/s42/ allowlist and committed them. They are the best base any future attempt has:
func_8017C6F4 has frame 0x120 + vars=232 EXACT with only a register rotation left, and its permuter
has never been aimed at it (make_base_c fails on the gte_ macro block -- demacroize first).
Both logged to the backlog with today's MEASURED values, class, reach and draft path.
⚠️ LEDGER INTEGRITY, flagged not silently fixed: the backlog already held
`func_8017C6F4 closeness=14` (2026-07-01, ov_SC03_010, source=bulk-harvest) -- BETTER than today's
63, but with **draft: None, klass: None, nins: None, reach: None**. There is no artifact behind it
and no draft of it survives on disk (today's agent scanned every stored draft and found two, both
junk). `load_best` takes the LOWEST closeness per address, so this unverifiable row will out-rank
today's real, reproducible 63 in every future target selection.
This is the Phase-28 defect class (`func_80178004` recorded close=0 when it was 91). It is left in
place rather than deleted because deciding between "a lost good draft" and "a bad number" needs
evidence I do not have. **Whoever picks this up: treat the 14 as UNVERIFIED, start from the
committed 63/47 drafts, and if the 14 cannot be reproduced, purge the row.**
The general rule this argues for: a backlog row with no draft artifact is a rumour, not a result --
`backlog.py log` should require a draft path (or mark the row unverifiable) so an artifact-less
number cannot outrank a reproducible one.
Answering "did we do S4?" honestly: NO, not properly. The earlier pass re-gated only the NEWEST
stored draft per draft-exemplar head (8 banked of 35). S6 then proved that is sampling, not scanning
-- its giant's match was the 9th of 31 drafts, and my first pass had reported "closeness 40".
Redone with EVERY stored draft run through match_one, over the 39 draft-exemplar heads + Drew's
named large-function list (38 targets, 33 with drafts on disk):
14 of 33 targets MATCH from a stored draft (some had 51-57 drafts each)
-> 6 banked first pass, +1 after recover_giant = 7 banked
-> including func_8018057C (897 ins), which was on the "needs an agent" list
The 14 came overwhelmingly from ov_SC01_077 -- exactly the heads where only the newest draft had
been tried. The winning drafts sit in .run/_a10_sample-cn-cast-rc/, .run/drafts-wave-cn-cast/,
.run/drafts-wave-cn/, .run/ab-exp/opus-cn/, .run/backlog_drafts/ -- i.e. spread across many
historical pipelines, which is precisely why "newest" is the wrong selector.
7 still open after recovery (5 near, 2 failed) -- integration classes, drafts kept in .run/s41/rec/.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12483035 -> 12484373 instr; distinct +1,338 / +7 uniq; fn-count +7. instr-weighted 94.9%.
audit-digest OK. 0 NON_MATCHING (G4).
STILL OPEN from S4: the 263x5 cluster (0x80182fd4 exemplar) sweeps 0/5 with `parse error before
'unsigned'` in the spliced draft -- NOT the missing-type class, undiagnosed, do not assume codegen.
And the 2 resident stubs with gate-rejected match_one-MATCH drafts remain untouched.
THE RULE (cookbook §146, now paid for twice): SCAN every stored draft, never sample. A head with 57
drafts has 57 chances, and the pipelines that produced them differ in ways that matter.
The two functions the roadmap has carried as PERMANENT WALLS since Phase 24 are matched in all 138
overlays. Neither needed a siege. Both matched from drafts ALREADY ON DISK.
func_80178004 165 ins x 138 = 22,770 Phase 26: Fable5, ~477k tokens, "intrinsic 3-integer
regalloc wall". THREE stored drafts report match_one
MATCH today; one banked first try, no new work.
func_801412A8 198 ins x 138 = 27,324 close=29/110 since Phase 24. Matched from 1 of 31 stored
drafts + the §37/§124 alias.
WHY func_801412A8 LOOKED INTRINSIC (worth understanding — match_one is structurally blind to it):
the TU declares `extern int func_801412A8(int,int,int,int,int,int)` and its callers USE the return
(`param_1 = func_801412A8(...)`), while the byte-true definition is
`Prim_1412A8 *(Prim_1412A8 *, int, int, int, u16, u16)`. Narrow params cannot agree with an `int`
prototype and the no-prototype escape is illegal once a param promotes, so NEITHER side can move --
and the resulting byte difference is in the CALLERS, which match_one never compiles. The §37/§124
def-side asm-label alias decouples them: the TU decl keeps governing the call sites (codegen
untouched), the definition keeps its byte-true signature.
THEN PROPAGATION RETURNED 0/137 TWICE, both times a missing TYPE, not codegen:
family_remap's `_carry_macros` carries file-scope #defines but (a) NOT typedefs, and (b) is NOT
TRANSITIVE -- it brought addPrim_1412A8 and stopped, though that macro calls setaddr/getaddr and
getaddr casts to PTag_1412A8. Lifted Env_1412A8 / PTag_1412A8 / Prim_1412A8 + OT/getaddr/setaddr
into src/shared/engine_types.h (inside the include guard) -> 137/137, 0 failed.
MY ERROR, CAUGHT BY THE GATE: I lifted the typedefs but did not STRIP them from ov_SC01_077.c, so
they were declared twice and gcc-2.7.2 rejects a repeated typedef even when identical -- the lesson
already recorded at the foot of engine_types.h. R22 came back 139/140 with [FAIL] ov_SC01_077 (the
exemplar's own overlay). Stripped, re-verified, 140/140. A proper lift strips the source;
build_engine_types --strip does both and I did it by hand.
Also a measurement error worth recording: I checked whether the draft defined Prim_1412A8 with a
plain `grep -c` -- which matches inside `addPrim_1412A8` -- and briefly concluded the carry worked.
Substring false positive; the same shape as reading a `return` as a declaration.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12432941 -> 12483035 instr (+50,094 -- EXACTLY the two giants x138); fn-count +276;
instr-weighted 94.5% -> 94.8%. audit-digest OK. 0 NON_MATCHING (G4).
THE RULE THIS BUYS: re-measure a wall before respecting it, and SCAN every stored draft rather than
sampling (my first pass checked 8 of 31 and reported "closeness 40" for a function whose MATCH was
in the 9th). Four minutes of re-measurement was worth 50,094 instructions.
Propagation behind every crack, same session (the multiplier the waves exist for). 19 newly-banked
exemplars from waves 1+2, all in the family_sweep lane (0 has_mid_jr):
87 candidate members / 10,212 ins -> 61 BANKED / 26 failed across 39 overlays
The 26 that did not bank are the known plumbing shapes, not codegen: 20 CC1-FAIL + 5 callee
`conflicting types` (func_8017EFA0 x3, func_8012B23C x2) -- the same classes the S40 recovery ladder
already has levers for (§17a-1 no-proto + call-site cast; recover_giant block-scoping). Left open
deliberately rather than force-banked (P9); they are the cheapest fuel on the board next session.
TOOLING GAP RECORDED: the sweep's classifier writes "CC1-FAIL: make: *** Error 33" WITHOUT the actual
cc1 message, so 20 of 26 failures carry no actionable reason. Diagnosing one currently requires
manually splicing the draft into its TU and rebuilding (done twice this session). The classifier
should capture cc1 stderr the way harvest_verify already does -- worth fixing before the next big
sweep, or every CC1-FAIL costs a manual reproduction.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12425854 -> 12432941 instr (+7,087); distinct +6,145 / +51 uniq; fn-count +61.
instr-weighted back to 94.5% ON THE HONEST (post-main-regen) denominator of 13,160,961.
audit-digest OK. 0 NON_MATCHING (G4).
Two ultracode waves over the open-only h_norm clusters (the pool nobody had ever aimed a wave at),
pool VERIFIED from the sigs first (R14).
wave 1 8 targets 8/8 match_one 5/8 gate first pass -> 8/8 after recovery
wave 2 16 targets 16/16 match_one 14/16 gate first pass -> 16/16 after recovery
THE HEADLINE IS NOT 24/24 -- IT IS THAT NOT ONE FAILURE WAS CODEGEN. All six first-pass gate
failures were TU-integration plumbing, each with an already-documented lever:
func_801802EC redefinition of morph_lerp strip the §77 PROBE LAYER (the draft carries types +
a static inline so match_one can compile standalone;
the real TU already defines them -- scaffolding is
not part of the bank)
func_8018B238 conflicting types D_80115158 recover_giant: draft declared it file-scope as a
struct array, TU declares u8[] BLOCK-scope inside
other functions -> block-scope the draft's externs
func_8017EF54 conflicting types (SELF) §37/§124 def-side asm-label alias (TU declares
void f(void) for no-arg callers; byte-true def takes
s32 in $a0; no-proto escape illegal once a param
promotes)
func_80183D78 conflicting types (callee) recover_giant
func_8017F278 conflicting types func_80146C3C §17a-1: the fleet canonical is the NO-PROTOTYPE
form + the intended signature applied AT THE CALL
SITE; a concrete prototype collides with it
(wave-2's 14 first-pass banks needed nothing -- the wave-1 lessons were folded into the prompt)
=> the gate number measures INTEGRATION, not matching. Run the recovery ladder before recording a
wave's yield or the metrics under-report the drafters and send the next wave hunting walls that are
not there. docs/wave-metrics.md S40-1.
POOL VERIFICATION (R14, and it cut both ways): the frontier report's cluster pool MEASURED
1,677 clusters / 5,795 fns / 319,755 ins at a 3.68x multiplier vs its claimed 1,689 / 5,956 /
326,261 at 2.7x -- within 2-4%, and the multiplier is BETTER than claimed. The SAME document's whale
claim was 3/4 wrong. Verify each claim separately; do not accept or reject a source wholesale.
ALSO: 24/24 members propagated from wave 1's 5 banked exemplars (0 failed) -- the same machinery
that returned 0/39 before this session's cast_call_sites fix.
NEW IDIOMS, distilled in-session (R16/R30):
§144 the LITERAL'S SPELLING picks the immediate encoding (`cnt + 0xff` vs `cnt - 1`: mod-256
identical, both one addiu, but gcc emits 0x00FF vs 0xFFFF from the source text)
§145a combine_givs ANCHOR RULE -- the address-giv group anchors on the LAST address-giv in SOURCE
order (record_giv prepends, combine_givs takes the head); store order decides the base and a
wrong choice spawns a third induction register
§145b a bare `p = r;` is a COMBINE BARRIER (can_combine_p/use_crosses_set_p) -- it preserves a
pointer-bump addiu that combine would otherwise fold into every MEM offset
§145c chained assignment `a=b=c=0` emits stores RIGHT-TO-LEFT
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12420375 -> 12425854 instr (+5,479); distinct +5,479 / +43 uniq; fn-count +43.
audit-digest OK. 0 NON_MATCHING (G4). Cost: 3.73M subagent tokens across 24 agents, 0 errors.
THE BUG. tools/cast_call_sites.py classifies a declaration line with
^([ \t]*)(extern\s+)?([A-Za-z_][\w \t\*]*?)\b([A-Za-z_]\w*)\s*\(([^;{]*)\)\s*;
Feed it a return statement and `return` is a perfectly good identifier where a type is expected:
return func_8012CB64((s32)out, -0xC0, 0x40, -0x60, 0);
^^^^^^ captured as the return TYPE, func_8012CB64 as the DECLARED NAME
so the "rewrite this decl to canonical" path REPLACED the statement with
`extern s32 func_8012CB64(s32,s32,s32,s32,s32);`, DELETING the return. In C89 a declaration after a
statement is a parse error, so the damage surfaced as a bare syntax error in the DRAFT -- reading as
the draft's fault, not the tool's. 9 of 9 staged members of family 0x801848dc lost their return.
fix: a keyword guard (a declaration's type-specifier can never begin with a statement keyword)
family_sweep --hseq --band all over 5 families: 0/39 -> 18/39 banked (only the guard changed)
⚠️ AND THE TRAP INSIDE THE FIX: the obvious R33 move is "route it through cdecl". CHECKED, and it is
WRONG -- cdecl.parse() is a DECLARATOR-GRAMMAR parser that assumes it was handed a declaration; it
reports `return func_X(...);` as declaring func_X and `if (f(a));` as declaring `if`.
Statement-vs-declaration is a question cdecl does not answer. Routing there would have been a silent
non-fix that looked principled. §134's law still holds for line-SHAPE masking; this is a different
question.
BLAST RADIUS (measured, not assumed -- R14): cast_call_sites is in gate_stage's DEFAULT pipeline
(canon_resident_calls -> cast_call_sites -> sig_unify -> harvest_verify) and has been since Phase 20.
Of 44,833 stored drafts, 318 (0.7%) carry a `return f(...);` line this mis-reads, across 67 callees
(func_8014F468 x41, func_8014F6F4 x37, func_8014F74C x32, ratan2 x25). Every one, every time it
passed the gate pipeline, lost its return and failed as PLUMBING. Part of the historical plumbing
tail is this bug.
ALSO IN THIS COMMIT
- S5 CALIBRATION WAVE (8 agents, ultracode, 1.31M tokens). Pool VERIFIED FIRST (R14 -- Fable's whale
claim was 3/4 wrong): measured 1,677 clusters / 5,795 fns / 319,755 ins at a 3.68x multiplier vs
its claimed 1,689 / 5,956 / 326,261 at 2.7x -- its numbers hold, and the multiplier is BETTER.
Result: 8/8 match_one MATCH (close=0), and 5/8 banked whole-binary -- the §52b/§61 gap is
integration, not codegen. Banked: func_801822E0 func_8017EC98 func_801851A8 func_80189A34
func_80188E10 (693 ins x1 before propagation). Not banked: func_8018B238 (FAILED),
func_8017EF54 + func_801802EC (NEAR) -- drafts kept in .run/wave-s40/ for recovery.
- 18 member-banks from the re-run sweep (the cross-address free-h_exact pool: h_exact-identical at
DIFFERENT addresses, which dedup_propagate correctly refuses since it assumes position-locking --
family_sweep is the right lane).
- cookbook §143 (this bug + the cdecl trap + the blast radius); index regenerated.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12419169 -> 12420375 instr; distinct +1,526 / +5 uniq; fn-count +23. audit-digest OK.
0 NON_MATCHING (G4).
NEW IDIOM FROM THE WAVE, not yet folded into §31 (agent was told to write only its draft): a byte
counter must be spelled `cnt + 0xff`, NOT `cnt - 1`. Both are mod-256 identical and both compile to
one addiu, but gcc-2.7.2 picks the immediate encoding from the SOURCE SPELLING (0xFFFF vs 0x00FF).
Also flagged: .run/ghidra_c/func_8017EF54.c is a stale decompile of the WRONG function.
Drew asked whether we should build a master list of all funcs, a banked list, and a
MASTER_REMAINING = total - banked that we hand-edit on every bank. Assessment in
docs/decision-log.md (2026-08-04): ADOPT THE GOAL, REJECT THE MECHANISM.
The triple already exists and is DERIVED, not maintained:
total = .run/sig.*.jsonl (sig_image over the ORIGINAL bytes, independent of splat)
banked = sig - stubs (INCLUDE_ASM pastes the original asm => not-wrapped == byte-exact)
remaining = corpus.stubs() (filesystem-derived, coverage-asserted)
and "remove it when we bank it" already happens -- banking IS deleting the INCLUDE_ASM line. A
hand-maintained file would drift SILENTLY and flatteringly, which is the exact failure R33 exists
for (fuel_manifest recorded 130 live stubs when the truth was 30, hiding 91.6% of remaining gain).
What was genuinely missing is CROSS-ASSERTION. Six artifacts answer "what's left" -- corpus.stubs,
worklist, backlog, family_hseq, fuel_manifest, progress.fleet -- each individually derived, none
ever compared to the others. That is what cost P30 T0 a hand-reconciliation (family_hseq 29,961 vs
progress.py 28,296). R34: not a better assertion inside one oracle, but a second one that can argue.
tools/audit_frontier.py takes corpus.stubs as the reference and checks every other view against it:
rows/targets naming an already-banked function, and any view whose PUBLISHED count disagrees with a
recount. On first run it immediately caught a real one:
family_hseq publishes 11,456 unmatched instances; only 11,297 of its members are still open
per the corpus (delta +159) -- the map predates tonight's 159 banks. Ranking work off it would
have mis-scoped by that much.
It also PRINTS ITS OWN SCOPE LIMIT, deliberately: agreement here does NOT mean the denominator is
complete. Every view, and the byte-gate itself, is blind to never-onboarded code -- the 39 type-1
modules and main's missing independent boundary oracle stay open (R34/R36).
DELIBERATELY NOT wired into tools-health (Drew said "dont do this now" about the master list; this
is the additive half). --strict exits 1 for when he wants it binding; wiring is one line.
main's sig was dated 2026-06-14 and covered only 1,525 of its 2,002 INCLUDE_ASM stubs: 477
stubs were INVISIBLE to the weighted metrics, so main was being graded against two-thirds of
itself and the fleet denominator was understated.
tools/ghidra_mcp_stop.sh (R23 - clean stop, "Save succeeded", releases the .rep lock)
make sig-refresh BINARY=main -> DumpFunctionSignatures.java, read-only, -noanalysis
signatures 1,729 -> 2,205 (+476)
stubs covered 1,525 -> 2,001 of 2,002 (1 still uncovered, named below)
main .text ins 60,201 -> 79,510 (+19,309)
METRICS RE-BASELINED (a DENOMINATOR CORRECTION, not a regression -- the Phase-27 precedent,
where onboarding 4 hidden overlays honestly moved 68.9% -> 67.0%):
instr-weighted 94.5% -> 94.4% (12,419,169 / 13,160,961; numerator UNCHANGED)
distinct-code 89.3% -> 89.0% (5,029,454 / 5,654,184; numerator UNCHANGED)
fn-count 96.51% (unchanged -- it never read the sig)
MAIN game-code 0.72% -> 0.55% (436 / 79,510)
Both numerators are identical across the change; only the denominator grew. audit-digest OK.
CAVEAT UNCHANGED (R34): main still has no INDEPENDENT boundary oracle -- sig_image cannot sign a
PS-X EXE (header offset, interleaved islands), so main's function list rests on Ghidra alone and
audit-corpus cannot cross-check it. That is the open item in docs/second-oracle.md and part of
task #9's denominator work.
NOTE the sig itself is gitignored/regenerable, so this commit lands only the digests; a fresh
clone reproduces it with `make sig-refresh BINARY=main` (Ghidra required, MCP stopped).
MCP IS NOW DOWN (I stopped it for the project lock). The SessionStart hook restarts it next
session; run /mcp before any Ghidra work (R29).
§134 had been patched individually in six tools; the standing note said the fix is ONE masking
oracle, not a seventh regex (R33). The last two holdouts are migrated.
progress.py.strip_comments — a private 2-line regex, NOT string-aware, feeding three line-shape
decisions in classify(): the {-vs-; definition/declaration scan, the count('{')-count('}') body
walk, and the empty-vs-real body test. A brace inside a string literal therefore mis-buckets a
function in the FN-COUNT metric. Negative control:
void f(void) { puts("}"); x = 1; }
old regex -> body-depth -1 (the string's brace was counted)
cdecl._mask -> body-depth 0 (correct)
Metrics IDENTICAL before/after on today's corpus (341365/353717; REAL 339510, empty 896, stubs
12345) -- a latent defect, harmless until someone banks a function containing "{".
lint_symbol_refs.strip_comments_strings — correct, but a SECOND implementation of the same
masking. Deleted in favour of cdecl._mask. The one behavioural difference (_mask blanks the quote
DELIMITERS, the private scanner kept them) was CHECKED not assumed: irrelevant because every token
the linter hunts lives outside the quotes. Gated on the linter's OUTPUT being byte-identical across
the change (it is), not on the two masks being byte-identical -- the right gate is the tool's
answer, not its internals.
cookbook §141 + index regenerated. No src/ or config/ change; no bytes touched.
Measured the h_exact free pool from the bytes rather than trusting the frontier report's
numbers (R14 — its whale claim was 3/4 wrong: it said the whale was open in all four SC07
overlays; three were already banked and I closed the fourth earlier this session).
MEASURED: 215 open function-instances / 8,763 instructions are byte-identical (h_exact,
including reloc payloads) to an already-matched function. ONE class is 86% of that pool:
func_801758FC — 55 ins, same address in all 138 overlays, matched in ov_SC01_000 only,
OPEN in the other 137 => 7,535 instructions.
h_exact means identical INCLUDING jal/lui/%lo reloc immediates, so the matched body compiles
byte-identically at every member with NO remap (dedup_extend's correctness argument, §14).
dedup_propagate --addr authored it once as DEFINE_func_801758FC() in engine_core.h and
instantiated it at all 137 open sites in address order.
[ OK ] 138 overlays byte-identical after propagation; 1 new group in config/dedup.us.yaml
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet instr 12411467 -> 12419002 = +7,535 EXACTLY; fn-count +137; instr-weighted crosses to
94.5%. distinct-code unchanged BY DESIGN -- the class was already matched in ov_SC01_000, so
the 137 add fleet instructions but no new DISTINCT function. audit-digest OK. 0 NON_MATCHING.
Note this function had been sitting in the stored-draft backlog for ov_SC06_030 and
ov_SC07_010 and re-gated "no" earlier tonight -- because gating a DRAFT is the wrong move for
an h_exact class. The right move is propagating the already-MATCHED body. Same function, two
routes, and only one of them is free.
Remaining free pool after this: 78 instances / 1,228 ins across 32 classes.
The 39 draft-exemplar families all have their exemplar still OPEN in ov_SC01_077 -- a
draft-exemplar family cannot propagate until its head banks. Re-gated the newest stored
ov077 draft per head, in 4 small batches (§61: a wide harvest broke a TU in S38).
Set aside the top 4 heads (65% of the pool's weight, all known-hard): func_801412A8 +
func_80178004 ARE S6's two giant walls (198x138 + 165x138 = 50,094 ins riding on 2 cracks),
func_8017C974 is today's byte-proven close=47, func_8017C294 its 246-ins neighbour.
batch 0 1/9 batch 1 3/9 batch 2 4/9 batch 3 0/8 = 8/35 (23%)
BANKED: func_8017EC7C func_8018281C func_801820DC func_80182988 func_80183BAC
func_80183AF0 func_80183CF4 func_80182E7C
(+474 ins x1 now; ~1,441 ins of templatable weight behind them once their families propagate.)
CALIBRATION REFINEMENT (docs/calibration.md, S39): this population re-gates at 23%, vs 8%
for the general stored pool and 4/6 for fresh post-repair drafts. Three different populations,
three different rates -- which is exactly why the rule is "re-gate what a repair plausibly
touched", not "re-gate the ledger". ov_SC01_077 is the split-heaviest overlay, so the S38
alias-deletion repair plausibly touched all of these.
VERIFIED: make clean && make extract-all && make check-all -> 140 passed, 0 failed of 140.
Fleet 12410275 -> 12410749 instr (+474), distinct +474 / +8 uniq, fn-count +8. audit-digest OK.
0 NON_MATCHING (G4).
Tested whether decision-log A10 ("stored drafts re-gate at 0/958", measured in T1) survives
S38's tool repairs. Three populations, plain re-gate, no draft edits:
fresh wave-6 drafts (diagnosed "blocked on a class") 4/6
stored pool, unbiased sample (every 96th of 1,155) 1/12 <- hit was in a REVERTED overlay
the two REVERTED overlays, targeted 3/17
A10 BROADLY STANDS. ~8% on the general stored pool is not a harvest, and a 1,155-wide sweep
(= 1,155 whole-binary builds) is not justified by it. Do NOT generalise the fresh-draft rate
(4/6) onto the stored pool -- different populations. The honest rule is narrower and cheaper:
after a tool repair, re-gate the drafts THAT DEFECT plausibly touched, targeted by its
blast radius -- not the whole ledger. (R35 applied to the backlog, not just to metrics.)
BANKED (+146 ins): ov_SC06_030 func_80161208 + func_80162CCC; ov_SC07_010 func_801506A4 +
func_8016F0AC. R22 clean-fleet 140 passed, 0 failed of 140 -- which also proves byte-neutral a
fleet-shared engine_core.h edit the bank required (extern s32 func_801506A4(s32,s32) -> the
no-prototype form), reaching all 138 overlays (T2 blast radius).
Fleet 12410129 -> 12410275 instr; distinct +95 / +1 uniq; fn-count +4. audit-digest OK.
Also documents the LEDGER MECHANICS in calibration.md (Drew asked): .run/backlog.jsonl is
append-only and nothing is deleted on bank -- open-ness is DERIVED from corpus.stubs at every
read (load_best drops now-banked rows per-binary, P9) and `make report` runs `backlog.py prune`.
Membership is therefore self-maintaining and currently clean: 863 rows, 0 already-banked, 14
duplicate-addr (was 6,867 rows / 98% banked before Phase-29 compaction). What pruning does NOT
re-validate is the VERDICT on surviving rows -- closeness + residual class are as old as the
tooling that wrote them (Phase 28 found a corrupt one: func_80178004 close=0 -> 91). That is
the staleness that matters, and it is exactly what this probe measured.
Drew T