Lower-table census, battery 1: integer/move exact; Q-pipeline anomaly open
==========================================================================
14 lower ops x 400 cases x {default, exactdiv}, full-state diff.

Verified exact (all state, both configs):
  IADD ISUB IADDI IAND IOR  -- the integer ALU is bit-exact between
    engines (executed-effect confirmed: results land in VI)
  MOVE MR32 MTIR MFIR       -- register moves exact (MTIR effect
    confirmed, 371/400 nonzero results)

Memory family -- VERIFIED EXACT (memory-seeded battery):
  LQ SQ ILW ISW LQI SQI LQD SQD ILWR ISWR, 400 cases each against
  per-case deterministic pseudorandom VU data memory
  (ps2_audit_vu_memfill), with full-state register comparison AND a
  post-run memory hash (ps2_audit_vu_memhash) per engine. All rows
  bit-identical on both. Executed-effect held throughout: loads
  carried nonzero varied data in 400/400, stores changed the memory
  hash away from the pure-fill baseline in 400/400 (the check that
  distinguishes agreeing stores from agreeing inaction), ILW landed
  nonzero VI results in 400/400. The battery-1 LQI/SQI weak rows are
  superseded at full strength.

Battery 2 -- flag ops, R ops, branches: ARCHITECTURALLY EXACT
  24 ops x 400 cases: IADDIU ISUBIU, RINIT RGET RNEXT RXOR, FSEQ
  FSSET FSOR FMEQ FMOR FCEQ FCAND FCOR FCSET FCGET, IBEQ IBNE IBLTZ
  IBGTZ IBLEZ IBGEZ B BAL. Branch takenness exercised both paths
  (146-275 taken per row, marker-instruction discrimination) and
  every observable result -- VF, VI results, branch markers, flag-op
  outputs -- is bit-identical between engines.

  Rig fix banked: the recompiler's status-flag instances hold an
  internal layout, and seeding them with the raw architectural
  value mangled the block-end normalize; the exec export now seeds
  through the same denormalization the core applies to CFC2-written
  status (mVUallocSFLAGd's mapping). Before the fix this manufactured
  phantom divergence in every op; after it, flag-reader RESULTS are
  exact.

  Representation notes (architecture-equal, recorded for savestate
  fidelity review, not correctness findings):
  - R register: interpreter stores hardware format
    (0x3F800000|mantissa), recompiler stores the bare 23-bit
    mantissa and re-ors on RGET; RGET results are identical.
  - Raw VI[REG_STATUS] after a recompiled block that never computed
    flags differs from the seed in single sticky bits (the rec exit
    path's sticky handling); every flag READ (FSAND FSEQ FSOR FCGET
    results) agrees, so the difference is invisible to programs.

Battery 3 -- register jumps and VIF reads:
  JR and JALR exact (0/400 each) with landing-pattern verification
  across four target pairs: every pattern shows the branch delay
  slot executing before the landing point, identically in both
  engines (e.g. target pair 4 yields markers 1,0,0,1 -- the
  delay-slot marker plus the landing tail), and JALR's link write
  agrees. XTOP/XITOP agree structurally (both engines read the same
  vif top/itop globals) but coverage is thin: the values were zero
  at both the boot and in-game sample points, so the address/masking
  of the read is unexercised; recorded as weak rows, semantic risk
  minimal. XGKICK is out of rig scope -- its effect is a GIF-path
  side transfer, which needs GIF capture comparison, not register
  diffing.

LOWER TABLE STATUS: complete. Integer ALU, immediate ALU, moves,
memory family (seeded), Q pipeline (exact under exactdiv, oracle
fixed), R ops, flag ops, branches with delay-slot verification, and
register jumps -- all architecturally exact. Remaining VU items are
the weak-coverage notes above and XGKICK's out-of-scope transfer.

Q pipeline -- RESOLVED (this commit):
  The "lane-selection anomaly" was a rig readback artifact: the
  recompiler retires committed Q into VI[REG_Q] (microVU_Branch
  block-end flush), not the q field the readback compared, so the
  Q column was seed-vs-computed. The lane-identified probe (distinct
  exponent per lane, 16 fsf/ftf combos) then showed 16/16 bit-exact
  agreement -- no decode disagreement exists. The exec export now
  mirrors the recompiler's committed VI[REG_Q]/VI[REG_P] into the
  q/p fields so the readback slots are engine-agnostic.

  Real Q census (400 cases): default DIV 183, SQRT 106, RSQRT 184
  divergent -- one-ulp chop-vs-model plus overflow clamp-vs-saturate,
  the classes exact divide exists for; wire proven live (183/400
  def-vs-exactdiv rec deltas). Under exactdiv: DIV 0, SQRT 0,
  RSQRT 7 -- and the RSQRT residual was an ORACLE bug: every case
  was ft = -0, where the interpreter's hand-coded zero-denominator
  path XORed both signs while the hardware-verified model, the
  exact stub, and the recompiler's default emission all agree the
  sqrt stage strips the denominator sign (saturation by numerator
  sign alone). With the interpreter corrected: DIV 0, SQRT 0,
  RSQRT 0 -- the exact-divide option is bit-exact for the entire
  Q pipeline, its first accuracy verification.

Rig lessons banked this battery:
  - The q field sits at regs_io offset 656 (after the 16-byte ACC at
    640); the first analysis read 644 -- inside ACC -- and produced
    an all-zero Q column that the executed-effect check (q_out must
    differ from q_in) exposed. That check is now part of the
    standard battery integrity set alongside files-must-differ and
    known-answer splits.

Fused/composite front, adversarial re-census (session findings, no
code change shipped):
- The clampE-branch hypothesis for the old fused residual is
  DEPRIORITIZED by measurement: routing the accurate option through
  the exact stage in clampE mode changed nothing on any measured
  row (old and new binaries byte-agree across the battery), i.e.
  clampE is not set in the measured contexts. The candidate edit
  was reverted rather than shipped unproven.
- The adversarial operand mix (25% FMAX-class, 10% raw exp-255
  register values -- 0x7F800000 / 0x7FFFFFFF patterns as direct
  VF/ACC inputs, a class the earlier 1600-case distribution barely
  sampled) opens two characterized fronts:
  1. Plain SUB diverges 205/400 while plain ADD is 0/400 on the
     SAME distribution under both accuracy options. The composite
     folds subtraction into a sign flip on the masked copy; that
     fold mishandles an operand class addition survives. This is
     the sharper lead: one code path, an A/B contrast on identical
     inputs, and the exact stage's own subtract semantics to read
     against the ps2f model.
  2. Fused MADD/MSUB at 115-122/400 with raw exp-255 register
     operands -- the old 15-16/1600 was this class undersampled
     through product-generated saturation only.
- Next session: anatomy peek on the SUB divergents (operand
  patterns vs results, oracle sanity per rule 10), then the sign
  fold read. Distribution note for all future FMAC batteries: raw
  exp-255 register operands are mandatory, not optional.

SUB/ADD asymmetry -- CLOSED (follow-up to the elide commit): the
anatomy peek showed every divergent SUB lane carrying a raw exp-255
operand, the oracle arithmetically correct by inspection, and the
recompiler's results all clamp signatures (several with the wrong
sign). The source is mundane: mVU_SUB carries Kingdom Hearts-era
input clamp flags (cFs|cFt) that mVU_ADD does not, and those clamps
flattened exp-255 operands before the accurate composite's detector
could route them -- ADD's exactness on the same distribution
through the same composite is the proof raw operands are handled.
The fix extends the exactmul elide: under the accurate add/sub
option, add/sub input clamps are elided. SUB: 205/400 to 0/400; ADD
and MUL hold at zero; default rig outputs byte-identical; 300
frames of Tekken under the option pixel-identical. MADD/MSUB
(115-122/400) remain open -- their clamps live in the fused FMAC
bodies and get the same per-site treatment next session.

Fused front, the decomposition probe -- mechanism NAILED, design
work scoped (no code shipped this session; a candidate cACC-clamp
elide measured as a no-op in every tested context and was reverted
per the standing rule):
- Decomposed MUL-then-ADD over the identical operands and dataflow:
  0/400 -- the standalone composites are exact on everything the
  fused ops see, saturated products included.
- Fused MADD on the same cases: 158/400. And the decisive third
  number: the decomposed ORACLE disagrees with the fused ORACLE on
  exactly those 158 cases. The interpreter's MADD is not
  mul-then-add: the hardware model's fused datapath hands the adder
  the pre-saturation wide product (exponent above 255 preserved
  into the add), where the recompiler's fused path -- and any
  decomposition -- adds the saturated float. On saturating products
  the two semantics differ, and the recompiler currently implements
  decomposition semantics.
- The closing work is therefore a design item with an exact spec:
  the fused composite's mul stage must hand its add stage the
  pre-saturation exponent/mantissa (the exact stage already
  computes wide intermediates internally; the hand-off must bypass
  the float-format saturation between stages). Verification target:
  fused rows to 0/400 on the adversarial distribution, plain rows
  held at zero, default byte-identical, pixels identical.
- Prerequisite before any emission work, per rule 10: confirm the
  oracle's fused-vs-decomposed split against hardware expectations
  (the ps2f suite's MADD lineage), since this is now the load-
  bearing semantic claim. One hardware capture -- FMAX*FMAX MADD
  -FMAX on silicon -- settles it alongside the queued CFC1 and EFU
  items.

Fused MAC overflow rule -- IMPLEMENTED AND CLOSED (this commit):
the model's own source supplied the exact semantics ahead of the
hardware capture (ps2f_mac_finish: mul-stage overflow forces the
sign-selected all-ones saturation pattern regardless of the add;
MADD's pattern sign follows the product, MSUB's is flipped), which
derisks proceeding since the model is the hardware-verified suite's
encoding; the silicon capture stays queued as confirmation. The
emission is a per-lane detect-and-blend around the fused add,
active under exactmul+accurate-addsub: the exact mul already leaves
true overflow as the all-ones pattern in the product register, so
detection is a magnitude compare (|prod| == 0x7FFFFFFF) -- the
first, broader exponent-field detector wrongly captured exp-255
products with computed mantissas, which come from exp-255 INPUTS,
carry no overflow in the model, and flow into the add normally
(residual 3-5/400 with that detector, anatomy on record). With the
pattern detector: MADD 115-to-0, MSUB 122-to-0 on the adversarial
distribution, the decomposition probe's MADD row also zero, plain
rows held at zero, default rig outputs byte-identical, 300 frames
under both options pixel-identical. FMACb (MADDA/MSUBA) is not yet
wired -- same helper, its ACC dual-path insert next session, with
MADDA/MSUBA rows added to the adversarial battery. Flag-side OF
forcing for blended lanes is ledgered with the flag residuals, not
silently claimed.

FMACb (MADDA/MSUBA) -- wired and closed (this commit): the same
detect-and-blend helper inserted around both of the body's add
paths (the direct-ACC full-mask path and the tempACC masked-merge
path, the blend applied before the merge so partial-dest writes
stay correct). MADDA 169-to-0 and MSUBA 169-to-0 on the adversarial
distribution with ACC as the compared surface; MADD/MSUB control
rows held at zero; default byte-identical; 300 frames under both
options pixel-identical. THE FUSED FAMILY IS COMPLETE: every
measured VU FMAC op -- ADD SUB MUL MADD MSUB MADDA MSUBA -- is
bit-exact under exactmul plus accurate add/sub on the adversarial
distribution, raw exp-255 operands and saturating products
included.

Flag front, adversarial opening census (values are done; this is
the flags ledger's first adversarial measurement, FSAND/FMAND
observed under exactmul+accurate-addsub):
  status/mac divergence per 400: ADD 34, MUL 370, MADD 375,
  MSUB 377, MADDA 377, MSUBA 379.
  The anatomy is singular: EVERY divergent case differs in the O
  bit alone -- status bit 3, its sticky bit 9, and the mac O
  nibble; Z/S/U columns are exact throughout. The recompiler
  under-reports overflow the oracle sets.
  Two distinct mechanisms, both with designed probes:
  1. ADD/SUB: overflow detection is structurally disabled -- the
     class gate (ovfDetectOK) enables the detect block for the
     mul family only, a correct default-mode economy; under the
     accurate option the composite produces genuine exp-255
     results whose O the detect block would need to see. Probe:
     extend ovfDetectOK to add/sub under CHECK_VU_ACC_ADDSUB and
     check whether the existing cmpnltps detector (unordered-true
     on the exp-255 pattern) already suffices.
  2. MUL and the fused family: ovfDetectOK is true there, yet O is
     missed at adversarial density under exactmul. Probe: the same
     spec in default mode -- if default MUL sets O on these cases
     (the class-gate arc's numbers say its detector works), the
     exactmul path specifically loses or bypasses the detection,
     and the emission read starts at the exact composite's
     interaction with mVUupdateFlags.
  Games reading flags at this operand density are rare; the values
  campaign's exactness stands regardless. This is the ledger the
  fused commits pointed to, now with numbers and a mechanism split.

O-flag closure, session 2 (this commit): the mechanism behind
rec-O-equals-zero was one gate -- the entire overflow-detect block
was emitted only under the overflow GAMEFIX (CHECK_VUOVERFLOWHACK),
so no non-hack mode ever detected overflow; the class-gate arc's
working numbers were measured with the hack on. The detect block
now also emits under either accuracy option, with the detector
itself split by mode: the historical float threshold (result >=
FLT_MAX, correct when clamps make FLT_MAX stand for overflow) in
hack mode, and an integer equality against the all-ones exp-255
pattern under the accuracy options, where FLT_MAX is a legitimate
value (the threshold form spuriously fired on every legitimate FMAX
add: 34-to-358 before the split).

Scope, measured honestly: the value-pattern proxy is EXACT for the
mul family -- exp-255 inputs yield exp-255-with-mantissa products,
never all-ones, so all-ones equals a genuine overflow event -- and
MUL closes 370-to-0/0. It over-fires on add/sub, whose results can
be all-ones by pass-through of an exp-255 operand with no overflow
event (an ovfDetectOK extension to add/sub was measured, made ADD
worse, and was reverted). Final adversarial columns: MUL 0/0, fused
status 3-5 and mac 36-41 (from ~377 across the board), ADD 34/34
unchanged. Default emission byte-identical, 300 frames under both
options pixel-identical.

Remaining design item, precisely specified: add/sub (and the fused
residual's mac lanes) need the EVENT, not the value -- the exact
composite's internal es>255 saturation mask exported from the add
stage to the flag block. That export is the flag front's last
rig-side item.

Event-mask export -- LANDED (this commit): the exact add stage
spills its per-lane es>255 saturation event (in architectural lane
order -- the stage's internal order is reversed at the computation
point, caught when the mac O nibble read back bit-reversed while
the order-blind status OR was already exact), every non-exact path
zeroes the spill first, the fused blends OR their mul-overflow
lanes into it, and the flag block reads the event instead of any
value proxy for accurate add/sub. Adversarial columns after:
  status: ZERO across all six ops (from 34-379).
  mac:    ADD 0, MUL 0; fused 291-312 remain.
The fused mac remainder survives the lane fix that closed ADD, so
its mechanism is in the fused flag composition itself (the
blend-OR interaction or mac_finish's per-lane flag replacement
semantics), not the spill -- post-fix anatomy examples are in the
transcript, next session's first peek. RESOLVED (this commit): the
correlation peek plus the oracle's mac-update source located it as
one more lane-order seam -- the spill is stored in the reversed
convention the flag block's movmsk/shl path expects (which is why
ADD closed), while the fused blend-OR contributed its mul-overflow
mask in architectural order, landing blend lanes mirrored in the
mac nibble. Reversing the mask for the OR (and restoring it for the
value blend) closes everything:

  FLAG FRONT FINAL: status 0 and mac 0 across ADD, MUL, MADD,
  MSUB, MADDA, MSUBA on the adversarial distribution -- the front
  that opened at 34-379 divergent cases per op ends at zero
  everywhere. Default emission byte-identical; 300 frames under
  both options pixel-identical.

With this, the campaign has no open rig-side items: VU values
exact, VU flags exact, EE table complete, both processors priced.
What remains is hardware minutes (CFC1 round-trip, fused-MADD
confirmation, EFU sweeps) and the maintainer's promotion
decisions. Default emission
byte-identical; 300 frames under both options pixel-identical.
