mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-28 14:59:48 -04:00
85fb289db582d842fc41dc059fa187bb992e76ea
81 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Drew T
|
b0c1e14fda |
feat(phase-30 S46-final): 400+ cascade banked (11) + waste-prevention gate; B re-scoped, C blocked
- BANKED: 11 functions at 400-952 ins from the cascade (func_8017D898 952, func_8017CE58 733,
func_801902EC 673, func_8018C2D8 673, func_8018A8D4, func_8017C6F4, func_800CBB38,
func_800CF3A4, +3). check-all 213/213 from a clean tree. 6 near = jr/switch (§53 separate
banking step), 1 failed. The cascade agents wrote 6 new cookbook sections incl. §158.
⚠️ tools-health UNVERIFIED at commit (stale cookbook index fixed, confirming re-run
interrupted) — run it first next session. check-all is the byte oracle and it is green.
- WASTE PREVENTION (Drew: "prevent this from ever happening again, however you need to"):
* tools/validate_targets.py (NEW) — names 5 defect classes (NO-ASM / MID-BODY /
OUT-OF-RANGE / ALREADY-DONE / NO-BOUNDARY), exits non-zero.
* WIRED INTO wave_snapshot so it fails closed — every wave passes through there for its .s
files, so no path from target list to spawned agents bypasses validation. Negative-control:
a 3-target bad list is refused with the exact mid-body offset (+72 bytes of 100).
* The cascade `done()` predicate now short-circuits on SKIPPED as well as MATCH. It tested
only MATCH, so a non-existent target fell Sonnet -> Opus -> Fable and three agents each
proved the same phantom absent: ~29 invalid targets x 3 tiers = 87 of 119 agents, ~9.7M
tokens. A tier that cannot act must END the pipeline, not escalate emptiness.
* docs/accelerators.md A9, including that wave_snapshot's own R32 assertion REFUSED that list
(24 of 57 found) and was routed around — the one instrument warning that was right and ignored.
- B RE-SCOPED (S46-10) and deliberately NOT done: the extend blocker is INTRA-HEADER, not
target-side. engine_core.h declares memcpy FOUR incompatible ways across its DEFINE_ macros;
two in one TU collide. NOT a safe cleanup — the in-tree note at ov_MAIN_012.c:14333 records
that `extern memcpy` disables gcc's builtin and turns an inlined block-move into a CALL, so the
declaration CHANGES CODEGEN. Probe one macro in one binary and byte-gate before any sweep.
- C (dedup_extend over the 129) stays blocked on B. Full context for both in the checkpoint.
|
||
|
Drew T
|
37c60a5ff3 |
feat(phase-30 S43): R22 CONFIRMS ALL 18 BANKS 140/140 — fleet 94.99% instr; §147 refuted by the bytes
- ✅ R22 CLEAN-FLEET: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
Discharges the [R22 PENDING] caveats on commit:1486 (the 0xECC family x12) and commit:1487
(func_8018D98C). All 18 of today's banks are confirmed, not incremental artifacts (§130).
- FLEET: 96.63% fn-count / 94.99% instr-weighted (12,501,204/13,160,961) / 89.4% distinct-code.
Session +16,831 instructions, 18 functions. P30's 95% instr bar is 1,708 instructions away
(18,539 at session open). NOTE the report line rounds to "95.0%" — the bar is NOT yet met.
- THE 5th WAVE AGENT: func_8017CE58 is TWO bodies at one address (246 in SC02_000/003, 734 in
SC03_092). The 246 body is byte-identical to func_8017C294 — THE FUNCTION §147 WAS WRITTEN FROM —
so one draft covers 4 instances, and it went 12 (with a recorded "stop searching" verdict) -> 2.
- §147 CORRECTED IN PLACE (H5: original text preserved, correction appended):
* A "stratum 3, unreachable from C" is REFUTED — there is NO stratum 3. The frame is declared
locals then reload spill slots in pseudo-regno order; the mystery 0x108 slot is an ordinary
spill on a loop.c-created pseudo, reachable by writing the loop as an INDEX loop (a pointer
walk puts it at the bottom). Prior drafts faked it with volatile pEnd + dead[7]. (121 -> 54)
* B the unreferenced slots are combine-orphaned sign-extension intermediates (combine.c:10839),
not "?: on memory" frame cost.
* E the qty_compare tie IS breakable — §148-C's zero-emission ref slider. (30 -> 25)
* D applied properly (drop volatile out + the $24 pin, let a1 spill) remains: 54 -> 30.
- CONSEQUENCE: func_8017C294's 15 siblings were parked "until stratum 3 is explained" — that hold
is VOID. Both near-misses logged to the ledger with their measured closeness, not forced (P9).
- PROCESS LESSON in §147: a confident NEGATIVE verdict is a claim like any other — date it, name
its evidence, and re-measure it before letting it park work (same shape as §146).
|
||
|
Drew T
|
01d7d3276c |
feat(phase-30 S43): FABLE5 CRACKS func_8017EF68 (the 2-of-969 wedge); R22 CONFIRMS ALL FIVE BANKS 140/140
- func_8017EF68 MATCH 969/969, re-verified by me, gated: ov_SC06_000 byte-identical at da4a26ff.
- MECHANISM (from cc1's own -dR trace, not inferred): the r3000 machine description gives the
memory unit load-ready-cost 2 / store 1, so blockage(load,store)=2 — a LOAD CAN NEVER BE PICKED
IN THE TICK IMMEDIATELY AFTER A STORE PICK. sched2 therefore always wedges one ready ALU insn
between the lw and the sh, and the target's zero-wedge order is UNREACHABLE BY ANY STATEMENT
ORDER. That is why ~20 documented hand variants AND the repaired permuter both floored at 2.
The draft's own §49 sched1-LUID story was incomplete — real but secondary.
- THE LEVER (cookbook §151, "the ghost wedge"): a zero-emission tied in/out asm
`__asm__("" : "=r"(v) : "0"(v), "r"(rival));` — 0 bytes, but a schedulable insn that absorbs the
blocked tick, and it sets reg_n_sets(v)=2 which also kills sched1's birthing boost (one
instrument, both passes). Two measured fallouts: rival-read in the same asm (22->12), then a
second re-tie on a HIGH-REF host to restore allocno live-length parity (each in-loop insn is +1
live length for every loop-spanning allocno; a trio of invariant addresses sat exactly on
allocno_compare's integer-floor boundary). Host choice empirical: pkt=MATCH, ot=705, double=10.
- ✅ R22 CLEAN-FLEET: make clean && extract-all && check-all -> 140 passed, 0 failed of 140.
This DISCHARGES the [R22 PENDING] caveat on commit:1484 — all five banks are confirmed, not
incremental-build artifacts (§130).
- FLEET: 96.63% fn-count / 94.9% instr-weighted (12,489,130/13,160,961) / 89.2% distinct-code;
0 NON_MATCHING (G4); dedup 1919 groups. Session +4,757 ins from 2 cracks x 5 binaries.
Distance to P30's 95% instr bar: 13,782 ins (was 18,539 at session start).
|
||
|
Drew T
|
25402b2eb4 |
feat(phase-30 S43): FABLE5 CRACKS func_8017C6F4 pin-free — banked ×4 (~3,788 ins) [R22 PENDING]
⚠️ R22 CLEAN-FLEET VERIFY IS OWED, NOT DONE. All four gates below were INCREMENTAL builds
(§130: an incremental build can report BYTE-IDENTICAL for a change a clean build cannot link).
Committed now only to protect the work — a second Fable5 agent is reading asm/, so `make clean`
would destroy its inputs mid-run. The clean-fleet run follows the moment that agent finishes;
treat these four banks as UNCONFIRMED until then.
- THE CRACK (Drew approved the Fable5 escalation, R27): byte-exact, PIN-FREE, 947 ins. My §147-E
"qty_compare tie, unreachable from source" diagnosis was WRONG. The residual was VARIABLE
IDENTITY: (1) the X-pass and Y-pass min/max intermediates are DIFFERENT variables (8, not 4
reused); (2) mnc/mxc do not exist — the cell clamps reuse the prim-loop mn/mx (X) and mny/my (Y).
Ablations: split-only 63, reuse-only 624, conjunction MATCH. That is also why S42's "separate
X vs Y variables" probe was filed as a failure (it was half the fix), and why every allocator
lever was inert — pins, §148-C sliders, declaration order and 14 permuter restarts cannot reach
a draft with the wrong NUMBER OF PSEUDOS.
- VERIFIED INDEPENDENTLY BEFORE BELIEVING IT (R14): I re-ran match_one -> MATCH (947 ins), then
the whole-binary gate per binary.
- BANKED ×4 (every 948-ins sibling of this body), each byte-identical:
ov_SC03_126 c48a8bb8 · ov_SC03_003 898bf52a · ov_SC04_021 33614234 · ov_SC05_019 3f5b4f13.
family_remap produced all three siblings cleanly.
- §146 SEEN AGAIN: all three siblings first failed with `PLUMBING: parse error before 'MTX_C6F4'`
— _carry_macros carries #defines but NOT typedefs; prepending the 9 typedef lines fixed all
three. That label is legible ONLY because of this session's classifier fix; before it, it read
"CC1-FAIL: make: *** Error N" and cost a manual splice-and-rebuild each.
- cookbook §150 (decode register ownership from the MATCHING diff regions before touching the
allocator; per-instance register asymmetry ⇒ per-instance variables; the deleted-self-move tell
and the global.c:719-vs-:729 death-before-store exemption behind it). §147-E corrected: it named
the wrong allocator — these are global.c allocnos, not local qty_compare quantities.
|
||
|
Drew T
|
f5ea22b4f5 |
feat(phase-30 S43): serial queue — func_8017EF68 is at 2 of 969, and was scanned against the WRONG BODY
- 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.
|
||
|
Drew T
|
e75ed7adcc |
docs(phase-30 S43): checkpoint — the permuter takes 63->41 and plateaus; evidence preserved
- 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. |
||
|
Drew T
|
fa122cf62f |
fix(phase-30 S43): permuter takes func_8017C6F4 63->42; the "rumour row" was an ADDRESS COLLISION
- 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. |
||
|
Drew T
|
35d00fe3ec |
chore(phase-30 S42): PRESERVE the two serial NEAR drafts + log them; flag a draft-less ledger row
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.
|
||
|
Drew T
|
e879ec6da2 |
feat(phase-30 S4-redo): SCAN don't SAMPLE — 14 matches found on disk, 7 banked (+1,338 ins)
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. |
||
|
Drew T
|
9f61cd33c5 |
feat(phase-30 S6): BOTH GIANT WALLS CRACKED ×138 (+50,094 ins) — the verdicts were stale, not wrong
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.
|
||
|
Drew T
|
669367dab0 |
feat(phase-30 S40): propagate the 19 wave exemplars — 61/87 members banked (+7,087 ins), R22 140/140
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). |
||
|
Drew T
|
443a3e3afe |
feat(phase-30 S40): waves 1+2 bank 24/24 after recovery — ZERO codegen walls; +5,479 ins
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.
|
||
|
Drew T
|
6e0b1605c6 |
fix(phase-30 S40): cast_call_sites read a RETURN as a prototype and deleted it — 0/39 sweep becomes 18/39
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 T
|
638f97dbbb | feat(phase-30 S39): propagate free h_exact class 0x80176144 (53 ins x 1) - R22 140/140 | ||
|
Drew T
|
c3bf1c988d |
feat(phase-30 S39): func_801758FC propagated x137 (+7,535 ins) — the largest free h_exact class
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. |
||
|
Drew T
|
0414171237 |
feat(phase-30 S39/S4): 8/35 draft-exemplar heads re-gate and bank (+474 ins, 4 gate cycles, 0 agent tokens)
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).
|
||
|
Drew T
|
7b5eda0424 |
feat(phase-30 S39/S4): re-gate probe — A10 broadly stands; 4 banked from the reverted overlays (+146 ins)
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
|
d8016c49c8 |
docs(phase-30 S38): checkpoint v4 — POST-S1d, fresh-session safe
Refreshes a checkpoint that had gone stale (v3 predated S1d) — stale is worse than absent. FLEET 96.46 / 94.4 / 89.2, +37,166 instructions this session, ~0 agent tokens after the opening wave. R22 run thirteen times: 140/140 on eleven, TWO REAL FAILURES (ov_SC07_010, ov_SC06_030), both caught by the clean-tree rebuild after passing their per-binary gate, both reverted and recorded. Records the session's biggest find: the §37/§124 DEFINITION-SIDE ASM-LABEL ALIAS is a CLASS lever, not a one-off. It cracked the 208-conflict narrow-parameter class 138/138 after cast_call_sites, --normalize-self-decls and --fix-def-sig were each eliminated BY MEASUREMENT. S33 proved it once and it was never generalised. Carries the unresolved accounting anomaly prominently (new task #11 / S1e): distinct-code FELL 89.3 -> 89.2 across the alias harvest while fn-count ROSE, which no pure naming artifact explains. The bytes are proven; the yield number is not. Next session starts there, before scaling the lever. Also records eleven tool defects fixed (nine of ten "walls" were our own instruments, two of them mine), that §134 has now appeared in SIX tools and wants cdecl._mask rather than a seventh patch, and seven process errors of my own including piping away a gate summary I then could not report. |
||
|
Drew T
|
10f9546272 |
chore: regenerate the fleet digest + backlog after S1/S2/S3
docs/progress.fleet.md is the authoritative metric source the checkpoint's staleness self-check compares against — committing it keeps that check meaningful for the next session. |
||
|
Drew T
|
6fe9b66f2d |
feat(phase-30 S6h): wave 3 — 34/38 banked, +639 members, reconcile lane now 12/12 (R22 140/140)
- 38 targets / 44,297 templ ins, model-routed (Haiku <=89 + Opus escalation, Opus direct >=90):
52 agents, ~4.1M tokens -> gate 27/38 (71%). All 11 failures captured + classified: 8 declaration/
link plumbing, 3 genuine byte-DIFF. An 8-agent Opus reconcile wave fixed 8/8 (7 banked) ->
wave-3 total 34/38 = 89%. Propagation +639 members / 1 failed / 83 overlays.
R22 clean-fleet 140/140. Fleet 95.42% fn / 92.4% instr / 85.5% distinct.
- DESIGN (S27 law applied BEFORE it bit): six of eight reconcile targets share ONE TU, so this wave
FORBADE agents any build — six concurrent splice-builds would have clobbered a tracked file.
- THE AGENTS OUT-DIAGNOSED MY BLOCKERS:
* func_801848B0 — an agent REJECTED MY PREMISE: I said byte-correct + decl-blocked; it ran
match_one first, found a real 1-ins DIFF, fixed both. R14 aimed back at me, correctly.
* func_8017C5F0 — the "invented symbol" D_801DA0F0 is an INTERIOR ADDRESS: offset 0x6C into
D_801DA084 (0x801DA084..0x801DA103). The lui/addiu pair builds an interior pointer.
* func_8018A860 — the TU declares memcpy THREE times with incompatible signatures, with a latent
byte bug behind it. One symbol declared three ways is a defect awaiting the next draft.
- Carried (4): func_80184A94 (match_one MATCH, gate-refused) + 3 genuine byte-DIFFs
(func_801845B0, func_8017BEBC@ov_SC02_026, func_8018480C).
|
||
|
Drew T
|
372dc62d35 |
feat(phase-30 S6g): wave 2 — 93% bank rate (was 83%), all 4 reconciles closed, +342 members (R22 140/140)
- 15 targets (11 fresh Haiku + 4 gate-failed reconciles on Opus), 15 agents, ~0.74M tokens.
Gate banked 14/15 (93%) vs wave 1's 20/24 (83%); ALL 4 RECONCILES BANKED.
Propagation +328 members / 0 failed / 76 overlays. R22 clean-fleet 140/140.
Fleet 95.23% fn-count / 92.1% instr / 85.0% distinct (phase opened 92.00 / 87.5 / 78.0).
- THE 83->93% CAME FROM THREE FIXES, ONE PER WAVE-1 FAILURE (the S27 finding reproducing):
(1) args pasted from the DERIVED manifest, never typed — all 30 paths verified on disk first;
(2) blocker-capture BEFORE the reconcile fan-out (S29 law: agents cannot run the gate, so a
match_one-MATCH draft dying on `conflicting types` reads to them as a codegen wall) —
each got the exact symbol+line plus the two byte-neutral levers;
(3) wave-1's Opus DISCOVERIES became wave-2's Haiku INSTRUCTIONS (ori-vs-addiu unsigned
destination; store-sinking scheduler order).
- THE RECONCILES OUT-DIAGNOSED MY CAPTURE: func_80189B78's error named ONE symbol; the agent found
SIX invented prototypes, two AFTER the splice point where cc1 had not yet reached — all fixed by
copying the TU's decls verbatim + casting at the call site, zero bytes changed. func_8018584C had
lever (A) blocked in BOTH directions (the draft must also compile standalone for match_one) and
closed with the DATA form of the asm-label alias. func_80180A4C was one character class (s32[] vs
the TU's u8[], declared 11 lines after the splice point).
- Carried: func_80189C4C (the one agent that returned no structured result; gate refused).
|
||
|
Drew T
|
6e181db771 |
feat(phase-30 S6f): B-shaped wave — Haiku drafts, Opus closes, +544 members (R22 140/140)
- POOL (derived from the regenerated map): 36 families / 28,829 templatable ins, kind=modal (no member matched ANYWHERE so no sweep could reach them), >=20 members, <=60 ins, non-jr, and NOT ONE exemplar in ov_SC01_077. Hand-calibrated 3/3 one-shot before scaling (Phase-15/18 discipline). - WAVE (ultracode; Haiku drafters + Opus escalation, 24 targets): 31 agents, 0 errors, ~2.0M tokens, 12.5 min. Agents claimed 24/24 MATCH; the whole-binary gate banked 20/24 (83%); propagation +524 members / 0 failed / 91 overlays. 17 of 20 banks were HAIKU, 3 Opus — the cheap-tier-ab-validated call (Haiku == Opus at <=~50 ins, ~4.8x cheaper) held on real work. - WHAT OPUS BOUGHT: (1) a `sh` of a constant with the stored width's top bit set needs a u16 destination — via s16 gcc folds it sign-extended and li emits addiu, via u16 force_fit_type keeps it positive and li emits ori; (2) a schedule-reorder closed by STATEMENT ORDER not the permuter (gcc's list scheduler preserves relative order of disambiguable stores); (3) three loose-typing fn-ptr casts a cheap drafter had misread as delay-slot/permuter residuals. - MY ERROR (R37/R14): I generated the manifest to .run/s6f_wave_targets.json then HAND-TRANSCRIBED the args into the Workflow call, pattern-filling _jr_8017BEBC across overlays where no such split exists (corpus.stubs says _jr_8017AE2C). Three agents lost time rediscovering real paths. The gate driver written after (.run/s6f_gate.py) DERIVES every TU/split from corpus.stubs and asserts nothing. Assert nothing you can derive. - The 24->20 gap is the known match_one->gate gap (standalone compile cannot see a TU decl conflict; Phase 19 measured 88-92% -> 60-71%). 4 carried: func_8018584C, func_80180A4C, func_8017CC80, func_80189B78. - R22 clean-fleet 140/140. Fleet 95.13% fn-count / 92.0% instr / 84.9% distinct (phase opened 92.00 / 87.5 / 78.0). |
||
|
Drew T
|
e6cec30736 |
feat(phase-30 S6f): calibrate the B-shaped vein — 3/3 one-shot by hand, +65 members (R22 140/140)
- func_8017E934 (ov_SC05_001, 29 ins x65): hand-drafted off the .s, match_one MATCH first try, whole-binary gate byte-identical, propagated 64 members / 0 failed across 63 overlays. - That makes the B-shaped lane 3-for-3 one-shot (func_8017CDD8 17ins, func_8017CE7C 16ins, func_8017E934 29ins) for ~0 agent tokens = 330 member-matches from 62 instructions of C. - THE POOL (derived from the regenerated map): 36 families / 28,829 templatable ins that are kind=modal (NO member matched anywhere, so no sweep could ever reach them) with >=20 members and <=60 ins, non-jr. NOT ONE exemplar is in ov_SC01_077 — they are invisible to exactly the two habits this phase already corrected (the ov077-source default and --band substantial). - The calibrated recipe, now the wave prompt: read the .s as ground truth (a cached Ghidra-C seed was measured this session decompiling a DIFFERENT body) -> conform every callee decl to what the TU already says (the PLUMBING class: standalone-MATCH C is gate-REJECTED as `conflicting types` when it redeclares a callee the TU defines as (void)) -> match_one -> whole-binary gate. - R22 clean-fleet 140/140; fleet 94.96% fn-count / 91.9% instr / 84.7% distinct. |
||
|
Drew T
|
381cd56d40 |
feat(phase-30 B): the x138 era was NOT over — 2 tiny cracks -> 268 members (R22 140/140)
- A: frontier regen at HEAD (sigs + family_hseq) before pricing anything (R35). Also the reason
it was needed: .run/hseq_verified.*.txt has accumulated 22,841 files across every sweep ever
run, so any per-family analysis globbing them over-counts; the regenerated map derives state
from sigs + corpus.stubs (R33), which is the authority.
- B / THE FINDING (third §133-class miss in a row): the S29 checkpoint's structural signal
"after S2 the x138 era ENDS — those are the last two crackable fleet-wide families" — the stated
TRIGGER for the phase close — is wrong. Two fresh-crack families with >=126 members were open:
0x8017cdd8 ov_SC02_039 17 ins x 142 members PURE
0x8017ce7c ov_SC03_114 16 ins x 126 members IMM
Both kind=modal (NO member matched anywhere, so no sweep could reach them) and neither exemplar
in ov_SC01_077 — invisible to exactly the two habits this phase already corrected.
- Both hand-drafted off the .s, match_one MATCH on the FIRST try, ~0 agent tokens. First gate
attempt failed PLUMBING (not DIFF): the draft declared `extern void func_8017CFCC(s32 a0)` while
the TU DEFINES `void func_8017CFCC(void)` — the target passes $a0 only because the caller's
incoming argument still sits in the register (loose typing). Byte-true C calls it with no
argument; re-verified MATCH, gated byte-identical, propagated 266 members / 0 failed / 118 overlays.
- R14 on the seed: the cached Ghidra-C for func_8017CE7C decompiled an entirely DIFFERENT body
(three calls absent from the asm). Reading the .s is what made it one-shot.
- R22 clean-fleet 140/140. Fleet 94.88->94.96% fn-count, 91.9% instr, 84.6->84.7% distinct.
|
||
|
Drew T
|
aa600c56ef |
fix(phase-30 S6e): family_sweep snapshotted TUs it never edited — the self-decl lever measures 0, honestly
- D6: hseq_sweep took the tu_snapshots snapshot UNCONDITIONALLY, one line before the `if nfix:` that decides whether to edit. A TU that normalize_self_decls merely INSPECTED was therefore registered, and the phase-2 MISMATCH backstop attributed ANY group failure to a "self-decl edit" that was never made -> revert + `0/N banked`. Measured: 909 of 909 groups took that branch while NSD actually fires on ~25% of members (3 of 12 probed). The §103 tu-scope path below has always snapshotted inside `if _rep["moved"]:`; NSD now matches it. - After the fix: NON-NEUTRAL 909 -> 303 (consistent with the fire rate) and STILL 0 banked — the 606 groups that now take the normal path bank nothing, so the lever's verdict is REAL, not an artifact: this residue is not self-decl-conflict-bound. Lever measured, closed, zero. - R14 on my own conclusion: I byte-measured a firing case instead of trusting the backstop — func_80162CCC/ov_SC01_000 builds to 9052dc0e... WITH and WITHOUT the NSD edit (byte-NEUTRAL), so the surviving 303 verdicts are wrong too (likely accumulated multi-member edits in one TU). Logged as a named open item, not chased: the lever yields 0 either way. - The tell, twice in one session (§134): a 100% rate is a property of the mechanism, not of 1,622 different functions. Three earlier sweeps over the same population reported 0 NON-NEUTRAL. |
||
|
Drew T
|
21ccb171ac |
feat(phase-30 UC): wave-2 propagation — 2,192 members, fleet 91.4% instr (R22 140/140)
19/19 wave-2 heads banked and propagated: 2,192 member-matches / 411 stage-but-DIFF residue (each individually gate-rejected and reverted). FLEET 94.43% fn / 91.4% instr / 84.0% distinct; dedup 1905/0; 0 NON_MATCHING (G4). Session arc: 93.25->94.43 fn / 89.2->91.4 instr / 80.5->84.0 distinct. Phase arc: 92.00->94.43 fn / 87.5->91.4 instr / 78.0->84.0 distinct. |
||
|
Drew T
|
1a1463b1c6 |
feat(phase-30 UC): wave-1 propagation — 1,370 member instances, fleet 90.9% instr (R22 140/140)
- 9 banked heads propagated: 1,096 non-jr member-matches (family_sweep --hseq --band all, 0 failed) + 137 (func_80159A20, jr) + 137 (func_801549F8, jr) - func_80176734 (371 ins, the largest single item in the frontier) banked + propagated - FLEET 93.81% fn / 90.9% instr / 83.9% distinct; dedup 1905/0; 0 NON_MATCHING (G4) - cookbook §132b (--span-rel: the already-matched owner that is ITSELF multi-switch) and §133 (the DEFAULT-FILTER class — three times in one session a tool silently answered a narrower question than the one asked: my own >=80-ins cut, worklist's h_exact pricing, --band substantial) |
||
|
Drew T
|
4a23c82a33 | feat(phase-30 S2): func_8016EC0C x138 complete — 137/137 siblings, fleet 90.1% instr (R22 140/140) | ||
|
Drew T
|
56210fdadd |
feat(phase-30 S1): zero-crack tier — 186 members banked; fleet crosses 90% instr
- head func_8014032C 137/137 (25,071 ins, --span-rel §132b) + jr tier 46 members incl.
func_8017BEBC 13/13 (12,376), func_8015A3C8 6/6, func_8015AE2C 4/4, func_8017A4AC 4/4,
func_8013FFD8 9/10 + non-jr pass 3.
- MY ROUTING ERROR (recorded): pass 1 ran all 28 families through jtbl_family_bank; 13 are NOT
jr functions, so they carve-failed by construction — §123's own law ('propagate a family with
the tool its TIER needs'), which I had quoted in the task description. Re-routed via
family_sweep --hseq: 3 banked / 38 failed => that residue is the genuine stage-but-DIFF class.
- MEASURED: 13 of 29 zero-crack families have remaining members ONLY in the 4 P27-onboarded SC07
overlays (18,856 ins) — not a stub-count gap; they simply missed every sweep that predates them.
- R22 clean-fleet 140/140. Fleet 93.38% fn / 90.0% instr / 82.4% distinct; dedup 1905/0.
Phase arc: +1.38pp fn / +2.5pp instr / +4.4pp distinct.
|
||
|
Drew T
|
b9efe66f91 |
fix(phase-30): the JR-PAIR "wall" was TWO instrument defects — pair banked, class retired
S28 ledgered `JR-PAIR-IN-ONE-O0-OBJECT` (two jr fns matched in one -O0 object => a clean build that cannot link: `undefined reference to $L105` + `func_8013C938`) with §81 step 1 (isolate one into its own code subseg) as the untested escape. BOTH the class and the escape are REFUTED — no isolation, no compiler wall, both fns banked from a genuinely clean fleet. The 4th consecutive "structural wall" to resolve to our own tooling (§124/§125/§126/§131). - DEFECT 1 (tools/jtbl_carve.py): ov_SC01_077_o0's carve at 0xb01a4 predates the §8e `tables=` persistence and is a MERGED DOUBLE (func_8013C0F8 $L75 + func_8013C414 $L105); the 2nd owner is MATCHED so extract pruned the stub .s naming its table. The single-table- predecessor inference derived 3 starts where the object emits 4 tables -> JTBL_PADS 0,4,4 -> jtbl_rodata_pads refused mid-stream, correctly. FIX: R32 coverage assertion + payload recovery at the single choke point (spec_from_starts) — every zero word inside a span is an original `.align 3` pad (the tool's own axiom), so the word after it STARTS a table; recovered starts are logged. No-op where structure is known (the 134 sibling _o0c spans carry tables=+0x0,+0x70). Honest limit: tight (0-pad) boundaries stay unrecoverable but fail LOUD via the filter's count guard — never silent. - DEFECT 2 (Makefile): no .DELETE_ON_ERROR, so `as` (a pipeline consumer) left a TRUNCATED .o on disk — 12 of 16 T func_, undefined $L57/$L59/$L63/$L75/$L76 — newer than its .c, and the NEXT build linked the corpse. That IS the S28 link error, one build downstream of a loud, correct compile error. Negative-control-proven on a scratch invocation. - BANKED: func_8013B83C (272 ins) + func_8013BD74 (198 ins) in ov_SC01_077 (d19c9580). Byte proof: 4 tables 0x801D8254/828C/82FC/836C (13/27/27/27 entries, each zero-pad separated); span 0xb00fc..0xb0280 = 388 B = 52+4+108+4+108+4+108 exactly; spec 0,4,4,4. - R22 clean-fleet (make clean + extract-all + check-all): 140 passed, 0 failed of 140. The incremental result was NOT trusted (§130). Fleet 93.25% fn-count / 89.2% instr / 80.5% distinct; dedup 1905/0; 0 NON_MATCHING (G4). - cookbook §132 + index (356 sections): the mechanism, the fingerprint (an undefined $L<n> in a LINK error is a truncated object, never codegen), the 30-second standalone-TU ladder that named the 4th table owner before any build, and the transferable rule — a fail-loud guard is only as trustworthy as the artifact hygiene around it. |
||
|
Drew T
|
b58fd82068 |
docs(phase-30): SS131 the jtbl OVER-SPAN + checkpoint — #9 SOLVED, JTBL-CARVE-BREAKS-BYTES retired
SS131: `sltiu N` is ground truth in BOTH directions. jtbl_range already EXTENDS a span the dlabel cut short and WARNS when a span is shorter than the bound, but had no clamp for a span too LONG for a NON-ZERO reason — and the trailing trim only removes ZERO words, so ordinary data that spimdisasm ran into the dlabel slipped through and under-filled the piece. Records the reusable FINGERPRINT of an under-fill, because it does not look like codegen: hundreds of 1-byte diffs spread over most of the overlay, ~95% at byte 0 (mod 4) = the low byte of a 16-bit immediate, every one changing by exactly -4. Bucket differing bytes by offset%4 and decode a few words; uniform small deltas in the immediate field mean LAYOUT, not codegen. (Measured: 812 of 853 at pos 0 mod 4, all -4.) The clamp's authorization matches the extension path exactly: unambiguous sltiu bound only, and REFUSE LOUDLY if any surplus word is a plausible code address. This was the single instrument failure that survived SS125's retraction round — the one case where "the tool is broken" was actually true. Now fixed, with the 710-ins behemoth banked. |
||
|
Drew T
|
20e970a928 |
docs(phase-30): SESSION-28 CHECKPOINT — fresh-session handoff for T1/T3, Max prompt for #9
Fleet 93.25% fn-count / 89.2% instr / 80.5% distinct; R22 140/140 (thirteen runs). Nothing running, tree clean, lock FREE. Records for the fresh session: the ordered resume list (T1 + T3 need /effort ultracode and a WAIT for the toggle; #9 and T5 need Max), the JR-PAIR-IN-ONE-O0-OBJECT wall with its untested SS81-step-1 escape, and the S28 ROI evidence that a 15-target wave bought 12 banks and +0.00pp headline — so waves are only worth resuming against HIGH-REACH targets. Flags the milestone reality plainly rather than leaving it for T5 to discover: 89.2% instr against a >=95% bar, with the remaining volume in main + the 39 type-1 modules (P31 scope). P30 realistically closes on the milestone's LEDGER branch, which is an explicit either/or in the approved milestone — Drew's call, deliberately. Adds the S28 HONESTY LEDGER: five wrong calls this session, each caught by an oracle, none committed. The standing consequence is stated once, at the top of the handoff: only a full clean-fleet R22 counts, and a tool's exit status is never the oracle. Also removes a duplicated results section left by my own earlier checkpoint edit. |
||
|
Drew T
|
8d40d55c7a |
docs(phase-30): SS130 — an INCREMENTAL build reported BYTE-IDENTICAL for a change the CLEAN build cannot LINK
I reported func_8013B83C + func_8013BD74 as "BOTH BANKED - BYTE-IDENTICAL". That was
WRONG. My in-loop gate ran `make extract && make build` without `make clean`, and it gave
a FALSE PASS. The clean rebuild does not link at all:
ov_SC01_077_o0.c:(.text+0x10f8): undefined reference to `$L105'
ov_SC01_077_jr_801588CC.o: undefined reference to `func_8013C938'
- the first is a local label from the C-emitted jump table;
- the second is a PREVIOUSLY-MATCHED cluster fn going undefined (the incremental build
reused objects that still satisfied it).
Reverted; R22 140/140; nothing lost, nothing was committed.
SS42b named the stale-object trap for a FALSE FAIL. This is its MIRROR: a FALSE PASS, on a
change that is not even linkable — false in the most convincing direction possible, a green
SHA. Anything touching config/ (carve, resegment, split) must be gated by a full
clean-fleet R22 before it is BELIEVED, let alone reported.
THREE WRONG CLASSIFICATIONS ON THIS PAIR, all corrected in the ledger:
CC1-FAIL-UNREAD -> it has no compile error at all
JTBL-PAD-SPEC-DRIFT -> I had carved ONE fn of a TWO-table span; carving both gives
pad spec [0,4,4] and the filter is satisfied
"both banked" -> the false pass above
Real class: JR-PAIR-IN-ONE-O0-OBJECT. Both bodies ARE byte-correct (match_one --o0 and
rtu_match --o0 both MATCH, 272 / 198 ins); the blocker is integrating TWO jr fns into ONE
-O0 object. Untested escape: SS81 step 1, isolate one into its own code subseg so each
object owns exactly one table.
Also records the diagnostic ladder that found it: diff the two BINARIES and bucket each
differing byte against the function's own vram range. 3,749 of 3,791 diffs were OUTSIDE the
function, first diff near the overlay START, image 57 bytes LONGER - the SS8 signature of
.rodata floating to the front. That fingerprint separates a codegen residual from a layout
effect in one build, and it is what finally redirected three wrong guesses.
|
||
|
Drew T
|
7281e0af57 |
docs(phase-30): SS129 (two jr traps) + checkpoint — 1 of 3 reach-138 targets banked, 2 ledgered
SS129a: post-carve, rtu_match/match_one COUNT THE JUMP TABLE AS INSTRUCTIONS. For func_8013BD74 it reported `mine=198, target=226, 206 mismatched` — and 226-198=28 is exactly the table's entry count. A draft that verified cleanly BEFORE the carve reads as a total mismatch AFTER it, and the number looks like deep codegen trouble. SS81 says a jr fn's match_one MATCH is not a bank; SS129a says its post-carve DIFF is not a diff either. Let the whole-binary gate arbitrate. SS129b: NEVER commit a carve whose owner is still a stub. harvest_verify refuses a dirty tree (SS97) and the carve dirties config/, so committing the carve to get a clean tree is tempting — and it STRANDS the carve. jr_inventory refused instantly (R32: "carve ownership is not 1:1 ... UNOWNED 0x801d828c"), blocking every later jr operation on that overlay. Reverted; R22 140/140. The route for a jr fn is the INTEGRATED jtbl_family_bank (carve -> extract -> remap -> gate per sibling in ONE uncommitted transaction). The SS81 hand-chain is for diagnosis; as a banking path its two constraints contradict each other. Both were mine, both caught by oracles before any lasting damage, both now documented. Ledger: JTBL-PAD-SPEC-DRIFT (func_8013BD74, with the exact SS8e error) and CC1-FAIL-UNREAD (func_8013B83C — the diagnostic is genuinely unread; say so rather than guess). Fleet 93.21% fn-count / 89.1% instr / 80.4% distinct. |
||
|
Drew T
|
a98d138c73 |
docs(phase-30): SS127 the -O0 idiom set + SESSION-28 wave checkpoint (honest ROI)
SS127/SS127a/SS127b distil what the wave's agents kept re-deriving, because the index fired on only 3 of 15 targets: - the -O0 CONSTANT-OFFSET FOLD: `p->f` folds to `lbu 3(r)`, `p[i]` does NOT (addiu + 0-displacement load). At -O2 these converge, which is why nothing in SS1-SS126 covers it. - the -O0 regime generally: spill/reload pairs are REAL named locals; load-delay nops and redundant copies are normal; write plain C, the -O2 steering levers are inert here. - SS127a: SS71 sibling-first is the STRONGEST -O0 lever — an -O0 TU is a near-uniform code regime, so a banked sibling's shape transfers far better than at -O2. - SS127b: two agents' decisive levers came from a SOURCE COMMENT in ov_SC01_077_o0.c, not from docs/. Promote levers out of source comments or every future agent re-buys them. Checkpoint records the wave AND its honest ROI: 1.33M tokens for 12 banks and +0.00pp headline. The value is contingent on three reach-138 functions, and all three are currently unpropagated (func_8013C08C 0/137, SS94 type-carry) or gate-failed (func_8013BD74 CARVE-REFUSED, func_8013B83C CC1-FAIL). Fix propagation before wave 2 — drafting more x2-reach targets is not where the leverage is. |
||
|
Drew T
|
b5362c7b7f |
feat(phase-30): the -O0 cluster HARVEST — 1,364 banks for ZERO agent tokens; fleet 92.71->93.09% fn / 88.3->88.6% instr / 78.7->79.3% distinct
The payoff of routing the cluster to -O0 (commit:1270). These functions were ALREADY
CRACKED in ov_SC01_077 and could not be banked anywhere else purely because every
destination file compiled -O2. With the destinations now -O0, they template in
deterministically -- no drafting, no agents.
dedup_propagate --recover 0x8013C360 (h_exact x138) -> 137 overlays byte-identical
family_sweep --hseq 10 variant families -> 1,227 banked / 133 failed (90%)
1360 staged across 136 groups
------------------------------------------------------------------------------------
1,364 new banks
FLEET: fn-count 92.71 -> 93.09% · instr 88.3 -> 88.6% · distinct-code 78.7 -> 79.3%
(71,756 / 87,459 unique fns; +1,162 unique). dedup 1904 -> 1905 groups, 0 failed;
C1 coverage 240496/240496. 0 NON_MATCHING in any default build (G4).
R22 CLEAN-FLEET: extract-all 139/139 (+main); check-all 140 passed, 0 failed of 140.
--recover WAS LOAD-BEARING (SS75): without it dedup_propagate took its historical
all-or-nothing branch -- one failing overlay (the SOURCE, ov_SC01_077) dropped the whole
function and it printed "all candidates dropped", which reads exactly like a wall. Reading
the exclusion code instead of believing the message showed the remedy: --recover excludes
only that overlay (kept x1 with its own inline match) and propagates to the other 137.
The two has_mid_jr families in the cluster were REFUSED BY DESIGN, not attempted (SS53
interlock): 0x8013C0F8 (154 ins) and 0x8013C414 (329 ins), ~137 members each = ~466
members queued behind the jtbl carve path they actually need, rather than a fake 0% from
the wrong tool.
REMAINING in the cluster: the 133 sweep failures + the 2 jr families + the 3 addresses
never cracked anywhere (0x8013B83C, 0x8013BD74, 0x8013C08C) -- the last are genuine
drafting work, now finally possible since their TU is -O0.
|
||
|
Drew T
|
803d73bb97 |
docs(phase-30): SESSION-28 checkpoint — T2 proven + tooled; fleet 92.71/88.3/78.7, R22 140/140
Records the T2 result as the phase's biggest unblock: the carve-within-a-carve is byte-neutral (Arm-A does NOT bite), the real constraint is that an address range is not an optimization region (SS126), and tools/o0_subsplit.py implements the correct bound. Measured, not assumed, what it unblocks: 275 open stub instances across 18 overlays in the 0x8013B568..0x8013C98C cluster, homed in an -O2 jr split — plus a note that the T0(f) "2,192 open members" pin is STALE and must be re-derived before costing (R37). Also flags my own under-count: the "15 contiguous -O0 fns" came from an asm scan that cannot see matched functions. |
||
|
Drew T
|
8d4f2a38cb |
fix(phase-30): RETRACT 2 of 3 jr wall verdicts — SS125 rewritten; my measurement was the defect
Max-effort re-measurement of the three jr refusals I ledgered earlier this session.
Two of the three verdicts were FALSE. Every number below is SHA vs config/check.<ov>.sha
from a clean tree, with the restore re-verified.
func_8018057C / ov_SC01_009 : jr_isolate_all is BYTE-NEUTRAL
-> "JR-ISOLATE-BREAKS-BYTES" RETRACTED; original failure not reproducible.
func_80191C50 / ov_SC06_018 : isolate NEUTRAL -> carve DIVERGED
(got 1b1667ea, want cbbc4f44) -> the ONE real instrument failure. CONFIRMED.
func_8017BEBC / ov_SC04_004 : carve is BYTE-NEUTRAL (body-free)
-> failure is the TEMPLATED BODY, the OPPOSITE of what SS125 first claimed.
Re-probed once more from a verified-clean tree: still gate-fail. Reclassified
BODY-TEMPLATE-GATE-FAIL.
So the tidy "two apparent walls are ONE tooling problem" conclusion was wrong: they
are two different problems, and the third target has no demonstrated problem at all.
ROOT CAUSE, and it is mine not the tools': a grep-of-the-build-log gate inside a driver
that did not revert on abort. config/overlays.mk is SHARED, so target 1's half-applied
isolate was still in the tree while target 3 was measured. Separately reproduced the
SS42b stale-object trap head-on: `git checkout -- config/` WITHOUT a re-extract turned a
byte-identical overlay into [FAIL] got 8f28aa77 / want 38a3d919 (Phase-20's R22
corollary, live).
SS125 rewritten. The METHOD (split the carve from the body, one build) is kept and is
what refuted this section's own first conclusion; what is added is the instrument rules
that make its answer trustworthy: compare the SHA against config/check, never grep the
log; re-extract after every config change AND every revert; a driver that aborts a
target must revert it before the next; verify the BASELINE against canonical too.
Meta-lesson recorded: SS53 says a 0% from the wrong TOOL manufactures a doctrine — this
is the same failure one level up, a verdict from the wrong MEASUREMENT, and my own
diagnostic script is an instrument subject to R35 like any other.
Ledger corrected in place (3 entries, superseding the earlier misattributions), so the
scheduled repair is the right one. No source/config change; no bank affected; the fleet
is untouched at 140/140 (last full R22 this session, HEAD commit:1263).
|
||
|
Drew T
|
c95b61063f |
docs(phase-30): SS125 split the CARVE from the BODY; 3 jr residues ledgered by STAGE
The session's most useful finding is an instrument ticket, not a match. SS125 (new): before ledgering any jr residue, run jtbl_carve with NO body spliced and rebuild. Byte-identical => the carve is neutral and the failure is the template; NOT identical => the failure is the carve and the body was never fairly tested. One build, and it collapses ambiguity that SS53 warns has twice steered strategy. MEASURED: group B func_8017BEBC had gate-failed 3 probes in a row (default AND --raw, cross-address ov_SC02_015 AND same-address ov_SC04_004). Carve-only on ov_SC04_004 broke the bytes with nothing spliced — so all 3 probes were testing a body that never got a fair run. The SAME stage had already refused behemoth func_80191C50/ov_SC06_018. Two "unrelated walls" = ONE tooling problem. func_8018057C/ov_SC01_009 fails at a DIFFERENT stage (jr_isolate_all, step 1) and is deliberately NOT grouped with them. Both tools reported SUCCESS on every failing target; only the whole-binary gate refused (G3/P9). A tool's exit code is not the oracle. Ledger: the three logged by STAGE (JTBL-CARVE-BREAKS-BYTES / JR-ISOLATE-BREAKS- BYTES), not by function, so a carve fix auto-reopens every target it should. None is diagnosed, so none is called a compiler wall — that guess has been wrong four times running on this project (R35). CURRENT_PHASE: SESSION-28 checkpoint refreshed; the carve diagnosis is now resume item 1 (it gates 13 members + a 710-ins behemoth and every future jr family). |
||
|
Drew T
|
0130fb340a |
feat(phase-30): wave-4 resumed 10/10 MATCH banked + h_exact leg (14 propagated); R22 140/140
The 12 agents killed by the usage-limit pause were resumed and ALL returned MATCH (2 had already banked from their partial drafts, so 10 ran). h_exact propagation leg completed over all 112 banked exemplars: 14 propagated, 42 benign skips (h_seq tier, correctly routed away per §123), 0 failures — the 0x801466F0 'halt' was a third benign-refusal phrase, not a partial write. fn-count 92.61 -> 92.67% | instr 88.2 -> 88.3% | distinct 70,581 -> 70,590 unique fns. |
||
|
Drew T
|
29cd4d4c39 |
feat(phase-30): T3 wave-4 — 60/68 drafts banked across 14 binaries (parallel gate); R22 140/140
Wave 4 launched 70 agents / 14 binaries; 58 returned before the pause (all match_one MATCH) and their drafts + 10 partials gated to 60 banks. fn-count 92.59 -> 92.61%, distinct 70,506 -> 70,581. R22 clean-fleet 140 passed / 0 failed under the campaign lock. Propagation deliberately deferred (--no-propagate) — it runs per-function, routed by tier (§123). |
||
|
Drew T
|
471314da54 |
feat(phase-30): T3 waves 2+3 + 4 behemoths — 52 cores banked, 911 members propagated; R22 140/140
WAVE 3 (48 agents / 8 binaries, dealt across binaries so BANKING fans out): 48/48 match_one MATCH, 48/48 banked through 8 PARALLEL per-binary gates. WAVE 2: 15/19. BEHEMOTHS: 4 non-jr confirmed (func_8017E120 884ins x14, func_8017FA5C 728, func_8017CAD4 755, func_8017E35C 719). Tier-routed propagation (§123): family_sweep --hseq banked 911 members across 137 overlays. fn-count 92.32 -> 92.59% | instr 87.9 -> 88.2% | distinct 78.3 -> 78.7% (70,506 unique fns) R22 clean-fleet 140 passed / 0 failed, under one campaign lock (treelock.sh). CORRECTION (R14): the 'per-binary bank-rate cliff' I reported from the pre-incident gate run (SC03_014 1/6, SC04_018 1/6, SC06_018 2/6) was an ARTIFACT — those gates ran against a tree propagation was concurrently rewriting. Re-gated clean: 6/6 everywhere. A measurement taken during corruption is not a measurement; I should not have theorised a cause before re-running it. |
||
|
Drew T
|
159317d3fe |
feat(phase-30): T3 wave-1 — 8 cores banked + 4 propagated fleet-wide; R22 140/140 (fn-count 92.00 -> 92.16%)
Ultracode wave of 14 agents over fresh reach-138 cores: 14/14 match_one MATCH, 8 accepted by the whole-binary gate (the §52b law reproduced exactly). Propagated per-function (the incident fix): 0x8012E014, 0x80151C54, 0x8012F49C, 0x80151B98 -> +573 instances. R22 clean-fleet 140/140; instr 87.5 -> 87.7%, fn-count 92.00 -> 92.16%, distinct 69,828 -> 69,836. The other 4 banked cores are h_seq (PURE/IMM) families: dedup_propagate is h_exact-only, so its 'reach<2' / 'not self-contained' refusals were statements about the TOOL's tier, not the functions -> cookbook §123 (the §53 carve-law generalized to the propagation-tier axis) + a routing table. They bank via family_sweep --hseq next. |
||
|
Drew T
|
fa1f6d0bf2 |
docs(phase-30): T1a close-out — +18 banked (+12 unique), R22 140/140, stored-draft question CLOSED (report point #2)
39% prior did not generalize (S16 measured FRESH wave drafts; this is A10's stored-backlog class, 0/958 by plain re-gate) — the driver lifted ~16% over that 0%. Residue routed to T3 redraft lanes. §61 orphan-carve residue reverted; two T3 pre-work gaps recorded (gate_stage commit add-scope for new carve files; no tracked writes during tree-writing campaigns). Ledger pruned: 1,350 -> 1,332. |
||
|
Drew T
|
0acd4cc5d4 |
(Phase 29 landed as 552 commits commit:0661..commit:1212 + this PhaseEnd. Fleet 68.9 -> 87.5% instr / 49.5 -> 78.0% distinct / 83.94 -> 92.00% fn-count; 140/140 byte-identical throughout; 0 NON_MATCHING. The granular trail -> logs/Phase29.md.)
feat(phase-29): the family campaign — +18.6pp instr in 25 sessions; engine spent on evidence; roadmap v2 (v1.28.0) - T1 diff_regions.py RESOLVED the swing number: (a) TOOLING — the "~3% h_seq ceiling" was an -O0 compile-flag artifact (REGALLOC 0/106); the third structural wall to resolve to our own tooling. - The campaign: crack waves + propagate-behind-each-crack + the §20 broad type-lift (154 types) + the jtbl carve waves + the SC07-region sweeps. SESSION-25 alone: 2,713 members, +100,572 ins, +1,620 unique fns, every named blocker closed — NOT ONE a compiler wall. - Doctrine shifts (decision-log): fresh cracks are the only lever that moves distinct-code; the propagation cap gates de-duplication, not coverage; the wave bottleneck is INTEGRATION (~92% byte-correct, ~27% bank) -> the tiered T0/T1 blast-radius recovery driver (14/36 = 39% measured); gate_stage call-site-casts are the integration spine (bulk header edits BREAK builds). - T98 characterised the residue: 80 families / 960 members / 173 distinct (29 all-STRUCT by-design + 51 gate-failing, 3 sweeps at 0) -> T99 burn-down (derived from digest git history, R33): final-four-day decay +2.7 -> +0.3pp/day. Closed on the measurement, gate-2 confirmed. - roadmap-to-100 v2: P30 Recovery & Concentration -> P31 Scope-Complete + Main & Resident -> P32 Behemoths+Walls -> P33 Verify+Flip. member_adapt + family-adapt fine-tune VACATED. - Honesty ledger: 7 recorded errors + the month-old shared byte-gate default defect (found+fixed); the -O0 Arm-A splat wall named and carried as P30 T2 instrument work, never force-banked. - cookbook §54-§121 (68 sections); ~15 decision-log entries; calibration re-measured; R37 proposed. |
||
|
Drew T
|
bcd44badc9 |
fix(phase-29): T55 — frontier re-mapped; 2 families swept, 0 banked, both blockers diagnosed to the line
Honest result: NO YIELD. What it produced is a re-measured frontier, a real fix to my own T53 work,
and both failures diagnosed rather than left as "0/N".
FRONTIER RE-MAPPED (T52's +132 moved it): family_hseq -> 2,647 target families, 513 substantial,
64 with a banked exemplar AND live stubs. Caveat recorded: the top two by byte-weight (0x8013c414
180KB, 0x8013c0f8 84KB) are -O0, and _o0 families are already measured at ~1/137 — do not be drawn
by their weight.
FAMILY 1 func_8014032C (183 ins x 136 ~ 25,000 ins): sample 0/8, last_err empty. Read one sibling's
real gate result (§53/§59) past the -j16 interleave and the §58 memcpy red herring — TWO causes:
(1) conflicting types for D_80115128 — the T48/T51 class, which tu-scoped should have caught;
(2) jtbl_rodata_pads "more rodata .align than pad specs — table-count drift vs the carve", a
DISTINCT class jtbl_family_bank's own comment documents as NOT isolate-fixable (§91 --like
role trap).
After fixing (1): still 0/8. Cause 2 is the live blocker — carve work, not decl work. NOT ground
further; it is a documented wall.
THE T53 DEFECT, FOUND AND FIXED: contested() scanned only the draft's BLOCK-scope externs, because
T51's motivating family had them hand-written in the body. But gather_externs carries decls in at
FILE scope, and those are exactly the ones scope_data_externs.fix DROPS when the TU already declares
the symbol — its give-up branch, the fatal case the lever exists for. Measured: scope_data_fix
dropped 3 symbols while contested() returned []. So the stage never fired on its own class. Now
scope-independent; regression-checked against T51's case using the pre-T51 TU from git (old ==
new, added []), and it now finds D_80115128 on the T55 target.
FAMILY 2 func_80144090 (154 ins x 136 ~ 21,000 ins), chosen because has_mid_jr=False avoids the
carve: 0/136. Diagnosed: conflicting types for D_800A651C (2210 vs 379) — the SAME class.
family_sweep gates via PLAIN harvest_verify by design, so it never sees the tu-scoped lever, which
lives only in jtbl_family_bank. Probed: the lever would move D_800A651C + D_800AF648 (deletion-only)
and REFUSES D_800B9A02 as "3 file-scope decls above (ambiguous)" — an over-conservative refusal,
since duplicate-IDENTICAL externs are legal C.
THE FINDING: the same decl-scope collision class gates the frontier's mechanical families — it cost
T52's family 133 of 137 siblings, and it blocks both families probed here. The lever exists and is
byte-proven; it is not reachable from the sweep path most families use.
No src/ or config/ change: no bank, no metric move. Tree verified clean after every probe.
|
||
|
Drew T
|
687d761bde |
feat(phase-29): wave22 families swept 548/548 (R22 140/140) — parallel gating proven at scale
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.
|
||
|
Drew T
|
d109f591f9 | docs(phase-29): item 1 — grinder 4 wins/2 banked (reach-1, R22 140/140); its targeting census is the real result | ||
|
Drew T
|
3d01aaea8c |
feat(phase-29): func_801789AC family banked 137/137 — fleet crosses 84% instr
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. |
||
|
Drew T
|
8f85c5b967 |
feat(phase-29): func_801330E0 family swept 137/137 (R22 140/140) — fn-count crosses 90%
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. |