dreamteamer for VS Code

Structured, modular memory for coding agents — and this is the half you look at.

Your agent already has a memory. You just can't see it: prose, in a black box somewhere, untracked and unshared. dreamteamer makes it plain files with a schema, which your agent reads natively — no API, nothing intercepted.

This extension is the other side of that trade. Files are what the agent wants; tables, boards and forms are what you want. Same records, same folder, same git history — the editor just makes them look like an app.

Get started

Search dreamteamer in your editor's extensions panel. It is published to both the VS Code Marketplace and Open VSX, so VS Code, Cursor, VSCodium and Windsurf all resolve it.

Then open an empty folder and click Create a dreamteamer workspace here in the dreamteamer view. It scaffolds itself in a terminal you can watch — for a tool that writes files into your folder, seeing it happen beats being told about it.

Or from a shell:

npm install dreamteamer
npx dreamteamer init
npx dreamteamer compile

There is no server, no port and no browser tab. The whole workspace lives in the editor.

What you get

Native VS Code — the things only an editor can do

Collections tree in the activity bar: ungrouped collections first, then descriptor group: folders. Records labelled by their title field, newest-first for date-prefixed ids, with per-collection filter and sort, and "save as view" — a durable, compile-gated ui-view record.
References are links. assignee: users/ada is cmd-clickable: go to definition, hover preview, Find All References for backlinks, and /-triggered completion offering the real records.
check is the Problems panel. Validation runs on every change and lands each violation on its own line, with a count in the status bar and a badge on failing files. An invented field or a link to a record that doesn't exist shows up the way a type error does.
Records are files. Git gutter, Timeline, diffs, blame, search — all VS Code's, none of ours.
Form editor: a schema-driven record form bound to the TextDocument, so it round-trips through the engine's own codec and coexists with editing the same file as text.

The data app — editor tabs that behave like an app

Rich tables with search, filter, sort, column selection and pagination · seven layouts — table, cards, kanban, calendar, map, diagram, gantt · record detail with revisions · and the data-model designer, where changing the schema is a normal thing you do rather than a migration you dread.

Tabs behave like the explorer's, and are titled by the content they hold ("meetings", "Robert Gil", "Data Model") rather than by the extension:

gesture	result
single click in the tree	the reusable tab re-routes and re-titles in place — browsing never piles up tabs
single click on content already open	focuses that tab instead of duplicating it
double click	pins that tab; the next single click opens a fresh reusable one beside it
navigating inside a tab (row click, breadcrumb)	the tab follows and re-titles, never spawns

Each tab persists its own route and pinning into webview state, so a window reload brings back the same set of titled tabs.

Two VS Code limits shape this: webview panels can't be real preview tabs (nothing renders italic, so "reusable" is invisible until you click again), and TreeView has no double-click event — it's two command fires arriving inside 400ms.

One engine, no drift

src/engine.ts dynamic-imports the engine the workspace itself pins, applying the same self-shadowing precedence the dreamteamer bin does (modules/ → git_modules/ → node_modules/).

The extension bundles no engine copy, so its validator cannot drift from the one your CLI and your agent sessions run. What you see in the editor is what the agent sees.

It needs engine 0.19.0 or later. Below that the extension refuses the workspace outright — it shows what to install and changes nothing on disk — rather than opening a surface whose buttons call verbs the pinned engine does not have. npm install dreamteamer@^0.19 in the workspace, then dreamteamer compile, then reload the window.

And the rule that keeps it honest: anything this extension can do is doable from a dreamteamer CLI invocation an agent can run headlessly — same validation, same sources touched, same commit shape. The UI is a surface, never a second implementation.

Architecture

VS Code extension host                         webview
┌───────────────────────────────┐             ┌────────────────────────┐
│ tree · commands · language    │             │  the data app (Vue)    │
│ providers · diagnostics       │             │  webview/src           │
│                               │  postMessage│                        │
│ panel.ts  ◄────── RPC ────────┼────────────►│  api/transport.ts      │
│ api.ts    the clean contract  │             └────────────────────────┘
│ engine.ts ─┐                  │
└────────────┼──────────────────┘
             ▼  in-process, from the WORKSPACE's own install
   dreamteamer engine: Store · presentation · schema-ops · check
             ▼
   validated write → one git commit

No server. src/api.ts is a port of the engine's server.js routes with Express removed — identical paths, query handling, response shapes and error→status mapping, called as functions. The app's api/adapter.ts is untouched; only its transport changed from fetch to postMessage.

Module bundles keep working. A workspace module's pre-built app.js still calls fetch('/api/…') per the documented contract; installApiFetchShim() answers those from the host, so the same bundle runs unchanged on any surface.

Issues

github.com/dreamteamer/dreamteamer is the open-source engine — collections, records, validation and the CLI — and it is where issues for either the engine or this extension are welcome. The extension's own source is not public.