Add VS Code extension E2E test architecture

.agents/skills/cli-e2e-testing/SKILL.md

@@ -611,6 +611,35 @@ When CLI E2E tests fail in CI, follow these steps to diagnose the issue:
 
 > **Flaky test investigation:** for recurring/intermittent failures, see [`troubleshooting.md`](./troubleshooting.md) for a catalog of known flake classes (Y/n input race, prompt-counter desync, etc.) and the recipes to identify them from `.cast` recordings.
 
+### VS Code Extension E2E Diagnostics
+
+VS Code extension E2E jobs upload shard-specific diagnostics as `extension-e2e-diagnostics-<rid>-<shard>-attempt<N>` artifacts. Linux shards include `.mp4` display recordings from Xvfb by default; Windows shards do not record video and instead rely on screenshots, VS Code logs, state files, and workspace diagnostics.
+
+```bash
+# List VS Code extension E2E diagnostic artifacts for a run.
+gh api "repos/microsoft/aspire/actions/runs/<run-id>/artifacts?per_page=100" --paginate \
+  --jq '.artifacts[] | select(.name | startswith("extension-e2e-diagnostics")) | "\(.size_in_bytes)\t\(.name)"'
+
+# Download one shard's diagnostics. The artifact contains .mp4 recordings
+# on Linux, .ffmpeg.log files, screenshots, VS Code logs, state files, and
+# captured workspace diagnostics.
+mkdir -p ./e2e-diagnostics && cd ./e2e-diagnostics
+gh run download <run-id> --repo microsoft/aspire \
+  -n extension-e2e-diagnostics-linux-x64-<shard>-attempt<N> \
+  -D <shard>
+```
+
+Important paths inside the downloaded shard:
+
+```text
+<shard>/.test-recordings/<shard>/<runId>.mp4
+<shard>/.test-recordings/<shard>/<runId>.ffmpeg.log
+<shard>/.test-storage/**/screenshots/
+<shard>/.test-results/e2e/<shard>/extension-state.json
+```
+
+The workflow keeps Linux recordings by default with `ASPIRE_EXTENSION_E2E_RECORDING_MODE=always`. Use `failure` to keep only failed-run videos or `off` to disable recording for local runs.
+
 ### Quick Start: Download and Play Recordings
 
 The fastest way to debug a CLI E2E test failure is to download and play the asciinema recording.

.github/agents/agentic-workflows.agent.md

@@ -176,3 +176,4 @@ gh aw compile --validate
 - Follow security best practices: minimal permissions, explicit network access, no template injection
 - **Network configuration**: Use ecosystem identifiers (`node`, `python`, `go`, etc.) or explicit FQDNs in `network.allowed`. Bare shorthands like `npm` or `pypi` are **not** valid. See https://github.com/github/gh-aw/blob/v0.72.0/.github/aw/network.md for the full list of valid ecosystem identifiers and domain patterns.
 - **Single-file output**: When creating a workflow, produce exactly **one** workflow `.md` file. Do not create separate documentation files (architecture docs, runbooks, usage guides, etc.). If documentation is needed, add a brief `## Usage` section inside the workflow file itself.
+- **User-facing changelog/release-note output**: Workflows that generate changelogs, release notes, status reports intended for release communication, or related summaries must explicitly exclude non-user-facing issues and PRs. Do not include agentic workflow, automation, CI/build, test-only, dependency-bump, release-engineering, changelog-generation, or repository-maintenance changes unless they directly change the released product experience for users.

.github/workflows/extension-changelog.md

@@ -238,12 +238,20 @@ enrich when helpful (for example `is:pr is:merged repo:microsoft/aspire` queries
 to confirm PR titles and labels). You may also read the changed file list /
 diff under `extension/` to understand what actually changed.
 
+Exclude anything that is not user-facing. A change is user-facing only when
+someone using the VS Code extension can observe it in commands, settings,
+debugging, tree views, walkthroughs, diagnostics, packaging/installation,
+security, compatibility, or performance. Do not mention issues or PRs that only
+affect repository operation or the engineering process.
+
 Exclude noise that a user-facing changelog should not mention:
 
 - Dependency-bump / Dependabot PRs unless they fix a user-visible security issue.
 - Build, CI, and test-only changes with no user-facing effect.
 - Internal refactors with no behavior change.
 - Version-bump and release-prep commits (including this PR's own commit).
+- Agentic workflow, automation, changelog-generation, and repository maintenance
+  changes unless they directly change the released extension experience.
 
 ## Step 5: Learn the existing changelog format