Show help for a bare ts dev proxy invocation #1063

Running ts dev proxy with no arguments does not print help. It runs part of proxy startup, then fails with a debug-formatted error-stack report that exposes internal source locations.

Reproducing

On macOS (ts dev proxy is macOS-only):

$ cargo run -q -p trusted-server-cli --target aarch64-apple-darwin -- dev proxy
sudo: a password is required
warning: Safari: could not auto-restore the system proxy for 'Wi-Fi' (needs admin). ...
[ts] invalid rule configuration
├╴at crates/trusted-server-cli/src/commands/dev/proxy/mod.rs:256:41
│
╰─▶ no rewrite rule: pass --map FROM=TO (or -f/--from with -t/--to)
    ╰╴at crates/trusted-server-cli/src/commands/dev/proxy/config.rs:269:20

Two problems, and the second is not in the original report:

1. Internal paths leak. dev/mod.rs:50 renders the report with format!("{report:?}"), so every user-facing proxy failure prints error-stack debug output with file/line attachments. The underlying message ("no rewrite rule: pass --map FROM=TO") is already good; only the framing is wrong.

2. Side effects run before the error. run calls browser::restore_system_proxy_if_pending at mod.rs:254 before config::resolve at mod.rs:256. So a bare invocation touches system proxy state and attempts sudo before discovering it has no rule to serve. A user who typed ts dev proxy to see what it does gets a sudo prompt.

Suggested approach

Set arg_required_else_help = true on ProxyArgs (proxy/mod.rs:81) so Clap prints help and exits before run is ever called. That fixes both problems at once, since nothing in run executes.

Watch the interaction with the nested subcommand: ProxyArgs carries command: Option<ProxySub> (mod.rs:150), which is how ts dev proxy ca install is reached. ts dev proxy ca … takes no rewrite rules and must keep working. Verify this by hand, not just by reading — the flag's behavior with an optional subcommand plus all-optional args is worth confirming empirically. If arg_required_else_help turns out to break the ca path, fall back to an explicit check at the top of run that prints help for the no-args, no-subcommand case.

Separately, consider whether dev/mod.rs:50 should render {report} rather than {report:?} for user-facing output. That is a slightly wider change — it affects every ts dev proxy error, not just this one — so it is acceptable to leave out and file separately if it grows.

Acceptance criteria

• A bare ts dev proxy prints Clap help and exits without touching system proxy state, attempting sudo, or printing error-stack debug output.
• ts dev proxy ca path, ca install, ca uninstall, and ca regenerate still work.
• An incomplete-but-explicit invocation (for example ts dev proxy --from a.example.com with no --to) still produces the concise no-rule error, not help text.
• A regression test covers the bare invocation. no_rule_passed_is_a_no_rule_error in proxy/config.rs:669 is the neighboring test; a Clap-level test likely belongs with the other Args::try_parse_from tests in run.rs.
• cargo clippy and the CLI test suite pass.

Getting set up

ts dev proxy is macOS-only: its dependencies are cfg-scoped in Cargo.toml and the Proxy subcommand does not exist on other hosts. The workspace default target is wasm32-wasip1, so the CLI needs an explicit host target:

cargo run -p trusted-server-cli --target aarch64-apple-darwin -- dev proxy
./scripts/test-cli.sh

Pointers

• crates/trusted-server-cli/src/commands/dev/proxy/mod.rs:81 — ProxyArgs
• crates/trusted-server-cli/src/commands/dev/proxy/mod.rs:150 — the optional ca subcommand field
• crates/trusted-server-cli/src/commands/dev/proxy/mod.rs:184 — run, including the ca early return and the ordering problem
• crates/trusted-server-cli/src/commands/dev/proxy/config.rs:266 — resolve and ConfigError::NoRule
• crates/trusted-server-cli/src/commands/dev/mod.rs:50 — the {report:?} rendering