Files
Syphon_Filter_3/src
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.
2026-09-24 18:15:57 -04:00
..