Wheels CLI ignores --no-sqlite argument

[teleotic]

Describe the bug
Using wheels new --no-sqlite incorrectly results in SQLite database files still being created, and SQLite datasource code being generated. This was partially addressed in issue #2621 but the behavior remains. On investigation, the --no-sqlite argument is never passed through to Wheels CLI module.

To Reproduce
Steps to reproduce the behavior:

1. Create new app with wheels new test_app --no-sqlite
2. App is erroneously created with a SQLite database

Expected behavior
The SQLite database and related code should not be generated.

Desktop (please complete the following information):

• OS: Ubuntu 26.04 LTS, Windows 11 Pro 25H2
• Version: Wheels 4.0.2 (Linux), 4.0.3-snapshot.1966 (bleeding-edge)

Additional context
After testing several variations, it appears that no command line argument beginning with --no- is passed through to the Wheels CLI module (/wheels/cli/lucli/Module.cfc). Therefore options.noSQLite is never set to true and the default behavior continues. I have not determined whether this is a Wheels issue or a limitation with the upstream LuCLI tool. (LuCLI has a --no-agents option that may be causing a parsing problem, but this is just speculation.)

A possible quick fix is renaming the command line argument. For instance --nosqlite correctly passes through.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear "what happened / what I expected / steps to reproduce" structure, and confirms it against the prior fix attempt in #2621 / #2624. From the issue:

After testing several variations, it appears that no command line argument beginning with --no- is passed through to the Wheels CLI module … --nosqlite correctly passes through.

Suspected layer

cli — see cli/lucli/Module.cfc and cli/CLAUDE.md for canonical patterns.

The wheels new handler at cli/lucli/Module.cfc:746 already parses --no-sqlite correctly (line 791-792, default options at line 776, and scaffoldNewApp consumes opts.noSQLite at lines 4554-4562, 4578, 4608). So the in-handler logic from #2624 is intact — the bug is that the --no-sqlite token never reaches getArgs(arguments) in the first place. That points upstream at the LuCLI argv layer, which appears to strip or reroute --no-* flags (the reporter speculates a conflict with LuCLI's own --no-agents flag).

Fix sketch

Two plausible shapes:

1. Rename / alias the flag in Module.cfc — add --nosqlite (already works per the reporter) as the canonical form, document both --no-sqlite and --nosqlite, and update the wheels new help text (cli/lucli/Module.cfc:759, 766). Same change pattern needed for --no-open-browser (line 793-794) if it's also affected. Quick, local, low-risk.
2. Fix the upstream LuCLI argv handling so all --no-* flags pass through to module functions. Larger blast radius — touches the LuCLI runtime that the wheels binary is built on, not just Module.cfc.

Either approach should ship with a verification step (run wheels new test_app --no-sqlite and confirm db/development.sqlite is NOT created and lucee.json has "{}" for datasources). Recommend (1) for fast resolution and filing (2) separately if confirmed as a LuCLI runtime issue.

Confidence: medium

Symptom and rough fix shape are clear, but the root cause sits at the LuCLI argv boundary (not Wheels code) and the two fix paths have meaningfully different scopes — that's a design trade-off propose-fix should weigh, not a mechanical one-liner.

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

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2856

Spec: cli/lucli/tests/specs/commands/NewCommandArgvSpec.cfc — failing → passing
Implementation: cli/lucli/Module.cfc (argsFromCollection()'s false branch now re-emits --no-<key> instead of dropping the entry); test fixture cli/lucli/tests/_fixtures/commands/ModuleArgvProbe.cfc exposes the private helper for unit testing.

The triage proposed two paths (rename/alias vs. fix the upstream argv handling). Investigation showed the conversion lives inside argsFromCollection() in cli/lucli/Module.cfc itself, not in the LuCLI runtime — so the "upstream" path turned out to be a small local change that fixes every --no-* flag at once (--no-sqlite, --no-open-browser, --no-routes, --no-test-db). That is what landed.

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.