[Jinwoo-H]

	Files	Added	Deleted	Net
Test	0	0	0	0
Prod	788	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​788	$\color{#cf222e}{\Huge{\mathbf{−}}}$​788	0

The four page PRs that landed today (#22549, #22556, #22569, #22570) changed fenced paths (mobile/src, mobile/app) without touching the recording corpus. The corpus still reproduces byte-identically from the old pin (the pin guard's reproduce job stayed green on every one of them and main's ancestry check is green), but the recorder refuses --record while the fenced tree differs from its baseline, so no new scenario can be recorded until the pin moves. This repins the corpus to main's tip 37820f9. Every golden changes only its baseline line (788 files, two distinct changed lines after masking the sha); recorded fresh with --record (148 s), and the recorder's own ancestry and reproduce checks pass from the pinned tree. Same shape as #22407 after #22381.

[pullfrog]

✅ No new issues found.

Reviewed changes

• Corpus-wide repin — all 787 goldens under mobile/rpc-foundation/goldens/ plus pilot-scenarios.json change exactly one line: the baseline header from 996f9cc3068c… to 37820f9683527becf68d8d4d4fb564f32c49e72d. Collapsing every added/removed line confirms it — 788 additions all equal the new line, 788 deletions all equal the old, nothing else moved.
• Pin names a real, reachable tree — 37820f9683 is main's tip at review time (#22570) and the sole parent of the single repin commit, so the guard's ancestry check holds. No file elsewhere in the repo references either sha.
• Reproduction still owns the verdict — mobile/src is a fenced path, so the guard's reproduce --if-changed-since job checks out the new pin, overlays this tree's recorder, and replays the corpus in CI. Because it runs on every corpus provenance change, passing it is what certifies a header-only repin like this one; README.md step 4 predicts exactly this "header-only" shape.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}