Files
Veskslop-t/poc/README.md
T

2.0 KiB

Veskslop daemon

The external daemon and the development spikes. The daemon holds all logic and exposes MCP.

Read the project docs first: ../docs/INDEX.md.

Setup

pnpm install

Run commands

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).