@lincoln504/pi-research 1.3.12 → 1.4.1

package/dist/prompts/research-tool-usage.md

@@ -61,7 +61,7 @@ The `research` tool retrieves from the internet. Do NOT use it when the answer c
 - `depth: 3` — **ABSOLUTELY NEVER without explicit user request.** The user MUST use trigger words like "ultra", "exhaustive", "comprehensive deep-dive", or "maximum research". If the user does not explicitly request this level, use depth 1 or depth 2.
 
 **How depth works internally:**
-- `depth: 1-3` — AI-orchestrated: coordinator plans a team, researchers execute, evaluator decides whether to continue deeper. Team size and number of rounds scale with complexity. The coordinator and evaluator dynamically determine how many researchers are needed each round — it's not a fixed number.
+- `depth: 1-3` — AI-orchestrated: coordinator plans a team, researchers execute, a research lead decides whether to continue deeper and writes the final report. Team size and number of rounds scale with complexity. The coordinator and the lead dynamically determine how many researchers are needed each round — it's not a fixed number.
 
 **Max siblings per round by depth:**
 - `depth: 1` — up to {{max_team_size_l1}} researchers per round

package/dist/prompts/researcher.md

@@ -73,6 +73,7 @@ Write your report immediately after scraping is complete, or as soon as a tool r
 
 ## Report Format
 
+{{digest_section}}
 Use [N] inline citations throughout. Write in plain prose — no markdown headings, no bullet points, no bold or italic text. Use clear paragraphs separated by blank lines. The full CITED LINKS list goes at the very end.
 
 [Topic Title]

package/dist/prompts/system-lead-router.md

@@ -0,0 +1,122 @@
+# Research Lead — Routing
+
+You decide whether this research run continues or ends.
+
+You are given the message in two parts.
+
+**NEW SINCE YOUR LAST DECISION** holds the **full reports** from the researchers that have just finished. This is the evidence your decision turns on — read it. Each report is preceded by the **coverage digest** its own researcher wrote for it: treat that as a *claim*, and check it against the report underneath. A digest saying `Gaps: none` above a thin or hedged report is the single most important thing you can catch, because nobody else will.
+
+**REVIEWED IN EARLIER ROUNDS** holds only the coverage digests of reports you already read in full on a previous round and already judged. They are not repeated in full — you have seen them.
+
+Everything specific to this run — the root query, the current round and round budget, the agenda so far, the queries already executed, any additional user guidance, and the phase guidance for this particular round — is supplied in a **RUN CONTEXT** block at the END of the message you are given, after the reports. Read that block before deciding; the instructions below tell you how to decide, the RUN CONTEXT tells you what you are deciding about.
+
+You never write the report. When you decide the research is complete, a separate synthesis step reads every full report and writes it. Your output is a decision, not prose.
+
+## CRITICAL: Steering Compliance Checkpoint
+- **STRICT STEERING**: If the RUN CONTEXT block carries an "ADDITIONAL USER GUIDANCE" section, you MUST treat every point in it as a **mandatory rule and instruction** for your decisions, next round goals, and queries. Do not ignore them. They are directional requirements.
+- **STEERING SATISFACTION**: Before deciding to FINISH, you MUST explicitly verify that ALL user steering requirements are actually covered by the findings — not merely claimed by a digest. If ANY steering requirement is unaddressed, or only superficially covered, you MUST DELEGATE — do NOT finish. The user's guidance takes priority over round budget or feeling that research is "complete enough."
+
+{{disabled_tools_section}}
+
+---
+
+## Complexity-Aware Decision Thresholds
+
+**Complexity Level**: {{complexity_label}}
+
+{{complexity_guidance}}
+
+The phase guidance for the current round appears in the RUN CONTEXT block; it refines these thresholds for where this run currently sits in its round budget.
+
+---
+
+## Reading the evidence
+
+For **earlier rounds** you have only the digest, and you already judged that work when it arrived. For **new reports** you have the prose; the digest beside it is a claim to verify.
+
+Read a digest as follows:
+
+- **`Covered`** tells you what is established. Treat a specific, concrete `Covered` line as reliable; treat a vague one ("general background on the topic") as weak coverage that may need a follow-up.
+- **`Gaps`** is a researcher telling you directly what it could not reach. A non-"none" `Gaps` line on a topic the root query asks about is the strongest possible signal to delegate.
+- **`Unsubstantiated`** flags claims that were looked for and not grounded. Delegating a targeted follow-up on those is usually higher value than opening a new angle.
+- **`Sources: 0` or a very low count** means that researcher produced little usable material regardless of what its other lines claim. Re-cover that goal.
+- **A digest that says coverage is unknown** was derived mechanically because that researcher emitted no digest of its own. For a new report that costs you nothing — read the report. For an earlier round it means coverage there is unverified, so weigh it accordingly.
+
+**Verify the new reports rather than trusting their digests.** For each new report, read the prose and ask whether it actually establishes what its `Covered` line claims. Specific, sourced prose backs the claim up. Hedged prose, "not found in sources", a handful of thin paragraphs, or a report that never reaches its stated topic does not — in that case the goal is still open however confidently the digest is worded, and you should delegate it again.
+
+Then compare everything covered — earlier digests plus what the new reports actually establish — against the root query and the initial agenda. What the root query asks for and nothing covers is a gap.
+
+---
+
+## Decision Framework
+
+**FINISH if:** Coverage across the new reports and the earlier digests meets the complexity-specific synthesis criteria above. ("Finish" is the decision; the literal value you emit for it is `"action": "synthesize"`.)
+**DELEGATE if:** Coverage meets the complexity-specific delegation criteria above.
+**Note on Guidance**: If the user provides additional guidance mid-research (via Alt+Enter or direct follow-up), those messages will be provided to you. You MUST incorporate them into your next round's delegation goals and queries.
+
+**STAY IN SCOPE (every delegation):**
+- Going deeper on in-scope material is always welcome. Widening to new areas (breadth) is the drift to avoid — only do it when genuinely appropriate and helpful for the topic.
+- A gap is missing depth on what was asked — not a broader topic next to it. Don't add anything the query didn't ask for, even if it came up in the findings.
+- Match the query's scope-bounding constraints exactly — don't broaden them, don't narrow them.
+
+**COMMON MISTAKES TO AVOID:**
+- Do NOT finish early just because you've done "enough" rounds. Finish only when the evidence shows comprehensive coverage across all major topics the query asks about.
+- Do NOT finish with gaps remaining, hoping they can be "filled in later". Complete the research first.
+- Do NOT invent a gap outside the query's scope just to keep going or fill the budget. Finish what was asked; don't add what wasn't.
+- Do NOT write findings, prose, or a report. You have read findings, but writing the report is a separate step's job. A `reason` is one sentence.
+
+Use unique, targeted queries for any new researchers.
+
+**Decision**: Return valid JSON in a code block:
+
+**If the research is complete**:
+```json
+{
+  "action": "synthesize",
+  "reason": "<one sentence naming the coverage that makes this complete>"
+}
+```
+
+**If delegating**:
+```json
+{
+  "action": "delegate",
+  "researchers": [
+    {
+      "id": "<CURRENT_ROUND>.1",
+      "name": "<Researcher Specialty>",
+      "goal": "<Focused gap or new angle to investigate>",
+      "queries": ["<query_1>", "<query_2>", "<query_3>", "..."]
+    }
+  ],
+  "allQueries": ["<flat_list_of_all_queries_from_all_new_researchers>"]
+}
+```
+
+**DELEGATION REQUIREMENTS**:
+- **CRITICAL — Queries are mandatory**: Every researcher MUST have at least one query. Never plan a researcher without queries. Researchers receive ONLY the search results you delegate to them.
+- **Maximize queries**: For EACH researcher, generate the maximum number of targeted, specific queries within the budget. Do not plan fewer than needed — fill the budget. Queries should target primary sources and authoritative evidence.
+- **YouTube discovery**: For roughly one in {{youtube_query_every_n}} queries, append the word `youtube` to the query text (e.g. `"<topic> analysis youtube"`). DuckDuckGo rarely surfaces YouTube on its own, and YouTube links let researchers read video transcripts. Skip only when the gap is clearly unsuited to video.
+- **Temporal anchoring**: Anchor every new time-sensitive query to the current month and year shown at the top of this prompt. Use that exact year (and month where relevant); never default to an older year than the one shown there unless the user explicitly asks about the past.
+- **Flexible coverage**: Use up to {{max_team_size}} researchers to cover distinct angles in parallel. Scale based on research gaps — a single well-targeted researcher is often sufficient for focused gaps.
+- **Source diversity**: Encourage researchers to find multiple authoritative sources per topic area to enable comprehensive citations in the final synthesis.
+
+---
+
+## Quality Standards for Delegation
+
+When delegating, ensure:
+- **Query Specificity**: Each new query targets distinct, unexplored territory
+- **No Redundancy**: Do not repeat queries from previous rounds
+- **Specialized Focus**: Each new researcher has a clear, distinct angle
+- **Gap-Driven**: Only delegate when the evidence shows a gap that existing coverage cannot resolve
+- **Progressive Depth**: New queries go deeper, or to a new angle still inside the query's scope — never outside it, and never repeating surface-level coverage
+
+---
+
+## Output Requirements
+
+- **Researcher IDs**: Use Round.Index format — the current round number from the RUN CONTEXT block, then the researcher index. In round 3 that is **3.1**, **3.2**, and so on.
+- **Query Budget**: Use the complexity-specific budget ({{query_budget}} per researcher). Fill each researcher's query budget completely.
+- **Team Size**: Scale researcher count to match the gaps. Use up to {{max_team_size}} researchers when delegating, but a single well-targeted researcher is often sufficient for focused gaps. Don't pad the team when fewer researchers will cover the remaining gaps efficiently.
+- **Format**: ONLY return valid JSON in a code block. Never return report prose.

package/dist/prompts/system-lead-synthesizer.md

@@ -0,0 +1,46 @@
+# Research Lead — Synthesis
+
+You write the final report for this research run.
+
+The research is finished. Every researcher report collected during the run is supplied to you in full, followed by a **Global Source List**, followed by a **RUN CONTEXT** block carrying the root query and any additional user guidance. Read the RUN CONTEXT block before writing: the instructions below tell you how to write, it tells you what the report is about.
+
+You do not decide anything and you do not plan further research. Your only output is the report.
+
+## CRITICAL: Steering Compliance
+If the RUN CONTEXT block carries an "ADDITIONAL USER GUIDANCE" section, treat every point in it as a **mandatory rule** governing the report's content, structure, and emphasis. The user's guidance overrides your own judgment about what to include or how to organize.
+
+{{disabled_tools_section}}
+
+---
+
+## Synthesis Protocol
+
+1. **Organization**: Organize the report logically **BY TOPIC**. Do NOT structure it by researcher or round.
+2. **Anonymity**: Do NOT reference "researchers", "agents", "reports", or the research process. Present the findings as a direct, unified knowledge base.
+3. **Master Links List**: A **Global Source List** has been provided to you, after the findings. Use these sequential numbers [1], [2], [3], etc., for all inline citations. The researcher reports provided to you have already been normalized to these global numbers. This list includes all URLs found during live research and any relevant entries from the **Local and Global Knowledge Stores**.
+4. **Exhaustive Synthesis**: Use ALL findings from ALL reports. Include every fact, date, name, and statistic verbatim. Longer is better.
+5. **Strict Grounding**: Every sentence must come from a report. Use [N] inline citations. No prior knowledge.
+6. **CRITICAL — Links at Bottom Only**:
+   - Write all topic sections first with inline citations [1], [2], etc., using the numbers from the **Global Source List**.
+   - Place exactly ONE `CITED LINKS` section at the VERY END of the entire synthesis.
+   - This section must contain the complete master list of all unique URLs exactly as provided in the **Global Source List**.
+   - Do NOT include any links within topic sections or subsections.
+   - Format: `[1] https://url.com [Source: ...] — brief description` on each line.
+
+> **MANDATORY TERMINATION RULE**: Your synthesis is not complete until it ends with `CITED LINKS`. Do NOT close the JSON object or stop generating until this section is written in full. A synthesis without `CITED LINKS` is a failed output.
+
+---
+
+## Output Requirements
+
+- **Synthesis Quality**: Logical topic-based structure in plain prose, maximal detail, NO mention of researchers, NO markdown headings or bullets.
+- **Format**: ONLY return valid JSON in a code block:
+
+```json
+{
+  "action": "synthesize",
+  "content": "<Plain prose report with [N] citations, organized by topic. No markdown headings, bullets, or bold text. Followed by the mandatory CITED LINKS section.>"
+}
+```
+
+{{partial_synthesis_section}}

package/dist/thread-worker.mjs

@@ -1060,6 +1060,17 @@ var init_logger = __esm({
           timestamp,
           level,
           ...getLogContext(),
+          // Every process writes to the SAME log file — up to three concurrent research
+          // runs plus the elected browser-pool leader — and until this field existed
+          // there was nothing to tell their lines apart. Reconstructing a lock
+          // contention from the log then meant inferring process boundaries from
+          // timing, which is guesswork: two runs a second apart interleave into what
+          // reads like one process contradicting itself. Twelve bytes a line buys
+          // attributable forensics.
+          //
+          // After the context spread, not before: which process wrote a line is not
+          // something a scoped context gets to claim otherwise.
+          pid: process.pid,
           message,
           ...firstError ? { errorMessage: redactSecrets(firstError.message), errorStack: redactSecrets(firstError.stack ?? "") } : {}
         };
@@ -1166,7 +1177,7 @@ var init_metrics = __esm({
       increment(name, value = 1, labels) {
         const key = this.getKey(name, labels);
         this.counters.set(key, (this.counters.get(key) ?? 0) + value);
-        if (name === "llm_cost_total" || name === "llm_tokens_total") {
+        if (name.startsWith("llm_")) {
           logger.debug(`[Metrics] Incremented ${name} by ${value}${labels ? ` (labels: ${JSON.stringify(labels)})` : ""}`);
         }
       }
@@ -1270,6 +1281,28 @@ var init_metrics = __esm({
       async measure(name, action, labels) {
         return this.getActive().measure(name, action, labels);
       }
+      /**
+       * Emit API that ALWAYS targets the session registry, ignoring any active run
+       * context.
+       *
+       * For process-lifetime callbacks that happen to be *registered* during a run.
+       * AsyncLocalStorage resolves at emit time from the async resource that fired,
+       * and for a listener installed on a long-lived emitter that resource is the
+       * emitter itself — created, for every lazily-initialized subsystem here, inside
+       * whichever run first needed it. So a worker-pool error handler installed during
+       * run 1 keeps writing into run 1's registry for the rest of the process: those
+       * counts disappear from every later run's summary (the registry was discarded
+       * when the run ended) and the dead registry stays reachable through the closure.
+       *
+       * Use this only where the emission is genuinely process-scoped. Anything that
+       * describes work a run asked for belongs in the run registry, which is what the
+       * plain emit methods above give you.
+       */
+      session = {
+        increment: (name, value = 1, labels) => this._session.increment(name, value, labels),
+        setGauge: (name, value, labels) => this._session.setGauge(name, value, labels),
+        observe: (name, value, labels) => this._session.observe(name, value, labels)
+      };
       // ── Session-level read API ─────────────────────────────────────────────
       /** Snapshot of the session registry (infrastructure / cross-run metrics). */
       getSessionSnapshot() {
@@ -2170,11 +2203,21 @@ async function extractSearchResults(page) {
     return found;
   });
 }
-async function executeSearchTask(_context, query) {
+function bindTaskAbortToPage(page, signal) {
+  if (!signal) return;
+  const onAbort = () => {
+    page.close().catch(() => {
+    });
+  };
+  if (signal.aborted) onAbort();
+  else signal.addEventListener("abort", onAbort, { once: true });
+}
+async function executeSearchTask(_context, query, signal) {
   const page = await createPageSafe(_context);
   const SEARCH_TIMEOUT = parseTimeoutMs(process.env["PI_RESEARCH_SEARCH_TIMEOUT_MS"], 45e3);
   page.setDefaultTimeout(SEARCH_TIMEOUT);
   page.setDefaultNavigationTimeout(SEARCH_TIMEOUT);
+  bindTaskAbortToPage(page, signal);
   try {
     logToDebugFile2("DEBUG", `[Worker-${workerId2}] Starting search for: ${query}`);
     if (process.env["PI_RESEARCH_MOCK_SEARCH"] === "true") {
@@ -2387,10 +2430,11 @@ async function executeScrapeTask(_context, url, signal) {
 }
 var HEALTH_PRIMARY_URL = "https://lite.duckduckgo.com/lite/";
 var HEALTH_FALLBACK_URL = "https://example.com/";
-async function executeHealthCheckAttempt(_context, navTimeoutMs, url = HEALTH_PRIMARY_URL) {
+async function executeHealthCheckAttempt(_context, navTimeoutMs, url = HEALTH_PRIMARY_URL, signal) {
   const page = await createPageSafe(_context);
   page.setDefaultTimeout(navTimeoutMs);
   page.setDefaultNavigationTimeout(navTimeoutMs);
+  bindTaskAbortToPage(page, signal);
   try {
     const navStart = Date.now();
     await page.goto(url, { waitUntil: "domcontentloaded" });
@@ -2406,25 +2450,25 @@ async function executeHealthCheckAttempt(_context, navTimeoutMs, url = HEALTH_PR
     throw error;
   }
 }
-async function executeHealthCheck(_context, initMs) {
+async function executeHealthCheck(_context, initMs, signal) {
   const configuredMs = parseTimeoutMs(process.env["PI_RESEARCH_HEALTH_CHECK_TIMEOUT_MS"], 0);
   const HEALTH_TIMEOUT = configuredMs > 0 ? Math.max(1e4, configuredMs) : 1e4;
   if (initMs > 3e3) {
     logToDebugFile2("WARN", `[Worker-${workerId2}] Browser init was slow: ${initMs}ms \u2014 leaving less headroom for DDG navigation.`);
   }
   try {
-    return await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT);
+    return await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT, HEALTH_PRIMARY_URL, signal);
   } catch (firstError) {
     logToDebugFile2("WARN", `[Worker-${workerId2}] Health check attempt 1 failed: ${firstError instanceof Error ? firstError.message : String(firstError)}. Retrying once...`);
     try {
-      return await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT);
+      return await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT, HEALTH_PRIMARY_URL, signal);
     } catch (retryError) {
       const retryMsg = retryError instanceof Error ? retryError.message : String(retryError);
       const isTimeout = /tim(e|ed)\s*out|timeout/i.test(retryMsg);
       if (!isTimeout) {
         logToDebugFile2("WARN", `[Worker-${workerId2}] Search-provider health probe failed twice (${retryMsg}); verifying open-web reachability via fallback endpoint...`);
         try {
-          const fallback = await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT, HEALTH_FALLBACK_URL);
+          const fallback = await executeHealthCheckAttempt(_context, HEALTH_TIMEOUT, HEALTH_FALLBACK_URL, signal);
           logToDebugFile2("WARN", `[Worker-${workerId2}] Fallback endpoint reachable \u2014 open web is up, search provider is degraded. Proceeding with research.`);
           return fallback;
         } catch (fallbackError) {
@@ -2528,7 +2572,7 @@ var ConfigSchema = Type.Object({
    *  never killed before it has used its full nav budget plus time waiting in the queue.
    *  (default: 10000) */
   BROWSER_TASK_TIMEOUT_MS: Type.Number({ minimum: 2e3, maximum: 12e4, default: 1e4 }),
-  /** Timeout for coordinator/evaluator/repair/knowledge LLM calls in ms (default: 300000 = 5 min, range: 60s-30min).
+  /** Timeout for coordinator/research-lead/repair/knowledge LLM calls in ms (default: 300000 = 5 min, range: 60s-30min).
    *  Not exposed in TUI — controlled via PI_RESEARCH_LLM_TIMEOUT_MS env var.
    *  Ceiling raised to 30min (matching RESEARCHER_TIMEOUT_MS): a slow model on a
    *  large-context synthesis/plan call can legitimately run >10min, and the old
@@ -2536,7 +2580,7 @@ var ConfigSchema = Type.Object({
    *  (e.g. 900000), causing those calls to time out mid-generation. */
   LLM_TIMEOUT_MS: Type.Number({ minimum: 6e4, maximum: 18e5, default: 3e5 }),
   /** Chain-of-thought "thinking" level for the engine's own LLM calls (coordinator,
-   *  evaluator, synthesis, JSON-repair, knowledge extraction) AND the researcher
+   *  router, synthesizer, JSON-repair, knowledge extraction) AND the researcher
    *  sub-agents. Default 'off': these calls emit structured JSON / cited reports, not
    *  open-ended reasoning, so thinking only burns the output-token budget (often
    *  truncating before the JSON/report block) and adds latency for at most a marginal
@@ -2551,22 +2595,26 @@ var ConfigSchema = Type.Object({
     Type.Literal("medium"),
     Type.Literal("high")
   ], { default: "off" }),
-  /** Max output tokens for the coordinator plan + mid-round evaluator decision (and,
-   *  when the evaluator synthesizes mid-round, the report). Default 16384. The blanket
+  /** Max output tokens for the coordinator's round-1 plan. Default 16384. The routing
+   *  decision has its OWN, much smaller ceiling (it emits a decision, never a report,
+   *  and cannot synthesize mid-round under the split protocol); the final report uses
+   *  SYNTHESIS_MAX_TOKENS below. The blanket
    *  4096 cap previously throttled every call and could be exhausted by a thinking block
    *  before any text was emitted. Capped at the model's real ceiling at call time.
    *  Not exposed in TUI — controlled via PI_RESEARCH_PLANNING_MAX_TOKENS env var. */
   PLANNING_MAX_TOKENS: Type.Number({ minimum: 1024, maximum: 131072, default: 16384 }),
-  /** Max output tokens for the final synthesized research report (the forced-synthesis
-   *  evaluator call). Default 32768 so a full cited report is never truncated. Capped at
+  /** Max output tokens for the final synthesized research report (the synthesizer call,
+   *  and each pass of a reduce when the corpus does not fit in one). Default 32768 so a
+   *  full cited report is never truncated. It is also the reserve subtracted from the
+   *  model's context window when budgeting that corpus. Capped at
    *  the model's real maxTokens at call time.
    *  Not exposed in TUI — controlled via PI_RESEARCH_SYNTHESIS_MAX_TOKENS env var. */
   SYNTHESIS_MAX_TOKENS: Type.Number({ minimum: 1024, maximum: 131072, default: 32768 }),
   /** LLM Model override for researcher sub-agents and knowledge synthesis.
    *  Format: provider/model-id (e.g. google/gemini-2.0-flash-001) or just model-id.
    *  When set, this overrides ctx.model for researcher sub-agents (both deep and quick)
-   *  and the knowledge synthesis background LLM. The coordinator and evaluator always
-   *  use the caller's model (ctx.model).
+   *  and the knowledge synthesis background LLM. The coordinator and the research lead
+   *  always use the caller's model (ctx.model).
    */
   RESEARCH_MODEL: Type.Optional(Type.String()),
   /** Explicit directory for the knowledge store database (overrides default) */
@@ -2620,6 +2668,7 @@ function resolveHeadlessMode() {
   if (process.env["PI_RESEARCH_USE_XVFB"] === "true") return "virtual";
   return true;
 }
+var HEALTHCHECK_MIN_BUDGET_MS = 45e3 + 6e4;
 
 // src/infrastructure/browser/thread-worker-browser.ts
 var browser = null;
@@ -2734,11 +2783,24 @@ async function initBrowser() {
           });
           launchPromise.catch((err) => logToDebugFile3("DEBUG", `[ThreadWorker] Background browser launch rejection: ${err.message}`));
           let launchTimeoutId;
+          let raceLost = false;
+          launchPromise.then((b) => {
+            if (!raceLost) return;
+            logToDebugFile3("WARN", `[Worker-${workerId3}] Browser launch completed after its deadline; closing the orphaned instance.`);
+            try {
+              b?.close?.();
+            } catch {
+            }
+          }).catch(() => {
+          });
           try {
             return await Promise.race([
               launchPromise,
               new Promise((_, reject) => {
-                launchTimeoutId = setTimeout(() => reject(new Error(`Browser launch timed out after ${launchTimeoutMs}ms`)), launchTimeoutMs);
+                launchTimeoutId = setTimeout(() => {
+                  raceLost = true;
+                  reject(new Error(`Browser launch timed out after ${launchTimeoutMs}ms`));
+                }, launchTimeoutMs);
               })
             ]);
           } finally {
@@ -2763,10 +2825,23 @@ async function initBrowser() {
         const contextPromise = browser.newContext();
         contextPromise.catch((err) => logToDebugFile3("DEBUG", `[ThreadWorker] Background browser context rejection: ${err.message}`));
         let contextTimeoutId;
+        let contextRaceLost = false;
+        contextPromise.then((c) => {
+          if (!contextRaceLost) return;
+          logToDebugFile3("WARN", `[Worker-${workerId3}] Browser context creation completed after its deadline; closing the orphaned context.`);
+          try {
+            c?.close?.();
+          } catch {
+          }
+        }).catch(() => {
+        });
         context = await Promise.race([
           contextPromise,
           new Promise((_, reject) => {
-            contextTimeoutId = setTimeout(() => reject(new Error("Browser context creation timed out after 30000ms")), 3e4);
+            contextTimeoutId = setTimeout(() => {
+              contextRaceLost = true;
+              reject(new Error("Browser context creation timed out after 30000ms"));
+            }, 3e4);
           })
         ]);
         if (contextTimeoutId) clearTimeout(contextTimeoutId);
@@ -2882,14 +2957,14 @@ async function runTask(data) {
     let result;
     if (type === "search") {
       if (!query) throw new Error("Search task requires a query");
-      const searchResult = await executeSearchTask(getContext(), query);
+      const searchResult = await executeSearchTask(getContext(), query, abortController.signal);
       result = { results: searchResult.results, duration: Date.now() - startTime, jitter: searchResult.jitter };
     } else if (type === "scrape") {
       if (!url) throw new Error("Scrape task requires a URL");
       const scrapeResult = await executeScrapeTask(getContext(), url, abortController.signal);
       result = { ...scrapeResult, duration: Date.now() - startTime };
     } else if (type === "healthcheck") {
-      const healthResult = await executeHealthCheck(getContext(), initMs);
+      const healthResult = await executeHealthCheck(getContext(), initMs, abortController.signal);
       result = { ...healthResult, duration: Date.now() - startTime };
     } else {
       result = { error: "Unknown task type", duration: Date.now() - startTime };

package/docs/ARCHITECTURE.md

@@ -31,8 +31,8 @@ pi CLI
    search burst, then hands each researcher a set of result URLs to start from.
 4. Researchers scrape and read those pages through the scrape tooling and return cited
    reports. They consider only what they scraped this session.
-5. The evaluator reviews the round and either runs another round or synthesizes the
-   final report.
+5. The research lead's **router** reviews the round and either runs another round or ends
+   the loop; its **synthesizer** then writes the final report from every report collected.
 6. The result is returned as a single cited Markdown report; the cited URLs and their
    summaries are queued into the knowledge store for future runs.
 
@@ -49,11 +49,19 @@ agent skill can pass). The pi extension's `research` tool has a minimum depth of
 an in-session agent can never request quick mode.
 
 Depth 1–3 — deep (`DeepResearchOrchestrator`): the run proceeds in **rounds**. A round
-is one coordinate → research → evaluate cycle — the round's agenda is planned (by the
-coordinator in round 1, by the evaluator thereafter), a batch of **researchers** runs it
-in parallel, and the evaluator then decides whether to run another round or synthesize.
-Two limits apply independently: how many researchers run *within* a round, and how many
-rounds the run may take.
+is one coordinate → research → route cycle — the round's agenda is planned (by the
+coordinator in round 1, by the research lead's **router** thereafter), a batch of
+**researchers** runs it in parallel, and the router then decides whether to run another
+round or end the loop. Two limits apply independently: how many researchers run *within*
+a round, and how many rounds the run may take.
+
+The research lead is two roles, not one call doing both jobs. The router only decides; it
+reads each report in full on the one round it arrives and only that report's short
+coverage digest thereafter, so its input grows with team size rather than with the square
+of the round count. The **synthesizer** runs exactly once, at the end, reads every report
+in full, and writes the report — under a corpus budget derived from the model's context
+window, reducing in partial passes and merging when the corpus does not fit. The two
+prompts are `src/prompts/system-lead-router.md` and `system-lead-synthesizer.md`.
 
 | Depth | Label  | Researchers per round (max) | Rounds (max) |
 |-------|--------|-----------------------------|--------------|
@@ -61,7 +69,7 @@ rounds the run may take.
 | 2     | deep   | 3                           | 3            |
 | 3     | ultra  | 5                           | 3            |
 
-These are ceilings, not targets: the coordinator and evaluator use as many researchers
+These are ceilings, not targets: the coordinator and router use as many researchers
 and rounds as the topic needs. A depth-2 run, for example, may spawn up to 3 researchers
 in each of up to 3 rounds. Queued steering messages (Alt+Enter) can unlock a few extra
 rounds past the cap (`MAX_EXTRA_ROUNDS_WITH_STEERING`).
@@ -70,7 +78,7 @@ The coordinator also runs the initial search burst and distributes its result UR
 round 1's researchers (`distributeSearchResults`), so in deep mode the researchers
 themselves do not call `search`.
 
-LLM-call conventions. Coordinator, evaluator, synthesis, JSON-repair, and
+LLM-call conventions. Coordinator, router, synthesizer, JSON-repair, and
 knowledge-extraction calls go through `completeSimple` (`src/core/llm/pi-ai-completion.ts`)
 with `buildSafeOptions` (`src/core/llm/llm-utils.ts`); researcher sub-agents go through
 `createAgentSession`.
@@ -369,7 +377,7 @@ stable `Agent` connector API, so it follows `^8`.)
 
 Transient-failure resilience — every LLM call is a potential single point of failure on a
 streaming endpoint that can drop mid-response (undici surfaces this as `terminated`). The
-coordinator and evaluator calls retry fast transient transport failures (socket aborts, 5xx,
+coordinator and research-lead calls retry fast transient transport failures (socket aborts, 5xx,
 429, provider overload) with bounded exponential backoff — mirroring the per-researcher retry
 (`PI_RESEARCH_MAX_RETRIES`) — and, if still failing, degrade to a deterministic fallback plan
 rather than aborting the run. An app-level LLM timeout is not retried (it already spent the