VS Code Extension
A live revision timeline, drift findings in the Problems panel, and push / pull / generate from buttons — all native to VS Code, no terminal required. The same drift CI blocks on, shown where you write the code.
● In sync — rev 12 my-api▾ Revisions ● rev 12 just now · 17n 18e ← current ● rev 11 2h ago · 16n 17e (+1n +1e)▾ Drift 3 finding(s) ● Table "products" — missing in code ● Service "MailService" — not in architecture▾ Implementation 12/40 · 3 by AI ● users.service.ts 5 waiting
The Solarch extension puts the live state of your architecture in the Activity Bar. It scans your TypeScript on save, fetches the cloud graph every 60 seconds, and shows every place the code has drifted from the design as a native VS Code diagnostic. The CLI engine is embedded in-process, so sign in, link, pull, push, and generate run from buttons — and identity and project link are the exact same files the terminal CLI uses, fully interchangeable. The drift this extension surfaces is byte-for-byte the drift CI blocks on.
// what it does
Revision timeline
A per-workspace timeline of every observed revision — first-seen time, node/edge counts, and +/- deltas. Last 30 kept. Like Git Graph, but for system design.
Update-available alert
The status row turns blue when someone edited the canvas and the cloud revision is ahead of the last one you acknowledged. Click to acknowledge.
Live drift in Problems
Every place code has drifted from the design becomes a native VS Code diagnostic with a code and severity. Click a finding to jump to the evidence file.
Push, pull & generate
The full CLI flows from buttons: plan-and-apply push with rule-violation blocking and conflict retry, To-Be pull, and scaffold generation with surgical markers.
Implementation progress
In scaffolded repos, see filled vs. waiting members grouped by file (12/40, with a 'by AI' breakdown). Click a NOT_IMPLEMENTED member to jump to its @solarch:surgical line.
Live Entity to DTO binding
Bind a DTO to its Entity and saving the source re-syncs the fields automatically — like solarch watch. Only @solarch:bound declarations change; your code is untouched.
// how it works
Live drift, every time you save
The extension keeps a single picture of code-versus-architecture up to date as you type. There is no build step and no manual sync — it reacts to file saves and a background poll, then paints the result into the sidebar, the Problems panel, and the status bar at once.
- ›Scan: saving a .ts file rescans the tracked folder with a 500ms debounce, building the As-Is graph from your code.
- ›Fetch: the cloud To-Be graph and rule catalog are pulled and cached for 60 seconds; a background poll re-checks every 60s.
- ›Diff: the As-Is and To-Be graphs are matched node-by-node and compared against the rule catalog to produce findings by severity.
- ›Paint: status row, revision timeline, drift findings and implementation progress all update from the same state.
// revisions
A revision timeline for your system design
Open the Solarch icon in the Activity Bar and you get a native tree: a status row, a Revisions section, a Drift section, and — in repos with generated scaffolds — an Implementation section. The status row turns blue when the architecture changed in the cloud; click to acknowledge. Every observed revision is persisted per workspace with first-seen time, node/edge counts, and deltas.
- ›Revisions: last 30 kept per workspace, each with a relative timestamp and +/- node and edge deltas.
- ›Drift: findings sorted by severity — red for missing-in-code or rule violations, yellow for unapproved additions, blue for property drift.
- ›Click any finding to jump to the evidence file; cloud-only nodes are reported gracefully when no file exists yet.
- ›Marker-loss detection: if generated @solarch:surgical comments are removed, the tree warns that implementation tracking has gone blind.
● In sync — rev 12 my-api▾ Revisions ● rev 12 just now · 17n 18e ← current ● rev 11 2h ago · 16n 17e (+1n +1e) ● rev 10 1d ago · 16n 16e▾ Drift 3 finding(s) ● Table "products" — in the architecture, not in the code. ● Service "MailService" — in the code, not in the architecture. ● Controller -[QUERIES]-> Table … (ERR_002)▾ Implementation 12/40 implemented (30%) · 3 by AI ● users.service.ts 5 waiting ● orders.service.ts 3 waiting
// the CLI, in buttons
Push, pull, generate — without leaving the editor
The Solarch CLI engine runs in-process, so the full flows are driven from the view-title icons and the command palette with native VS Code UI. Push builds a plan, shows a modal summary, and applies it atomically; rule violations block the push and are listed with fix suggestions, and a revision conflict rebuilds and retries the plan once. Identity (~/.solarch/credentials) and the link (solarch.json) are the same files solarch login and solarch link write.
- ›Push: plan → modal summary → atomic apply; nodes changed in the cloud meanwhile are skipped and reported.
- ›Pull: downloads the To-Be graph to .solarch/to-be.json with a summary toast.
- ›Generate: a modal offers "Only new files" (your method bodies are never touched) or "Overwrite all" (fresh scaffold).
- ›Generated files arrive with @solarch:surgical markers, so the Implementation section immediately shows what is left to fill in.
// implementation progress
How much of the scaffold is actually filled in
In repos with generated code, the Implementation section counts how many members are implemented versus waiting — for example 12/40 implemented (30%), with a "by AI" breakdown when surgical fill was used. Members are grouped by file: expand a file to see the NOT_IMPLEMENTED members along with the business description of what each should do, and click one to jump straight to the marked line. The same counter appears in the status bar.
- ›Counts read directly from @solarch:surgical markers — filled vs. skeleton, grouped by file.
- ›Contract violations on a member are surfaced alongside the skeletons it belongs to.
- ›Each NOT_IMPLEMENTED member carries its intended behavior as a tooltip, so you fill it in with context.
- ›Status bar shows the rollup: Solarch: in sync, or Solarch: 2E 5W with the filled/total counter.
// live binding
Keep a DTO in sync with its Entity on save
Bind Entity to DTO lets you pick a Table or Model source, a DTO target, and either all fields or a chosen subset. After binding, saving the Entity re-runs the sync automatically — exactly like solarch watch — so the DTO's columns follow the source. Only property declarations are touched (each carries an @solarch:bound marker); hand-written code is never overwritten, and conflicting fields are left untouched and reported.
- ›Interactive QuickPick: source Entity/Model → target DTO → all fields or pick fields.
- ›On-save sync mirrors solarch watch — only bindings tied to the saved file re-run.
- ›Each synced property is marked @solarch:bound; conflicts are skipped and surfaced as warnings.
- ›The binding config lives in solarch.json, interchangeable with the terminal CLI.
// trust surfaces
Native diagnostics, offline fallback, one source of truth
Findings are published as VS Code diagnostics attached to their files (or to solarch.json when no file applies), so drift shows up in the Problems panel like a compiler error. If the cloud is unreachable, the view falls back to the last pulled .solarch/to-be.json with rule checks paused, instead of going blank. The engine comes from @solarch/cli — runScan, diffGraphs, evaluateEdge — the same code path the MCP server and CI use.
- ›Problems panel: every finding as a diagnostic with a solarch source and an error code.
- ›Offline: drift computed against the last pulled graph; the status bar shows a disconnect indicator.
- ›Monorepo-aware: Select Folder to Track picks the project folder, and Switch Project re-points it.
- ›The drift shown here is byte-for-byte the drift CI blocks on — one diff engine, no second opinion.
// faq
Do I need to run the Solarch CLI in a terminal?
No. The CLI engine is embedded in the extension and runs in-process. Sign in, link, pull, push, generate, and bind all run from buttons and the command palette. The terminal CLI still works and is fully interchangeable — identity lives in ~/.solarch/credentials and the project link in solarch.json, the same files solarch login and solarch link write.
How does it know when the architecture changed?
The extension polls the cloud every 60 seconds. When someone edits the canvas, the revision number advances; if it is ahead of the last revision you acknowledged, the sidebar status row turns blue with an update-available alert. Click it to acknowledge.
Where do drift findings show up?
In three places at once, all from the same diff: the Drift section of the Solarch sidebar (click to jump to the evidence file), the native Problems panel as diagnostics with a solarch source and error code, and a rollup in the status bar (for example Solarch: 2E 5W).
Will Generate or Bind overwrite my hand-written code?
No, not by default. Generate's modal offers 'Only new files', which never touches existing files including your implemented method bodies; 'Overwrite all' is opt-in and resets to a fresh scaffold. Bind only touches property declarations carrying an @solarch:bound marker, and leaves conflicting fields untouched and reported.
What happens if the cloud is unreachable?
The view falls back to the last To-Be graph pulled to .solarch/to-be.json instead of going blank. Drift is computed against that cached graph, rule checks are paused (no rule catalog offline), and the status bar shows a disconnect indicator.
Is the drift the same as what CI enforces?
Yes. The engine comes from @solarch/cli — runScan, diffGraphs, evaluateEdge — the same code path the MCP server and CI use. The drift the extension shows is byte-for-byte the drift CI blocks on.
Put VS Code Extension to work
Architecture that's verified, not guessed.