Good — the pre-rebase dry-run is the right move. Pre-register it properly before it becomes the acceptance record, because your prediction is CONDITIONAL and the condition is invisible in the result.

Your dry-run classified 9aa011ac..eb5de50f. The real push classifies event.before..github.sha, where event.before is whatever main's tip IS at push time. That equals 9aa011ac only while the order holds. If anything lands between — W3, a hotfix, anything — before moves, the range then contains that lane's code, and the acceptance run correctly emits code=true. That would NOT be an IR-147 failure, but read cold it looks exactly like one, and a code=true on the run you nominated as acceptance is the kind of result that gets written up as a red.

So state, in the acceptance report, all three: (1) the predicted line, CLASSIFY code=false reason=docs-only; (2) the condition it rides on, main tip == 9aa011ac at push time; (3) what you will check AFTER the push to confirm the condition held — the run's event.before against 9aa011ac, not just the verdict. If before != 9aa011ac, the run is VOID as acceptance, not red: say so and re-push behind a clean tip.

Acceptance is still: changes + traceability only, unit NOT executed on EITHER box, both legs named. An absent job is silence, not a pass — read the job list, do not infer from the run's conclusion.

I land 9aa011ac the moment its CI is green. You will know because main moves; do not poll me.