[bpamiri]

Upstream issue: cybersonic#136

What

--env / --envfile never reached a module started through the module shortcut: lucli <module> … --env=x, lucli --env=x <module> …, or an aliased binary (-Dlucli.binary.name=<module>, e.g. wheels start --env=prod). Inside the module, LuCLI.getCurrentEnvironment() was null; only LUCLI_ENV and lucli --env=x modules run … worked.

Why

executeViaModulesCommand() re-executes modules run <module> … on the same root CommandLine. picocli resets the root's options on that re-parse, and only --verbose / --debug were re-injected. So LuCLIExecutionStrategy then set currentEnvironment / envFilePath from a root with no --env.

How

• The shortcut's argument list now comes from a small static moduleShortcutArgs(...).
• It puts --env=<x> / --envfile=<path> before modules, at the root position the execution strategy reads.
• --verbose / --debug stay after the module args, where the module's own parser expects them (unchanged).
• With no --env, the argument list is exactly as before.

Tests

• Unit: new ModuleShortcutArgsTest (4 cases: no flags unchanged; env + envfile at the root position; verbose/debug still after the module args; empty env not re-injected).

• Full suite: mvn test gave 773 tests, 0 failures, 0 errors, 6 skipped. I didn't run the BATS suite locally (no bats-core here); please rely on CI.

• End to end: an envprobe module printing LuCLI.getCurrentEnvironment(), isolated LUCLI_HOME / user.home.

  Invocation	v0.6.2.2	this branch
  -Dlucli.binary.name=envprobe … show --env=prod	NULL	prod
  lucli envprobe show --env=prod	NULL	prod
  lucli --env=prod envprobe show	NULL	prod
  lucli envprobe show (no --env)	NULL	NULL

Fork bookkeeping

CHANGELOG ## Unreleased entry; FORK.md "Next queue" row 9.

Upstream

The same change goes to cybersonic/LuCLI as a cherry-pick -x onto upstream main (without FORK.md) once this is reviewed.

🤖 Generated with Claude Code

[github-actions]

Integration Tests (ubuntu-latest, Java 21)

78 tests   78 ✅  1m 22s ⏱️
14 suites   0 💤
 1 files     0 ❌

Results for commit 23bb2a2.

[github-actions]

Unit Tests (ubuntu-latest, Java 21)

 62 files   62 suites   2m 24s ⏱️
768 tests 762 ✅ 6 💤 0 ❌
773 runs  767 ✅ 6 💤 0 ❌

Results for commit 23bb2a2.

[bpamiri]

rev1-r3 review @ 23bb2a2: APPROVE (final)

I built wheels @ 8942048 (base) and this branch with JDK 21 (mvn package). I ran an envprobe module that prints LuCLI.getCurrentEnvironment() and LuCLI.envFilePath, with an isolated LUCLI_HOME, -Dlucli.home and a sandboxed HOME / -Duser.home.

Invocation	base	this branch
lucli envprobe show --env=prod	NULL	prod
lucli --env=prod envprobe show	NULL	prod
-Dlucli.binary.name=envprobe … show --env=prod	NULL	prod
lucli envprobe show -e prod / -e=prod	NULL	prod
lucli envprobe show --envfile=probe.env	envfile NULL	probe.env
lucli envprobe show (no flag)	NULL	NULL
lucli --env=prod modules run envprobe show (control)	prod	prod

So the RED-before reproduces on base, and the fix covers both the short alias and --envfile.

• Code: minimal and in upstream style. moduleShortcutArgs is a pure static, so it's unit-testable. --env / --envfile sit at the root position, --verbose / --debug stay after the module args as before, and an empty or null env isn't re-injected. A relative --envfile stays relative, which is fine because the re-execution keeps the same cwd. Re-executing with --envfile loads the file at the root again, which is idempotent.
• Tests: ModuleShortcutArgsTest passes 4/0/0 locally. It can't be RED on base, since the method doesn't exist there; the end-to-end table above is the behavioural RED.
• PR CI: green on every job (Build ×3, Unit ×3, Integration ×2); the APT smoke check was skipped.
• The CHANGELOG ## Unreleased entry and FORK.md row 9 are fine. Ready for the upstream cherry-pick -x, without FORK.md.