diff --git a/AGENTS.md b/AGENTS.md
index 2780e797..bf5a4415 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -458,9 +458,9 @@ free to run a full `local:gate`). Raising a budget nobody chose hides no race.
   option, a `describe` option, a project setting and a `--retry` flag all land
   on the same check.
 - **`maxWorkers` stays unset — on measurement, not by omission (#2336).** The
-  five forks-pool projects inherit `availableParallelism() - 1`; web's
+  five forks-pool projects inherit `max(availableParallelism() - 1, 1)`; web's
   `storybook` project runs the browser pool, whose own default is
-  `min(12, availableParallelism() - 1)` and which was not measured (a cap set
+  `max(min(12, availableParallelism() - 1), 1)` and which was not measured (a cap set
   there would apply, so it is not exempt — it just needs its own numbers).
   Capping the forks pool to 4 was
   measured at the leased baseline as +14% wall on the web unit suite and +39%
diff --git a/vitest.shared.mts b/vitest.shared.mts
index fb7754ec..7eba9e4b 100644
--- a/vitest.shared.mts
+++ b/vitest.shared.mts
@@ -83,12 +83,13 @@ export const INTEGRATION_TIMEOUTS = Object.freeze({
  *
  * The five forks-pool projects — web `unit` and `integration`, `cli`, `tui`,
  * `launcher` — therefore inherit Vitest's non-watch default,
- * `availableParallelism() - 1`: 7 on the eight-logical-core M3 this team
- * works on. Web's `storybook` project is the exception: it runs the browser
- * pool, whose default is a different expression,
- * `min(12, availableParallelism() - 1)` — also 7 here, but capped on larger
- * machines because the main thread chokes past ~12 browser workers
- * (vitest#7871) — and 1 unless the run is headless with file parallelism. A
+ * `max(availableParallelism() - 1, 1)`: 7 on the eight-logical-core M3 this
+ * team works on. Web's `storybook` project is the exception: it runs the
+ * browser pool, whose default is a different expression,
+ * `max(min(12, availableParallelism() - 1), 1)` — also 7 here, but capped on
+ * larger machines because the main thread chokes past ~12 browser workers
+ * (vitest#7871) — and a single worker unless the run is headless, file
+ * parallelism is on, and the provider supports it. A
  * `maxWorkers` set on that project *would* apply to it (`getThreadsCount`
  * reads it before falling back), so it is not exempt from this decision;
  * but nothing below measured it. The numbers are the forks pool's, and a cap