RT 2026-07-24 - area 2 - opus (Opus 4.8) - yield 1

[ms609-agent]

opus (Opus 4.8) | effort: unrecorded | 2026-07-24

Migrated record. This round predates the move to Discussions; it is reproduced
verbatim below from dev/red-team/log.md, which is now closed to new entries. It is
posted here so this area has a round record whose createdAt orders correctly against
the other areas' — the backfill ran oldest-first for that reason. All fourteen posting
timestamps are later than the rounds they describe; the real date is in the title and
in the date: field.

⚠ Scoped round. This was one of the 2026-07-24 directed passes over what was new in
MaximizeParsimony since the previous inspection — not the area's full file list. The
seam verdict it records is about that surface. Read the verdict in the notes rather
than inferring one from the yield in the title: a low number here can mean the new
code was clean, which says nothing about the parts of the area it never opened.

---

area: 2 (Search topology invariants — DIRECTED round: "what's new in MaximizeParsimony since last inspection")
reviewed_by: opus finder (aa75cdea) + haiku verifier (a67fbb31) + orchestrator (advisor-briefed scoping)
date: 2026-07-24
tier: opus (Opus 4.8)
yield: 1 (T-334 P3 — low-sev, exact-preserving, opt-in prototype consistency; found OFF the reject angle)
notes: First area-2 review since 2026-05-26 (2-month gap; that round was yield-0 AND pre-tier AND
predates this entire new surface → this is a fresh-surface opus first pass, NOT a dry-seam re-mine —
do not misread it as violating escalate-on-empty). Angle = topology-restore-on-REJECT (the canonical
area-2 bug class: T-235 stale SPR state, drift saved_postorder, T-316 stale constraint metadata — "stale
state survives a rejected move"), deliberately ORTHOGONAL to the area-1 (2026-07-24) scoring angle:
L3b edge-set VALUES (byte-identical to from-scratch, accept-dense oracle) + the cutoff trajectory were
handed to the finder as area-1 GIVENS, NOT re-verification targets (anti-collision — prevents an opus
finder re-closing area 1's work). Advisor's load-bearing insight (shaped suspect #1): area-1's oracle
proves relative correctness (incremental tracks compute_insertion_edge_sets), but 00d73d6a (skip
per-clip zero-fill) modified that from-scratch reference function ITSELF → the oracle is structurally
BLIND to whether from-scratch is still correct post-zero-fill-removal (a read-before-write / stale-slot
would be invisible by construction). RESULT: the four ranked reject-invariant suspects ALL resolved
clean at high confidence (static trace; the finder judged an oracle build not worth the stale-ABI risk
vs a confirmatory-only run — see below). (1) 00d73d6a zero-fill skip — closed by construction.
ts_fitch_combine tiles [0, sum_n_states) contiguously (block_word_offset = cumulative sum of
n_states, ts_data.cpp:325-337), so combine overwrites every word any reader can touch; every reader
masks per-block to [off, off+n_states) (fitch_indirect_length_cached, ..._flat_x4:1041, IW cached
kernels); simd::any_hit_reduce never over-reads (4/2-wide loops gated, scalar remainder); the ONLY word
left unwritten is the trailing even-pad (ts_data.cpp:333-337, odd sum(n_states)) and no reader reads it
unmasked. Zero-fill was pure waste; removal safe on real NDEBUG. (2) L3b base-incremental rollback on
reject (d9e6515a, default-ON n_tip>=150) — closed by construction. edge_set_base/up_base are
mutated ONLY inside the if (keep_going) accept block (update_base_after_spr_move, ts_tbr.cpp:2877);
patch_insertion_edge_sets takes up_base as const; the per-clip restore (:2597) writes only the
WORKING buffers (edge_set_buf/edge_set_up) over l3b_changed and clears it before the accept/reject
decision; exactly one accept per clip-pass (break :2915). So within a pass the base is a read-only
reference describing exactly the tree each rejected clip restores to → a reject provably cannot leak a
stale base slot. (Area-1's oracle ran accept-DENSE, which is why this reject-path rollback was still open
going in; it is now closed analytically.) (3) x4 reroot-batch (994f19a9 default IW + 20c96e52/
d6856bc5) + spr_search-default (ae62e0a8) reject paths — ruled out. spr_search saves/restores both
prelim and final_ via save_node_state/restore_saved_states; the T-235 regraft_was_rescored
full_rescore is intact (the exact directional scorer changes only WHICH array is read, not the restore
requirement); x4 batch is read-only on persistent state; drift exact scorer (TS_DRIFT_EXACT, opt-in)
recomputes edge_set_buf FRESH per clip (no cross-move persistence, unlike L3b). (4) 5d7e7c2c
collapsed_all_zero refresh → surfaced the one finding, T-334. T-334 (P3, verified REAL by haiku):
the aggressive-collapse neighbourhood criterion is applied inconsistently across the four
compute_collapsed_flags* recompute sites — the initial (ts_tbr.cpp:1539-1540) and default-root-edge
(:2967-2968) sites branch on collapse_aggr; the post-accept (:2859) and legacy-reroot (:2991) sites call
plain compute_collapsed_flags UNCONDITIONALLY. Under the opt-in default-OFF TS_COLLAPSE_AGGRESSIVE=1
(set once :1536), the collapsed set is aggressive for pass 1 then silently reverts to conservative after
the first accepted move. EXACT-PRESERVING — collapsed[] feeds only enumeration skip/continue
conditions (:1903,2177,2305,2446), never a scorer, and conservative marks a strict subset collapsible
(only widens the neighbourhood, never hides a move) → cannot corrupt a score or the MPT set; the defect
is purely that the opt-in prototype's neighbourhood-reduction is inconsistent within a search (muddies A/B
against it). Filed for the prototype author to adjudicate rather than fixed inline (plausible
intentionality + shared-branch no-edit discipline). UPDATE (same day, concurrent session): T-334
adjudicated UNINTENTIONAL (briefing dev/plans/2026-06-22-collapse-aggressive-strategy-briefing.md
documents only testing/results, no "explore-then-settle" rationale) and FIXED — branch on collapse_aggr
at :2859/:2991 mirroring :1539/:2967, rebuilt clean; findings.md row marked Closed. The ts_tbr.cpp fix is a
parallel session's in-flight edit (NOT committed by this red-team round — [[concurrent-session-git-hazard]]). Ruled out: ts_pool (relocated 78b74147, behaviour unchanged) — dedup is split-based
(compute_splits/compute_collapsed_splits+splits_equal, topology-invariant), eviction is
score+diversity, and pool add()/add_collapsed() is decoupled from the TBR accept/reject cycle → no
reject interaction. ts_tree ASAN/zero-Fitch/T-327/T-329 changes are UB/crash/constraint-construction
guards outside the save/restore machinery (T-327 = a build_postorder cyclic-tree backstop, inert for
valid trees — off the reject angle). Latent, not a bug: spr_search leaves prealloc_undo nullptr
(only tbr/drift/temper set it) → its save/restore uses the slow per-clip NodeSnapshot heap path; correct
but a per-clip alloc cost, matters only if spr_search is promoted onto a hot production path (the exact-
scorer default now makes an SPR warmup viable). Oracle NOT run locally (the brief's cheap reject-dense
TS_L3B_INCREMENTAL=1 TS_L3B_ORACLE=1 experiment): a reliable build is a preclean full rebuild
(stale-ABI hazard, [[stale-object-abi-gotcha]]), not the ~30s local budget, and it is confirmatory-only —
patch holds up_base const so rejects provably can't mutate the base, and both oracle sides read
tree.prelim so it can't catch a prelim-coherence bug anyway. If belt-and-suspenders wanted, offload to
Hamilton ([[feedback-no-local-heavy-compute]]). Seam status: RAN DRY on the reject-invariant angle at
opus-4.8 — the high-value new surface (suspects #1-#4) is exhausted; the one finding is a low-sev off-angle
consistency nit. (As recorded 2026-07-24: "per doctrine (dry static opus on a numerical core ⇒ escalate),
next area-2 visit escalates to FABLE".) RE-TARGETED 2026-07-27 by the opus version bump: the next area-2
visit is opus (Opus 5) with a fresh-angle brief, NOT fable (version bump before rung bump; fable is the
step after Opus 5 also runs dry). Everything below is UNCHANGED — that round must still carry BOTH
unconfirmed residuals with the RIGHT check for each (a static-only retirement of #1 is exactly what the
escalation exists to double-check; do NOT let the blind spot propagate by re-aiming only at #2): (#1, ORACLE-BLIND — the higher-value carry-forward): absolute
correctness of compute_insertion_edge_sets AFTER the 00d73d6a zero-fill removal. The L3b oracle CANNOT
see this — both oracle sides now call the same zero-fill-skipped from-scratch, so "zero mismatch" can never
detect a from-scratch bug. Confirmable only by end-to-end score/reach-equivalence vs an INDEPENDENT
baseline (non-incremental score_tree, or a pre-00d73d6a build) on homoplasy-rich data. Blast radius
bounded to REACH, never a wrong returned score, by the full_rescore firewall: compute_insertion_edge_sets
feeds candidate SELECTION/bounds, not accepted scores; accepted scores are ALWAYS full_rescored (T-235
lineage, regraft_was_rescored intact) → a zero-fill bug's worst case is a wrongly-bailed candidate =
reach/quality degradation. (This firewall — not the tiling-completeness argument — is what makes shipping
this round safe.) (#2, ORACLE-VISIBLE): value-correctness of update_base_after_spr_move across many
consecutive same-pass-then-next-pass accepts on large real data (n_tip>=150 default-ON) → the Hamilton L3b
oracle CAN confirm this (incremental vs from-scratch). Both checks are Hamilton-class
([[feedback-no-local-heavy-compute]]); mirrors the area-1 escalation residual on ts_fitch_combine absolute
correctness. All traces at the current cpp-search tip; no builds, no commits, named-file edits only
(findings.md + this log). NEXT ROTATION AREA = 3 (Ratchet & perturbation).