[docs] Update notification center docs to include canceled command state

[aspire-repo-bot]

Documents changes from microsoft/aspire#17204 — authored by @JamesNK.

Target branch

Targeting release/13.4 based on the source PR milestone 13.4 (exact match on microsoft/aspire.dev).

Why this PR is needed

Prior to microsoft/aspire#17204, when a user canceled a resource command in the Aspire Dashboard, the in-progress notification was silently removed from the notification center. The fix keeps canceled commands visible in the notification center as a warning (amber) notification.

The existing docs stated: "A resource command starts, succeeds, or fails. Both success and failure messages appear as notifications." This no longer accurately describes the behavior — canceled commands are now retained too.

Files modified

• src/frontend/src/content/docs/dashboard/explore.mdx

Generated by PR Documentation Check for issue #17204 · ● 33M · ◷

[Copilot]

Pull request overview

Updates the Aspire Dashboard “Notification center” documentation to reflect the newer behavior where canceled resource commands remain visible (as warning notifications), aligning docs with the dashboard change from microsoft/aspire#17204.

Changes:

• Updated notification center description to include the “canceled” command outcome.
• Clarified that the notification center retains completed command outcomes (success/error/canceled) with their corresponding notification severities.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[IEvangelist]

Generated by running the doc-tester skill against the changed page on a local docs build (aspire run), navigating with Playwright and following the methodology in SKILL.md.

Summary

This PR updates a single bullet on dashboard/explore.mdx so that the Notification center section reflects the behavior introduced by microsoft/aspire#17204: canceled resource commands are now retained in the notification center (as a warning) instead of being silently removed.

I tested the changed page against a locally served docs build (Aspire AppHost running, frontend at http://localhost:49938) and read it as a new user would, per the doc-tester skill. The change is accurate, well-scoped, and renders correctly, with only optional clarification opportunities — no blockers and nothing factually wrong.

Category	Pass	Warn	Fail
Content accuracy	✓	–	–
Renders correctly	✓	–	–
Internal links resolve	✓	–	–
Style consistency	✓	–	–
Cross-doc consistency	✓	–	–

Findings

Nit 1 — Implicit fate of the in-progress (“starts”) notification

• Location: src/frontend/src/content/docs/dashboard/explore.mdx line 571.
• Severity: nit (advisory).

The new bullet enumerates four trigger events in sentence 1 (starts, succeeds, fails, or is canceled) and then says sentence 2 — “The notification center retains entries for all completed command states” — which lists only the three completed outcomes. A reader can infer that the starts (in-progress) notification is replaced/transitioned when the command reaches a completed state, but the doc doesn’t spell that out. Since the source-of-truth PR (microsoft/aspire#17204) describes the fix as “keeps canceled commands visible … as a warning,” it might help future readers to make the lifecycle explicit (e.g., “the in-progress notification is replaced by the corresponding completion entry”).

This is not a blocker; the bullet is grammatically correct and matches behavior.

Nit 2 — “View response” paragraph is silent on canceled notifications

• Location: src/frontend/src/content/docs/dashboard/explore.mdx line 574 (existing prose, just below the changed bullet).
• Severity: nit (advisory).

The very next paragraph still reads:

Success and error notifications that include a command result provide a View response action button to open the result in the text visualizer.

Now that canceled commands are first-class notifications, a new reader may wonder whether canceled notifications can also include a result / surface a View response button. The doc currently implies “no” by omission, which is probably correct, but stating it explicitly (or generalizing the sentence) would close the loop opened by the new bullet. Out of scope for this minimal targeted fix, but worth a follow-up.

Nit 3 — notificationCenterOpen screenshot doesn’t (yet) showcase the new warning state

• Location: src/frontend/src/content/docs/dashboard/explore.mdx ~ line 576 (<Image src={notificationCenterOpen} … />).
• Severity: nit (advisory, definitely follow-up).

The accompanying screenshot in this section pre-dates the canceled-as-warning behavior, so it shows only success/error rows. Re-capturing it with a canceled (amber) entry would make the new wording self-evident. Not a blocker on this PR; flagging only because the bullet now explicitly calls out the warning state.

Suggested wording (optional)

If the author wants to address Nit 1 + Nit 2 in this PR, a tweak like the following would close both loops without adding much length (keeping the same bullet structure):

- A resource command starts, succeeds, fails, or is canceled. While in progress, a command appears as an in-progress notification; when it completes, the notification center retains an entry for the final state — success (information), failure (error), or canceled (warning). Only **success** and **failure** notifications can include a command result with a **View response** action.

Take it or leave it — the current wording is accurate.

Knowledge gaps surfaced

Per the doc-tester skill, here are places where I noticed myself reaching for inferred / prior knowledge rather than reading it on the page:

Knowledge gap: severity color mapping (information / error / warning)

• What I needed to know: that information renders blue-ish, error renders red-ish, warning renders amber.
• Source of my knowledge: built-in convention (and the source PR description), not this page.
• User impact: A new user who has never opened the dashboard would not visually anchor “warning” to an amber pill — they’d need to open the app to discover the color treatment.
• Recommendation: Reasonable to leave implicit on this page (colors are visual UI conventions and an updated screenshot would address it; see Nit 3).

Knowledge gap: what “canceled” means in this context

• What I needed to know: that canceled refers to the user backing out of a confirmation prompt (or otherwise canceling a command), distinct from a server-side failure.
• Source of my knowledge: the linked Custom resource commands page (which is cross-referenced from this section and documents CommandResults.Canceled()), so it’s already two clicks away.
• User impact: Low — anyone wanting more detail will find it via the existing link at the bottom of the section.

Verification performed

1. Read .github/skills/doc-tester/SKILL.md and followed its methodology.
2. Checked out PR #1008 (pr-1008) on top of upstream/release/13.4.
3. Started the local docs site via aspire run; resolved the frontend at http://localhost:49938 (via aspire describe).
4. Navigated to http://localhost:49938/dashboard/explore/#notification-center with Playwright and confirmed the new bullet renders, is well-formed, and reads naturally.
5. Resolved the only internal link in the section, /fundamentals/custom-resource-commands/ (loaded HTTP 200 on the local site, title Custom resource commands | Aspire).
6. Cross-checked terminology against src/frontend/src/content/docs/fundamentals/custom-resource-commands.mdx (the ExecuteCommandResult / Canceled documentation) — consistent.
7. Verified em-dash style (—) matches existing usage in the same file.
8. Confirmed no other docs page contradicts the new wording (grep for “notification center” and “canceled command”).

Verdict

COMMENT. No blocking issues. The change is correct, narrowly scoped, and renders well. The notes above are all optional, advisory, and can either be folded into this PR with a small wording tweak or tracked as a follow-up.