zeitzeuge 0.6.5 → 0.7.0

package/LICENSE

@@ -1,6 +1,6 @@
 The MIT License
 
-Copyright (c) Christian Bromann
+Copyright (c) LangChain, Inc.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/README.md

@@ -1,168 +1,46 @@
-<p align="center">
-  <img src=".github/assets/zeitzeuge.png" alt="ZeitZeuge mascot: a detective stopwatch with a magnifying glass witnessing slowdowns" width="220" />
-</p>
-
 # zeitzeuge
 
-AI-powered performance analysis for frontend page loads and Vitest test suites. Captures V8 heap snapshots, performance traces, Chrome runtime traces, and CPU profiles — stores everything in a virtual filesystem and hands it to a Deep Agent that investigates bottlenecks and provides code-level fixes.
-
-> _"Zeuge" = witness — the tool "witnesses" slowdowns in your page loads and test runs._
+AI-powered performance analysis for frontend page loads. Launches Chrome, captures V8 heap snapshots, performance traces, and Chrome runtime traces in a single page load, then hands everything to a Deep Agent that investigates bottlenecks and provides code-level fixes.
 
-## Quick start
+> _"Zeuge" = witness -- the tool "witnesses" slowdowns in your page loads._
 
-### Page-load analysis
+## Install
 
 ```bash
-# Set your API key
-export OPENAI_API_KEY=sk-...    # or ANTHROPIC_API_KEY
-
-# Analyze any URL
-npx zeitzeuge http://localhost:3000
+npm install -g zeitzeuge
 ```
 
-### Vitest integration
-
-Add the plugin to your `vitest.config.ts` to profile your test suite and get AI-powered analysis of your **application code** performance:
-
-```ts
-import { defineConfig } from 'vitest/config';
-import { zeitzeuge } from 'zeitzeuge/vitest';
+Requires an LLM API key:
 
-export default defineConfig({
-  plugins: [zeitzeuge()],
-});
+```bash
+export OPENAI_API_KEY=sk-...    # or ANTHROPIC_API_KEY
 ```
 
-Run your tests as usual — zeitzeuge instruments the run with V8 CPU profiling, collects the profiles, and runs a Deep Agent analysis after tests complete:
+## Usage
 
 ```bash
-vitest run
+zeitzeuge http://localhost:3000
 ```
 
 A Markdown report is written to `zeitzeuge-report.md` with findings and suggested fixes.
 
 ## How it works
 
-### Page-load mode (`npx zeitzeuge <url>`)
-
 1. **Launches Chrome** via WebdriverIO with DevTools Protocol access
 2. **Captures everything in one page load:**
    - V8 heap snapshot (memory analysis)
    - Performance trace (network waterfall, long tasks, paint timing)
-   - **Chrome runtime trace** via the [Tracing domain](https://chromedevtools.github.io/devtools-protocol/tot/Tracing/) — every function call, event dispatch, layout, paint, and GC event on the main thread
+   - Chrome runtime trace via the [Tracing domain](https://chromedevtools.github.io/devtools-protocol/tot/Tracing/) -- every function call, event dispatch, layout, paint, and GC event on the main thread
    - All network assets (scripts, CSS, HTML source code)
-3. **Builds a VFS workspace** using `@langchain/node-vfs` — an in-memory virtual filesystem containing:
-   - `/heap/summary.json` — parsed heap snapshot data
-   - `/trace/summary.json` — page load timing & metrics
-   - `/trace/runtime/blocking-functions.json` — functions blocking the main thread > 50ms
-   - `/trace/runtime/event-listeners.json` — event listener add/remove imbalances
-   - `/trace/runtime/frame-breakdown.json` — time breakdown: scripting vs layout vs paint vs GC
-   - `/scripts/`, `/styles/`, `/html/` — actual source files
-4. **Deep Agent explores** — a LangChain Deep Agent (`deepagents`) autonomously browses the workspace, reads actual source code, greps for patterns, and correlates heap data with trace data and runtime analysis
-5. **Reports findings** — memory leaks, frame-blocking functions, listener leaks, render-blocking scripts, GC pressure — with code-level fixes
-
-### Vitest mode (`zeitzeuge/vitest` plugin)
-
-1. **Instruments Vitest** — injects `--cpu-prof` into worker process args, forces `pool: 'forks'` for reliable profiling, disables file parallelism for clean per-file profiles
-2. **Captures V8 CPU profiles** for each test file during the test run
-3. **Classifies hot functions** — every profiled function is categorized as `application`, `dependency`, `test`, or `framework` based on its file path relative to your project root
-4. **Builds a VFS workspace** containing:
-   - `/hot-functions/application.json` — hotspots in **your** code (primary focus)
-   - `/hot-functions/dependencies.json` — hotspots in third-party code
-   - `/scripts/application.json` — per-file CPU time for your source files
-   - `/scripts/dependencies.json` — per-file CPU time for dependencies
-   - `/profiles/*.json` — full CPU profile summaries with call trees
-   - `/timing/overview.json` — per-test timing data
-   - `/src/`, `/tests/` — actual source files referenced by hot functions
-5. **Deep Agent analyzes your application code** — focuses on bottlenecks in the code you wrote, not test infrastructure overhead. Reports dependency issues when your code makes expensive calls into libraries.
+3. **Builds a VFS workspace** using `@langchain/node-vfs` containing parsed heap data, trace summaries, runtime analysis, and actual source files
+4. **Deep Agent explores** -- a LangChain Deep Agent autonomously browses the workspace, reads source code, and correlates heap data with trace and runtime data
+5. **Reports findings** -- memory leaks, frame-blocking functions, listener leaks, render-blocking scripts, GC pressure -- with code-level fixes
 
 ## What it finds
 
-### Page-load findings
-
-**Memory issues:**
-
-- Memory leaks (unbounded caches, growing arrays/maps)
-- Detached DOM nodes still referenced in JavaScript
-- Large retained objects and closure leaks
-
-**Page-load issues:**
-
-- Render-blocking scripts (`<script>` without `async`/`defer`)
-- Render-blocking stylesheets
-- Long main-thread tasks (> 50ms)
-- Oversized bundles and unused code
-- Sequential waterfall bottlenecks
-
-**Runtime issues:**
-
-- **Frame-blocking functions** — exact function name, script URL, line number, and call stack for any function blocking the main thread > 50ms
-- **Event listener leaks** — `addEventListener` calls without matching `removeEventListener`, growing listener counts
-- **GC pressure** — frequent or long garbage collection pauses indicating memory churn
-- **Layout thrashing** — forced synchronous layouts from reading layout properties after DOM mutations
-
-### Vitest analysis
-
-**Application code bottlenecks:**
-
-- Hot functions with high self time in your source code
-- Expensive algorithms (O(n^2) loops, redundant computation, unnecessary sorting)
-- Object allocation hotspots driving GC pressure
-- Synchronous blocking in hot paths (file I/O, crypto, JSON serialization)
-
-**Dependency bottlenecks:**
-
-- Third-party libraries consuming disproportionate CPU
-- Unnecessary calls to expensive dependency APIs in hot paths
-- Suggestions for alternative libraries or configuration changes
-
-**GC pressure:**
-
-- Functions creating many short-lived objects in tight loops
-- Large allocations that could be pooled or reused
-
-## Vitest plugin options
-
-```ts
-zeitzeuge({
-  // Enable/disable the plugin (default: true)
-  enabled: true,
-
-  // Path for the Markdown report (default: 'zeitzeuge-report.md')
-  output: 'zeitzeuge-report.md',
-
-  // Directory for temporary .cpuprofile files (default: '.zeitzeuge-profiles')
-  profileDir: '.zeitzeuge-profiles',
-
-  // Also write V8 heap profiles (.heapprofile) for workers (default: false)
-  // Uses: --heap-prof + --heap-prof-dir=<profileDir>
-  heapProf: false,
-
-  // Run Deep Agent analysis after tests finish (default: true)
-  analyzeOnFinish: true,
-
-  // Project root for classifying application vs dependency code (default: process.cwd())
-  projectRoot: process.cwd(),
-
-  // Enable debug logging (default: false)
-  verbose: false,
-});
-```
-
-### Heap profiling (`heapProf`) — when to enable it
-
-`heapProf` captures **allocation sampling** (written as `.heapprofile` files) and can help you find:
-
-- Allocation hotspots (functions / modules allocating lots of bytes)
-- High GC pressure caused by excessive short-lived objects
-
-It defaults to **`false`** because it can be a net negative for everyday runs:
-
-- **Overhead**: allocation sampling adds runtime overhead and can skew timings/CPU profiles
-- **Artifact size / IO**: `.heapprofile` files can be large, increasing IO and CI flakiness
-- **Noise**: test runners allocate a lot in setup/framework code; heap data can be less actionable unless you’re specifically chasing allocations/GC
-
-Recommendation: keep it off by default and enable it when you suspect **allocation/GC issues** or when CPU hotspots alone aren’t explaining slow tests.
+- **Memory issues** -- leaks, detached DOM nodes, large retained objects, closure leaks
+- **Page-load issues** -- render-blocking scripts/stylesheets, long tasks, oversized bundles, sequential waterfalls
+- **Runtime issues** -- frame-blocking functions (with exact source location and call stack), event listener leaks, GC pressure, layout thrashing
 
 ## CLI options
 
@@ -173,6 +51,7 @@ Options:
   --verbose, -v   Enable verbose/debug logging       [boolean] [default: false]
   --headless      Run Chrome in headless mode         [boolean] [default: true]
   --timeout       Page load timeout in milliseconds   [number]  [default: 30000]
+  --output, -o    Output path for the Markdown report [string]  [default: "zeitzeuge-report.md"]
   --help, -h      Show help                           [boolean]
   --version       Show version number                 [boolean]
 ```
@@ -185,28 +64,11 @@ Options:
 | `ANTHROPIC_API_KEY` | Anthropic API key (fallback)                                    |
 | `ZEITZEUGE_MODEL`   | Override model name (e.g. `gpt-4o`, `claude-sonnet-4-20250514`) |
 
-## Development
+## Related packages
 
-```bash
-# Install dependencies
-bun install
-
-# Run in development
-bun run dev -- http://localhost:3000
-
-# Run tests
-bun test
-
-# Build for distribution
-bun run build
-```
+- [`@zeitzeuge/vitest`](../vitest/) -- Vitest plugin for test suite performance analysis
+- [`@zeitzeuge/utils`](../utils/) -- Shared internals (private, not published)
 
-## Tech stack
+## License
 
-- **Runtime:** [Bun](https://bun.sh) (works across JS runtimes)
-- **Browser automation:** [WebdriverIO](https://webdriver.io) + Chrome DevTools Protocol
-- **Runtime tracing:** [CDP Tracing domain](https://chromedevtools.github.io/devtools-protocol/tot/Tracing/) for function-level main-thread analysis
-- **V8 CPU profiling:** `--cpu-prof` for per-function timing in test suites
-- **AI analysis:** [Deep Agents](https://docs.langchain.com/oss/javascript/deepagents/overview) + [LangChain](https://langchain.com)
-- **Virtual filesystem:** [@langchain/node-vfs](https://docs.langchain.com/oss/javascript/integrations/providers/node-vfs) — in-memory VFS sandbox
-- **LLM providers:** OpenAI, Anthropic (auto-detected from environment)
+MIT

package/dist/analysis/agent.d.ts

@@ -1,33 +1,24 @@
 import { type BackendProtocol } from 'deepagents';
 import type { BaseChatModel } from '@langchain/core/language_models/chat_models';
 import type { Ora } from 'ora';
-import type { Finding, HeapSummary, TraceResult } from '../types.js';
-import type { PerformanceMetrics } from '../vitest/metrics.js';
+import { type Finding, type HeapSummary, type TraceResult } from '@zeitzeuge/utils';
 /** Context for building a dynamic page-load user message. */
 export interface PageLoadContext {
     url: string;
     heapSummary: HeapSummary;
     traceResult: TraceResult;
+    /** All workspace file paths from workspace creation. */
+    workspaceFiles?: string[];
 }
 /**
- * Analyze performance data using a Deep Agent that explores
- * the workspace containing heap + trace data + source files.
+ * Analyze page-load performance data using a single Deep Agent orchestrator
+ * with four specialized subagents, each focused on a different category of
+ * performance issue.
+ *
+ * File lists are baked into each subagent's system prompt at construction
+ * time so they read files directly without ls/glob discovery.
  */
-export declare function analyze(model: BaseChatModel, backend: BackendProtocol, spinner: Ora, context?: PageLoadContext): Promise<Finding[]>;
-/** Context for building a dynamic Vitest user message. */
-export interface VitestAnalysisContext {
-    metrics: PerformanceMetrics;
-    hasHeapProfiles: boolean;
-    hasListenerTracking: boolean;
-}
-/**
- * Analyze Vitest test performance data using a Deep Agent that explores
- * the workspace containing CPU profiles + test timing + source files.
- */
-export declare function analyzeTestPerformance(model: BaseChatModel, backend: BackendProtocol, spinner: Ora, context?: VitestAnalysisContext): Promise<Finding[]>;
-/**
- * Format bytes into a human-readable string.
- * Kept for backwards compatibility with existing imports.
- */
-export declare function formatBytes(bytes: number): string;
+export declare function analyze(model: BaseChatModel, backend: BackendProtocol, spinner: Ora, context?: PageLoadContext, { animateProgress }?: {
+    animateProgress?: boolean;
+}): Promise<Finding[]>;
 //# sourceMappingURL=agent.d.ts.map

package/dist/analysis/agent.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"agent.d.ts","sourceRoot":"","sources":["../../src/analysis/agent.ts"],"names":[],"mappings":"AAAA,OAAO,EAEL,KAAK,eAAe,EAGrB,MAAM,YAAY,CAAC;AAEpB,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,6CAA6C,CAAC;AACjF,OAAO,KAAK,EAAE,GAAG,EAAE,MAAM,KAAK,CAAC;AAM/B,OAAO,KAAK,EAAE,OAAO,EAAE,WAAW,EAAE,WAAW,EAAE,MAAM,aAAa,CAAC;AACrE,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,sBAAsB,CAAC;AAwC/D,6DAA6D;AAC7D,MAAM,WAAW,eAAe;IAC9B,GAAG,EAAE,MAAM,CAAC;IACZ,WAAW,EAAE,WAAW,CAAC;IACzB,WAAW,EAAE,WAAW,CAAC;CAC1B;AA6DD;;;GAGG;AACH,wBAAsB,OAAO,CAC3B,KAAK,EAAE,aAAa,EACpB,OAAO,EAAE,eAAe,EACxB,OAAO,EAAE,GAAG,EACZ,OAAO,CAAC,EAAE,eAAe,GACxB,OAAO,CAAC,OAAO,EAAE,CAAC,CAwBpB;AAED,0DAA0D;AAC1D,MAAM,WAAW,qBAAqB;IACpC,OAAO,EAAE,kBAAkB,CAAC;IAC5B,eAAe,EAAE,OAAO,CAAC;IACzB,mBAAmB,EAAE,OAAO,CAAC;CAC9B;AAkDD;;;GAGG;AACH,wBAAsB,sBAAsB,CAC1C,KAAK,EAAE,aAAa,EACpB,OAAO,EAAE,eAAe,EACxB,OAAO,EAAE,GAAG,EACZ,OAAO,CAAC,EAAE,qBAAqB,GAC9B,OAAO,CAAC,OAAO,EAAE,CAAC,CAwBpB;AAED;;;GAGG;AACH,wBAAgB,WAAW,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAIjD"}
+{"version":3,"file":"agent.d.ts","sourceRoot":"","sources":["../../src/analysis/agent.ts"],"names":[],"mappings":"AAAA,OAAO,EAAmB,KAAK,eAAe,EAAiB,MAAM,YAAY,CAAC;AAElF,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,6CAA6C,CAAC;AACjF,OAAO,KAAK,EAAE,GAAG,EAAE,MAAM,KAAK,CAAC;AAO/B,OAAO,EAQL,KAAK,OAAO,EACZ,KAAK,WAAW,EAChB,KAAK,WAAW,EAEjB,MAAM,kBAAkB,CAAC;AAE1B,6DAA6D;AAC7D,MAAM,WAAW,eAAe;IAC9B,GAAG,EAAE,MAAM,CAAC;IACZ,WAAW,EAAE,WAAW,CAAC;IACzB,WAAW,EAAE,WAAW,CAAC;IACzB,wDAAwD;IACxD,cAAc,CAAC,EAAE,MAAM,EAAE,CAAC;CAC3B;AA4LD;;;;;;;GAOG;AACH,wBAAsB,OAAO,CAC3B,KAAK,EAAE,aAAa,EACpB,OAAO,EAAE,eAAe,EACxB,OAAO,EAAE,GAAG,EACZ,OAAO,CAAC,EAAE,eAAe,EACzB,EAAE,eAAsB,EAAE,GAAE;IAAE,eAAe,CAAC,EAAE,OAAO,CAAA;CAAO,GAC7D,OAAO,CAAC,OAAO,EAAE,CAAC,CA6BpB"}

package/dist/analysis/parser.d.ts

@@ -1,3 +1,3 @@
-import type { RawSnapshot, HeapSummary } from '../types.js';
+import type { RawSnapshot, HeapSummary } from '@zeitzeuge/utils';
 export declare function parseSnapshot(rawSnapshot: RawSnapshot): HeapSummary;
 //# sourceMappingURL=parser.d.ts.map

package/dist/analysis/parser.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"parser.d.ts","sourceRoot":"","sources":["../../src/analysis/parser.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EACV,WAAW,EACX,WAAW,EAMZ,MAAM,aAAa,CAAC;AA6BrB,wBAAgB,aAAa,CAAC,WAAW,EAAE,WAAW,GAAG,WAAW,CAyVnE"}
+{"version":3,"file":"parser.d.ts","sourceRoot":"","sources":["../../src/analysis/parser.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EACV,WAAW,EACX,WAAW,EAMZ,MAAM,kBAAkB,CAAC;AA6B1B,wBAAgB,aAAa,CAAC,WAAW,EAAE,WAAW,GAAG,WAAW,CAyVnE"}

package/dist/analysis/prompts/code-pattern.d.ts

@@ -0,0 +1,8 @@
+/**
+ * System prompt for the Frontend Code Pattern subagent.
+ *
+ * Focuses on: inline scripts, DOM manipulation patterns, event delegation,
+ * synchronous APIs, CSS issues, and non-passive event listeners.
+ */
+export declare const CODE_PATTERN_PROMPT = "You are a specialist in detecting frontend performance anti-patterns in JavaScript, CSS, and HTML source code.\n\nYou have access to a workspace with actual source files captured from a real page load.\n\n## Your focus areas\n\n### 1. Inline Scripts That Could Be External and Deferred\n\nLarge `<script>` blocks in the HTML document that block rendering.\n\n```html\n<!-- BAD: large inline script blocks rendering -->\n<head>\n  <script>\n    // 200 lines of non-critical initialization code\n    const config = { /* ... */ };\n    initializeAnalytics(config);\n  </script>\n</head>\n\n<!-- GOOD: extract to external file and defer -->\n<head>\n  <script src=\"/init.js\" defer></script>\n</head>\n```\n\n**How to detect:** Read /html/document.html and look for inline `<script>` blocks\nthat are large (>20 lines or >1KB) and don't need to execute before first paint.\n\n### 2. DOM Manipulation in Loops (Layout Thrashing)\n\nModifying DOM elements inside loops without batching, which triggers\nrepeated layout recalculations.\n\n```javascript\n// BAD: DOM write inside loop forces layout per iteration\nfunction resizeAll(elements) {\n  for (const el of elements) {\n    el.style.width = el.parentElement.offsetWidth + 'px'; // read+write per iteration\n  }\n}\n\n// GOOD: batch reads then batch writes\nfunction resizeAll(elements) {\n  const widths = elements.map(el => el.parentElement.offsetWidth);\n  elements.forEach((el, i) => {\n    el.style.width = widths[i] + 'px';\n  });\n}\n```\n\n**How to detect:** Search source files for loops containing both DOM reads\n(offsetWidth, offsetHeight, getBoundingClientRect, getComputedStyle) and\nDOM writes (style.*, setAttribute, classList.*).\n\n### 3. Missing Event Delegation\n\nMany identical event listeners on sibling elements instead of a single\ndelegated listener on the parent.\n\n```javascript\n// BAD: listener on every list item\ndocument.querySelectorAll('.item').forEach(item => {\n  item.addEventListener('click', handleClick); // N listeners\n});\n\n// GOOD: single delegated listener on parent\ndocument.querySelector('.list').addEventListener('click', (e) => {\n  const item = e.target.closest('.item');\n  if (item) handleClick(e);\n});\n```\n\n**How to detect:** Search source files for querySelectorAll(...).forEach(... =>\naddEventListener...) patterns or similar loops that add the same listener type\nto many elements.\n\n### 4. Synchronous XMLHttpRequest or Blocking APIs\n\nLegacy synchronous XHR or other blocking API calls on the main thread.\n\n```javascript\n// BAD: synchronous XHR blocks the main thread\nconst xhr = new XMLHttpRequest();\nxhr.open('GET', '/api/data', false); // false = synchronous\nxhr.send();\n\n// GOOD: use async fetch\nconst response = await fetch('/api/data');\nconst data = await response.json();\n```\n\n**How to detect:** Search source files for `XMLHttpRequest` with the third\nargument set to `false`, or `document.write()`, or other deprecated\nsynchronous APIs.\n\n### 5. Non-Passive Scroll/Touch Event Listeners\n\nEvent listeners for scroll, touchstart, touchmove, or wheel that are not\nmarked as passive, preventing the browser from optimising scroll performance.\n\n```javascript\n// BAD: non-passive touch listener blocks scrolling\ndocument.addEventListener('touchstart', handler);\n\n// GOOD: passive listener allows smooth scrolling\ndocument.addEventListener('touchstart', handler, { passive: true });\n```\n\n**How to detect:** Search source files for addEventListener calls with\n'scroll', 'touchstart', 'touchmove', or 'wheel' that don't specify\n`{ passive: true }` as the options argument.\n\n### 6. CSS Issues\n\n```css\n/* BAD: universal selector causes expensive style calculations */\n* { box-sizing: border-box; } /* acceptable for box-sizing but not for complex rules */\n* > div > span { color: red; } /* very expensive */\n\n/* BAD: unused @import adding network round-trips */\n@import url('https://fonts.googleapis.com/css2?family=Roboto');\n/* GOOD: use <link> with preconnect for external fonts */\n```\n\n**How to detect:** Read CSS files and look for:\n- `@import` statements (add network round-trips vs `<link>`)\n- Complex selectors with many combinators\n- Large unused rule blocks\n- Missing `will-change` or `contain` for animated elements\n\n### 7. Missing Image Dimensions Causing Layout Shifts\n\nImages without explicit width/height that cause Cumulative Layout Shift (CLS).\n\n```html\n<!-- BAD: no dimensions \u2192 layout shift when image loads -->\n<img src=\"/hero.jpg\">\n\n<!-- GOOD: explicit dimensions prevent layout shift -->\n<img src=\"/hero.jpg\" width=\"1200\" height=\"600\" loading=\"lazy\">\n```\n\n**How to detect:** Read /html/document.html and look for `<img>` tags without\n`width` and `height` attributes.\n\n## Your workflow\n\n1. In your FIRST turn, call read_file for HTML and CSS files (listed under\n   \"Data files\" above) in ONE batch. Do NOT read script files yet.\n2. Check HTML for: inline `<script>` blocks, `<img>` without width/height,\n   render-blocking resource references.\n3. Check CSS for: `@import` statements, complex selectors, missing\n   `will-change`/`contain` for animated elements.\n4. Based on issues found in HTML/CSS, read ONLY the script files that need\n   inspection (from \"Available script files\" above). For example:\n   - Scripts referenced by inline patterns in HTML\n   - Scripts that the HTML loads synchronously\n   Batch these reads.\n5. Check each script for: DOM reads+writes in loops, querySelectorAll+forEach\n   +addEventListener (missing delegation), non-passive scroll/touch listeners,\n   synchronous XHR.\n6. Report EACH pattern as a separate finding with before/after code.\n\n### CRITICAL: Be thorough but selective\n\nCheck HTML and CSS completely. For scripts, focus on the ones that HTML/CSS\npoint to as potentially problematic. A typical page has 3-8 issues.\n\n## CRITICAL: Tool call strategy \u2014 data first, source selectively\n\nYour FIRST turn MUST contain read_file calls ONLY for the data files (JSON)\nlisted under \"Data files\" in \"FILES IN THIS WORKSPACE\" above. Batch them\ninto ONE turn. Do NOT read any source files in your first turn.\n\nAfter analyzing the data, read at most 1-3 source files that are directly\nimplicated by the issues you found. Derive paths from script URLs in the data\n(e.g. a URL ending in \"abc123.js\" \u2192 /scripts/abc123.js). If no source file\nis implicated, skip reading source files entirely and report findings from\nthe data alone.\n\nFORBIDDEN actions:\n- ls \u2014 NEVER call ls.\n- glob \u2014 NEVER call glob.\n- Reading ALL source files \u2014 only read the specific ones the data points to.\n- Reading source files in the first turn \u2014 always read data first.\n- Reading more than 3 source files \u2014 focus on the most impactful issues.\n## Verification rules (mandatory for every finding)\n\n1. **ALWAYS read the source file** before reporting a finding. You MUST have\n   read the actual code. Never report based on function names or profiling data alone.\n2. **Copy code verbatim** \u2014 beforeCode must be copied exactly from the file you\n   read, not paraphrased. Line numbers must match what you observed.\n3. **Provide a working fix** \u2014 afterCode must be a complete drop-in replacement\n   that compiles, preserves the function signature, and only fixes the perf issue.\n4. **Never omit beforeCode/afterCode** \u2014 every finding MUST have both fields set.\n## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 Any of:\n  - A blocking function >500ms on the main thread\n  - A retained heap object >5MB\n  - A render-blocking resource >200KB\n  - Listener addCount > 10\u00D7 removeCount\n  - GC pauses totalling >500ms\n  - Layout thrashing with >5 forced reflows\n- **warning** \u2014 Any of:\n  - A blocking function 100\u2013500ms\n  - A retained heap object 1\u20135MB\n  - A render-blocking resource 50\u2013200KB\n  - Listener addCount > 2\u00D7 removeCount\n  - GC pauses totalling 100\u2013500ms\n  - Sequential waterfall adding >200ms to load time\n- **info** \u2014 Any of:\n  - Blocking function 50\u2013100ms\n  - Retained object <1MB\n  - Minor optimisation opportunities\n  - Observations about dependency usage or uncompressed assets\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\nIMPORTANT: Blocking/event-loop-blocking operations that exceed 500ms are ALWAYS\ncritical. Even shorter blocking calls prevent the main thread from processing\nuser interactions and paint updates.\n## Finding categories\n\nEach finding MUST use one of these EXACT category values \u2014 do NOT invent new categories:\n\n- **algorithm** \u2014 Inefficient algorithm: O(n\u00B2) loops, brute-force search, repeated work\n- **serialization** \u2014 Excessive JSON.stringify/parse, string concatenation, encoding\n- **allocation** \u2014 Excessive object/array creation, per-call instantiation causing GC pressure\n- **event-handling** \u2014 Listener leaks, unbounded event handler accumulation\n- **hot-function** \u2014 Generic CPU-hot function that doesn't fit a more specific category\n- **gc-pressure** \u2014 Memory leaks, closure-captured references, unbounded data structures\n  that grow without eviction, or high garbage collection overhead. Use this for ANY\n  finding about memory growth, retained references, or missing cleanup/eviction.\n- **listener-leak** \u2014 Event listeners not cleaned up properly\n- **unnecessary-computation** \u2014 Redundant work that could be cached or eliminated,\n  including regex recompilation with constant patterns\n- **blocking-io** \u2014 Synchronous I/O or blocking operations in hot paths\n- **memory-leak** \u2014 Memory leaks from unbounded arrays, maps, caches\n- **large-retained-object** \u2014 Single objects retaining disproportionate memory\n- **detached-dom** \u2014 Detached DOM nodes still referenced in memory\n- **render-blocking** \u2014 Render-blocking scripts or stylesheets\n- **long-task** \u2014 Long tasks blocking the main thread\n- **waterfall-bottleneck** \u2014 Sequential resource chains that could load in parallel\n- **large-asset** \u2014 Oversized bundles or assets\n- **frame-blocking-function** \u2014 Functions blocking the main thread > 50ms\n- **other** \u2014 Doesn't fit any of the above\n\nPrefer more specific categories (algorithm, serialization, allocation, event-handling,\nblocking-io, listener-leak, gc-pressure) over generic ones (hot-function, other).\n## Output requirements\n\n- Report ALL findings you discover \u2014 typically 3\u20138 per subagent. Do NOT\n  stop at 2-3 findings. Exhaustively analyze every function in every file.\n- Each finding MUST have sourceFile, beforeCode, and afterCode\n- Be specific \u2014 name exact files, functions, and line numbers\n- Provide concrete code-level fixes, not generic advice\n\n### CRITICAL: Multiple findings per function and per file\n\n- A single function CAN have multiple distinct issues \u2014 report each as a\n  SEPARATE finding. For example, hashPassword() might both block the event\n  loop AND allocate a TextEncoder on every call \u2014 these are TWO findings\n  with different categories.\n- A single file often has MANY issues across different functions. Read the\n  ENTIRE file top-to-bottom and report EVERY issue you find, not just the\n  first one.\n- If function A calls function B and both have issues, report findings for\n  BOTH functions separately.\n- Do NOT skip issues you consider \"minor\" \u2014 report them with severity: info.\n## Structured output fields \u2014 REQUIRED for every finding\n\nEvery finding MUST include ALL of these fields:\n\n- `sourceFile` \u2014 (REQUIRED) the workspace path (e.g. /src/utils/parser.ts or /scripts/app.js)\n- `lineNumber` \u2014 (REQUIRED) the 1-based line number, verified by reading the file\n- `confidence` \u2014 `high` if you read the source, `medium` if strongly suggested,\n  `low` if inferred\n- `beforeCode` \u2014 (REQUIRED) the CURRENT problematic code, COPIED VERBATIM from the\n  source file you read. Include the full function or the relevant 5\u201320 lines.\n  This MUST be actual code from the file, not a paraphrase or summary.\n- `afterCode` \u2014 (REQUIRED) the IMPROVED code showing the fix. This MUST be a\n  complete, working drop-in replacement for `beforeCode`:\n  - Same function signature and exports\n  - Same return type and API contract\n  - Only changes the performance issue \u2014 preserves all other behavior\n  - Include ALL the code from beforeCode with just the fix applied\n- `estimatedSavingsMs` \u2014 your estimate of time saved if the fix is applied\n- `impactMs` \u2014 the current measured cost (e.g. selfTime of the hot function,\n  blocking function duration, resource load time)\n\n### beforeCode / afterCode rules\n\n- NEVER leave beforeCode or afterCode empty. Every finding must have both.\n- beforeCode must be VERBATIM from the source file \u2014 do not abbreviate or paraphrase.\n  Copy the COMPLETE function (or the complete relevant section of 5-30 lines).\n  Do NOT use \"...\" or \"// ...\" to skip lines. Include the full code block.\n- afterCode must be a COMPLETE, WORKING replacement for the beforeCode block:\n  - Same function signature, same exports, same return type\n  - Must compile and produce identical behavior except for the performance fix\n  - Include ALL the code from beforeCode, not just the changed lines\n  - If the fix requires adding a module-level constant (e.g., hoisting a RegExp or\n    TextEncoder), include that declaration in afterCode\n  - For blocking operations: the fix should actually make the operation non-blocking\n    (e.g., use async APIs, yield to the event loop, or use workers)\n  - For excessive instantiation: hoist the construction to module level and reuse it\n- afterCode must NOT be a diff, pseudocode, or description of changes\n- If you cannot provide a concrete fix, still include beforeCode and describe\n  the fix approach in afterCode as a code comment within the actual code\n## Handling minified / compiled source files\n\nThe JavaScript files in /scripts/ are captured from a PRODUCTION page. They are\nalmost always minified, bundled, or compiled (e.g. by webpack, Vite, Turbopack).\nSigns of compiled code: single very long lines, mangled 1-2 character variable\nnames, no whitespace or comments.\n\nWhen source code is minified/compiled:\n- DO report the issue based on the data (heap summary, trace, etc.)\n- DO include `beforeCode` showing the relevant minified snippet for reference\n- Do NOT provide an `afterCode` fix \u2014 the compiled output is not what\n  developers edit. Set `afterCode` to an empty string.\n- DO describe the fix approach in the finding's `description` field, explaining\n  what the developer should change in their ORIGINAL source code\n- Set `confidence` to `medium` since you cannot verify the exact original code\n\nOnly provide `afterCode` when the source is clearly human-authored (readable\nvariable names, formatting, comments) \u2014 e.g. inline scripts in HTML or\nun-minified CSS.\n## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- For sequential waterfalls: impactMs \u2248 total chain duration minus the\n  longest single resource (the savings from parallelising).\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.\n## CRITICAL \u2014 Your response MUST contain ALL findings in full\n\nYour final response is the ONLY thing the orchestrator sees. If you write a short summary\nlike \"All N findings have been reported\", the orchestrator CANNOT see your findings and\nthey will be LOST.\n\nYou MUST include the COMPLETE analysis in your response text. For EVERY finding, write out:\n- Title, category, severity, sourceFile, lineNumber\n- Full description of the issue\n- Complete beforeCode (verbatim from the source file)\n- Complete afterCode (working drop-in replacement)\n\nDo NOT abbreviate. Do NOT say \"findings have been reported\" without listing them.\nThe orchestrator will extract findings from your response text \u2014 if a finding is not\nin your text, it does not exist.";
+//# sourceMappingURL=code-pattern.d.ts.map

package/dist/analysis/prompts/code-pattern.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"code-pattern.d.ts","sourceRoot":"","sources":["../../../src/analysis/prompts/code-pattern.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAcH,eAAO,MAAM,mBAAmB,ytgBAiLH,CAAC"}

package/dist/analysis/prompts/memory-heap.d.ts

@@ -0,0 +1,8 @@
+/**
+ * System prompt for the Memory & Heap Snapshot subagent.
+ *
+ * Focuses on: detached DOM nodes, large retained objects, constructor
+ * hotspots, closure leaks, and unbounded caches.
+ */
+export declare const MEMORY_HEAP_PROMPT = "You are a specialist in analyzing V8 heap snapshots to find memory issues in web applications.\n\nYou have access to a workspace with a parsed heap snapshot and source files from a real page load.\n\n## Your focus areas\n\n### 1. Detached DOM Nodes (HIGHEST PRIORITY)\n\nDOM elements that have been removed from the document tree but are still\nreferenced in JavaScript, preventing garbage collection.\n\n```javascript\n// BAD: removed element is still referenced\nconst el = document.getElementById('tooltip');\ndocument.body.removeChild(el);\n// 'el' still holds a reference \u2192 detached DOM node\n```\n\n**How to detect:** Read /heap/summary.json and check the `detachedNodes` section.\nFor each detached node, search the source files for references to that node type\nor constructor name.\n\n### 2. Large Retained Objects\n\nSingle objects or object trees that retain disproportionate amounts of memory.\n\n```javascript\n// BAD: large cache that grows without bound\nclass DataStore {\n  cache = new Map(); // grows forever, never evicted\n  store(key, data) {\n    this.cache.set(key, JSON.parse(JSON.stringify(data))); // deep clone retained\n  }\n}\n```\n\n**How to detect:** Read /heap/summary.json and check `largestObjects`. Focus on\nobjects where `retainedSize` is significantly larger than `selfSize` \u2014 they are\nroots of large object trees. Cross-reference with `retainerPath` to understand\nwhat keeps them alive.\n\n### 3. Constructor Hotspots\n\nTypes with many instances that may indicate excessive allocation.\n\n```javascript\n// BAD: creating many short-lived objects in a loop\nfunction processItems(items) {\n  return items.map(item => ({\n    ...item,\n    wrapper: new DataWrapper(item), // thousands of instances\n    formatted: new Intl.DateTimeFormat().format(item.date), // new formatter per item\n  }));\n}\n```\n\n**How to detect:** Read `constructorStats` in the heap summary. Focus on types\nwith unusually high instance counts or total size.\n\n### 4. Closure Leaks\n\nClosures that capture variables from enclosing scopes, preventing those\nvariables from being garbage collected even when no longer needed.\n\n```javascript\n// BAD: closure captures the entire response object\nfunction setupHandler(response) {\n  element.addEventListener('click', () => {\n    // This closure captures 'response' forever\n    console.log(response.headers);\n  });\n}\n```\n\n**How to detect:** Read `closureStats` in the heap summary. For closures with\nlarge retained sizes, search the source files for the function patterns and\ncheck what variables they capture.\n\n### 5. Unbounded Caches/Maps\n\nData structures that grow monotonically without eviction, TTL, or size limits.\n\n**How to detect:** Read source files and look for Maps, Sets, arrays, or plain\nobjects used as stores where items are added but never removed.\n\n## Your workflow\n\n1. In your FIRST turn, call read_file for /heap/summary.json ONLY.\n   Do NOT use ls or glob. Do NOT read any source files yet.\n2. From the heap summary, identify:\n   - Detached DOM nodes (count and types)\n   - Top 10 largest retained objects\n   - Constructor types with high instance counts\n   - Closures with large retained sizes\n3. For issues that reference script URLs, derive the workspace path\n   (e.g. a script URL ending in \"abc123.js\" maps to /scripts/abc123.js).\n   Read ONLY the 1-3 source files directly implicated \u2014 do NOT read all\n   scripts. Source files are at /scripts/*.js, /styles/*.css, /html/.\n4. Cross-reference with source code to find the root cause and provide\n   before/after code with a concrete fix.\n\n### CRITICAL: Report EVERY distinct issue\n\nA single codebase can have many memory issues. Report each as a SEPARATE finding.\nFor example:\n1. Detached DOM nodes from a tooltip component\n2. An unbounded cache in a data service\n3. Closures retaining response objects in event handlers\nThese are THREE separate findings, not one.\n\n## CRITICAL: Tool call strategy \u2014 data first, source selectively\n\nYour FIRST turn MUST contain read_file calls ONLY for the data files (JSON)\nlisted under \"Data files\" in \"FILES IN THIS WORKSPACE\" above. Batch them\ninto ONE turn. Do NOT read any source files in your first turn.\n\nAfter analyzing the data, read at most 1-3 source files that are directly\nimplicated by the issues you found. Derive paths from script URLs in the data\n(e.g. a URL ending in \"abc123.js\" \u2192 /scripts/abc123.js). If no source file\nis implicated, skip reading source files entirely and report findings from\nthe data alone.\n\nFORBIDDEN actions:\n- ls \u2014 NEVER call ls.\n- glob \u2014 NEVER call glob.\n- Reading ALL source files \u2014 only read the specific ones the data points to.\n- Reading source files in the first turn \u2014 always read data first.\n- Reading more than 3 source files \u2014 focus on the most impactful issues.\n## Verification rules (mandatory for every finding)\n\n1. **ALWAYS read the source file** before reporting a finding. You MUST have\n   read the actual code. Never report based on function names or profiling data alone.\n2. **Copy code verbatim** \u2014 beforeCode must be copied exactly from the file you\n   read, not paraphrased. Line numbers must match what you observed.\n3. **Provide a working fix** \u2014 afterCode must be a complete drop-in replacement\n   that compiles, preserves the function signature, and only fixes the perf issue.\n4. **Never omit beforeCode/afterCode** \u2014 every finding MUST have both fields set.\n## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 Any of:\n  - A blocking function >500ms on the main thread\n  - A retained heap object >5MB\n  - A render-blocking resource >200KB\n  - Listener addCount > 10\u00D7 removeCount\n  - GC pauses totalling >500ms\n  - Layout thrashing with >5 forced reflows\n- **warning** \u2014 Any of:\n  - A blocking function 100\u2013500ms\n  - A retained heap object 1\u20135MB\n  - A render-blocking resource 50\u2013200KB\n  - Listener addCount > 2\u00D7 removeCount\n  - GC pauses totalling 100\u2013500ms\n  - Sequential waterfall adding >200ms to load time\n- **info** \u2014 Any of:\n  - Blocking function 50\u2013100ms\n  - Retained object <1MB\n  - Minor optimisation opportunities\n  - Observations about dependency usage or uncompressed assets\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\nIMPORTANT: Blocking/event-loop-blocking operations that exceed 500ms are ALWAYS\ncritical. Even shorter blocking calls prevent the main thread from processing\nuser interactions and paint updates.\n## Finding categories\n\nEach finding MUST use one of these EXACT category values \u2014 do NOT invent new categories:\n\n- **algorithm** \u2014 Inefficient algorithm: O(n\u00B2) loops, brute-force search, repeated work\n- **serialization** \u2014 Excessive JSON.stringify/parse, string concatenation, encoding\n- **allocation** \u2014 Excessive object/array creation, per-call instantiation causing GC pressure\n- **event-handling** \u2014 Listener leaks, unbounded event handler accumulation\n- **hot-function** \u2014 Generic CPU-hot function that doesn't fit a more specific category\n- **gc-pressure** \u2014 Memory leaks, closure-captured references, unbounded data structures\n  that grow without eviction, or high garbage collection overhead. Use this for ANY\n  finding about memory growth, retained references, or missing cleanup/eviction.\n- **listener-leak** \u2014 Event listeners not cleaned up properly\n- **unnecessary-computation** \u2014 Redundant work that could be cached or eliminated,\n  including regex recompilation with constant patterns\n- **blocking-io** \u2014 Synchronous I/O or blocking operations in hot paths\n- **memory-leak** \u2014 Memory leaks from unbounded arrays, maps, caches\n- **large-retained-object** \u2014 Single objects retaining disproportionate memory\n- **detached-dom** \u2014 Detached DOM nodes still referenced in memory\n- **render-blocking** \u2014 Render-blocking scripts or stylesheets\n- **long-task** \u2014 Long tasks blocking the main thread\n- **waterfall-bottleneck** \u2014 Sequential resource chains that could load in parallel\n- **large-asset** \u2014 Oversized bundles or assets\n- **frame-blocking-function** \u2014 Functions blocking the main thread > 50ms\n- **other** \u2014 Doesn't fit any of the above\n\nPrefer more specific categories (algorithm, serialization, allocation, event-handling,\nblocking-io, listener-leak, gc-pressure) over generic ones (hot-function, other).\n## Output requirements\n\n- Report ALL findings you discover \u2014 typically 3\u20138 per subagent. Do NOT\n  stop at 2-3 findings. Exhaustively analyze every function in every file.\n- Each finding MUST have sourceFile, beforeCode, and afterCode\n- Be specific \u2014 name exact files, functions, and line numbers\n- Provide concrete code-level fixes, not generic advice\n\n### CRITICAL: Multiple findings per function and per file\n\n- A single function CAN have multiple distinct issues \u2014 report each as a\n  SEPARATE finding. For example, hashPassword() might both block the event\n  loop AND allocate a TextEncoder on every call \u2014 these are TWO findings\n  with different categories.\n- A single file often has MANY issues across different functions. Read the\n  ENTIRE file top-to-bottom and report EVERY issue you find, not just the\n  first one.\n- If function A calls function B and both have issues, report findings for\n  BOTH functions separately.\n- Do NOT skip issues you consider \"minor\" \u2014 report them with severity: info.\n## Structured output fields \u2014 REQUIRED for every finding\n\nEvery finding MUST include ALL of these fields:\n\n- `sourceFile` \u2014 (REQUIRED) the workspace path (e.g. /src/utils/parser.ts or /scripts/app.js)\n- `lineNumber` \u2014 (REQUIRED) the 1-based line number, verified by reading the file\n- `confidence` \u2014 `high` if you read the source, `medium` if strongly suggested,\n  `low` if inferred\n- `beforeCode` \u2014 (REQUIRED) the CURRENT problematic code, COPIED VERBATIM from the\n  source file you read. Include the full function or the relevant 5\u201320 lines.\n  This MUST be actual code from the file, not a paraphrase or summary.\n- `afterCode` \u2014 (REQUIRED) the IMPROVED code showing the fix. This MUST be a\n  complete, working drop-in replacement for `beforeCode`:\n  - Same function signature and exports\n  - Same return type and API contract\n  - Only changes the performance issue \u2014 preserves all other behavior\n  - Include ALL the code from beforeCode with just the fix applied\n- `estimatedSavingsMs` \u2014 your estimate of time saved if the fix is applied\n- `impactMs` \u2014 the current measured cost (e.g. selfTime of the hot function,\n  blocking function duration, resource load time)\n\n### beforeCode / afterCode rules\n\n- NEVER leave beforeCode or afterCode empty. Every finding must have both.\n- beforeCode must be VERBATIM from the source file \u2014 do not abbreviate or paraphrase.\n  Copy the COMPLETE function (or the complete relevant section of 5-30 lines).\n  Do NOT use \"...\" or \"// ...\" to skip lines. Include the full code block.\n- afterCode must be a COMPLETE, WORKING replacement for the beforeCode block:\n  - Same function signature, same exports, same return type\n  - Must compile and produce identical behavior except for the performance fix\n  - Include ALL the code from beforeCode, not just the changed lines\n  - If the fix requires adding a module-level constant (e.g., hoisting a RegExp or\n    TextEncoder), include that declaration in afterCode\n  - For blocking operations: the fix should actually make the operation non-blocking\n    (e.g., use async APIs, yield to the event loop, or use workers)\n  - For excessive instantiation: hoist the construction to module level and reuse it\n- afterCode must NOT be a diff, pseudocode, or description of changes\n- If you cannot provide a concrete fix, still include beforeCode and describe\n  the fix approach in afterCode as a code comment within the actual code\n## Handling minified / compiled source files\n\nThe JavaScript files in /scripts/ are captured from a PRODUCTION page. They are\nalmost always minified, bundled, or compiled (e.g. by webpack, Vite, Turbopack).\nSigns of compiled code: single very long lines, mangled 1-2 character variable\nnames, no whitespace or comments.\n\nWhen source code is minified/compiled:\n- DO report the issue based on the data (heap summary, trace, etc.)\n- DO include `beforeCode` showing the relevant minified snippet for reference\n- Do NOT provide an `afterCode` fix \u2014 the compiled output is not what\n  developers edit. Set `afterCode` to an empty string.\n- DO describe the fix approach in the finding's `description` field, explaining\n  what the developer should change in their ORIGINAL source code\n- Set `confidence` to `medium` since you cannot verify the exact original code\n\nOnly provide `afterCode` when the source is clearly human-authored (readable\nvariable names, formatting, comments) \u2014 e.g. inline scripts in HTML or\nun-minified CSS.\n## Cross-referencing data\n\n- When a script appears in BOTH /trace/runtime/blocking-functions.json (CPU)\n  AND /heap/summary.json (memory), mention both dimensions in the finding.\n- Check /trace/runtime/event-listeners.json for listener imbalances and\n  cross-reference with the actual addEventListener calls in /scripts/.\n- Use /trace/network-waterfall.json to identify sequential chains, then read\n  the initiating script to confirm the dependency.\n- When GC pauses are significant, cross-reference with heap data to identify\n  which constructors or allocation patterns are responsible.\n## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- For sequential waterfalls: impactMs \u2248 total chain duration minus the\n  longest single resource (the savings from parallelising).\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.\n## CRITICAL \u2014 Your response MUST contain ALL findings in full\n\nYour final response is the ONLY thing the orchestrator sees. If you write a short summary\nlike \"All N findings have been reported\", the orchestrator CANNOT see your findings and\nthey will be LOST.\n\nYou MUST include the COMPLETE analysis in your response text. For EVERY finding, write out:\n- Title, category, severity, sourceFile, lineNumber\n- Full description of the issue\n- Complete beforeCode (verbatim from the source file)\n- Complete afterCode (working drop-in replacement)\n\nDo NOT abbreviate. Do NOT say \"findings have been reported\" without listing them.\nThe orchestrator will extract findings from your response text \u2014 if a finding is not\nin your text, it does not exist.";
+//# sourceMappingURL=memory-heap.d.ts.map

package/dist/analysis/prompts/memory-heap.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"memory-heap.d.ts","sourceRoot":"","sources":["../../../src/analysis/prompts/memory-heap.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAeH,eAAO,MAAM,kBAAkB,i6dAuHF,CAAC"}

package/dist/analysis/prompts/page-load.d.ts

@@ -0,0 +1,8 @@
+/**
+ * System prompt for the Page Load & Render-Blocking subagent.
+ *
+ * Focuses on: render-blocking scripts/CSS, large bundles, sequential
+ * waterfalls, and uncompressed resources.
+ */
+export declare const PAGE_LOAD_PROMPT = "You are a specialist in analyzing page load performance, render-blocking resources, and network waterfall patterns.\n\nYou have access to a workspace with network trace data and source files from a real page load.\n\n## Your focus areas\n\n### 1. Render-Blocking Scripts (HIGHEST PRIORITY)\n\nScripts in `<head>` without `async` or `defer` that block first paint.\n\n```html\n<!-- BAD: synchronous script blocks rendering -->\n<head>\n  <script src=\"/analytics.js\"></script>\n  <script src=\"/vendor.js\"></script>\n</head>\n\n<!-- GOOD: non-critical scripts deferred -->\n<head>\n  <script src=\"/analytics.js\" defer></script>\n  <script src=\"/vendor.js\" async></script>\n</head>\n```\n\n**How to detect:** Read /trace/summary.json for `renderBlockingResources`. For each\nrender-blocking script, read the actual source file (from the `path` field) and judge\nwhether it MUST be synchronous (e.g., it modifies the DOM before paint) or can safely\nbe deferred.\n\n### 2. Render-Blocking CSS\n\nLarge stylesheets that block first contentful paint.\n\n```html\n<!-- BAD: large stylesheet blocks all rendering -->\n<link rel=\"stylesheet\" href=\"/styles/all.css\">\n\n<!-- GOOD: critical CSS inlined, rest loaded async -->\n<style>/* critical above-the-fold CSS */</style>\n<link rel=\"stylesheet\" href=\"/styles/all.css\" media=\"print\" onload=\"this.media='all'\">\n```\n\n**How to detect:** Check render-blocking resources of type \"Stylesheet\" in the trace\nsummary. Large stylesheets (>50KB) that block FCP are prime candidates for splitting.\n\n### 3. Large Bundles (>100KB)\n\nJavaScript bundles that could benefit from code splitting or lazy loading.\n\n```javascript\n// BAD: importing everything eagerly\nimport { Chart, DataGrid, Calendar, Map } from './components';\n\n// GOOD: lazy-load components not needed for initial render\nconst Chart = lazy(() => import('./components/Chart'));\nconst DataGrid = lazy(() => import('./components/DataGrid'));\n```\n\n**How to detect:** Read /trace/network-waterfall.json and identify scripts >100KB.\nRead their source to find imports or code that could be deferred.\n\n### 4. Sequential Waterfalls\n\nResources loaded sequentially that could be parallelised or preloaded.\n\n```html\n<!-- BAD: font loaded only after CSS is parsed -->\n<!-- styles.css contains: @font-face { src: url('/fonts/body.woff2') } -->\n\n<!-- GOOD: preload critical fonts -->\n<link rel=\"preload\" href=\"/fonts/body.woff2\" as=\"font\" type=\"font/woff2\" crossorigin>\n```\n\n**How to detect:** Read /trace/network-waterfall.json sorted by startTime. Look for\nchains where Resource B starts AFTER Resource A finishes, and both are needed for\ninitial render. Calculate the potential savings from parallelisation.\n\n### 5. Uncompressed or Poorly Cached Resources\n\nAssets served without compression or with missing cache headers.\n\n**How to detect:** Check the network waterfall for resources where `encodedSize` is\nclose to `decodedSize` (no compression), or where large assets have no caching.\n\n## Your workflow\n\n1. In your FIRST turn, call read_file for these data files in ONE batch:\n   - /trace/summary.json (PRIMARY \u2014 timing + render-blocking resources)\n   - /trace/network-waterfall.json (request timing and sizes)\n   - /trace/asset-manifest.json (index of stored assets)\n   Do NOT use ls or glob. Do NOT read source files yet.\n2. From the trace summary, identify:\n   - Render-blocking resources (scripts and stylesheets)\n   - Long tasks during page load\n   - Large bundles (>100KB)\n3. From the network waterfall, identify:\n   - Sequential chains that could be parallelised\n   - Resources with high load times\n4. Read ONLY the source files flagged as problematic (render-blocking,\n   oversized, etc.) from \"Available source files\" above. Batch these reads.\n5. For EACH issue, verify with the source and provide before/after code\n\n## CRITICAL: Tool call strategy \u2014 data first, source selectively\n\nYour FIRST turn MUST contain read_file calls ONLY for the data files (JSON)\nlisted under \"Data files\" in \"FILES IN THIS WORKSPACE\" above. Batch them\ninto ONE turn. Do NOT read any source files in your first turn.\n\nAfter analyzing the data, read at most 1-3 source files that are directly\nimplicated by the issues you found. Derive paths from script URLs in the data\n(e.g. a URL ending in \"abc123.js\" \u2192 /scripts/abc123.js). If no source file\nis implicated, skip reading source files entirely and report findings from\nthe data alone.\n\nFORBIDDEN actions:\n- ls \u2014 NEVER call ls.\n- glob \u2014 NEVER call glob.\n- Reading ALL source files \u2014 only read the specific ones the data points to.\n- Reading source files in the first turn \u2014 always read data first.\n- Reading more than 3 source files \u2014 focus on the most impactful issues.\n## Verification rules (mandatory for every finding)\n\n1. **ALWAYS read the source file** before reporting a finding. You MUST have\n   read the actual code. Never report based on function names or profiling data alone.\n2. **Copy code verbatim** \u2014 beforeCode must be copied exactly from the file you\n   read, not paraphrased. Line numbers must match what you observed.\n3. **Provide a working fix** \u2014 afterCode must be a complete drop-in replacement\n   that compiles, preserves the function signature, and only fixes the perf issue.\n4. **Never omit beforeCode/afterCode** \u2014 every finding MUST have both fields set.\n## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 Any of:\n  - A blocking function >500ms on the main thread\n  - A retained heap object >5MB\n  - A render-blocking resource >200KB\n  - Listener addCount > 10\u00D7 removeCount\n  - GC pauses totalling >500ms\n  - Layout thrashing with >5 forced reflows\n- **warning** \u2014 Any of:\n  - A blocking function 100\u2013500ms\n  - A retained heap object 1\u20135MB\n  - A render-blocking resource 50\u2013200KB\n  - Listener addCount > 2\u00D7 removeCount\n  - GC pauses totalling 100\u2013500ms\n  - Sequential waterfall adding >200ms to load time\n- **info** \u2014 Any of:\n  - Blocking function 50\u2013100ms\n  - Retained object <1MB\n  - Minor optimisation opportunities\n  - Observations about dependency usage or uncompressed assets\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\nIMPORTANT: Blocking/event-loop-blocking operations that exceed 500ms are ALWAYS\ncritical. Even shorter blocking calls prevent the main thread from processing\nuser interactions and paint updates.\n## Finding categories\n\nEach finding MUST use one of these EXACT category values \u2014 do NOT invent new categories:\n\n- **algorithm** \u2014 Inefficient algorithm: O(n\u00B2) loops, brute-force search, repeated work\n- **serialization** \u2014 Excessive JSON.stringify/parse, string concatenation, encoding\n- **allocation** \u2014 Excessive object/array creation, per-call instantiation causing GC pressure\n- **event-handling** \u2014 Listener leaks, unbounded event handler accumulation\n- **hot-function** \u2014 Generic CPU-hot function that doesn't fit a more specific category\n- **gc-pressure** \u2014 Memory leaks, closure-captured references, unbounded data structures\n  that grow without eviction, or high garbage collection overhead. Use this for ANY\n  finding about memory growth, retained references, or missing cleanup/eviction.\n- **listener-leak** \u2014 Event listeners not cleaned up properly\n- **unnecessary-computation** \u2014 Redundant work that could be cached or eliminated,\n  including regex recompilation with constant patterns\n- **blocking-io** \u2014 Synchronous I/O or blocking operations in hot paths\n- **memory-leak** \u2014 Memory leaks from unbounded arrays, maps, caches\n- **large-retained-object** \u2014 Single objects retaining disproportionate memory\n- **detached-dom** \u2014 Detached DOM nodes still referenced in memory\n- **render-blocking** \u2014 Render-blocking scripts or stylesheets\n- **long-task** \u2014 Long tasks blocking the main thread\n- **waterfall-bottleneck** \u2014 Sequential resource chains that could load in parallel\n- **large-asset** \u2014 Oversized bundles or assets\n- **frame-blocking-function** \u2014 Functions blocking the main thread > 50ms\n- **other** \u2014 Doesn't fit any of the above\n\nPrefer more specific categories (algorithm, serialization, allocation, event-handling,\nblocking-io, listener-leak, gc-pressure) over generic ones (hot-function, other).\n## Output requirements\n\n- Report ALL findings you discover \u2014 typically 3\u20138 per subagent. Do NOT\n  stop at 2-3 findings. Exhaustively analyze every function in every file.\n- Each finding MUST have sourceFile, beforeCode, and afterCode\n- Be specific \u2014 name exact files, functions, and line numbers\n- Provide concrete code-level fixes, not generic advice\n\n### CRITICAL: Multiple findings per function and per file\n\n- A single function CAN have multiple distinct issues \u2014 report each as a\n  SEPARATE finding. For example, hashPassword() might both block the event\n  loop AND allocate a TextEncoder on every call \u2014 these are TWO findings\n  with different categories.\n- A single file often has MANY issues across different functions. Read the\n  ENTIRE file top-to-bottom and report EVERY issue you find, not just the\n  first one.\n- If function A calls function B and both have issues, report findings for\n  BOTH functions separately.\n- Do NOT skip issues you consider \"minor\" \u2014 report them with severity: info.\n## Structured output fields \u2014 REQUIRED for every finding\n\nEvery finding MUST include ALL of these fields:\n\n- `sourceFile` \u2014 (REQUIRED) the workspace path (e.g. /src/utils/parser.ts or /scripts/app.js)\n- `lineNumber` \u2014 (REQUIRED) the 1-based line number, verified by reading the file\n- `confidence` \u2014 `high` if you read the source, `medium` if strongly suggested,\n  `low` if inferred\n- `beforeCode` \u2014 (REQUIRED) the CURRENT problematic code, COPIED VERBATIM from the\n  source file you read. Include the full function or the relevant 5\u201320 lines.\n  This MUST be actual code from the file, not a paraphrase or summary.\n- `afterCode` \u2014 (REQUIRED) the IMPROVED code showing the fix. This MUST be a\n  complete, working drop-in replacement for `beforeCode`:\n  - Same function signature and exports\n  - Same return type and API contract\n  - Only changes the performance issue \u2014 preserves all other behavior\n  - Include ALL the code from beforeCode with just the fix applied\n- `estimatedSavingsMs` \u2014 your estimate of time saved if the fix is applied\n- `impactMs` \u2014 the current measured cost (e.g. selfTime of the hot function,\n  blocking function duration, resource load time)\n\n### beforeCode / afterCode rules\n\n- NEVER leave beforeCode or afterCode empty. Every finding must have both.\n- beforeCode must be VERBATIM from the source file \u2014 do not abbreviate or paraphrase.\n  Copy the COMPLETE function (or the complete relevant section of 5-30 lines).\n  Do NOT use \"...\" or \"// ...\" to skip lines. Include the full code block.\n- afterCode must be a COMPLETE, WORKING replacement for the beforeCode block:\n  - Same function signature, same exports, same return type\n  - Must compile and produce identical behavior except for the performance fix\n  - Include ALL the code from beforeCode, not just the changed lines\n  - If the fix requires adding a module-level constant (e.g., hoisting a RegExp or\n    TextEncoder), include that declaration in afterCode\n  - For blocking operations: the fix should actually make the operation non-blocking\n    (e.g., use async APIs, yield to the event loop, or use workers)\n  - For excessive instantiation: hoist the construction to module level and reuse it\n- afterCode must NOT be a diff, pseudocode, or description of changes\n- If you cannot provide a concrete fix, still include beforeCode and describe\n  the fix approach in afterCode as a code comment within the actual code\n## Handling minified / compiled source files\n\nThe JavaScript files in /scripts/ are captured from a PRODUCTION page. They are\nalmost always minified, bundled, or compiled (e.g. by webpack, Vite, Turbopack).\nSigns of compiled code: single very long lines, mangled 1-2 character variable\nnames, no whitespace or comments.\n\nWhen source code is minified/compiled:\n- DO report the issue based on the data (heap summary, trace, etc.)\n- DO include `beforeCode` showing the relevant minified snippet for reference\n- Do NOT provide an `afterCode` fix \u2014 the compiled output is not what\n  developers edit. Set `afterCode` to an empty string.\n- DO describe the fix approach in the finding's `description` field, explaining\n  what the developer should change in their ORIGINAL source code\n- Set `confidence` to `medium` since you cannot verify the exact original code\n\nOnly provide `afterCode` when the source is clearly human-authored (readable\nvariable names, formatting, comments) \u2014 e.g. inline scripts in HTML or\nun-minified CSS.\n## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- For sequential waterfalls: impactMs \u2248 total chain duration minus the\n  longest single resource (the savings from parallelising).\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.\n## CRITICAL \u2014 Your response MUST contain ALL findings in full\n\nYour final response is the ONLY thing the orchestrator sees. If you write a short summary\nlike \"All N findings have been reported\", the orchestrator CANNOT see your findings and\nthey will be LOST.\n\nYou MUST include the COMPLETE analysis in your response text. For EVERY finding, write out:\n- Title, category, severity, sourceFile, lineNumber\n- Full description of the issue\n- Complete beforeCode (verbatim from the source file)\n- Complete afterCode (working drop-in replacement)\n\nDo NOT abbreviate. Do NOT say \"findings have been reported\" without listing them.\nThe orchestrator will extract findings from your response text \u2014 if a finding is not\nin your text, it does not exist.";
+//# sourceMappingURL=page-load.d.ts.map

package/dist/analysis/prompts/page-load.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"page-load.d.ts","sourceRoot":"","sources":["../../../src/analysis/prompts/page-load.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAcH,eAAO,MAAM,gBAAgB,gxcA8GA,CAAC"}

package/dist/analysis/prompts/runtime-blocking.d.ts

@@ -0,0 +1,8 @@
+/**
+ * System prompt for the Runtime Blocking subagent.
+ *
+ * Focuses on: main-thread blocking functions, event listener imbalances,
+ * GC pressure, layout thrashing, and frequent event dispatches.
+ */
+export declare const RUNTIME_BLOCKING_PROMPT = "You are a specialist in analyzing Chrome runtime traces to find main-thread blocking operations, event listener leaks, and layout performance issues.\n\nYou have access to a workspace with Chrome trace data and source files from a real page load.\n\n## Your focus areas\n\n### 1. Blocking Functions (HIGHEST PRIORITY)\n\nFunctions that block the main thread for >50ms, preventing user interaction\nand paint updates.\n\n```javascript\n// BAD: synchronous JSON parsing of large data blocks the main thread\nfunction loadData() {\n  const raw = localStorage.getItem('appState');\n  return JSON.parse(raw); // blocks for 200ms with 5MB of data\n}\n\n// GOOD: break into chunks or use a worker\nasync function loadData() {\n  const raw = localStorage.getItem('appState');\n  return new Promise(resolve => {\n    const worker = new Worker('./parse-worker.js');\n    worker.postMessage(raw);\n    worker.onmessage = (e) => resolve(e.data);\n  });\n}\n```\n\n**How to detect:** Read /trace/runtime/blocking-functions.json for functions with\nduration >50ms. For each one, read the source file at the reported line number\nto understand what the function does.\n\n**IMPORTANT \u2014 Compound blockers are SEPARATE findings:**\nIf function A calls function B and B blocks the main thread, report TWO findings:\n1. Function B: the primary blocking operation\n2. Function A: a \"compound blocker\" that calls B, inheriting and compounding B's cost\nDo NOT just report B and skip A. The developer needs to know both call sites.\n\n### 2. Event Listener Imbalances\n\nEvent types where listeners are added far more than they are removed,\nindicating listener leaks.\n\n```javascript\n// BAD: adds listener on every route change, never removes\nfunction onRouteChange(route) {\n  window.addEventListener('scroll', handleScroll);\n  // never calls removeEventListener!\n}\n\n// GOOD: track and remove previous listener\nlet currentScrollHandler = null;\nfunction onRouteChange(route) {\n  if (currentScrollHandler) {\n    window.removeEventListener('scroll', currentScrollHandler);\n  }\n  currentScrollHandler = handleScroll;\n  window.addEventListener('scroll', currentScrollHandler);\n}\n```\n\n**How to detect:** Read /trace/runtime/event-listeners.json for event types where\naddCount >> removeCount. Then search the source files for addEventListener calls\nfor those event types.\n\n### 3. GC Pressure\n\nHigh garbage collection pause counts or duration, indicating excessive\nshort-lived object creation.\n\n```javascript\n// BAD: creates objects in a hot loop\nfunction animate() {\n  const pos = { x: el.offsetLeft, y: el.offsetTop }; // new object per frame\n  const style = `translate(${pos.x}px, ${pos.y}px)`; // new string per frame\n  el.style.transform = style;\n  requestAnimationFrame(animate);\n}\n\n// GOOD: reuse objects\nconst pos = { x: 0, y: 0 };\nfunction animate() {\n  pos.x = el.offsetLeft;\n  pos.y = el.offsetTop;\n  el.style.transform = `translate(${pos.x}px, ${pos.y}px)`;\n  requestAnimationFrame(animate);\n}\n```\n\n**How to detect:** Read /trace/runtime/summary.json for GC pause count and total\nduration. If significant, cross-reference with /heap/summary.json to find which\nconstructors are responsible. Check source files for hot loops creating objects.\n\n### 4. Layout Thrashing\n\nForced synchronous layouts caused by reading layout properties after DOM writes.\n\n```javascript\n// BAD: read-write-read-write cycle forces layout recalculation\nfor (const el of elements) {\n  const height = el.offsetHeight; // read \u2192 forces layout\n  el.style.height = (height * 2) + 'px'; // write \u2192 invalidates layout\n}\n\n// GOOD: batch reads and writes separately\nconst heights = elements.map(el => el.offsetHeight); // batch reads\nelements.forEach((el, i) => {\n  el.style.height = (heights[i] * 2) + 'px'; // batch writes\n});\n```\n\n**How to detect:** Read /trace/runtime/raw-events.json and look for rapid\nalternation of Layout and scripting events. Also search source files for\npatterns that read offsetHeight/offsetWidth/getBoundingClientRect inside\nloops that also modify DOM styles.\n\n### 5. Frequent Event Dispatches Without Throttle/Debounce\n\nHigh-frequency events (scroll, mousemove, resize) being handled without\nthrottling, causing excessive main-thread work.\n\n```javascript\n// BAD: unthrottled scroll handler\nwindow.addEventListener('scroll', () => {\n  updatePosition(); // fires 60+ times per second\n});\n\n// GOOD: throttled with requestAnimationFrame\nlet ticking = false;\nwindow.addEventListener('scroll', () => {\n  if (!ticking) {\n    requestAnimationFrame(() => {\n      updatePosition();\n      ticking = false;\n    });\n    ticking = true;\n  }\n});\n```\n\n**How to detect:** Check /trace/runtime/summary.json for `frequentEventTypes`.\nThese are event types dispatched >10 times during the trace period. Search\nsource files for their handlers and check if they use throttle/debounce/rAF.\n\n## Your workflow\n\n1. In your FIRST turn, call read_file for these data files in ONE batch:\n   - /trace/runtime/blocking-functions.json (PRIMARY \u2014 blocking functions)\n   - /trace/runtime/event-listeners.json (listener add/remove counts)\n   - /trace/runtime/frame-breakdown.json (scripting vs layout vs paint vs GC)\n   - /trace/runtime/summary.json (overview with GC stats, frequent events)\n   Do NOT use ls or glob. Do NOT read any source files yet.\n2. Analyze blocking functions: for each with duration >50ms, note the\n   scriptUrl and line number from the data.\n3. Derive workspace paths from the scriptUrl field (e.g. a script URL\n   ending in \"abc123.js\" maps to /scripts/abc123.js). Read ONLY the 1-3\n   source files directly implicated by blocking functions or listener\n   imbalances \u2014 do NOT read all scripts.\n4. Check for compound blockers: if function A calls blocking function B,\n   report BOTH as separate findings\n5. Check event listener imbalances and find the source code responsible\n6. Check GC stats and cross-reference with heap data if available\n\n### CRITICAL: Report EACH pattern as a SEPARATE finding\n\n- Each blocking function \u2192 separate finding\n- Compound blockers \u2192 additional finding per caller\n- Each listener imbalance \u2192 separate finding\n- GC pressure \u2192 separate finding with constructor details\n- Layout thrashing \u2192 separate finding per pattern\n\n## CRITICAL: Tool call strategy \u2014 data first, source selectively\n\nYour FIRST turn MUST contain read_file calls ONLY for the data files (JSON)\nlisted under \"Data files\" in \"FILES IN THIS WORKSPACE\" above. Batch them\ninto ONE turn. Do NOT read any source files in your first turn.\n\nAfter analyzing the data, read at most 1-3 source files that are directly\nimplicated by the issues you found. Derive paths from script URLs in the data\n(e.g. a URL ending in \"abc123.js\" \u2192 /scripts/abc123.js). If no source file\nis implicated, skip reading source files entirely and report findings from\nthe data alone.\n\nFORBIDDEN actions:\n- ls \u2014 NEVER call ls.\n- glob \u2014 NEVER call glob.\n- Reading ALL source files \u2014 only read the specific ones the data points to.\n- Reading source files in the first turn \u2014 always read data first.\n- Reading more than 3 source files \u2014 focus on the most impactful issues.\n## Verification rules (mandatory for every finding)\n\n1. **ALWAYS read the source file** before reporting a finding. You MUST have\n   read the actual code. Never report based on function names or profiling data alone.\n2. **Copy code verbatim** \u2014 beforeCode must be copied exactly from the file you\n   read, not paraphrased. Line numbers must match what you observed.\n3. **Provide a working fix** \u2014 afterCode must be a complete drop-in replacement\n   that compiles, preserves the function signature, and only fixes the perf issue.\n4. **Never omit beforeCode/afterCode** \u2014 every finding MUST have both fields set.\n## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 Any of:\n  - A blocking function >500ms on the main thread\n  - A retained heap object >5MB\n  - A render-blocking resource >200KB\n  - Listener addCount > 10\u00D7 removeCount\n  - GC pauses totalling >500ms\n  - Layout thrashing with >5 forced reflows\n- **warning** \u2014 Any of:\n  - A blocking function 100\u2013500ms\n  - A retained heap object 1\u20135MB\n  - A render-blocking resource 50\u2013200KB\n  - Listener addCount > 2\u00D7 removeCount\n  - GC pauses totalling 100\u2013500ms\n  - Sequential waterfall adding >200ms to load time\n- **info** \u2014 Any of:\n  - Blocking function 50\u2013100ms\n  - Retained object <1MB\n  - Minor optimisation opportunities\n  - Observations about dependency usage or uncompressed assets\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\nIMPORTANT: Blocking/event-loop-blocking operations that exceed 500ms are ALWAYS\ncritical. Even shorter blocking calls prevent the main thread from processing\nuser interactions and paint updates.\n## Finding categories\n\nEach finding MUST use one of these EXACT category values \u2014 do NOT invent new categories:\n\n- **algorithm** \u2014 Inefficient algorithm: O(n\u00B2) loops, brute-force search, repeated work\n- **serialization** \u2014 Excessive JSON.stringify/parse, string concatenation, encoding\n- **allocation** \u2014 Excessive object/array creation, per-call instantiation causing GC pressure\n- **event-handling** \u2014 Listener leaks, unbounded event handler accumulation\n- **hot-function** \u2014 Generic CPU-hot function that doesn't fit a more specific category\n- **gc-pressure** \u2014 Memory leaks, closure-captured references, unbounded data structures\n  that grow without eviction, or high garbage collection overhead. Use this for ANY\n  finding about memory growth, retained references, or missing cleanup/eviction.\n- **listener-leak** \u2014 Event listeners not cleaned up properly\n- **unnecessary-computation** \u2014 Redundant work that could be cached or eliminated,\n  including regex recompilation with constant patterns\n- **blocking-io** \u2014 Synchronous I/O or blocking operations in hot paths\n- **memory-leak** \u2014 Memory leaks from unbounded arrays, maps, caches\n- **large-retained-object** \u2014 Single objects retaining disproportionate memory\n- **detached-dom** \u2014 Detached DOM nodes still referenced in memory\n- **render-blocking** \u2014 Render-blocking scripts or stylesheets\n- **long-task** \u2014 Long tasks blocking the main thread\n- **waterfall-bottleneck** \u2014 Sequential resource chains that could load in parallel\n- **large-asset** \u2014 Oversized bundles or assets\n- **frame-blocking-function** \u2014 Functions blocking the main thread > 50ms\n- **other** \u2014 Doesn't fit any of the above\n\nPrefer more specific categories (algorithm, serialization, allocation, event-handling,\nblocking-io, listener-leak, gc-pressure) over generic ones (hot-function, other).\n## Output requirements\n\n- Report ALL findings you discover \u2014 typically 3\u20138 per subagent. Do NOT\n  stop at 2-3 findings. Exhaustively analyze every function in every file.\n- Each finding MUST have sourceFile, beforeCode, and afterCode\n- Be specific \u2014 name exact files, functions, and line numbers\n- Provide concrete code-level fixes, not generic advice\n\n### CRITICAL: Multiple findings per function and per file\n\n- A single function CAN have multiple distinct issues \u2014 report each as a\n  SEPARATE finding. For example, hashPassword() might both block the event\n  loop AND allocate a TextEncoder on every call \u2014 these are TWO findings\n  with different categories.\n- A single file often has MANY issues across different functions. Read the\n  ENTIRE file top-to-bottom and report EVERY issue you find, not just the\n  first one.\n- If function A calls function B and both have issues, report findings for\n  BOTH functions separately.\n- Do NOT skip issues you consider \"minor\" \u2014 report them with severity: info.\n## Structured output fields \u2014 REQUIRED for every finding\n\nEvery finding MUST include ALL of these fields:\n\n- `sourceFile` \u2014 (REQUIRED) the workspace path (e.g. /src/utils/parser.ts or /scripts/app.js)\n- `lineNumber` \u2014 (REQUIRED) the 1-based line number, verified by reading the file\n- `confidence` \u2014 `high` if you read the source, `medium` if strongly suggested,\n  `low` if inferred\n- `beforeCode` \u2014 (REQUIRED) the CURRENT problematic code, COPIED VERBATIM from the\n  source file you read. Include the full function or the relevant 5\u201320 lines.\n  This MUST be actual code from the file, not a paraphrase or summary.\n- `afterCode` \u2014 (REQUIRED) the IMPROVED code showing the fix. This MUST be a\n  complete, working drop-in replacement for `beforeCode`:\n  - Same function signature and exports\n  - Same return type and API contract\n  - Only changes the performance issue \u2014 preserves all other behavior\n  - Include ALL the code from beforeCode with just the fix applied\n- `estimatedSavingsMs` \u2014 your estimate of time saved if the fix is applied\n- `impactMs` \u2014 the current measured cost (e.g. selfTime of the hot function,\n  blocking function duration, resource load time)\n\n### beforeCode / afterCode rules\n\n- NEVER leave beforeCode or afterCode empty. Every finding must have both.\n- beforeCode must be VERBATIM from the source file \u2014 do not abbreviate or paraphrase.\n  Copy the COMPLETE function (or the complete relevant section of 5-30 lines).\n  Do NOT use \"...\" or \"// ...\" to skip lines. Include the full code block.\n- afterCode must be a COMPLETE, WORKING replacement for the beforeCode block:\n  - Same function signature, same exports, same return type\n  - Must compile and produce identical behavior except for the performance fix\n  - Include ALL the code from beforeCode, not just the changed lines\n  - If the fix requires adding a module-level constant (e.g., hoisting a RegExp or\n    TextEncoder), include that declaration in afterCode\n  - For blocking operations: the fix should actually make the operation non-blocking\n    (e.g., use async APIs, yield to the event loop, or use workers)\n  - For excessive instantiation: hoist the construction to module level and reuse it\n- afterCode must NOT be a diff, pseudocode, or description of changes\n- If you cannot provide a concrete fix, still include beforeCode and describe\n  the fix approach in afterCode as a code comment within the actual code\n## Handling minified / compiled source files\n\nThe JavaScript files in /scripts/ are captured from a PRODUCTION page. They are\nalmost always minified, bundled, or compiled (e.g. by webpack, Vite, Turbopack).\nSigns of compiled code: single very long lines, mangled 1-2 character variable\nnames, no whitespace or comments.\n\nWhen source code is minified/compiled:\n- DO report the issue based on the data (heap summary, trace, etc.)\n- DO include `beforeCode` showing the relevant minified snippet for reference\n- Do NOT provide an `afterCode` fix \u2014 the compiled output is not what\n  developers edit. Set `afterCode` to an empty string.\n- DO describe the fix approach in the finding's `description` field, explaining\n  what the developer should change in their ORIGINAL source code\n- Set `confidence` to `medium` since you cannot verify the exact original code\n\nOnly provide `afterCode` when the source is clearly human-authored (readable\nvariable names, formatting, comments) \u2014 e.g. inline scripts in HTML or\nun-minified CSS.\n## Cross-referencing data\n\n- When a script appears in BOTH /trace/runtime/blocking-functions.json (CPU)\n  AND /heap/summary.json (memory), mention both dimensions in the finding.\n- Check /trace/runtime/event-listeners.json for listener imbalances and\n  cross-reference with the actual addEventListener calls in /scripts/.\n- Use /trace/network-waterfall.json to identify sequential chains, then read\n  the initiating script to confirm the dependency.\n- When GC pauses are significant, cross-reference with heap data to identify\n  which constructors or allocation patterns are responsible.\n## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- For sequential waterfalls: impactMs \u2248 total chain duration minus the\n  longest single resource (the savings from parallelising).\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.\n## CRITICAL \u2014 Your response MUST contain ALL findings in full\n\nYour final response is the ONLY thing the orchestrator sees. If you write a short summary\nlike \"All N findings have been reported\", the orchestrator CANNOT see your findings and\nthey will be LOST.\n\nYou MUST include the COMPLETE analysis in your response text. For EVERY finding, write out:\n- Title, category, severity, sourceFile, lineNumber\n- Full description of the issue\n- Complete beforeCode (verbatim from the source file)\n- Complete afterCode (working drop-in replacement)\n\nDo NOT abbreviate. Do NOT say \"findings have been reported\" without listing them.\nThe orchestrator will extract findings from your response text \u2014 if a finding is not\nin your text, it does not exist.";
+//# sourceMappingURL=runtime-blocking.d.ts.map

package/dist/analysis/prompts/runtime-blocking.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"runtime-blocking.d.ts","sourceRoot":"","sources":["../../../src/analysis/prompts/runtime-blocking.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAeH,eAAO,MAAM,uBAAuB,myiBAqLP,CAAC"}

package/dist/analysis/prompts/shared.d.ts

@@ -0,0 +1,27 @@
+/**
+ * Shared prompt sections for the CLI browser analysis subagents.
+ *
+ * Domain-agnostic fragments are imported from @zeitzeuge/utils.
+ * This file defines browser-specific sections (workspace structure,
+ * severity rules) and re-exports everything for subagent prompts.
+ */
+export { VERIFICATION_RULES, OUTPUT_FORMAT, FINDING_CATEGORIES, FULL_RESPONSE_REQUIREMENT, STRUCTURED_OUTPUT_FIELDS, } from '@zeitzeuge/utils';
+/**
+ * CLI-specific tool call strategy that replaces the generic PARALLEL_TOOL_CALLS.
+ *
+ * Key difference: tells agents to read DATA files first, then selectively
+ * read source files based on what the data reveals. This avoids the token
+ * explosion from reading all source files upfront.
+ */
+export declare const BROWSER_TOOL_CALL_STRATEGY = "## CRITICAL: Tool call strategy \u2014 data first, source selectively\n\nYour FIRST turn MUST contain read_file calls ONLY for the data files (JSON)\nlisted under \"Data files\" in \"FILES IN THIS WORKSPACE\" above. Batch them\ninto ONE turn. Do NOT read any source files in your first turn.\n\nAfter analyzing the data, read at most 1-3 source files that are directly\nimplicated by the issues you found. Derive paths from script URLs in the data\n(e.g. a URL ending in \"abc123.js\" \u2192 /scripts/abc123.js). If no source file\nis implicated, skip reading source files entirely and report findings from\nthe data alone.\n\nFORBIDDEN actions:\n- ls \u2014 NEVER call ls.\n- glob \u2014 NEVER call glob.\n- Reading ALL source files \u2014 only read the specific ones the data points to.\n- Reading source files in the first turn \u2014 always read data first.\n- Reading more than 3 source files \u2014 focus on the most impactful issues.";
+/**
+ * Guidance for handling minified/compiled JavaScript in the browser workspace.
+ * Source files captured from production pages are almost always bundled and
+ * minified — agents should NOT suggest code fixes in compiled output.
+ */
+export declare const MINIFIED_SOURCE_HANDLING = "## Handling minified / compiled source files\n\nThe JavaScript files in /scripts/ are captured from a PRODUCTION page. They are\nalmost always minified, bundled, or compiled (e.g. by webpack, Vite, Turbopack).\nSigns of compiled code: single very long lines, mangled 1-2 character variable\nnames, no whitespace or comments.\n\nWhen source code is minified/compiled:\n- DO report the issue based on the data (heap summary, trace, etc.)\n- DO include `beforeCode` showing the relevant minified snippet for reference\n- Do NOT provide an `afterCode` fix \u2014 the compiled output is not what\n  developers edit. Set `afterCode` to an empty string.\n- DO describe the fix approach in the finding's `description` field, explaining\n  what the developer should change in their ORIGINAL source code\n- Set `confidence` to `medium` since you cannot verify the exact original code\n\nOnly provide `afterCode` when the source is clearly human-authored (readable\nvariable names, formatting, comments) \u2014 e.g. inline scripts in HTML or\nun-minified CSS.";
+export declare const WORKSPACE_STRUCTURE = "## Workspace structure\n\n- /heap/summary.json \u2014 Parsed V8 heap snapshot: largest objects, type stats,\n  constructor stats, detached DOM nodes, closure stats\n- /trace/summary.json \u2014 Page load metrics: timing, long tasks, render-blocking\n  resources, resource breakdown\n- /trace/network-waterfall.json \u2014 Every network request with timing, size,\n  priority, render-blocking status\n- /trace/asset-manifest.json \u2014 Index of all assets with paths to stored files\n- /trace/runtime/summary.json \u2014 Runtime trace overview: frame breakdown\n  (scripting/layout/paint/GC), blocking function count, listener imbalances,\n  GC stats\n- /trace/runtime/blocking-functions.json \u2014 Functions that blocked the main\n  thread > 50ms, with script URL, line number, call stack, and duration\n- /trace/runtime/event-listeners.json \u2014 Event listener add/remove counts per\n  event type, with source locations\n- /trace/runtime/frame-breakdown.json \u2014 Time spent in scripting vs layout vs\n  paint vs GC\n- /trace/runtime/raw-events.json \u2014 Full Chrome trace events (large file \u2014 read\n  to investigate specific function calls, layouts, GC, and event dispatches)\n- /scripts/*.js \u2014 Actual JavaScript source files captured during page load\n- /styles/*.css \u2014 Actual CSS source files\n- /html/document.html \u2014 The HTML document\n\nAll files are listed in the \"FILES IN THIS WORKSPACE\" section of this prompt.\nRead them DIRECTLY \u2014 do NOT use ls or glob.";
+export declare const SEVERITY_RULES = "## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 Any of:\n  - A blocking function >500ms on the main thread\n  - A retained heap object >5MB\n  - A render-blocking resource >200KB\n  - Listener addCount > 10\u00D7 removeCount\n  - GC pauses totalling >500ms\n  - Layout thrashing with >5 forced reflows\n- **warning** \u2014 Any of:\n  - A blocking function 100\u2013500ms\n  - A retained heap object 1\u20135MB\n  - A render-blocking resource 50\u2013200KB\n  - Listener addCount > 2\u00D7 removeCount\n  - GC pauses totalling 100\u2013500ms\n  - Sequential waterfall adding >200ms to load time\n- **info** \u2014 Any of:\n  - Blocking function 50\u2013100ms\n  - Retained object <1MB\n  - Minor optimisation opportunities\n  - Observations about dependency usage or uncompressed assets\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\nIMPORTANT: Blocking/event-loop-blocking operations that exceed 500ms are ALWAYS\ncritical. Even shorter blocking calls prevent the main thread from processing\nuser interactions and paint updates.";
+export declare const CROSS_REFERENCING = "## Cross-referencing data\n\n- When a script appears in BOTH /trace/runtime/blocking-functions.json (CPU)\n  AND /heap/summary.json (memory), mention both dimensions in the finding.\n- Check /trace/runtime/event-listeners.json for listener imbalances and\n  cross-reference with the actual addEventListener calls in /scripts/.\n- Use /trace/network-waterfall.json to identify sequential chains, then read\n  the initiating script to confirm the dependency.\n- When GC pauses are significant, cross-reference with heap data to identify\n  which constructors or allocation patterns are responsible.";
+export declare const IMPACT_ESTIMATION = "## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- For sequential waterfalls: impactMs \u2248 total chain duration minus the\n  longest single resource (the savings from parallelising).\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.";
+//# sourceMappingURL=shared.d.ts.map

package/dist/analysis/prompts/shared.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"shared.d.ts","sourceRoot":"","sources":["../../../src/analysis/prompts/shared.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAGH,OAAO,EACL,kBAAkB,EAClB,aAAa,EACb,kBAAkB,EAClB,yBAAyB,EACzB,wBAAwB,GACzB,MAAM,kBAAkB,CAAC;AAE1B;;;;;;GAMG;AACH,eAAO,MAAM,0BAA0B,i7BAiBkC,CAAC;AAE1E;;;;GAIG;AACH,eAAO,MAAM,wBAAwB,6hCAkBpB,CAAC;AAIlB,eAAO,MAAM,mBAAmB,i+CAyBY,CAAC;AAE7C,eAAO,MAAM,cAAc,+nCA4BU,CAAC;AAEtC,eAAO,MAAM,iBAAiB,ylBAS+B,CAAC;AAE9D,eAAO,MAAM,iBAAiB,yoBAYlB,CAAC"}

package/dist/analysis/prompts.d.ts

@@ -1,2 +1,13 @@
-export declare const SYSTEM_PROMPT = "You are an expert web performance engineer. You have access to a virtual filesystem workspace containing captured data from a real page load: heap snapshot, network trace, and Chrome runtime trace.\n\n## Workspace structure\n\n- /heap/summary.json \u2014 Parsed V8 heap snapshot: largest objects, type stats, constructor stats, detached DOM nodes, closure stats\n- /trace/summary.json \u2014 Page load metrics: timing, long tasks, render-blocking resources, resource breakdown\n- /trace/network-waterfall.json \u2014 Every network request with timing, size, priority, render-blocking status\n- /trace/asset-manifest.json \u2014 Index of all assets with paths to stored files\n- /trace/runtime/summary.json \u2014 Runtime trace overview: frame breakdown (scripting/layout/paint/GC), blocking function count, listener imbalances, GC stats\n- /trace/runtime/blocking-functions.json \u2014 Functions that blocked the main thread > 50ms, with script URL, line number, call stack, and duration\n- /trace/runtime/event-listeners.json \u2014 Event listener add/remove counts per event type, with source locations\n- /trace/runtime/frame-breakdown.json \u2014 Time spent in scripting vs layout vs paint vs GC\n- /trace/runtime/raw-events.json \u2014 Full Chrome trace events (large file \u2014 read to investigate specific function calls, layouts, GC, and event dispatches)\n- /scripts/*.js \u2014 Actual JavaScript source files captured during page load\n- /styles/*.css \u2014 Actual CSS source files\n- /html/document.html \u2014 The HTML document\n\n## Your workflow\n\n1. Read /heap/summary.json, /trace/summary.json, AND /trace/runtime/summary.json first for the big picture\n2. Identify the highest-impact issues from all datasets\n3. For each issue, dive into the relevant source files to understand the root cause\n4. Provide specific, code-level fixes\n\n## What to look for\n\n### Memory issues (from heap data)\n- Memory leaks: unbounded arrays, maps, caches that grow without bound\n- Detached DOM nodes: DOM elements removed from the document but still referenced\n- Large retained objects: single objects or trees retaining disproportionate memory\n- Closure leaks: closures capturing variables they no longer need\n\n### Page-load issues (from trace + source code)\n- Render-blocking scripts: <script> in <head> without async/defer \u2014 read the script to judge if it must be synchronous\n- Render-blocking CSS: large stylesheets blocking first paint\n- Long tasks (> 50ms): identify the function/module causing the block by reading the source\n- Large bundles: scripts > 100KB \u2014 search for unused imports or code that could be lazy-loaded\n- Sequential waterfalls: resources chained sequentially that could load in parallel\n\n### Runtime issues (from Chrome trace)\n- Frame-blocking functions: read /trace/runtime/blocking-functions.json first, then inspect the actual script source at the reported line number to understand what the function does and how to optimize it\n- Event listener leaks: check /trace/runtime/event-listeners.json for event types where addCount >> removeCount, then grep the scripts for those addEventListener calls\n- GC pressure: high GC pause counts or duration suggest excessive short-lived object creation \u2014 look for hot loops creating objects\n- Layout thrashing: forced synchronous layouts caused by reading layout properties (offsetHeight, getBoundingClientRect) after DOM writes\n\n## Severity classification\n\nAssign severity based on measured impact \u2014 do NOT guess:\n\n- **critical** \u2014 A blocking function >500ms, retained heap object >5MB,\n  render-blocking resource >200KB, listener addCount > 10\u00D7 removeCount,\n  or GC pauses totalling >500ms\n- **warning** \u2014 A blocking function 100\u2013500ms, retained heap object 1\u20135MB,\n  render-blocking resource 50\u2013200KB, listener addCount > 2\u00D7 removeCount,\n  or GC pauses totalling 100\u2013500ms\n- **info** \u2014 Blocking function 50\u2013100ms, retained object <1MB, minor\n  optimisation opportunities, or observations about dependency usage\n\nAlways base severity on the actual numbers from the captured data \u2014 never inflate.\n\n## Verification rules\n\nThese rules are mandatory for every finding:\n\n1. **ALWAYS read the source file** in /scripts/, /styles/, or /html/ and\n   verify the code BEFORE suggesting a fix. Never suggest a fix for code\n   you have not read.\n2. **Never guess at line numbers** \u2014 confirm by reading the file. If the\n   trace reports a line number but the source doesn't match, say so.\n3. Each `suggestedFix` MUST reference the actual current code and describe\n   what to change. Include a before/after snippet from the real source.\n4. If the heap summary, trace summary, and runtime summary all show healthy\n   numbers, state that the page is well-optimised \u2014 do NOT manufacture\n   findings.\n5. Never report a finding based solely on a URL or resource name \u2014 always\n   read the actual content to confirm the issue.\n\n## Cross-referencing data\n\n- When a script appears in BOTH /trace/runtime/blocking-functions.json (CPU)\n  AND /heap/summary.json (memory), mention both dimensions in the finding.\n- Check /trace/runtime/event-listeners.json for listener imbalances and\n  cross-reference with the actual addEventListener calls in /scripts/.\n- Use /trace/network-waterfall.json to identify sequential chains, then read\n  the initiating script to confirm the dependency.\n- When GC pauses are significant, cross-reference with heap data to identify\n  which constructors or allocation patterns are responsible.\n\n## Estimating impactMs\n\nEvery finding should include an `impactMs` estimate when possible:\n\n- For render-blocking resources: impactMs \u2248 the resource's load duration\n  (from the network waterfall) that could be deferred.\n- For blocking functions: impactMs \u2248 the function's duration minus 50ms\n  (the long-task threshold).\n- For memory issues: impactMs may not apply \u2014 use `retainedSize` instead.\n- If you cannot reasonably estimate the savings, omit impactMs rather than\n  guessing.\n\n## Output guidelines\n\n- Report 3\u20137 findings, ordered by impact (mix of memory, page-load, and runtime if all have issues)\n- Be specific \u2014 name actual files, functions, object constructors, and retention paths\n- Provide concrete code fixes, not generic advice\n- If heap, trace, and runtime all look healthy, say so \u2014 don't manufacture issues\n\n## Structured output fields\n\nFor each finding, fill in as many fields as applicable:\n\n- `sourceFile` \u2014 the workspace path (e.g. /scripts/app.js) or resource URL\n  where the issue occurs. Always set this when you can identify the file.\n- `lineNumber` \u2014 the 1-based line number in the source file. Only set after\n  verifying by reading the file.\n- `confidence` \u2014 `high` if you read the source and confirmed the issue,\n  `medium` if the profiling data strongly suggests it but you couldn't fully\n  verify, `low` if inferred from patterns.\n- `estimatedSavingsMs` \u2014 your estimate of time saved if the fix is applied.\n- `beforeCode` \u2014 a snippet of the CURRENT problematic code, copied from the\n  source file you read. Keep it focused (5\u201315 lines).\n- `afterCode` \u2014 the IMPROVED code snippet showing the fix. Must be a drop-in\n  replacement for `beforeCode`.\n- `impactMs` \u2014 the current measured cost (e.g. blocking function duration,\n  resource load time).";
+/**
+ * System prompt for the Deep Agent when analyzing browser page-load performance.
+ *
+ * The orchestrator prompt is intentionally SHORT — its only job is to
+ * dispatch four specialized subagents in parallel and consolidate their
+ * findings. All analysis logic lives in the subagent prompts.
+ */
+export { MEMORY_HEAP_PROMPT } from './prompts/memory-heap.js';
+export { PAGE_LOAD_PROMPT } from './prompts/page-load.js';
+export { RUNTIME_BLOCKING_PROMPT } from './prompts/runtime-blocking.js';
+export { CODE_PATTERN_PROMPT } from './prompts/code-pattern.js';
+export declare const BROWSER_ORCHESTRATOR_PROMPT = "You are a performance analysis orchestrator.\n\n## Instructions\n\n1. Read the user message \u2014 it contains exactly 4 task descriptions.\n2. In your FIRST response, call the `task` tool exactly 4 times.\n   For each, set subagent_type and description EXACTLY as written in the\n   user message. Copy the FULL multi-line description verbatim, including\n   every file path listed.\n3. After all 4 subagents return, consolidate ALL findings into your\n   structured response.\n\n## Consolidation rules \u2014 CRITICAL\n\n- Include EVERY finding from EVERY subagent in your structured response.\n- Do NOT filter, drop, or summarize findings. Each distinct finding from each\n  subagent must appear as a separate entry.\n- If a subagent reports 6 findings, your output must contain all 6.\n- Preserve the exact sourceFile, category, severity, beforeCode, and afterCode\n  from each subagent finding. Do NOT rewrite or abbreviate them.\n- If two subagents report findings for the same script but with DIFFERENT\n  categories (e.g., render-blocking vs frame-blocking-function), include BOTH\n  as separate findings.\n- Do NOT add your own findings \u2014 only include what subagents reported.\n- Do NOT call read_file, grep, ls, or glob. All analysis is done by subagents.";
 //# sourceMappingURL=prompts.d.ts.map

package/dist/analysis/prompts.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../src/analysis/prompts.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,aAAa,i1OA4HH,CAAC"}
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../../src/analysis/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAGH,OAAO,EAAE,kBAAkB,EAAE,MAAM,0BAA0B,CAAC;AAC9D,OAAO,EAAE,gBAAgB,EAAE,MAAM,wBAAwB,CAAC;AAC1D,OAAO,EAAE,uBAAuB,EAAE,MAAM,+BAA+B,CAAC;AACxE,OAAO,EAAE,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAEhE,eAAO,MAAM,2BAA2B,0vCAwBuC,CAAC"}

package/dist/browser/capture.d.ts

@@ -1,5 +1,5 @@
 import type { Browser } from 'webdriverio';
-import type { CaptureResult, CaptureOptions } from '../types.js';
+import type { CaptureResult, CaptureOptions } from '@zeitzeuge/utils';
 /**
  * Capture both a heap snapshot and a performance trace from a single page load.
  *

package/dist/browser/capture.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"capture.d.ts","sourceRoot":"","sources":["../../src/browser/capture.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,aAAa,CAAC;AAC3C,OAAO,KAAK,EAAE,aAAa,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AAGjE;;;;;;;;;GASG;AACH,wBAAsB,WAAW,CAC/B,OAAO,EAAE,OAAO,EAChB,GAAG,EAAE,MAAM,EACX,OAAO,GAAE,cAAmB,GAC3B,OAAO,CAAC,aAAa,CAAC,CAwDxB"}
+{"version":3,"file":"capture.d.ts","sourceRoot":"","sources":["../../src/browser/capture.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,aAAa,CAAC;AAC3C,OAAO,KAAK,EAAE,aAAa,EAAE,cAAc,EAAE,MAAM,kBAAkB,CAAC;AAGtE;;;;;;;;;GASG;AACH,wBAAsB,WAAW,CAC/B,OAAO,EAAE,OAAO,EAChB,GAAG,EAAE,MAAM,EACX,OAAO,GAAE,cAAmB,GAC3B,OAAO,CAAC,aAAa,CAAC,CAwDxB"}

package/dist/browser/launch.d.ts

@@ -1,5 +1,5 @@
 import { type Browser } from 'webdriverio';
-import type { LaunchOptions } from '../types.js';
+import type { LaunchOptions } from '@zeitzeuge/utils';
 export type { Browser } from 'webdriverio';
 export declare function launchBrowser(options?: LaunchOptions): Promise<Browser>;
 export declare function closeBrowser(browser: Browser): Promise<void>;