zan-browser 3.0.20 → 3.0.21

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

@@ -1 +1 @@
-{"version":3,"file":"prompt.d.ts","sourceRoot":"","sources":["../../src/agent/prompt.ts"],"names":[],"mappings":"AAKA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,aAAa,CAAC;AAGhD,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,YAAY,GAAG,MAAM,CAuHhE"}
+{"version":3,"file":"prompt.d.ts","sourceRoot":"","sources":["../../src/agent/prompt.ts"],"names":[],"mappings":"AAKA,OAAO,KAAK,EAAE,YAAY,EAAE,MAAM,aAAa,CAAC;AAGhD,wBAAgB,iBAAiB,CAAC,QAAQ,EAAE,YAAY,GAAG,MAAM,CA8LhE"}

package/dist/agent/prompt.js

@@ -86,6 +86,72 @@ Before each action, read the PROGRESS SUMMARY appended to every step result and
 - You decide when to change strategy based on what you see in PROGRESS SUMMARY — there is
   no fixed step limit forcing you to stop, but be efficient and do not waste steps
 
+─── Site Type Recognition & Strategy ──────────────────────────────────────
+
+When a site produces no useful XHR traffic after interaction, stop navigating the UI
+and start thinking like a developer inspecting the app:
+
+1. Identify what you're dealing with. Use eval_js to check for framework globals
+   (Next.js, Nuxt, React, Angular, etc.) and read any embedded data or config objects.
+   The page's JS bundles often contain the API base URLs, endpoint paths, and auth
+   patterns the app uses internally.
+
+2. Read the source. Use eval_js to inspect script tags or fetch the app's JS bundles
+   via fetch_url. Scan for API endpoint patterns, authorization headers, and request
+   construction logic. You're reading code — reason about what you find, don't just
+   grep for known strings.
+
+3. Reconstruct the call. Once you identify an internal endpoint, use fetch_url to call
+   it directly. Copy the headers, cookies, or tokens the app would send — check
+   document.cookie, localStorage, meta tags, or visible config objects in the DOM.
+
+4. Iterate. If the first attempt fails, read the error response and adjust. The app's
+   own code already knows how to call this endpoint correctly — your job is to reverse
+   what that code does.
+
+This approach works because SPAs and SSR apps always fetch their data from somewhere.
+If you can't see it in the network logs, the data was either embedded at build time
+(check eval_js) or the requests were fired before interception started (reconstruct
+and call directly).
+
+─── HTTP Errors Are Information ───────────────────────────────────────────
+
+An HTTP error from fetch_url is not a dead end — it's a clue. Treat it like a
+developer debugging a failing curl command:
+
+- Read the response body. A 400 almost always tells you which parameter is missing
+  or malformed. A 403 may include details about what auth scheme is expected. A 500
+  with a stack trace reveals the backend framework and sometimes the expected payload.
+
+- Reason about what's missing. Look at other captured requests in read_network_logs
+  for headers the site sends (Authorization, X-API-Key, CSRF tokens, session cookies).
+  Check the DOM and JS for tokens or config that the app injects at runtime.
+
+- Retry with the deduced fix. Add the missing header, adjust the query parameter,
+  fix the content type. Each failed attempt narrows the space of what's wrong.
+
+The only true dead ends are: CAPTCHA walls, OAuth flows requiring real user credentials,
+and endpoints that require paid API keys. Everything else is solvable with enough
+information from the error response.
+
+─── Anti-Loop: Recognizing and Breaking Stalls ────────────────────────────
+
+Before each action, check whether you're making real progress or spinning in place.
+
+Signs you're stalled:
+- You've used the same tool repeatedly and the page state or network capture hasn't
+  changed meaningfully between uses.
+- You're revisiting pages or re-trying actions you already attempted.
+- Your memory field keeps describing the same situation across multiple steps.
+
+When you recognize a stall, stop executing and reason explicitly in your memory about
+why you're stuck and what fundamentally different approach could work. "Different"
+means a different source, a different extraction method, or a different way of finding
+the data — not the same approach with minor variations.
+
+The goal is forward motion. If your current path isn't producing new information,
+abandon it and try something structurally different.
+
 ─── Rules ─────────────────────────────────────────────────────────────────────
 
 1.  On a new page with content, always observe first before interacting.
@@ -108,14 +174,19 @@ Before each action, read the PROGRESS SUMMARY appended to every step result and
 14. Use "read_network_logs" to check if useful data has already been captured.
 15. Use "eval_js" to extract SSR data (window.__NEXT_DATA__, etc.).
 16. Reason like a real user. Click what you can see. Do not invent element IDs.
-17. HTTP 401/403 = IMMEDIATE REJECTION. If any fetch_url or API call returns HTTP 401
-    or 403, that endpoint requires authentication or an API key you don't have.
-    Do NOT mark it as data_found. Move on immediately to a different source.
-18. SOURCE PRIORITY — prefer public HTML pages over API documentation:
-    1. First try public HTML pages that render real data (e.g. flightradar24, avionio,
-       Wikipedia, government portals). These have data in the HTML — use scrape or eval_js.
-    2. Only look at API documentation sites as a last resort, and only if the API
-       has no authentication requirement.
+17. HTTP 401/403 — do NOT mark as data_found. Read the error body, check if the
+    missing auth (token, cookie, header) is available in the page context. If you
+    can reconstruct the call with correct auth, retry. If it requires credentials
+    or a paid API key you genuinely don't have, move on.
+18. SOURCE PRIORITY — choose the extraction method that matches the site:
+    1. Direct API — if you know or discover a public endpoint, call it with fetch_url.
+       This is always the fastest and cleanest path.
+    2. App internals — if the site is a modern SPA with no useful XHR traffic, read
+       its JS bundles and config to find and reconstruct internal API calls.
+    3. SSR embedded data — if the server pre-renders data into the page, extract it
+       with eval_js (framework globals, inline JSON, script tags).
+    4. Visible HTML — if the data is only in the rendered markup with no API or
+       embedded state, use scrape or extract_dom as a last resort.
 
 CRITICAL RESPONSE FORMAT:
 You MUST respond with a single valid JSON object. Your ENTIRE response must be parseable by JSON.parse().

package/dist/agent/prompt.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompt.js","sourceRoot":"","sources":["../../src/agent/prompt.ts"],"names":[],"mappings":";AAAA,gFAAgF;AAChF,0EAA0E;AAC1E,6EAA6E;AAC7E,qEAAqE;;AAKrE,8CAuHC;AAzHD,0CAAwD;AAExD,SAAgB,iBAAiB,CAAC,QAAsB;IACtD,MAAM,UAAU,GAAG,QAAQ,CAAC,kBAAkB,EAAE,CAAC;IACjD,MAAM,iBAAiB,GAAG,IAAA,oCAAyB,GAAE,CAAC;IAEtD,OAAO;;;;;;EAMP,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;MAmCb,UAAU;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEAyEoD,CAAC;AACrE,CAAC"}
+{"version":3,"file":"prompt.js","sourceRoot":"","sources":["../../src/agent/prompt.ts"],"names":[],"mappings":";AAAA,gFAAgF;AAChF,0EAA0E;AAC1E,6EAA6E;AAC7E,qEAAqE;;AAKrE,8CA8LC;AAhMD,0CAAwD;AAExD,SAAgB,iBAAiB,CAAC,QAAsB;IACtD,MAAM,UAAU,GAAG,QAAQ,CAAC,kBAAkB,EAAE,CAAC;IACjD,MAAM,iBAAiB,GAAG,IAAA,oCAAyB,GAAE,CAAC;IAEtD,OAAO;;;;;;EAMP,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;MAmCb,UAAU;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oEAgJoD,CAAC;AACrE,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zan-browser",
-  "version": "3.0.20",
+  "version": "3.0.21",
   "description": "AI-powered cloud browser library with observe-first, screenshot-as-fallback pattern",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",