Lazy `apply_tbr_move` rescore in `tbr_search`

[ms609]

Priority: P3 · Former status: PARKED (d7, other ) · Blocks: —

Lazy apply_tbr_move rescore in tbr_search. After the score_fresh flag was wired (companion to T-187/PSF work), the trailing full_rescore at function exit is now skipped when states are coherent. The remaining redundancy is the full_rescore(tree, ds) call at ts_tbr.cpp:1134, run after every successful apply_tbr_move to obtain the authoritative score for the acceptance check. Each call is O(n_node × total_words). Since the move is local (clip + reroot + regraft), the indirect-evaluation pre-check at ts_tbr.cpp:767-772 already shows that fitch_incremental_downpass/uppass from the join point gives the correct score in O(affected_subtree_depth × total_words) instead. Plan: make apply_tbr_move push touched nodes onto the prealloc_undo stack, return the join node, and replace line 1134's full_rescore with fitch_incremental_downpass from that node. Estimated savings: O(n_char) per accepted move × ~10–100 accepted moves per replicate. Risk: medium — apply_tbr_move is the hot correctness-critical path; need careful unit tests covering NA/non-NA, IW/EW, constrained/unconstrained, equal-accept paths. Validate by comparing scores against current unconditional rescore on a battery of datasets before committing.

---

Migrated 2026-08-04 from the retired to-do.md; former task id T-300. Full original row: git show findings-md-final:to-do.md. Task state now lives in this tracker — see dev/red-team/migration-map.tsv for red-team ids.

[ms609]

Claiming this. Branch: claude/treesearch-issue-38-8103cc, worktree hungry-pike-343881.

First finding: the core of T-300 already landed (commits f531bbcd EW + 014ccdea NA dirty-set, plus bb421347 for the T-304 regression test) — the issue body's line numbers (ts_tbr.cpp:1134) predate it. The accept path at src/ts_tbr.cpp:2793-2840 now uses fitch_dirty_downpass/uppass for SPR-classified accepts. What remains under the fallback is (a) true TBR rerooting accepts and (b) HSJ/XFORM. Measuring whether either is worth the risk before writing any code.

[ms609]

Done — PR #47.

Two things worth recording here.

Most of this was already fixed. T-300 landed its SPR half in f531bbcd (EW) + 014ccdea (NA), so this issue text describes code that no longer exists — the cited ts_tbr.cpp:1134 predates the fix. The genuine residue was accepts that rerooted the clipped fragment, which still fell through to full_rescore. That is what the PR closes, via a third dirty seed at clip_node (the NA kernel already took one for exactly this region).

The estimated saving in the issue no longer holds. "O(n_char) per accepted move × ~10–100 accepted moves per replicate" was true in May 2026, when the accept path was 19.2 % of NA-path DLL CPU. After T-300 the whole accept branch is 0.18–0.51 % of tbr_search wall (in-DLL na_t_accept_ms, 15 paired cells across Vinther2008/Agnarsson2004/Zanol2014 × EW,IW). Finishing it cuts that slice ×0.901 ⇒ ≈0.03 % end-to-end. Rerooting accepts are ~18 % of accepts, so that is a genuine ceiling rather than thin coverage.

So the change is correct and score-identical, but its value is codepath unification, not speed. Area 4 is now recorded AT-LIMIT in dev/profiling/focus-areas.md, with a note that the T-300 rows "19.2 %" is the pre-fix figure and must not be read as a live target. Reopening condition: only if the accept branch is re-measured above a few per cent of tbr_search wall — e.g. if a future change makes accepts far more frequent, or moves scoring back onto a full-tree walk.