CLI: Review which commands should display update notifications

[JamesNK]

Summary

After #17350 changed update notifications to opt-in, we should review which commands display the notification and establish a clear rule for when it's appropriate.

Current state

Commands that currently opt in to UpdateNotificationsEnabled:

Command	Purpose
AddCommand	Add integrations to a project
DashboardRunCommand	Run the Aspire dashboard
InitCommand	Initialize an Aspire project
LsCommand	List Aspire projects
NewCommand / TemplateCommand	Create a new Aspire project
PipelineCommandBase (Deploy/Destroy/Do/Publish)	Deploy or publish
RestoreCommand	Restore project dependencies
RunCommand (non-detach)	Run an AppHost interactively
SetupCommand	Set up the Aspire layout
StartCommand	Start an AppHost in the background
StopCommand	Stop a running AppHost

Commands that were removed from opt-in during review:

• DescribeCommand, ExportCommand, LogsCommand, PsCommand, ResourceCommand, WaitCommand

Proposed rule

Update notifications should only be displayed for project-lifecycle commands — commands that create, configure, build, run, or deploy an AppHost. Commands that interact with individual resources within a running AppHost, produce machine-readable output, or are quick utilities should NOT display update notifications.

Rationale:

• Project-lifecycle commands (new, init, run, start, deploy) are natural moments for users to learn about updates
• Resource-interaction commands (logs, ps, describe, wait, resource start/stop) are executed frequently during development and the notification becomes noise
• Machine-readable/streaming commands should never show notifications as they pollute structured output

Action items

• Confirm the proposed rule matches team intent
• Evaluate whether LsCommand and StopCommand should still show notifications (they're quick commands)
• Add the rule to agent instructions so future commands follow the convention

[joperezr]

🤖 Aspire triage pass — 2026-05-22 03:25 UTC

Area: area-cli
Kind: question (convention / policy review, follow-up to #17350)
Repro: n/a — proposal / discussion (see "Proposed rule" section in body, ~lines 20–28)
Affected version(s): not version-specific; tracks behavior introduced by #17350
Severity: S4 — UX/convention polish, no broken scenario

Urgency: ⚪ backlog — no milestone
Reason: Policy/convention discussion with no user-facing breakage. Not a regression vs. shipped bits; doesn't meet the servicing or vNext bar.

Suggested owner(s): @mitchdenny (CODEOWNERS for /src/Aspire.Cli), backup @davidfowl (CODEOWNERS)
Evidence:

• CODEOWNERS lists @mitchdenny @JamesNK @davidfowl for /src/Aspire.Cli
• area-cli merged PRs in the last 90d are dominated by the issue author (@JamesNK), who is excluded as the reporter; next non-author signal is from CODEOWNERS
• @adamint also has recent merged activity in area-cli (e.g. Fix aspire new: move OpenEditor after agent init prompt in VS Code extension #15552) as a secondary signal

Confidence: medium
Needs human?: no — straightforward backlog classification; owner pick relies on CODEOWNERS because the dominant recent CLI contributor is the reporter.

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.