Review CLI flow rendering for polyglot AppHost experience

[davidfowl]

Objective

Clean up CLI rendering and ensure spinner/progress output is in the right place for the core polyglot AppHost flows.

Commands in scope

• aspire new
• aspire init
• aspire add
• aspire update
• aspire run
• aspire do
• aspire publish
• aspire deploy

Rendering contract (applies to every command)

• Spinner is shown only while real work is in progress.
• Spinner is always stopped/cleared before prompts, summaries, warnings, errors, or streamed logs.
• Only one active spinner at a time (no nested or competing animations).
• Completed spinner steps are replaced by stable, readable lines (for example: ✔ Restored dependencies).
• No orphaned frames, cursor artifacts, or overwritten text after command completion/failure.
• Non-interactive mode (CI/non-TTY) emits plain, line-based progress (no animation control codes).
• Output remains readable with --no-color and when copied into issue comments/logs.

Command-by-command flow review

1) aspire new

Flow:

1. Create files/template output
2. Restore/install dependencies
3. Print next steps (cd ..., aspire run)

Rendering checks:

• Spinner appears for file generation and dependency restore/install only.
• Spinner is not shown during template selection prompts.
• Final "next steps" block is static text with no trailing animation artifacts.

Failure checks:

• Existing directory conflict, missing Node/.NET SDK, restore/install failure all clear spinner before error text.

2) aspire init

Flow:

1. Detect existing project layout
2. Generate/wire AppHost artifacts
3. Print summary of files/changes

Rendering checks:

• Detection output is concise and stable (spinner only if detection takes noticeable time).
• Spinner used while writing/modifying files, then replaced with a final change summary.
• Any confirmation prompt appears without active spinner.

Failure checks:

• Already-initialized project and unsupported layout errors are printed cleanly with no spinner residue.

3) aspire add

Flow:

1. Resolve target apphost and parse add target
2. Prompt for options (name, image/version, etc.)
3. Apply project/config changes
4. Print "what changed" summary

Rendering checks:

• No spinner during interactive prompts.
• Spinner used during template/resource resolution and file updates.
• Result shows a stable summary of added resource + touched files.

Failure checks:

• Duplicate name, invalid option, or unknown add target ends with clean error output (no broken render state).

4) aspire update

Flow:

1. Check current vs available versions
2. Show update plan
3. Apply updates
4. Print result + follow-up guidance

Rendering checks:

• Spinner used for remote/version checks and package acquisition/apply steps.
• Spinner is cleared before printing plan/details.
• Final output clearly separates updated items, skipped items, and warnings.

Failure checks:

• Network/version conflict/partial apply failures render explicit recovery steps after spinner clears.

5) aspire run

Flow:

1. Preflight checks (restore/build/validate)
2. Start apphost + services
3. Print dashboard URL + service status view
4. Stream logs and support clean shutdown

Rendering checks:

• Startup spinner only during preflight/startup phases.
• Spinner is removed before persistent service table/log stream begins.
• Service state transitions are stable and readable (no flicker/duplication).
• Ctrl+C shutdown messages render in order and leave terminal in a clean state.

Failure checks:

• Port conflicts/startup failures show actionable errors with no interleaved spinner frames.

6) aspire do

Flow:

1. Resolve operation and target context
2. Execute the requested operation
3. Print a final summary of what ran/changed

Rendering checks:

• Spinner is shown only during execution and not while prompting for missing inputs.
• Per-step completion is emitted as stable lines once each step finishes.
• Final summary renders after spinner teardown, with no cursor/control-sequence artifacts.

Failure checks:

• Invalid operation, validation failures, and execution errors clear spinner before actionable error output.

7) aspire publish

Flow:

1. Resolve publish target/profile
2. Build/package assets and dependencies
3. Emit artifacts and publish summary

Rendering checks:

• Spinner is used for packaging/upload-prep work only.
• Detailed plan/table output is printed with no active spinner.
• Final output clearly identifies artifact locations and next actions.

Failure checks:

• Build/package/publish failures stop animation cleanly and include recovery guidance.

8) aspire deploy

Flow:

1. Validate environment/credentials and deployment target
2. Apply deployment plan
3. Print deployed endpoints/resources and status

Rendering checks:

• Spinner is used for remote operations and provisioning waits.
• Long-running deployment progress does not flicker or duplicate lines.
• Completion/failure messages are stable and readable after spinner cleanup.

Failure checks:

• Auth/permission, target validation, and partial-deploy failures produce clean, non-interleaved error output.

Deliverables

• Capture golden transcripts for each command in TTY and non-TTY mode.
• Validate rendering/copy for TypeScript-only and mixed-language (.NET + TS) solutions.
• File follow-up issues for each command-specific UX/rendering gap.
• Update help/next-step text where wording is .NET-centric or ambiguous for polyglot users.
• Add/adjust tests for spinner lifecycle and final rendered output where test coverage exists.

Non-goals

• Full redesign of command architecture in this issue.
• Solving every parity gap immediately (this issue tracks review + prioritized follow-up work).

[davidfowl]

We have some missing animations from the various experiences

[JamesNK]

Missing animations? Do you mean displaying a status indicator while work is happening?

[davidfowl]

Yep.