@marver-design/marver 0.16.1 → 0.18.0

package/CHANGELOG.md

@@ -2,6 +2,99 @@
 
 Notable changes to `@marver-design/marver`. Format follows [Keep a Changelog](https://keepachangelog.com); versions follow semver.
 
+## 0.18.0 - 2026-09-07
+
+### Changed
+
+- **Hi-fi frames at rest sleep in place.** A frame on the canvas is one live document, awake
+  or asleep - the DOM-snapshot "lean" cover of earlier releases is gone. At rest, its CSS
+  animations pause and every `backdrop-filter` element (the glass that made a 4-frame hi-fi
+  board checkerboard at 20-70 % zoom) wears a static texture of its own filtered backdrop,
+  computed and certified pixel by pixel by the dev server in headless Chrome, under
+  `backdrop-filter: none` and a static `filter` (the containing block stays, the compositor
+  layer goes: a sleeping frame is one layer to raster, not thirty). Interact mode wakes the
+  frame by removing one `<style>`; laser, comment pins and selection work on the sleeping
+  document as it is. Nothing is copied, so nothing can shift at the transition: measured on
+  real frames in a window at 200 % zoom, 29 pixels of 5.2 million differ from the live paint
+  by more than 8 levels, none by more than 32. During a pan or a zoom the presented frames
+  stay whole where the live board leaves the frame body blank. The one residual: at a zoom
+  that puts a glass element on fractional device pixels, Chrome resamples the live effect
+  layer and paints the sleeping element at its true position, so its edge rows can differ by
+  up to 32 levels at the wake.
+  Markdown, image, slide and lo-fi frames have nothing to compile and never ask the server.
+- Theme flips and resizes wake the frame first and sleep it again once it has settled at the
+  new theme or size; an edit (HMR) or a reload does the same under a new source generation, so
+  a texture can never outlive the source it describes.
+
+- **Boards open in seconds, not minutes.** A board of 128 lo-fi frames went from 77-95 s to
+  under 8 s to fully ready, and its first frames show within the first second. Three causes,
+  three fixes: every frame evaluated the WHOLE prebundled icon package its scene imported one
+  icon from (`@phosphor-icons/react`: 3000 icons, 6.5 MB of JavaScript, ~400 ms per frame,
+  the entire boot of a lo-fi frame) - the dev server now unrolls icon barrel imports in design
+  sources to the per-icon modules the installed package's own barrel names (phosphor, lucide),
+  one line for one line;
+  all frames booted at once on one main thread and finished together, so nothing showed until
+  the last was done - frames are now admitted a few at a time, nearest the centre of the view
+  first; and the 10 s ready watchdog fired on every frame of a big board and renavigated it, so
+  every frame loaded twice - it now counts from admission. A frame reports ready when React
+  has committed, not when it was asked to render.
+
+### Added
+
+- **Published canvases rest under the same certified glass.** `marver build` compiles every
+  published node's textures, in every theme, against the site it just built, and ships them with
+  it (`__mv/bakes/`); the static shell reads one index. A shared hi-fi board now pans and zooms
+  like the dev canvas (measured: 36-59 flat blocks per presented frame at worst, from 1139-1417).
+  Needs Chrome on the build machine; without one the build ships without textures and says so.
+  `--no-textures` / `MARVER_NO_TEXTURES=1` skip the compile.
+- **Published glass was flat.** The CSS transform of a build kept only `-webkit-backdrop-filter`
+  on a rule that declared both, and Chromium then computed `backdrop-filter: none`: the sidebar
+  and header of every published hi-fi frame lost their blur. The build now puts the standard
+  declaration back beside the prefixed one.
+- **Chrome in a build container.** A root build on Linux (a Dockerfile, Railway) gets
+  `--no-sandbox` and `--disable-dev-shm-usage` from marver itself; `MARVER_CHROME` still names
+  a browser marver does not find. The publish guides carry a Dockerfile with Chromium.
+- **Published HTML frames never reported ready.** The build shipped the frame bridge without the
+  module it imports, so in a published canvas an HTML frame stayed "still loading" and neither
+  slept nor took laser or comments. Both files ship now.
+- `POST /__mv/api/bakes` (owner-gated) compiles frames in batch; textures are cached on disk
+  under `design/.local/bakes/<generation>/` and served immutable. Identical asks share one
+  compile; a compile the source outran is dropped; two dev servers on one project keep their
+  own generations.
+
+### Caveats
+
+- Only the dev canvas compiles (it needs Chrome): published canvases sleep with the animation
+  pause alone, their glass live as before.
+- Glass inside glass, a glass element with a blend mode, and any frame whose paint at rest is
+  not a function of its URL (random data at boot, a clock) stay live - the compiler refuses
+  what it cannot certify, and `?awake=1` on the canvas URL keeps every frame live for comparison.
+
+## 0.17.0 - 2026-09-04
+
+### Added
+
+- **Shots in batch.** `npx marver shot a b c`, `--scene <name>` or `--all` render many
+  frames as ONE operation: one headless browser, several frames at a time inside it
+  (`MARVER_SHOT_CONCURRENCY`, default up to 6 sized to the machine). `POST /api/shots`
+  and the jam inbox (`{"scene":...}`, `{"frames":[...]}`, `{"all":true}`) take the same
+  ask; every frame answers for itself (`results[]`, in the order asked). Measured on a
+  31-frame canvas: 65 s of one-at-a-time calls becomes 8 s; a 5-frame scene, 10 s
+  becomes 2 s; a single shot, 2.1 s becomes 1.05 s.
+- A capture that ran out of settle budget says so: `unsettled: true` and a note, instead
+  of a silently half-drawn PNG.
+
+### Fixed
+
+- **A shot's Chrome could outlive the server** - Ctrl-C, a closed terminal or `kill -9`
+  mid-shot left a headless copy of the user's own Chrome running for ever, and on macOS
+  such a ghost can swallow every link the machine opens. The browser is now driven over
+  Chrome's debugging pipe, so it dies with the server however the server dies, and none
+  exists between shots. The first `marver dev` after upgrading kills the ghosts and
+  removes the profiles earlier versions left in the temp dir.
+- Chrome starts and opens tabs several times faster: a stale `--disable-gpu` flag was
+  costing ~0.5 s per start and per tab.
+
 ## 0.16.1 - 2026-09-03
 
 ### Added

package/README.md

@@ -45,6 +45,7 @@ Frames appear on the canvas the moment the files land. That's the loop.
 - **Prototype links.** `data-goto="scene/frame"` on any element links frames into a walkable prototype - across boards, too.
 - **Five ways to view a board.** The canvas (frames on a plane), the board (the same, tidy), **present** (`p`: a full-screen clickable walkthrough - `data-goto` navigates, arrows step, `[` / `]` cycle variants, laser, comments, theme and device pickers in the toolbar), **focus** (one frame as a document - the reading preset for specs), and **slides** (a deck). A published board names its landing view; a frame deep link opens straight into it.
 - **Content frames.** Specs, Mermaid diagrams, mood boards, and slides live on the same canvas as the screens - import `Doc`, `Md`, `Diagram`, `Img`, `Slide`, `Chart`, `Video` from `@marver-design/marver/content` and think a feature through before any pixels exist. Works in a repo with no app at all: idea first, design second.
+- **Hi-fi at rest.** A frame at rest is its own live document, asleep: animations paused and every `backdrop-filter` element painted with a certified texture of its filtered backdrop (compiled by the dev server's headless Chrome), so a board of 30 glass screens pans like 30 statics and wakes pixel-identical on interact. Glass inside glass, blend modes and frames whose paint depends on random data or the clock stay live; `?awake=1` keeps every frame live for comparison.
 - **Charts and video in any frame.** `Chart` (Apache ECharts, SVG, still at rest) inherits the ink, typeface and accent of whatever frame it sits in - a Tailwind dashboard, a dark spec, a slide - sizes its type to the context and follows the layout on resize. `Video` is poster-first everywhere: click to play wherever the frame is live, `autoplay` for an ambient loop, `ratio` for vertical clips; omit the poster and marver renders one from the clip. A screen with a chart or a clip is still a screen.
 - **Copy as image.** Select a frame, press `i` - a 2x PNG of it lands on the clipboard, rendered by the same headless Chrome that serves `marver shot`; `⇧i` for 4x (a slide is 5120×2880). Paste into Slack, a doc, or a chat with your agent.
 
@@ -84,7 +85,7 @@ The trust boundary is hard: only comments written on the owner's machine trigger
 
 ## Working state
 
-The same glow, driven from the terminal. When your agent takes a request, it creates the frame files first, pins them on a board, and runs `npx marver work start <scene/frame ...>` - you see the work land on the canvas in seconds, watch it shimmer while subagents build in parallel, and see it settle on `work done`. Marks self-expire, so a crashed agent never leaves a frame glowing. And `npx marver shot <scene/frame> [--scale 4]` renders one frame headless to a PNG, so the agent can look at what it built before it says it is done - the same picture you get from the canvas's copy-as-image.
+The same glow, driven from the terminal. When your agent takes a request, it creates the frame files first, pins them on a board, and runs `npx marver work start <scene/frame ...>` - you see the work land on the canvas in seconds, watch it shimmer while subagents build in parallel, and see it settle on `work done`. Marks self-expire, so a crashed agent never leaves a frame glowing. And `npx marver shot --scene <scene>` (or `<scene/frame ...>`, `--all`; `[--scale 4]`) renders frames headless to PNGs - a whole scene in one browser, several frames at a time - so the agent can look at what it built before it says it is done - the same picture you get from the canvas's copy-as-image.
 
 ## Commands
 
@@ -97,7 +98,7 @@ The same glow, driven from the terminal. When your agent takes a request, it cre
 | `npx marver share …` | The roster (owner): `add <who> [--role]` · `remove` · `block` / `unblock` · `general <mode>` · `list` · `requests` · `explain <who>` · `who` |
 | `npx marver comments …` | The agent's queue: `connect <url>` · `sync` · `list` · `reply` · `resolve` · `invite <email>` · `revoke <email>` |
 | `npx marver work …` | Working glow from the terminal: `start <scene/frame …>` · `done … \| --all` · `list` |
-| `npx marver shot <frame> [--scale 1-4]` | Render one frame headless and print the PNG path (needs `dev` running); 2x by default |
+| `npx marver shot <frame ...> \| --scene <name> \| --all [--scale 1-4] [--json]` | Render frames headless and print the PNG paths (needs `dev` running); a scene is one browser, several frames at a time; 2x by default |
 | `npx marver boards [--json]` | The sidebar as the files say it is: folders, boards in reading order with their title, `order` and description, the landing board |
 
 ## Shortcuts