This area is how the Tom framework is developed inside the editor: a VS Code extension that hosts a Dart bridge, so framework tooling and automation can be written in Dart — the same language as the framework itself — with full access to the VS Code API. It is one of the seven building blocks of Tom, and it sits on the parallel tooling line, alongside the build CLI and the cloud/provisioning layer.

The problem it solves is a language mismatch. VS Code extensions are TypeScript, but the Tom framework, its scripts, and its developers' fluency are all in Dart. Rewriting every piece of editor automation in TypeScript would fork the framework's tooling into a second language and a second skill set. Instead, this area keeps a thin TypeScript host and pushes the real logic into Dart: a Dart process the extension spawns and drives, running Dart scripts through the D4rt interpreter with the whole editor surface available to them.

How it works

Three layers cooperate, from the editor down to the scripts a developer writes:

1. The TypeScript extension is the host registered with VS Code. It owns the webview wiring, the command registrations, and the lifecycle, and it spawns the Dart bridge. 2. The Dart bridge is the Dart process the extension spawns. It plays two roles at once: it talks JSON-RPC to the extension over stdin/stdout and runs Dart scripts through D4rt with full editor access, and it hosts a CLI Integration Server on a local TCP port that out-of-process clients — Tom CLI tools and *.d4rt.dart scripts — connect to. 3. The scripting API is the typed Dart surface scripts are written against — bridge-agnostic abstractions over the VS Code APIs, plus the client that connects a Dart program to the bridge's CLI Integration Server.

Because the scripts execute through D4rt, the same sandboxed interpreter that powers Tom's runtime scripting also powers its editor automation — a script can be iterated without recompiling the extension.

The components and modules

The area is delivered by the Vscode component (vscode) and its three modules.

• tom_vscode_extension — the @Tom VS Code extension itself, in practice an

AI-assisted development cockpit. Beyond the TypeScript host duties (registering commands and webviews, managing the bridge lifecycle), it provides multi-model chat (Anthropic via both the direct SDK and the Agent SDK, GitHub Copilot, and a local LLM), a multi-transport prompt queue with follow-ups and timed requests, a shared tool registry published to external clients through a standalone MCP server, a per-window status page, and the workflow, tracker, and quest panels used to develop Tom. - tom_vscode_bridge — the Dart bridge server the extension launches. It plays two roles: a D4rt script host that runs Dart scripts with full VS Code API access and returns JSON results to the extension over stdin/stdout, and the CLI Integration Server (TCP 19900–19909) that forwards JSON-RPC from out-of-process clients into the same editor API, streaming notifications and reverse callbacks back. (The API wrappers themselves live in the scripting API, not here.) - tom_vscode_scripting_api — the typed, bridge-agnostic Dart client for that CLI Integration Server, exposing three API families behind one connection: VS Code scripting (window, workspace, commands, extensions, lm, chat, plus a VsCodeHelper), a 1:1 Anthropic Agent SDK mirror (streaming query(), in-process Dart tools, a canUseTool permission callback), and the extension's own features (todos, the prompt queue, timed requests, documents, workspace metadata, send-to-chat).

How it fits the rest of Tom

This area is an AI-assisted development cockpit for building the framework, not a part of any shipped Tom application. It is the authoring counterpart to Tom Forge (the framework's GUI/IDE) and the build CLI: where the build tools build and publish from the command line and Forge provides visual editors, the VS Code extension brings Tom's Dart-first automation directly into the editor most developers already use.

It also connects to the broader Tom story through D4rt and Tom Brain. The bridge's primitive API includes a vscode.* surface that procedures can call, so Tom Brain's procedures — and other AI-driven workflows — can reach into the editor through the same scripting layer that human-written scripts use.