[Jinwoo-H]

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

What this is

A baseline repin of mobile's RPC recording corpus, the same shape as #21092 and #21065.

Every golden under mobile/rpc-foundation/goldens/ carries a baseline header naming the commit its recording was made against, and --record refuses to run unless the working product tree equals that commit. The corpus was pinned to 97aa5ff19b19231670ab7d06d070115640bb8f41, set by #21092. Two commits have landed on a fenced path since:

$ git log --format='%H %s' 97aa5ff19b19231670ab7d06d070115640bb8f41..origin/main \
    -- mobile/src src/shared mobile/pnpm-lock.yaml ':!mobile/src/test-support/rpc-recording'
9add08bb5943144f5fb0178ab628cdfebe99c22a test(mobile): recorder follow-ups — write ordinal, teardown streams, context anchor, salvage observation, provider pass-through, React draw (#21088)
85d1ffc0726d8403f9494436c421c5e3d7932c47 fix: accept enterprise managed GitHub owner logins (#20450)

So recording on main refuses:

Error: Product sources or lockfile differ from the pinned main baseline
    at <anonymous> (mobile/scripts/rpc-recording.mts:28:9)

What drifted

#21088 is the recorder follow-up branch, so it is the README's awkward case: it edited the recorder engine, which moves recorderSha256 on every golden and forces a full rewrite, while its own product tree no longer matched the pin. It re-recorded all 705 goldens and it changed two fenced product files, but it left pilot-scenarios.json alone, so the corpus kept naming the older tree.

fenced path #21088 changed	what moved
mobile/src/source-control/mobile-hosted-review-service.ts	dropped the provider type assertion
src/shared/rpc-contract/hosted-review-params.ts	provider opened from a closed enum to z.string()

#20450 added enterprise-managed owner-login handling under mobile/src/tasks and src/shared/github. Neither PR's product change is visible to any recording, which the decode below establishes rather than assumes.

The new pin

baseline in mobile/rpc-foundation/pilot-scenarios.json moves to 9add08bb5943144f5fb0178ab628cdfebe99c22a, main's last commit to touch a fenced path and also main's tip, and the whole corpus is re-recorded against it. git diff 9add08bb59 origin/main over the fenced paths is empty, so this is the only tree the fence can match.

No behaviour moved

Each golden was decoded through its own values pool against the origin/main copy, resolving 12-hex value references before the comparison and comparing the header key by key.

class	count
header-only	705
body moved	0
added	0
deleted	0

baseline is the only header key that differs on any golden, and it differs on all 705. lockfileSha256, recorderSha256, adapterSha256, scenarioSha256 and runnerVersion are unchanged everywhere, which is what a pure repin looks like. The unchanged recorderSha256 also says #21088's own refresh already carried the current engine digest.

The zero body moves settle the question the detached-pin recipe leaves open. #21088 recorded its goldens from a tree that was not main's, and those same bytes reproduce from main's product tree, so neither the loosened provider schema nor the enterprise owner-login change is observable through any recorded screen. The diff is 706 files, one line inserted and one deleted each.

Gates

Run from mobile/, all green.

gate	result
tsc --noEmit	clean
vitest run src/test-support/rpc-recording	20 files, 827 passed, 3 skipped
oxfmt --check .	2598 files correct

The full re-record itself passed 707 tests in 93s.

One recommendation

This is the third repin follow-up in a row, after #21065 and #21092, and the cause is the same each time. A PR that lands on a fenced path should repin baseline to its own last fenced commit in the same PR, which is the README's behaviour-change recipe. The recorder branches are the ones that keep missing it, because the detached-pin recipe hands them a valid recording without ever making them look at the pin. Recording from the detached pin and repinning forward are two different obligations, and #21088 discharged only the first.

Reproducing the typecheck in a fresh worktree needs mobile/src/terminal/terminal-webview-engine.generated.ts and mobile/src/components/pr-sidebar/mermaid-webview-engine.generated.ts, both gitignored postinstall artifacts. Running node scripts/build-terminal-webview-engine.mjs and node scripts/build-mermaid-webview-engine.mjs first clears the two TS2307 errors they otherwise cause.

[pullfrog]

✅ No new issues found.

Reviewed changes

A mechanical repin of the mobile RPC recording corpus after #21088, matching the documented squash-merge follow-up. Verified independently against the checked-out head:

• Repin baseline to main's tip — pilot-scenarios.json and all 705 goldens move baseline from 97aa5ff19b… to 9add08bb59…; origin/main is 9add08bb5943144f5fb0178ab628cdfebe99c22a, the new pin is an ancestor of it, and the fenced-path diff (mobile/src, src/shared, mobile/pnpm-lock.yaml, excluding the recorder dir) between the pin and main is empty.
• Header-only — the diff is 706 files at +1 / -1 each, and every added/deleted line is a baseline line. No values or other header key moved, so no recorded behavior changed; recorderSha256, adapterSha256, scenarioSha256, lockfileSha256, and runnerVersion are unchanged.
• Process — the log since the old pin over fenced paths is exactly the two commits the description names (#21088 and #20450), so the pin is the last fenced commit and the only tree the fence can match.

The trailing recommendation (fenced-path PRs should repin in the same PR, discharging both the detached-pin recording and the forward repin) is sound, but it is a process suggestion outside this diff and already recorded in the description.

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