fix(cli): hide internal completion command

[yingdi-shan]

Summary

• hide the internal aenv completion subcommand from end-user help
• remove the shell completion section from the end-user CLI guide as they will be modified by PR 115.
• keep the command callable for internal completion generation

Testing

• cargo fmt --all -- --check
• cargo test -p aenv

[github-actions]

✅ OpenCodeReview: Review complete: 0 finding(s) across 1 selected item(s).

[LSX-s-Software]

Exposing a completion-generation command is standard public CLI behavior, not an internal implementation detail. rustup completions, kubectl completion, helm completion, gh completion, podman completion, minikube completion, flux completion, etc. all expose and document such commands. Some of these tools also install completion scripts automatically, but they still retain the command for manual installation, custom paths, and current-session activation.

I don’t think exposing completion meaningfully increases users’ cognitive load. --help is a discoverability and reference surface, not a list of concepts every user must learn before using the CLI. Users who do not need shell completion can simply ignore this conventional, self-explanatory subcommand, while users who do need it must be able to find it. Hiding the command shifts that complexity onto users by making the supported manual path harder to discover.

More importantly, #115 is still a draft, has received no review, and is nowhere near ready. Until it lands, aenv completion is the only supported way for users to enable completion. Hiding it from --help and deleting its documentation makes an existing feature effectively undiscoverable. That is a user-facing regression, not cleanup in preparation for #115. The documentation should remain until automatic installation is actually delivered, and even then the manual generation command remains useful.

But since this has already been merged, I guess there is not much left for me to say.

[yingdi-shan]

Exposing a completion-generation command is standard public CLI behavior, not an internal implementation detail. rustup completions, kubectl completion, helm completion, gh completion, podman completion, minikube completion, flux completion, etc. all expose and document such commands. Some of these tools also install completion scripts automatically, but they still retain the command for manual installation, custom paths, and current-session activation.

I don’t think exposing completion meaningfully increases users’ cognitive load. --help is a discoverability and reference surface, not a list of concepts every user must learn before using the CLI. Users who do not need shell completion can simply ignore this conventional, self-explanatory subcommand, while users who do need it must be able to find it. Hiding the command shifts that complexity onto users by making the supported manual path harder to discover.

More importantly, #115 is still a draft, has received no review, and is nowhere near ready. Until it lands, aenv completion is the only supported way for users to enable completion. Hiding it from --help and deleting its documentation makes an existing feature effectively undiscoverable. That is a user-facing regression, not cleanup in preparation for #115. The documentation should remain until automatic installation is actually delivered, and even then the manual generation command remains useful.

But since this has already been merged, I guess there is not much left for me to say.

That said, I do think the completion documentation is worth keeping — the real issue is one of balance. Right now, the docs spend a lot of space on minor details like this, while saying very little about what actually matters most to users, such as how our system compares to others. We can restore it once we've reworked the docs more broadly.