[ViperJuice]

Fixes two live defects on main, both introduced by #192. The correctness seat reported them after that PR merged — I had not frozen the branch, which is my process error, not the seat's.

Both confirmed against nopt and the real npm binary before acting.

1. A blanket null rule minted wrong identities across ~193 boolean entries

#192 added "null" to the boolean-literal set for the whole table. nopt consumes null after only the 5 nullable booleans (null|Boolean): expect-results, optional, production, workspaces, yes. For every other boolean, null is the positional — and null is a real published npm package.

nopt: npm exec --global null zz  -> remain ["null","zz"]    package is null
nopt: npm exec --yes    null zz  -> remain ["zz"]           package is zz
main: both returned zz

A fourth set, _NPM_NULLABLE_BOOLEAN_FLAGS, is derived from the same null|Boolean test the generator already performs — 12 spellings including --no- negations and the -y / --ws shorthands.

Worth naming: my plan-round correction — "drop null, it means unset" — was right about classification and I wrongly generalised it to parsing. The same word means different things in the two places.

2. npx inverts literal consumption, and #192 regressed it

bin/npx-cli.js pre-scans argv and inserts -- before the first positional, so a plain-name boolean switch never consumes a literal under npx. Confirmed against the real binary, not just the parser:

npx --offline --global true zz-not-a-real-pkg  ->  fetches registry.npmjs.org/true

The package is true. #192 returned the trailing token — and its own test pinned that wrong behaviour (test_real_boolean_still_consumes_the_literal, with command="npx"). That test now uses npm; the npx case is covered separately.

npx now refuses on a literal rather than modelling the rule, because the --no- family behaves differently again — the pre-scan doesn't recognise no-X as a switch, so nopt still consumes there. A refusal cannot mint a wrong identity, and a config carrying a bare true/false/null after a boolean is vanishingly rare.

My first cut broke npx -y pkg

The most common MCP launch form. I consumed a token in the non-literal path. The new tests passed — only re-running the full regression set caught it. That is the fourth time this session a fix for a board finding introduced its own defect, and precisely why the regression set is maintained separately from the tests.

Verification

2810 passed, 3 skipped, 0 failed      ruff + mypy clean
manifest: 98 servers, 0 unknown

All 8 regression forms intact — npm --silent exec pkg, npm exec pkg, npm install i, npm exec exec, npx -y exec, npx -y pkg, npm exec -- pkg, npm exec --global false a.

All 5 of #180's original collisions still closed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbREMUsxgJ8TDBLpJ56PWb

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}