aspire new: staging-identity CLI should auto-register the staging channel

[radical]

A staging-channel CLI (identity = staging) does not get the staging channel registered in PackagingService.GetChannelsAsync by default.

PackagingService only registers the staging channel when KnownFeatures.IsStagingChannelEnabled is true — i.e. when the stagingChannelEnabled feature flag is set, or configuration["channel"] == "staging". A user running a freshly downloaded staging CLI with no extra config hits neither condition.

The result: aspire new (and any other command that resolves channels) sees only { default, stable, daily } and falls back to Implicit (nuget.org). The CLI's own identity is silently ignored.

This is benign for aspire new after #17120 (it falls back to a stable nuget.org template, which restores fine), but it means staging users don't actually get the staging feed for templates or for aspire add. It should "just work" the same way daily does — the daily channel is registered unconditionally.

Suggestion

In PackagingService.GetChannelsAsync, treat CliExecutionContext.IdentityChannel == "staging" as another trigger for registering the staging channel, alongside the existing feature-flag / config triggers.

Repro

1. Install a staging CLI: ./eng/scripts/get-aspire-cli.sh --quality staging --install-path /tmp/aspire-staging --skip-path
2. /tmp/aspire-staging/aspire new aspire-ts-starter --name X --output . --non-interactive — note that the generated aspire.config.json has no channel pin and the SDK version comes from nuget.org rather than the staging feed.

[radical]

@joperezr what should be done for this? something to fix?

[joperezr]

🤖 Aspire triage pass — 2026-05-15 08:45 UTC

Area: area-cli, area-acquisition
Kind: bug
Repro: yes-minimal — repro script provided in the issue body (see "Repro" section, ~6 lines)
Affected version(s): staging CLI channel (current staging build); behavior persists with default config. Latest stable: 13.3.x
Severity: S3 — staging CLI silently falls back to the implicit nuget.org feed for templates and aspire add. There is an effective workaround (set stagingChannelEnabled feature flag or configuration["channel"] = "staging"), and #17120 makes aspire new itself recover, so user-visible impact is degraded staging coverage rather than a broken core scenario.

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: clean repro, well-scoped behavior fix in PackagingService.GetChannelsAsync, but no regression baseline vs. 13.2 is established and the failure mode is benign (silent fallback) rather than broken — does not meet the servicing bar.

Suggested owner(s): @JamesNK (score 100+), backup @mitchdenny (score 6)
Evidence:

• JamesNK merged 40+ area-cli PRs in the last 90 days, including very recent CLI changes (Refactor CLI commands to return CommandResult and centralize cancellation handling #17005, Echo selection prompt result after interactive selection #16996, Add --search option to aspire logs and aspire otel commands #16939, Trim whitespace in markdown link text and extract MarkdownLinkConverter #16926, Add --yes validation to UpdateCommand and share validation logic #16829)
• mitchdenny merged Fix config discovery to search from apphost directory and add aspire.config.json to .NET templates #15423 and Remove mature feature flags that no longer need toggles #15075 in area-cli
• CODEOWNERS for src/Aspire.Cli/** not inspected in this run; consider checking before final assignment

Confidence: medium
Needs human?: yes — confirm whether the linked #17120 fully covers the user-visible regression and whether the remaining aspire add / template-feed silent fallback warrants servicing rather than vNext.

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

[joperezr]

Pulling into 13.4 as it directly helps our own staging dogfood loop -- right now a freshly-downloaded staging CLI silently falls back to nuget.org for templates and aspire add, which makes `but it worked in staging'' checks unreliable.

The fix scope looks small (register the staging channel in PackagingService.GetChannelsAsync when CliExecutionContext.IdentityChannel == staging ), low risk, and it aligns with theme 3 (acquisition vectors) where channel routing has to be solid.

FYI @mitchdenny -- flagging as something to consider for staging dogfood facilitation. Priority will be medium in the Aspire burndown project.