1be3026446f24de6bada899252e4cb7f00a448bf
367 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Christopher Williams
|
1be3026446 | phase12: match func_80027BE8 (687 bodies / 696 regions) | ||
|
Christopher Williams
|
9729dd0ed7 | phase12: match func_80102F58 (686 bodies / 695 regions) | ||
|
Christopher Williams
|
3ce5c11603 | phase12: final figures -- 685 bodies / 694 regions (+83), +65 to the milestone | ||
|
Christopher Williams
|
c4ac21b819 | phase12: actually merge 0x8002D014 (the previous message's count was wrong -- my extent error, not D's row) | ||
|
Christopher Williams
|
0cb720da1c | phase12: merge worker D's final row 0x8002D014 (685 bodies / 694 regions, +83) + record my attribution error | ||
|
Christopher Williams
|
ae49fc4528 | phase12: final tree cleanup -- worklist regeneration and a worker WIP file removal | ||
|
Christopher Williams
|
603e221156 | phase12: ledger verified clean at the stop (0 held-and-unregistered) + C's casing trap, and an unverified WIP file committed only for a clean tree | ||
|
Christopher Williams
|
b87044652e | phase12: final checkpoint at 684 bodies / 693 regions (+82) with the resume pointer | ||
|
Christopher Williams
|
00f951d502 |
phase12: SESSION STOP at 684 bodies / 693 regions (+82) -- clean tree, handover in the ledger
Gate exit 0 (693 regions, MATCH), 344 tests OK, make check exit 0, tracked patch regenerated so
pristine + patch reproduces the working tree.
+4 this commit (worker D): 0x80100334, 0x800FBDC0, 0x800F88F0 (all maspsx=epilogue), 0x80042DD4.
Phase: 602 -> 684 = +82. Milestone 750 was not reached; +66 remains.
TWO TOOL INCIDENTS OF MINE, both reported by workers before I saw them, both repaired:
1. I edited tools/sf3_match in place while four workers verified against it. The new add_argument
block landed between `--fill-epilogue` and its help=, raising IndentationError at line 1129 --
EVERY worker's verification failed for the duration. A verified with a probe copy and re-verified
with the official tool once it parsed; D reported it independently.
2. Reverting an untested transform, my scripted edit DELETED `_LOAD_RA`, the load-delay regex
fill_epilogue needs, breaking maspsx=epilogue for all 21 regions carrying the token. The
whole-binary gate caught it immediately (exit 2, no result line) and it is repaired at the point
of damage.
Guard adopted for every future tool edit: ast.parse immediately after saving, and one atomic write
rather than a scripted multi-step edit. A worker cannot tell a transient tool break from a broken row,
and the cost lands in their context.
ONE DEFERRED ITEM COSTS A BODY: `gp=-` is SINGLE-VALUED per region. D's 0x80102F58 (60 B) needs
D_801221A8/AA/AC registered with gp markers (proven: 60/0 with, 72 without), but A's merged 0x800FFF60
needs those same three ABSENT from the registry because it uses them as SYMBOLS with per-site macro
expansion. Measured: adding the rows breaks A's 140 -> 124; adding them AND giving A three gp=- overrides
restores A to 140/0 -- but the parser refuses with `duplicate override key 'gp'`. The resolution is
proven; only the option key's multiplicity blocks it. Cheapest remaining body in the phase.
The la SYM+N harness transform the developer directed was implemented and REVERTED, because it did not
close its target and an untested transform in the shipped tool is worse than a documented design. Its
mechanism, its guard, where it belongs in the pipeline, and the open question about WHICH STAGE's text
it must rewrite are all in the ledger so it can be resumed without re-deriving.
Also recorded: the gp-rewrite bug worker A found and I fixed (a stale %hi from an unrecorded register
redefinition); the compiler-boundary class (3 rows no vendored cc1 can build); the per-region codegen
flag policy; D's measured tier finding (4/4 with a call or a frame, 0/4 on leaves); and the reading
rules discovered this session, each with at least two instances.
|
||
|
Christopher Williams
|
22ff419c58 | phase12: scope the harness-transform item (3 shapes, 9 test cases, 6 open) for a developer decision + B's mask-as-type-witness rule | ||
|
Christopher Williams
|
9cabd2c44f | phase12: checkpoint at 679 bodies / 688 regions (+77) -- the working band, the open items, the closed classes | ||
|
Christopher Williams
|
c16d97aaa2 | phase12: A's switch-vs-chain discriminator, and the codegen flag is per-row even within one family | ||
|
Christopher Williams
|
12ac628ea4 | phase12: merge 28 (679 bodies) + the per-region codegen-flag policy, and A's semantics-not-codegen correction | ||
|
Christopher Williams
|
656e78d9f1 | phase12: merge 27 (677 bodies) + D's exit-shape rule, the verified D_801219D4 symbol, and the nested-comment trap | ||
|
Christopher Williams
|
dfe8d8c388 | phase12: the compiler-boundary class (3 rows, no vendored build has the combination) + my refuted hypothesis with its mechanism | ||
|
Christopher Williams
|
4588107cd7 | phase12: merge 26 (674 bodies) + the epilogue token is a per-row property invisible in a length check | ||
|
Christopher Williams
|
9b9ba0c2ea | phase12: correct the body count in 354e90d's message (672/681, not 670/680) | ||
|
Christopher Williams
|
354e90d5e5 |
phase12: merge 24-25 (670 bodies) + worker A's sf3_match gp-rewrite bug, found and fixed
**670 bodies / 680 regions. Phase: 602 -> 670 = +68.**
**+3 bodies, all verified by me from fresh --work dirs at their REAL extents:**
0x80107CCC (76 B, cc1bin=gcc-2.8.1-psx) -- A's row, unlocked by the tool fix below
0x8002D060 (72 B, D) 0x8006FAEC (88 B, D)
And +2 earlier this round: 0x8004D7C8 (220 B, B), 0x8003A9C8 (240 B, B).
**WORKER A FOUND A REAL BUG IN tools/sf3_match AND I FIXED IT.** `rewrite_gp_accesses`'s `_GP_LO`
branch rewrote `lw $2,%lo(SYM)($R)` to `lw $2,%gp_rel(SYM)($gp)` and then `continue`d WITHOUT recording
that the rewrite redefines its destination register. `carrying` kept the stale `%hi`, the register's
next use was scored as an unrewritten use, and the `%hi` was deliberately kept -- so the region came
out exactly 4 bytes long, one instruction.
I reproduced the evidence independently before touching the code, in 0x80107CCC's pre-fix output:
lui $2,%hi(D_801221CC) # high
lw $2,%gp_rel(D_801221CC)($gp)
The same failure the docstring says was fixed for the adjacent-lines case, still live for the
load-whose-result-is-used-later case. One-line fix, A's reasoning and name in the comment, plus why it
stayed invisible: nothing breaks until a gp-marked LOAD feeds something.
Measured: 80/LENGTH-MISMATCH -> 76/0/MATCH. **The tool change was GATED, not trusted**: the pass
touches every gp region, so the full gate was re-run -- c_regions=678, differing_bytes=0, MATCH. That
also answers A, which asked whether the four merged cc1bin rows needed re-verification; the gate is
what proves it and it was green.
**AND WORKER D FOUND THE SAME PASS FROM THE OPPOSITE DIRECTION** on 0x800FFBBC: cc1 2.8.1 puts a safe
`lui $2,%hi(...)` in a branch delay slot, the rewrite folds the hi/lo pair to gp-relative, the lui
DISAPPEARS and the store slides into the delay slot (48 -> 44). So A's case is the rewrite failing to
fire and D's is the rewrite firing and changing a schedule -- two faces of one pass, on two rows, found
by two workers who could not see each other's row. D's framing is the open item: a maspsx mode that
re-derives the delay slot after the gp-relative rewrite would likely close a class.
**cc1bin's measured boundary, and a correction to my own guidance.** B swept the compilers: 2.5.7 /
2.6.0 / 2.6.3 / 2.7.2 / 2.7.2-cdk / 2.7.2-psx give a MERGED epilogue; 2.8.0-psx / 2.8.1-psx give
SEPARATE jr $31 per return. So return merging is a 2.7.2-family behaviour. BUT 2.8.x also changes the
GLOBAL ACCESS FORM (explicit lui %hi / lw %lo pair instead of the symbolic load maspsx turns into
lw v0,2080(gp)). **The lever moves two axes at once and is not free** -- which corrects what I told A,
B and D when routing the multi-exit rows.
**0x80107D7C sits BETWEEN the compilers and is a genuine open question.** B: default 112, 2.8.1 104,
target 108. I swept all TEN vendored builds because B's table listed eight: only 2.7.2-cdk produces 108
bytes, and it is 30 bytes off in content. 2.91.66 and 2.95.2 give 100. So the length is reachable and
the content is not, on any vendored compiler.
**Two corrections of record, both mine:** I guessed extents instead of reading
config/function_extents.tsv (testing A's 76-byte row against an 80-byte extent and reporting
LENGTH-MISMATCH from a correct candidate); and I told three workers cc1bin was a clean lever for the
multi-exit rows when B's sweep shows it moves two axes.
**Ruling on A's per-region codegen flag request (0x800AB504): (b) class-bound, with the diagnosis
kept** -- because `-fno-strength-reduce` gives 152 against a 148 target. A flag that closes a row is a
lever; one that moves a row 16 bytes closer to a different number is a diagnosis. But the PRINCIPLE is
recorded for the next such row: a codegen flag is admissible on the same terms as cc1bin, i.e. a named
mechanism in the bytes, and A has one (address normalisation creating a second loop-carried pointer).
**D: the indexed and pointer loop forms COEXIST and neither carries across rows.** 0x8002D060 matches
only as an INDEXED loop; 0x80107B40 wants the pointer form. A direct refutation of pattern-carrying
from the worker with the most reason to trust a pattern. Also: the both-sides-volatile rule TRANSFERS
(0x8006FAEC), with the narrowing measured (only interleaved accesses need it); and READ the displacement
and compute the symbol rather than inferring it from an adjacent symbol's name (gp+0xBA4 -> 0x801224DC).
**Charter note: `--cc1-flag=X` REPLACES the default `-quiet -O2 -G0` set**, so a diagnosis run must
pass all four explicitly. A's first -fthread-jumps probe read 200 B purely because -O2 was dropped.
|
||
|
Christopher Williams
|
58ff408f9f |
phase12: merge 23 (667 bodies) + five multi-exit rows ARE gate-permitted for cc1bin
MERGE 23: +2 bodies from worker D's un-attempted band, both re-verified from fresh --work dirs: 0x800582AC (64 B) and 0x800A82D0 (64 B). Gate c_regions=676, differing_bytes=0, MATCH. DISPATCH CORRECTION, and it came from checking a claim rather than forwarding it. D reported three multi-exit rows as unclosable because 'my multi-return probes share ONE exit under all ten cc1 builds'. Measured from the binary: ALL SEVEN unregistered multi-exit rows are >=2 jr $31, which is the gate's precondition for naming an alternative cc1 -- so the restriction PERMITS the lever on every one, with four merged rows as precedent. And C's measured row refutes the probe conclusion directly: 0x801008DC is 3 exits and the default gives the correct 88 bytes with 58 DIFFERING bytes because it merges all three returns, while cc1bin=gcc-2.8.1-psx gives 88/0/MATCH. The merge is SHAPE-dependent, and a synthetic probe speaks only for the shape it probes. I made exactly this error earlier in the phase with a probe-dependent mechanism written into tools/sf3_match. Rows routed: A gets 0x80107CCC (3 exits, A has the diagnosis), B gets 0x800FF6DC / 0x80100998 / 0x80107D7C, D gets 0x800FFBBC. Also recorded: D's self-caught harness hazard -- its run helper leaves the LAST variant on disk, so its first verification of 0x800A82D0 ran against the wrong variant and report.tsv's md5 described it. D re-verified from a fresh directory and made the re-write explicit in its procedure. This is the failure mode that would produce a FALSE MATCH CLAIM rather than a missed one, and it is invisible from outside because the report's own md5 agrees with the wrong file. |
||
|
Christopher Williams
|
bf7b6ceac2 |
phase12: merge 22 (665 bodies) + the pool band filter, and I had the first call backwards
MERGE 22: +2 bodies, both from worker D's un-attempted band. 0x801092C0 (52 B) and 0x80085B44 (60 B), both re-verified by me from fresh --work dirs first. Gate: c_regions=674, differing_bytes=0, MATCH. POOL FILTER, SECOND LEAK, MY ERROR CORRECTED. D found 0x80012D54 -- the charter-blocked 0x80012xxx primitive-init family, with class , so the address-parsing rule I installed after the FIRST leak (0x80012A98) had no text to match on. D read its bytes and confirmed the family. I had explicitly DECLINED band-blocking the first time, arguing it 'would silently discard unclassified rows on an inference the charter does not make'. That was backwards: the charter names the family as 'the 0x80012xxx primitive-init family', i.e. BY ADDRESS BAND, and earlier phases already acted on it -- 0x80012A10/AE0/B20/CFC, all class '-', are excluded BY NAME in the Makefile. Two rows leaked by label phrasing and the second had no label at all. The band is the predicate. Blocked 8 -> 15, pools 70 -> 54. Also applying my own corrected commit idiom: this commit names the two claim sources rather than using 'git add -A src/', which swept three of D's in-flight rows into an earlier commit. New levers recorded: LOAD/STORE INTERLEAVING NEEDS BOTH SIDES VOLATILE (a volatile load can still hoist above a plain store and vice versa; cc1 orders volatile only against volatile) -- and from 0x801092C0, unsigned-parameter signedness read from the instruction AFTER the test, volatile on a table pointer for an alias reason, cookbook 19 generalising to a forward loop, and `p += i + start; p->p0 = 0;` over the subscript form. |
||
|
Christopher Williams
|
6109c3b0a9 |
phase12: record my git-add-src defect (benign this time, measured) + worker A's loop-invariant-motion class
My per-merge command used `git add -A $(git status --porcelain src/)`, which adds EVERY modified or untracked file under src/ -- and four workers write there concurrently. One merge commit therefore carried three files I had not verified: an edit to src/func_80013114.c, a new src/func_80085B44.c, and a 20-line DELETION from src/func_800FBF5C.c. Measured, not assumed: all three are UNREGISTERED, so no region references them and the full gate re-run on the committed tree is c_regions=672 / differing_bytes=0 / MATCH. Also committed here: the deletion of src/func_80013114.c, which a worker made after I had committed the file, so that HEAD and the working tree agree again. The dangerous variant is one edit away and did not happen: if a worker edits a REGISTERED region's source mid-merge, that edit is committed and the gate verdict from moments earlier no longer describes the committed tree. Rule from here: a merge adds the named claim sources plus config/docs/tools, never src/ wholesale. |
||
|
Christopher Williams
|
50270a95f6 |
phase12: merge 20-21 (663 bodies) -- worker B's maspsx predicate patch closes a released row
**+4 bodies: 0x80102A80 (132, B, maspsx=epilogue), 0x800FFF60 (140, A, maspsx=epilogue),
0x80102A00 (128, B's source + the NEW maspsx=regread predicate), and the positioning is now
663 bodies / 672 regions. Phase: 602 -> 663 = +61.** Gate byte-exact at every merge, SHA-1 unchanged,
make check exit 0, 344 tests green.
**THE HARNESS PATCH IS THE HEADLINE, because it turns a class into a predicate.** Worker B reported
`0x80102A00` as an UNCLOSABLE row with the mechanism pinned to the harness's own `--work`
intermediates, and refused to touch `tools/` -- correct, since it could not know the default path's
invariants. Its diagnosis: finding 27's gap was fixed by `line_jumps_via_reg` (a load feeding a
REGISTER JUMP), and **this row is the complementary case in the opposite direction -- the jump
ignores the register, but the instruction in its DELAY SLOT reads it.**
lw $2, D_8011FD2C <- loads $2
jal func_80103FCC
sb $0, 0($2) <- the SLOT FILLER reads $2
cc1 emits that with no `#nop` and no marker, correctly by the documented load-to-use rule (gap of 1).
**ASPSX was conservative ACROSS a jump** -- the slot filler is part of the jump -- and maspsx's own
trace says so: `#nop # DEBUG: 'jal func_80103FCC' does not load from $2`. It declined the row for
exactly the reason the original accepted it.
Implementation: `_jump_slot_filler_reads_reg`, on the **existing opt-in** `--nop-on-reg-read` /
`maspsx=regread` token, so the default path is byte-identical and the green gate cannot move. Confirmed
safe rather than assumed: **no registered region named that token before this commit.** Restricted to
`j`/`jal` -- `jr`/`jalr` slot fillers are the same shape but UNMEASURED, and an opt-in predicate whose
whole purpose is default-identity has no place for an unmeasured widening.
Measured, on the source unchanged: **default 124 LENGTH-MISMATCH -> `maspsx=regread` 128 / 0 differing
/ MATCH.** So B's "unclosable" row is a body, and B's candidate source is now `src/func_80102A00.c`
with a header recording that the token is REQUIRED and must not be "cleaned up".
**THE PATCH WAS REGENERATED IN THE SAME COMMIT, which is the whole point of the discipline.**
`tools/patches/maspsx-phase10-r1r2.patch` went 229 -> 289 lines, and all 7 `test_maspsx_patch` tests
pass -- so pristine + patch reconstructs the working tree byte-for-byte and a fresh clone can still
rebuild the gate. Phase 11's `ea51ac9` did exactly this correction WITHOUT regenerating the patch and
left a fresh clone broken; that is why the test exists and it is why this was done in one commit.
**Cookbook, two new entries:**
* **61c -- THE REGISTRY DECIDES THE SPELLING.** A closed two rows today in OPPOSITE directions and the
deciding fact is the registry entry, not the code's shape: `0x800FB758`'s address IS `gp`-marked and
the original writes it absolutely, so the source must use the LITERAL (a symbol lets the harness
rewrite to `%gp_rel`); `0x800FFF60`'s three addresses are NOT registered, so the source must use
SYMBOLS (as literals the address becomes a value and cc1 CSEs it -- the index's `cc1=-G4` attempt was
chasing the wrong thing). Rule: check the registry first. This is the source-side companion to
finding 46.
* **61d -- the `nop_on_reg_read` second gap**, above, with the trace line as the receipt.
Also recorded: worker A's `0x80011484` is no longer the index's "UNRESOLVED" row -- A derived it from
the bytes as an octagonal distance approximation (`s=|dx|+|dz|`, `d=||dx|-|dz||`, then `d<h -> s-q`,
`h+q<d -> s`, else `s-(s>>3)`) with both absolutes as SWAPPED SUBTRACTIONS, and the build is 120 with
a scheduler residual. And A's `0x8002FB54` gave the phase a new lever type: **a DUPLICATED MASK is
evidence of the variable's WIDTH** (`unsigned char r` vs `int r &= 0xFF`), because a byte-typed object
masks at every read and no placement can fake that.
|
||
|
Christopher Williams
|
dd412fe0b1 | phase12: merge 19 (660 bodies), the twin TYPES refinement, and the 24-byte dual-cause trap | ||
|
Christopher Williams
|
98a15efca5 | phase12: merge 18 (659 bodies) + cookbook 61b: a duplicated mask is a WIDTH fact, not a schedule | ||
|
Christopher Williams
|
dd28188b43 | cookbook 61: maspsx=moves proven on 0x8010AA28 -- the first region it has closed, sub-case scoped | ||
|
Christopher Williams
|
f1b840a177 | phase12: merge 17 (658 bodies) -- maspsx=moves closes the 'mutual exclusion' class, first proven instance of finding 61 | ||
|
Christopher Williams
|
3cd0f91515 | phase12: merge 16 (657 bodies), three-worker per-site gp evidence, C's decline endorsed, A's cross-jump test | ||
|
Christopher Williams
|
401c92558e | phase12: merge 15 (654 bodies), C's finding-44 direction, and the 3-of-6 reachability expectation | ||
|
Christopher Williams
|
5af450c491 |
phase12: the three-worker triage key was implemented, TESTED, and FAILED -- disarmed, kept as a label
Three workers converged independently on the same split within one hour, which is normally the
signal to act on. This time acting on it would have been wrong, and the reason is measurable.
D, from its scoreboard: what matters is whether the row has been attempted WITH THE CURRENT LEVER
SET, not which pool it is in.
C, from 11 classifications: prio-1 does not distinguish "a name that implies a SOURCE SHAPE" from
"a name that implies a COMPILER BEHAVIOUR".
A, from 14 rows touched: what predicts closability is the WORDING of the row's own note, not its
prio -- and a grep would separate the two groups in one pass.
**The insight is right and is kept. The proposed discriminator is not predictive, and I measured it
rather than arguing about it.** I classified every row A and C named, by outcome, against the pool's
own record:
MATCHED (8): 0x8010036C 0x800690E4 0x80018284 0x80094370 0x80065494 0x800C3514 0x80022E44 0x8002DF1C
-> source-shape 2 | unknown 2 | **residual-class 4**
RESISTED (7): 0x8010400C 0x800A6C34 0x80107CCC 0x80050674 0x80023D40 0x80024630 0x80101E50
-> source-shape 1 | **unknown 3** | residual-class 3
Precision of "residual-class => will resist": **3/7, worse than a coin flip**, and the rule would have
**deprioritised four of the eight actual successes.** The decisive examples are the proposers' own:
C's `0x800C3514` is classed `alloc+layout (priority selector; ...)` and MATCHED -- the lever was
ARITY; B's `0x8002DF1C` is classed `candidate_bytes=104 = CORRECT length, 58 differing bytes` and
MATCHED -- the lever was a `goto` into the body. Both would have gone to the back of the queue.
So `kind` is DISARMED as an ordering rule and retained only as a LABEL written into every pool row,
with the failure and its numbers in the header so no worker trusts it. A test asserts it is not in
the sort key and cannot drop a row, so it cannot be quietly re-enabled.
**This is defect 5's shape exactly** -- a text heuristic over free prose, on this same field, which
inverted 62 rows. The difference is only that this one was tested before being believed. The real
discriminator is whether a residual has been LOCALISED to an allocation or scheduling decision, and
that requires reading the bytes rather than the note. **Free prose is not evidence about closability.**
Also in this commit: `negatives-d-unattempted.tsv`, the 74-row UN-PUSHED band that worker D asked for
and that D's own numbers justify (2-for-7 on rows a previous session pushed to 1-6 bytes, against
one-spelling closes on rows nobody had pushed). Rows with no mechanism named, not registered, not
excluded, not charter-blocked, not held in the ledger. This is D's criterion applied as a band rather
than as a preference.
Pools after the re-cut: 70 rows (a 16 / b 19 / c 21 / d 14).
|
||
|
Christopher Williams
|
ca5eb6e613 |
phase12: merge 12-14 (652 bodies) + the phase's first inline-asm row + charter s7's not-counted row
MERGES. +13 bodies across rounds 12-14, each re-verified by me from a fresh --work dir first:
0x80042CE0 (80, D) 0x80018284 (80, A) 0x80094370 (84, A) 0x8002DF1C (104, B)
0x80065494 (80, C) 0x800C3514 (88, C) 0x801097A0 (128, D)
Gate every time: differing_bytes=0 result=MATCH, SHA-1 unchanged. make check exit 0.
**652 bodies / 662 regions. Phase: 602 -> 652 = +50.**
**A DEPENDENT ROW WAS RE-VERIFIED WHEN ITS DEPENDENCY LANDED, and this is a new rule.** Worker C's
`0x80091490` was merged as a DEPENDENT claim whose callee `0x80018284` was unreconstructed, with a
3-argument prototype INFERRED from the call site. Worker A then reconstructed `0x80018284`. Merging it
changes `config/symbols.tsv`, which is the environment that row was verified IN -- so I re-ran
`0x80091490` after the merge: still `differing_bytes=0 result=MATCH`. The arity check I promised:
A's `int func_80018284(int *a0, int a1, struct V8 *a2)` vs C's inferred `(int, int, int *)` --
**same arity (3)**, differing only in pointee types on args 1 and 3, which are **byte-invisible** at a
pass-through and a literal-0 site. So the inference held. Rule recorded: **a dependent claim must be
re-verified whenever its dependency is merged**, because the symbol set is part of its input.
**`0x801097A0` -- THE PHASE'S FIRST GENUINE INLINE-ASM ROW IS IN.** Worker D needed seven spellings and
each of the four asm properties is a *measurement with its counter-shape*, which is what makes this an
authorised use rather than a shortcut:
1. `$31` cannot be WRITTEN from C. `register int ra __asm__("$31"); ra = ...;` makes cc1 keep a frame
(132 B) and DELETES the assignment -- reading `$31` is a documented binding, writing it is not
expressible. That is the "provably cannot express" clause demonstrated rather than asserted.
2. The call must NOT be a C call: as a C call cc1 preserves `$31` itself and adds a prologue and an
epilogue (140 B), while **the original has NO FRAME AT ALL**. Written as an asm `jal`, cc1 never
sees a call. This single fact is what makes the row expressible.
3. Zero operands must be `$0` LITERALLY: `gte_ldOFX(0)` passes `"r"(0)`, cc1 materialises a register,
and the original's `ctc2 zero,$24` becomes `move` + `ctc2`.
4. The constant register must be pinned to `$8` (cookbook 160); otherwise the seven constants land in
`a0` (10 differing bytes = five `li` plus five `ctc2` register fields).
Also measured: maspsx supplies the jump-slot `nop` after the asm `jal` (writing one explicitly gives
132 B -- two nops), and the CP0 constant is `0x40000000`, not `0x4000`: bit 30 is the COP2-enable bit,
and `0x4000` compiles to `ori` and does not match.
**I wrote `include/gtemac.h` myself, because worker D refused to and was RIGHT.** D's charter section 4
forbids it from writing under `include/`, and my authorisation conflicted with the charter. D held its
write scope and handed me the macro text with the note that "I followed the charter because it is a
file and it is unambiguous". **That is the correct resolution of a coordinator error and it is the
behaviour I want**: the charter is a file, it was unambiguous, and D did not quietly exceed it. The two
macros (`gte_ldZSF3`/`gte_ldZSF4`, $29/$30) are written in exactly the form of the existing entries,
with the evidence in the comment -- the NUMBERS are the evidence, not the register names. The open
question D raises is recorded for the next charter: whether `include/` should be a worker write scope
or whether worker-authored macro text passed to the coordinator is the right division of labour.
**CHARTER SECTION 7'S NOT-COUNTED ROW IS NOW EXCLUDED BY NAME, and this one is my miss.** Worker C found
`0x80107C5C` (112 B) in its pool and skipped it because section 7 says it "matches but has no
documented source -- it is NOT counted; do not claim it". **I had READ that sentence earlier in this
session and did not act on it.** A worker who did not know the sentence would have produced a body the
phase does not count. It is now in `NAMED_EXCLUSIONS` -- the one place an exclusion lives -- with a
comment explaining that its reason differs from the rest of the list.
**`sf3_free` CRASHED, worker B caught it, and the fix is in.** My `--claim` addition used `free` and
`failed` without initialising them, so **every FREE address raised NameError and exited 1**. Worker B
reported the reproduction and, critically, the asymmetry that makes it matter: **the crash happened
AFTER the `FREE` line was printed, so a worker reading stdout saw the right answer while `$?` said 1**
-- a false BLOCKED for anyone checking the exit code or running under `set -e`. The harmless direction
of the two, but it costs a row per occurrence and it would have looked like a ledger problem rather
than a tool problem. Fixed (`free: list[int] = []`, `failed = False`), B's exact reproduction now
exits 0, and the 25-test suite passes. **The test suite caught this on the very change that introduced
it** -- recorded because that is the tests earning their keep, and because the tool whose whole purpose
is to be trusted unread is the one that must never be wrong about its exit code.
**`--claim` added so check-and-claim is ONE step.** The race is real and worker B hit it: B appended its
`wip` row in the same shell line as the check, *before* reading the output, so the ledger's last row for
`0x80042CE0` said B while D held it. B caught it, did not touch the row, and restored D's hold by
appending the row back (last-row-wins). **In the safe direction** -- B's own row masked the true holder
as TAKEN -- but the inverse ordering, appending on a stale read, is how two workers end up on one
address. `--claim WORKER` now appends only if every address is free, and a refusal writes nothing.
**Worker C found the FOURTH row where the class name pointed at the right place and the mechanism was
not what the note said.** `0x800C3514`'s note described "all stack loads hoisted, beqz+nop+li groups";
the lever was **ARITY** -- the function takes SIX `unsigned char` parameters, the fifth and sixth
arriving on the stack (`lbu 16(sp)`/`lbu 20(sp)`), which the note read as hoisted loads. Measured: the
four-argument spelling gives 56 bytes, twelve short, with neither stack load present. The tally is now
`alloc-tiebreak` -> a pass-through argument (finding 164) | `constant-materialisation-order` -> source
statement order | `return-merge` -> a literal twin and a compiler revision | `alloc+layout` -> arity.
|
||
|
Christopher Williams
|
ce8e1221ff | phase12: record the five pool defects, the convergent worker findings, and D's counter-evidence | ||
|
Christopher Williams
|
9053a4dc51 |
phase12: merge 11 (646 bodies / 655 regions) + sf3_free: claimed is HELD, not FREE
MERGE 11: +7 bodies. All seven re-verified by me from fresh --work dirs BEFORE merging:
0x800A6B38 (104 B, D) 0x8010036C (56 B, A, maspsx=epilogue)
0x800690E4 (68 B, A) 0x800FE970 (84 B, C, maspsx=epilogue)
0x80022E44 (52 B, B) 0x80047468 (72 B, B, gp=-D_80121BFC)
0x80042D88 (76 B, B)
Gate: c_regions=655 differing_bytes=0 result=MATCH, SHA-1 unchanged. make check exit 0.
Registry: 646 distinct bodies, 0 missing sources, 4 carry cc1bin. Phase: 602 -> 646 = +44.
**sf3_free: a `claimed` ledger row is HELD, not FREE.** Worker D found this and reported it rather
than changing a tracked tool on its own judgement, which is the right instinct. The old rule was
`wip` -> TAKEN, else FREE, so a row whose last ledger row was `claimed` -- a worker holding a
STAGED, UNMERGED claim -- read as free. That is a false FREE in the dangerous direction: the row is
neither registered nor abandoned, so the next worker re-derives it and the merge can then receive two
claims for one address.
**This was not hypothetical. It is exactly what the credit outage produced**: all four workers
stopped with claims in flight, and I re-dispatched the pools underneath them. I recovered those rows
by auditing the staging files, but that was luck of ordering, not a mechanism. D reported the two
live instances it could see (`0x800460AC` held by B, `0x800FE970` held by C). `0x800460AC` I had
already merged, which masked the first one; `0x800FE970` was live when D wrote.
A registered row never reaches the changed branch -- `region_owner()` returns TAKEN first -- so the
new rule only ever fires for a claim whose merge has NOT landed, which is precisely the window at
issue. Measured after the fix:
0x800FE970 TAKEN by inflight (claim staged, merge pending)
0x80012A98 FREE (last ledger row 'released') <- a genuine release still reads FREE
0x800FECF8 FREE (last ledger row 'released')
0x800ACA10 FREE (last ledger row 'released')
The residual risk is the opposite direction and is now an orchestrator DUTY, recorded here: if a
claim is ever REJECTED rather than merged, the merge path must append a `released` row, or that
address stays held forever. Nothing has been rejected so far this phase.
Also recorded from this batch:
* **B's `0x80047468` is the second worked case of cookbook 46's per-site override**: the registry
marks `D_80121BFC` gp, but this row reads it absolutely (`lui v1,0x8012 / lw v1,7164(v1)`), so
without `gp=-D_80121BFC` the candidate is one instruction SHORT (68 vs 72). C independently hit the
same class on `0x800A6658` with `D_801226E0`. **The registry's gp marker is per-SYMBOL and the
access form is per-SITE**, and two workers in one hour each lost time to that.
* **B and C independently converged on the same conclusion about what these negatives are worth:**
B -- "the recorded class named the SYMPTOM (a merged store, a folded shift, a strength-reduce)
while the fix was an ORDER or a claim-row option"; C -- "in every one the recorded class NAME was
right and the recorded MECHANISM was half wrong". Two workers, different partitions, same finding.
That is the strongest argument yet for dispatching onto named negatives, and simultaneously a
warning: **the class is a signpost, not an instruction.**
|
||
|
Christopher Williams
|
7090663275 |
phase12: sf3_negpool -- kill the five defects that reached the workers, and merge 10 (639 bodies)
MERGE 10: +4 bodies -> 639 bodies / 648 regions. All four re-verified by me from fresh --work dirs
with --symbols first: 0x80099E34 (40 B), 0x800AC9D8 (56 B), 0x800460AC (40 B), 0x80045540 (56 B).
Gate: c_regions=648 differing_bytes=0 result=MATCH, SHA-1 unchanged. make check exit 0.
The tool, and why it exists. The Phase 12 re-dispatch put all four workers on the ~193-row
classified-negatives index. I generated those pools with a one-off script, and that script was
wrong in FIVE ways. Every one of them shipped, and **every one was found by a worker, not by me**:
1. The index documents its own schema on line 2 -- `# Columns: address<TAB>size<TAB>status<TAB>class`
-- and my script **never read `status`**. 5 rows `blocked` + 1 `blocked,deferred` are rows
charter section 7 forbids attempting (trapping arithmetic, the 0x80012xxx primitive-init family,
the maspsx rare-epilogue mutual exclusion). **Six forbidden rows went out at prio 1, the top of
the list.** Worker C found three in its own pool and refused them.
2. `status` is not enough either: `0x80012A48` is status `near-match` with class `primitive-init
scheduler-bound family`, so it reached prio 1 as well. Blocked families are now matched on the
CHARTER's own wording, in both the status and the class column -- 7 rows dropped.
Deliberately NOT blocked: `rare-epilogue-ORDER`. Worker A drew that line precisely (the order is
work; only the maspsx mutual EXCLUSION is blocked), and cookbook 140/147/165 shipped
`maspsx=epilogue` for it.
3. The Makefile's `NAMED_EXCLUSIONS` (12 rows) was invisible to my script: **8 of the 12 leaked back**
as fresh work -- $gp-switch thunk halves, a fragment, false extent starts. Worker A found two and
asked whether they should be filtered. Eight were leaking, not two. The list now lives in ONE
place (`NAMED_EXCLUSIONS`), and both `worklist` and the new `negpool` target are given it.
4. The workers' own `negatives.tsv` staging was invisible: **94 of the 115 rows they had already
classified were served as fresh work, at the TOP of the prio-1 order.** Worker C: "they are the
first four rows in the file's own prio-1 order, so a worker starting at the top spends its first
hours re-deriving my floor." 58 rows dropped as classified-with-no-mechanism (a second worker
re-deriving a row that already yielded nothing is pure duplication), and a worker's OWN
classification is dropped from that worker's own pool (12 rows) while still being dispatched to
the others, who get the recorded mechanism as a lead.
5. `named = class not in ('-', '')` is a test for a NON-EMPTY STRING, not for a mechanism. Worker D's
staging labels 56 of its 92 rows `no-mechanism-yet` and 6 more `no-extent`, so **62 rows were
ranked prio 1, "cheapest, mechanism already named", when their label says the exact opposite.**
That is why worker A's pool led with rows it could not close. `names_a_mechanism()` now rejects
absences, numbers and bare status words, and accepts prose (workers A and C write their class as
a sentence, so a token-only rule would have missed their mechanisms).
This is a SCHEMA error, not a logic error, and it is worth naming as such: five separate bugs all
trace to generating a dispatch file from a table whose header I had not read.
One coordinator aside that belongs in the record: I had already "fixed" defect 3 by hand, adding
`--exclude 0x8001DC20` to the `worklist` target -- and **the counter caught me**:
`excluded_named_exclusion` did not move, because that row was already excluded from the worklist
under a different rule and had reached the worker through the negatives pool instead. Fixing one row
by hand while the generator leaked was treating a symptom, and the tool said so.
Pools: 176 unregistered -> **93 rows** (a 24 / b 23 / c 28 / d 18), every exclusion and blocked row
gone. C's pool now leads with `index-only` rows, i.e. genuinely fresh work.
Tests: 17 new, `tools/tests/test_sf3_negpool.py`. Fail-first is demonstrated rather than asserted --
the two INTEGRATION tests (which read `NAMED_EXCLUSIONS` out of the Makefile rather than hard-coding
addresses, because the whole defect was two lists that must agree living in different files) were run
against the pools the workers were holding at that moment and **failed, naming all 8 leaked rows**.
Two further bugs found in the process: my own `names_a_mechanism` accepted the numeric dashboard
columns (`'1'` is not a mechanism), which made the rule vacuous and dropped 0 rows instead of ~62; and
one of my tests asserted output that its own `--quiet` flag suppressed.
|
||
|
Christopher Williams
|
ab5b2d3857 | phase12: fragment predicate, D's twin correction (coordinator error), and the redundant-flag lesson | ||
|
Christopher Williams
|
228ad953e4 |
phase12: exclude 0x8001DC20 as the second FRAGMENT row, with the class predicate written down
Worker D found it while sweeping the GTE batch, refused to spend spellings on it, and reported it rather than grinding. I re-derived the conclusion from the bytes before acting: its first instruction is lw t0,0(t5) (0x8DA80000) and $13 is written ZERO times in the whole 72-byte extent, so t5 is read but never established and the extent is the tail of a larger function. The already-excluded 0x800C3490 has the identical signature (also zero writes to $13). That gives the fragment class a CHECKABLE predicate instead of a vibe: 'a caller-saved temporary ($8-$15) is READ before any instruction in the extent WRITES it.' It is sound because $8-$15 are never incoming o32 arguments and no compiler emits a read of an uninitialised temporary. It is not yet an automatic triage rule -- that needs a fail-first test, so it is recorded as an open item rather than half-implemented at the context cap. Until then fragments are caught by a worker reading the row, which has now cost two workers a reading budget each. Excluded rather than left in the dispatch files: 0x800C3490 was re-identified twice by two separate workers before this. |
||
|
Christopher Williams
|
e074d947fb | phase12: credit-outage recovery (10 bodies recovered, 635/644) and the negatives re-dispatch | ||
|
Christopher Williams
|
6da840f3ab |
phase12: recovery merge 9 — 635 bodies / 644 regions (+33, past the cycle-1 checkpoint)
All four workers stopped when the account ran out of credit. This commit recovers every row they
had produced and verified but not yet reported, and it is the first thing done on resumption.
RECOVERY AUDIT, because work that was produced but never claimed is INVISIBLE to the merge flow
(charter rule 13):
untracked src/ files produced this phase 11
distinct addresses claimed in ANY staging file 29
src/ files claimed by nothing (orphans) 0
claims whose source file is missing 0
One false alarm worth recording: my first pass globbed `.run/p12/w-*/claims.tsv` and reported
`src/func_801008DC.c` as an orphan. It is claimed -- in `claims-altcc1.tsv`, which is a DELIBERATE
separate pool because those rows need the `cc1bin` override. The audit tool was wrong, not the
worker. A `src/`-vs-claims audit must glob EVERY claims file a charter defines, not just the default
one, or it manufactures orphans.
I re-verified ALL 29 claimed rows from fresh --work directories with `--symbols` (and
`--cc1 gcc-2.8.1-psx/cc1` for the four `cc1bin` rows) BEFORE merging: **29 of 29
`differing_bytes=0 result=MATCH`, exit 0.** Then one `apply --skip-registered` over the combined
input: 19 skipped as already merged, 10 added, 0 rejected.
sf3_match gate c_regions=644 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make check exit 0 extents-verify regions=644 disagreements=0 AGREE
make worklist listed=984, excluded_already_registered=642
registry audit 644 rows, 635 distinct bodies, 0 missing, 4 carry cc1bin
The 10 recovered rows, and they are the phase's best evidence that the dispatch re-cut worked:
0x8006D3B0 (192 B) and 0x8006AA88 (244 B) -- worker A, adjacency
0x8006D250 (172 B) and 0x8006D2FC (180 B) -- worker B, family/adjacency, sibling with a 5th arg
0x8002515C (60 B) and 0x800254B0 (60 B) -- worker D: BOTH twins of the registered 0x80025070,
a THREE-member family, and twins of each other
0x80101C5C (32 B) and 0x80102FE4 (48 B) -- worker D, GTE class
0x80091490 (84 B) -- worker C, DEPENDENT, merged on my ruling (below)
0x801008DC (88 B) -- worker C, `cc1bin=gcc-2.8.1-psx`, 3 `jr $31`
**RULING ON THE DEPENDENT CLAIM `0x80091490`.** Worker C flagged it rather than quietly merging it,
correctly applying charter rule 2: its callee `0x80018284` is NOT reconstructed, and the 3-argument
prototype is INFERRED from the call site (the tell is `move a1,zero` -- an integer 0, not a null
pointer in v0). Ruling: MERGE, with the dependency recorded here and in the ledger. Reasoning:
(i) rule 2 forbids verifying against a SUPERSET, and no superset was used; (ii) the whole-binary
gate proves the bytes exact, so the call site's register setup is right; (iii) the residual risk is
that a future `0x80018284` reconstruction disagrees about arity, and **that risk is caught by the
gate the moment it happens** -- the row would stop matching and the cause would be visible. The
alternative, holding a verified body, costs a body for a risk the gate already covers.
**The worker who takes `0x80018284` must treat `0x80091490`'s prototype as a hypothesis to check.**
Also recorded: `excluded_already_registered` still lags the registry by exactly 2 (642 vs 644). The
lag did NOT grow when this merge added four negatives-derived rows, so it is not "negatives rows are
counted elsewhere" -- it is a fixed pair of registry rows the counter never counts. Still open,
still a diagnostic rather than a gate, still to be reconciled at the close with the full census.
Phase position: 602 -> 635 bodies, +33. The cycle-1 checkpoint was +30.
|
||
|
Christopher Williams
|
3765dc4352 | phase12: checkpoint record — 625 bodies / 634 regions and the measured route to them | ||
|
Christopher Williams
|
b8502c5693 |
phase12: merges 7-8 — 625 bodies / 634 regions (from 621 / 630)
Merge 7: worker D's 0x8006AD5C (84 B, a GOAL B row, first spelling) and 0x8006D1C4 (140 B).
Merge 8: worker C's GTE pair 0x80010810 / 0x8009C69C (60 B each, on the DEFAULT toolchain, via
the inline-asm hatch). Every row verified from a fresh --work dir against the exact md5, merged to
a candidate, gated whole-binary, promoted only on result=MATCH.
sf3_match gate c_regions=634 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make check exit 0 extents-verify regions=634 disagreements=0 AGREE
registry audit 634 rows ordered, non-overlapping, 625 distinct sources, 0 missing
INTEGRITY CHECK THAT PASSED, ON A REAL HAZARD. Worker C edited the headers of the three
ALREADY-MERGED cc1bin sources after I merged them, changing their md5s (6afb89a7 / 51ab9083 /
c30c5bfa). The registry points at those paths, so a content change would have made it stale. I
re-ran the full gate on the current registry: MATCH. Comments only. This is exactly what the
md5-in-claim-row guard exists for, and here the whole-binary gate is what settled it.
C'S INLINE-ASM HATCH WAS JUSTIFIED TWICE, AND THE SECOND REASON IS A NEW FINDING.
The GTE pair is the d=0/15 identical pair, so one solve meant two bodies. The hatch was needed
because (1) ~20 spellings and ALL TEN vendored cc1 builds fold the dead `move t0,a1` into the
negation, and `((y ^ -1) + 1)` is the only spelling reaching the right LENGTH while lowering to
nor+addiu -- so length alone was never evidence; and (2) THE ORIGINAL'S NEGATION IS THE TRAPPING
`sub` (funct 0x22), not `subu` (0x23). objdump prints `neg` for the original and `negu` for the
candidate, so a mnemonic comparison cannot see it: a one-byte funct-field difference, cookbook 6's
class. With the copy fixed but the C negation kept, the row sits at differing_bytes=1.
AND C CLOSED THE ALT-CC1 QUESTION AGAINST ITS OWN INTEREST. On the 0x80050674 pair the residual is
differing_bytes=1 on the default cc1 and differing_bytes=22 on BOTH 2.8.1 and 2.91.66-psx, so it is
not a compiler-revision artifact. C then declined to spend the inline-asm hatch on it, on the
grounds that the residual is a mundane operand order inside an otherwise all-C body and the hatch
would be doing COSMETIC work. Ruling: endorsed. The hatch is for shapes plain C provably cannot
express; pinning three registers to win one operand order is not that. The row is classified with
its mechanism and an exhausted dimension instead.
OPEN, RECORDED WITH THE EXPERIMENTS RATHER THAN A GUESS: the workflow's checklist item
`excluded_already_registered == registry size` held exactly through merges 5, 6 and 7 and diverges
at merge 8 (634 registry rows, counter 632). Two hypotheses were tested and BOTH REFUTED: the two
new rows are not extent-graded non-exact (both are `exact`/`term=jr_ra`), and it is not "negatives
rows are counted under the negatives filter instead" (11 registry rows have negatives addresses,
but removing only the 2 newest from the registry reproduces the count exactly). Two failed
root-cause attempts, so per AGENTS.md rule 10 it is recorded with the evidence instead of a third
guess. No correctness risk, and that is measured: the whole-binary gate proves all 634 rows
byte-exact simultaneously, the registry audit is clean, and extents-verify agrees. It is a
diagnostic, not a gate. To be reconciled at the close, where the negatives-index reconciliation
happens anyway and is probably the same question.
|
||
|
Christopher Williams
|
677d982398 |
phase12: merge 6 — worker A's 572 B body -> 621 bodies / 630 regions; exclude the 0x800C3490 fragment
Worker A's third claim, verified from a fresh --work dir against the exact md5 in the claim,
merged to a candidate, gated whole-binary, promoted only on result=MATCH. It is the largest body
any worker has taken this phase (572 B).
sf3_match gate c_regions=630 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make check exit 0 make extents-verify regions=630 disagreements=0 AGREE
make worklist listed=989, excluded_already_registered=630
registry audit 630 rows, 621 distinct sources, 0 missing, 3 carry cc1bin
**ADJACENCY IS NOW 3-FOR-3 FOR WORKER A, ACROSS THREE BANDS.** 0x800297F4 (204 B, band 0) ->
0x800298C0 (392 B, band 1) -> 0x80029A48 (572 B, band 2): three CONSECUTIVE bodies, 1168 bytes,
four spellings total, with the density ranker not involved in any of the three picks. The chain
ends where no row starts at the next boundary. That is the strongest single piece of dispatch
evidence in the phase, and it is why the fresh-band files were re-cut to put adjacency above
density inside a band.
Worker A's lever, recorded because it is an operator RECOVERY rule rather than a spelling tip: the
original is `if ((x1 < 0 && x2 > 0) || (x1 > 0 && x2 < 0))`, and the truth-table-equivalent
if/else ladder is EXACTLY ONE INSTRUCTION SHORT. The emitted stream is `bgez x1` / `bgtz x2` /
`blez x1` / `bgez x2` -- each term's first test branches over its own second test -- and the ladder
has no `bgez x1` to emit. So the four BRANCH SENSES let you write the operator down without
guessing; cookbook 83's "branch direction distinguishes && from ||" turned into a recovery rule.
And `(x1 ^ x2) < 0` is the same predicate with the wrong codegen: the original compares.
**0x800C3490 IS EXCLUDED FROM THE WORKLIST.** Cookbook 114 (worker A, Phase 10) records it as a
FRAGMENT: it starts mid-expression, its body is a SHARED TAIL (`addiu sp,sp,48; jr ra`) that also
appears at 0x800C3470-0x800C348C, and it cannot be matched standalone. The extents table still
grades it `exact` with `term=jr_ra` because the boundary walk sees a well-formed terminal, so the
tool cannot catch it -- which is exactly why it needs a recorded exclusion rather than a tool rule.
Worker A recognised it for the SECOND time in Phase 12 and skipped it instead of spending reading
budget, which is the signal that the exclusion belongs in the Makefile: a row that has to be
re-identified by hand every phase is a row the dispatch should not be offering.
Added with its provenance in the Makefile comment, the same mechanism Phase 10 used for
0x8010080C's false extent start. excluded_named_exclusion 8 -> 9.
Ledger updated with merges 2-5, the cc1bin lever and its gate, the mechanism correction, the gp
pair rewrite and both of my failures in it, the dispatch measurement (369 of 993 rows abut SOME
region = noise; only 5 abut a PHASE-12 match = the signal), and the partition-membership fix.
|
||
|
Christopher Williams
|
63008d5a49 |
phase12: merges 3-5 — 620 bodies / 629 regions (from 604 / 613), incl. the first cc1bin rows
FIVE claim batches, every row re-verified by the coordinator from a fresh `--work` directory
against the exact md5 in the claim, merged to a candidate, gated whole-binary, promoted only on
`result=MATCH`. Merges 3 and 4 are separated so the every-3rd-merge full audit falls on merge 3.
sf3_match gate c_regions=629 differing_bytes=0 result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9 (unchanged)
make clean && make all exit 0 (full audit at merge 3)
cmp exit 0
make check exit 0
make extents-verify regions=629 disagreements=0 result=AGREE
make worklist listed=991, excluded_already_registered=629
registry audit 629 rows, ordered, non-overlapping, 620 distinct sources, 0 missing
make test 318 tests, OK
**THE FIRST THREE `cc1bin` REGIONS ARE IN THE REGISTRY**, and the gate is byte-exact for the
whole binary with them -- the alternative-cc1 lever works end-to-end, not just in a scratch
harness. All three came from worker C, all three match with gcc-2.8.1-psx/cc1 and NONE matches
with the default (56/60/52 B LENGTH-MISMATCH). They carry `cc1bin=gcc-2.8.1-psx` in the region
row and the gate re-checks the >=2-exit-jump restriction on every build.
0x800FF43C (64 B) and 0x800FF47C (64 B) — a TWIN PAIR, raw words d=2/16. They are also two of
the rows worker F left open at the Phase 11 close with a named mechanism and a named untried
lever. C closed them with the cc1 lever, not a re-spelling.
0x80108578 (56 B) — needed TWO levers: the cc1 AND a source shape that re-tests the guard each
iteration (`for(;;){ if (a0==0) return 0; ... }`), because the original's loop back edge
targets the function's FIRST instruction. A `while` spelling rotates the loop, skips the
guard, and leaves the 1-byte residual an earlier attempt had recorded.
**AND `0x800298C0` IS AN OVERTURN — the recorded negative, merged as worker A's claim.** Worker A
took it on ADJACENCY (the row immediately after its own previous match) and matched it first try,
overturning cookbook 128's named mechanism. It is also the row Phase 11's close had to release as
STALE-TAKEN because both holders had gone out of context: the row the close flagged as invisible
became a body in the next phase. Cookbook 182 demonstrated end-to-end.
**Worker D's GOAL B produced bodies, not just a classification:** 92/92 of its unclassified rows
are now classified, and TWO of them were raw-word twins of registered bodies and MATCHED
(0x8006AE04 = 1/20 words from 0x8006B66C; 0x80017A38 = 1/18 from 0x80017B50). A Goal B result that
adds zero bodies would still have been met; this one added two.
Worker B's 0x8006B964 is the fourth match in ONE translation unit (0x8006B0A8/B328/B5F0/B964),
which is what prompted the dispatch re-rank below.
MEASURED, AND IT IS THE PHASE'S DISPATCH RESULT SO FAR: every body Phase 12 has produced came from
ADJACENCY, a family/twin finder, or a named structural class -- none from the top of a
density-ranked file, and B hit the leading indicator (four consecutive small-residual near-misses,
no new mechanism) doing exactly that. So the fresh-band files are now ordered band-first, then by
ADJACENCY TO A PHASE-12 MATCH, then density. Plain adjacency is NOT discriminating -- 369 of 993
rows (37%) abut SOME registered region, in every band -- but only FIVE rows abut a region matched
this phase, and the mechanical key independently flagged 0x8006B398, which worker D had already
chosen from B's handoff. The key agrees with the human pick.
PARTITION MEMBERSHIP IS NOW A HASH OF (band, address), not a position in a list. I had this wrong
twice and told the workers membership was stable when it was not: first partitioned by
density-sorted position (correcting the payload bug moved rows; band-0 top-20 overlap 1/20), then
by (band, address) POSITION, which is stable only while the row set is unchanged -- and the set
shrinks by design as rows register (1001 -> 993). Verified: removing 10 rows moves 0 assignments.
|
||
|
Christopher Williams
|
567b069495 |
phase12: cc1bin= — the alternative-cc1 lever, RESTRICTED BY THE GATE (developer-approved)
Worker C found that the project's cc1 cannot build a whole class of the original's functions,
and the census is triply verified (C, worker D, coordinator):
623/623 REGISTERED regions contain EXACTLY ONE `jr $31`. ZERO contain two or more.
12 of the 193 NEGATIVES rows contain two or more. That is the entire blocked class.
NOT a flag: 14 flag sets on the default cc1 all yield one exit.
And it produces bodies: 0x800FF43C / 0x800FF47C / 0x80108578 are byte-exact with
gcc-2.8.1-psx/cc1 where the default gives 56/60/52 B LENGTH-MISMATCH.
THE RESTRICTION IS ENFORCED HERE, NOT LEFT TO A CONVENTION. Allowing a second compiler
BINARY widens the corpus, and the project's rule against per-function compiler choice exists
because the gate CANNOT catch a wrong choice -- byte-exact is byte-exact. So a region naming
`cc1bin` is REFUSED unless its original body has >= 2 function-exit jumps, i.e. unless it has
a NAMED MECHANISM in the bytes:
region 0x8006B5F0..0x8006B66C names cc1bin=gcc-2.8.1-psx but its original body has only
1 function-exit jump(s) (`jr $31`); 2 are required. -> exit 2
`cc1bin` takes a BARE vendored directory name under tools/old-gcc/ (no slashes, no paths), so
the nameable set is exactly the pinned set already in the repo. Validated by `sf3_merge` at
merge time and enforced by `sf3_match` before anything is compiled.
THE MECHANISM SENTENCE IN THIS FILE WAS WRONG AND IS CORRECTED, NOT DELETED. My first version
said "2.7.2 emits one shared return epilogue while 2.8.x emits one per return". C's 4-return
probe reproduces that and I reproduced C's probe exactly -- but worker D could NOT reproduce
it: on both a 3-return framed probe and a 3-return frameless probe, ALL TEN builds emitted one
shared exit. Both probes are real, so the compiler-side result is SHAPE-DEPENDENT and the
general claim is false. The census and the three bodies justify the lever; the mechanism was a
hypothesis I recorded as a finding. Left in place, marked as corrected, because the next reader
will otherwise re-derive it and believe it.
ALSO IN THIS COMMIT:
* **The 2.8.x gp access pair.** 2.8.x addresses a global as `lui $R,%hi(SYM)` +
`<op> $r,%lo(SYM)($R)` where 2.7.2 emits a bare `sw $2,SYM`. Both lines were invisible to
the existing regexes, so a gp-touching region built with an alt cc1 came out 4 BYTES LONG.
Now rewritten as a pair: the access becomes `%gp_rel(SYM)($gp)` and the `%hi` is dropped.
My first two attempts at this were both wrong and both are recorded in the code:
it required the two lines to be ADJACENT and maspsx emits a BLANK LINE between them (so it
silently did nothing), and it deleted the `%hi` unconditionally, which leaves a later access
to the same global addressing a register nothing wrote -- right length, plausible, wrong.
The deletion is now gated on every use of the register before it is redefined being rewritten,
with redefinition tracked explicitly and `jalr` deliberately treated as non-defining so the
rule can only ever keep a `%hi` alive, never delete a live one.
* **`check-claims` reported a healthy CUMULATIVE file as a failure.** Worker B hit this: an
already-registered row is exactly what `apply --skip-registered` exists to skip, and a
worker's claims file is cumulative, so `result=PROBLEMS`/exit 1 was the NORMAL case for a
good file. A checker whose healthy output is a failure teaches workers to ignore its exit
code, and then it catches nothing. Already-registered is now information
(`already_registered=N`, exit 0); format errors stay exit 2, missing sources and duplicate
starts stay exit 1.
Tests: 306 -> 318, with the restriction pinned both ways (a 1-exit region is refused, a 2-exit
region is allowed), the census checked on a synthetic payload, and the gp pair rewrite's three
shapes covered. Full gate on the tracked registry stays byte-exact at 623 regions, so none of
this changes the existing corpus. `make check` exit 0.
|
||
|
Christopher Williams
|
d2cf1b8f10 |
phase12: sf3_cc's maspsx stage NEVER RAN, then doubled the output — fixed (worker B's finding)
Worker B measured this and was right, and the diagnosis is exact. The call was
maspsx.py --aspsx-version=2.56 "$OUT/$BASE.s" "$OUT/$BASE.ms.s"
but maspsx takes ONE positional (an INPUT) and writes to STDOUT -- it has no output-file
argument, which is precisely why sf3_match runs it as a stdin->stdout filter (run_filter).
So maspsx tried to open the OUTPUT path as its input, failed, and the failure was hidden
TWICE: by `2>/dev/null`, and by a `|| cp` fallback that quietly copied the raw cc1 output
over `.ms.s`.
Measured on src/func_8006B5F0.c before the fix:
run 1, fresh scratch : .ms.s IDENTICAL to .s (71 lines) -- maspsx NEVER APPLIED
run 2, scratch exists: 133 lines = TWO body copies with 6 `addu`, because maspsx now read
the STALE .ms.s as input, succeeded, printed its real output STRAIGHT
TO STDOUT (unredirected), and `cat` printed the stale raw copy after it
After the fix: 62 lines both runs, IDENTICAL to each other, stdout == .ms.s, and .ms.s differs
from .s for the right reason (the stage actually runs).
**So the tool was wrong on the first run and wrong-and-doubled on every later one, from its
Phase 11 promotion (
|
||
|
Christopher Williams
|
f5c3426e85 |
phase12: merge 2 — worker B's 3 rows -> 607 bodies / 616 regions
All three re-verified from fresh --work dirs against the EXACT md5 in the claim rows
(4ad25781c69f611450544ae097936d1a / 7188c87c37bfc87b8e0ebfddd47ded97 /
542de2b2242dd8e6149440e4bb034f77), merged to a candidate, gated whole-binary, promoted only
on result=MATCH.
sf3_match range (x3, --symbols) exit 0, differing_bytes=0, result=MATCH
sf3_merge check-claims exit 0, problems=0
sf3_match gate --expect-sha1 exit 0, c_regions=616, differing_bytes=0, result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9
make check exit 0
make extents-verify regions=616 disagreements=0 result=AGREE
make worklist listed=998, excluded_already_registered=616
WORKER B'S CHARTER CORRECTION, CONFIRMED INDEPENDENTLY. The charter's §3d verify command
omitted `--symbols config/symbols.tsv`. Without it this entire family is +4 LENGTH-MISMATCH,
because the gp-marked global D_80121E88 auto-resolves to an absolute address and becomes
lui+lw. Measured on 0x8006B5F0:
without --symbols: candidate_bytes=128 result=LENGTH-MISMATCH exit 1
with --symbols: differing_bytes=0 result=MATCH exit 0
That is the THIRD defect in the charter I wrote for this phase (after the claims-file format
and the evidence-file name). A verify command that does not match the configuration the gate
uses is a command that reports a false negative, and it would have had workers discarding
correct spellings as LENGTH-MISMATCH.
TWO REUSABLE MECHANISMS FROM B, both named rather than ground out:
(a) A REGISTER RESIDUAL CAN BE ARGUMENT ARITY. 0x8006B328 came out at correct length with
exactly 4 differing bytes, all the a1-vs-v1 register field of the record pointer. Cause:
the callee was called with TWO arguments. With one argument cc1 allocates the record
pointer to v1; with two, both values are already in a0/a1, the call emits NO setup at all,
and the emitted code differs only in that field. Diagnostic: correct length + the only
residual is one value in an argument register => try declaring an extra parameter.
(b) A LOOP-INVARIANT CONSTANT MUST BE A NAMED LOCAL DECLARED INSIDE THE GUARDED SCOPE, and
the `s4` save is the tell. On 0x8006B0A8 (frame 40, saves ra+s4+s3+s2+s1+s0): a literal
`&= -2049` rematerialises the `li` inside the loop and the whole s4 save/restore pair
vanishes; a named local before the `while` hoists the `li` above the guard test and
reschedules the entry block (20 differing bytes); declaring it inside
`if (p != 0) { int hmask = ...; while (...) }` MATCHES. The guard wrapper is what matters,
not the loop form (do/while is byte-identical to while). A SECOND mask in the same function
must stay a literal -- the hoist is per-statement, not per-function.
make test 306 tests, OK (from 301)
|
||
|
Christopher Williams
|
1e620cde50 |
phase12: a CHARTER is a file every worker copies — my claims format was wrong (cookbook 190)
The phase's FIRST merge was rejected: "expected three or four fields", while all four workers
were already staging files in the format my charter had given them.
charter said: range<TAB>source<TAB>md5<TAB>differing_bytes<TAB>result<TAB>options
with range written 0xSTART..0xEND
tool reads: start<TAB>end<TAB>source[<TAB>overrides]
Finding 179 says a rule every worker must follow belongs in a TRACKED tool, not in a file each
worker copies, because a copied artefact cannot be fixed for the people who already copied it.
Phase 11 earned that from a worker's free.sh. **A charter IS a file each worker copies**, so
writing a FORMAT into prose recreates the defect one level up — and this time the unfixable
copied artefact was the coordinator's.
AND THE TOOL HAD ALREADY LEARNED IT. validate_overrides exists because a Phase 11 worker put
md5= in the 4th column, and its error message says in terms: "Per-claim metadata such as a
source md5 belongs in report.tsv, not in the registry row." The convention was documented
INSIDE THE TOOL, I did not read it, and I wrote prose contradicting it — including renaming
the evidence file to evidence.tsv when report.tsv is the established name in the tool's own
error string and in every Phase 8/9/11 worker's staging directory.
Standing rule: before writing a staging format, an interface, or an exit-code contract into a
charter, READ THE TOOL THAT ENFORCES IT. "The tool is the contract" is not advice for workers
only. Workers compute addresses rather than eyeballing them; the coordinator must derive
formats rather than inventing them.
FIXED AS A COMMAND, NOT AS CORRECTED PROSE. New `sf3_merge check-claims --claims F [--regions R]`
validates the format, flags a duplicate start, a missing source file and an already-registered
row, so a worker answers "is my staging mergeable?" itself before reporting. 11 tests, one of
which asserts THE CHARTER'S OWN WRONG FORMAT IS REJECTED, so the message stays honest for the
next coordinator — who will also write prose.
Charter §10 rewritten to specify the tool's format by READING THE TOOL, to separate claims.tsv
(the merge input) from report.tsv (the evidence, where the md5 lives), and to name
check-claims as a required pre-report step; §5 gained rule 17.
What worked: fail-fast validation caught it in under a second at the merge, not as a confusing
failure at the gate. Phase 11's override-key guard paid off again. A staging format a tool can
CHECK is worth more than one that is documented well.
Cost: one rejected merge, four correction messages, ~10 minutes. Cheap because the tool refuses
to guess.
make test 301 tests, OK (from 290)
|
||
|
Christopher Williams
|
b3e3ec3ea7 |
phase12: merge 1 — worker C's two ADJACENT-TWIN negatives -> 604 bodies / 613 regions
The phase's first two bodies, and both are recorded negatives rather than worklist rows.
Worker C found them with the NAMED UNTRIED LEVER I handed it: tools/sf3_family driven over the
101 negative rows against the 611 registered regions. I measured candidates=0 for the fresh
band and told C that said nothing about its own pool. It didn't:
score >= 1.000 : 3 rows (NOT 0)
score >= 0.99 : 4 rows
score >= 0.95 : 15 rows
-> 0x800518BC (88 B) -> 0x80051864 MATCHED (this merge)
-> 0x800B34A4 (88 B) -> 0x800B34FC MATCHED (this merge)
-> 0x8010804C (16 B) -> 0x80085B80 blocked class (gp-thunk), correctly not attempted
Transfer rate 2/2 on the unblocked score-1.000 rows, against finding 166's 7/7.
I re-verified BOTH claims from fresh --work directories before merging (differing_bytes=0,
result=MATCH, exit 0 each), merged to a candidate, gated the whole binary, and promoted only on
result=MATCH.
./tools/sf3_merge apply ... exit 0, added_regions=2
./tools/sf3_match gate --expect-sha1 e173... exit 0, c_regions=613
differing_bytes=0, result=MATCH
sha1 e173426c157384ebf1b6caf8c6fea18a85a14af9
make check exit 0
make extents-verify regions=613 disagreements=0 result=AGREE
registry audit 613 rows, ordered, non-overlapping,
604 distinct sources, 0 missing files
Worklist regenerated. It still lists 1001 rows, and the reason is worth recording because it
looks like nothing happened:
excluded_already_registered 611 -> 613 (+2)
excluded_recorded_negative 169 -> 167 (-2)
The two rows were NEVER in the worklist -- they were excluded as recorded negatives. Registering
them MOVES each row from the negatives-exclusion bucket to the registered bucket, so `listed`
is unchanged while both counts shift by exactly 2. excluded_already_registered == the registry
size, as required. No partition refilter is needed: both rows were in C's negatives partition,
not in any fresh partition.
WORKER C'S FINDING, which is worth more than the two bodies and is a Goal-B-grade result: BOTH
rows' recorded class strings were WRONG ABOUT THEIR OWN MECHANISM.
0x800518BC was classed "return-merge/sltiu", with a note that three spellings all came out
80 B and sltiu fixed the compare byte but not the 8-byte layout. RAW WORDS: 21 of 22 words
are IDENTICAL to matched 0x80051864. The sole difference is the forward `j` to the shared
return, and its target differs only because `j` encodes an ABSOLUTE address and the two
bases are 0x58 apart. The body is a literal twin; no re-spelling was ever needed.
0x800B34A4 was classed "alloc-tiebreak" (bit-index/base register pair a0/a1 vs cc1 a0/v1).
RAW WORDS: 20 of 22 identical to matched 0x800B34FC; both differences are the OFFSET
CONSTANT (`li a0,3` vs `li a0,20`). The register pair the note asked for was already there.
The lever is the constant, not the allocator.
Both rows abut their matched twin, so the negatives index contains whole RUNS of repeated
bodies -- and C's operational conclusion is that the cheapest finder is a raw-word HAMMING scan
against the 611 registered regions, which the histogram tool only half-finds. C is running that
scan across all 101 rows now. That map, not the bodies, is likely the largest thing this phase
produces.
Note the discipline this vindicates: an unclassified negative is not overturnable (finding 182),
but these two WERE classified -- wrongly, in the same dimension, by earlier sessions that then
wrote off the row. Cookbook 182's rule needs its other half: a recorded mechanism is a HYPOTHESIS,
and a WRONG named mechanism is as unattemptable as no mechanism at all until someone reads the
raw words.
|
||
|
Christopher Williams
|
f4b1f59b85 |
phase12: the stale patch confirmed end to end — 52 bytes = 4 x 13, and the arithmetic closes
T0's defect was proven three ways (the patch rejects, the guard tests fail, the transform emits an extra nop). This adds the end-to-end one, and its arithmetic closes exactly. Gating the CURRENT 611-region registry with the SUPERSEDED transform: rebuilt_bytes=1886260 original_bytes=1886208 -> 52 bytes LONG rebuilt_sha1=24c4c2a9c99cc7f5daf88c0a30107bda2d16340f original_sha1=e173426c157384ebf1b6caf8c6fea18a85a14af9 result=DIFF 52 bytes is 13 instructions, and 13 was derived INDEPENDENTLY from the original payload: the 15 maspsx=epilogue regions split 2 shapes A / 13 shapes B, classified by asking whether the word before the `jr $31` is a nop (A) or a real instruction (B), with the frame release after the jump in both cases. Each shape-B region gets one extra nop, so 4 x 13 = 52. A count taken from the bytes and a count taken from the failing gate AGREE. That is what makes this a measurement rather than an argument, and it is why the T0 record does not rest on a single line of tool output. ALSO RECORDED, because it is the trap this phase's own documentation warns about: my demonstration command piped the gate through `tail` and then printed `$?`, so the `>>> gate exit=0` line in that log is MEANINGLESS -- `$status` is a fish variable and the pipeline masked the gate's real status. `result=DIFF` is the authoritative field and the byte arithmetic is the independent check. Workflow section 6's rule is "use the gate's EXIT CODE as the gate"; I broke it while quoting it. Standing note for every future gate call: capture the exit code directly, never through a pipeline. |
||
|
Christopher Williams
|
4750d466b4 |
phase12: T1 — phase open, roster spawned and chartered, ledger started
Roster (fresh, spawned by the orchestrator; tab w1:t5, 2x2 grid):
A w1:pC 01a0d529 A1 lever-a.tsv 334 rows
B w1:pE 01a0d52a-2c40 A1 lever-b.tsv 334 rows
C w1:pD 01a0d52a-55d3 A2 negatives-c.tsv the 101 NAMED negatives
D w1:pF 01a0d52a-6198 A1+B lever-d.tsv 333 + negatives-d.tsv the 92 UNCLASSIFIED
Four agent_pane_not_found errors on first start, all cleared on retry after a few seconds --
the documented transient, not a bad id.
PARTITIONS ARE PROVEN, NOT ASSERTED (.run/p12/partition-proof.txt):
worklist rows 1001; a=334 b=334 d=333; sum 1001; distinct union 1001; overlaps 0;
union == worklist True; negatives 193 (c=101 d=92); negatives overlap worklist 0;
negatives c/d overlap 0.
The phase's structural premise was verified by set comparison: 0 of the 193 negatives rows
appear in the 1001-row worklist, because sf3_triage plan --negatives excludes them. The
negatives are an INDEX, not a queue, and worker C is the first worker in this project whose
partition is that index.
THE MEASURED RANKING, and it produced a real number. Band first, density second, with the
density statistic IMPORTED from the tracked tools/sf3_rank (which declares itself the reference
implementation and warns scores are not comparable across implementations -- reimplementing it
would silently break that guarantee):
band rows median density max size range
0 (<=244 B) 410 0.359 0.912 4-244 B
1 (245-400 B) 225 0.491 0.920 248-400 B
2 (401-800 B) 221 0.604 0.896 404-796 B
3 (>800 B) 145 0.720 0.940 804-11516 B
Median density rises MONOTONICALLY with band. That is worker D's warning ("density is
correlated with size, which biases the top of the list") measured on this corpus, and it is
exactly why a pure density ranking is wrong when the milestone counts BODIES rather than bytes:
one body at 80 B and one at 8000 B are worth the same. Band-first suppresses the bias; density
then orders within the band, where it is the measured cost signal.
MEASURED NEGATIVE, recorded so three workers do not each rediscover it: tools/sf3_family
--top 25 returns candidates=0 against the fresh band at ratio 1.000. The family lever is
EXHAUSTED for the worklist (Phase 11's 7 rows were all of it). It has NEVER been run against
the 193 negatives -- sf3_family reads the worklist, which excludes them -- so that is a named,
UNTRIED lever handed to workers C and D, who were both told to report who runs it.
Baseline revalidated from clean before dispatch: make clean/all exit 0; cmp exit 0; SHA-1
e173426c157384ebf1b6caf8c6fea18a85a14af9 unchanged; make test 290 OK (253 -> 281 -> 290);
extents-verify regions=611 disagreements=0 AGREE; gate c_regions=611 differing_bytes=0 MATCH.
CURRENT_PHASE.md rewritten for the phase, with the milestone warning stated plainly (+148 is
larger than any phase so far) and the cycle-1 requirement that at least 8 bodies must come from
the negatives pool -- so a low overturn rate is measured in cycle 1, not discovered at the close.
|
||
|
Christopher Williams
|
afce5aa108 |
phase12: sf3_cc --help was broken — three of four workers tripped on it
Worker B, worker C and worker D all probed `tools/sf3_cc` with `--help` during the Phase 12 capability probe, and all three got a raw coreutils `basename` error instead of help: ./tools/sf3_cc: line 29: .run/sf3_cc/Usage: basename NAME [SUFFIX] ... : No such file ANY leading-`-` argument was taken as a source path. `basename --help .c` prints coreutils' own help text, and that entire text then became the output filename, so the failure surfaced as a confusing redirection/cpp error. Every worker lost time on it, on the first command they tried, and worker D spent probe effort diagnosing it as a "genuinely broken path". This is cookbook 179 from the other side. That finding says a rule every worker must follow belongs in a TRACKED tool rather than a file each worker copies. Here the tool WAS tracked -- and it was still unusable the way every single worker reaches for it first. Tracking a tool is necessary but not sufficient; it also has to survive first contact. Fixed: `--help`/`-h` print real help and exit 0, an unknown option is rejected BY NAME, and a missing source file says so rather than failing inside cpp. The compile path is unchanged. Also documented its LIMIT, which was previously unwritten and is easy to misread as a match: the maspsx stage always runs with DEFAULT options and no region option is passed, so this shows a SPELLING's shape and NOT a region's final bytes. A region needing `maspsx=epilogue`, `nopmarker`, `moves`, `regread`, `off` or `gp=`/`cc1=`/`as=` looks different here than under `sf3_match range`. Sweep spellings with this; decide matches with `sf3_match range` -- and decide an `epilogue` token from the CANDIDATE's tail, never the original's (finding 165/180). 9 new tests (tools/tests/test_sf3_cc.py): the argument-handling cases run without a toolchain, including one that pins the exact symptom (no coreutils help text in the output, and no file created named after it); the compile-path test skips cleanly when the ignored toolchain or any src/func_*.c is absent, and one test pins the documented LIMIT so it cannot be dropped. make test 290 tests, OK (from 281) |
||
|
Christopher Williams
|
98988e04ec |
phase12: PLAN approved — milestone 750 bodies (+148), stretch 800
Approved by the developer 2026-09-24: milestone 750, stretch 800; both harness repairs authorised; Goal B (the 92-unclassified negatives) in scope and bounded; 4 workers — two on the fresh band, one on the 101 named negatives, one on the third fresh slice plus the 92 unclassified as the Goal B worker; compaction-first. THE ONE STRUCTURAL FACT THIS PLAN IS BUILT ON, measured at the open: 0 of the 193 near_match_negatives rows appear in the 1001-row worklist. The negatives index is held OUT of the worklist (sf3_triage plan --negatives) and is not a queue — it is an index, and a worker dispatched only from the worklist can never reach it. So the negatives pool becomes a first-class partition with its own worker, and the phase's structural change is that it stops being an appendix. Two pools, measured: 1001 fresh rows (410 of them <=244 B) plus 193 attempted-but-unresolved negatives, of which 101 carry a NAMED mechanism and are overturnable by cookbook 182's rule, and 92 carry no class at all and cannot be attempted until someone re-reads them. That is what Goal B is for. The plan states plainly that +148 is LARGER THAN ANY PHASE SO FAR (Phase 11 closed +118) and that it cannot be reached from the fresh worklist alone — it depends on the negatives-overturn programme working at scale, which is a measured route but only a ONE-ROW demonstration so far (worker F's 0x8002622C). Two safeguards are built in rather than discovered late: the cycle-1 checkpoint must include at least 8 bodies from the negatives pool, so a low overturn rate is measured in cycle 1 and not at the close; and the leading-indicator rule stands unchanged — report the projection and ask, never redefine or self-certify the milestone. Also recorded: the fresh-band size distribution, the negatives class distribution, and the baseline revalidation table including the failed precondition that T0 repaired. |