Gpt4free Provider Sync

4. Adding a browser provider (wire ALL of these)

Learned adding GLM (chat.z.ai). Miss one and it half-breaks silently.

1. webAdapters.ts - add the id to the WebProviderId union AND an entry to WEB_ADAPTERS. This one file is the source of truth: the UI picker, host routing (adapterForHost), WEB_PROVIDERS, and extensionMatchPatterns() all derive from it. Selectors always rot, so provide layered lists and mark tested: false. For loggedOut, prefer a stable sign-in testid/anchor; avoid a generic a[href*="login"] (false-positives lock signed-in users out). Note whether the site allows anonymous/guest use.
2. web_session.rs - add ("<id>", "<fresh-chat-url>") to the PROVIDERS array. The desktop window opens from THIS map, not from webAdapters. Omitting it makes the window fail with "unknown provider".
3. extension/src/adapters/<id>.ts - one line: registerAdapter('<id>'); (copy any sibling).
4. extension/manifest.json - add https://<host>/* to BOTH host_permissions and web_accessible_resources[0].matches (and the description provider list).
5. package.json build:extension - append extension/src/adapters/<id>.ts. The esbuild input list is explicit, not a glob, so a new adapter file is otherwise never built.
6. src-tauri/capabilities/assistant.json - add https://<host>/* to remote.urls. This is the one that fails SILENTLY. The injected agent reports back over Tauri events (core:event:allow-emit), and Tauri only allows emit from remote origins on this whitelist. Miss it and the agent installs, boots, and drives the page but every event is dropped by the ACL (the agent's send() swallows the emit error), so the shell sees NOTHING: no ready, so the queued job never dispatches, and the run just hangs. Symptom when testing: agentInstalled: true on the page but zero abs-web-event. Capabilities are compiled into the exe by tauri-build, so this needs a rebuild.

Nothing else in the UI needs touching: WebSessionModePanel.tsx renders straight from WEB_PROVIDER_IDS (a new provider shows with a "not tested" badge automatically), and PROMPT_BUDGETS in AgentStartScreen.tsx is a Partial map (only ChatGPT has a hard cap; an absent provider falls back to the full prompt, which is fine).

5. Build + verify

npm run build:assistant-agent   # rebundles the injected agent (webAssistantAgent.ts). It is include_str!'d into the exe at COMPILE time, so a running tauri:dev never picks up selector edits until a rebuild.
npm run build:extension         # confirms the new adapter file compiles into dist/adapters/<id>.js
npm run typecheck               # 3 pre-existing errors are known/unrelated: CanvasArea.tsx:296, TextElement.tsx:91, TextElement.tsx:117. Your change must add zero new ones.

New adapters are best-effort until selectors are verified against the live site. Live-testing recipe (scratch Tauri instance, copied profile, CDP harness, op-log forensics) is in the tauri-desktop-integration memory; the embedded-webview architecture and the hard-won login/iframe correctness rules are in embedded-webview-account-mode.

Reasoning-model providers (GLM, DeepSeek R1, Qwen QwQ)

A reasoning model shows a "thinking" placeholder for many seconds before its answer. waitForReply's only guard against returning early is the streaming (stop-button) selector — if it's dead/guessed, the text-settle heuristic (1.2s) returns the stable "thinking" placeholder as the answer and the plan parser rejects it. Since these sites often have no stable CSS stop button, add a per-adapter isGenerating?: () => boolean hook (reads the live "Thinking…/Skip"-style control by text; CSS can't match text) — it's OR'd into waitForReply's streaming check. Capture the in-progress control live (CDP button-dump while it generates) rather than guessing. Also: these models can't fetch the hosted catalog (reply CANNOT_FETCH), and some (GLM) emit a junk JSON skeleton alongside the sentinel — the AgentStartScreen URL branch caches 'fail' on the sentinel regardless of junk JSON and uses extractJsonCandidates + token-match (not first-only extractJson), so verify a new reasoning provider's can't-fetch verdict actually caches (else every run re-pays the URL round-trip).