@diagrammo/dgmo 0.61.0 → 0.62.0

package/dist/index.d.ts

@@ -1,12 +1,7 @@
-import { a as DiagnosticSpec, P as PaletteConfig, C as CompactViewState, D as DgmoError } from './registry-Ch0Umdi1.js';
-export { b as ChartTypeId, c as ChartTypeMeta, d as DgmoSeverity, e as DiagnosticParams, E as EmitOptions, f as PaletteColors, g as chartTypes, h as emit, i as formatDgmoError, j as getPalette, r as resolvePaletteOrFallback, p as validate } from './registry-Ch0Umdi1.js';
-import { T as Theme } from './themes-DC6u80yr.js';
-export { G as Gazetteer, a as GazetteerEntry, M as MapCompletionOptions, b as MapData, c as MapLocationMatch, d as MapPlaceCompletion, e as MapRegionCompletion, R as RegionName, f as RegionNames, g as completeMapPlaces, h as completeMapRegions, p as palettes, s as searchMapLocations, t as themes } from './themes-DC6u80yr.js';
-
-declare function getMinDimensions(content: string): {
-    width: number;
-    height: number;
-};
+import { D as DiagnosticSpec, P as PaletteConfig, C as CompactViewState, a as DgmoError } from './dgmo-router-Dd5PTjxl.js';
+export { b as ChartTypeId, c as ChartTypeMeta, d as DgmoSeverity, e as DiagnosticParams, E as EmitOptions, f as PaletteColors, g as chartTypes, h as emit, i as formatDgmoError, j as getPalette, r as resolvePaletteOrFallback, p as validate } from './dgmo-router-Dd5PTjxl.js';
+import { T as Theme, M as MapDataSource } from './themes-DiUAG4Bf.js';
+export { G as Gazetteer, a as GazetteerEntry, b as MapCompletionOptions, c as MapData, d as MapLocationMatch, e as MapPlaceCompletion, f as MapRegionCompletion, R as RegionName, g as RegionNames, h as completeMapPlaces, i as completeMapRegions, p as palettes, s as searchMapLocations, t as themes } from './themes-DiUAG4Bf.js';
 
 /**
  * Make an SVG produced by `@diagrammo/dgmo`'s static `render()` suitable for
@@ -144,7 +139,23 @@ interface RenderOptions {
      */
     width?: number;
     height?: number;
+    /**
+     * Basemap assets for `map` charts — the data itself, or a loader returning
+     * it. `render()` reads nothing from the filesystem or the network on its own,
+     * so this is the only way a map obtains a basemap, and its presence here is
+     * what tells a caller whether a render can touch the environment.
+     *
+     * - Node / CLI / SSR: pass the `loadMapData` loader from
+     *   `@diagrammo/dgmo/advanced`. It runs only when the content really is a
+     *   map, so a non-map render never pays to read the assets.
+     * - Browser / Worker / Obsidian: pass your bundled `MapData`.
+     *
+     * Omit it and a map renders empty with an `E_MAP_DATA_NOT_SUPPLIED`
+     * diagnostic. Every other chart type ignores this option.
+     */
+    mapData?: MapDataSource;
 }
+
 interface RenderResult {
     svg: string;
     diagnostics: DgmoError[];
@@ -193,4 +204,4 @@ interface DecodedDiagramUrl {
  */
 declare function decodeDiagramUrl(url: string): DecodedDiagramUrl | null;
 
-export { CompactViewState, D3_DATA_CHART_TYPES, type DataChartInteractionOpts, type DecodedDiagramUrl, DgmoError, DiagnosticSpec, type EncodeDiagramUrlOptions, type MountD3Opts, type MountedD3Chart, type NormalizeSvgForEmbedOptions, PaletteConfig, type RenderOptions, type RenderResult, Theme, attachDataChartInteractions, decodeDiagramUrl, defaultEmbedBackground, encodeDiagramUrl, getDiagnosticSpec, getEmbedSvgViewBox, getMinDimensions, listDiagnosticCodes, mountD3DataChart, normalizeSvgForEmbed, render, supportsD3DataChart };
+export { CompactViewState, D3_DATA_CHART_TYPES, type DataChartInteractionOpts, type DecodedDiagramUrl, DgmoError, DiagnosticSpec, type EncodeDiagramUrlOptions, MapDataSource, type MountD3Opts, type MountedD3Chart, type NormalizeSvgForEmbedOptions, PaletteConfig, type RenderOptions, type RenderResult, Theme, attachDataChartInteractions, decodeDiagramUrl, defaultEmbedBackground, encodeDiagramUrl, getDiagnosticSpec, getEmbedSvgViewBox, listDiagnosticCodes, mountD3DataChart, normalizeSvgForEmbed, render, supportsD3DataChart };

package/dist/index.js

@@ -9,21 +9,21 @@ import {
   searchMapLocations,
   themes
 } from "./chunk-SQAG3UXH.js";
-import {
-  MAP_DIAGNOSTICS
-} from "./chunk-4B5YISOR.js";
 import {
   render
-} from "./chunk-BSJIPMPG.js";
+} from "./chunk-DHIBVN2D.js";
 import {
   renderErrorCard
-} from "./chunk-5PWIV7ZF.js";
+} from "./chunk-LFAQ4BLZ.js";
+import {
+  MAP_DIAGNOSTICS
+} from "./chunk-536EBUPG.js";
 import {
   D3_DATA_CHART_TYPES,
   renderDataChartD3,
   supportsD3DataChart
-} from "./chunk-6CWNVQPW.js";
-import "./chunk-VHO3YBTB.js";
+} from "./chunk-4C3BTTOL.js";
+import "./chunk-CVVICCSB.js";
 import "./chunk-3OLO2MZ6.js";
 import "./chunk-YRYKTYMQ.js";
 import "./chunk-YYVTBZZC.js";
@@ -41,9 +41,8 @@ import {
   encodeDiagramUrl
 } from "./chunk-U7VO6JAA.js";
 import {
-  REGISTRY_BY_ID,
   parseDgmo
-} from "./chunk-ZDFIY6WX.js";
+} from "./chunk-3PVUGECM.js";
 import "./chunk-2CMM36O7.js";
 import "./chunk-A2RUBBVT.js";
 import "./chunk-JWJBWNQL.js";
@@ -144,15 +143,6 @@ import {
 } from "./chunk-OLMWTJVU.js";
 import "./chunk-5WRI5ZAA.js";
 
-// src/dimensions.ts
-function getMinDimensions(content) {
-  const { chartType } = parseDgmo(content);
-  if (!chartType) return { width: 300, height: 200 };
-  const descriptor = REGISTRY_BY_ID.get(chartType);
-  const counts = descriptor?.measure?.(content) ?? {};
-  return descriptor?.minDims?.(counts) ?? { width: 300, height: 200 };
-}
-
 // src/charts-d3/interactions.ts
 var NS = "http://www.w3.org/2000/svg";
 var STYLE_ID = "dgmo-chart-interactions-style";
@@ -850,7 +840,8 @@ async function render2(text, options) {
     palette: palette.id,
     ...options?.viewState !== void 0 && { viewState: options.viewState },
     ...options?.width !== void 0 && { width: options.width },
-    ...options?.height !== void 0 && { height: options.height }
+    ...options?.height !== void 0 && { height: options.height },
+    ...options?.mapData !== void 0 && { mapData: options.mapData }
   });
   const errors = result.diagnostics.filter((d) => d.severity === "error");
   if (errors.length === 0) {
@@ -903,7 +894,6 @@ export {
   formatDgmoError,
   getDiagnosticSpec,
   getEmbedSvgViewBox,
-  getMinDimensions,
   getPalette,
   listDiagnosticCodes,
   mountD3DataChart,

package/dist/{renderer-IYMA5W7X.js → renderer-A5GFW2XH.js}

@@ -1,11 +1,11 @@
 import {
   renderLiveLinkCard
-} from "./chunk-MOT3NXB5.js";
-import "./chunk-5PWIV7ZF.js";
+} from "./chunk-FVYHDZ6Q.js";
+import "./chunk-LFAQ4BLZ.js";
 import "./chunk-6KFWC4CO.js";
 import "./chunk-4ASYQ347.js";
 import "./chunk-U7VO6JAA.js";
-import "./chunk-ZDFIY6WX.js";
+import "./chunk-3PVUGECM.js";
 import "./chunk-2CMM36O7.js";
 import "./chunk-A2RUBBVT.js";
 import "./chunk-JWJBWNQL.js";
@@ -73,4 +73,4 @@ import "./chunk-5WRI5ZAA.js";
 export {
   renderLiveLinkCard
 };
-//# sourceMappingURL=renderer-IYMA5W7X.js.map
+//# sourceMappingURL=renderer-A5GFW2XH.js.map

package/dist/{renderer-R6OKKSVR.js → renderer-Q2YHQQSN.js}

@@ -1,11 +1,11 @@
 import {
   renderMap,
   renderMapForExport
-} from "./chunk-2WPLOS4Q.js";
+} from "./chunk-USHDV2AF.js";
 import "./chunk-FWVKPEG3.js";
-import "./chunk-OPBZYISB.js";
+import "./chunk-37EHGTQ2.js";
 import "./chunk-4QV26TEG.js";
-import "./chunk-VHO3YBTB.js";
+import "./chunk-CVVICCSB.js";
 import "./chunk-A4GOY3PE.js";
 import "./chunk-UKZ7K5GS.js";
 import "./chunk-ES66QH6J.js";
@@ -24,4 +24,4 @@ export {
   renderMap,
   renderMapForExport
 };
-//# sourceMappingURL=renderer-R6OKKSVR.js.map
+//# sourceMappingURL=renderer-Q2YHQQSN.js.map

package/dist/{resolver-W3WKLWDP.js → resolver-ZLYSMILY.js}

@@ -1,9 +1,9 @@
 import {
   isSubNationalUsExtent,
   resolveMap
-} from "./chunk-DNSEG6P2.js";
+} from "./chunk-PJDX4IKR.js";
 import "./chunk-4QV26TEG.js";
-import "./chunk-4B5YISOR.js";
+import "./chunk-536EBUPG.js";
 import "./chunk-A2RUBBVT.js";
 import "./chunk-OLMWTJVU.js";
 import "./chunk-5WRI5ZAA.js";
@@ -11,4 +11,4 @@ export {
   isSubNationalUsExtent,
   resolveMap
 };
-//# sourceMappingURL=resolver-W3WKLWDP.js.map
+//# sourceMappingURL=resolver-ZLYSMILY.js.map

package/dist/{themes-DC6u80yr.d.ts → themes-DiUAG4Bf.d.ts}

@@ -1,4 +1,4 @@
-import { T as TagGroup, D as DgmoError, P as PaletteConfig } from './registry-Ch0Umdi1.js';
+import { T as TagGroup, a as DgmoError, P as PaletteConfig, f as PaletteColors, C as CompactViewState } from './dgmo-router-Dd5PTjxl.js';
 
 /** A POI / route-stop position: gazetteer name (+ optional ISO scope) or coords. */
 type PoiPos = {
@@ -477,6 +477,41 @@ declare const palettes: {
     readonly tokyoNight: PaletteConfig;
 };
 
+/**
+ * How a host supplies map basemap assets: the data itself, or a loader that
+ * returns it. Declared here (rather than accepting only `MapData`) so a Node
+ * host can hand over `loadMapData` without paying to read eleven JSON files on
+ * a render that turns out not to be a map — the loader is called only inside
+ * the map branch.
+ */
+type MapDataSource = MapData | (() => Promise<MapData>);
+/**
+ * Renders a D3 chart to an SVG string for export.
+ * Creates a detached DOM element, renders into it, extracts the SVG, then cleans up.
+ */
+type RenderForExportOptions = {
+    c4Level?: 'context' | 'containers' | 'components' | 'deployment';
+    c4System?: string;
+    c4Container?: string;
+    tagGroup?: string;
+    exportMode?: boolean;
+    mapData?: MapDataSource;
+    mapAspect?: number;
+    onMapResolverDiagnostics?: (diagnostics: readonly DgmoError[]) => void;
+    /**
+     * Canvas to draw onto, in px. Defaults to EXPORT_WIDTH x EXPORT_HEIGHT.
+     *
+     * Every chart used to render onto a fixed 1200x800 sheet, so a caller who
+     * fitted the result to a narrow column got its ASPECT too — a one-line goal
+     * meter arrived 800px tall with the bar as a sliver in the middle. Callers
+     * that know the shape they need can now say so; omitting these keeps the
+     * previous canvas exactly.
+     */
+    width?: number;
+    height?: number;
+};
+declare function renderForExport(content: string, theme: 'light' | 'dark' | 'transparent', palette?: PaletteColors, viewState?: CompactViewState, options?: RenderForExportOptions): Promise<string>;
+
 interface MapPlaceCompletion {
     /** Canonical display name (original casing), e.g. `Portland`. */
     readonly name: string;
@@ -593,4 +628,4 @@ declare const themes: {
     readonly transparent: "transparent";
 };
 
-export { type AirportData as A, type BoundaryTopology as B, type Gazetteer as G, type MapCompletionOptions as M, type ParsedMap as P, type RegionName as R, type Theme as T, type GazetteerEntry as a, type MapData as b, type MapLocationMatch as c, type MapPlaceCompletion as d, type MapRegionCompletion as e, type RegionNames as f, completeMapPlaces as g, completeMapRegions as h, type ResolvedMap as i, type MapLayoutLegend as j, type GeoExtent as k, type MapDirectives as l, type MapEdge as m, type MapPoi as n, type MapRegion as o, palettes as p, type MapRoute as q, type PoiPos as r, searchMapLocations as s, themes as t, type ProjectionFamily as u, type ResolvedEdge as v, type ResolvedPoi as w, type ResolvedRegion as x, type ResolvedRoute as y };
+export { type AirportData as A, type BoundaryTopology as B, renderForExport as C, type Gazetteer as G, type MapDataSource as M, type ParsedMap as P, type RegionName as R, type Theme as T, type GazetteerEntry as a, type MapCompletionOptions as b, type MapData as c, type MapLocationMatch as d, type MapPlaceCompletion as e, type MapRegionCompletion as f, type RegionNames as g, completeMapPlaces as h, completeMapRegions as i, type ResolvedMap as j, type MapLayoutLegend as k, type GeoExtent as l, type MapDirectives as m, type MapEdge as n, type MapPoi as o, palettes as p, type MapRegion as q, type MapRoute as r, searchMapLocations as s, themes as t, type PoiPos as u, type ProjectionFamily as v, type ResolvedEdge as w, type ResolvedPoi as x, type ResolvedRegion as y, type ResolvedRoute as z };

package/docs/ai-integration.md

@@ -9,7 +9,7 @@ Use AI coding tools to generate `.dgmo` diagrams. This guide covers Claude Code,
 Install the `dgmo` CLI, then run one command:
 
 ```bash
-brew install diagrammo/dgmo/dgmo   # or: npm install -g @diagrammo/dgmo
+brew install diagrammo/dgmo/dgmo   # or: npm install -g @diagrammo/dgmo-cli
 dgmo install                       # auto-detects every AI assistant you have
 ```
 
@@ -509,12 +509,12 @@ Cursor and Windsurf speak MCP, so `dgmo install` gives them the full render/shar
 
 ```bash
 # From node_modules (if installed as a dependency)
-cp node_modules/@diagrammo/dgmo/.cursorrules .
-cp node_modules/@diagrammo/dgmo/.windsurfrules .
-mkdir -p .github && cp node_modules/@diagrammo/dgmo/.github/copilot-instructions.md .github/
+cp node_modules/@diagrammo/dgmo-cli/.cursorrules .
+cp node_modules/@diagrammo/dgmo-cli/.windsurfrules .
+mkdir -p .github && cp node_modules/@diagrammo/dgmo-cli/.github/copilot-instructions.md .github/
 
 # From global npm install
-cp $(npm root -g)/@diagrammo/dgmo/.cursorrules .
+cp $(npm root -g)/@diagrammo/dgmo-cli/.cursorrules .
 ```
 
 Each file contains the generated DGMO AI core (anti-patterns + 43-type index), a condensed syntax reference with examples, rendering commands, and common mistakes to avoid.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@diagrammo/dgmo",
-  "version": "0.61.0",
+  "version": "0.62.0",
   "description": "DGMO diagram markup language — parser, renderer, and color system",
   "license": "MIT",
   "repository": {
@@ -12,9 +12,6 @@
   "engines": {
     "node": ">=20.6"
   },
-  "bin": {
-    "dgmo": "dist/cli.cjs"
-  },
   "main": "./dist/index.js",
   "module": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -63,14 +60,6 @@
       "types": "./dist/pert.d.ts",
       "default": "./dist/pert.js"
     },
-    "./auto": {
-      "types": "./dist/auto.d.ts",
-      "default": "./dist/auto.mjs"
-    },
-    "./element": {
-      "types": "./dist/element.d.ts",
-      "default": "./dist/element.mjs"
-    },
     "./fonts/*": "./fonts/*",
     "./block": {
       "types": "./dist/block.d.ts",
@@ -80,18 +69,12 @@
   },
   "files": [
     "dist/*.js",
-    "dist/*.mjs",
     "dist/*.d.ts",
     "dist/*.css",
     "dist/map-data/*.json",
     "fonts",
     "docs/*.md",
-    "gallery/fixtures",
-    ".claude/commands",
-    ".github/copilot-instructions.md",
-    ".cursorrules",
-    ".windsurfrules",
-    "SKILL.md"
+    "gallery/fixtures"
   ],
   "sideEffects": [
     "./src/palettes/*.ts",
@@ -137,12 +120,10 @@
     "check:size": "pnpm build && node scripts/check-bundle-size.cjs",
     "check:size:update": "pnpm build && node scripts/check-bundle-size.cjs --update",
     "check:types": "attw --pack . --ignore-rules no-resolution false-export-default cjs-resolves-to-esm",
-    "postinstall": "node -e \"console.log('\\n💡 Claude Code user? Run: dgmo install claude-code\\n')\"",
     "prepare": "husky"
   },
   "dependencies": {
     "@dagrejs/dagre": "^3.0.0",
-    "@resvg/resvg-js": "^2.6.2",
     "d3-array": "^3.2.4",
     "d3-cloud": "^1.2.9",
     "d3-geo": "^3.1.1",

package/.claude/commands/dgmo-codebase-report.md

@@ -1,172 +0,0 @@
-# /dgmo-codebase-report — Visual Architecture Report for a Codebase
-
-You are producing a **single, committable Markdown report** that explains how a codebase works, using embedded DGMO diagrams. The report is a real engineering deliverable — an onboarding / architecture document a new teammate could read top-to-bottom and understand the system. The diagrams are there to do work, not decoration.
-
-## Output contract (read this first)
-
-- **One Markdown file.** Default path `docs/architecture-report.md` (create `docs/` if missing). If the user named a path, use it.
-- **Diagrams are embedded as fenced code blocks**, not images:
-
-  ````
-  ```dgmo
-  c4 System Context
-  ...
-  ```
-  ````
-
-  Rendering surfaces (diagrammo app, online.diagrammo.app, the remark/astro/docusaurus/fumadocs wrappers, the Obsidian plugin) render these fences live. In a plain viewer (e.g. GitHub) the reader sees the DGMO source, which is still readable. Do **not** inline PNG/SVG — the fence is the source of truth and stays diffable in git.
-- **Prose carries the report.** Every diagram is wrapped in explanation: what it shows, why it matters, the non-obvious bits. A diagram with no surrounding analysis is a failure.
-- **Everything is real.** Use actual module, file, service, table, and endpoint names pulled from the code. No invented components, no placeholder "ServiceA".
-
-## Prerequisites (optional, graceful)
-
-You can produce the report with **no tools at all** — it is just Markdown. But validate the DGMO if you can:
-
-- **MCP available?** (you can call `mcp__dgmo__list_chart_types`) → use `mcp__dgmo__get_language_reference(type)`, `mcp__dgmo__get_examples(type)`, and `mcp__dgmo__validate_diagram(dgmo)`.
-- **No MCP, `dgmo` CLI installed?** → `dgmo types` lists chart types; validate a fence by writing it to a temp file and running `dgmo /tmp/x.dgmo -o /tmp/x.svg` (it exits non-zero and prints diagnostics on a syntax error).
-- **Neither?** → lean on the `dgmo-diagramming` skill for syntax. Still ship the report; tell the user it was not machine-validated and how to install the CLI (`npm i -g @diagrammo/dgmo` or `brew install diagrammo/dgmo/dgmo`).
-
-Never block the report on tooling. Never `dgmo install` or render images unless the user asks.
-
-## Step 1 — Map the codebase
-
-Read enough to be accurate, not everything. Prioritize:
-
-1. **README / docs** — stated purpose, vocabulary, intended architecture.
-2. **Manifest(s)** — `package.json`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `pom.xml`, `*.csproj`, etc. → language, framework, key deps, scripts, workspaces/monorepo layout.
-3. **Source tree** — top-level of `src/` / `app/` / `cmd/` / `lib/` and the package/module boundaries. Identify the real seams (layers, services, domains).
-4. **Entry points** — `main`, server bootstrap, CLI entry, route registration, job/worker registration.
-5. **Data layer** — ORM models, migrations, `schema.sql`, prisma/drizzle/typeorm/ent/sqlalchemy definitions.
-6. **Infra & integrations** — `Dockerfile`, `docker-compose.yml`, `k8s/`, `terraform/`, `.env.example`, queue/cache/3rd-party clients.
-
-Write down (for your own use): one-sentence purpose, tech stack, the 5–12 top-level components and how they depend on each other, the 1–3 most important runtime flows, the data model, external dependencies.
-
-## Step 2 — Choose the diagrams (fit, not formula)
-
-A good report is 3–7 diagrams that form a **narrative**: zoom from the outside in, then show behavior, then data. Pick from this matrix based on what the code actually has — skip anything that doesn't apply.
-
-| Signal in the codebase | Chart type | Section it anchors |
-|---|---|---|
-| Any system with external users/deps | `c4` (context, then container) | "System at a glance" — almost always include one |
-| Internal modules/packages with dependencies | `boxes-and-lines` | "Module map" — the dependency graph, grouped by layer/domain via tags |
-| REST/GraphQL/RPC handlers, key workflows | `sequence` | "Key flows" — 1–3 important request/event paths |
-| DB models / migrations / schema | `er` | "Data model" |
-| Docker / k8s / cloud / LB / queues | `infra` | "Infrastructure & traffic" |
-| Status fields, workflow/state machines | `state` | "Lifecycle" |
-| Class/interface hierarchies that matter | `class` | "Core types" |
-| Cross-team / cross-service process | `swimlane` | "End-to-end process" |
-
-Rules:
-- **Always** open with a `c4` context or container view — the high-level orientation.
-- **Always** include a `boxes-and-lines` **module/dependency map** for any non-trivial repo — this is the highest-value diagram for understanding code and the main reason this report exists.
-- Behavior → `sequence`. Don't ship more than 3 sequences; pick the flows that teach the system.
-- `er` only if there's a real schema. `infra` only if there's real infra config. Don't force-fit.
-- Small repo (a script, a single-file lib)? 1–2 diagrams is the right answer. Don't pad.
-
-## Step 3 — Pull syntax for each type
-
-For every chart type you'll use, fetch idiomatic syntax before writing it:
-
-- MCP: `mcp__dgmo__get_language_reference("<type>")` + `mcp__dgmo__get_examples("<type>")`.
-- No MCP: consult the `dgmo-diagramming` skill.
-
-DGMO syntax reminders (common mistakes):
-- First line is `type Title` (e.g. `c4 System Context`) — no colon.
-- No colons in chart-type declarations, tag declarations, or directives.
-- Arrows carry inline labels: `User -POST /login-> API` (sync), `API ~publish~> Queue` (async). Never Mermaid-style `-->`/`->>`.
-- Tags color groups: `tag Layer as l` then indented `Frontend blue`. Color is a trailing token, no parens, no hex.
-- ER columns are space-separated: `id int pk` (the one carve-out). Infra node props need a colon (`latency-ms: 50`).
-- Lean on inference: `User` → actor, `PostgresDB` → database; only declare a type when the name won't infer it.
-
-## Step 4 — Write the report
-
-Build the Markdown around the diagrams. Structure:
-
-```markdown
-# <Project> — Architecture Report
-
-> Generated from a codebase walkthrough on <date>. Diagrams are DGMO fences —
-> view in the Diagrammo app, online.diagrammo.app, or any DGMO-enabled docs site
-> to see them rendered; the raw source is readable as-is.
-
-## TL;DR
-- **What it is:** <one sentence>
-- **Stack:** <language / framework / db / infra>
-- **Shape:** <monolith | modular monolith | services | library | CLI> with <N> top-level modules.
-- **Read next:** the Module map below is the fastest way in.
-
-## System at a glance
-<2–4 sentences framing the system and its external dependencies.>
-
-```dgmo
-c4 System Context
-...
-```
-<1–3 sentences reading the diagram: what each actor/system is, the key boundary.>
-
-## Module map
-<What the internal pieces are and how they depend on each other. Call out the
-seams, the direction of dependencies, and anything surprising (cycles, a god
-module, a layer that reaches around another).>
-
-```dgmo
-boxes-and-lines Module Dependencies
-tag Layer as l
-  api blue
-  domain green
-  data orange
-...
-```
-<Analysis: the layering, the hotspots, where new code tends to go.>
-
-## Key flows
-<For each important runtime path: a sentence of setup, the sequence, a sentence
-on the tricky part (auth, retries, async handoff).>
-
-```dgmo
-sequence <Flow name>
-...
-```
-
-## Data model        ← only if there's a real schema
-...
-
-## Infrastructure & traffic   ← only if there's real infra
-...
-
-## Notes & gotchas
-<Non-obvious constraints, tech debt, conventions a newcomer must know. Pull these
-from comments, config, and naming you noticed while reading.>
-```
-
-Writing standards:
-- Keep each diagram **focused** — 5–9 nodes reads; 25 nodes is a wall. Split or summarize instead of cramming.
-- Every section: prose → diagram → reading of the diagram. Never a bare fence.
-- Use the codebase's real vocabulary. If the team calls it a "broker," call it a broker.
-- Group with tags to encode meaning (layer, domain, team), not just color.
-
-## Step 5 — Validate every fence (do not skip)
-
-Before saving, validate each DGMO fence:
-- MCP: `mcp__dgmo__validate_diagram(dgmo)` for each block; fix until clean.
-- CLI: write each block to a temp `.dgmo` and run `dgmo <tmp> -o <tmp>.svg`; a non-zero exit means a syntax error — read the diagnostic and fix.
-
-A report that ships broken DGMO fails its primary job. If you could not validate (no tools), say so explicitly in your summary.
-
-## Step 6 — Save and hand off
-
-Write the file (default `docs/architecture-report.md`). Then report to the user:
-
-1. **What was produced** — the path, the section list, how many diagrams and of which types.
-2. **How it's organized** — one line on the narrative arc (context → modules → flows → data).
-3. **How to view it rendered** — open in the Diagrammo app, paste into online.diagrammo.app, or render through a DGMO docs wrapper; raw Markdown shows the source.
-4. **What's next** — which diagram would most benefit from depth, or a flow/section worth adding.
-
-## Quality bar / anti-patterns
-
-- ❌ Generic boxes ("Service", "Module 1") → ✅ real names from the code.
-- ❌ One giant everything-diagram → ✅ several focused, layered views.
-- ❌ Fences with no prose → ✅ each diagram is explained and "read aloud."
-- ❌ Forcing `er`/`infra` with nothing to show → ✅ only diagram what exists.
-- ❌ Inlining rendered PNG/SVG → ✅ DGMO fences (diffable, editable, the point of the format).
-- ❌ Asking the user which diagrams to make → ✅ decide from the code; they can adjust after.

package/.claude/commands/dgmo-diagram-this.md

@@ -1,60 +0,0 @@
-# /dgmo-diagram-this — Generate Diagrams from Code
-
-You are reading the user's code and generating DGMO diagrams that document what it does. Don't ask what kind of diagram — figure it out from the code.
-
-## Prerequisites
-
-Verify DGMO MCP tools are available by calling `mcp__dgmo__list_chart_types`. If not available, tell the user to run `/dgmo` first to set up the MCP server.
-
-## Step 1 — Determine Scope
-
-The user may provide:
-- **A file path** — diagram that specific file
-- **A function/class name** — diagram that specific piece
-- **A directory** — diagram the module/package
-- **Nothing** — look at the current working directory and diagram the overall project structure
-
-If scope is unclear, read the project root (`package.json`, `README.md`, `src/` listing) and pick the most interesting thing to diagram.
-
-## Step 2 — Read the Code
-
-Read the relevant source files. Look for:
-- Function signatures and call chains
-- API endpoints and request handlers
-- Database models, schemas, ORM entities
-- State machines, status enums, workflow transitions
-- Service-to-service calls, message passing
-- Infrastructure config (Docker, k8s, terraform)
-- Import graphs and module dependencies
-
-## Step 3 — Pick the Diagram Type
-
-| What you found | Diagram type |
-|---|---|
-| API handler calling other services/DB | `sequence` |
-| Multiple models with relationships | `er` |
-| Service/module dependency graph | `c4` (container level) |
-| State enum, FSM, workflow transitions | `state` |
-| Decision logic, branching control flow | `flowchart` |
-| Docker/k8s/cloud infra config | `infra` |
-| Class hierarchy with methods | `class` |
-| Team/org structure data | `org` |
-
-If a single file contains multiple diagrammable things (e.g., models AND an API handler), generate multiple diagrams.
-
-## Step 4 — Generate
-
-1. Call `mcp__dgmo__get_language_reference("<type>")` for syntax.
-2. Call `mcp__dgmo__get_examples("<type>")` for idiomatic patterns.
-3. Write the DGMO using **real names from the code** — actual function names, model names, service names, field types.
-4. Call `mcp__dgmo__validate_diagram(dgmo)` — fix any errors.
-5. Call `mcp__dgmo__preview_diagram([{dgmo, title}])` to show the result.
-6. Save to `<descriptive-name>.dgmo` in the project.
-
-## Rules
-
-- **Use real names** — `UserService`, `orders` table, `POST /api/auth/login` — not generic placeholders
-- **Keep it focused** — a sequence diagram with 5-8 messages is better than one with 30. Show the main flow, not every edge case.
-- **Lean on inference** — don't declare `PostgresDB is a database` (the name auto-infers). Only use `is a` when the name doesn't match.
-- **No colons in directives** — `sequence Auth Flow`, not `chart: sequence`
-- **Multiple diagrams are fine** — if the code has both a schema and an API flow, generate both and use `preview_diagram` with multiple entries