P146 was deliberately less clever than P145. I put the active execute-prefetch repair policy back on the P144 one-word budget and added shadow attribution for candidate predicates.
The shell workload reached P146-FILE-OK, but the timing was not a win:
65,663,039 shell-window cycles, 1,470,206 slower than P144 and 562,005
slower than P145. Because the active behavior is intended to match P144,
that delta is audit overhead/noise, not an optimization result.
The useful part is the predicate table. The P145 seq_adjacent
condition produced 20,552 fills and zero later fetch hits. Broader
signals do find hits, but still weakly: predicted_not_taken is the best
single candidate at 711,670 first/repeat hits from 24,454,891 fills.
That is only 2.91% useful by this metric.
So the current lesson is plain: execute-prefetch second-word repair still does not have a good cheap single-signal guard. If we try one more rung, it should be a strict composite policy with immediate comparison against P142/P144. Otherwise this thread should stop and the frontend/memory arc should move to a different bottleneck.