ci: leave the Windows recovery suites to the required test lane

This lane's pull-request filter named every source directory in the
workspace closure of the crash and owner-death tests it runs, so it took
a Windows runner on 118 of the last 200 merges. The filter was accurate —
those suites really do import most of `runtime`, `runtime-host`,
`storage` and `core`, and a generated import closure measured at 106 of
the same 200, because they boot a real Runtime Host. The list was not the
problem.

What the run history shows is that the pull-request trigger was. Across
300 runs, 241 of them pull requests, this lane produced 12 reds and not
one of them was unique: every pull-request failure sat on a commit whose
`test` run had already failed, usually at the very same step — six at
`Install dependencies`, one at the workspace tests that run the same
owner-death suite on Linux. Its single unique catch in that window was a
Windows-only NTFS alternate stream regression found by the unfiltered
main push, which is the trigger that exists for exactly that.

So the filter now names only what a Windows runner can prove and `test`
cannot: how `npm ci` resolves and what the dependency patches and the
Electron installer produce there, what the clean step removes there, and
the Local IPC trust boundary, a PowerShell script with no other caller.
That is 14 of 200 merges instead of 118. The install and build steps stay
unconditional, because proving those suites still build and run on
Windows is what the lane is for once it does run.

The recovery authorities are now covered after merge rather than before
it, by the unfiltered main push minutes later and by the nightly.
`windows_recovery` is deliberately not a required context in `.asf.yaml`,
so it was never what stood between a regression and `main` in any case.

Generated-by: Claude Code

Author: Astro-Han

.github/workflows/windows-recovery.yml

@@ -17,24 +17,31 @@
 
 name: Windows recovery
 
-# The paths below are a pre-filter, not this lane's real input. The real input
-# is the import closure of the crash and owner-death recovery authorities in
-# storage, runtime and Runtime Host, which reaches well past any list worth
-# hand-maintaining. So they name those workspaces and every workspace they hold
-# a TypeScript project reference to, plus the manifests, patches and scripts
-# the unconditional install and clean steps consume. That keeps a change there
-# reported before merge, and the nightly run covers the transitive edits the
-# list cannot match.
+# The paths below name only what a Windows runner can prove and the required
+# `test` lane cannot: how `npm ci` behaves here, what the dependency patches and
+# the Electron installer produce here, and the Local IPC trust boundary, which
+# is a PowerShell script with no other caller.
 #
-# GitHub evaluates a path filter against the first 300 files of the diff only,
-# so a pull request wider than that can skip the filter outright. A repository-wide sweep is exactly the change that touches every
-# recovery authority at once, which is one more reason the main push below
-# carries no filter at all.
+# They deliberately do not name the recovery authorities themselves. Those used
+# to be here, as every source directory in the workspace closure of the crash
+# and owner-death tests below, which put this lane on 118 of the last 200
+# merges. Over 300 runs it never once produced a pull-request red that the
+# `test` lane had not already produced on the same commit, usually at the very
+# same step: the recovery suites are ordinary TypeScript, so a defect in them
+# fails on Linux first and blocks the merge there. Its one unique catch in that
+# window — a Windows-only NTFS alternate stream regression — came from the main
+# push below, which is what that trigger exists for.
+#
+# So the authorities are covered after merge rather than before it, minutes
+# later, by a push run that carries no filter at all. That trigger is also
+# unfiltered because `required_status_checks` is `strict: false`, so a pull
+# request can go green against a stale base, and because GitHub evaluates a path
+# filter against the first 300 files of a diff only — and a repository-wide
+# sweep is exactly the change that touches every recovery authority at once.
 on:
   pull_request:
     branches: [main]
     paths:
-      - 'package.json'
       - 'package-lock.json'
       - 'patches/**'
       - 'scripts/apply-dependency-patches.mjs'
@@ -43,21 +50,6 @@ on:
       - 'scripts/clean-build.mjs'
       - 'scripts/clean-paths.mjs'
       - 'scripts/windows-runtime-host-local-ipc-trust.ps1'
-      - 'tsconfig.base.json'
-      - 'tsconfig.lib.json'
-      - 'packages/core/package.json'
-      - 'packages/core/tsconfig.json'
-      - 'packages/core/src/**'
-      - 'packages/storage/package.json'
-      - 'packages/storage/tsconfig.json'
-      - 'packages/storage/src/**'
-      - 'packages/runtime/package.json'
-      - 'packages/runtime/tsconfig.json'
-      - 'packages/runtime/src/**'
-      - 'packages/runtime/scripts/**'
-      - 'packages/runtime-host/package.json'
-      - 'packages/runtime-host/tsconfig.json'
-      - 'packages/runtime-host/src/**'
       - '.github/workflows/windows-recovery.yml'
   # Unfiltered on purpose: required_status_checks is `strict: false`, so a pull
   # request goes green against a stale base and only the merged result proves

scripts/ci-test-plan.test.mjs

@@ -687,29 +687,38 @@ test('the recovery lane keeps every run kind out of one shared concurrency group
   assert.match(workflow, /\n {2}cancel-in-progress: true/u);
 });
 
-test('the recovery lane filters pull requests by the workspaces its steps execute', () => {
+test('the recovery lane leaves the suites it executes to the required test lane', () => {
   const workflow = readWorkflow('windows-recovery.yml');
   const filtered = new Set(pullRequestPathFilter('windows-recovery.yml'));
 
   // Derived from the dist paths the steps run, then widened along the workspace
   // dependency graph the planner selects with. The separator class matches the
   // backslash form too, because these steps run under pwsh where both are
-  // legal. A new workspace on this lane, or a new dependency under one of them,
-  // fails here until the filter admits its sources and project file.
+  // legal.
   const executed = [
     ...new Set(
       [...workflow.matchAll(/packages[/\\]([^/\\]+)[/\\]dist[/\\]/gu)].map((match) => match[1]),
     ),
   ].sort();
   assert.deepEqual(executed, ['runtime', 'runtime-host', 'storage']);
 
+  // None of that closure belongs in the filter. These suites are ordinary
+  // TypeScript, so `test` runs them on Linux on every pull request and fails
+  // first; naming their sources here only bought a second, slower red. Listing
+  // one again would put this lane back on most merges, so it fails here.
   const closure = dependencyClosure(executed.map((workspace) => `packages/${workspace}`));
   assert.ok(closure.includes('packages/core'), 'dependency closure must reach core');
   for (const dir of closure) {
-    assert.ok(filtered.has(`${dir}/src/**`), `${dir}: sources`);
-    assert.ok(filtered.has(`${dir}/tsconfig.json`), `${dir}: project file`);
-    assert.ok(filtered.has(`${dir}/package.json`), `${dir}: manifest`);
+    for (const entry of [`${dir}/src/**`, `${dir}/tsconfig.json`, `${dir}/package.json`]) {
+      assert.ok(!filtered.has(entry), `${entry} belongs to the required test lane`);
+    }
   }
+
+  // What the Windows runner proves instead is that the suites still build and
+  // run here at all, which is why the unconditional install and build steps stay
+  // unconditional even though nothing in the filter names a workspace.
+  assert.match(workflow, /\n {6}- name: Install dependencies\n {8}run: npm\.cmd ci\n/u);
+  assert.match(workflow, /\n {8}run: npm\.cmd run build:test\n/u);
 });
 
 test('the recovery lane filter follows the postinstall launcher chain', () => {
@@ -732,25 +741,23 @@ test('the recovery lane filter follows the postinstall launcher chain', () => {
   }
 });
 
-test('the recovery lane filters pull requests by what its install and clean steps consume', () => {
+test('the recovery lane filters pull requests by what only Windows can prove', () => {
   const filtered = new Set(pullRequestPathFilter('windows-recovery.yml'));
 
-  // `npm.cmd ci` and `npm.cmd run build:test` run unconditionally, so these are
-  // first-class inputs of the lane rather than transitive edits the nightly can
-  // be left to cover. A grouped dependabot bump touches only the manifests, and
-  // the crash gates sit on a native file lock the Linux `test` lane never sees.
+  // What is left after the workspace sources came out: how `npm.cmd ci` resolves
+  // and what it produces on Windows, what `npm.cmd run build:test` cleans up
+  // there, and a PowerShell script this lane is the only caller of. Each of
+  // these can be green on Linux and red here, which is the whole test for
+  // membership in this list.
   for (const path of [
-    'package.json',
     'package-lock.json',
     'patches/**',
     'scripts/apply-dependency-patches.mjs',
     'scripts/install-electron-with-retry.mjs',
+    'scripts/run-electron-installer.cjs',
     'scripts/clean-build.mjs',
     'scripts/clean-paths.mjs',
     'scripts/windows-runtime-host-local-ipc-trust.ps1',
-    'tsconfig.base.json',
-    'tsconfig.lib.json',
-    'packages/runtime/scripts/**',
     '.github/workflows/windows-recovery.yml',
   ]) {
     assert.ok(filtered.has(path), path);