@kenkaiiii/gg-boss 4.3.162 → 4.3.163

package/dist/{chunk-U3L3QW6X.js → chunk-JBKZOBJ7.js}

@@ -68336,6 +68336,41 @@ function normalizeProjectPath(cwd2) {
 function nowIso() {
   return (/* @__PURE__ */ new Date()).toISOString();
 }
+function mergeGoalTasks(existing, input) {
+  if (!input)
+    return existing;
+  const byId = new Map(input.map((task) => [task.id, task]));
+  const merged = existing.map((task) => {
+    const next = byId.get(task.id);
+    if (!next)
+      return task;
+    return {
+      ...task,
+      ...next,
+      status: task.status !== next.status || task.attempts > next.attempts ? task.status : next.status,
+      attempts: Math.max(task.attempts, next.attempts),
+      workerId: task.workerId ?? next.workerId,
+      verification: task.verification ?? next.verification,
+      lastSummary: task.lastSummary ?? next.lastSummary
+    };
+  });
+  for (const task of input) {
+    if (!existing.some((item) => item.id === task.id))
+      merged.push(task);
+  }
+  return merged;
+}
+function mergeGoalEvidence(existing, input) {
+  if (!input)
+    return existing;
+  const byId = new Map(existing.map((item) => [item.id, item]));
+  const merged = [...existing];
+  for (const item of input) {
+    if (!byId.has(item.id))
+      merged.push(item);
+  }
+  return merged;
+}
 function isObject2(value) {
   return typeof value === "object" && value !== null && !Array.isArray(value);
 }
@@ -68358,7 +68393,7 @@ function isEvidenceKind(value) {
   return value === "log" || value === "command" || value === "screenshot" || value === "file" || value === "summary";
 }
 function isEvidenceMechanism(value) {
-  return value === "command" || value === "test" || value === "script" || value === "fixture" || value === "log" || value === "screenshot" || value === "video" || value === "browser" || value === "device" || value === "source" || value === "manual";
+  return value === "command" || value === "test" || value === "script" || value === "fixture" || value === "log" || value === "screenshot" || value === "video" || value === "browser" || value === "device" || value === "source" || value === "file" || value === "manual";
 }
 function isEvidencePlanStatus(value) {
   return value === "planned" || value === "ready" || value === "blocked";
@@ -68674,8 +68709,8 @@ async function upsertGoalRun(cwd2, input) {
       prerequisites: input.prerequisites ?? existing.prerequisites,
       harness: input.harness ?? existing.harness,
       evidencePlan: input.evidencePlan ?? existing.evidencePlan,
-      tasks: input.tasks ?? existing.tasks,
-      evidence: input.evidence ?? existing.evidence,
+      tasks: mergeGoalTasks(existing.tasks, input.tasks),
+      evidence: mergeGoalEvidence(existing.evidence, input.evidence),
       blockers: input.blockers ?? existing.blockers,
       status: deriveRunnableStatus(input.status ?? existing.status, input.prerequisites ?? existing.prerequisites)
     } : createGoalRun(cwd2, input);
@@ -68843,10 +68878,10 @@ function buildHarnessTaskPrompt(run) {
   const harnessItems = run.harness.filter((item) => !item.command && !item.path).map((item) => `- ${item.label}: ${item.description ?? "Create local instrumentation."}`).join("\n");
   return `Goal: ${run.goal}
 
-Build the missing local/free harness instrumentation needed before verification. Translate the user's requested outcome into observable proof: ask what artifact would prove this actually worked end-to-end, then build the simplest reliable local/free path to observe it.
+Build only the missing local/free harness instrumentation needed before verification. Start by restating the intended experience, the relevant failure modes, and the senses/signals this harness must observe; do not default to generic tests, scripts, screenshots, benchmarks, or simulations unless that signal is required for this specific goal.
 ${harnessItems}
 
-Inventory domain-appropriate local capabilities before blocking: existing tests and CLIs, fixtures or seeded data, dev servers, browser automation, simulator/device screenshots, video/frame inspection, logs, generated assets, protocol traces, database assertions, API probes, contract tests, performance measurements, source/docs/code-search comparison, or other artifacts that directly measure the outcome. For mobile/UI goals, prefer local simulator/browser screenshots (for example iOS Simulator tooling when available) before requiring a physical phone. Create any scripts, fixtures, or test helpers in the repository, update the Goal harness/verifier metadata with the goals tool, and record command/file/screenshot/log evidence. Do not require paid services or signups; block only with exact user instructions if a true external prerequisite is missing.`;
+Inventory available local capabilities just deeply enough to choose a proportional instrument, then build it. Update the Goal harness/verifier metadata with the goals tool and record durable evidence showing the instrument exists and works. Do not require paid services or signups; block only with exact user instructions if a true external prerequisite is missing.`;
 }
 function blockedEvidencePlanReason(run) {
   const blocked = run.evidencePlan.find((item) => item.status === "blocked");
@@ -68901,15 +68936,15 @@ function buildEvidencePlanTaskPrompt(run) {
   const plannedItems = run.evidencePlan.filter((item) => item.status === "planned").map((item) => `- ${item.label} (${item.mechanism}): ${item.description}${item.command ? `; candidate command: ${item.command}` : ""}${item.path ? `; artifact: ${item.path}` : ""}`).join("\n");
   return `Goal: ${run.goal}
 
-Turn the planned proof paths below into real local/free verification capability before the Goal verifier runs. Translate success criteria and outcome requirements into observable proof paths: ask what would prove this goal actually worked end-to-end, then build the simplest reliable local/free way to capture that proof.
+Turn the planned proof paths below into real local/free verification capability before the Goal verifier runs. For each path, preserve the orchestrator's goal-specific sensory intent: what experience is being observed, what failure it catches, and what signal proves it.
 ${plannedItems}
 
-Inventory domain-appropriate capabilities deeply enough for this task before blocking: existing tests/CLIs, generated fixtures, seeded data, scripts, dev servers, browser automation, simulator/browser/device screenshots, video/frame inspection, logs, generated assets, protocol traces, database assertions, API probes, contract tests, performance measurements, source/docs/code-search comparison, or other artifacts that directly measure the requested outcome. For mobile/UI goals, screenshots are examples rather than the whole solution: prefer local simulator/browser tooling (for example iOS Simulator screenshots when available) before requiring a physical phone, and add image/frame checks when visual correctness matters. Build what is missing, update the Goal evidence_plan/harness/verifier metadata with the goals tool, and persist command/file/screenshot/log evidence, not narrative-only verification or human visual inspection. Only block with exact user instructions for inputs that cannot be generated or checked locally, such as credentials, paid services, physical devices, or unavailable source assets.`;
+Inventory available local capabilities without anchoring on any fixed tool category. Build only the proportional instrument needed for this proof path, update the Goal evidence_plan/harness/verifier metadata with the goals tool, and persist concrete command/file/artifact/log evidence that the instrument works. Do not use narrative-only verification or human visual inspection as completion evidence. Only block with exact user instructions for inputs that cannot be generated or checked locally.`;
 }
 function buildVerifierTaskPrompt(run) {
   return `Goal: ${run.goal}
 
-Define and build a real end-to-end verifier for this Goal. Translate the objective into observable proof: what command, artifact, trace, screenshot, log, fixture, database assertion, API probe, contract test, performance measurement, source/docs comparison, or other domain-appropriate signal would prove the requested outcome with near-100% confidence? Create the simplest reliable local/free scripts, fixtures, harnesses, or test commands needed, then update the Goal with a verifier_command and verifier_description using the goals tool. For mobile/UI goals, prefer local simulator/browser evidence such as iOS Simulator screenshots when available before requiring a physical phone. The verifier must be runnable locally/free and produce command or file evidence, not narrative or human visual inspection. If an external prerequisite is missing, mark it missing with exact user instructions.`;
+Define and build a real end-to-end verifier for this Goal. Begin from the intended experience and required senses/signals already implied by the success criteria and evidence plan. Choose a proportional local/free verifier that observes those signals and catches the important goal-specific failures; do not add generic simulations, screenshots, benchmarks, or scripts unless they directly support that proof. Update the Goal with a verifier_command and verifier_description using the goals tool. The verifier must be runnable locally/free and produce durable command or file evidence, not narrative or human visual inspection. If an external prerequisite is missing, mark it missing with exact user instructions.`;
 }
 function incompleteTasks(run) {
   return run.tasks.filter((task) => task.status !== "done");
@@ -68976,6 +69011,10 @@ ${priorSummaries}
 Run targeted diagnostics, fix the root cause, update durable Goal evidence with the goals tool, and rerun the exact verifier command. Do not mark the Goal complete.`;
 }
 function decideGoalNextAction(run, options2 = {}) {
+  const completion = canCompleteGoalRun(run);
+  if (completion.ok) {
+    return { kind: "complete", reason: completion.reason };
+  }
   if (run.status === "blocked" || run.status === "failed" || run.status === "passed" || run.status === "paused" && !run.continueRequestedAt) {
     return { kind: "terminal", status: run.status, reason: `Goal is ${run.status}.` };
   }
@@ -69016,10 +69055,6 @@ function decideGoalNextAction(run, options2 = {}) {
       reason: `Goal task "${task.title}" is ready for worker attempt ${attempts}.`
     };
   }
-  const completion = canCompleteGoalRun(run);
-  if (completion.ok) {
-    return { kind: "complete", reason: completion.reason };
-  }
   const blockedEvidence = blockedEvidencePlanReason(run);
   if (blockedEvidence) {
     return { kind: "blocked", reason: blockedEvidence };
@@ -69120,6 +69155,7 @@ var EvidencePlanInput = external_exports.object({
     "browser",
     "device",
     "source",
+    "file",
     "manual"
   ]).describe("How this proof will be gathered"),
   description: external_exports.string().describe("What this evidence proves"),
@@ -69188,7 +69224,7 @@ function asEvidenceKind(value) {
   return "summary";
 }
 function asEvidenceMechanism(value) {
-  if (value === "command" || value === "test" || value === "script" || value === "fixture" || value === "log" || value === "screenshot" || value === "video" || value === "browser" || value === "device" || value === "source" || value === "manual") {
+  if (value === "command" || value === "test" || value === "script" || value === "fixture" || value === "log" || value === "screenshot" || value === "video" || value === "browser" || value === "device" || value === "source" || value === "file" || value === "manual") {
     return value;
   }
   return "command";
@@ -69415,7 +69451,9 @@ function createGoalsTool(cwd2) {
           const completion = canCompleteGoalRun(runWithVerifier);
           const updated = await upsertGoalRun(cwd2, {
             ...runWithVerifier,
-            status: result.status === "pass" && completion.ok ? "passed" : result.status === "pass" ? "ready" : result.status === "fail" ? "ready" : "verifying"
+            status: result.status === "pass" && completion.ok ? "passed" : result.status === "pass" ? goalHasBlockingPrerequisites(runWithVerifier) ? "blocked" : "ready" : result.status === "fail" ? goalHasBlockingPrerequisites(runWithVerifier) ? "blocked" : "ready" : "verifying",
+            blockers: result.status === "pass" ? [] : run.blockers,
+            activeWorkerId: void 0
           });
           return `Verifier recorded for "${updated.title}": ${result.status}.`;
         }
@@ -70335,7 +70373,7 @@ ${planContent.trim()}
 function renderResearchSection() {
   return `## Research & Verification
 
-Do not assume APIs, CLI flags, config schema, internals, or error wording. Use \`source_path\` for installed deps and inspect with read/grep/find/ls; use \`web_search\` then \`web_fetch\` for authoritative docs. For public code, use ReferenceSources for curated repos or DiscoverRepos for current/top repos, then verify exact snippets with SearchCode literal text/RE2 (not semantic); \`path\` is a literal path substring and \`repo\` only after broad/peek proof. When driving a programmatic Goal run, proactively ask what observable artifact would prove the requested outcome worked end-to-end, then plan the simplest reliable local/free proof path for that domain: tests/CLIs, fixtures or seeded data, dev servers, browser automation, simulator or device screenshots, video/frame inspection, logs, generated assets, protocol traces, database assertions, API probes, contract tests, performance measurements, source/docs comparisons, or other measurable artifacts. UI/mobile screenshots are examples, not the whole solution; prefer local simulator/browser tooling such as iOS Simulator screenshots when available before blocking on a physical device, and block only with exact user instructions for true external prerequisites. Run relevant checks after edits; read/fix failures; never report unrun or failing checks as passing.`;
+Do not assume APIs, CLI flags, config schema, internals, or error wording. Use \`source_path\` for installed deps and inspect with read/grep/find/ls; use \`web_search\` then \`web_fetch\` for authoritative docs. For public code, use ReferenceSources for curated repos or DiscoverRepos for current/top repos, then verify exact snippets with SearchCode literal text/RE2 (not semantic); \`path\` is a literal path substring and \`repo\` only after broad/peek proof. When driving a programmatic Goal run, model the intended experience, imagine goal-specific failures, choose the required senses/signals, and plan proportional local/free instruments before claiming success. Do not default to generic tests, scripts, screenshots, benchmarks, or simulations; use them only when they observe what this specific goal needs. Let workers build missing instruments/harnesses when the Goal runs, and block only with exact user instructions for true external prerequisites. Run relevant checks after edits; read/fix failures; never report unrun or failing checks as passing.`;
 }
 function renderCodeQualitySection() {
   return `## Code Quality
@@ -72071,51 +72109,71 @@ var PROMPT_COMMANDS = [
     description: "Create a programmatic goal loop",
     prompt: `# Goal: Programmatic Goal Loop
 
-You are creating a durable Goal run: a programmatic control loop that should keep the main orchestrator focused on the user's objective while workers/harnesses/diagnostics produce evidence.
+You are creating a durable Goal run: a programmatic control loop that lets the user rely on the agent while they are not watching. The run should keep the main orchestrator focused on the objective while workers build, instrument, diagnose, and gather evidence.
 
 ## User objective
 
 The user's objective is in the command arguments. If the arguments are absent or too vague to identify an actionable objective, ask exactly one concise clarifying question and do not create a Goal run yet.
 
-## Required behavior
+## Non-negotiable boundary: /goal creates a run, it does not do the work
+
+The initial /goal invocation is setup/orchestration only. During this turn:
+
+- Create or update the durable run and Goal tasks, then stop.
+- Do not implement, fix, refactor, edit, or generate project artifacts for the objective yourself.
+- Do not call subagent, the normal tasks tool, goals resume, or any action that starts workers, verifiers, or auto-continuation.
+- Do not run the verifier or "just start" any task. Worker agents do implementation after the user explicitly starts the Goal from the Goal pane with (R).
+- The only non-goals tools allowed before stopping are cheap local prerequisite checks needed to know whether the run is blocked. If a check would mutate files, start a service, run a long process, launch a worker, or begin implementation, make it a Goal task instead.
+
+## Core mindset: goal-specific sensory proof
+
+Do not default to ordinary tests, generic scripts, or broad simulations. First model what must be experienced for this specific goal to be trusted without the human present.
+
+For each Goal, identify:
+
+1. Intended experience \u2014 who or what must experience the result: user, customer, operator, developer, attacker, browser, device, API client, database, model, downstream system, or another relevant perspective.
+2. Failure imagination \u2014 the goal-specific ways the result could appear done while still failing in reality.
+3. Required senses/signals \u2014 the observations needed to detect those failures. Think in capabilities, not fixed tools: perception of rendered output, interaction, timing, persistence/state, external boundaries, adversarial/social pressure, generated artifacts, traces, comparisons, or other signals relevant to this objective.
+4. Proportional instruments \u2014 local/free ways workers can capture those signals. The evidence portfolio should be as small as possible while still removing the important assumptions; do not simulate, script, screenshot, benchmark, or red-team anything unless that signal is relevant to this goal.
+5. Completion rule \u2014 why the planned evidence would be enough to claim success, and what remains unproven or blocked.
+
+Any examples you consider are inspiration, not a checklist. Borrow verification ideas from any domain when useful, but choose only the senses/signals that fit the user's actual objective.
+
+## Orchestrator responsibilities
 
 1. Translate the user's objective into:
    - a short title,
    - the original goal text,
    - concrete success criteria that can be verified,
    - prerequisite checks,
-   - an evidence plan: the simplest proof paths that would demonstrate success end-to-end,
-   - the local/free harness or observability you can build,
-   - a verifier command or verifier description.
-2. Build a capability/evidence plan before implementation: decide what would actually prove the goal works, such as scripts, tests, fixtures, seeded data, app/dev servers, browser automation, screenshots, logs, video/frame inspection, source/docs/code-search comparison, local CLIs, or generated assets. Do not require a script for every task; choose the simplest reliable proof that removes assumptions.
-3. Before doing implementation work or launching workers, identify prerequisites and check the ones you can check locally. Examples:
-   - model/API/OAuth credentials exist for simulated-agent testing,
-   - required local CLIs exist (ffmpeg, expo, adb, xcrun, playwright, etc.),
-   - required app/dev server can start or is already running,
-   - required fixture files, assets, devices, emulators, or test data exist or can be generated locally.
-4. Prefer local/free tools: scripts, shell commands, existing CLIs, test runners, logs, screenshots/images, existing dependencies, source_path, web docs, kencode search, and disposable workers/subagents. Do not require paid services, signups, or new external accounts unless unavoidable.
-5. Only ask the user for true external blockers after checking what you can do yourself. If a missing input cannot be generated or verified locally (credentials, paid services, physical devices, private assets, permissions), record the exact minimal prerequisite and ask once in chat; do not ask for broad lists of things you could inspect or create yourself.
+   - an evidence plan describing the goal-specific sensory proof required,
+   - harness or observability items that workers may need to build,
+   - a verifier command when already obvious, otherwise a verifier description or task to define one.
+2. Plan first; do not build during initial Goal creation. The orchestrator may do cheap local prerequisite checks needed to determine whether the Goal is blocked, but worker agents should build instruments, implementation changes, harnesses, diagnostics, and verifier commands after the user starts the Goal. If implementation work is needed, capture it as a Goal task instead of doing it yourself.
+3. Before launching workers, identify prerequisites and check the ones you can check locally. Examples are non-exhaustive and should not anchor the plan: required credentials or permissions, local capabilities, app/runtime availability, fixture/assets/test data, devices/emulators, network or service access, or domain-specific inputs.
+4. Prefer local/free capabilities already available in the project or environment. Do not require paid services, signups, new external accounts, private assets, or physical access unless unavoidable for this specific objective.
+5. Only ask the user for true external blockers after checking what you can do yourself. If a missing input cannot be generated or verified locally, record the exact minimal prerequisite and ask once in chat; do not ask for broad lists of things you could inspect or create yourself.
 6. Treat user-provided prerequisites as the first Goal item, named "User prerequisites" in the pane. The user may provide the missing value or instructions in chat. After they do, verify it locally without revealing secrets, then update the matching prerequisite to \`met\` with short evidence before any worker task runs.
 7. Persist the run with the goals tool:
    - call \`goals({ action: "create", ... })\` once the objective is understood,
    - include success criteria, prerequisites, evidence_plan items, harness items, and verifier info,
    - if any prerequisite is missing or unknown and cannot be automatically checked, persist the run as blocked and ask the user for the exact missing thing once.
-8. Add Goal tasks with \`goals({ action: "task", ... })\`. Do not use the normal tasks tool for this workflow. Each Goal task prompt must be standalone, mention the same project cwd, the specific files/scripts/commands to use, evidence to record, and verification expectations. Avoid pure "investigate and report" tasks unless their prompt explicitly requires persisting concrete findings with \`goals({ action: "evidence", ... })\` and creating or updating the next implementation task from those findings.
-9. Persist evidence with \`goals({ action: "evidence", ... })\` whenever you create diagnostics, run harnesses, capture logs/screenshots, record controller decisions, attach verifier artifact paths, or learn a blocker.
-10. Completion means verifier evidence satisfies the original success criteria. Do not call \`goals({ action: "complete" })\` merely because tasks are done; only complete after verification passes.
-11. When the Goal reaches a terminal state, give the user a concise final summary in chat. Use a compact 3\u20134 column table with columns that fit what happened, such as outcome, evidence/verifier, changed work, blockers, or next action. Do not dump worker logs; point to artifact paths when useful.
+8. Add Goal tasks with \`goals({ action: "task", ... })\`. Do not use the normal tasks tool for this workflow. Each Goal task prompt must be standalone, mention the same project cwd, the specific goal slice, the sensory signals or evidence it must produce, any existing instruments it should reuse, and verification expectations. Avoid pure "investigate and report" tasks unless their prompt explicitly requires persisting concrete findings with \`goals({ action: "evidence", ... })\` and creating or updating the next implementation task from those findings.
+9. Persist evidence with \`goals({ action: "evidence", ... })\` whenever workers create diagnostics, build or run instruments, capture artifacts, record controller decisions, attach verifier output, or learn a blocker.
+10. Completion means verifier evidence satisfies the original success criteria and the required sensory proof. Do not call \`goals({ action: "complete" })\` merely because tasks are done; only complete after verification passes.
+11. When the Goal reaches a terminal state, give the user a specific final summary in chat. Do not collapse the outcome into one generic row or say only that it "verified." Use a compact 3\u20134 column table with one row per substantive Goal task, evidence path, success criterion, verifier result, blocker, or decision. For bug/fix/audit goals, include the problem, how it was proven real or wrong, what fixed it, and the exact verification. For creation/improvement/non-problem goals, substitute the requested outcome or gap, what was delivered or decided, and the exact proof that the intended experience now exists. Include small snippets when useful: file:line references, command names and exit codes, short before/after text, log excerpts, artifact paths, or verifier output summaries. Do not dump worker logs; quote only the few details needed to make the conclusion auditable.
 
 ## Loop semantics
 
-Think in this order: observe \u2192 instrument \u2192 automate \u2192 run \u2192 inspect evidence \u2192 fix \u2192 rerun until verified or blocked.
+Initial /goal turn order: understand intended experience \u2192 imagine relevant failures \u2192 choose required senses/signals \u2192 plan proportional instruments \u2192 persist the run/tasks/evidence plan \u2192 stop.
 
-After the user starts a Goal from the Goal pane with (R), worker and verifier completions are sent back to you as hidden synthetic events. On each event, call \`goals({ action: "status", run_id })\`, inspect current state, briefly say what the orchestrator is doing so the chat shows progress, and take the next durable control-loop action rather than merely narrating. The UI keeps auto-continuing until the run is passed, blocked, paused, or failed.
+After the user starts a Goal from the Goal pane with (R), worker and verifier completions are sent back to you as hidden synthetic events. On each event, call \`goals({ action: "status", run_id })\`, inspect current state, briefly say what the orchestrator is doing so the chat shows progress, and take the next durable control-loop action rather than merely narrating. The UI keeps auto-continuing until the run is passed, blocked, paused, or failed. Even during auto-continuation, do not switch into hands-on implementation; if work is needed, create or update Goal tasks and let workers/verifiers do it.
 
-If no verifier command exists yet, create a task to define one. If the verifier fails, persist the failure evidence and add the next Goal task that addresses the failure. Cap runaway loops by pausing and recording evidence when repeated attempts stop making progress.
+If no verifier command exists yet, create a task to define one. If an evidence path or harness is only planned, create a worker task to build the missing instrument, then later workers can reuse that instrument for subsequent slices. If the verifier fails, persist the failure evidence and add the next Goal task that addresses the failure. Cap runaway loops by pausing and recording evidence when repeated attempts stop making progress.
 
 ## Final response
 
-When initially creating the Goal, keep the response short: say whether the Goal was created, ready, or blocked; mention the exact missing prerequisite if blocked; and tell the user they can press Ctrl+G to view it. If they ask how to start it, tell them the Goal pane keybind is (R) to run it. When auto-continuation eventually passes, fails, blocks, or pauses the Goal, provide the compact final summary table described above.`
+When initially creating the Goal, keep the response short: say whether the Goal was created, ready, or blocked; mention the exact missing prerequisite if blocked; and tell the user they can press Ctrl+G to view it. Then stop. Do not continue into implementation, worker startup, verifier execution, or Goal resume. If they ask how to start it, tell them the Goal pane keybind is (r) to run it. When auto-continuation eventually passes, fails, blocks, or pauses the Goal, provide the specific multi-row final summary table described above, with concrete proof snippets instead of a generic "verified" claim.`
   },
   {
     name: "scan",
@@ -73671,6 +73729,33 @@ function estimateConversationTokens(messages) {
 var TOOL_RESULT_MAX_CHARS = 2e3;
 var MAX_SUMMARY_RETRIES = 2;
 var MAX_SUMMARY_OUTPUT_TOKENS = 4096;
+var SUMMARY_ATTEMPT_TIMEOUT_MS = 3e4;
+var SummaryTimeoutError = class extends Error {
+  constructor(timeoutMs) {
+    super(`Summary LLM response timed out after ${timeoutMs}ms`);
+    this.name = "SummaryTimeoutError";
+  }
+};
+async function awaitSummaryResponseWithTimeout(response, timeoutMs, signal) {
+  signal?.throwIfAborted();
+  let timeout;
+  let abortListener;
+  try {
+    return await new Promise((resolve4, reject) => {
+      timeout = setTimeout(() => reject(new SummaryTimeoutError(timeoutMs)), timeoutMs);
+      if (typeof timeout.unref === "function")
+        timeout.unref();
+      abortListener = () => reject(new DOMException("Aborted", "AbortError"));
+      signal?.addEventListener("abort", abortListener, { once: true });
+      response.then(resolve4, reject);
+    });
+  } finally {
+    if (timeout)
+      clearTimeout(timeout);
+    if (abortListener)
+      signal?.removeEventListener("abort", abortListener);
+  }
+}
 var COMPACTION_SYSTEM_PROMPT = "You are a conversation compaction assistant. Your job is to create a concise summary of a conversation between a user and an AI coding assistant.\n\nThis summary will replace older messages to keep the conversation within context limits while preserving all important information needed to continue the work seamlessly.\n\nAlways output the summary \u2014 never refuse, never ask questions, never output empty responses.\n\n## What to Include\n- **User intent and goals** \u2014 what the user is trying to accomplish\n- **What was done** \u2014 what was implemented, modified, or debugged, including technical approaches and outcomes\n- **File operations** \u2014 all files created, modified, or referenced, with key changes\n- **Tool call outcomes** \u2014 which tools were called and their key results\n- **Key decisions** \u2014 important choices made and why\n- **Solutions & troubleshooting** \u2014 problems encountered and how they were resolved\n\n## What to Exclude\n- Redundant or superseded information\n- Full file contents (reference by path instead)\n- Verbose tool output (summarize key results)\n- Plans, next steps, or implementation instructions \u2014 do NOT carry forward action items or plans from old conversation summaries. Summarize what HAPPENED, not what SHOULD happen next. The recent messages (preserved separately) already contain the current context.\n\nFocus on technical precision. Include specific identifiers (file paths, function names, etc.) that would be essential for continuation. Write in third person and maintain an objective, technical tone.";
 var COMPACTION_USER_PROMPT = "Summarize the conversation above into a concise summary following the instructions. Output only the summary, nothing else.";
 var COMPACTION_RESERVE_TOKENS = 16384;
@@ -74032,7 +74117,7 @@ You MUST preserve all references to this plan and its approval status in the sum
         baseUrl: options2.baseUrl,
         signal: options2.signal
       });
-      const response = await result.response;
+      const response = await awaitSummaryResponseWithTimeout(result.response, SUMMARY_ATTEMPT_TIMEOUT_MS, options2.signal);
       options2.signal?.throwIfAborted();
       log("INFO", "compaction", `Summary LLM response received`, {
         attempt: String(attempt),
@@ -74061,7 +74146,7 @@ You MUST preserve all references to this plan and its approval status in the sum
       if (options2.signal?.aborted || err instanceof Error && err.name === "AbortError") {
         throw err;
       }
-      log("WARN", "compaction", `Summary LLM call failed: ${err instanceof Error ? err.message : String(err)}`, { attempt: String(attempt) });
+      log("WARN", "compaction", err instanceof SummaryTimeoutError ? `Summary LLM call timed out after ${SUMMARY_ATTEMPT_TIMEOUT_MS}ms \u2014 using fallback if no later attempt succeeds` : `Summary LLM call failed: ${err instanceof Error ? err.message : String(err)}`, { attempt: String(attempt), timeoutMs: String(SUMMARY_ATTEMPT_TIMEOUT_MS) });
     }
   }
   if (summaryText.length === 0) {
@@ -99859,4 +99944,4 @@ react/cjs/react-jsx-runtime.development.js:
    * LICENSE file in the root directory of this source tree.
    *)
 */
-//# sourceMappingURL=chunk-U3L3QW6X.js.map
+//# sourceMappingURL=chunk-JBKZOBJ7.js.map