mockpit 2.0.0 → 3.1.0

package/README.md

@@ -1,263 +1,99 @@
 # mockpit
 
-**A design-decision loop for terminal coding agents.**
+**A design loop for terminal coding agents. Your agent shows designs in your browser and asks
+its questions there. You answer in place and press Send once.**
 
-Your agent publishes a mock (a page or a component) in each of its UI states and
-in a few parallel variants. It shows up live in your browser with the agent's
-questions beside it: pick a variant from pictures, tune the knobs it exposed, leave
-comments on the parts it declared, then press **Send**, at your own pace. Nothing
-the agent calls waits for you: it gets the whole batch once and revises.
+The agent publishes a screen in its states and a few variants, then ends its turn. You compare
+them from pictures, tune knobs, comment on parts and keep the runners-up. One Send gives the
+agent the whole reply. Nothing it calls waits for you.
 
-<table>
-  <tr>
-    <td width="50%" valign="top">
-      <picture>
-        <source media="(prefers-color-scheme: dark)" srcset="docs/mockpit-dark.png">
-        <img width="100%" alt="The Writer mock on its first question, Which variant?: the Writing state on the stage with a numbered question pin, the row of four UI states below it, and the panel offering three variants (Quiet, Dark, Editorial) as picture options" src="docs/mockpit-light.png">
-      </picture>
-    </td>
-    <td width="50%" valign="top">
-      <img width="100%" alt="Animated demo: the agent publishes the Writer mock; the user previews the three variants on the stage, picks Quiet, answers where the trim goes, borrows a part from another variant and presses Send; the top bar reads Sent, Not seen yet, then Delivered once the agent reads the feedback; the agent replies and publishes its next version" src="docs/mockpit-demo.gif">
-    </td>
-  </tr>
-</table>
-
-## Fork of sideshow
-
-mockpit is a fork of [sideshow](https://github.com/modem-dev/sideshow) by
-[Ben Vinegar](https://github.com/benvinegar), sponsored by
-[Modem](https://modem.dev). The renderer, sandboxing, MCP/CLI/HTTP tiers and
-Cloudflare deploy all come from that work. Thank you.
-
-Upstream is a live visual surface where agents post renders and you comment.
-mockpit turns that into a design-decision loop:
-
-|               | sideshow                                           | mockpit                                                                                                                        |
-| ------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| Structure     | A stream of posts per session                      | **project › mock › state › variant › version**: a repo, a page or component by slug, its UI states, parallel variants, history |
-| Questions     | Free-text comments                                 | The agent asks; you answer in place, picking from pictures of each option                                                      |
-| Tuning        | —                                                  | Knobs the agent declares (sliders, colours, springs…) on [tunekit](https://github.com/fabiogaliano/tunekit), live on the stage |
-| Comments      | Text on a post                                     | Anchored on a **part** the agent declared with `data-part`, in a given state                                                   |
-| Feedback      | Each comment reaches the agent as it's written     | Picks, tuned values, borrowed parts and comments stay drafts until you **Send**, then go out as one reply                      |
-| Design system | Built-in viewer themes                             | `mockpit init` detects the repo's tokens, fonts and kit so the agent's markup matches your codebase                            |
-| Agent verbs   | Post-level: `publish`, `update`, `wait`, `comment` | Mock-level, never blocking: `publish`, `ask`, `read`, `feedback`, `say`, `edit`, `export`, `upload`, `guide`, `run`            |
-
-## The loop
+<a href="docs/mockpit-demo.gif"><img width="100%" alt="Animated demo: on HALDE, a shop design with three product grids, the pointer hovers Gallery and Editorial, each previewing on the stage, then picks Gallery" src="docs/mockpit-demo.gif"></a>
 
-1. **Publish.** The agent publishes each state of the mock ("Writing", "Lab
-   open") in one or more variants ("quiet", "dark"). One stage shows the mock,
-   one state at a time.
-2. **Ask.** The agent asks what it can't decide alone: which variant, where a
-   panel goes, which of two layouts. The question lives in the mock, not in
-   chat; the agent tells you where to look and ends its turn. Options bound to
-   a variant or to knob values render as pictures; hovering one previews it on
-   the stage, clicking picks it, and the part it changed is outlined. A
-   region the agent drew several ways (a part with fills: one `data-part`, a
-   `data-fill` per alternative) is asked about once; a part inside a fill is
-   asked only while that fill is chosen. Variants the agent forgot to ask about
-   get a built-in **Which variant?**.
-3. **Tune.** Parts the agent declared are selectable on the stage. Tune lists
-   them with the knobs it declared for each, a **Borrow** line for a part
-   another variant draws differently, plus a comment field. Presets
-   save a set of tuned values in your browser.
-4. **Send.** Everything above is a draft (it survives a reload) until one
-   **Send**. A mock with a single variant and no questions gets **Use this /
-   Revise** instead. The Send lands in the Thread as **Not seen yet**,
-   then **Delivered** once the agent has it. If it isn't picked up, tell your
-   agent you've answered.
-5. **Revise.** The agent gets one reply (answers, tuned values, borrowed parts, comments)
-   on its next write, its next `feedback` call, or from `mockpit watch` under a
-   background monitor. It publishes the next version. Versions are named by
-   their variant's own number ("Dark #2"); the version bar walks the history,
-   and **Use this** puts an older one back in use. Variants that lost are
-   archived, not deleted.
+## Quickstart
 
-**Home** lists the project's mocks with a thumbnail, their states and how many
-questions are open, with "Answer next ›" to jump to the first one. Dark and
-light themes, toggled from the top bar. On a phone or an iPad in portrait the
-design is a canvas you pan and pinch, at each width the agent names (or one you
-pick: Phone 390, Tablet 744, Desktop 820, Wide 1280) side by side, and the
-questions float over it in a card you can snap to a corner, a side or the
-bottom, or tuck against an edge. On a desktop, Inspect opens the stage full
-screen to pan and pinch-zoom it.
-
-## Quick start
-
-Requires Node 22.18 or newer.
+Needs Node 22.18 or newer.
 
 ```sh
-git clone https://github.com/fabiogaliano/mockpit && cd mockpit
-npm install
-npm start                      # viewer on http://localhost:8228
-npm link                       # puts the `mockpit` CLI on your PATH
+npm i -g mockpit
+mockpit serve --open     # http://localhost:8228
+mockpit demo             # seeds a sample design to click through
 ```
 
-Point your agent at it by pasting the setup block into its instructions:
+Point your agent at it, once per repo:
 
 ```sh
 curl -s http://localhost:8228/setup >> AGENTS.md
+mockpit init             # reads the repo's tokens, fonts and kit
 ```
 
-Then run `mockpit init` once per repo and ask the agent to "mock this up on
-mockpit". No agent handy? `mockpit demo` seeds the Writer: one mock in four
-states and three variants, with questions, knobs and declared parts.
-
-MCP, the Pi extension and the Claude Code plugin are covered in
-**[docs/connecting-agents.md](docs/connecting-agents.md)**.
-
-## What a mock can show
-
-A version is an ordered list of **surfaces**, and one version can carry several.
-Html is what design mocks use and the only kind with parts and knobs; the others
-render the same way on the stage.
-
-<table>
-  <tr>
-    <td width="50%" valign="top">
-      <img src="docs/surfaces/01-html.png" width="100%" alt="html surface">
-      <p><b><code>html</code></b>: markup the agent authors, rendered in a sandbox and themed by your design system.</p>
-    </td>
-    <td width="50%" valign="top">
-      <img src="docs/surfaces/02-markdown.png" width="100%" alt="markdown surface">
-      <p><b><code>markdown</code></b>: prose, tables and fenced code.</p>
-    </td>
-  </tr>
-  <tr>
-    <td width="50%" valign="top">
-      <img src="docs/surfaces/03-diff.png" width="100%" alt="diff surface">
-      <p><b><code>diff</code></b>: a patch as a syntax-highlighted code review (unified or split).</p>
-    </td>
-    <td width="50%" valign="top">
-      <img src="docs/surfaces/07-mermaid.png" width="100%" alt="mermaid surface">
-      <p><b><code>mermaid</code></b>: diagram source rendered to SVG in the viewer palette.</p>
-    </td>
-  </tr>
-</table>
-
-There are also `terminal` (ANSI output), `image` (uploaded assets), `json`
-(collapsible tree) and `code` (shiki-highlighted source with line numbers).
-
-## Agent verbs
-
-Ten verbs, the same on every tier with the same fields: a zero-dependency CLI
-for agents with only a shell, MCP over stdio or streamable HTTP at `/mcp`, and
-plain HTTP. None of them waits for the user.
-
-| CLI                   | MCP                  | HTTP                                                |
-| --------------------- | -------------------- | --------------------------------------------------- |
-| `mockpit publish`     | `publish`            | `POST /api/mocks`                                   |
-| `mockpit ask`         | `ask`                | `POST /api/mocks/:id/asks`                          |
-| `mockpit read [slug]` | `read`               | `GET /api/mocks`, `GET /api/mocks/:id`              |
-| `mockpit feedback`    | `feedback`           | `GET /api/feedback?session=…`                       |
-| `mockpit say`         | `say`                | `POST /api/mocks/:id/say`                           |
-| `mockpit edit`        | `edit`               | `PATCH /api/mocks/:id`, `PATCH /api/projects/:name` |
-| `mockpit export`      | `export`             | `GET /api/mocks/:id/export`                         |
-| `mockpit upload`      | `upload`             | `POST /api/assets`                                  |
-| `mockpit guide`       | `guide`              | `GET /agent-howto`                                  |
-| `mockpit run`         | `run` (`?mode=code`) | `POST /api/run`                                     |
+Then ask it to "design this up on mockpit". Claude Code, Codex, OpenCode, Pi and MCP setup:
+[docs/connecting-agents.md](docs/connecting-agents.md).
 
-The CLI adds `mockpit init` (detect the repo's design system, once per repo)
-and `mockpit watch` (one line per Send, for a background monitor).
-
-- **`publish` is the one write.** It creates the mock, state or variant, or the
-  next version of an existing one. Send `html`, the full ordered `surfaces`
-  list (an entry that is only `{id}` keeps that surface), or `parts` to replace
-  just the declared elements.
-- **`feedback` returns at once** with what the user sent since the agent last
-  heard, plus `pending`: whether each mock is open in the viewer and how far the user's
-  draft has got (`2 of 3 answered`). Every write returns `feedback` too, and
-  each Send is delivered exactly once across all of them.
-- **Questions are nudged.** A publish that leaves several variants with no
-  question binding them returns a nudge and a ready `suggestedAsk`.
-
-A typical turn:
+## A turn
 
 ```sh
-mockpit publish --mock writer --state "Writing" --variant quiet --html quiet.html
-mockpit publish --mock writer --state "Writing" --variant dark  --html dark.html
-mockpit ask     --mock writer "Quiet or dark?" --option Quiet=quiet --option Dark=dark
-# the agent says where to look and ends its turn; once you've answered:
+mockpit publish --design shop --state Grid --variant index --html index.html
+mockpit publish --design shop --state Grid --variant gallery --html gallery.html
+mockpit ask --design shop "Which grid?" --option Index=index --option Gallery=gallery
+# the agent says where to look and stops. After your Send:
 mockpit feedback
 ```
 
-The running server serves the brief at `/agent-howto`: one short, project-aware
-document an agent reads before its first publish. Reference topics (`knobs`,
-`asks`, `surfaces`, `html`, `feedback`, `http`, `scripts`) are at
-`/agent-howto?topic=<id>`; `/guide` is the `html` topic. `run` executes one
-script against the same verbs on the server, so publishing variants and asking
-take one call; `/mcp?mode=code` serves it as the only tool, for connectors
-without a codemode of their own.
+## What you can do with an answer
 
-## Guidance
+- **Pick** from pictures. Hover to preview it on the stage.
+- **Keep** runners-up. After Send they stay beside the design, one click from Use this instead.
+- **Hide** what you don't want, with a reason if you like. The agent won't offer it again.
+- **Ask for more** answers without sending the rest of your draft.
+- **Save a set** of answers across questions, like Warm or Quiet, and switch between sets.
+- **Tune** the knobs the agent declared, **borrow** a part from another variant, and
+  **comment** on any part.
 
-Agents read one brief before their first publish, in layers. Higher wins:
+Studio puts every variant side by side. Home groups a project's ideas, screens, flows and
+components, and Needs you lists what's waiting on you.
 
-| Layer         | Where                           | Who gets it                           |
-| ------------- | ------------------------------- | ------------------------------------- |
-| Core          | built in                        | everyone: how mockpit works, no taste |
-| Packs         | built in, off by default        | whoever turns one on (`design-craft`) |
-| Your rules    | `~/.mockpit/rules.md`           | you, in every project                 |
-| Project rules | `.mockpit/rules.md` in the repo | anyone designing that repo            |
+<table>
+  <tr>
+    <td width="50%"><a href="docs/mockpit-question.png"><img src="docs/mockpit-question.png" width="100%" alt="The HALDE shop asking Which grid?, with Index, Gallery and Editorial as picture answers beside the stage"></a></td>
+    <td width="50%"><a href="docs/mockpit-preview.png"><img src="docs/mockpit-preview.png" width="100%" alt="The product page previewing the Bone answer to What colour behind the products? before it is picked"></a></td>
+  </tr>
+</table>
 
-A rules file has `## Rules` (always followed) and `## Suggestions` (aimed for),
-and turns packs on with `packs: [design-craft]` in its frontmatter. `mockpit
-rules` sends the project's file to the server; `mockpit init` does it too.
-[`examples/rules.md`](examples/rules.md) is the maintainer's own, symlinked to
-`~/.mockpit/rules.md`.
+## What it shows
 
-## Run it anywhere
+Html with parts and knobs, plus markdown, diff, terminal, image, mermaid, json and code. All of
+it renders in a sandboxed frame.
 
-It runs locally as a small Node server (SQLite at `~/.mockpit/mockpit.db`), or on
-Cloudflare Workers when your agent and browser are on different machines. See
-**[docs/deploying.md](docs/deploying.md)**.
+## Agent side
 
-The server keeps an event log, one JSON line per agent call, viewer write and
-live-feed connection (ids and shapes, never content), at
-`~/.mockpit/events.jsonl` next to the database. It rolls over at 10 MB. Set
-`MOCKPIT_LOG` to another path, or to `off` to disable it; on Workers it goes to
-Workers Logs. `node scripts/inspect.ts` in a checkout reads it alongside the
-database and Claude Code transcripts.
+Eleven verbs, the same on the zero-dependency CLI, MCP (stdio, or HTTP at `/mcp`) and plain
+HTTP: `publish`, `ask`, `read`, `feedback`, `say`, `move`, `edit`, `export`, `upload`,
+`guide`, `run`. `mockpit watch` wakes a waiting agent on each Send.
 
-The server app is importable from `mockpit/server` (`createApp`, `SqlStore`,
-`createSqliteStorage`). The embeddable viewer engine (`mockpit/viewer-embed`,
-`mountViewer`) is gone: the viewer is self-hosted only.
+Agents read a short brief before their first publish (`/agent-howto`). Add your own taste in
+`~/.mockpit/rules.md`, or per repo in `.mockpit/rules.md`.
+[`examples/rules.md`](examples/rules.md) is one.
 
-## Migrating from 0.x
+## Where it runs
 
-- **SQLite workspaces migrate in place on first boot.** Each item becomes a
-  single-state mock with its variants and version history; comments keep their
-  ids and sequence numbers, so agents' feedback cursors carry over. Comments a
-  user was still drafting become the mock's draft. Deployed Durable Objects
-  migrate the same way.
-- **The JSON store is gone.** If you run with `MOCKPIT_STORE=json`, start your
-  current version once without it **before upgrading**:
-  `env -u MOCKPIT_STORE mockpit serve` (keep `MOCKPIT_DATA`/`MOCKPIT_DB` if you
-  set them). That first SQLite boot copies `~/.mockpit/mockpit.json` into
-  `~/.mockpit/mockpit.db`, as long as the database is still empty; then upgrade.
-  The JSON file is left untouched either way.
-- **`--item` is now `--mock`** (`mockpit publish --mock <slug> --state <s>
---variant <v>`), and the MCP tools are named by verb (`publish`, `ask`,
-  `read`, `feedback`, `say`, `export`, `upload`, `guide`).
-- **Removed:** the item, post, snippet and session-page routes
-  (`/api/projects/:name/items`, `/api/posts`, `/api/surfaces`, `/api/snippets`,
-  `/session/:id`, `/p/:id`), `?part=`, the item/post MCP tools and their
-  deprecated aliases (`publish_item`, `publish_post`, `publish_surface`, …), the
-  CLI's `page`, `list`, `sessions`, `update`, per-kind shortcuts (`markdown`,
-  `diff`, …), `test-post` and `trace*` commands, the github/gruvbox/one themes
-  and the embed engine. Agents should re-fetch `/agent-howto`; refresh pasted
-  setup blocks from `/setup`.
+Locally, a small Node server with SQLite at `~/.mockpit/mockpit.db`. When the agent and browser
+are on different machines, deploy it to Cloudflare Workers: [docs/deploying.md](docs/deploying.md).
 
 ## Development
 
 ```sh
-npm run dev          # server with watch + viewer watch build
-npm run typecheck    # node + workers + viewer
-npm run lint         # oxlint
-npm run format       # oxfmt
+git clone https://github.com/fabiogaliano/mockpit && cd mockpit
+npm install
+npm run dev        # server + viewer watch build
+npm run typecheck && npm run lint && npm run format:check
 ```
 
-The architecture and contributor rules are in [AGENTS.md](AGENTS.md).
+Architecture and rules: [AGENTS.md](AGENTS.md).
+
+## Credits
 
-## License
+A fork of [sideshow](https://github.com/modem-dev/sideshow) by
+[Ben Vinegar](https://github.com/benvinegar), sponsored by [Modem](https://modem.dev). The
+renderer, sandboxing, agent tiers and Cloudflare deploy started there.
 
 [MIT](LICENSE). The original sideshow copyright is retained.

package/bin/demoData.js

@@ -1,4 +1,4 @@
-// Seed content for `mockpit demo`: the Writer mock — four states of one
+// Seed content for `mockpit demo`: the Writer design — four states of one
 // writing app, each drawn in three variants, with its parts marked so the viewer
 // can show questions, tuning and part comments. Dependency-free like the CLI.
 
@@ -103,7 +103,7 @@ export const DEMO = {
     {
       id: "tone",
       text: "Quiet, dark or editorial?",
-      scope: "mock",
+      scope: "design",
       options: [
         { label: "Quiet", variant: "quiet" },
         { label: "Dark", variant: "dark" },

package/bin/initDesign.js

@@ -4,7 +4,7 @@
 //
 // The point of this file is that the agent never assembles a design set by
 // hand: init reads what the repo already declares (Tailwind, shadcn, a `:root`
-// token block, fonts), turns it into the project's DesignSettings, and writes a
+// token block, fonts), turns it into the project's DesignSystem, and writes a
 // starter file the agent copies from. Everything here is deterministic — no
 // model in the loop.
 
@@ -14,17 +14,6 @@ import { readdirSync, readFileSync, statSync } from "node:fs";
 import { homedir } from "node:os";
 import { basename, join, relative } from "node:path";
 
-// The palette mapper lives in server/themes.ts so the server and the CLI can
-// never disagree about what a repo's tokens mean. Node type-strips the .ts in a
-// checkout; the packed CLI has only the compiled tree, hence the fallback.
-async function loadThemes() {
-  try {
-    return await import("../server/themes.ts");
-  } catch {
-    return await import("../dist/server/themes.js");
-  }
-}
-
 // Where repos actually keep their global stylesheet. Ordered by how likely the
 // first hit is to be THE token file, because the first file with the most
 // custom properties wins.
@@ -257,12 +246,11 @@ function hasTailwind(cwd) {
 }
 
 /**
- * Inspect a repo and derive the project's DesignSettings inputs.
+ * Inspect a repo and derive the project's DesignSystem inputs.
  * Never throws on a hostile/odd tree — an undetectable repo returns the
  * builtin kit with no palette, which is a perfectly good starting point.
  */
-export async function detectDesign(cwd) {
-  const { paletteFromCssVars } = await loadThemes();
+export async function detectDesignSystem(cwd) {
   const budget = { left: MAX_FILES };
   const cssFiles = findCssFiles(cwd, budget);
 
@@ -309,7 +297,6 @@ export async function detectDesign(cwd) {
       cssVars: best ? best.count : 0,
       fonts: [...fonts].slice(0, 8),
     },
-    palette: cssVars ? paletteFromCssVars(cssVars) : null,
     cssVars,
     // Where the tokens came from, relative to the repo — `init` prints it so
     // the operator can see which file was imported.
@@ -494,6 +481,7 @@ export function readTokenFiles(files) {
     if (isMap(json)) collectTokens(json, [], undefined, all);
   }
   const values = {};
+  const types = {};
   let count = 0;
   for (const [name, token] of all) {
     let { type, value } = token;
@@ -508,9 +496,12 @@ export function readTokenFiles(files) {
     const text = ref ? `{${ref}}` : tokenText(value);
     if (text === null) continue;
     count++;
-    if (count <= TOKENS_MAX) values[name] = text.slice(0, VALUE_MAX);
+    if (count <= TOKENS_MAX) {
+      values[name] = text.slice(0, VALUE_MAX);
+      types[name] = type;
+    }
   }
-  return count ? { count, values } : null;
+  return count ? { count, values, types } : null;
 }
 
 // tsconfig is JSONC: comments and trailing commas, outside strings.
@@ -613,10 +604,14 @@ export function readDesignFiles(cwd, css = "") {
       cssVars:
         tokens.count === names.length && names.every((n) => declared.has(n.replace(/\./g, "-"))),
       values: tokens.values,
+      types: tokens.types,
     };
     // Tokens are the one unbounded part; shed them until the blob fits.
     while (JSON.stringify(files).length > DESIGN_FILES_MAX && names.length) {
-      for (const n of names.splice(Math.floor(names.length / 2))) delete files.tokens.values[n];
+      for (const n of names.splice(Math.floor(names.length / 2))) {
+        delete files.tokens.values[n];
+        delete files.tokens.types[n];
+      }
     }
   }
   const shadcn = readShadcn(cwd);
@@ -818,13 +813,13 @@ const STARTER_TOKENS = [
  * tokens, and one icon in use. `iconSets` are the prefixes the server resolves
  * for this project.
  */
-export function renderStarter(design, iconSets = ["lucide", "mage"]) {
-  const kit = design?.kit ?? "builtin";
+export function renderStarter(designSystem, iconSets = ["lucide", "mage"]) {
+  const kit = designSystem?.kit ?? "builtin";
   const bodies = { tailwind: TAILWIND_BODY, basecoat: BASECOAT_BODY };
   const body = (bodies[kit] ?? BUILTIN_BODY).replace("ICON_SLOT", '<i icon="lucide:check"></i>');
   // Show the tokens an agent reaches for first. A repo's block is usually led
   // by sizing/easing tokens, so surface the semantic colors ahead of them.
-  const props = customProps(design?.cssVars ?? "");
+  const props = customProps(designSystem?.cssVars ?? "");
   const rank = (name) => {
     const i = STARTER_TOKENS.indexOf(name);
     return i === -1 ? STARTER_TOKENS.length : i;