wheels upgrade check scans only 3 of 11 documented 3.x→4.0 breakers

[bpamiri]

Describe the bug

wheels upgrade check --to=4.0.0 for currentMajor <= 3 && targetMajor >= 4 in cli/lucli/Module.cfc (around line 3591) only checks:

1. Legacy plugins/ directory exists
2. extends="wheels.Test" in any file under tests/
3. application.wirebox references in any file under app/

It misses 8 of the 11 documented breakers from the canonical 3.x → 4.0 guide:

• CORS default flip (deny-all)
• HSTS default on in production
• CSRF key + JWT alg validation
• allowEnvironmentSwitchViaUrl defaults to false in production
• RateLimiter trustProxy=false and proxyStrategy="last"
• CSRF cookie SameSite=Lax
• wheels snippets → wheels generate snippets CLI rename
• tests/specs/functions/ → tests/specs/functional/ directory rename
• Vite manifest strictness (viteStrictManifest defaults to true)

Why this matters

A 3.x user runs wheels upgrade check, sees only the WireBox bootstrap, the plugin folder, and the test base class flagged, upgrades, and then hits one of the unscanned breakers in production. The tool's silence is interpreted as a green light. The whole point of an "upgrade check" command is to surface what needs attention before you ship.

Suggested fix

Extend the 3.x → 4.x checks block in runUpgradeCheck() to scan for each of the 8 missing breakers. Most can be done with simple greps:

• Grep config/ for allowEnvironmentSwitchViaUrl=true and warn if not explicitly disabled or scoped to staging.
• Grep config/ for set(reloadPassword="") or absence of reloadPassword.
• Check for tests/specs/functions/ directory.
• Grep Makefile, package.json, *.sh, .github/workflows/* for wheels snippets (no generate).
• Grep views for viteScriptTag/viteStyleTag/vitePreloadTag and warn that the strictness default has flipped.
• Grep config/ for set(middleware=[...]) and parse for new wheels.middleware.Cors() without an allowOrigins argument.
• Grep config/ for set(middleware=[...]) with RateLimiter and no explicit trustProxy/proxyStrategy.

A textual scan won't catch every case (middleware built up across files, dynamically-constructed config) but it raises the floor significantly.

Environment

• Wheels CLI: 4.0.0-SNAPSHOT+1779

🤖 Filed by Claude Code while assisting with a 4.0 upgrade testbed

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — see .ai/wheels/cli/ for canonical patterns.

Fix sketch

Extend the 3.x -> 4.x checks block in runUpgradeCheck() at cli/lucli/Module.cfc:3591 with additional entries appended to the existing checks array. The runner already supports two checkTypes — directory and grep (with scanDir + extensions + pattern) — so most of the 8 missing breakers map onto the existing infrastructure with new arrayAppend(checks, {...}) calls: greps over config/ for allowEnvironmentSwitchViaUrl=true, missing reloadPassword, Cors() without allowOrigins, RateLimiter without trustProxy/proxyStrategy; a directory check for tests/specs/functions/; greps over Makefile, package.json, *.sh, and .github/workflows/ for the legacy wheels snippets invocation; and a grep over views for viteScriptTag|viteStyleTag|vitePreloadTag to surface the strict-manifest default flip. Some patterns (parsing middleware arrays built across files, dynamically-constructed config) are inherently best-effort, but the floor rises substantially from 3/11 to ~10/11.

Confidence: medium

The file, function, and existing check-pattern are unambiguous, but adding 8 distinct scans involves real regex-robustness and false-positive trade-offs that the issue author already calls out — not a single mechanical one-liner.

<!-- wheels-bot:triage:2628 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2645

Spec: vendor/wheels/tests/specs/cli/UpgradeCheckCoverageSpec.cfc — failing → passing (1 pass + 7 fail → 8 pass + 0 fail)
Implementation: cli/lucli/Module.cfc (extended 3.x → 4.x runUpgradeCheck() block with seven additional grep / directory checks; runner gained backward-compatible scanTargets and absent options)

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.