COR-1576: Improve CLI wrapper/help UX (wrapper --version passthrough, gate progress)

[juangaitanv]

Summary

Fixes the CLI UX inconsistencies surfaced during corgea 1.9.1 smoke testing against devex-testing-grounds. Linear: COR-1576.

Issue	Decision	Change
1 — wrapper --version intercepted	Pass through to the package manager	#[command(disable_version_flag = true)] on the shared InstallWrapArgs struct. corgea npm/pip/uv/yarn/pnpm --version (and -V) now forward to the underlying tool instead of printing corgea-npm 1.9.1. corgea --version still reports the Corgea version; wrapper -h/--help unchanged.
2 — nested help	Already works on main (regressed only in ≤1.8.7)	Regression test only — both corgea help deps scan and corgea deps help scan exit 0 with byte-identical output. No behavior change.
3 — sparse Install Gate progress	Add stderr progress, keep stdout JSON-clean	Two eprintln! resolution lines before the resolve thread::scope; removed VERDICT_PROGRESS_THRESHOLD and gate the checking N packages… line on !jobs.is_empty() so small/early sets narrate too. Under --json, stdout stays exactly one schema_version: 1 document. Empty pass stays silent.

Why

During release smoke testing, corgea npm --version reported the wrapper version instead of npm's (non-install wrapper commands otherwise delegate), and short Install Gate runs printed nothing on stdout/stderr for 25s+ — indistinguishable from a hang — because the only progress line was gated to trees larger than 8 packages.

Changes

Production (3 files):

• src/main.rs — disable_version_flag on InstallWrapArgs.
• src/precheck/mod.rs — stderr resolution-progress lines (resolving named package targets…, resolving the would-install dependency tree…).
• src/precheck/verdict.rs — removed the > 8 threshold; pluralized + always-on verdict progress for non-empty sets.

Tests (3 files): tests/cli_install.rs, tests/cli_verdict.rs, tests/cli_deps.rs — regression coverage for all three issues.

Verification

• cargo test: 441 passed / 0 failed / 13 ignored (network-gated); 4 new regression tests green.
• cargo clippy --all-targets -- -D warnings and cargo fmt --check: clean.
• Guard proofs: reverting each production file makes its regression test fail, confirming the tests catch the prior behavior.
• Behavior confirmed against built binary: corgea npm --version → real npm, corgea --version → corgea 1.9.1 preserved.

Notes (non-blocking)

• Automated --version forwarding test covers npm+pip; uv/yarn/pnpm verified manually against real binaries.
• resolving named package targets… prints even when all targets are git/URL/path specs (no registry call) — cosmetic, left out of scope.

[cursor]

No meaningful production-blocking findings.

Verified the PR diff against main and inspected the affected wrapper parsing (src/main.rs), install-gate progress paths (src/precheck/mod.rs, src/precheck/verdict.rs), and the added regression coverage. I also ran the focused tests with the lockfile on Rust stable:

• cargo +stable test --locked wrapper_version_flag_forwards_to_manager
• cargo +stable test --locked small_set_emits_resolve_and_verdict_progress_on_stderr
• cargo +stable test --locked small_set_progress_keeps_json_stdout_clean
• cargo +stable test --locked cli_deps_nested_help_forms_both_work

All passed. I did not find an actionable reason to block merge.

  

_{Sent by Cursor Automation: pr-flow}