What to build
Lithos needs a broader and more coherent terminal UI than it has today.
Right now the interactive experience is uneven: deploy and undo already have richer preview and confirmation flows, but commands like outputs, import, and destroy still mostly behave like direct flag-only commands with little or no navigable interface. That makes the CLI feel inconsistent and leaves some workflows harder to discover than they need to be.
The next step should be a command-wide TUI/navigation model that can guide users through common flows when they are in an interactive terminal, while still preserving the plain flag-driven CLI for scripts, CI, and people who do not want interactive navigation.
Lithos already has some good building blocks for this: an alt-screen plan viewer, arrow-key confirmation prompts, and an environment selection helper. This issue is about turning those pieces into a consistent command experience rather than leaving them isolated to a small slice of the CLI.
Commands that should participate
deploy
outputs
import
destroy
undo
- future interactive commands that benefit from the same navigation model
Acceptance criteria
- Lithos provides a consistent navigable TUI flow for the commands above when running in an interactive terminal.
- Where required or helpful inputs are missing, Lithos can collect them through navigation/prompt flows instead of forcing every interaction through memorized flags.
deploy and undo keep their plan review experience, but the same overall navigation model can also be used by outputs, import, destroy, and future commands.
- Lithos adds one consistent opt-out flag across interactive commands, tentatively
--no-navigation (final name can differ), that disables navigable UI and falls back to the plain CLI path.
- The opt-out flag does not silently approve destructive operations. Approval semantics such as
--yes remain explicit.
- Non-interactive environments (CI, piped output, redirected stdin/stdout) never hang waiting for the TUI and continue using deterministic non-interactive behavior.
- Help text and docs explain when Lithos opens navigable UI, how to bypass it, and how the new flag interacts with command-specific flags like
--yes, --no-preview, and --plain-preview.
- Tests cover interactive-routing and non-interactive fallback behavior for at least the listed command set.
Out of scope
- Removing the existing explicit flag-driven CLI surface.
- Requiring a full-screen TUI for every command.
- Auto-approving destructive actions when navigation is disabled.
- Building heavy command-specific browsing UIs for data Lithos cannot sensibly enumerate yet.
What to build
Lithos needs a broader and more coherent terminal UI than it has today.
Right now the interactive experience is uneven:
deployandundoalready have richer preview and confirmation flows, but commands likeoutputs,import, anddestroystill mostly behave like direct flag-only commands with little or no navigable interface. That makes the CLI feel inconsistent and leaves some workflows harder to discover than they need to be.The next step should be a command-wide TUI/navigation model that can guide users through common flows when they are in an interactive terminal, while still preserving the plain flag-driven CLI for scripts, CI, and people who do not want interactive navigation.
Lithos already has some good building blocks for this: an alt-screen plan viewer, arrow-key confirmation prompts, and an environment selection helper. This issue is about turning those pieces into a consistent command experience rather than leaving them isolated to a small slice of the CLI.
Commands that should participate
deployoutputsimportdestroyundoAcceptance criteria
deployandundokeep their plan review experience, but the same overall navigation model can also be used byoutputs,import,destroy, and future commands.--no-navigation(final name can differ), that disables navigable UI and falls back to the plain CLI path.--yesremain explicit.--yes,--no-preview, and--plain-preview.Out of scope