@marver-design/marver 0.16.1 → 0.17.0

package/docs/live-jam.md

@@ -89,19 +89,31 @@ resolves a thread; you do that after reviewing.
 
 The missing sense that no-shell used to cost - "does my frame actually RENDER?" - is a
 server capability instead, rendered in the machine's own headless Chrome (no bundled
-browser, CDP over Node's built-in WebSocket) and written as a PNG under
+browser; CDP over Chrome's debugging pipe, so the browser lives exactly as long as the
+shot) and written as a PNG under
 `design/.local/shots/`. Two transports reach it, because the no-shell jail rules out the
 obvious one:
 
 - **The file-drop inbox** (works for every agent, including Claude Code, which has no shell
   and whose WebFetch refuses localhost). The agent writes
-  `design/.local/shots/<slug>.request.json` with `{"frame":"<id>","theme":"<t>"}`; the dev
-  server renders and writes `<slug>.result.json` with the PNG path or an error, which the
-  agent Reads.
-- **`npx marver shot <frame> [--scale 1-4]`** / `GET /api/shot?frame=<id>&theme=<t>&scale=<n>`
-  for humans and shell-ful agents - the same renderer, one line. Default 2x; `--scale 4` for a
-  print-quality still (a slide comes back 5120×2880). A frame too tall for the asked scale steps
-  down and says so in `note`; the file name carries the scale actually used (`…@4x.png`).
+  `design/.local/shots/<slug>.request.json` with `{"frame":"<id>","theme":"<t>"}` - or
+  `{"scene":"<name>"}`, `{"frames":[...]}`, `{"all":true}` for a batch; the dev server renders
+  and writes `<slug>.result.json` with the PNG path or an error (a batch: `results`, one entry
+  per frame), which the agent Reads.
+- **`npx marver shot <frame ...> | --scene <name> | --all [--scale 1-4] [--json]`** /
+  `GET /api/shot?frame=<id>&theme=<t>&scale=<n>` / `POST /api/shots {frames|scene|all, theme,
+  scale}` for humans and shell-ful agents - the same renderer, one line. A batch is ONE
+  operation: one headless browser, `MARVER_SHOT_CONCURRENCY` frames at a time inside it
+  (default up to 6, sized to the machine), so a scene costs about what a frame does. Default
+  2x; `--scale 4` for a print-quality still (a slide comes back 5120×2880). A frame too tall
+  for the asked scale steps down and says so in `note`; the file name carries the scale
+  actually used (`…@4x.png`). A frame that ran out of settle budget still ships, marked
+  `unsettled` with a note.
+- **The browser's life.** The headless Chrome exists only while an operation runs - it is
+  driven over Chrome's own debugging pipe, so it dies with the dev server however the server
+  dies (Ctrl-C, a closed terminal, `kill -9`), and none is kept between shots. `MARVER_CHROME`
+  picks the binary; pointing it at a Chrome for Testing or Chromium build makes the shot
+  browser a different app from your own, which some people prefer on macOS.
   The canvas's **copy as image** (`i` / `⇧i`, the images-square toolbar button) is this same
   renderer with `format=png`, so what a designer pastes and what an agent shoots is one picture.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@marver-design/marver",
-  "version": "0.16.1",
+  "version": "0.17.0",
   "description": "The agent-native design canvas. A design/ folder, one command, a canvas of live frames built from your repo's real components - comment @marver and your own coding agent does the work. The tool ships no AI.",
   "type": "module",
   "private": false,

package/templates/AGENTS-embedded.md

@@ -81,7 +81,10 @@ planning. The human should see the request land on the canvas within the first m
    lit frame, never before one.
 3. Build. Independent frames can go in parallel - one subagent per frame, each marking
    its own; frames that depend on one another go in order.
-4. **Clear as you finish**: `npx marver work done <scene/frame ...>` (or `--all`). Marks
+4. **Look before you say done**: `npx marver shot --scene <scene>` (or `<scene/frame ...>`,
+   `--all`) renders the frames headless in one go - one PNG path per line - and you READ
+   the PNGs. No shell? instructions/jam.md has the file-drop way (`{"scene":"..."}`).
+5. **Clear as you finish**: `npx marver work done <scene/frame ...>` (or `--all`). Marks
    self-expire (default 10 min; `--ttl <min>` up to 30) - re-run `start` on long jobs,
    and never lean on expiry instead of `done`.
 

package/templates/AGENTS-studio.md

@@ -81,7 +81,10 @@ planning. The human should see the request land on the canvas within the first m
    lit frame, never before one.
 3. Build. Independent frames can go in parallel - one subagent per frame, each marking
    its own; frames that depend on one another go in order.
-4. **Clear as you finish**: `npx marver work done <scene/frame ...>` (or `--all`). Marks
+4. **Look before you say done**: `npx marver shot --scene <scene>` (or `<scene/frame ...>`,
+   `--all`) renders the frames headless in one go - one PNG path per line - and you READ
+   the PNGs. No shell? instructions/jam.md has the file-drop way (`{"scene":"..."}`).
+5. **Clear as you finish**: `npx marver work done <scene/frame ...>` (or `--all`). Marks
    self-expire (default 10 min; `--ttl <min>` up to 30) - re-run `start` on long jobs,
    and never lean on expiry instead of `done`.
 

package/templates/instructions/jam.md

@@ -98,6 +98,15 @@ file - the dev server renders it and writes the PNG back:
 3. **Read the PNG** at that `path` and check it with your own eyes: content present, both
    themes if you touched theming, nothing clipped. Fix and re-shoot; files overwrite in place.
 
+**Several frames? Ask for them in ONE request** - a whole scene renders in one browser,
+several frames at a time, for about the cost of one shot. Write any `<name>.request.json`
+with `{"scene":"checkout"}`, or `{"frames":["checkout/cart","checkout/summary"]}`, or
+`{"all":true}` (plus `"theme"`, `"scale"` as you like). The result is
+`{"ok":true,"results":[{"frame":"checkout/cart","ok":true,"path":"..."},...]}`, one entry
+per frame in the order asked; a frame that failed carries its own `"ok":false,"error"` and
+the others still ship. A frame that ran out of time to settle (a slow image, a heavy chart)
+comes back with `"unsettled":true` and a `note` - shoot that one alone before you judge it.
+
 The `result.json` is the universal signal - it works even when you cannot see images.
 `"ok":false` means the frame did not render: the `error` carries the reason (a runtime
 throw shows the frame's own exception, "the frame rendered an error - ..."; an unreachable
@@ -108,9 +117,12 @@ shot at its natural width and its FULL height, so a wide layout or a long spec r
 full, not cropped. A frame tall enough to hit the capture cap comes back with
 `"truncated":true` and a `note` - split it or shorten it and re-shoot.
 
-(If you DO have a shell - `npx marver shot <scene/frame> [--theme dark] [--scale 4]` is the
-same thing in one line, printing the PNG path. `--scale 4` is for a print-quality still - the
-human's "copy as image" on the canvas uses this same renderer, so you both see one picture.)
+(If you DO have a shell - `npx marver shot <scene/frame ...>`, `npx marver shot --scene
+<name>` or `--all` (`[--theme dark] [--scale 4] [--json]`) is the same thing in one line,
+printing one PNG path per line; a failed frame goes to stderr and the exit code is 1. After
+writing a scene, shoot the scene, not the frames. `--scale 4` is for a print-quality still -
+the human's "copy as image" on the canvas uses this same renderer, so you both see one
+picture.)
 
 Verification is best-effort, not a gate. If your model cannot read images, or the result
 reports no Chrome on the machine, still act on `ok`/`error` - and say plainly in your reply

package/templates/instructions/shape.md

@@ -183,7 +183,8 @@ of described imagery every time (the full asset rules: instructions/craft.md,
   never set a frame height - the frame auto-heights to fit everything the canvas
   measures. Marver renders images crisp and zooms fast, so fine detail is one zoom away.
 - Judge on the RENDER, not the props: after composing, look at the actual frame
-  (screenshot it if you can) and adjust the per-row count until it reads well. "The code
+  (`npx marver shot --scene <scene>` shoots the whole scene in one go; instructions/jam.md
+  has the shell-less way) and adjust the per-row count until it reads well. "The code
   says they're the same width" proves nothing.
 
 ## When Shape ends

package/dist/shot-By1AItpD.mjs

@@ -1,30 +0,0 @@
-import { n as NAME } from "./cli.mjs";
-import { readDevInfo } from "./work-CLrmY-vQ.mjs";
-//#region src/cli/shot.ts
-/**
-* `marver shot <scene/frame>` - render one frame headless and print the PNG path.
-*
-* The shell-ful agents' door into the same verify loop jam teaches: build, shoot, LOOK.
-* Thin wrapper over the dev server's /api/shot (shot.ts has the capture story).
-*/
-async function shotCommand(root, frame, opts) {
-	if (!frame) throw new Error(`name the frame: ${NAME} shot <scene/frame> [--theme <name>] [--scale 1-4]`);
-	const info = readDevInfo(root);
-	if (!info) throw new Error(`\`${NAME} dev\` is not running in this repo (design/.local/dev.json not found) - start it first.`);
-	const qs = new URLSearchParams({
-		frame,
-		...opts.theme ? { theme: opts.theme } : {},
-		...opts.scale != null ? { scale: String(opts.scale) } : {}
-	});
-	let res;
-	try {
-		res = await fetch(`http://localhost:${info.port}/__mv/api/shot?${qs}`, { headers: { "x-mv-work": info.token } });
-	} catch {
-		throw new Error(`could not reach \`${NAME} dev\` on port ${info.port} - is it still running?`);
-	}
-	const data = await res.json().catch(() => ({}));
-	if (!res.ok || !data.path) throw new Error(data.error ?? `shot failed (${res.status})`);
-	console.log(data.path);
-}
-//#endregion
-export { shotCommand };