@diagrammo/dgmo 0.60.0 → 0.62.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@diagrammo/dgmo",
-  "version": "0.60.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

package/.claude/commands/dgmo-document-project.md

@@ -1,128 +0,0 @@
-# /dgmo-document-project — Generate Diagrams for a Codebase
-
-You are generating a suite of DGMO diagrams that document the user's project. Your goal is to read the codebase, understand its architecture, and produce 3–6 diagrams that capture how the system works.
-
-## Prerequisites
-
-Before starting, verify that the DGMO MCP tools are available by calling `mcp__dgmo__list_chart_types`. If the tools are not available, tell the user to run `/dgmo` first to set up the MCP server, then come back to this command.
-
-## Step 1 — Understand the Project
-
-Read these files (skip any that don't exist):
-
-1. **README.md** or **README** — project purpose and overview
-2. **package.json** / **Cargo.toml** / **go.mod** / **pyproject.toml** / **requirements.txt** — tech stack and dependencies
-3. **docker-compose.yml** / **Dockerfile** / **k8s/** / **terraform/** — infrastructure
-4. **src/** or **app/** directory listing — code structure
-5. **.env.example** or config files — external services and integrations
-
-From this, determine:
-- What the project does (one sentence)
-- The tech stack (language, framework, database, message broker, etc.)
-- Key modules or services
-- External dependencies and integrations
-- Data models (if database-backed)
-
-## Step 2 — Decide Which Diagrams to Generate
-
-Pick 3–6 diagrams based on what the project actually has. Don't force a diagram type that doesn't fit. Use this decision matrix:
-
-| Signal in codebase | Diagram type | What to show |
-|---|---|---|
-| Multiple services, APIs, or modules | **c4** (context or container) | System components and their relationships |
-| REST/GraphQL endpoints, API handlers | **sequence** | 1–2 key request flows (e.g., auth, main business operation) |
-| Database models, ORM entities, schema files | **er** | Entity relationships and key fields |
-| Docker, k8s, cloud infra, load balancers | **infra** | Traffic flow and infrastructure components |
-| State machines, workflow engines, status fields | **state** | Key state transitions |
-| Multiple packages or layers | **flowchart** | Request lifecycle or data flow |
-| Microservices with message queues | **sequence** | Async event flow between services |
-
-**Rules:**
-- Always include a C4 context or container diagram — every project benefits from a high-level view
-- Prefer sequence diagrams for showing **behavior** (how things interact at runtime)
-- Prefer ER diagrams only if there's a real database schema to document
-- Don't generate infra diagrams for projects without infrastructure config
-- Don't generate more than 2 sequence diagrams — pick the most important flows
-
-## Step 3 — Get Syntax Help
-
-For each diagram type you'll generate, call:
-
-```
-mcp__dgmo__get_language_reference("<type>")
-```
-
-Also call `mcp__dgmo__get_examples("<type>")` to see real examples of that chart type. Use these as patterns — they show idiomatic DGMO style.
-
-## Step 4 — Generate the Diagrams
-
-Write the DGMO markup for each diagram. Follow these rules:
-
-- **Keep diagrams focused** — a C4 diagram with 5–8 components is better than one with 20
-- **Use real names from the codebase** — actual service names, model names, endpoint paths
-- **Lean on inference** — don't declare participant types unless the name doesn't match (e.g., `User` auto-infers as actor, `PostgresDB` as database)
-- **Add tags for color coding** when there are natural groupings (teams, domains, layers)
-- **Title every diagram** — the title goes on the first line after the chart type
-
-### Syntax reminders (no colons in directives or data):
-```
-sequence Auth Flow          // first line: type + title
-tag Layer as l              // tag declaration (use `as`)
-  Frontend blue             // color is trailing token (no parens)
-  Backend green
-
-User -POST /login-> API     // sync arrow
-API ~publish~> Queue        // async arrow
-note Validates JWT          // note (no colon)
-```
-
-## Step 5 — Validate Before Rendering
-
-For each diagram, call `mcp__dgmo__validate_diagram(dgmo)` to check for errors. Fix any issues before proceeding.
-
-## Step 6 — Generate the Report
-
-Once all diagrams validate, bundle them into a report:
-
-```
-mcp__dgmo__generate_report({
-  title: "<Project Name> — Architecture Diagrams",
-  subtitle: "Auto-generated from codebase analysis",
-  sections: [
-    { title: "System Context (C4)", description: "High-level view of ...", dgmo: "..." },
-    { title: "Auth Flow", description: "How authentication works", dgmo: "..." },
-    ...
-  ],
-  theme: "dark",
-  palette: "slate",
-  include_source: true,
-  open: true
-})
-```
-
-## Step 7 — Save Source Files
-
-Write each diagram to a `diagrams/` directory in the project root:
-
-- `diagrams/c4-context.dgmo`
-- `diagrams/sequence-auth.dgmo`
-- `diagrams/er-schema.dgmo`
-- etc.
-
-Use descriptive filenames. Create the `diagrams/` directory if it doesn't exist.
-
-## Step 8 — Report to the User
-
-Summarize what was generated:
-
-1. List each diagram with a one-line description
-2. Mention the HTML report was opened in the browser
-3. Note the saved `.dgmo` files in `diagrams/`
-4. Suggest which diagrams might be worth expanding or adding next
-
-## Important Notes
-
-- This skill works with **any** project — not just TypeScript or JavaScript
-- Don't ask the user what diagrams to generate — make the decision based on what you find in the code. They can request changes after.
-- If the project is very small (single file, script), generate just 1–2 diagrams instead of forcing 6
-- If you can't determine the project structure, ask the user to point you at the main source directory