## A release-safety alarm that was firing on wording
```
AssertionError: dry-run must exit before proceed confirmation
```
The probe searched for ``await confirm(`Proceed with release``. The
prompt has since become:
```js
await confirm(`Proceed with ${CHANNEL} release v${chosenVersion} (build, publish to npm tag '${NPM_DIST_TAG}', tag)?`)
```
so `indexOf` returned **-1**, `dryRunExitIndex < -1` was false, and this
has been red on `main` ever since.
## The property itself holds — verified directly, not inferred from a
green suite
| | offset |
| --- | --- |
| first `if (DRY_RUN) {` guard, calling `process.exit(0)` | **28808** |
| the sole `await confirm(` call site | **44503** |
Two dry-run exit guards, one confirmation, exit first. **`pnpm release
--dry-run` cannot reach the proceed prompt.** This was never a real
safety failure.
The probe is narrowed to the stable prefix `await confirm(\`Proceed with
`, which still names the one confirmation in the file while surviving
the interpolated channel and version. The sentence was never the safety
property.
## Why this one mattered more than an ordinary stale probe
A stale probe on a *safety* test spends the alarm on cosmetics. Everyone
learns the assertion is red for no reason — so a genuine reordering
later arrives at an alarm nobody reads. That is a worse outcome than the
test not existing.
## Proven to still catch the real regression
I injected a `confirm(` call **above** the first dry-run exit in
`release.mjs`:
```
confirm injected before the dry-run exit → ℹ pass 5 ℹ fail 1 (dry-run must exit before proceed confirmation)
reverted → ℹ pass 6 ℹ fail 0
```
**No release command was run.** The mutation was local to a scratch copy
of `release.mjs`, reverted immediately, and the working tree verified
clean — `release.mjs` is untouched by this commit, and the diff is the
test file only.
## Fifth and last of the mechanically-fixable suites
That closes the mechanical half of the seven red `scripts/__tests__`
suites I found: `plugin-authoring-docs` (#3036), `verify-fast` (#3038),
`ci-test-shard-timings` (#3040), `engine-vitest-gate-policy` (#3044),
and this.
**`workflow-reliability-release-check` is the one that is not
mechanical** and I am still not touching it: its acceptance map cites 13
test files with **8 missing** and **2 of 5 rows carrying zero surviving
evidence**. That needs its owner to decide, per row, whether the
coverage moved or was deleted — a repoint would launder the gap
(diagnosed on #3036).
Five of six looked identical from the failure line. Only that one is
unsafe to fix without owning the subject.
## Verification (measured)
- this suite — **6 passed / 0 failed** (was 1 failed)
- `eslint` — clean
Test-only. No changeset.
53aef245f9