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", "Dana Oren", "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 (a git_modules/dreamteamer clone shadows node_modules/dreamteamer). It loads exactly one module of it — the engine's public API (import … from 'dreamteamer') — and opens the workspace through it, so engine extensions the workspace installs take part in every compile and schema edit the editor makes, exactly as on the CLI.

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.36.0 or later — the release whose record layers and module-owned collections read, rename and commit the way this extension's source marks and commit action assume. 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.36 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.

Module apps

A module's ui/app.js — from an npm package or a workspace under git_modules/ — runs in a sandboxed frame inside the panel (sandbox="allow-scripts", no same origin, no network), never in the panel itself. Every record it asks for, every value it is shown and every change it sends back goes through a bridge that allows only its own collections, plus what YOU grant it in the workspace's own .vscode/settings.json ("dreamteamer.moduleApps": { "<module>": { "reads": [...], "writes": [...] } } — the same entry in your user settings or a .code-workspace file grants nothing); without a grant it is read-only, it writes only in its own repository, and it cannot commit or change the schema. What it can still do: copy what it may read into the collections you let it write — a layer's records leave the machine when you push the layer — and, as any web page, open a peer connection (WebRTC) to a server it names. The grant is the workspace's: the settings file is tracked, so everyone who clones the workspace shares it.

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 public API: Store · presentation · schema ops · check
             ▼
   validated write → one git commit

No server. src/api.ts is a port of the engine's HTTP 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.

A collection can set display.nav.section: workspace (or another section key) in its descriptor or a workspace overlay. The editor groups it under that section before applying namespace and module grouping. This also works for workspace-owned collections and visible runtime collections such as an overlaid agents collection. Internal schema collections that were hidden remain hidden. The collection name, storage path, record references and saved view routes are unchanged.

Without a section, or with a blank section, existing namespace/module grouping is preserved. Sections share the folder keys used by dreamteamer.navGroups; dreamteamer.navOrder orders them. Saved views remain children of their collection. Section keys identify a single folder, not a filesystem path or a nested navigation path.

dreamteamer