erdraft 0.0.0-stage → 0.0.2

package/dist/window/favicon.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="4.5 4.5 52 52"><path fill="#7CD06A" d="M13.72 9.05A1 1 0 0 1 14.62 8.5L45.38 8.5A1 1 0 0 1 46.28 9.95L41.28 19.95A1 1 0 0 1 40.38 20.5L21.31 20.5A0.5 0.5 0 0 0 20.86 20.78L19.36 23.78A0.5 0.5 0 0 0 19.81 24.5L49.38 24.5A1 1 0 0 1 50.28 25.95L45.28 35.95A1 1 0 0 1 44.38 36.5L25.31 36.5A0.5 0.5 0 0 0 24.86 36.78L23.36 39.78A0.5 0.5 0 0 0 23.81 40.5L53.38 40.5A1 1 0 0 1 54.28 41.95L49.28 51.95A1 1 0 0 1 48.38 52.5L17.62 52.5A1 1 0 0 1 16.72 51.05L21.64 41.22A0.5 0.5 0 0 0 21.19 40.5L11.62 40.5A1 1 0 0 1 10.72 39.05L17.64 25.22A0.5 0.5 0 0 0 17.19 24.5L7.62 24.5A1 1 0 0 1 6.72 23.05Z"/></svg>

package/dist/window/index.html

@@ -0,0 +1,23 @@
+<!doctype html>
+<html lang="en">
+  <head>
+    <meta charset="UTF-8" />
+    <meta name="viewport" content="width=device-width, initial-scale=1" />
+    <title>Erdraft</title>
+    <link rel="icon" href="/favicon.ico" sizes="48x48" />
+    <link rel="icon" href="/favicon.svg" type="image/svg+xml" />
+    <link rel="icon" href="/favicon.png" type="image/png" sizes="32x32" />
+    <link rel="apple-touch-icon" href="/apple-touch-icon.png" />
+    <script>
+      // The theme chosen before, or the system's, set before the page is drawn so it never flashes the other
+      const chosen = localStorage.getItem('erdraft-theme')
+      const dark = chosen ? chosen === 'dark' : matchMedia('(prefers-color-scheme: dark)').matches
+      document.documentElement.classList.toggle('dark', dark)
+    </script>
+    <script type="module" crossorigin src="/assets/index-v2x3QhC-.js"></script>
+    <link rel="stylesheet" crossorigin href="/assets/index-BCt7ERad.css">
+  </head>
+  <body>
+    <div id="root"></div>
+  </body>
+</html>

package/package.json

@@ -1,6 +1,100 @@
 {
+  "$schema": "https://json.schemastore.org/package.json",
   "name": "erdraft",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
+  "version": "0.0.2",
+  "description": "A project's data model drafted with an agent while a person watches: drafts proposed through MCP, drawn live beside the schema, one adopted before any code is written",
+  "keywords": [
+    "database",
+    "schema",
+    "data-model",
+    "erd",
+    "drizzle",
+    "postgres",
+    "mcp",
+    "claude-code",
+    "agent"
+  ],
+  "homepage": "https://erdraft.com",
+  "bugs": "https://github.com/erdraft/erdraft/issues",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/erdraft/erdraft.git"
+  },
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "erdraft": "dist/cli.js"
+  },
+  "exports": {
+    "./inspect": {
+      "types": "./dist/types/inspect/inspector.d.ts",
+      "default": "./dist/inspect/index.js"
+    },
+    "./inspect/logger": {
+      "types": "./dist/types/inspect/inspect-logger.d.ts",
+      "default": "./dist/inspect/logger.js"
+    },
+    "./package.json": "./package.json"
+  },
+  "files": [
+    "dist",
+    "skill"
+  ],
+  "engines": {
+    "node": ">=22"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "~1.32.2",
+    "@napi-rs/keyring": "~2.1.2",
+    "tsx": "~4.23.15",
+    "zod": "~4.6.7"
+  },
+  "peerDependencies": {
+    "@ngrok/ngrok": ">=1.7.0",
+    "drizzle-orm": ">=0.44.0",
+    "react": ">=19.2"
+  },
+  "peerDependenciesMeta": {
+    "@ngrok/ngrok": {
+      "optional": true
+    },
+    "react": {
+      "optional": true
+    }
+  },
+  "devDependencies": {
+    "@arcnote/typescript-config": "~0.0.0",
+    "@arcnote/ui": "~0.0.0",
+    "@dagrejs/dagre": "~3.1.3",
+    "@fontsource-variable/inter": "~5.3.0",
+    "@ngrok/ngrok": "~1.7.0",
+    "@tailwindcss/vite": "~4.3.3",
+    "@testing-library/react": "~16.3.3",
+    "@types/node": "~26.6.6",
+    "@types/react": "~19.3.0",
+    "@types/react-dom": "~19.3.0",
+    "@vitejs/plugin-react": "~6.1.2",
+    "@vitest/coverage-v8": "~5.0.5",
+    "@xyflow/react": "12.12.0",
+    "drizzle-orm": "~0.45.4",
+    "happy-dom": "~21.0.4",
+    "react": "~19.3.1",
+    "react-dom": "~19.3.1",
+    "tailwindcss": "~4.3.3",
+    "tsup": "~9.0.0",
+    "typescript": "~7.0.2",
+    "vite": "~8.3.5",
+    "vitest": "~5.0.5"
+  },
+  "scripts": {
+    "erdraft": "tsx bin/erdraft.ts",
+    "dev": "tsx bin/erdraft.ts studio",
+    "bundle": "tsup && vite build && tsc -p tsconfig.build.json",
+    "check-types": "tsc --noEmit",
+    "test": "vitest run",
+    "test:coverage": "vitest run --coverage"
+  }
 }

package/skill/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: erdraft
+description: Design or change the project's database schema with Erdraft, a person watching and adopting in its window before any code is written. Use when asked to design, model or change the data model, tables, columns, relations, keys, indexes or constraints ("add a table for invoices", "model the data for the wiki", "what tables do we need for tags", "desenhar a base de dados", "modelar as tabelas"), and whenever a change to the schema's code is about to be made.
+---
+
+# Erdraft
+
+Erdraft draws the project's data model, read from its schema's code, in a window a person watches (`erdraft studio`, http://localhost:9369 unless `.erdraft.json` says another port). You propose a change as a **draft**, drawn at once beside the schema; the person **adopts** one in the window; only then is it written in the code. Erdraft never changes the code nor the database.
+
+Use the `erdraft` MCP's tools. Where they are not connected, the CLI does the same: `erdraft read`, `tables`, `table <name>`, `propose <file|-> --title <title>`, `revise`, `show`, `wait <id>`, `draft <id>` (`erdraft --help`).
+
+## 1. Read before proposing
+
+- **The project's own conventions for its schema:** the instructions beside the schema module `.erdraft.json` names and above it (`CLAUDE.md`, `AGENTS.md`, a README), and two or three existing tables like the one asked for. Naming, ids, timestamps, how a table is laid out in files, how migrations and seeds are made: the project's, never your habits.
+- **The schema as the code has it:** `list_databases` (the one the person works on), `read_schema` when the code changed, `list_tables`, then `describe_table` on every table the change touches and the tables they join.
+- **What is asked, measured against what is there:** a table that already holds the field, a name already taken, a screen or a feature the data serves.
+
+## 2. Propose the whole design
+
+- **One draft holds the whole change:** its tables and columns (types as Postgres names them, `not null` and defaults as meant), its foreign keys with what happens on delete, and every rule the database can hold as an operation, never as prose in a note: unique indexes (`add_index` with `unique`), indexes for what is joined or filtered, checks (`add_check`, a name and its SQL). A rule the database cannot hold goes in the table's note, said as checked by the code that writes. **A `json` or `jsonb` column always carries its `shape`:** its TypeScript type as the code's `$type<...>()` will write it (`{ accent?: string; tone?: 'light' | 'dark' }`), every field and its optionality, literal unions spelled out, so the person reads its fields in the window, behind the braces on its row. A rule of its values (a format, a range) is not in the shape: it goes in the column's note and, once written, in its zod schema.
+- **Its title says what it does, its summary why and what it trades.**
+- **When there is more than one good answer** (a flag on a row or a table of its own, one table or two), propose two or three drafts in one `group`, each whole, so the person compares them a tab each.
+- **Build a large draft step by step** with `revise_draft` (mode `append`); the window follows each step.
+- **Show it:** `show_in_window` on the draft's main table with `related`, so the person sees it with the tables it joins.
+
+## 3. Wait for the person
+
+Tell the person in one line what the draft is and where to see it, and that they can adopt it there or tell you what to change, then call `wait_for_decision` with the draft's id (the CLI's `erdraft wait <id>`), its time left as it is: short, as your turn is held while you wait, and what the person writes to you is read only between two waits. Never ask them to say they adopted.
+
+- **Adopted:** write it (step 4).
+- **Another of its group adopted:** write that one.
+- **Set aside:** stop, and ask what to change.
+- **Still proposed, and the person wrote to you meanwhile:** answer them first. A change asked for (a column taken away, a type changed) is `revise_draft` on that draft, or a new draft in its group when it is another answer; say what changed, then wait again.
+- **Still proposed, nothing written:** wait again. After about ten minutes in all, say the draft waits in the window, and stop; wait again when they come back.
+
+Never adopt or set aside a draft yourself, and never write a draft that is not adopted.
+
+## 4. Write it in the code
+
+- **By the project's conventions** read in step 1: the schema's code, its migration made by the project's own tool (never written by hand where the tool makes it), its tests for each constraint where the project tests its schema, its seeds and documents where it keeps them.
+- **A json column's shape is written as a zod 4 schema** the schema's module exports by the column's table and name in camelCase, then `Shape` (`websites.theme` is `websitesThemeShape`, `wiki_pages.page_place` is `wikiPagesPagePlaceShape`), the column's type inferred from it (`jsonb('theme').$type<z.infer<typeof websitesThemeShape>>()`) and the code that writes the column parsing with it. Erdraft reads that export to draw the shape once the draft is written; a type alone (`$type<Theme>()`) is gone when the module runs, and the column loses its braces. Where the project keeps its json types elsewhere, the module re-exports the schema under that name.
+- **What the code must do differently from the draft** (a foreign key's `on delete`, a name the tool gives, a type the ORM writes otherwise) is said to the person in your reply, with why. Postgres checks a `RESTRICT` key at once and a `NO ACTION` key at the statement's end: a row reached by two cascades (a project's pages and the collection they are in, both going with the project) needs `NO ACTION`, or the delete can fail by the order the cascades run. A check that is null lets a row through: write each so it is true or false (`coalesce`, `is null`).
+- **The database itself** is never changed beyond what the project's commands do (its migrations, its seeds), and rows a person changed are never written over without asking.
+
+## 5. Check it is written
+
+`read_schema`, then `show_draft` on the draft: it says *Written in the code: the schema holds what it does*, and the window says the same on its card. When it does not, it names the step the code does not hold: write what is missing, or say why it differs. Each json column written shows its shape in `describe_table` (`shape { ... }` on its line): one without is a zod schema missing, or exported under another name.