@ait-co/devtools 0.1.143 → 0.2.0

package/README.en.md

@@ -47,7 +47,7 @@ pnpm dev:phone          # same as AIT_TUNNEL=1 pnpm dev
 # QR appears in the terminal → scan with your phone camera → opens in the launcher PWA
 ```
 
-With `tunnel: { cdp: true }`, a single QR scan opens both the screen preview and on-device CDP — inspect the real WebKit DOM, console, and exceptions from your MCP host (`call_sdk` still hits the mock on environment 2; the real SDK lives on environment 3).
+With `tunnel: { cdp: true }`, a single QR scan opens both the screen preview and on-device CDP — inspect the real WebKit DOM, console, and exceptions from your MCP host (`call_sdk` still hits the mock on environment 2; the real SDK lives on environment 3). CDP needs two extra packages — see [Debugging packages](#debugging-packages-environments-2-and-3) below.
 
 One-time prerequisite: add `https://devtools.aitc.dev/launcher/` to your phone's home screen. Details: [`docs/scenarios/env-2.md`](./docs/scenarios/env-2.md)
 
@@ -55,10 +55,10 @@ One-time prerequisite: add `https://devtools.aitc.dev/launcher/` to your phone's
 
 **Environment 3 — intoss-private** (Toss WebView, HMR off, debug only)
 
-Load a dog-food bundle in the real Toss app WebView and debug it via the MCP relay.
+Load a dog-food bundle in the real Toss app WebView and debug it via the MCP relay. Requires `@ait-co/debugger` — see [Debugging packages](#debugging-packages-environments-2-and-3) below.
 
 ```bash
-devtools-mcp              # start MCP server → QR printed in terminal
+npx -y -p @ait-co/debugger debugger   # start MCP server → QR printed in terminal (or `pnpm exec debugger` if it's a devDependency)
 # ait build && ait deploy --scheme-only
 # one start_attach(scheme_url) call generates the QR and waits for the phone to attach — scan it and the Toss app loads the bundle + relay attaches
 ```
@@ -73,7 +73,7 @@ To enable on-device CDP debugging in environments 2 and 3, add **one line** to y
 
 ```ts
 // main.tsx (or the top of your mini-app entry)
-import '@ait-co/devtools/in-app/auto';
+import '@ait-co/debug-console/auto';
 ```
 
 What this single line does:
@@ -85,7 +85,9 @@ What this single line does:
 
 For environment 3 (intoss-private relay), the relay QR deep-link carries `?debug=1&relay=<wss>` query params, so this one line is all the wiring you need. Environment 2 (PWA, `tunnel: { cdp: true }`) works the same way.
 
-> For dog-food builds with TOTP authentication, inject `__DEBUG_TOTP_SECRET__` via your build define and use `@ait-co/devtools/in-app` directly with `evaluateDebugGate({ verifyTotpCode })` + `maybeAttach()`. `in-app/auto` does not inject a TOTP verifier, so Layer C3 is disabled.
+The old `@ait-co/devtools/in-app/auto` path still resolves in 0.2.x as an inert no-op stub and is removed in 1.0.0 — migrate the import to the path above.
+
+> For dog-food builds with TOTP authentication, inject `__DEBUG_TOTP_SECRET__` via your build define and use `@ait-co/debug-console` directly with `evaluateDebugGate({ verifyTotpCode })` + `maybeAttach()`. `in-app/auto` does not inject a TOTP verifier, so Layer C3 is disabled.
 
 ## Five common problems
 
@@ -99,7 +101,7 @@ No page has joined the relay yet. Re-enter via `start_attach` → QR scan on you
 
 **"Tunnel down" — no response or timeout**
 
-A cloudflared quick tunnel can drop after a few hours. Restart the `devtools-mcp` process to get a new tunnel URL, then scan the new QR. (Related: [#290](https://github.com/apps-in-toss-community/devtools/issues/290))
+A cloudflared quick tunnel can drop after a few hours. Restart the `debugger` process to get a new tunnel URL, then scan the new QR. (Related: [#290](https://github.com/apps-in-toss-community/devtools/issues/290))
 
 **"Page crash" — list_pages shows a non-null crashDetectedAt**
 
@@ -107,7 +109,7 @@ The page on the phone died (OOM, JS exception, or native bridge crash). Relaunch
 
 **"SDK not available" — window.__sdkCall not injected**
 
-When `call_sdk` returns `ok: false, error: "window.__sdkCall is not available"`, the SDK bridge has not been installed. Check that `import '@ait-co/devtools/in-app/auto'` is present at the top of your mini-app entry — see the "On-device debugging in one line" section above. This error is the expected result in environment 2 (PWA). (Related: [#285](https://github.com/apps-in-toss-community/devtools/issues/285))
+When `call_sdk` returns `ok: false, error: "window.__sdkCall is not available"`, the SDK bridge has not been installed. Check that `import '@ait-co/debug-console/auto'` is present at the top of your mini-app entry — see the "On-device debugging in one line" section above. This error is the expected result in environment 2 (PWA). (Related: [#285](https://github.com/apps-in-toss-community/devtools/issues/285))
 
 **"QR scanned but auth rejected" — TOTP code expired**
 
@@ -138,6 +140,26 @@ devtools runs two npm dist-tags off the same code at once. Pick the channel that
 
 When 3.0 ships GA, the stable `latest` peer moves up to the 3.0 line and the beta channel is retired. Calling an API that devtools has not yet mocked will throw a runtime error — please [file an issue](https://github.com/apps-in-toss-community/devtools/issues) for missing APIs.
 
+### Debugging packages (environments 2 and 3)
+
+**If you only use environment 1 (local browser + mock + panel), the install above is all you need.** Nothing else to add.
+
+For on-device CDP debugging — `tunnel: { cdp: true }` on environment 2, or relay attach on environment 3 — install the two debugging packages as well:
+
+```bash
+pnpm add -D @ait-co/debugger @ait-co/debug-console
+```
+
+| Package | Role | Can enter a bundle |
+|---|---|---|
+| [`@ait-co/debugger`](https://www.npmjs.com/package/@ait-co/debugger) | MCP daemon · real-device test runner · dev-bridge (environment 2 CDP relay + QR dashboard) | No — devDependency / `npx` only |
+| [`@ait-co/debug-console`](https://www.npmjs.com/package/@ait-co/debug-console) | On-device attach + in-app eruda console | Yes — the only one that enters a debug build |
+
+Both are **optional peers** of devtools.
+
+- Without `@ait-co/debugger`, `tunnel: { cdp: true }` skips the CDP wiring, degrades to the plain screen-preview tunnel, and prints the install hint once.
+- Without `@ait-co/debug-console`, the unplugin injects no in-app attach at all — the attach code cannot structurally enter your bundle, which is the technical boundary of the debug surface.
+
 ## Reference consumer
 
 [`sdk-example`](https://github.com/apps-in-toss-community/sdk-example) is the reference consumer of devtools. It's a catalog app where every SDK API can be run interactively, and the web demo is live at <https://sdk-example.aitc.dev/>. When you add a new mock, confirming that it works on the sdk-example card is the first sanity check. That said, this repo's E2E suite runs against an **internal self-contained fixture (`e2e/fixture/`)** without cloning sdk-example — so a broken sdk-example won't affect devtools CI.
@@ -280,7 +302,7 @@ aitDevtools.vite({ tunnel: { cdp: true } }); // real-device preview + on-device
 
 ## Production builds
 
-By default, the devtools plugin **automatically disables itself in production** (`NODE_ENV === 'production'` causes both the alias transform and the Panel injection to be skipped). No conditional configuration is needed to keep it safe.
+By default, the devtools plugin **automatically disables itself in production** (`NODE_ENV === 'production'` causes both the alias transform and the Panel injection to be skipped). No conditional configuration is needed to keep it safe. `@ait-co/devtools` is a devDependency, and its contribution to a production bundle is zero bytes. CI enforces this by building a real consumer fixture and grepping the output.
 
 To use devtools in a production build — for example in a staging environment — use the `forceEnable` option:
 
@@ -391,9 +413,9 @@ The launcher **only works when launched as an installed PWA from the home screen
 >
 > The `tunnel` option only works in Vite dev mode — no tunnel is started for production builds, even with `forceEnable`. It is silently ignored for other bundlers (Webpack/Rspack, etc.). When the option is enabled, `cloudflared` and `qrcode-terminal` are loaded via dynamic import only, so they do not appear in the bundle graph when the option is off.
 
-### One-line setup (planned)
+### One-line setup
 
-The per-project steps above (vite.config patch + `onlyBuiltDependencies` + `dev:phone` script) are planned to be absorbed into a single command like `/ait setup phone` in the future [`agent-plugin`](https://github.com/apps-in-toss-community/agent-plugin) (command name is tentative). Since this README serves as the spec for that automation, the manual steps will remain documented here even after automation is available.
+The per-project steps above (vite.config patch + `onlyBuiltDependencies` + `dev:phone` script) are automated by a single [`agent-plugin`](https://github.com/apps-in-toss-community/agent-plugin) command, `/ait:setup-phone-preview`. Since this README serves as the spec for that automation, the manual steps stay documented here alongside it.
 
 ## Device API mode system
 
@@ -621,6 +643,7 @@ __ait.update({ networkStatus: 'OFFLINE' });
 __ait.patch('permissions', { camera: 'denied' });
 __ait.patch('deviceModes', { location: 'web' });
 __ait.patch('iap', { nextResult: 'USER_CANCELED' });
+__ait.patch('failureModes', { loadAdMob: 'PLACEMENT_ID_FETCH_FAILED' }); // reproduce a real-device ad placement lookup failure
 
 // Trigger events
 __ait.trigger('backEvent');
@@ -735,6 +758,8 @@ unsubscribe(); // unsubscribe
 | `TossAds.destroy/destroyAll` | No-op |
 | `loadFullScreenAd` / `showFullScreenAd` | Similar flow to GoogleAdMob |
 
+> Unless a failure dial is set (`failureModes.loadAdMob`, panel `forceNoFill`), the events above fire the same way every time — the mock does not use `adGroupId` to decide the outcome, and it does not model a server-side placement-resolution step. A real device can fail placement lookup itself before any ad exists (e.g. `PLACEMENT_ID_FETCH_FAILED`) and reject immediately, so a mock `loaded` event is not a signal that an ad will actually serve on a real device. To reproduce this failure locally: `__ait.patch('failureModes', { loadAdMob: 'PLACEMENT_ID_FETCH_FAILED' })`.
+
 ### Events
 
 | API | Mock behavior |
@@ -842,6 +867,19 @@ it('can write and read from Storage', async () => {
 });
 ```
 
+## On-device test runner (`debugger-test`)
+
+"Using in tests" above verifies mocks in desktop jsdom. The runner that runs the same style of tests **against the real SDK inside the Toss app WebView on a real phone (environment 3)** moved to `@ait-co/debugger` (#818) — the bin is now `debugger-test`, renamed from `devtools-test`.
+
+```bash
+pnpm add -D @ait-co/debugger
+pnpm exec debugger-test 'src/**/*.ait.test.ts' \
+  --scheme-url "intoss-private://my-mini-app?_deploymentId=<uuid>" \
+  --cell-sdk-line 3.x --cell-platform ios --report-dir .ait-report
+```
+
+The full flag reference, QR-scan procedure, and artifact layout are now documented in `@ait-co/debugger` — see `debugger-test --help`. The one line this package still owns is the mini-app entry point: `import '@ait-co/debug-console/auto'` ([section above](#on-device-debugging-in-one-line)).
+
 ## SDK update tracking
 
 devtools tracks [`@apps-in-toss/web-framework`](https://www.npmjs.com/package/@apps-in-toss/web-framework), and [`sdk-example`](https://github.com/apps-in-toss-community/sdk-example) tracks both the original SDK and devtools. When a new SDK version is released, the flow is: (1) devtools catches up on mock/type signatures → (2) sdk-example incorporates both new versions together. If a devtools-only PR breaks sdk-example, both are addressed together.
@@ -956,176 +994,40 @@ import '@ait-co/devtools/panel';
 
 ## MCP Server
 
-AI coding agents (Claude Code, Cursor, etc.) can observe a running mini-app directly via [MCP (Model Context Protocol)](https://modelcontextprotocol.io/). A single `devtools-mcp` binary provides two modes.
-
-A local browser (env 1) and a phone Toss WebView (env 2/3) both speak CDP, so every tool works identically in both environments — the only difference is the attach strategy (`--target=relay` vs `--target=local`).
-
-| Mode + target | Invocation | Env vars | Target | Tools |
-|---|---|---|---|---|
-| `--target=mobile` (env 2) | `devtools-mcp` → `start_debug({mode:'relay-sandbox'})` | `AIT_RELAY_BASE_URL`, `AIT_TUNNEL_BASE_URL` | Real-device Safari/WebKit PWA (external Chii relay + cloudflared tunnel, env 2) | console/network/page + DOM/snapshot/screenshot |
-| `--mode=debug --target=relay` (default, env 3) | `devtools-mcp` → `start_debug({mode: 'relay-staging'})` | — | Dog-food bundle on a phone (CDP/Chii relay + cloudflared tunnel, env 3) | same + `AIT.*` |
-| `--mode=debug --target=local` (env 1) | `devtools-mcp --target=local` | `MCP_ENV=mock` (auto) | Local Chromium launched by the MCP server (CDP direct-attach, no relay needed, env 1) | same |
-| `--mode=dev` | `devtools-mcp --mode=dev` | `MCP_ENV=mock` (auto) | Mock state from a running Vite dev server (AIT.* only, no CDP) | `AIT.*` (+ `devtools_get_mock_state` alias) |
-
-`--target=local` opens `AIT_DEVTOOLS_URL` (default `http://localhost:5173`) and attaches directly to a local Chromium — no relay or tunnel required. `--mode=dev` reads the mock-state HTTP endpoint of the Vite dev server and does not provide CDP tools. Switch environments in-session with `start_debug(mode)`: `relay-sandbox` (env 2 PWA), `relay-staging` (env 3 dogfood), `local-browser` (env 1).
-
-#### Environment 2 (real-device PWA CDP) — `--target=mobile`
-
-Debug on a real phone using Safari/WebKit without Toss review. The Vite dev server with [`tunnel:{cdp:true}`](#tunnel-option) brings up both an app HTTP tunnel and a Chii relay tunnel. The MCP server attaches to that relay and provides `start_attach` → launcher QR.
-
-**Setup procedure:**
-
-1. Start the Vite dev server in CDP tunnel mode:
-   ```bash
-   AIT_TUNNEL_CDP=1 pnpm exec vite --config e2e/fixture/vite.config.ts
-   ```
-   The terminal banner prints two URLs:
-   - **App HTTP tunnel** `https://<A>.trycloudflare.com` → set as `AIT_TUNNEL_BASE_URL`
-   - **Relay wss tunnel** `wss://<B>.trycloudflare.com` → set `AIT_RELAY_BASE_URL` to its `https://` form
-
-2. Start the MCP server in mobile mode (separate terminal):
-   ```json
-   {
-     "mcpServers": {
-       "ait-debug": {
-         "command": "npx",
-         "args": ["-y", "@ait-co/devtools", "devtools-mcp"],
-         "env": {
-           "AIT_RELAY_BASE_URL": "https://<B>.trycloudflare.com",
-           "AIT_TUNNEL_BASE_URL": "https://<A>.trycloudflare.com"
-         }
-       }
-     }
-   }
-   ```
-
-3. In a Claude Code session:
-   ```
-   start_debug({mode: 'relay-sandbox'})
-   start_attach()
-   ```
-   Scan the QR with your phone camera. The launcher PWA opens the app in a frame and injects Chii target.js.
-
-4. `list_pages()` → expect one page. Use `take_screenshot()` and other CDP tools.
-
-**Env 2 fidelity boundary**: uses the mock SDK (`call_sdk` hits the mock). For real SDK fidelity, move to env 3. CDP runs on the real WebKit engine, so DOM, console, and screenshot reflect the real device screen.
-
-**Local-PC verification**: `e2e/launcher-cdp.test.ts` automates node-side relay startup (`startChiiRelay({port:0})`) and launcher param forwarding (Playwright). Browser-side Chii target.js injection is not automated in CI due to the localhost host gate (Layer B1) and ws:// vs wss:// constraints — completed by the manual procedure above on a real device with a trycloudflare.com hostname.
-
-### Debug mode (CDP via Chii)
-
-For a step-by-step walkthrough of the on-device relay debug loop (dog-food build → QR scan → relay attach) including common failure recovery, see **[`docs/dogfood-relay-loop.md`](./docs/dogfood-relay-loop.md)** (Korean). For crash triage — `list_pages.crashDetectedAt`, iOS Console.app `.ips` analysis, and the redact procedure — see **[`docs/crash-triage.md`](./docs/crash-triage.md)** (Korean).
-
-Read-only tools only. Tools are registered in two tiers based on attach state — before attach, only the bootstrap tools (`start_attach`, `list_pages`) are visible; once a relay/local page attaches, the attach-dependent tools are registered dynamically in the same session via `notifications/tools/list_changed` (no session restart needed). The phone attach roundtrip is fully wired; all that remains is a single on-device acceptance run. The tool layer is CI-verified via a mockable injectable CDP connection / AIT source.
-
-Running `devtools-mcp` as a stdio server starts a local Chii relay on an OS-assigned port and opens a cloudflared quick tunnel, printing a public `wss://*.trycloudflare.com` URL and a QR code in the terminal (secrets/auth codes are never printed). When the phone enters the dog-food entry point, the in-app attach UI connects to the relay with that URL, and the agent reads console/network/page state via `chrome-devtools-mcp`-compatible tools — diagnosing regressions without anyone watching the phone.
-
-Environment 3 (intoss-private relay) — start `devtools-mcp` as-is, then enter via `start_debug(mode)`:
+The MCP surface (daemon, attach, CDP tools) moved to `@ait-co/debugger` (#818). Point your agent's registration at debugger, not devtools:
 
 ```json
 {
   "mcpServers": {
     "ait-debug": {
-      "command": "pnpm",
-      "args": ["exec", "devtools-mcp"]
+      "command": "npx",
+      "args": ["-y", "-p", "@ait-co/debugger", "debugger"]
     }
   }
 }
 ```
 
-- Environment 3 (dog-food relay): `start_debug({mode: 'relay-staging'})`
-**`start_debug(mode)` is the single in-session entry path.**
-
-| Tool | CDP / AIT backing | Description |
-|---|---|---|
-| `list_console_messages` | `Runtime.consoleAPICalled` | Recent console.log/warn/error messages (level, text, timestamp, args) |
-| `list_network_requests` | `Network.requestWillBeSent` + `responseReceived` | Recent XHR/fetch requests (url, method, status, timing) |
-| `list_pages` | Chii relay target list | Attached pages + tunnel status + wss URL |
-| `start_attach` | (pure synthesis + attach wait) | Splices `debug=1` + the relay URL into an `ait deploy --scheme-only` URL, prints a QR, then waits in the same call until the phone attaches (QR generation and attach in one call). A `mode` arg can switch the session environment too, and the TOTP code is re-minted automatically during the wait. Entry tool for env 2 and 3 (bootstrap) — no `list_pages` needed first |
-| `get_dom_document` | `DOM.getDocument` | DOM tree read (structural/layout regression diagnosis) |
-| `take_snapshot` | `DOMSnapshot.captureSnapshot` | Page snapshot (documents + interned strings, visual regression) |
-| `take_screenshot` | `Page.captureScreenshot` | Page PNG screenshot (returned as an MCP image content block) |
-| `measure_safe_area` | `Runtime.evaluate` | Runs a safe-area probe on the attached page → returns normalized safe-area insets, viewport geometry, DPR, and User-Agent. Read-only. Use in a relay session to get ground-truth values for upgrading a viewport preset from extrapolated/placeholder to measured. Requires attach (`list_pages` first) |
-| `evaluate` | `Runtime.evaluate` | Evaluates an arbitrary JS expression on the attached page (returnByValue) and returns the result. **Not read-only** — the expression can have side effects (DOM mutations, SDK calls, state changes). Requires attach |
-| `call_sdk` | `window.__sdkCall` bridge (via `Runtime.evaluate`) | Calls a dog-food SDK method via the `window.__sdkCall` bridge (exported by `@apps-in-toss/web-framework` in `__DEBUG_BUILD__` bundles only). **Not read-only** — SDK calls have side effects (navigation, payments, permissions, etc.). Hits the real SDK on env 3, mock SDK on env 1. Env 2 (PWA) does not inject the SDK — not available there. Requires attach. Returns `{ok,value}` / `{ok,error}` |
-| `AIT.getSdkCallHistory` | AIT domain | SDK call trace (method, args, result/error, timestamp) |
-| `AIT.getMockState` | AIT domain | Mock state snapshot (`window.__ait`) |
-| `AIT.getOperationalEnvironment` | AIT domain | `getOperationalEnvironment()` + SDK version |
-
-`AIT.*` covers what raw CDP cannot; the same MCP server forwards it alongside CDP. In debug mode the in-app side answers over the Chii channel.
-
-### Dev mode (mock state)
-
-`devtools-mcp --mode=dev` reads the mock state from a running browser. It shares the same `AIT.*` tool surface as debug mode.
-
-#### Architecture
-
-```
-Browser (aitState)
-  └─ POST /api/ait-devtools/state (auto-pushed by the panel on every state change)
-       └─ Vite dev server (unplugin with mcp: true)
-            └─ GET /api/ait-devtools/state
-                 └─ MCP stdio server (dist/mcp/server.js)
-                      └─ AI agent (AIT.getMockState tool)
-```
-
-#### Setup
-
-**1. Add `mcp: true` to the Vite plugin**
-
-```ts
-// vite.config.ts
-import aitDevtools from '@ait-co/devtools/unplugin';
-
-export default {
-  plugins: [aitDevtools.vite({ mcp: true })],
-};
-```
-
-**2. Configure your MCP client (e.g. Claude Code `.claude/settings.json`)**
-
-```json
-{
-  "mcpServers": {
-    "ait-devtools": {
-      "command": "pnpm",
-      "args": ["exec", "devtools-mcp", "--mode=dev"],
-      "env": {
-        "AIT_DEVTOOLS_URL": "http://localhost:5173"
-      }
-    }
-  }
-}
-```
-
-`AIT_DEVTOOLS_URL` defaults to `http://localhost:5173` — you can omit it if you're using the default port.
-
-**3. Open the app in your browser, then call the tool from your AI agent**
-
-```
-> AIT.getMockState
-```
-
-Returns the full current mock state (permissions, location, auth, network, IAP, etc.) as JSON.
-
-| Tool | Description |
-|---|---|
-| `AIT.getMockState` | Returns the current `AitDevtoolsState` snapshot (read-only) |
-| `AIT.getOperationalEnvironment` | Environment + version derived from the mock state's `environment` + `appVersion` |
-| `AIT.getSdkCallHistory` | Empty in dev mode (the HTTP endpoint records no trace) |
-| `devtools_get_mock_state` | Backward-compatible alias of `AIT.getMockState` (prefer `AIT.getMockState` in new configs) |
+What this gives you: CDP observation of a running mini-app across environments 1 (local browser), 2 (PWA), and 3 (intoss-private WebView) — console, network, DOM, snapshot, screenshot — plus `start_attach` for on-device entry in environments 2/3. The full tool list, mode/target matrix, and per-environment config live in the [`@ait-co/debugger`](https://www.npmjs.com/package/@ait-co/debugger) package docs.
 
 ## Package export structure
 
+The entry points this package actually ships:
+
 | Import path | Purpose |
 |---|---|
-| `@ait-co/devtools` or `@ait-co/devtools/mock` | All mock exports (bundler alias target) |
+| `@ait-co/devtools` (= `/mock`) | Bundler alias target, all mock exports |
 | `@ait-co/devtools/panel` | Floating DevTools Panel (auto-mounts on import) |
 | `@ait-co/devtools/unplugin` | Bundler plugin (.vite, .webpack, .rspack, .esbuild, .rollup) |
-| `@ait-co/devtools/mcp/server` | Dev-mode MCP stdio server function (Node.js) |
-| `@ait-co/devtools/mcp/cli` | `devtools-mcp` bin entry point (debug / dev mode, Node.js) |
-| `@ait-co/devtools/in-app` | In-app debug attach — runtime gate (layers B/C) + Chii target.js injection. The consumer wraps the import in `if (__DEBUG_BUILD__)` so it is DCE'd from release builds — dog-food builds only |
-| `@ait-co/devtools/in-app/auto` | Self-gating side-effect entry — a single `import '@ait-co/devtools/in-app/auto'` line wires attach + SDK bridge. Active only when `?debug=1` / `?relay=` are in the URL or it is a DEV build; stays dormant on normal production loads. See the [section above](#on-device-debugging-in-one-line) |
+
+Everything below is a **transition stub** — it exists only in 0.2.x and is removed in 1.0.0 (#818). Migrate to the new package.
+
+| Import path | New home | On import |
+|---|---|---|
+| `@ait-co/devtools/mcp/server` | `@ait-co/debugger/mcp/server` | throws |
+| `@ait-co/devtools/mcp/cli` | `@ait-co/debugger/mcp/cli` | throws |
+| `@ait-co/devtools/test-runner` | `@ait-co/debugger/test-runner` | throws |
+| `@ait-co/devtools/in-app` | `@ait-co/debug-console` | no-op + one `console.error` |
+| `@ait-co/devtools/in-app/auto` | `@ait-co/debug-console/auto` | no-op + one `console.error` |
 
 ## License