@lincoln504/pi-research 1.0.10 → 1.0.12

package/dist/thread-worker.mjs

@@ -1356,7 +1356,10 @@ function isTransientSocketError(error) {
   err.message.includes("Worker pool is shutting down") || // Poolifier throws this when pool.execute() is called while the pool is being
   // destroyed (e.g., during scheduler restart). Treat as transient — the pool will
   // be ready for new tasks once destruction completes and a new pool is initialized.
-  err.message.includes("Cannot execute a task on destroying pool") || err.message.includes("destroying pool"));
+  err.message.includes("Cannot execute a task on destroying pool") || err.message.includes("destroying pool") || // The leader answered 503 because it is shutting down after losing
+  // leadership. Retrying re-elects and reaches the new leader, so this is
+  // transient in exactly the same sense as a pool drain.
+  err.message.includes("Browser pool leader is draining"));
 }
 function isCloudflareBlockError(error) {
   if (!error || typeof error !== "object") return false;
@@ -1368,6 +1371,11 @@ function isTaskTimeoutError(error) {
   const err = error;
   return typeof err.message === "string" && (err.message.includes("timed out after") || err.message.includes("Search task timed out") || err.message.includes("Scrape task timed out") || err.message.includes("Health check timed out") || err.message.includes("[BrowserClient] Request to"));
 }
+function isServerDrainingError(error) {
+  if (!error || typeof error !== "object") return false;
+  const err = error;
+  return typeof err.message === "string" && err.message.includes("Browser pool leader is draining");
+}
 function isPoolShutdownError(error) {
   if (!error || typeof error !== "object") return false;
   const err = error;
@@ -1389,6 +1397,7 @@ var init_browser_error_utils = __esm({
       name: "BrowserPool",
       isTransientError: (error) => {
         if (isPoolShutdownError(error)) return false;
+        if (isServerDrainingError(error)) return false;
         if (isCloudflareBlockError(error)) return false;
         if (isTaskTimeoutError(error)) return false;
         return isTransientSocketError(error);
@@ -1404,6 +1413,7 @@ __export(scraper_utils_exports, {
   createJsMarkdownConverter: () => createJsMarkdownConverter,
   createNativeMarkdownConverter: () => createNativeMarkdownConverter,
   extractDomain: () => extractDomain,
+  formatErrorWithCause: () => formatErrorWithCause,
   getRandomUserAgent: () => getRandomUserAgent,
   getSsrfSafeDispatcher: () => getSsrfSafeDispatcher,
   isBenignScrapeFailure: () => isBenignScrapeFailure,
@@ -1535,6 +1545,34 @@ async function getSsrfSafeDispatcher() {
   }
   return cachedSsrfDispatcher;
 }
+function formatErrorWithCause(err) {
+  try {
+    const parts = [];
+    let current = err;
+    for (let depth = 0; current !== null && current !== void 0 && depth < 5; depth++) {
+      let segment;
+      if (current instanceof Error) {
+        segment = current.message || current.name;
+        const code = current.code;
+        if (typeof code === "string" && code && !segment.includes(code)) {
+          segment = `${segment} [${code}]`;
+        }
+      } else if (typeof current === "string") {
+        segment = current;
+      } else {
+        segment = String(current);
+      }
+      if (segment && !parts.includes(segment)) parts.push(segment);
+      const next = current.cause;
+      if (next === current) break;
+      current = next;
+    }
+    if (parts.length === 0) return String(err);
+    return parts.length === 1 ? parts[0] : parts.join(" \u2190 ");
+  } catch {
+    return String(err);
+  }
+}
 function isPrivateIp(ip) {
   const parts = ip.split(".").map(Number);
   if (parts.length !== 4 || parts.some((p) => isNaN(p))) return false;

package/docs/CHANGELOG.md

@@ -5,6 +5,32 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.0.12] - 2026-08-03
+
+### Fixed
+- **Run-cap / file-lock / leader-election could misreport a live process as dead (Windows/macOS) — the root cause of the flaky `run-semaphore-multiprocess` integration failures on Windows CI.** `ProcessLifecycleService.isProcessAlive(pid, expectedStartTime)` returned `false` ("dead") whenever `process.kill(pid, 0)` confirmed the process was alive but the follow-up **start-time lookup failed**. On Linux that null reliably means the process exited in the microsecond gap between the `signal(0)` and the `/proc/{pid}/stat` read, so `false` was correct — but on Windows/macOS the start time comes from a subprocess (`powershell Get-Process` / `ps`) that can fail or time out under load while the process is still very much alive. Reporting a confirmed-alive PID as dead is catastrophic for *every* caller: a live lock / leader / run-cap owner is reclaimed from under it, so two writers collide (lost update) or the run-cap admits extra concurrent runs. The v1.0.11 Windows CI failure manifested both ways depending on timing — `expected 3 to be 4` (two holders collided on one slot) and `expected +0 to be 3` (a 5th process stole a live holder's slot and was admitted past the cap). The fix re-confirms liveness instead of guessing: when the start-time lookup returns null it issues a second `signal(0)`; if the process is still alive it reports `true`, and only if that probe throws (the process genuinely died in the interim) does the outer handler return `false`. A real death is therefore still detected within one poll tick (~100 ms); the only behavioural change is that a confirmed-alive process is never again reclaimed on a transient start-time lookup failure. PID-reuse protection is unchanged when the start time is resolvable (the `±1s` slack comparison still applies). This is a strict safety improvement across all consumers — file locks, the run-cap semaphore, GPU locks, the embedding leader, browser scheduler and state sessions — none of which ever wanted a live owner treated as dead.
+- **Stack Exchange integration tests no longer fail when the upstream API returns empty results** — the Stack Exchange `search` endpoints intermittently answer `200 OK` (quota consumed, no error) with a zero-item `items:[]` for queries that normally return thousands of results (verified 2026-08-03: `q=javascript` on Stack Overflow returned `[]` from a residential IP). This is an upstream API degradation / contract drift, not a pi-research code fault and not a datacenter-IP block, yet it hard-failed the serial integration suite on all three CI OSes and thereby blocked every release whose code was otherwise identical to a previously-green build. The integration-test environment-skip helper (`isNetworkUnavailable`) now also recognizes a successful-but-empty Stack Exchange response (anchored on the tool-specific `**API Quota:**` footer plus the zero-item body) and skips the affected tests visibly via `ctx.skip()` — the same treatment already given to transport errors and `429`/`5xx` throttling. The anchor is emitted only by the Stack Exchange tool, so it cannot mask a regression in any other tool, and a populated result still exercises the assertions in full.
+
+## [1.0.11] - 2026-08-02
+
+### Added
+- **Cross-process research run-cap** — a machine-wide counting semaphore (`ResearchRunSemaphore`) now gates every `runResearch()` entry on one of N file-lock slots. This is the root-cause fix for the parallel-run instability (60+ error storms and, on constrained hosts, process aborts) that occurred when several research runs saturated the single shared leader-elected browser/embedding pool at once. Holders are reclaimed immediately when their PID exits (PID + startTime guards against PID reuse); *live* holders are never stolen, because a run legitimately holds a slot for minutes. The cap **fails open** on any internal/IO error (a semaphore bug can never break research) and **fails fast** with a distinct `ResearchRunCapacityError` only on genuine capacity exhaustion. (Phase 1 of the multi-run hardening plan.)
+- **Browser leader `drain` / 503 handover** — when the elected leader loses leadership (election loss, idle timeout, or shutdown), it now enters a draining state that answers new requests with an explicit `503 { error: "draining" }` *before* closing the listener, instead of letting connected clients stall on a connect timeout or bare reset. The client classifies this as a transient "re-elect and retry" signal (logged at DEBUG, recorded under its own `draining` errorType for forensics) and it is deliberately excluded from the circuit breaker so a routine leadership handover never reads as an incident.
+
+### Fixed
+- **Citation rewriting regression — `[removed]` tokens, list/code corruption, `[0]` deletion** — the prior placeholder-citation defense rewrote synthesis bodies with a global space collapse that flattened nested lists and 4-space code blocks, deleted bracketed integers *inside* quoted code (`items[12]`), treated `[0]` as a citation, and emitted broken `[removed]` tokens for dropped citations. All replaced by a structure-preserving rewrite: fenced blocks and inline-code spans are skipped entirely, line-leading indentation is preserved, dangling markers are removed cleanly (never as a visible token), and `[N]` outside a plausible citation range (`1..200`) and `[0]` are left untouched.
+- **Provenance gate mass-dropping legitimate citations** — the gate that previously DROPPED citations tagged Scrape/Transcript when their URL was absent from the successful-scrape pool conflated a *blocked* scrape (real URL, content unretrieved) with fabrication: under the common high-scrape-failure rate (bot blocks on GitHub / Microsoft / etc.) it mass-deleted real citations. The gate is removed; every parsed citation is now kept (deduped by URL). Fabrication defense rests on URL dedup plus a new prose-URL sweep instead of punishing failed scrapes.
+- **Fabricated inline URLs in synthesis prose** — inline `https?://` tokens in the report body whose URL was not retrieved this session are now redacted to `[link removed: not found in retrieved sources]` (verified inline references are kept). A matching caveat block is appended when a model-written `CITED LINKS` section survives a run that retrieved nothing, so no report ships fully-sourced-looking with no warning on a zero-retrieval run.
+- **Fetch-layer scrape had no retry** — the fetch layer was the only scrape layer with no transient retry, so a single socket/DNS blip (ECONNRESET, ENOTFOUND, `UND_ERR_*`, a bare `fetch failed`) cost a full 10–30× slower browser render. It now retries once (250 ms, gated on `isTransientError`) before falling back to the stealth browser; SSRF rejections, size caps and 4xx rethrow immediately. Error tracking is recorded exactly once per URL (moved out of the retried layer) rather than once per attempt.
+- **Uninformative `fetch failed` scrape logs** — Node/undici wraps the real transport reason under `error.cause`; logging only `String(err)` recorded the uninformative top-level message and discarded it. A new `formatErrorWithCause` walks the cause chain (bounded, `.code`-folding, defensive) so every fetch-failure line is self-diagnosing; it is now used consistently across the scrape path.
+- **Final synthesis body never logged** — every other layer (researcher prompts/responses, searches, scrapes) was logged at DEBUG, but the synthesis itself — the actual bytes returned to the caller — was the one conspicuous exception, making post-hoc diagnosis of citation/output reports impossible. The full final and fallback synthesis bodies are now logged at DEBUG.
+- **`abortableDelay` could exit the process mid-operation** — the timer was unconditionally `unref`'d, so a foreground backoff that was the sole pending handle let Node drain the loop and silently truncate work. A `keepAlive` option (used by the new foreground fetch retry) holds the loop until the operation completes; background callers are unaffected.
+
+## [1.0.10] - 2026-07-30
+
+### Fixed
+- **pi 0.83.0 compatibility — `ResourceLoader` contract** — pi 0.83.0 extended the `ResourceLoader` contract with `getSystemPromptSource()` and `getAppendSystemPromptSources()` (consumed by interactive mode's startup context listing for file-backed `SYSTEM.md`/`APPEND_SYSTEM.md`). The in-memory sub-session loader now implements both, returning "no backing file" — accurate for prompts passed as text. The extra methods are harmless on pre-0.83 hosts, so the supported range stays `>=0.80.8 <1`. Audited the 0.82.1→0.83.0 dist diffs: the only other contract change (`ExtensionContext.scopedModels`) is provided by pi's own session code, and the mock runtime path has been immune since v1.0.9 via `createExtensionRuntime()`.
+
 ## [1.0.9] - 2026-07-28
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lincoln504/pi-research",
-  "version": "1.0.10",
+  "version": "1.0.12",
   "description": "A set of web research tools (search, scrape, and others) and research agent system that uses them safely and efficiently.",
   "type": "module",
   "private": false,
@@ -142,7 +142,10 @@
     "ua-parser-js": "^1.0.41",
     "protobufjs": "7.6.5",
     "vite": "^8.0.16",
-    "adm-zip": "^0.6.0"
+    "adm-zip": "^0.6.0",
+    "jsdom": {
+      "undici": "^7.29.0"
+    }
   },
   "devDependencies": {
     "@eslint/js": "^10.0.1",

package/skills/pi-research/SKILL.md

@@ -2,7 +2,7 @@
 name: pi-research
 description: "Multi-agent web research for any coding agent. Use for anything requiring current information from the internet — news, trends, product/service/company facts, statistics, people, places, events, APIs, library behavior, or 'what is X / how does X work' questions. Also use to search a local knowledge store of previously researched findings before doing live research. Powered by the pi-research engine (search, stealth scraping, security databases, Stack Exchange). Not for reading local files, running project commands, or analyzing this repository's own source."
 license: MIT
-metadata: { "author": "Lincoln Deen", "version": "1.0.10", "package": "@lincoln504/pi-research", "engine": "pi-research-sdk", "openclaw": { "requires": { "bins": ["node"] } } }
+metadata: { "author": "Lincoln Deen", "version": "1.0.12", "package": "@lincoln504/pi-research", "engine": "pi-research-sdk", "openclaw": { "requires": { "bins": ["node"] } } }
 allowed-tools: Bash(node:*)
 ---
 

package/src/core/interfaces/service-names.ts

@@ -31,6 +31,8 @@ export const ServiceNames = {
   // Research session services
   RESEARCH_SESSION_SERVICE: 'research-session-service',
   RESEARCH_SYNTHESIS_SERVICE: 'research-synthesis-service',
+  // Cross-process cap on concurrent research runs (Phase 1 run-cap)
+  RESEARCH_RUN_SEMAPHORE: 'research-run-semaphore',
 } as const;
 
 /**

package/src/infrastructure/browser/browser-client.ts

@@ -103,7 +103,25 @@ export class BrowserClient implements IScheduler {
                     const duration = Date.now() - start;
                     try {
                         const parsed = JSON.parse(body);
-                        if (res.statusCode !== 200) {
+                        if (res.statusCode === 503 && parsed?.error === 'draining') {
+                            // Planned leadership handover, not a fault. Distinct message so
+                            // isServerDrainingError can classify it: retry paths treat it as
+                            // transient and the circuit breaker ignores it. Logged at DEBUG,
+                            // not ERROR, so a routine re-election doesn't read as an incident.
+                            // It is still recorded in the error tracker (this file records every
+                            // non-200 uniformly) under its own `draining` errorType, which is
+                            // what keeps handovers distinguishable from real 503s in forensics.
+                            const error = new Error(
+                                `Browser pool leader is draining (${parsed.reason || 'leadership-lost'}) — re-elect and retry`,
+                            );
+                            logger.debug(`[BrowserClient] Leader draining on ${path}; re-election required.`);
+                            errorTracker.trackError(error, {
+                                component: 'browser-manager',
+                                operation,
+                                errorType: 'draining',
+                            });
+                            reject(error);
+                        } else if (res.statusCode !== 200) {
                             const error = new Error(parsed.error || `HTTP ${res.statusCode}`);
                             errorTracker.trackError(error, {
                                 component: 'browser-manager',

package/src/infrastructure/browser/browser-error-utils.ts

@@ -31,7 +31,11 @@ export function isTransientSocketError(error: unknown): boolean {
         // destroyed (e.g., during scheduler restart). Treat as transient — the pool will
         // be ready for new tasks once destruction completes and a new pool is initialized.
         err.message.includes('Cannot execute a task on destroying pool') ||
-        err.message.includes('destroying pool')
+        err.message.includes('destroying pool') ||
+        // The leader answered 503 because it is shutting down after losing
+        // leadership. Retrying re-elects and reaches the new leader, so this is
+        // transient in exactly the same sense as a pool drain.
+        err.message.includes('Browser pool leader is draining')
     );
 }
 
@@ -68,6 +72,22 @@ export function isTaskTimeoutError(error: unknown): boolean {
     );
 }
 
+/**
+ * Check if an error is a "leader is draining" rejection (HTTP 503 from
+ * {@link BrowserServer.beginDrain}).
+ *
+ * The leader answers 503 while tearing down after losing leadership, so this is
+ * an expected transition signal rather than a fault: the correct response is to
+ * re-elect and retry against the new leader. It must not count toward the
+ * circuit breaker — a leadership handover would otherwise look like a burst of
+ * infrastructure failures and open the breaker for every subsequent request.
+ */
+export function isServerDrainingError(error: unknown): boolean {
+    if (!error || typeof error !== 'object') return false;
+    const err = error as NodeError;
+    return typeof err.message === 'string' && err.message.includes('Browser pool leader is draining');
+}
+
 /**
  * Check if an error is specifically a pool-shutdown / pool-drain error.
  * For these errors the scheduler itself is fine — only the WorkerPool is temporarily
@@ -107,6 +127,9 @@ const DEFAULT_BREAKER_CONFIG: any = {
     isTransientError: (error: unknown) => {
         // Pool-drain transients: pool recovers on its own — don't count.
         if (isPoolShutdownError(error)) return false;
+        // Leadership handover (503 draining) is a planned transition, not a
+        // failure — counting it would open the breaker on every re-election.
+        if (isServerDrainingError(error)) return false;
         // Cloudflare blocks are content-layer rejections, not infra failures — don't count.
         if (isCloudflareBlockError(error)) return false;
         // Task-level timeouts (slow/unresponsive sites) are expected during parallel

package/src/infrastructure/browser/browser-server.ts

@@ -32,9 +32,57 @@ export function getBrowserServerAuthSecret(): string {
 export class BrowserServer {
     private server: http.Server | null = null;
     private port: number = 0;
+    /**
+     * Live client sockets. Tracked so teardown can tell whether anyone is still
+     * attached (`hasActiveClients`) rather than guessing, and so drain has a
+     * meaningful count to report.
+     */
+    private connections: Set<import('node:net').Socket> = new Set();
+    private draining = false;
+    /**
+     * Why this server stopped accepting work. Reported to the client so a log line
+     * says which teardown it hit — a lost election, an idle timeout, or process
+     * shutdown all reach the same code path but are very different incidents.
+     */
+    private drainReason = 'shutting-down';
 
     constructor(private options: BrowserServerOptions) {}
 
+    /**
+     * Enter draining mode: every *subsequent* request is answered `503` instead of
+     * being served or left to hit a closed socket. Requests already past this
+     * check run to completion, so drain never truncates in-flight work.
+     *
+     * This exists for leadership-loss teardown. Without it a client that is
+     * mid-conversation with a leader that just lost the election waits out a
+     * connect timeout or gets a bare ECONNREFUSED/RST once the listener closes,
+     * and only then re-elects. An explicit 503 turns that silent stall into an
+     * immediate, unambiguous "this leader is gone — re-elect now".
+     *
+     * Idempotent: calling it while already draining is a no-op.
+     */
+    beginDrain(reason = 'shutting-down'): void {
+        if (this.draining) return;
+        this.draining = true;
+        this.drainReason = reason;
+        logger.log(`[BrowserServer] Draining (${reason}) — refusing new requests with 503 (${this.connections.size} client connection(s) attached).`);
+    }
+
+    /** True once {@link beginDrain} has been called. */
+    isDraining(): boolean {
+        return this.draining;
+    }
+
+    /** Whether any client socket is currently attached. */
+    hasActiveClients(): boolean {
+        return this.connections.size > 0;
+    }
+
+    /** Number of attached client sockets (observability / teardown decisions). */
+    getConnectionCount(): number {
+        return this.connections.size;
+    }
+
     async start(): Promise<number> {
         return new Promise((resolve, reject) => {
             this.server = http.createServer(async (req, res) => {
@@ -49,6 +97,20 @@ export class BrowserServer {
                     return;
                 }
 
+                // Checked after auth so an unauthenticated caller cannot probe
+                // leadership state, and before routing so no new work is started
+                // against a pool that is being torn down. `Connection: close`
+                // stops the client reusing this socket for a retry that would
+                // only 503 again.
+                if (this.draining) {
+                    res.writeHead(503, {
+                        'Content-Type': 'application/json',
+                        'Connection': 'close',
+                    });
+                    res.end(JSON.stringify({ error: 'draining', reason: this.drainReason }));
+                    return;
+                }
+
                 if (req.method !== 'POST') {
                     res.writeHead(405);
                     res.end('Method Not Allowed');
@@ -138,6 +200,13 @@ export class BrowserServer {
                 });
             });
 
+            this.server.on('connection', (socket) => {
+                this.connections.add(socket);
+                socket.on('close', () => {
+                    this.connections.delete(socket);
+                });
+            });
+
             this.server.listen(0, '127.0.0.1', () => {
                 const addr = this.server?.address();
                 if (addr && typeof addr === 'object') {
@@ -162,6 +231,7 @@ export class BrowserServer {
             return new Promise((resolve) => {
                 this.server?.close(() => {
                     this.server = null;
+                    this.connections.clear();
                     resolve();
                 });
             });

package/src/infrastructure/browser/browser-task-scheduler.ts

@@ -108,7 +108,7 @@ export class BrowserTaskScheduler implements IScheduler {
                     if (this.consecutiveLeadershipMisses >= this.LEADERSHIP_MISS_THRESHOLD) {
                         metrics.increment('browser_leadership_lost_total', 1);
                         logger.error(`[Scheduler] Leadership threshold exceeded (${this.consecutiveLeadershipMisses} misses), shutting down pool...`);
-                        await this.shutdown();
+                        await this.shutdown('leadership-lost');
                         return;
                     }
                 } else {
@@ -145,7 +145,7 @@ export class BrowserTaskScheduler implements IScheduler {
             // getService throwing during a concurrent container disposal) would otherwise surface
             // as an unhandledRejection from this fire-and-forget timer. Swallow it — an idle
             // teardown that fails is non-fatal; the next run gets a fresh scheduler regardless.
-            this.shutdown().catch(err => logger.warn('[Scheduler] Idle-timeout shutdown failed (non-fatal):', err));
+            this.shutdown('idle-timeout').catch(err => logger.warn('[Scheduler] Idle-timeout shutdown failed (non-fatal):', err));
         }, this.IDLE_TIMEOUT_MS);
         if (this.idleTimer.unref) this.idleTimer.unref();
     }
@@ -374,10 +374,26 @@ export class BrowserTaskScheduler implements IScheduler {
         return result;
     }
 
-    async shutdown() {
+    /**
+     * @param reason why the pool is going away. Reported verbatim to clients in the
+     *   drain 503, so a lost election, an idle timeout and a process shutdown are
+     *   distinguishable in a client-side log rather than all reading as one.
+     */
+    async shutdown(reason = 'shutting-down') {
         if (this.isShuttingDown) return;
         this.isShuttingDown = true;
 
+        // Start draining before any of the teardown below. Clearing state and
+        // stopping the pool involves awaits, and until the listener actually
+        // closes a connected client would otherwise keep issuing requests against
+        // a pool that is already going away — the leadership-loss case this
+        // guards. Draining first turns those into an immediate 503 so the client
+        // re-elects at once instead of waiting for a reset.
+        if (this.server?.hasActiveClients()) {
+            logger.log(`[Scheduler] Draining ${this.server.getConnectionCount()} client connection(s) before shutdown (${reason}).`);
+        }
+        this.server?.beginDrain(reason);
+
         if (this.idleTimer) {
             clearTimeout(this.idleTimer);
             this.idleTimer = null;

package/src/infrastructure/browser/scheduler-factory.ts

@@ -139,7 +139,7 @@ export async function forceSchedulerRestart(forceClearRemoteState: boolean = fal
 
         if (oldScheduler && 'schedulerId' in oldScheduler && oldScheduler.schedulerId) {
             if (oldScheduler instanceof BrowserTaskScheduler) {
-                const shutdownPromise: Promise<void> = oldScheduler.shutdown().catch((err: unknown) => {
+                const shutdownPromise: Promise<void> = oldScheduler.shutdown('leadership-lost').catch((err: unknown) => {
                     logger.warn('[Scheduler] Error during old scheduler shutdown after restart:', err);
                 });
                 schedulerService.setPendingShutdownPromise(shutdownPromise);

package/src/infrastructure/browser/thread-worker.mjs

@@ -1356,7 +1356,10 @@ function isTransientSocketError(error) {
   err.message.includes("Worker pool is shutting down") || // Poolifier throws this when pool.execute() is called while the pool is being
   // destroyed (e.g., during scheduler restart). Treat as transient — the pool will
   // be ready for new tasks once destruction completes and a new pool is initialized.
-  err.message.includes("Cannot execute a task on destroying pool") || err.message.includes("destroying pool"));
+  err.message.includes("Cannot execute a task on destroying pool") || err.message.includes("destroying pool") || // The leader answered 503 because it is shutting down after losing
+  // leadership. Retrying re-elects and reaches the new leader, so this is
+  // transient in exactly the same sense as a pool drain.
+  err.message.includes("Browser pool leader is draining"));
 }
 function isCloudflareBlockError(error) {
   if (!error || typeof error !== "object") return false;
@@ -1368,6 +1371,11 @@ function isTaskTimeoutError(error) {
   const err = error;
   return typeof err.message === "string" && (err.message.includes("timed out after") || err.message.includes("Search task timed out") || err.message.includes("Scrape task timed out") || err.message.includes("Health check timed out") || err.message.includes("[BrowserClient] Request to"));
 }
+function isServerDrainingError(error) {
+  if (!error || typeof error !== "object") return false;
+  const err = error;
+  return typeof err.message === "string" && err.message.includes("Browser pool leader is draining");
+}
 function isPoolShutdownError(error) {
   if (!error || typeof error !== "object") return false;
   const err = error;
@@ -1389,6 +1397,7 @@ var init_browser_error_utils = __esm({
       name: "BrowserPool",
       isTransientError: (error) => {
         if (isPoolShutdownError(error)) return false;
+        if (isServerDrainingError(error)) return false;
         if (isCloudflareBlockError(error)) return false;
         if (isTaskTimeoutError(error)) return false;
         return isTransientSocketError(error);
@@ -1404,6 +1413,7 @@ __export(scraper_utils_exports, {
   createJsMarkdownConverter: () => createJsMarkdownConverter,
   createNativeMarkdownConverter: () => createNativeMarkdownConverter,
   extractDomain: () => extractDomain,
+  formatErrorWithCause: () => formatErrorWithCause,
   getRandomUserAgent: () => getRandomUserAgent,
   getSsrfSafeDispatcher: () => getSsrfSafeDispatcher,
   isBenignScrapeFailure: () => isBenignScrapeFailure,
@@ -1535,6 +1545,34 @@ async function getSsrfSafeDispatcher() {
   }
   return cachedSsrfDispatcher;
 }
+function formatErrorWithCause(err) {
+  try {
+    const parts = [];
+    let current = err;
+    for (let depth = 0; current !== null && current !== void 0 && depth < 5; depth++) {
+      let segment;
+      if (current instanceof Error) {
+        segment = current.message || current.name;
+        const code = current.code;
+        if (typeof code === "string" && code && !segment.includes(code)) {
+          segment = `${segment} [${code}]`;
+        }
+      } else if (typeof current === "string") {
+        segment = current;
+      } else {
+        segment = String(current);
+      }
+      if (segment && !parts.includes(segment)) parts.push(segment);
+      const next = current.cause;
+      if (next === current) break;
+      current = next;
+    }
+    if (parts.length === 0) return String(err);
+    return parts.length === 1 ? parts[0] : parts.join(" \u2190 ");
+  } catch {
+    return String(err);
+  }
+}
 function isPrivateIp(ip) {
   const parts = ip.split(".").map(Number);
   if (parts.length !== 4 || parts.some((p) => isNaN(p))) return false;

package/src/infrastructure/process-lifecycle-service.ts

@@ -119,9 +119,27 @@ export class ProcessLifecycleService implements IProcessLifecycle {
       if (expectedStartTime !== undefined && expectedStartTime !== null) {
         const actualStartTime = await this.getProcessStartTime(pid);
         if (actualStartTime === null) {
-          // If we can't get start time but expected it, we can't be sure it's the same process
-          // On Linux this usually means the process just exited between the signal and the read.
-          return false;
+          // signal(0) above confirmed a live process at this PID, but we couldn't
+          // resolve its start time to verify it's the SAME instance (the PID-reuse
+          // guard). The two failure modes collapse to the same null here but must
+          // NOT be treated identically:
+          //   • Linux: usually the process exited in the microsecond gap between
+          //     signal(0) and the /proc/{pid}/stat read → genuinely dead.
+          //   • Windows/macOS: far more often the start-time lookup subprocess
+          //     (powershell `Get-Process` / `ps`) simply failed or hit its timeout
+          //     while the process is still very much alive → NOT dead.
+          // Reporting that confirmed-alive PID as DEAD is catastrophic for every
+          // caller — a live lock/leader/run-cap owner is reclaimed from under it
+          // → two writers collide (lost update) or the run-cap admits extra
+          // concurrent runs (the flaky duplicate-slot/cap-breach we saw on Windows
+          // CI). So re-confirm liveness instead of guessing: if signal(0) STILL
+          // succeeds the process is alive → return true; if it now throws it died
+          // between the two probes and the outer catch returns false. A genuine
+          // death is therefore still detected within one poll tick (~100ms); the
+          // only behavioural change is that a confirmed-alive PID is never again
+          // misreported as dead on a transient start-time lookup failure.
+          process.kill(pid, 0); // re-confirm; a throw (process died) → outer catch → false
+          return true;
         }
         // Allow ±1s slack. The macOS/BSD fallback derives start time as
         // floor(Date.now()/1000) - `ps etimes` (elapsed whole seconds); both terms are