Repository navigation
Conversation
LuCLI's module router dispatches a no-args `wheels` invocation to a `main()` function on the module. `cli/lucli/Module.cfc` only defined `showHelp()`, so picocli surfaced Component [modules.wheels.Module] has no function with name [main] every time a user typed `wheels` with no subcommand. Add `main()` as a thin delegate to `showHelp()` (and hide it from `mcpHiddenTools()` so it doesn't leak as an MCP tool — it's a CLI-only no-args dispatch target). Fixes #2840 Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
![wheels-bot[bot]](https://avatars.githubusercontent.com/in/3657588?s=60&v=4){kind=small}
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: This is a minimal, correct fix for issue #2840 — adding a main() delegation shim so bare wheels invocations print the help banner instead of throwing a picocli missing-method exception. The implementation is clean, the test strategy (source-level scan) is the right call given the LuCLI runtime constraint, and the commit is well-formed. I have three minor nits, none of which warrant blocking the merge.
Correctness
The core change is 2 lines: add public string function main() { return showHelp(); } and insert "main" into mcpHiddenTools(). Both are necessary and sufficient. The fix does exactly what the PR title claims. No edge cases are missing — the no-args dispatch path is fully covered, MCP exposure is suppressed, and the help regression path (wheels help / wheels --help) is unaffected because those still route through showHelp() directly.
Conventions
Nit 1 — Issue reference in inline source comment.
cli/lucli/Module.cfc, line 189:
// (#2840). Delegate to showHelp() so the no-args entry point is friendly.CLAUDE.md says: "Don't reference the current task, fix, or callers... since those belong in the PR description and rot as the codebase evolves." The (#2840) reference is redundant — the commit message already says Fixes #2840, the PR description repeats it, and the CHANGELOG entry includes it. Strip the issue reference from the inline comment; the surrounding sentences already explain the non-obvious WHY.
Suggested replacement:
// LuCLI dispatches a bare `wheels` invocation (no subcommand) to a
// `main()` function on the module. Without it, picocli surfaces:
// Component [modules.wheels.Module] has no function with name [main]
// Delegate to showHelp() so the no-args entry point lands on something useful.Nit 2 — Misleading hint: text.
cli/lucli/Module.cfc, line 191:
/**
* hint: Default entry point — shown when `wheels` is run with no arguments
*/The phrase "shown when wheels is run with no arguments" implies the hint text itself is what's displayed. It's actually the showHelp() output that's displayed — the hint text only surfaces in LuCLI's auto-discovery listing, and main is explicitly suppressed from that via mcpHiddenTools(). Consider: hint: No-args dispatch target — delegates to showHelp() which describes the mechanism accurately without implying the hint is user-visible.
Nit 3 — CHANGELOG section ordering.
CHANGELOG.md, lines 23–25:
### Fixed
...
### AddedKeep a Changelog's canonical section order is Added → Changed → Deprecated → Removed → Fixed → Security. This PR inserts ### Fixed above ### Added. The fix should appear after ### Added (or after ### Changed / ### Removed if present). Minor, but consistent ordering helps readers skim the changelog.
Tests
The source-level scan approach (fileRead + reFindNoCase / toMatch) is the correct choice here — Module extends modules.BaseModule which only resolves at LuCLI runtime, and the existing specs (UpgradeCommandSpec, ReloadCommandSpec, ConsoleCommandSpec) all use the same pattern. The three test cases cover the right surface:
main()is declared as a public functionmain()delegates toshowHelp()mainis present inmcpHiddenTools()
One observation: the 800-character window in the third test (var body = mid(variables.moduleSource, idx, 800)) is sufficient for the current mcpHiddenTools() array (≈350 chars), but would silently miss "main" if the array ever grows past ~800 chars before the "main" entry. Since "main" is the first entry in the array (line 112), this is not a practical risk — the entry is only ~8 chars into the function body. Fine to leave as-is.
The toMatch("public\s+(string|any)\s+function\s+main\s*\(") pattern is intentionally permissive about the return type; that's reasonable for a delegation shim.
Commits
fix(cli): handle bare `wheels` invocation by delegating to showHelp()
Type fix, scope cli, subject under 100 chars, sentence-case, not ALL-CAPS. Commit body explains the why ("LuCLI's module router dispatches..."). DCO Signed-off-by: claude[bot] trailer present. Passes commitlint.config.js.
…cation section Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Wheels Bot — Docs updatedAdded a doc commit to this PR:
|
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: This is a follow-up docs commit (20e93bc) that adds one sentence to the installation verification section, responding to the previous review's request for user-facing documentation. The sentence is useful but contains a misleading version claim. The three nits from the previous review (issue reference in inline comment, misleading hint text, CHANGELOG section ordering) remain unaddressed. Overall verdict: comment — no blockers, nothing that warrants blocking merge, but the version claim should be corrected before the docs go live.
Docs
Finding 1 — "pre-4.0.x build" is the wrong version bracket.
web/sites/guides/src/content/docs/v4-0-0/command-line-tools/installation.mdx, line 216 (new):
If you see a `Component [modules.wheels.Module] has no function with name [main]` error instead, you are running a pre-4.0.x build; upgrade to restore the expected behavior.This fix is being introduced within the 4.0.x series (CHANGELOG [Unreleased], docs path v4-0-0). Users on any 4.0.x release that predates this patch would also see the error — calling them "pre-4.0.x" is incorrect and will confuse someone who just installed 4.0.0. Suggested replacement:
If you see a `Component [modules.wheels.Module] has no function with name [main]` error instead, you are running a build that predates this fix — upgrade to the latest 4.0.x release to restore the expected behavior.Carry-over nits (from previous review, still unaddressed)
These were flagged at SHA 63e3cbab2 and are unchanged. Repeating them briefly so they don't fall through:
Nit A — Issue reference in inline comment (cli/lucli/Module.cfc, line ~186):
// (#2840). Delegate to showHelp() so the no-args entry point is friendly.CLAUDE.md: "Don't reference the current task, fix, or callers... since those belong in the PR description and rot as the codebase evolves." The (#2840) reference should be stripped; the surrounding sentences already carry the why.
Nit B — Misleading JSDoc hint (cli/lucli/Module.cfc, line ~190):
/**
* hint: Default entry point — shown when `wheels` is run with no arguments"shown when wheels is run with no arguments" implies the hint text itself is the user-visible output. It isn't — showHelp() is. The hint only surfaces in LuCLI's auto-discovery listing, which main is explicitly suppressed from via mcpHiddenTools(). Suggested: hint: No-args dispatch target — delegates to showHelp().
Nit C — CHANGELOG section ordering (CHANGELOG.md, lines 23–25):
### Fixed appears above ### Added. Keep a Changelog's canonical order is Added → Changed → Deprecated → Removed → Fixed → Security. The ### Fixed block should move below ### Added.
Commits
Both commits are well-formed:
fix(cli): handle bare \wheels` invocation by delegating to showHelp()— typefix, scopecli, ≤ 100 chars, DCOSigned-off-by` present.docs(web/guides): note bare \wheels` invocation prints help in verification section— typedocs, scopeweb/guides, ≤ 100 chars, DCOSigned-off-by` present.
Both pass commitlint.config.js.
Wheels Bot — Reviewer B (round 1)A's critique of the initial Module.cfc commit is well-reasoned: all three nits are grounded in the actual diff, the test analysis is accurate, and the commit validation checks out. However, A's review was submitted against an older SHA ( SycophancyNone detected. A's LGTM is backed by line-level reasoning about the 2-line change and a clear explanation of why the source-level scan test pattern is the right approach given the LuCLI runtime constraint. False positivesNone detected. Verified each nit against the diff:
Missed issuesDocs commit inaccuracy — new commit added after A's review (
"Pre-4.0.x" is wrong in both directions:
Suggested correction: "you are running a 4.x build that predates this fix; upgrade your Verdict alignmentA's COMMENTED verdict (non-blocking, three minor nits) is consistent with a 2-line mechanical fix backed by solid tests and only style-level findings. No misalignment on the scope A reviewed. ConvergenceNot aligned. A's review did not cover the docs commit because it was added after A's SHA. That commit contains user-facing language that is factually incorrect and would mislead users on 4.x. A should acknowledge the docs inaccuracy — either request a correction or explain why "pre-4.0.x build" is intentional — before we converge. |
There was a problem hiding this comment.
Wheels Bot — Reviewer A response (round 1)
B's round 1 critique is largely consistent with my updated review on the current SHA. Both A and B independently flagged the same docs inaccuracy ("pre-4.0.x build"), and B's false-positive/sycophancy checks all came back clean. The only substantive difference is timing: my second review on 20e93bc9 landed 27 seconds before B's comment, so B was likely mid-run when it posted. We are effectively converged on all findings.
Conceded points
None. B raised one new finding (docs version claim) that I had already surfaced in my updated review on 20e93bc95b06b1f08442081e58ca536d6a0b6ad1:
Finding 1 — "pre-4.0.x build" is the wrong version bracket. ... Suggested replacement: "If you see a
Component [modules.wheels.Module] has no function with name [main]error instead, you are running a build that predates this fix — upgrade to the latest 4.0.x release to restore the expected behavior."
B's suggested wording ("a 4.x build that predates this fix") and my suggested wording ("a build that predates this fix") are functionally identical. The diagnosis is the same: the fix lives within the 4.0.x series and users who see the error are on a 4.x release, not a pre-4.x one.
Defended points
-
Docs inaccuracy already flagged: My second review (
PRR_kwDOABMUH88AAAABBwoGYQ, submitted2026-06-02T19:40:53Z) covered20e93bc9and explicitly called out the "pre-4.0.x" version bracket as wrong. B's comment arrived at19:41:20Z— the workflow had already launched before my review landed. No gap remains: both reviewers agree the sentence needs correcting. -
Three carry-over nits still stand: B confirmed all three of A's original nits (issue reference in inline comment, misleading hint text, CHANGELOG section ordering) are true positives. None have been addressed yet. They are minor and non-blocking but should be cleaned up before merge.
-
Verdict: COMMENT remains the right state. The docs fix is the only item that rises to "should not go live as written"; the three nits are style-level. Nothing here is a correctness or cross-engine bug.
Updated verdict
Still comment — same as initial. The docs sentence needs a one-word correction ("pre-4.0.x" → "that predates this fix") and the three carry-over nits (issue ref in inline comment, hint text, CHANGELOG order) are worth a follow-up commit, but none of these block the core fix from being merged.
Wheels Bot — Reviewer B (round 2)A's review of the docs commit independently surfaces the same docs inaccuracy B flagged in round 1, and correctly carries forward the three unaddressed nits from the earlier review. All four findings check out against the diff. The COMMENT verdict (non-blocking, fix before docs go live) is appropriate. We are now aligned. SycophancyNone detected. A does not approve unconditionally — the review explicitly calls for a doc correction and repeats three open nits. The COMMENT verdict is earned by the evidence. False positivesNone detected. Verified each finding against the diff:
Missed issuesNone detected. The test spec's file-level docblock also contains Verdict alignmentCOMMENT with four concrete, actionable findings is consistent with A's stated "no blockers, nothing that warrants blocking merge." Verdict matches severity. ConvergenceAligned. A's review independently identified the docs inaccuracy B raised in round 1, and confirmed all three carry-over nits remain unaddressed. Joint recommendation: apply the four corrections (doc version claim, inline comment issue ref, JSDoc hint text, CHANGELOG section ordering) before merge. |
- cli/lucli/Module.cfc: strip `(#2840)` issue reference from inline comment on `main()` (CLAUDE.md: don't reference current task/fix in comments — belongs in PR description). - cli/lucli/Module.cfc: rewrite misleading `hint:` text on `main()`. The previous "shown when `wheels` is run with no arguments" implied the hint text itself was user-visible — it isn't (`showHelp()` output is, and `main` is suppressed from MCP listing via `mcpHiddenTools()`). New hint describes the dispatch mechanism. - CHANGELOG.md: move `### Fixed` below `### Added` and `### Changed` under `[Unreleased]` to follow Keep a Changelog's canonical section order (Added → Changed → Deprecated → Removed → Fixed → Security). - web/sites/guides/.../installation.mdx: correct "pre-4.0.x build" diagnosis to "a build that predates this fix — upgrade to the latest 4.0.x release". The LuCLI-based `wheels` CLI did not exist before 4.0, so users seeing this error are on a 4.x release that predates the patch, not a pre-4.x build. Signed-off-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Wheels Bot — Address Review (round 1)Applied consensus findings from Reviewer A and Reviewer B's convergence (round 2):
Test verificationThe CLI test runner ( The new commit will trigger a fresh Reviewer A run on the updated SHA. Convergence loop continues until reviewers align on `approve` or the outer-loop cap (5 rounds) is reached. |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: The new commit (932a6a8e6) closes out every finding raised across both previous reviews. All four items — the inline issue reference, the misleading JSDoc hint, the CHANGELOG section ordering, and the docs version-bracket inaccuracy — are now correctly addressed. The core fix has been correct from the start; the PR is clean end-to-end. No remaining findings. A human maintainer may approve.
Carry-over findings — all resolved
Nit A — Issue reference stripped from inline comment (cli/lucli/Module.cfc, line 189)
Previous form:
// (#2840). Delegate to showHelp() so the no-args entry point is friendly.Current form:
// Delegate to showHelp() so the no-args entry point lands on something useful.The (#2840) reference is gone. Aligns with CLAUDE.md: "Don't reference the current task, fix, or callers — those belong in the PR description." ✓
Nit B — JSDoc hint corrected (cli/lucli/Module.cfc, line 191)
Previous form: hint: Default entry point — shown when 'wheels' is run with no arguments
Current form: hint: No-args dispatch target — delegates to showHelp()
The new text accurately describes the dispatch mechanism and does not imply the hint text is user-visible output. ✓
Nit C — CHANGELOG section ordering fixed (CHANGELOG.md, lines 23–31)
Current order under [Unreleased]: ### Added (line 23) → ### Changed (line 27) → ### Fixed (line 31). Matches Keep a Changelog's canonical order. ✓
Finding 1 — Docs version claim corrected (web/sites/guides/src/content/docs/v4-0-0/command-line-tools/installation.mdx, line 216)
Previous: "you are running a pre-4.0.x build; upgrade to restore the expected behavior."
Current: "you are running a build that predates this fix — upgrade to the latest 4.0.x release to restore the expected behavior."
Accurate: the LuCLI-based CLI did not exist before 4.0, so anyone seeing the error is on a 4.x release that predates this patch. ✓
Commits
Three commits, all well-formed:
| SHA | Message | Result |
|---|---|---|
63e3cbab |
fix(cli): handle bare \wheels` invocation by delegating to showHelp()` |
Pass |
20e93bc9 |
docs(web/guides): note bare \wheels` invocation prints help in verification section` |
Pass |
932a6a8e |
fix(cli): address Reviewer A/B consensus findings (round 1) |
Pass |
All three: type from allowlist, scope non-empty, subject ≤ 100 chars, not ALL-CAPS, DCO Signed-off-by: claude[bot] trailer present.
No new concerns introduced in 932a6a8e6. The diff is four focused one-liner changes (strip issue ref, reword hint, reorder CHANGELOG block, fix docs sentence) with no functional side-effects. The bot cannot self-approve, but from a correctness standpoint this is ready.
Wheels Bot — Reviewer B (round 1)A's review of the consensus-fix commit ( SycophancyNone detected. A's "human maintainer may approve" conclusion is earned by line-level verification of each of the four previous findings, not handed out unconditionally. False positivesNone detected. Verified each resolution claim against the files at
Missed issuesNone detected. The round-1 fixup is four focused one-liner changes (strip issue ref, reword hint, reorder CHANGELOG block, fix docs sentence) with no functional side-effects. No cross-engine concerns (CLI-only code). Commits are well-formed conventional commits with DCO trailers. The test spec's file-level docblock retaining Verdict alignmentA's COMMENTED verdict (not APPROVED) is correct — the bot cannot self-approve, and COMMENTED correctly signals "human may approve" without exceeding that boundary. ConvergenceAligned. All four consensus findings are addressed and verified. Joint recommendation: a human maintainer approves and merges. |
The bot's MainCommandSpec scanned raw Module.cfc with a fixed 400-char window, so a commented-out main() could false-green it (the PR #2595 / CLAUDE.md anti-pattern #14 class of bug). Strengthen the scan: - strip line and block comments before matching, so commented-out declarations no longer satisfy the assertions (negative-control tested) - scope the showHelp() delegate check to main()'s body (declaration through its first closing brace) rather than a fixed-width window - assert showHelp() actually emits the "Wheels CLI " banner, so a stubbed delegate target cannot pass - guard Left(str, 0), which crashes Lucee 7 (cross-engine invariant #8) Verified: regex logic against the real Module.cfc incl. a negative control, and bare `wheels` printing the help banner end-to-end via the LuCLI launcher with the worktree module mounted. Signed-off-by: Peter Amiri <peter@alurium.com>
Maintainer follow-up — hardened the #2840 regression specPicked up the converged bot PR and strengthened the test. The fix itself (
Verified: regex logic against the real Why no behavioral test in |
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: The latest commit (17053b137) is a focused test-hardening pass on MainCommandSpec.cfc: it adds comment stripping before source scans (closing the CLAUDE.md anti-pattern #14 gap), scopes the delegate-body check to the actual function boundary instead of a fixed window, adds a third assertion that showHelp() produces a real banner string, and guards Left(str, 0) for Lucee 7. No functional code was touched. All findings from previous review rounds remain resolved. No new concerns. Verdict: comment — the diff is clean and the PR is ready for human approval; the bot cannot self-approve.
Tests
The hardening in 17053b137 is well-judged across four dimensions:
1. Comment stripping ($stripComments)
Block-comment regex uses [\s\S]*? (lazy, multiline-safe, no (?s) dotall flag needed — correct for all engines). Line-comment regex uses (?m)^[ \t]*// anchored at line-start, which strips standalone comment lines while leaving mid-line URL paths (like the guides.wheels.dev URL in the banner) intact. (?m) is an inline Java-regex flag honoured by Lucee, Adobe CF, and BoxLang identically. This is the right scalpel for this job.
2. Function-body scoping (test 2)
Old approach: fixed 400-char window from the match point. New approach: finds the first } after the function declaration, with the Lucee 7 Left(str, 0) guard correctly applied (cross-engine invariant #8). The 200-char window is more than adequate — the actual main() body is ~45 chars. The assertion relaxed from "showHelp()" to "showHelp" — fine; the parentheses added no real false-positive protection.
3. New banner assertion (test 3)
expect(reFindNoCase("public\s+string\s+function\s+showHelp\s*\(", variables.source)).toBeGT(0);
expect(variables.source).toInclude("Wheels CLI ");Guards against a scenario where main() delegates to a stub showHelp() that returns "". Sensible belt-and-suspenders addition.
4. variables.source threaded through all four tests
All scan assertions now operate on the comment-stripped source. The raw source is still available as variables.rawSource (unused in tests, but preserved for diagnostics). Clean refactor.
Cross-engine
(?m)inline flag inreReplace(): Java regex, supported identically across Lucee 5/6/7, Adobe CF 2018-2025, and BoxLang. ✓[\s\S]*?for cross-line block-comment matching: no dotall flag needed, cross-engine safe. ✓Left(str, 0)Lucee 7 guard present at the one site that could reach zero. ✓private function $stripCommentsin a test CFC: the$-prefix/private convention caveat in CLAUDE.md applies only tovendor/wheels/mixin integration; in a TestBox spec it is correct and appropriate. ✓
Commits
| SHA | Message | Result |
|---|---|---|
63e3cbab |
fix(cli): handle bare wheels invocation by delegating to showHelp() |
Pass |
20e93bc9 |
docs(web/guides): note bare wheels invocation prints help in verification section |
Pass |
932a6a8e |
fix(cli): address Reviewer A/B consensus findings (round 1) |
Pass |
17053b137 |
test(cli): harden #2840 main() regression spec to be comment-aware |
Pass |
All four: type from allowlist, scope non-empty, subject ≤ 100 chars, not ALL-CAPS. 17053b137 is authored by Peter Amiri with Signed-off-by: Peter Amiri <peter@alurium.com> — the DCO trailer matches the commit author identity. ✓
No new findings. The PR is clean end-to-end.
Wheels Bot — Reviewer B (round 1)A's review of the SycophancyNone detected. A's "no new concerns" conclusion is earned: each claim traces back to an actual diff line (regex patterns, Lucee 7 guard, False positivesNone detected. Verified each of A's assertions against the diff:
Missed issuesNone detected. The change is a test-only, CLI-only hardening pass with no functional side-effects. No cross-engine concerns (test CFC, no Verdict alignmentCOMMENTED is the correct state — the bot cannot approve its own work; this is how "human may approve" is expressed. Consistent with A's finding of zero new concerns. ConvergenceAligned. A independently verified all four prior-round consensus findings as resolved, confirmed no new concerns in the hardening commit, and correctly deferred final approval to a human maintainer. Joint recommendation: human approval and merge. |
The previous revision stripped comments with a global non-greedy reReplace over the ~6k-line Module.cfc before scanning. That match hung the Lucee 7 CLI test suite (5-minute timeout, HTTP 000000) while passing on the Lucee that LuCLI 0.3.7 bundles — a classic engine-dependent catastrophic backtrack. Same comment-robustness, no whole-file scan: match declarations with (?m)^[ \t]*public ... function main, which a commented-out `// public ... main()` or a ` * ...` docblock line cannot satisfy. The check is now a cheap first-match reFind with no backtracking-prone construct. Logic re-verified against the real Module.cfc incl. //-comment and docblock negative controls. Signed-off-by: Peter Amiri <peter@alurium.com>
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: The fifth and final commit (c06c5065d) is a focused, well-motivated refactor of MainCommandSpec.cfc: it swaps the whole-file comment-stripping approach (which caused catastrophic backtracking on Lucee 7) for line-anchored regex patterns. The approach change is correct, well-documented, and adds no regression risk. All prior findings are resolved. Verdict: comment — no blockers; the PR is clean and ready for a human maintainer to approve.
Correctness
The line-anchoring approach is sound. Every pattern changes from an unanchored scan like:
reFindNoCase("public\s+(string|any)\s+function\s+main\s*\(", source)to a line-start-anchored scan:
reFindNoCase("(?m)^[ \t]*public\s+(string|any)\s+function\s+main\s*\(", source)The (?m)^[ \t]* prefix means the match can only begin at the start of a line after optional tabs/spaces. A commented-out // public string function main() cannot satisfy it (the line starts with //). A JSDoc line * public string function main() cannot satisfy it (the line starts with *, not whitespace). The docblock in the spec correctly enumerates both negative controls and states they were verified against the real Module.cfc. ✓
Test 2's startIdx now points to the start of the public string function main() { line (including leading whitespace). mid(source, startIdx, 200) therefore captures the full single-delegation body; find("}", rest) always hits the closing brace of main() (no inner braces in a one-liner), and left(rest, braceAt) preserves the showHelp call. ✓
Cross-engine
(?m)inline flag inreFindNoCase(): Java MULTILINE mode; supported identically on Lucee 5/6/7, Adobe CF 2018/2021/2023/2025, and BoxLang. ✓[ \t]in a character class: passed through as the two-character regex literal in CFML strings (CFML does not process backslash escapes); Java regex interprets\tas the tab character inside[]. ✓- No
[\s\S]*?over large source: the catastrophic-backtrack root cause (the$stripCommentshelper in17053b137) is fully removed. ✓ - No
Left(str, 0)risk: test 2 retains thebraceAt > 0 ?guard from the prior revision (cross-engine invariant 8). ✓
Tests
All four test cases remain intact with the same logical coverage:
main()is declared as a public function (line-anchored, comment-resistant) ✓main()delegates toshowHelp()(body scan scoped to function boundary) ✓showHelp()is a real implementation, not a stub (checks declaration and banner literal) ✓"main"is inmcpHiddenTools()(800-char window from function start;"main"is the first array entry, so the window is adequate) ✓
The removal of variables.rawSource and the now-unnecessary $stripComments helper simplifies the spec by 44 lines with no coverage loss.
Commits
Five commits, all well-formed:
| SHA | Message | Result |
|---|---|---|
63e3cbab |
fix(cli): handle bare wheels invocation by delegating to showHelp() |
Pass |
20e93bc9 |
docs(web/guides): note bare wheels invocation prints help in verification section |
Pass |
932a6a8e |
fix(cli): address Reviewer A/B consensus findings (round 1) |
Pass |
17053b13 |
test(cli): harden #2840 main() regression spec to be comment-aware |
Pass |
c06c5065 |
test(cli): line-anchor the #2840 spec instead of stripping comments |
Pass |
All five: type from allowlist, scope non-empty, subject ≤ 100 chars, not ALL-CAPS. DCO Signed-off-by trailers present and match commit author identities. ✓
No new concerns introduced in c06c5065d. The diff is 25 insertions / 44 deletions of test infrastructure, net simpler, with equivalent correctness guarantees and better runtime behavior on Lucee 7.
Wheels Bot — Reviewer B (round 1)A's review of the SycophancyNone detected. A's "no new concerns" conclusion is backed by line-level evidence for each regex pattern, the cross-engine flag analysis, the Lucee 7 backtracking root-cause, and the commit metadata table. No unconditional LGTM. False positivesNone detected. Verified each claim:
Missed issuesNone detected. The Verdict alignmentCOMMENTED is correct — the bot cannot self-approve; this is how "human may approve" is expressed. Consistent with A's finding of zero new concerns. ConvergenceAligned. A independently confirmed all prior consensus findings remain resolved and found no new concerns in the test-refactor commit. Joint recommendation: a human maintainer approves and merges. |
…rguments-results-in-er
There was a problem hiding this comment.
Wheels Bot — Reviewer A
TL;DR: The only change since the last review (SHA c06c5065d) is a develop-merge commit (d5091882b) that incorporated upstream develop changes into the fix branch before final merge — no modifications to the fix, the test spec, or the docs. The PR has since been merged. All findings from previous review rounds remain resolved; no new concerns introduced. This review is a completeness pass only.
What changed at d509188
git show --stat d5091882b confirms this is a merge commit (Merge: c06c5065d f4ed63759) authored by Peter Amiri that pulled develop into the branch. The files it touches (.ai/, .github/workflows/, CHANGELOG.md, CLI templates, test infrastructure) are all from other PRs landing on develop — not from this fix. The PR diff (gh pr diff 2842) is unchanged from what was reviewed at c06c5065d:
cli/lucli/Module.cfc:main()delegation shim +mcpHiddenTools()entry — clean.cli/lucli/tests/specs/commands/MainCommandSpec.cfc: line-anchored source-scan spec — clean.CHANGELOG.md: entry under[Unreleased] → Fixed— clean.web/sites/guides/src/content/docs/v4-0-0/command-line-tools/installation.mdx: docs sentence with accurate version language — clean.
No findings. The PR is merged.
Wheels Bot — Reviewer B (round 1)A's completeness pass on the merge commit ( SycophancyNone detected. A explicitly identifies this as a completeness pass triggered by the develop-merge commit, explains the merge parents, and confirms the substantive diff is unchanged — not a blanket LGTM. False positivesNone detected. A's claim that the four files in the PR diff ( Missed issuesNone detected. The PR is already merged; the review is post-merge housekeeping only. All four prior-round consensus findings (docs version bracket, inline issue-ref comment, JSDoc hint text, CHANGELOG section ordering) were resolved in the Verdict alignmentCOMMENTED is correct — the bot cannot self-approve, and there is nothing substantive to flag on a pure merge commit. Consistent with A's "no findings" body. ConvergenceAligned. The fix, its test spec, the docs correction, and the CHANGELOG entry all landed cleanly. A's post-merge completeness pass confirms no regression from the develop merge. Joint recommendation: no action needed; PR is merged and all prior findings are resolved. |
Summary
Running
wheelswith no subcommand currently errors out withComponent [modules.wheels.Module] has no function with name [main]. LuCLI's module router dispatches a no-args invocation to amain()function on the module, butcli/lucli/Module.cfconly definedshowHelp(). This PR addsmain()as a thin delegate toshowHelp()so a barewheelsinvocation prints the help banner instead of crashing.The change is mechanical: define
public string function main() { return showHelp(); }and add"main"tomcpHiddenTools()so it doesn't surface as an MCP tool (it's a CLI-only no-args dispatch target).Related Issue
Fixes #2840
Type of Change
Feature Completeness Checklist
claude[bot]cli/lucli/tests/specs/commands/MainCommandSpec.cfccovers the failing-then-passing cycle: declaresmain(), delegates toshowHelp(), and is hidden from MCP tools/list. Source-level scan (no Module instantiation), matching the pattern inUpgradeCommandSpec/ReloadCommandSpecsince Module extendsmodules.BaseModule, which only resolves at LuCLI runtime.bot-update-docs.ymlbot-update-docs.ymlbot-update-docs.yml[Unreleased]→Fixed/wheels/cli/tests?format=json: withoutmain()the new bundle reportstotalPass:0 totalFail:3; withmain()it reportstotalPass:3 totalFail:0. The pre-existing 417 status comes from unrelatedwheels doctorchecks, not from this change.Test Plan
wheels(no args) — should print the same help banner thatwheels helpandwheels --helpproduce, not the picocli "no function with name [main]" error.wheels --helpandwheels help— should keep printing help (regression check; both still route through the wrapper /showHelp()).wheels mcp wheelsstdio surface) —mainshould NOT appear as a tool (hidden viamcpHiddenTools()).