AGENTS.md — Dual-LLM Bridge (v2, corrected)

⚠️ LANGUAGE NOTE: Headings and critical instructions are in English for maximum compatibility with coding agents. Explanations are in Russian. If you, the agent, do not understand a Russian comment — ask before coding.

🧠 MAIN RULE: This document is the source of truth. If your idea contradicts this document, stop and ask. Do not silently invent another architecture.

🎯 Project Overview

Dual-LLM Bridge is a Chrome Manifest V3 extension with a built-in Web UI.

The product goal:

1. The user has two LLM web chats open in browser tabs, for example:

   • Window 1 / left panel: Qwen — https://chat.qwen.ai
   • Window 2 / right panel: ChatGPT — https://chatgpt.com

2. The extension UI shows a split-screen control panel:

   • Left panel mirrors Window 1.
   • Right panel mirrors Window 2.
   • Bottom input sends messages to one or both chats.

3. Prefix routing:

   • -1 hello → send only to Window 1.
   • -2 hello → send only to Window 2.
   • hello → send to both windows.

4. Auto-Relay:

   • A completed answer from Model 1 can be automatically forwarded to Model 2.
   • A completed answer from Model 2 can be automatically forwarded to Model 1.
   • The user can stop the relay instantly.

5. The system must work without official APIs as the primary mode. Official APIs are optional fallback adapters, not the main path.

🧱 Core Architectural Decision

The UI is not a random standalone website on localhost trying to talk to content scripts.

The UI is an extension page, opened via chrome-extension://<extension-id>/index.html.

Reason:

• Content scripts live on chat.qwen.ai / chatgpt.com.
• A normal web page on another origin cannot reliably use chrome.runtime.
• BroadcastChannel cannot connect different origins.
• Extension pages have direct access to chrome.runtime, chrome.storage, and extension messaging.

Therefore:

UI = extension page
Background Service Worker = message router and command dispatcher
Content Scripts = adapters inside LLM chat tabs

🏛 Canonical Architecture

Use this architecture exactly.

┌────────────────────────────┐        ┌────────────────────────────┐
│ Qwen tab                   │        │ ChatGPT tab                │
│ https://chat.qwen.ai       │        │ https://chatgpt.com        │
│                            │        │                            │
│ MAIN-world interceptor     │        │ MAIN-world interceptor     │
│ patches fetch/SSE/stream   │        │ patches fetch/SSE/stream   │
│         │                  │        │         │                  │
│         ▼                  │        │         ▼                  │
│ ISOLATED content bridge    │        │ ISOLATED content bridge    │
└───────────┬────────────────┘        └───────────┬────────────────┘
            │                                     │
            │ chrome.runtime.sendMessage           │ chrome.runtime.sendMessage
            ▼                                     ▼
        ┌───────────────────────────────────────────────┐
        │ Background Service Worker                     │
        │ - routes events                               │
        │ - knows tab/window assignment                 │
        │ - executes SEND_PROMPT commands               │
        │ - reports tab status                          │
        └───────────────────────┬───────────────────────┘
                                │ chrome.runtime.connect / sendMessage
                                ▼
                    ┌─────────────────────────┐
                    │ Extension Web UI        │
                    │ Split-screen control app│
                    │ Relay controller        │
                    │ Settings / Stop button  │
                    └─────────────────────────┘

Important consequences

1. The UI does not embed official chat sites in iframes.
2. The UI shows a mirrored transcript of intercepted messages.
3. The actual chats remain open in normal browser tabs.
4. Sending a message to a model means:
   • UI sends command to background.
   • background executes injection into the target tab.
   • content adapter fills the chat input and presses send.
5. Receiving a response means:
   • MAIN-world interceptor observes network/stream output.
   • ISOLATED bridge forwards structured events to background.
   • background forwards events to UI.

🚫 ANTI-PATTERNS — DO NOT

1. DO NOT use plain <iframe src="https://chatgpt.com"> or similar. Major LLM chats block embedding using X-Frame-Options / CSP.

2. DO NOT use BroadcastChannel as the main bridge between chat tabs and UI. It does not work across different origins. It may only be used optionally between multiple extension UI pages of the same origin.

3. DO NOT rely on localStorage for real-time synchronization. Use extension messaging and in-memory state.

4. DO NOT parse by random CSS class names. CSS classes change often. Prefer:

   • network interception;
   • data-testid;
   • ARIA roles;
   • stable IDs if present;
   • semantic selectors.

5. DO NOT use MutationObserver polling as the main streaming mechanism. Streaming must be intercepted at network layer when possible. DOM observation is only a fallback.

6. DO NOT use Puppeteer / Playwright as the main product architecture. They are testing/fallback tools only.

7. DO NOT propose another tech stack. The stack is fixed below.

8. DO NOT generate code for the next phase before the current phase is accepted.

9. DO NOT try to bypass CAPTCHA, anti-bot, payment walls, or authentication. If the site requires human action, show a clear user-facing error.

10. DO NOT send chat content, cookies, tokens, or API keys anywhere except:

    • the original model provider domain in extension mode;
    • the official API endpoint in API fallback mode.

⚡ KNOWN SOLUTIONS — READ BEFORE CODING

CRITICAL: Do not invent integration architecture from scratch. Study and adapt these patterns.

Reference URLs

Agent: verify URLs before relying on them. If moved, find the current repository.

• ChatALL: https://github.com/ai-shifu/ChatALL
• NextChat: https://github.com/ChatGPTNextWeb/NextChat
• Chrome content scripts: https://developer.chrome.com/docs/extensions/develop/concepts/content-scripts
• Chrome scripting.executeScript: https://developer.chrome.com/docs/extensions/reference/api/scripting
• Chrome webRequest: https://developer.chrome.com/docs/extensions/reference/api/webRequest
• Zustand: https://docs.pmnd.rs/zustand
• CRXJS: https://crxjs.dev/vite-plugin

🔧 TECH STACK — FIXED

Frontend:
  framework: React 18.3.x
  language: TypeScript 5.5.x
  strict_mode: true
  bundler: Vite 5.4.x

State:
  library: zustand 4.5.x
  pattern: UI stores + relay controller store

Styling:
  framework: tailwindcss 3.4.x
  note: Do not switch to Tailwind 4 without user approval.

Extension:
  manifest: V3
  minimum_chrome: "120"
  build_tool: >
    Prefer @crxjs/vite-plugin if a known-good version works.
    If CRXJS beta is unstable, stop and ask the user.
    Fallback: plain Vite build + static manifest.json.

IPC:
  content_to_background: chrome.runtime.sendMessage
  background_to_content: chrome.tabs.sendMessage or chrome.scripting.executeScript
  ui_to_background: chrome.runtime.connect / chrome.runtime.sendMessage
  main_world_to_isolated: window.postMessage with schema validation

Storage:
  settings: chrome.storage.local
  api_keys: chrome.storage.local or IndexedDB
  transcript_cache: IndexedDB
  forbidden_for_sensitive_data: localStorage

Testing:
  unit: vitest
  e2e: playwright
  e2e_policy: Use local mock pages, not live LLM sites.

Runtime:
  node: ">=20"
  package_manager: npm workspaces

Version policy

• Pin exact versions in package.json.
• Do not use latest.
• If a dependency has breaking changes, ask before upgrading.
• If CRXJS beta fails repeatedly, report it and propose manual manifest build.

📁 PROJECT STRUCTURE — MANDATORY

Use this structure unless the user explicitly approves changes.

dual-llm-bridge/
├── packages/
│   ├── extension/
│   │   ├── src/
│   │   │   ├── background/
│   │   │   │   └── index.ts              # Service worker/router
│   │   │   │
│   │   │   ├── content/
│   │   │   │   ├── isolated/
│   │   │   │   │   └── index.ts          # Isolated-world bridge
│   │   │   │   ├── main-world/
│   │   │   │   │   └── injector.ts       # MAIN-world fetch/SSE interceptor
│   │   │   │   └── adapters/
│   │   │   │       ├── base.ts           # Shared adapter helpers
│   │   │   │       ├── qwen.ts           # Qwen adapter
│   │   │   │       └── chatgpt.ts        # ChatGPT adapter
│   │   │   │
│   │   │   ├── ui/
│   │   │   │   ├── components/
│   │   │   │   │   ├── SplitView.tsx
│   │   │   │   │   ├── ChatPanel.tsx
│   │   │   │   │   ├── MessageList.tsx
│   │   │   │   │   ├── UnifiedInput.tsx
│   │   │   │   │   ├── StatusBar.tsx
│   │   │   │   │   ├── RelayControls.tsx
│   │   │   │   │   └── WarningModal.tsx
│   │   │   │   ├── store/
│   │   │   │   │   ├── windows.ts
│   │   │   │   │   ├── relay.ts
│   │   │   │   │   └── settings.ts
│   │   │   │   ├── lib/
│   │   │   │   │   ├── parser.ts         # Prefix parsing: -1 / -2
│   │   │   │   │   ├── format.ts
│   │   │   │   │   └── ipc.ts            # chrome.runtime wrapper
│   │   │   │   ├── App.tsx
│   │   │   │   ├── main.tsx
│   │   │   │   └── index.html
│   │   │   │
│   │   │   └── shared-imports.ts         # Re-export shared package if needed
│   │   │
│   │   ├── manifest.json
│   │   ├── vite.config.ts
│   │   └── package.json
│   │
│   └── shared/
│       ├── src/
│       │   ├── types.ts                  # Protocol types
│       │   ├── guards.ts                 # Runtime validation guards
│       │   ├── protocol.ts               # Constants/topics
│       │   └── constants.ts              # Domains/timeouts/limits
│       └── package.json
│
├── tests/
│   ├── unit/
│   ├── e2e/
│   └── mocks/
│       ├── qwen-mock.html
│       └── chatgpt-mock.html
│
├── docs/
│   └── architecture.md
│
├── AGENTS.md
├── package.json
└── README.md

🌐 TARGET DOMAINS

Primary targets:

Manifest must register both ChatGPT patterns because chat.openai.com may redirect.

📨 MESSAGE PROTOCOL

All IPC messages must use typed structures from packages/shared/src/types.ts.

Envelope rules

Every message must have:

export const PROTOCOL_VERSION = 1;

export type WindowId = 1 | 2;

export type ModelId =
  | 'qwen'
  | 'chatgpt'
  | (string & {}); // allow future models, but constants must define known ones

export type MessageOrigin =
  | 'main-world'
  | 'content-isolated'
  | 'background'
  | 'ui';

export type ChatStatus =
  | 'unknown'
  | 'tab-not-found'
  | 'loading'
  | 'ready'
  | 'unauthenticated'
  | 'generating'
  | 'error';

export interface BridgeMeta {
  /** Unix timestamp in milliseconds */
  ts: number;

  /** Unique message id */
  messageId: string;

  /** Which UI window this belongs to */
  windowId: WindowId;

  /** Model id */
  model: ModelId;

  /** Who caused this message */
  source: 'user-ui' | 'user-chat-tab' | 'relay' | 'system';

  /** Auto-relay iteration number, 0 for user-initiated */
  iteration: number;

  /** true if this message was forwarded by relay */
  isAutoRelay: boolean;
}

Event types

export type BridgeEventType =
  | 'TAB_STATUS'
  | 'PROMPT_OBSERVED'
  | 'RESPONSE_CHUNK'
  | 'RESPONSE_DONE'
  | 'INJECTION_RESULT'
  | 'ERROR';

export interface BridgeEvent<T extends BridgeEventType = BridgeEventType> {
  kind: 'event';
  v: typeof PROTOCOL_VERSION;
  type: T;
  origin: MessageOrigin;
  meta: BridgeMeta;
  payload: BridgeEventPayload;
}

export interface BridgeEventPayload {
  status?: ChatStatus;
  text?: string;
  streamDelta?: string;
  fullText?: string;
  doneReason?: 'complete' | 'stopped' | 'error' | 'timeout';
  error?: {
    code: string;
    message: string;
    retryable: boolean;
  };
  url?: string;
}

Command types

export type BridgeCommandType =
  | 'SEND_PROMPT'
  | 'REQUEST_STATUS'
  | 'STOP_GENERATION'
  | 'ASSIGN_WINDOW';

export interface BridgeCommand<T extends BridgeCommandType = BridgeCommandType> {
  kind: 'command';
  v: typeof PROTOCOL_VERSION;
  type: T;
  origin: MessageOrigin;
  meta: BridgeMeta;
  payload: BridgeCommandPayload;
}

export interface BridgeCommandPayload {
  text?: string;
  windowId?: WindowId;
  tabId?: number;
  reason?: string;
}

Validation rules

• All incoming messages must be validated by guards in packages/shared/src/guards.ts.
• Invalid message:
  • log warning with [bridge:invalid];
  • discard;
  • never crash the app.
• MAIN-world messages are untrusted.
  • They can provide telemetry/events.
  • They must never trigger privileged extension actions directly.

🧩 CONTENT ADAPTER CONTRACT

Each supported model must have an adapter.

export interface ChatAdapterConfig {
  model: ModelId;
  windowId: WindowId;
  hostPatterns: string[];
  selectors: {
    input: string[];
    sendButton: string[];
    stopButton?: string[];
    loginIndicator?: string[];
    responseContainer?: string[];
  };
}

export interface ChatAdapter {
  config: ChatAdapterConfig;

  /** Return true if current URL belongs to this adapter */
  matches(url: string): boolean;

  /** Start network interception in MAIN world */
  initInterceptor(): void;

  /** Detect if user is logged in */
  detectAuth(): boolean;

  /** Extract last visible messages as fallback */
  extractVisibleHistory?(): Array<{
    role: 'user' | 'assistant' | 'system';
    text: string;
  }>;
}

Selector policy

Selectors must be arrays, tried in order.

Example:

selectors: {
  input: [
    '[data-testid="chat-input"]',
    'textarea[aria-label]',
    'textarea',
    '[contenteditable="true"]'
  ],
  sendButton: [
    '[data-testid="send-button"]',
    'button[aria-label*="send" i]',
    'button[type="submit"]'
  ]
}

Rules:

• Do not rely on generated class names.
• If no stable selector exists, use the most semantic fallback.
• If injection fails twice, report INJECTION_RESULT error.

🧪 PROGRAMMATIC MESSAGE INJECTION

This is mandatory.

To send text into a React-based chat input, do not do only:

textarea.value = text;

That often does not work with React controlled components.

Use the native setter pattern:

function setNativeValue(element: HTMLElement, value: string) {
  const el = element as HTMLTextAreaElement | HTMLInputElement;

  const prototype =
    el instanceof HTMLTextAreaElement
      ? HTMLTextAreaElement.prototype
      : HTMLInputElement.prototype;

  const descriptor = Object.getOwnPropertyDescriptor(prototype, 'value');
  const setter = descriptor?.set;

  if (!setter) {
    throw new Error('Native value setter is unavailable');
  }

  // React internal value tracker workaround
  const tracker = (el as any)._valueTracker;
  if (tracker) {
    tracker.setValue(el.value);
  }

  setter.call(el, value);

  el.dispatchEvent(new Event('input', { bubbles: true }));
  el.dispatchEvent(new Event('change', { bubbles: true }));
}

Then:

1. Focus the input.
2. Set value using the native setter.
3. Dispatch input and change.
4. Wait until send button becomes enabled, if detectable.
5. Click send button.
6. If send button not found, dispatch Enter key events on input.
7. Confirm that a request started or response stream started.
8. If no confirmation within timeout, return injection error.

Preferred execution method:

chrome.scripting.executeScript({
  target: { tabId },
  world: 'MAIN',
  func: injectPromptIntoChat,
  args: [adapterId, text, messageId]
});

Fallback if chrome.scripting MAIN world is unavailable:

• isolated content script posts a validated command to MAIN-world injector;
• MAIN-world injector performs DOM injection;
• result is posted back and forwarded to background.

📡 STREAM INTERCEPTION

Primary method:

• Patch window.fetch in MAIN world.
• Detect streaming responses from known model endpoints.
• Read response.body with a ReadableStream tee if needed.
• Parse SSE chunks or JSON lines depending on site behavior.
• Emit:
  • RESPONSE_CHUNK
  • RESPONSE_DONE

Secondary method:

• Patch XMLHttpRequest if the site uses it.

Tertiary fallback:

• Observe DOM only if network interception is impossible.
• DOM fallback must be clearly marked in status.

Rules:

• Do not block or modify original site behavior.
• Do not consume the stream destructively.
• If parsing fails, emit ERROR with code STREAM_PARSE_ERROR.
• Throttle UI stream updates to maximum ~10 updates per second. Accumulate deltas locally and flush periodically.

🔁 AUTO-RELAY RULES

Relay controller lives in the UI store, but all actual tab operations go through background.

Relay enablement

Auto-relay is disabled by default.

Before first enablement, show a warning modal:

«Авто-релей будет отправлять ответы одной модели в качестве ввода другой модели. Содержимое чата может передаваться между разными провайдерами. Продолжить?»

User must explicitly confirm.

Relay loop

When relay is enabled:

1. Wait for RESPONSE_DONE from Window A.
2. Apply debounce: default 800ms.
3. Check:
   • relay is still enabled;
   • iteration limit not reached;
   • target Window B tab exists;
   • target Window B status is not unauthenticated;
   • target Window B is not generating.
4. Send completed response text as SEND_PROMPT to Window B.
5. Mark command meta:

   isAutoRelay: true;
   iteration: previousIteration + 1;
   source: 'relay';
   

6. Wait for Window B RESPONSE_DONE.
7. Repeat in reverse direction if relay still enabled.

Queue rules

• Maintain one FIFO relay queue.
• Do not send two prompts to the same window simultaneously.
• If both models answer at the same time, queue responses.
• If target window is generating, wait for its RESPONSE_DONE.
• If target window remains generating longer than GENERATION_TIMEOUT, pause relay and show error.

Limits

export const DEFAULT_DEBOUNCE_MS = 800;
export const DEFAULT_MAX_ITERATIONS = 10;
export const MAX_HARD_ITERATIONS = 100;
export const CONNECTION_TIMEOUT_MS = 30_000;
export const GENERATION_TIMEOUT_MS = 300_000;
export const INJECTION_TIMEOUT_MS = 15_000;

• Default max iterations: 10.
• Hard cap: 100.
• Stop button must cancel relay within 100ms UI-wise.
• Stop must also send STOP_GENERATION to both adapters if possible.

Duplicate protection

Do not forward a message if:

• exact same text was already forwarded to the same target in the previous iteration;
• message is empty;
• message is only whitespace.

🖥 UI REQUIREMENTS

The UI is an extension page.

Layout

┌────────────────────────────────────────────────────┐
│ StatusBar: window statuses, relay iteration, Stop  │
├────────────────────────┬───────────────────────────┤
│ Window 1 transcript    │ Window 2 transcript       │
│ Qwen mirror            │ ChatGPT mirror            │
│                        │                           │
├────────────────────────┴───────────────────────────┤
│ Unified input: -1 / -2 / no prefix                 │
└────────────────────────────────────────────────────┘

Panels

Each panel must show:

• window number;
• model name;
• connection status icon:
  • 🟢 ready
  • 🟡 loading / generating
  • 🔴 error / tab missing / unauthenticated
• method:
  • extension
  • api
• message list.

Message rendering

Each message must show:

• role:
  • user;
  • model;
  • system/error.
• source:
  • typed in UI;
  • typed directly in chat tab;
  • relay-forwarded.
• timestamp.
• auto-relay mark:
  • relayed prompt shows 🔄.

Input behavior

Input parsing:

"-1 hello" -> window 1 only
"-2 hello" -> window 2 only
"hello"    -> both windows

Rules:

• Trim prefix and one following space.
• If message after prefix is empty, show validation error.
• If target window has no ready tab, show error and do not send.

Stop button

Stop button must:

• be visible when relay is enabled or any generation is active;
• disable relay;
• clear relay queue;
• send stop command to adapters where possible;
• show status stopped.

🔐 SECURITY AND PRIVACY RULES

1. No data exfiltration. Chat content must not be sent anywhere except:

   • the original chat domain in extension mode;
   • the official API endpoint in API mode.

2. API keys local only. Store API keys in chrome.storage.local or IndexedDB. Never store secrets in localStorage.

3. No remote code execution. No eval() of remote code. No injecting remote scripts.

4. Minimal permissions. Required manifest permissions:

   • storage
   • tabs
   • scripting
   • host permissions only for target domains.

   Do not request <all_urls> unless user explicitly approves.

5. Untrusted MAIN-world data. Data from page context must be schema-validated. It must never directly invoke privileged extension commands.

6. Relay privacy warning. Auto-relay must require explicit user confirmation.

7. No anti-bot bypass. If login, CAPTCHA, or consent screen is required, stop and notify user.

🧯 ERROR HANDLING STRATEGY

Every async operation must have error handling. Silent failures are forbidden.

Logging prefixes:

[bridge]
[bridge:error]
[bridge:relay]
[bridge:inject]
[bridge:stream]

🧪 TESTING STRATEGY

Unit tests

Test at least:

• prefix parser:
  • -1 text
  • -2 text
  • plain text
  • empty text
  • prefix without text
• message guards;
• relay iteration counter;
• debounce logic;
• duplicate suppression;
• queue behavior.

Integration tests

Use mock pages:

• tests/mocks/qwen-mock.html
• tests/mocks/chatgpt-mock.html

Mock pages should simulate:

• input field;
• send button;
• fake response stream;
• login state.

E2E tests

Playwright may test:

• extension loads;
• UI opens;
• mock tab is recognized;
• message injection works on mock page;
• response event reaches UI.

Do not run E2E against live LLM sites by default.

Manual acceptance may use live sites.

🚀 BUILD AND INSTALL

# install dependencies from repo root
npm install

# development build/watch
npm run dev

# production build
npm run build

# unit tests
npm run test

# e2e tests
npm run test:e2e

Load extension manually:

1. Run npm run build.
2. Open chrome://extensions.
3. Enable Developer mode.
4. Click “Load unpacked extension”.
5. Select dist/extension or the build output folder.
6. Open extension UI from toolbar action.

Firefox is not supported in the current scope.

📋 TASK BREAKDOWN — SEQUENTIAL

Do not skip phases. After each phase, present results and wait for user approval.

Phase 1 — Extension Skeleton and Stream Interception

Goal: prove that the extension can observe prompts and responses from real chat tabs.

Tasks:

• [ ] Create monorepo structure.
• [ ] Create packages/shared protocol types and guards.
• [ ] Create Manifest V3 skeleton.
• [ ] Register content scripts for:
  • https://chat.qwen.ai/*
  • https://chatgpt.com/*
  • https://chat.openai.com/*
• [ ] Implement MAIN-world interceptor.
• [ ] Implement isolated-world bridge.
• [ ] Forward intercepted events to background.
• [ ] Log structured BridgeEvent objects in console.
• [ ] Add [bridge] log prefixes.

Acceptance:

1. Load extension in Chrome.
2. Open Qwen chat tab.
3. Open ChatGPT chat tab.
4. Type a message in each chat.
5. In each tab console, see structured events:
   • PROMPT_OBSERVED
   • RESPONSE_CHUNK
   • RESPONSE_DONE

No UI is required yet.

Phase 2 — Extension UI, Handshake, and Message Injection

Goal: UI can see tab statuses and send messages into chat tabs.

Tasks:

• [ ] Create extension UI page.
• [ ] Implement split-screen layout.
• [ ] Implement status bar.
• [ ] Implement chrome.runtime.connect between UI and background.
• [ ] Background assigns tabs to Window 1 / Window 2.
• [ ] UI shows:
  • tab found/not found;
  • auth state if detectable;
  • generating state.
• [ ] Implement unified input with -1 / -2 parsing.
• [ ] Implement SEND_PROMPT command flow: UI → background → target tab → MAIN-world injection.
• [ ] Implement native React input setter pattern.
• [ ] Implement send-button click fallback.
• [ ] Implement injection result events.
• [ ] Show intercepted model responses in corresponding UI panel.

Acceptance:

1. Open Qwen tab and ChatGPT tab.
2. Open extension UI.
3. Both windows show 🟢 ready.
4. Type -1 hello → message is sent only to Qwen tab.
5. Type -2 hello → message is sent only to ChatGPT tab.
6. Type hello → message is sent to both tabs.
7. Responses appear in matching UI panels.

Phase 3 — Auto-Relay and Loop Control

Goal: models can talk to each other safely.

Tasks:

• [ ] Implement relay controller in UI store.
• [ ] Add relay enable toggle.
• [ ] Add privacy warning modal before first enable.
• [ ] Add debounce.
• [ ] Add iteration counter.
• [ ] Add max iteration limit.
• [ ] Add FIFO queue.
• [ ] Add target-busy waiting.
• [ ] Add duplicate suppression.
• [ ] Add Stop button.
• [ ] Mark relayed prompts with 🔄.
• [ ] Persist relay settings locally.
• [ ] Cache transcript in IndexedDB.

Acceptance:

1. Enable relay.
2. Send a prompt to Window 1.
3. Window 1 responds.
4. Response is automatically sent to Window 2.
5. Window 2 responds.
6. Response is automatically sent to Window 1.
7. At least 5 autonomous exchanges happen.
8. Iteration counter updates.
9. Stop button halts relay immediately.
10. After max iterations, relay stops automatically.

Phase 4 — API Fallback Adapter

Goal: allow official API mode without changing UI.

Tasks:

• [ ] Define BotAdapter abstraction.
• [ ] Implement ExtensionAdapter.
• [ ] Implement ApiAdapter interface.
• [ ] Add Qwen API adapter if endpoint is available.
• [ ] Add OpenAI API adapter for ChatGPT.
• [ ] Store API keys locally only.
• [ ] Add settings screen for mode switch:
  • extension mode;
  • API mode.
• [ ] Ensure UI message flow is identical in both modes.
• [ ] Verify API keys are not leaked to third-party domains.

Acceptance:

1. Enter API key.
2. Switch window to API mode.
3. Send message.
4. Receive response.
5. Switch back to extension mode.
6. UI behavior remains consistent.
7. Network tab shows no key leakage to unrelated domains.

💬 COMMUNICATION PROTOCOL WITH USER

These rules are mandatory.

1. Before starting each phase, confirm the plan in 1–2 sentences.

   Example:

   «Начинаю Phase 1: создаю монорепо, shared-типы и MAIN-world interceptor для fetch/SSE. Приступаю.»

2. If anything in this document is ambiguous, ask before coding.

3. After each phase, present:

   • what was done;
   • how to verify;
   • known limitations;
   • next phase proposal.

4. Do not proceed to the next phase without explicit user approval.

5. If a site changed DOM or network format, report it and propose adapter update.

6. If a dependency is broken or abandoned, report it before replacing.

7. Default communication language with the user: Russian.

🧭 DEFINITION OF DONE

The project is considered functionally complete when:

• extension loads without errors;
• Qwen and ChatGPT tabs are recognized;
• UI shows real statuses;
• -1, -2, and no-prefix routing works;
• responses are mirrored in UI;
• programmatic injection works for both supported chats;
• auto-relay works with debounce, queue, limits, and Stop;
• errors are visible and non-fatal where possible;
• no secrets are leaked;
• tests cover parser, relay logic, guards, and message flow;
• README explains installation and limitations.

⚠️ FINAL AGENT INSTRUCTION

If you are about to do any of the following, stop immediately and ask:

• use iframe embedding;
• use BroadcastChannel between chat tabs and UI;
• add a new framework;
• bypass CAPTCHA or anti-bot;
• send chat content to a third-party server;
• change the phase order;
• rely on unstable beta tooling without confirmation.

This project values predictable architecture over clever hacks.