docs: generalized interactivity design proposal

[jpage-godaddy]

Summary

• Generalizes the Interactive Domain Purchase Wizard proposal into a consistent pattern for interactivity across all gddy commands, triggered by missing required inputs rather than one-off wizards.
• Proposes --interactive/--non-interactive flags, defaulted by TTY detection the same way --output already is.
• Leaves library selection as an open question for discussion: inline/scrollback prompt libraries (inquire, dialoguer, promkit) vs. full-screen TUI (ratatui, cursive), with pros/cons of each and no recommendation locked in yet.

Test plan

• N/A — documentation only, no code changes
• Design discussion / feedback from reviewers on the open library-selection question

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR adds design documentation proposing a consistent, CLI-wide approach to interactive prompting (driven by missing required inputs), and includes a detailed domain purchase wizard concept as a concrete motivating example.

Changes:

• Adds a comprehensive “Interactive Domain Purchase Wizard” design doc with flow diagrams, UX mockups, and API/command mapping.
• Adds a “Generalized Interactivity Design” doc proposing --interactive / --non-interactive behavior and outlining TUI library options/tradeoffs.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

File	Description
docs/design/interactive_domain_wizard.md	Detailed wizard proposal for interactive domain registration/purchase, including API surface, flows, and agent + non-interactive mapping.
docs/design/generalized_interactivity_design.md	Generalizes interactivity entry/trigger rules across commands and discusses prompt/TUI library approaches.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[rts1-godaddy]

I like the direction here, "interactivity triggered by missing inputs" is the right model and aligns with how gh and Shopify CLI handle this.

One thing I think would strengthen this doc is explicitly distinguishing between the two cases it covers, since they have very different implementation complexity:

1. Simple auto-prompts: A command is missing a required arg → prompt for it, get the value, execute. This is what most commands would use. It could live entirely in the engine (intercept clap's "missing arg" error, prompt, re-dispatch). Command authors get it for free.
2. Multi-step flows: Commands like domain register where prompts depend on the results of earlier API calls, state accumulates across steps, and there's conditional branching (domain taken → show suggestions). These need handler-level orchestration with a state machine.

Both fit under the "interactivity triggered by missing inputs" umbrella, but the first is an engine level primitive (nearly zero work for command authors) while the second requires explicit wizard code in the handler. Calling this out would help clarify what command authors get automatically vs. what they need to build themselves.

[rts1-godaddy]

Looking at the existing commands, they are already defined in a logical sequence, but I don't see any docs around this. I am actively building a Comprehensive guide to add new commands, I will update that doc and I should be able to share that doc by tomorrow for further review.