dreamteamer-vscode

Structured, schema-validated records as plain files in git — browsed and edited natively in VS Code, and readable by your coding agent.

New here? Open an empty folder and click Create a dreamteamer workspace here in the dreamteamer view. It scaffolds itself in a terminal you can watch. Or from a shell:

npm install dreamteamer
npx dreamteamer init
npx dreamteamer compile

The surface for dreamteamer workspaces. VS Code is the UI; dreamteamer is the engine. There is no web server, no port, and no browser tab — the whole workspace lives in the editor.

what it is

Two halves in one extension.

Native VS Code — the things only an editor can do.

Collections tree in the activity bar: ungrouped collections, then descriptor group: folders. Records labeled by their title field, newest-first for date-prefixed ids, with per-collection filter/sort (ephemeral) 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 (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 status-bar item carrying the count and a badge on failing files.
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 hosting the full browse/edit experience: rich tables with search/filter/sort/columns/pagination, five layouts (table, cards, kanban, calendar, map), record detail with revisions, and the data-model designer.

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 — "reusable" is invisible until you click again), and TreeView has no double-click event, so it's two command fires arriving inside 400ms.

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.

One engine. src/engine.ts dynamic-imports the engine the workspace 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 dt runs.

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.

repo layout

path	what
`src/extension.ts`	activation, tree wiring, every command
`src/engine.ts`	loads the workspace's engine once, in-process
`src/api.ts`	the clean REST contract, server removed
`src/panel.ts`	the app tabs: explorer click rules, local assets, CSP, RPC dispatch
`src/titles.ts`	route → tab title (collection, record title, Data Model, saved view)
`src/native.ts`	refs, diagnostics, badges, status bar
`src/formEditor.ts`	schema-driven record form (CustomTextEditor)
`src/tree.ts`, `src/fsdata.ts`	the collections tree and its FS read layer
`webview/`	the data app (Vue), built to `dist/webview`

dreamteamer-studio remains as an archive of the browser surface; it is no longer built, served, or depended on.

Issues and source

The engine is open source: github.com/dreamteamer/dreamteamer — that is where the collections, records, validation and CLI live, and where issues for either the engine or this extension are welcome.

This extension is a surface over it. Anything it can do is doable from a dreamteamer CLI invocation an agent can run headlessly, by design.