## The pretest-validator mirror is stale by two
```
assert.deepEqual(PRETEST_STATIC_CHECK_SCRIPTS, PRETEST_CHECKS);
+ 'scripts/check-no-cwd-relative-dashboard-test-reads.mjs',
+ 'scripts/check-capacity-pool-id.mjs',
```
Production found ten validators; the test's mirror listed eight. **The
world was right and the assertion was stale** — the good direction.
`PRETEST_STATIC_CHECK_SCRIPTS` is *derived* from `package.json`'s
pretest chain, so `verify:fast` picked both new validators up
automatically when they were added. They are real scripts, they run in
pretest, and verify:fast was already running them. Only the mirror
needed telling.
Added in production order, since the assertion is a `deepEqual` and
order is part of it. Plain strings for these two — the surrounding
entries are split and re-joined to keep banned phrases (the port-kill
and nohup literals) off a single source line for the policy scanner, and
neither new name contains one.
## The guard is load-bearing — verified against the source of truth, not
the mirror
Syncing a mirror is worthless if the assertion can no longer fail, so I
mutated `package.json`'s pretest chain rather than the test:
```
dropped check-capacity-pool-id from pretest → ℹ pass 16 ℹ fail 1
restored → ℹ pass 17 ℹ fail 0
```
So it still catches a validator silently leaving `verify:fast`, which is
the regression that actually matters. `package.json` is restored; the
diff here is the test file only.
## Second of seven, and the contrast is the point
This is the second of the seven red `scripts/__tests__` suites I found
on clean `main` (after #3036). It was genuinely mechanical.
`workflow-reliability-release-check` was not, and I did **not** fix it —
diagnosed on #3036 instead:
`docs/custom-workflow-reliability-acceptance-map.md` cites 13 test files
of which **8 are missing**, and **2 of 5 rows have zero surviving
evidence**, including *"a custom workflow can be authored/imported,
rejected on invalid IR, saved, discovered, selected, and reloaded"*. The
obvious repoint would have turned it green while the behaviour stayed
unverified.
That contrast is why I am taking these one at a time rather than
sweeping them green: two of seven look identical from the failure line,
and only one of them is safe to fix without owning the subject.
## Verification (measured)
- this suite — **17 passed / 0 failed** (was 1 failed)
- `eslint` — clean
Test-only. No changeset.
19b97e9f09