Trim PR integration test skill

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b88f4443-0b18-4d44-ae20-dde46ff2eea8

Author: vanzue

.github/skills/pr-integration-test/SKILL.md

@@ -11,38 +11,23 @@ checklist.
 
 ## When to Use This Skill
 
-- Add integration or E2E tests for a specific PR.
-- Add follow-up regression coverage after a fix has merged.
-- Prove a bug from an issue cannot recur across real component boundaries.
+- Convert an open or merged PR into cross-component regression coverage.
 - Extend `doc/release-check-list.md` and make report scripts check the new rows.
 - Audit whether a PR's existing tests cover the user-visible behavior rather
   than only its implementation details.
 
 ## Prerequisites
 
-- Work on a feature branch, never directly on `main` or `master`.
-- Use `gh` to inspect the target PR, linked issues, review discussion, and state.
-- Read repository and area-specific instructions before editing.
 - Read `test/e2e/README.md` and reuse the ItE2E framework instead of creating a
   parallel harness.
 - Run `pwsh -File test/e2e/bootstrap.ps1 -Check` before live E2E validation.
 
 ## Workflow
 
 Follow [workflow.md](./references/workflow.md). Track the phases with a TODO
-list because PR analysis, test design, checklist wiring, live validation, and
-delivery must all complete.
-
-1. Resolve the target PR and select the correct base commit and branch strategy.
-2. Reconstruct the user-visible behavior and the complete component path.
-3. Audit existing unit, integration, E2E, and release-checklist coverage.
-4. Build a positive/negative/regression behavior matrix before writing tests.
-5. Implement the smallest deterministic integration suite using existing ItE2E
-   primitives.
-6. Map each new release-signoff behavior to a stable checklist item.
-7. Run the new suite, related existing regressions, and release-report scripts.
-8. Commit, push, and prepare a PR whose evidence names passes, skips, checklist
-   IDs, and the exact build tested.
+list.
+
+`analyze PR -> reconstruct behavior -> audit coverage -> design matrix -> write ItE2E -> wire checklist -> validate -> deliver`
 
 ## Test Design Standard
 
@@ -58,11 +43,6 @@ For every proposed case, record:
 | Existing protection | Which existing tests protect old behavior and must still run? |
 | Checklist title | Which exact bold release-checklist title contains the Pester test name? |
 
-An integration test is justified only when it proves a boundary that lower-level
-tests do not. Keep focused unit tests for branch logic; use E2E for wiring,
-packaging, process boundaries, protocol events, persistence, and real UI
-interaction.
-
 ## Oracle Priority
 
 Prefer the earliest deterministic product-owned signal:
@@ -73,9 +53,8 @@ Prefer the earliest deterministic product-owned signal:
 4. Rendered terminal or UI state
 5. LLM-generated text
 
-Use an LLM output or AI judge only when usefulness or semantic correctness is
-the behavior under test. Do not make routing, trigger, suppression, or
-single-flight regressions depend on model wording.
+Use model output only when it is the behavior under test; never use it to prove
+routing, triggers, suppression, or idempotency.
 
 ## Release Checklist Contract
 
@@ -85,26 +64,18 @@ single-flight regressions depend on model wording.
 - Prefer exact-title matching. Add `test/e2e/release-coverage-map.psd1` entries
   only when an exact test name would be misleading or one case intentionally
   covers multiple checklist items.
-- Run `pwsh -File test/e2e/Set-ChecklistIds.ps1`; never assign or renumber
-  stable checklist IDs manually.
-- Run the suite through the E2E report driver, not only `Invoke-Pester`, and
-  inspect `release-report.md` to prove every new ID is `[x]`.
-- Verify `Update-ReleaseReport.ps1` too when the suite is expected to support
-  partial release-signoff runs.
+- Assign stable IDs and verify `[x]` output through the full and incremental
+  report paths in [workflow.md](./references/workflow.md).
 
 ## Completion Gate
 
 Do not call the work complete until all of these are true:
 
-- The original regression fails on the old behavior or is otherwise tied to a
-  verified pre-fix symptom.
-- The fixed path passes through the real integration boundary.
-- False-positive and replay/idempotency risks are covered where applicable.
-- Related preexisting suites pass, or every skip/failure is explicitly
-  classified as environment, model variance, product regression, or test bug.
-- New checklist IDs become `[x]` through both applicable report paths.
-- The deployed package or executable under test is proven to contain the target
-  change; no stale artifact is being exercised.
+- Pre-fix evidence identifies the regression, and the fixed path crosses the
+  real integration boundary.
+- Relevant false positives, replay risks, and existing behavior are covered.
+- The correct build passes related suites and marks new checklist IDs `[x]`;
+  every skip is explained.
 
 ## Gotchas
 
@@ -118,16 +89,6 @@ Do not call the work complete until all of these are true:
 - **Do not turn product failures into skips.** Skip only when an external
   prerequisite is genuinely unavailable. A connected product that behaves
   incorrectly must fail.
-- **Do not rely on fixed sleeps for positive completion.** Start listeners
-  before actions and poll for a scoped event/state. Use a short bounded
-  observation window only to prove that something does not happen.
-- **Do not let unrelated panes or windows satisfy assertions.** Scope events by
-  pane/session/tab/window identifiers whenever the protocol exposes them.
-- **Do not trust a build command alone.** Confirm package selection, deployed
-  version, co-located binaries, and runtime logs when stale artifacts are
-  possible.
-- **Do not add checklist text without validating report matching.** A passing
-  Pester case that leaves its release row unchecked is incomplete coverage.
 
 ## References
 

.github/skills/pr-integration-test/references/workflow.md

@@ -31,9 +31,8 @@ Choose the branch deliberately:
 - **Open PR but independent validation is requested:** create a branch from the
   PR head and clearly state that the test branch depends on the unmerged PR.
 
-Never force-delete a branch based only on its name. Verify the PR state and a
-clean worktree first. A squash-merged branch may require `git branch -D`
-because Git cannot infer ancestry even though GitHub confirms the merge.
+Verify merge state and a clean worktree before deleting a branch. Squash-merged
+branches may require `git branch -D` because Git cannot infer ancestry.
 
 ## 2. Reconstruct the Behavioral Contract
 
@@ -54,9 +53,6 @@ For a regression, distinguish:
 - Why existing tests did not catch the gap.
 - Which observable separates the regression from a legitimate success case.
 
-Do not accept a PR description as the sole source of truth. Compare it with the
-code, issue reproduction, logs/events, and live behavior when available.
-
 ## 3. Audit Existing Coverage and Harness Primitives
 
 Search before adding helpers:
@@ -85,8 +81,8 @@ Classify current coverage:
 | Integration/E2E | Real process/protocol/package/UI wiring |
 | Release checklist | Which user-facing behaviors count as signed off |
 
-Reuse public ItE2E primitives. Add a shared helper only when multiple suites
-need the same operation or the helper itself provides a more precise oracle.
+Add a shared helper only when multiple suites need it or it provides a more
+precise oracle.
 
 ## 4. Build the Behavior Matrix
 
@@ -104,8 +100,8 @@ Start with the regression, then add only risk-driven controls:
 6. **Compatibility:** alternate shell, agent, policy, or language mode only when
    the changed code is shared with it.
 
-Avoid combinatorial matrices. Each case must correspond to a plausible failure
-mode introduced or exposed by the target PR.
+Each case must correspond to a plausible failure mode introduced or exposed by
+the target PR.
 
 For every case, identify both the immediate trigger and the downstream effect.
 For example, proving a failure event exists is insufficient when the user
@@ -139,19 +135,13 @@ Describe 'Feature: <behavior>' -Tag 'Feature' -Skip:(-not $script:Ready) {
 
 Implementation rules:
 
-- Start event listeners before triggering the behavior.
-- Scope event predicates by stable IDs; do not accept unrelated startup events.
-- Use `Wait-WtEvent`, `Test-Until`, or assertion helpers for positive outcomes.
-- For negative outcomes, first prove the command/action completed, then observe
-  a short bounded window and assert the forbidden event/state is absent.
-- Use unique command text when the product intentionally deduplicates repeated
-  requests.
-- Use fresh applications or explicit state cleanup when one case can leave an
-  agent turn, setting, pane, or listener active.
-- Put cleanup in `finally`/`AfterAll`.
-- Keep model-semantic tests separate from deterministic routing tests. If model
-  variance is accepted, skip only the semantic assertion after proving the
-  deterministic pipeline succeeded.
+- Start listeners before the action; scope predicates by stable IDs and poll for
+  positive outcomes.
+- For a negative case, first prove the action completed, then use a bounded
+  observation window.
+- Use unique inputs when the product deduplicates, isolate state between cases,
+  and clean up in `finally`/`AfterAll`.
+- Keep model-semantic assertions separate from deterministic pipeline checks.
 
 ## 6. Wire the Release Checklist
 
@@ -226,40 +216,19 @@ regressions or the PR changes common harness/product infrastructure.
 
 ## 8. Prove the Correct Build Ran
 
-Build and deploy according to the changed area. For WTA + Terminal changes:
-
-1. Build WTA with the explicit target matching the package architecture:
-   `--target x86_64-pc-windows-msvc` for x64 or
-   `--target aarch64-pc-windows-msvc` for ARM64. Package deployment prefers the
-   explicit-target artifact.
-2. Build the C++ package after WTA.
-3. Deploy/redeploy the package and select it with `ITE2E_PACKAGE` or
-   `-Package Dev`.
-4. Verify package version/path, runtime logs, or a changed observable.
-
-Do not infer deployment success from compilation alone. A stale packaged
-`wta.exe`, generated shell-integration script, profile reference, or AppX
-staging directory can make a new test exercise old code.
+Build and deploy the changed area. For WTA changes, build the explicit target
+matching the package architecture before the C++ package, deploy it, select it
+with `ITE2E_PACKAGE` or `-Package Dev`, and verify a runtime version, path, log,
+or changed observable. Compilation alone does not prove the deployed package
+contains the new `wta.exe` or generated shell integration.
 
 ## 9. Deliver the Test PR
 
-Before committing:
-
-```powershell
-git -c core.whitespace=cr-at-eol diff --check
-git status --short --branch
-```
+Before committing, run `git -c core.whitespace=cr-at-eol diff --check`.
 
 The PR description must include:
 
-- Target PR and issue.
-- Missing integration boundary now covered.
-- Positive, negative, and compatibility cases added.
-- New checklist IDs and proof they become `[x]`.
-- Exact targeted and regression test totals.
-- Every skip with its reason.
+- Target PR/issue and the integration boundary added.
+- Cases and checklist IDs.
+- Targeted/regression totals and skip reasons.
 - Package/build tested.
-
-Do not claim complete regression coverage if environment-dependent suites were
-not run. Distinguish deterministic passes from accepted model variance and
-unavailable prerequisites.