@marver-design/marver 0.21.0 → 0.22.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (45) hide show
  1. package/CHANGELOG.md +134 -15
  2. package/README.md +17 -4
  3. package/dist/{bake-BID6mo-N.mjs → bake-CvY8QR3L.mjs} +1 -1
  4. package/dist/board-status-CWGHIdo_.mjs +1307 -0
  5. package/dist/boards-BwKI0qWd.mjs +188 -0
  6. package/dist/{build-C7MqQ7hq.mjs → build-B1kavcpc.mjs} +74 -13
  7. package/dist/cli.mjs +69 -9
  8. package/dist/config-DJxMRVD8.mjs +373 -0
  9. package/dist/context-D4t59wDi.mjs +600 -0
  10. package/dist/{daemon-CRZFpl6K.mjs → daemon-PmNqoOAk.mjs} +1 -1
  11. package/dist/{dev-BNZF4Mup.mjs → dev-Cf4wLGe2.mjs} +15 -7
  12. package/dist/{init-C34BY3R4.mjs → init-C_K-cjBQ.mjs} +41 -45
  13. package/dist/managed-write-Bo-oPc-i.mjs +71 -0
  14. package/dist/{manifest-mMfUhPtL.mjs → manifest-CcdWx7ud.mjs} +42 -376
  15. package/dist/{plugin-omHLCn91.mjs → plugin-C5u07Yhv.mjs} +234 -105
  16. package/dist/{poster-BvxiAzy1.mjs → poster-BduzQBYz.mjs} +1 -1
  17. package/dist/{publish-bakes-BqzAAa3w.mjs → publish-bakes-b0jUwvM_.mjs} +2 -2
  18. package/dist/{shot-DswS4iRK.mjs → shot-BAR8hmU9.mjs} +2 -2
  19. package/docs/boards-and-folders.md +161 -0
  20. package/docs/context.md +117 -0
  21. package/docs/sharing.md +12 -2
  22. package/package.json +1 -1
  23. package/src/client/shell/BoardList.tsx +33 -3
  24. package/src/client/shell/ContextMenu.tsx +16 -5
  25. package/src/client/shell/StatusPicker.tsx +91 -0
  26. package/src/client/shell/board-icons.tsx +75 -0
  27. package/src/client/shell/store.ts +88 -9
  28. package/src/client/shell/styles.css +34 -3
  29. package/src/shared/board-tree.ts +30 -13
  30. package/src/shared/board-types.ts +103 -0
  31. package/src/shared/context.ts +265 -0
  32. package/src/shared/status.ts +157 -0
  33. package/templates/AGENTS-embedded.md +12 -0
  34. package/templates/AGENTS-studio.md +12 -0
  35. package/templates/context/INDEX.md +50 -0
  36. package/templates/context/map.json +6 -0
  37. package/templates/context/shipped-knowledge.md +19 -0
  38. package/templates/context/shipped.md +28 -0
  39. package/templates/instructions/boards.md +33 -0
  40. package/templates/instructions/context.md +123 -0
  41. package/templates/playbooks/publish-canvas/PLAYBOOK.md +72 -0
  42. package/templates/playbooks/reorganize-context/PLAYBOOK.md +232 -0
  43. package/templates/playbooks/reorganize-context/eval.md +93 -0
  44. package/dist/boards-BwiDAmPf.mjs +0 -337
  45. package/dist/boards-DnLewfj8.mjs +0 -71
package/CHANGELOG.md CHANGED
@@ -2,29 +2,148 @@
2
2
 
3
3
  Notable changes to `@marver-design/marver`. Format follows [Keep a Changelog](https://keepachangelog.com); versions follow semver.
4
4
 
5
+ ## 0.22.1 - 2026-10-06
6
+
7
+ ### Changed
8
+
9
+ - **A project without `context/` hears about it.** The AGENTS contract opens with it: in a
10
+ repository with no `context/`, every reply in which an agent made, specced or changed a feature or
11
+ project board ends with one line - every feature board reads Backlog, nothing records what shipped,
12
+ want me to set it up? - until the human answers; a no stands for the session, and nothing is set up
13
+ unasked. `instructions/boards.md`, `npx marver boards`, `npx marver boards new` (feature, project),
14
+ `npx marver init` and `marver dev` at boot point at it. In 0.22.0 a routing row merely pointed at
15
+ the instruction: Claude Code and Codex, asked to spec a feature, both read it and never mentioned
16
+ it; with the line, both end their reply with it.
17
+ - `npx marver init` on an existing canvas no longer ends with the first-session hand-off - an
18
+ upgrade is not a first session.
19
+
20
+ ### Docs
21
+
22
+ - **"Set up our context" is the whole ask.** `instructions/context.md`'s setup is now the full recipe,
23
+ in order: the kind (`product` or `knowledge`), the draft from evidence, the canvas reading it -
24
+ typed folders, feature boards named after their capability, a start board - and the check in ci.
25
+ After upgrading (`npx marver init`), tell your agent: "Set up our context."
26
+
27
+ ## 0.22.0 - 2026-10-06
28
+
29
+ ### Added
30
+
31
+ - **Context.** `npx marver context init` gives a repository `context/`: an index any agent reads first,
32
+ `shipped.md` - the only place availability is written, every claim `confirmed`, `reported` or
33
+ `unknown` with a citation - one current contract per capability, a map of which code each capability
34
+ lives in, a feedback inbox, and two playbooks Marver maintains (`reorganize-context`,
35
+ `publish-canvas`). The root `AGENTS.md` gets one line routing every agent to the index.
36
+ - **`npx marver context check`** keeps it true, in ci or by hand: no availability or status line in a
37
+ contract, no "section 20 wins", a level and a citation on every evidence cell, links and `path:line`
38
+ citations that resolve, the index under 800 words and equal to the map, `restricted` files out of
39
+ git and `team` files off published boards, feedback closed only on a confirmed deploy, no
40
+ `"status": "done"` on a board - and on a pull request, a contract change with every change to a
41
+ contracted capability's code, or `no-contract-change: <capability> - <why>` in the body. Exit 0
42
+ pass, 1 fail, 2 cannot determine. `npx marver context index` regenerates the index's table.
43
+ - **Board types.** Every board wears an icon for what it is for - `start`, `feature`, `surface`,
44
+ `project`, `feedback`, `context`, `deck`, `archive` - stated on the board or inherited from its
45
+ folder (`"type"` on a folder's entry in `_folders.json`), then the folder's parent.
46
+ - **Status, read from evidence.** Feature and project boards wear a status in the sidebar - Backlog,
47
+ To do, In progress (filling by phase: spec, lo-fi, hi-fi), Done, Done reported, Unknown - read from
48
+ `context/`, or decided on the board: archived, paused, blocked with a reason. Done is never set by
49
+ hand. The tooltip says what decided it; a change to the files reaches the sidebar without a reload.
50
+ An open status is an outline in its colour; a settled one is filled - Done green, Archived a box.
51
+ Right-click a feature or project board, **Change status…**: a Linear-style picker that offers only
52
+ what a person decides - Blocked (it asks why), Paused, Archived, Back to the evidence - and shows
53
+ what the evidence says; never Done.
54
+ `npx marver boards` and the manifest carry types and statuses too.
55
+ - **Starting points.** `npx marver init --kind product|knowledge` gives a fresh canvas the typed
56
+ folders every canvas shares: Start here, Features and Surfaces or Projects, Feedback, Context,
57
+ Archive. `npx marver folders add <module>` adds one later. `npx marver boards new <name>` makes a
58
+ board in its type's starting layout - a feature's spec, lo-fi and hi-fi bands, a start board
59
+ rendering `context/INDEX.md` and `context/shipped.md`, a deck on its title slide.
60
+ - **`"showStatus": true`** on a `publish.json` row shows a board's status on the published canvas -
61
+ only Backlog to Done, only when the evidence behind it is publishable (`audience: publishable` under
62
+ `context/`; a scene brief's phase counts unless the brief says otherwise - it ships with its board),
63
+ never a blocked reason or the evidence itself, with the date it was read.
64
+ - **Knowledge work.** `npx marver context init --kind knowledge` keeps a delivered record - Project
65
+ and Delivered columns - and project boards read Done from it. A repository without a canvas gets
66
+ the conventions as `context/README.md`.
67
+
68
+ ### Changed
69
+
70
+ - **A published board never carries its `status`, `reason` or `capability`,** and the build fails if
71
+ one would - or if a published status or meta carries anything beyond what is allowed. A board's type
72
+ suggests how it publishes (a deck as `slides`, a context board as `refs`, a project as `doc`) as a
73
+ note in the build; a publish row keeps presenting the way it always has until it names a `type`.
74
+ - **A fresh `npx marver init` creates typed folders** - product ones when an app is detected,
75
+ knowledge ones otherwise, said out loud. On a canvas that already has boards or folders, init adds
76
+ them only with `--kind`, and never renames or moves one.
77
+ - The board autosave keeps `type`, `capability`, `status` and `reason` from disk like `title` and
78
+ `description`, and a folder drag keeps a folder's `type`.
79
+
80
+ ### Fixed
81
+
82
+ - **Nested sidebar rows line up.** A board or sub-folder's icon now starts exactly where its folder's
83
+ name starts, at both levels, with one icon-to-name gap throughout - 0.21.0's indent left a folder's
84
+ boards 2px short of that line and a sub-folder's boards 6px past it. Drop seams follow the rows.
85
+ - **Renaming the open board after an agent edited it works.** The rename retried with the canvas's
86
+ old copy of the file and failed again; it now reloads the board and retries once - and only when
87
+ nothing was edited, dragged or switched while the request was out, so a reload never lands over
88
+ your own change.
89
+
90
+ ### Docs
91
+
92
+ - A new guide, [docs/context.md](docs/context.md): the files, the evidence levels, the check and its
93
+ ci step, statuses on the canvas, audiences. [Boards and folders](docs/boards-and-folders.md) gains
94
+ types, status and starting points; [Sharing](docs/sharing.md) documents `showStatus` and the
95
+ proposed publish type; the README links it all.
96
+ - A new managed instruction, `instructions/context.md`, routed from the AGENTS contract: what to read
97
+ at session start, when a contract changes, the setup interview when there is no `context/`.
98
+ `instructions/boards.md` teaches types, status and the new commands.
99
+
100
+ ### Upgrading
101
+
102
+ - Run `npx marver init` to take the new instructions (unedited files update in place; edited ones are
103
+ staged in `design/.local/latest/`). Existing canvases keep their sidebar; `--kind` adds the typed
104
+ folders when you want them.
105
+ - A board that says `"status": "done"` now fails `marver context check` - remove it; Done comes from
106
+ `context/shipped.md`.
107
+ - Folder registry writes now take a short lock, `design/boards/.folders.lock`, so the sidebar, `folders
108
+ add` and `init --kind` never overwrite one another; `npx marver init` adds it to `design/.gitignore`.
109
+
5
110
  ## 0.21.0 - 2026-10-05
6
111
 
7
112
  ### Added
8
113
 
9
114
  - **Folders in folders.** A folder can now hold folders, one level down, so the sidebar has two
10
- levels: a board sits at the root, in a folder, or in a sub-folder. Every folder move works at
11
- both levels, from the sidebar and from the files: **New folder inside** on a top-level folder's
12
- menu, **Move to top level** for a sub-folder, boards dragged into a sub-folder or between its
13
- boards, a folder without sub-folders dragged into a top-level folder. Deleting a folder moves
14
- what it held up one level, into its place - never a board lost. **Move to new folder** now
15
- makes the folder at the board's own level: a sub-folder when the board sits in a folder.
16
- - The files carry it with one new field: a sub-folder's entry in `design/boards/_folders.json`
17
- names its `"parent"`. A board's `folder` stays the one folder it sits in directly. `npx marver
18
- boards` prints the nested tree, the manifest lists each folder's `parent`, and a published
19
- canvas keeps the nesting of its published boards (a folder with nothing published at any depth
20
- stays out of the bundle). `instructions/boards.md` teaches agents the moves.
115
+ levels: a board sits at the root, in a folder, or in a sub-folder. Every folder move works at both
116
+ levels, from the sidebar and from the files - **New folder inside** on a top-level folder's menu,
117
+ **Move to top level** on a sub-folder, a board dragged onto a sub-folder or between its boards, a
118
+ folder with no sub-folders dragged into a top-level folder. At the bottom of a folder, where one
119
+ gap belongs to several levels, the seam is indented with the level a release lands in and the
120
+ pointer's indent picks it. Deleting a folder moves what it held up one level, into its place -
121
+ never a board lost.
122
+ - **One new field carries it.** A sub-folder's entry in `design/boards/_folders.json` names its
123
+ `"parent"`; a board's `folder` stays the one folder it sits in directly, and a sub-folder keeps its
124
+ title and agent-facing description like any folder. `npx marver boards` prints the nested tree, the
125
+ manifest lists each folder's `parent`, and a published canvas keeps the nesting of its published
126
+ boards - a folder with nothing published at any depth stays out of the bundle.
127
+
128
+ ### Changed
129
+
130
+ - **Move to new folder** makes the folder at the board's own level: a sub-folder in the board's slot
131
+ when the board sits in a folder, right after its sub-folder when it sits in one. At the root it
132
+ behaves as before.
133
+
134
+ ### Docs
135
+
136
+ - A new guide, [docs/boards-and-folders.md](docs/boards-and-folders.md): the sidebar moves, the two
137
+ files, descriptions, what publishing shows, mixed-version teams. The README links it and describes
138
+ two levels. `instructions/boards.md` and the AGENTS contract teach agents the two-level moves,
139
+ including renaming a folder slug (its sub-folders' `parent` moves with it) and deleting one.
21
140
 
22
141
  ### Upgrading
23
142
 
24
- - **The registry says `"version": 2` while any folder nests, and 1 when none does.** Marver 0.20
25
- and earlier refuse a version-2 registry with an error instead of rewriting it flat, so a
26
- teammate on an older version sees a clear message - upgrade the whole team before nesting.
27
- A canvas tab opened before the upgrade is refused the same way once folders nest: reload it.
143
+ - **The registry says `"version": 2` while any folder nests, and `1` when none does.** Marver 0.20
144
+ and earlier refuse a version-2 registry with an error instead of rewriting it flat, so upgrade the
145
+ whole team before nesting a folder. A browser tab opened before the upgrade is refused the same way
146
+ once folders nest - reload it.
28
147
  - Run `npx marver init` to take the new folders guidance (unedited instruction files update in
29
148
  place; edited ones are staged in `design/.local/latest/`).
30
149
 
package/README.md CHANGED
@@ -8,7 +8,7 @@
8
8
 
9
9
  Screens, prototypes, specs, and now slide decks - all real code, all on one canvas, all shareable with people who sign in as themselves.
10
10
 
11
- [marver.design](https://marver.design) · [Slides](docs/slides.md) · [Sticky notes](docs/sticky-notes.md) · [Live Jam](docs/live-jam.md) · [Deploying a canvas](docs/publish.md) · [Sharing](docs/sharing.md) · [Changelog](CHANGELOG.md) · [Contributing](CONTRIBUTING.md) · [Issues](https://github.com/TNEP4/marver/issues)
11
+ [marver.design](https://marver.design) · [Boards and folders](docs/boards-and-folders.md) · [Context](docs/context.md) · [Slides](docs/slides.md) · [Sticky notes](docs/sticky-notes.md) · [Live Jam](docs/live-jam.md) · [Deploying a canvas](docs/publish.md) · [Sharing](docs/sharing.md) · [Changelog](CHANGELOG.md) · [Contributing](CONTRIBUTING.md) · [Issues](https://github.com/TNEP4/marver/issues)
12
12
 
13
13
  ## Quickstart
14
14
 
@@ -40,7 +40,7 @@ Frames appear on the canvas the moment the files land. That's the loop.
40
40
 
41
41
  ## The canvas
42
42
 
43
- - **Frames, scenes, boards.** Frames are screens, scenes group them (`design/scenes/<scene>/<frame>.tsx`), boards arrange them. Agents write `design/boards/<name>.json` (a frame list is enough); switch boards at the top of the sidebar. `all-scenes` is auto-managed. Right-click any board, scene, or frame in the sidebar to copy its path - the exact string to paste to your agent - and rename or drag-reorder boards from there too. Boards can live in folders: right-click the Boards header (or its `+`) for a new one, name it inline, drag boards in and out (the seam shows exactly where a release lands) and folders among boards; agents do the same by writing `"folder": "<name>"` on a board and `design/boards/_folders.json` for empty or ranked folders (`npx marver boards` prints the tree). Boards, folders and scenes take a `title` - any name you like, "MVP", "UI", "Checkout (v2) 🛒" - while their file, key and directory stay the slug agents address; Rename in the sidebar edits the title. Every object takes a one-sentence `description` (project in `design/config.ts`, boards and folders in their JSON, a scene's first `_brief.md` line, `meta.description` on a frame) and `design/manifest.json` carries them all - a new agent session orients in one read.
43
+ - **Frames, scenes, boards.** Frames are screens, scenes group them (`design/scenes/<scene>/<frame>.tsx`), boards arrange them. Agents write `design/boards/<name>.json` (a frame list is enough); switch boards at the top of the sidebar. `all-scenes` is auto-managed. Right-click any board, scene, or frame in the sidebar to copy its path - the exact string to paste to your agent - and rename or drag-reorder boards from there too. Boards can live in folders, two levels deep - a folder holds boards and folders, a sub-folder holds boards: right-click the Boards header (or its `+`) for a new folder, a folder for a new one inside it, name it inline, drag boards in and out at either level (the seam shows exactly where a release lands, indented with the level) and folders among boards or into a folder; agents do the same by writing `"folder": "<name>"` on a board and `design/boards/_folders.json` for empty, ranked or nested folders (a sub-folder names its `"parent"`; `npx marver boards` prints the tree). The [boards and folders guide](docs/boards-and-folders.md) has every move. Boards, folders and scenes take a `title` - any name you like, "MVP", "UI", "Checkout (v2) 🛒" - while their file, key and directory stay the slug agents address; Rename in the sidebar edits the title. Every board wears an icon for its type - start, feature, surface, project, feedback, context, deck, archive - its own or its folder's, and feature boards wear a status read from the project's `context/`. Every object takes a one-sentence `description` (project in `design/config.ts`, boards and folders in their JSON, a scene's first `_brief.md` line, `meta.description` on a frame) and `design/manifest.json` carries them all - a new agent session orients in one read.
44
44
  - **Devices view.** Hotkeys `1`-`5` (or the Devices menu) size every frame to mobile / tablet / laptop / monitor / tv to sweep your breakpoints; `0` restores your own layout exactly. Widths live in `design/config.ts`.
45
45
  - **Prototype links.** `data-goto="scene/frame"` on any element links frames into a walkable prototype - across boards, too.
46
46
  - **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.
@@ -50,6 +50,16 @@ Frames appear on the canvas the moment the files land. That's the loop.
50
50
  - **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.
51
51
  - **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 1280×720 slide is 5120×2880, whatever size its node has). Paste into Slack, a doc, or a chat with your agent.
52
52
 
53
+ ## Context
54
+
55
+ Code says what is implemented; `context/` says the rest - what is available and to whom, how each
56
+ capability works, why, what is next - with evidence, in files any agent reads first.
57
+ `npx marver context init` sets it up, `npx marver context check` keeps it true in ci (availability
58
+ only in the shipped record, every claim with a level and a citation, a contract change with every
59
+ behaviour change), and the canvas reads the same files: feature boards wear Backlog, To do, In
60
+ progress, Done - never set by hand. Existing projects with scattered specs get a playbook that
61
+ reorganizes them on a branch and proves it with a blind eval. [The context guide](docs/context.md).
62
+
53
63
  ## Slides
54
64
 
55
65
  A deck is a scene of `slide: true` frames. On the canvas they are frames like any other - comment on them, laser them, fork variants, drag them to reorder the deck (the board's reading order is the play order). Press `p` on a slides board and you get slides mode: arrows / Space / click to advance, `d` cycles the theme, morphs between slides where the agent named the same element twice.
@@ -90,7 +100,7 @@ The same glow, driven from the terminal. When your agent takes a request, it cre
90
100
 
91
101
  | Command | What it does |
92
102
  |---|---|
93
- | `npx marver init` | Scaffold `design/` in this repo (safe to re-run; refreshes managed files) |
103
+ | `npx marver init [--kind product\|knowledge]` | Scaffold `design/` in this repo (safe to re-run; refreshes managed files); a fresh canvas gets the kind's typed folders |
94
104
  | `npx marver dev` / `canvas` | Start the local canvas - hot reload, comments, Live Jam armed (`--port`, default 5199) |
95
105
  | `npx marver build` | Static export → `design/.dist`; what ships comes from `design/publish.json` (default-closed) |
96
106
  | `npx marver serve` | Serve the export; `MARVER_ID_ISSUER` or `MARVER_PASSWORD` gates it, `MARVER_DATA_DIR` persists comments + accounts |
@@ -98,7 +108,10 @@ The same glow, driven from the terminal. When your agent takes a request, it cre
98
108
  | `npx marver comments …` | The agent's queue: `connect <url>` · `sync` · `list` · `reply` · `resolve` · `invite <email>` · `revoke <email>` |
99
109
  | `npx marver work …` | Working glow from the terminal: `start <scene/frame …>` · `done … \| --all` · `list` |
100
110
  | `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 |
101
- | `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 |
111
+ | `npx marver boards [--json]` | The sidebar as the files say it is: folders and sub-folders, boards in reading order with their title, type, status, `order` and description, the landing board |
112
+ | `npx marver boards new <name> [--folder f] [--type t]` | A board in its type's starting layout - a feature's spec, lo-fi and hi-fi bands, a start board rendering `context/` |
113
+ | `npx marver folders add <module ...>` | Add a typed folder: `start`, `features`, `surfaces`, `projects`, `feedback`, `context`, `decks`, `archive` |
114
+ | `npx marver context init \| check \| index` | Set up `context/`; check it (exit 0 / 1 / 2; `--base`, `--body-file` for a pull request); regenerate the index's capability table |
102
115
 
103
116
  ## Shortcuts
104
117
 
@@ -1,4 +1,4 @@
1
- import { AREA, SURFACE, pool, shotConcurrency, withBrowser } from "./shot-DswS4iRK.mjs";
1
+ import { AREA, SURFACE, pool, shotConcurrency, withBrowser } from "./shot-BAR8hmU9.mjs";
2
2
  import { existsSync, mkdirSync, readFileSync, readdirSync, realpathSync, renameSync, rmSync, statSync, utimesSync, writeFileSync } from "node:fs";
3
3
  import { join, sep } from "node:path";
4
4
  import { createHash } from "node:crypto";