docs: Interactive domain purchase design - #188
Conversation
| ### Command Signature | ||
|
|
||
| ``` | ||
| gddy domain register [DOMAIN] [--interactive | --non-interactive] |
There was a problem hiding this comment.
I wonder if we should have multiple entry points here. Users may start instead with gddy domain suggest --interactive and be presented with a search interface that then leads through the purchase flow.
There was a problem hiding this comment.
Good call, updated the design to support this. Any domain subcommand can hand off to the purchase wizard via --interactive:
- gddy domain suggest "cool startup" --interactive → pick from suggestions → continue to purchase
- gddy domain available example.com --interactive → if available, continue to options/purchase
- gddy domain quote example.com --interactive → jump straight to review & confirm
The command does its normal work first, then instead of exiting, it feeds the result into the wizard and continues from the appropriate step. Same state machine, different starting points.
Commands that don't naturally lead to a purchase (domain list, domain get, domain contacts init) ignore the flag.
| } | ||
| ``` | ||
|
|
||
| This preserves scriptability: `gddy domain register 2>/dev/null` gives clean JSON even when the interactive wizard ran. |
There was a problem hiding this comment.
Personally, I prefer the human output mode for interactive flows. Preserving scriptability seems moot to me if you're doing an interactive experience.
There was a problem hiding this comment.
Agreed. I will update the design to
- Interactive mode → human output by default (summary, colors, next-steps guidance on stdout)
- Non-interactive mode (--non-interactive or no TTY) → JSON envelope as usual for scripting/agent consumption
- User can still force JSON with --output json if they want structured output after an interactive session (edge case, but supported)
Proposal to support an Interactive domain purchase for cli users. This is intended for humans use only.