Command	Purpose
`pnpm poc:qr`	QR login. Writes the token file.
`pnpm control:bridge`	Start the daemon. It listens on `http://127.0.0.1:8788/mcp`.
`pnpm poc:dm`	Send one test DM to zzib.
`pnpm test:comm`	Run the unit tests for the pure logic.
`pnpm cdp:probe`	Check CDP access and event delivery.
`pnpm check`	Type check the daemon code.

Transport

The daemon uses Chrome DevTools Protocol at this time. Start the client with --remote-debugging-port=9222. The daemon connects to the Discord page and runs the actions in the real client.

The target transport is the validated core bridge. See ../docs/core-bridge.md. The daemon logic is the same on both transports.

Pacing

Every command gets a random delay of 500 to 2800 ms. One queue serializes the commands. The queue coalesces identical concurrent reads. State reads use the cache. DEBUG=1 logs each command and its delay.

Live test target

The only permitted live-send target is user zzib. See ../docs/testing.md for the full setup.

Verified

QR login works end-to-end. The token came from a phone scan.
The CDP transport works. get_state returned the real account and 7 guilds. send_dm delivered a real DM to zzib.
Pacing stayed inside the 500 to 2800 ms window.

Findings

Official discord.js is bot-only. It fails at login with a user token. The popular selfbot fork is archived. Do not use either. The core is the real Vesktop client.
MCP SDK 1.30.0 Streamable HTTP works as used here.
CDP gives control and events with no Vesktop patch. Raw CDP has no guardrails. The validated core bridge is the target for this reason.
pnpm 11: this folder is its own workspace root. Build approvals live in pnpm-workspace.yaml (allowBuilds).