fix-nested-subcommand

Fix: nested subcommand help text shows wrong command path (clap bin_name not propagated)

Metadata

Statusdone
Assignedagent-1350
Agent identityf51439356729d112a6c404803d88015d5b44832c6c584c62b96732b63c2b0c7e
Created2026-05-01T15:08:50.381925414+00:00
Started2026-05-01T15:10:27.150638024+00:00
Completed2026-05-01T15:30:15.144217221+00:00
Tagsfix,cli,ux,help, eval-scheduled
Tokens1122349 in / 4888 out
Eval score0.90
└ blocking impact0.95
└ completeness0.98
└ coordination overhead0.90
└ correctness0.95
└ downstream usability0.85
└ efficiency0.92
└ intent fidelity0.94
└ style adherence0.85

Description

Description

Nested subcommands lose the parent command name in their help text. Example: wg html publish -h shows Usage: publish <COMMAND> instead of Usage: wg html publish <COMMAND>. Confusing because the help could equally apply to wg publish (a different command). Same issue across every nested subcommand: wg html publish add, wg msg send, wg endpoint add, etc.

User report 2026-05-01 after using wg html publish: 'this particular harshness is kind of annoying. Like, it's not clear. It's wg.html.publish. Like, they're kind of mixing and stuff. There's a general way to fix this, which is to just use the command line to drive the help text, so it's not confusing.'

Spec

For every #[command(name = "...")] or subcommand declaration in clap that's nested, ensure the bin_name reflects the full invocation path:

  • wg (top-level)
  • wg html (one level)
  • wg html publish (two levels)
  • wg html publish add (three levels) etc.

The way to fix in clap (depending on which version): set bin_name("wg html publish") on the subcommand definition, OR use clap's automatic propagation via subcommand_help_heading and disable_help_subcommand with proper command tree configuration.

Reference: https://docs.rs/clap/latest/clap/_derive/_tutorial/index.html — search 'bin_name' for the canonical pattern.

Validation

  • wg html publish -h shows Usage: wg html publish <COMMAND> (full path)
  • wg html publish add -h shows Usage: wg html publish add [OPTIONS] <NAME>
  • wg msg send -h shows Usage: wg msg send [OPTIONS] <TASK> <MESSAGE>
  • wg endpoint add -h shows Usage: wg endpoint add [OPTIONS] <NAME>
  • wg secret set -h shows Usage: wg secret set [OPTIONS] <NAME>
  • At least one nested-3 case checked (e.g. wg func extract -h)
  • No regression of top-level help (wg --help still works correctly)
  • cargo build + cargo test pass
  • cargo install --path . was run before claiming done

Process note

This is a small but high-leverage UX fix — every command's help text becomes self-documenting about the full invocation path. Affects every user, every help-text view, forever. Worth getting right.

Depends on

Required by

Log