mockpit 1.3.0 → 3.0.0

package/opencode/package.json

@@ -0,0 +1,8 @@
+{
+  "name": "mockpit-opencode",
+  "private": true,
+  "type": "module",
+  "exports": {
+    "./server": "./mockpit.js"
+  }
+}

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "mockpit",
-  "version": "1.3.0",
-  "description": "A design-decision loop for terminal coding agents — agents publish mocks with states and variants, ask questions and expose knobs; you answer, tune and comment, then send one reply.",
+  "version": "3.0.0",
+  "description": "A design-decision loop for terminal coding agents — agents publish designs with states and variants, ask questions and expose knobs; you answer, tune and comment, then send one reply.",
   "keywords": [
     "agent-tools",
     "ai-agents",
@@ -35,7 +35,8 @@
     "viewer/dist/",
     "guide/",
     "skills/",
-    "extensions/"
+    "extensions/",
+    "opencode/"
   ],
   "type": "module",
   "exports": {
@@ -64,9 +65,6 @@
     "start": "npm run build:viewer && node server/index.ts",
     "build:viewer": "vite build",
     "mcp": "node mcp/server.ts",
-    "test": "node --test 'test/**/*.test.ts'",
-    "test:worker": "npm run build:viewer && node --test test/workerIntegration.integration.ts",
-    "test:e2e": "playwright test",
     "bench": "node --expose-gc bench/run.ts",
     "bench:all": "node --expose-gc bench/run.ts --all",
     "bench:check": "node --expose-gc bench/run.ts --check",

package/skills/launch-video/SKILL.md

@@ -11,7 +11,7 @@ Maintainer-only: requires a mockpit source checkout (the pipeline lives in
 Generates product videos where every app frame is the real mockpit viewer
 talking to a real server — no screen recording, no mockups. Unlike hunk's
 keyframe-compositing pipeline (`skills/launch-video` in the hunk repo),
-mockpit's product IS live motion — mocks arriving over SSE, sandboxed
+mockpit's product IS live motion — designs arriving over SSE, sandboxed
 iframes resizing, the comment loop — so this pipeline records **one real-time
 pass** instead of compositing stills:
 
@@ -68,7 +68,7 @@ ffmpeg -y -i "$RAW" -vf "fps=30,format=yuv420p" \
   delete it after.
 - **Custom:** any scene set works — tutorials, comparisons, announcements.
   Whatever runs in the viewer can be driven: publish over the API mid-recording
-  and the mock updates on camera; that's the money shot, use it.
+  and the design updates on camera; that's the money shot, use it.
 
 ## Storyboard model (record.mjs + stage.html)
 
@@ -82,16 +82,16 @@ ffmpeg -y -i "$RAW" -vf "fps=30,format=yuv420p" \
 - Card vocabulary: `badge`, `h1` (+ `span.ver` for the amber version),
   `sub`, `cmds`/`cmd` (+ `span.p` for the prompt `$`), `foot`.
 - Interact with the viewer through `page.frameLocator("#app")`. Useful
-  selectors (the same ones `e2e/decide-flow.spec.ts` drives):
-  `.home-step[data-mock="<slug>"]` (Home's screens), `.frame.on` (the frame on
+  selectors:
+  `.home-step[data-design="<slug>"]` (Home's screens), `.frame.on` (the frame on
   stage), `.strip [role="tab"]` (states), `.opt[data-option="<id>"]` (question
   options), `button.send`, `.themebtn` (dark/light).
-- Publish content via the HTTP API while recording: `POST /api/mocks`
-  (`{project, mock, state, variant, html | surfaces, knobs}`; pass the returned
-  `sessionId` as `session` afterwards), `POST /api/mocks/:id/asks`,
-  `POST /api/mocks/:id/revise` to revise (bumps the version live), and
-  `POST /api/comments` (`{session, mock, text}`) for agent replies.
-  Seed background mocks _before_ opening the page; save the live publishes
+- Publish content via the HTTP API while recording: `POST /api/designs`
+  (`{project, design, state, variant, html | surfaces, knobs}`; pass the returned
+  `sessionId` as `session` afterwards), `POST /api/designs/:id/asks`,
+  `POST /api/designs/:id/revise` to revise (bumps the version live), and
+  `POST /api/comments` (`{session, design, text}`) for agent replies.
+  Seed background designs _before_ opening the page; save the live publishes
   for on-camera.
 - Target pacing: money shots hold 2.5–4s after content settles, transitions
   ~1s, typing at `pressSequentially(..., { delay: 34 })`. Intro card ~3s,
@@ -109,7 +109,7 @@ ffmpeg -y -i "$RAW" -vf "fps=30,format=yuv420p" \
   hit-target check runs in the top frame; an overlay that intercepts clicks
   aimed into the app iframe times every action out — even actions "behind" an
   intro card.
-- **Wait for iframes after opening a mock.** Every frame renders from
+- **Wait for iframes after opening a design.** Every frame renders from
   `/s/:id`; cut away too early and the last shot shows an empty stage.
   `waitFor` a `.frame.on iframe` and hold ~2–3s before the outro (this is also
   why "publish on camera" shots need their settle time).
@@ -140,7 +140,7 @@ ffmpeg -y -i "$RAW" -vf "fps=30,format=yuv420p" \
   ("up to 95% lighter" for the 0.13.0 hydrate change, not "95% faster").
 - The window chrome's URL pill shows the real server host:port — decorative
   but it must not lie; `record.mjs` fills it from the actual base URL.
-- Demo content is `bin/demoData.js` (the Writer mock `mockpit demo` seeds) — label
+- Demo content is `bin/demoData.js` (the Writer design `mockpit demo` seeds) — label
   anything invented beyond it honestly, and keep agent names real
   (`claude-code`, `pi`).
 - The video is silent — never imply audio in the video or announcement copy.

package/skills/mockpit/SKILL.md

@@ -1,47 +1,59 @@
 ---
 name: mockpit
-description: Show design and visual work on the user's mockpit surface — UI mocks with states and variants, diagrams, interactive explainers, code reviews — ask structured questions on it, expose knobs to tune, and receive the user's one batched reply. Use when the user asks you to design, illustrate, visualize, sketch, mock up, or review something visually, mentions mockpit, or when a render would explain your work better than text.
+description: Show design and visual work on the user's mockpit surface — UI designs with states and variants, diagrams, interactive explainers, code reviews — ask structured questions on it, expose knobs to tune, and receive the user's one batched reply. Use when the user asks you to design, illustrate, visualize, sketch, design up, or review something visually, mentions mockpit, or when a render would explain your work better than text.
 ---
 
 # mockpit
 
-Read the brief before your first publish. It is short and written for this
-project (its palette, kit and icons): `mockpit guide`.
+Read the brief before your first publish: `mockpit guide`.
 
 Without the CLI: `curl -s ${MOCKPIT_URL:-http://localhost:8228}/agent-howto`.
 Over MCP: `guide`. A connector on `/mcp?mode=code` (stdio:
 `MOCKPIT_MCP_MODE=code`) has one `run` tool instead: write the publishes and
-the ask as one script. From a shell, `mockpit run loop.js` does the same.
+the question as one script. From a shell, `mockpit run loop.js` does the same.
 
 The loop never waits for the user:
 
-1. `mockpit init` once per repo; read the brief (`mockpit guide`).
-2. `mockpit publish --mock <slug> --state "<user's words>" --variant <v> --html f.html`,
-   once per variant; mark parts with `data-part`. Name a state by what the
-   user sees ("Home, idle"), never by your process ("Prototype", "v2"). The html is the UI alone:
-   say what a variant is in `--note`, never in the design, and name the
+1. `mockpit init` once per repo; read the brief (`mockpit guide`). In a new session
+   `mockpit read` first: its decisions are settled unless the user says otherwise.
+2. `mockpit publish --design <slug> --state "<user's words>" --variant <v> --html f.html`,
+   once per variant; declare parts with `data-part`. Name a state by what the
+   user sees ("Home, idle"), never by your process ("Prototype", "v2"); title
+   a design by what it is ("Hold menu"), never "Round 2 · …". The html is the UI alone:
+   say what a variant is in `--description`, never in the design, and name the
    widths it ships at once with `--widths 390,1280`.
-   Build screens from components: each reusable piece is its own
-   `--kind component` mock, embedded in pages with
-   `<mockpit-embed slug="card">`, so one decision on it reaches every page.
-3. A choice is several variants plus one ask that binds them: `mockpit ask`
+   Declare structure only when designing a product's screens: `--kind screen`
+   for a screen, `--flow <name> --step N` for states the user moves between,
+   and each reusable component as its own design embedded with
+   `<mockpit-embed slug="card">` (that makes it a component). Ideas,
+   diagrams and reviews stay plain. `--area <name>` groups Home by the
+   product's areas; `--source <path>` names the code that implements it.
+   `mockpit edit --design <slug>` changes slug, title, kind, area or source
+   without a new version; `mockpit edit --project <p> --area-order
+"Shell,Food"` orders Home's areas. A batch with `edited` is the user moving
+   a design from Home (kind, area): build on it.
+3. A choice is several variants plus one question that binds them: `mockpit ask`
    with options bound to variants. A variant decides everything it differs on;
    don't re-ask it. Visual options carry a `variant` or knob `set`. One render
    plus a control: `--knobs`; declare knobs for what is worth fine-tuning
    even unasked. When a publish result nudges, send its `suggestedAsk`.
-4. Tell the user in one line where to look, then end your turn. The question
-   itself lives in the mock (`ask`), never in chat. The user answers in the
-   browser at their own pace. Never poll.
+4. Tell the user in one line where to look, then end your turn. The question lives in the
+   design (`ask`), never in chat. Never poll.
 5. When the user says they answered (or a `mockpit watch` line wakes you), run
-   `mockpit feedback`. Every write also returns `feedback`; read it. Empty
-   `feedback` with a `pending` draft means they are still answering. A batch
-   with `resolved: true` means they closed the mock unanswered: never re-ask
-   its `dismissed` asks.
+   `mockpit feedback`. Every write also returns `feedback`; read it. Empty `feedback` with a
+   `pending` draft means they are still answering.
 6. `mockpit publish` the revision (`--parts name=file` for one part);
-   `mockpit export` once a variant is accepted.
+   `mockpit export` once a variant is in use.
 
-In Claude Code, arm `mockpit watch` under Monitor after asking, then end the
-turn, so Send wakes you. Elsewhere the user's next message is the wake-up.
+In Claude Code, arm `mockpit watch` under Monitor after asking, then end the turn:
+`Monitor({ command: "mockpit watch", description: "mockpit replies", timeout_ms: 1800000 })`.
+A monitor expires (30 minutes at most) with one notice: re-arm it while you still expect a
+reply, without telling the user. Arm one per conversation, and never run `mockpit watch` in the
+foreground; it never returns. With the mockpit plugin, skip all this: your first mockpit call
+starts its wait, which wakes you and restarts by itself.
+
+With no such tool, the viewer shows the user a line to paste when no watcher is open; treat it
+as them saying they answered.
 
 Reference topics, fetched only when needed with `mockpit guide --topic <id>`:
 knobs, asks, surfaces, html, feedback, http, scripts.