## Summary
Adds network inspection for Chromium (CDP) devices by extending the
**existing** RN network tools rather than adding a new one — so there's
one network-viewing surface across platforms.
- **`view-network-logs`** and **`view-network-request-details`** now
also accept a `chromium-cdp-<port>` `device_id`. They dispatch on the
device id (the same pattern the ported `debugger-*` tools and
`gesture-tap` use): RN → the Metro-injected `fetch` interceptor;
Chromium → the browser's native CDP `Network` recording for the **active
tab**. Same flags, same output shape.
- Both widen their capability from RN-only to `DEBUGGER_TOOL_CAPABILITY`
(apple + android + chromium).
## How the Chromium side works
A lean **`NetworkManager`** (`chromium-server/network.ts`) keeps a
passive, always-on capped ring buffer fed by the page's CDP `Network`
events, re-attached on tab switch so it follows the active tab. No
in-app injection (the browser exposes `Network` natively).
`view-network-request-details` fetches the response body on demand via
`Network.getResponseBody`, and reuses the existing header-redaction.
**Read-only**, matching the `view-network-*` contract. Per review, the
earlier cut's standalone `chromium-network` tool and its Fetch-based
**routing / abort / mock / HAR** were **removed** — the read capability
on the existing tools is sufficient.
> Rebased onto `main` after #334 (tabs) merged — diff is network-only.
## Test plan
- [x] `NetworkManager`: recording (fields/duration/headers/failed,
oldest-first), `get()`, `reattach` (Network.enable), `dispose` (disable
+ detach).
- [x] Chromium branch of both view tools: capability now admits
chromium, `services()` routing, paginated render matching the RN format,
no-traffic message, header redaction, body via
`Network.getResponseBody`, not-found.
- [x] Updated the RN locked-tools registry test (these two are no longer
RN-locked; 15→13) + a positive assertion they now admit Chromium. RN
integration tests unchanged/passing.
- [x] Full suite **1136 pass**; `tsc --build` + `typecheck:tests` +
prettier clean; tool-description gate **9.25 ≥ 9.0**.
- [x] **Live (Chrome for Testing)**: `view-network-logs --device_id
chromium-cdp-9222` → `=== NETWORK LOGS (page 1/1, 1 total) === {id: …}
"GET example.com" 200 Document`; `view-network-request-details` → full
request/response headers + body via `getResponseBody`.
## Summary
The Electron support added in #247 is **generic Chromium/CDP under the
hood**. The discovery layer probes the Chromium-default CDP port
(`9222`) and any `ARGENT_*_PORTS` entries; the connection picks the
first non-devtools page target; describe is a plain in-page DOM walker;
input/screenshot/screencast/navigation/JS-debugger are all straight CDP.
Nothing in that path is Electron-specific — the only Electron-specific
piece is the *launcher* (`boot-electron.ts`, which resolves and spawns
an Electron binary).
So any Chromium-family runtime exposing a CDP endpoint — an Electron
app, **or** Chrome/Brave/Edge/WebView2 launched with
`--remote-debugging-port` — is discoverable and drivable through the
same tool surface. This PR renames the platform discriminator (and
everything keyed off it) from `electron` to `chromium` so the naming
matches reality.
## What changed
**Public/contract surface (clean hard rename, no back-compat aliases):**
- Platform discriminator `"electron"` → `"chromium"`; device id
`electron-cdp-<port>` → `chromium-cdp-<port>`.
- `ToolCapability.electron` → `.chromium`; the capability-gate rejection
now reads `Tool 'X' is not supported on chromium app`.
- Env `ARGENT_ELECTRON_PORTS`(`_FILE`) →
`ARGENT_CHROMIUM_PORTS`(`_FILE`); ports cache
`~/.argent/electron-cdp-ports.json` → `chromium-cdp-ports.json`; HTTP
surface `/electron-server/` → `/chromium-server/`.
**Files / dirs / symbols:**
- `src/electron-server/` → `src/chromium-server/`; blueprints
`electron-cdp` / `electron-js-runtime-debugger` → `chromium-*`;
`describe`/`open-url`/`launch-app` `platforms/electron.ts` →
`chromium.ts`; `keyboard/electron-keys` → `chromium-keys`;
`utils/electron-discovery` → `chromium-discovery`.
-
`ElectronServer`/`ElectronCdpApi`/`ElectronJsRuntimeDebugger`/`describeElectron`/`discoverElectronDevices`/`ELECTRON_ID_PREFIX`/…
→ `Chromium*` / `CHROMIUM_*`. Tests renamed to match.
**Stays "electron" (the Electron-specific launcher):**
- `boot-device` keeps the `electronAppPath` / `electronPort` /
`electronArgs` inputs, and `boot-electron.ts` still resolves & spawns an
Electron binary. It just yields a `chromium` device now (an Electron app
*is* a Chromium/CDP runtime).
**Skills:** `argent-device-interact`, `argent-metro-debugger`,
`rules/argent.md`, and the RN-workflow reference were reframed to
describe **Chromium (CDP)** availability — Electron apps *plus* any
Chromium browser over CDP (auto-discovered on `9222` /
`ARGENT_CHROMIUM_PORTS`) — instead of Electron only.
## Test plan
- [x] `tsc --build` clean
- [x] `typecheck:tests` clean
- [x] **1116 vitest cases pass (126 files)**
- [x] prettier clean on all changed/renamed files
- [x] Full-repo sweep: every remaining "electron" mention is intentional
(the launcher path + skill prose explaining Electron as one kind of
Chromium/CDP app); `electronic` in LICENSE/COC untouched.
filip131311