@marver-design/marver 0.8.0 → 0.8.1

package/templates/AGENTS-studio.md

@@ -50,6 +50,29 @@ Two channels carry element-precise feedback - honor both:
   thread carries the anchored element (tag, quoted text, css path, frame). Work that queue
   per instructions/iterate.md; the comment names the div, so read the anchor before the words.
 
+## Show the work (working state)
+
+The canvas can wear your effort live. When a request will create or change frames, making
+it visible is your FIRST act - before research, before reading the codebase, before
+planning. The human should see the request land on the canvas within the first minute:
+
+1. **Create the frame files immediately** - right name, right scene, `meta` (title,
+   viewport), and a minimal skeleton (a heading and a few placeholder blocks - enough
+   to give it shape) - and pin them on the target board (APPEND a node to the board
+   JSON - adding is always yours, only rearranging belongs to the shell; auto boards pick
+   new frames up on their own). Changing existing frames only? Skip this step.
+2. **Light them up**: `npx marver work start <scene/frame ...>` - each frame wears the
+   live working shimmer. Only now do research, discovery, and planning begin - under a
+   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
+   self-expire (default 10 min; `--ttl <min>` up to 30) - re-run `start` on long jobs,
+   and never lean on expiry instead of `done`.
+
+Report where the request came from: chat requests get chat replies; only comment-born
+(`@marver`) work replies in its thread.
+
 ## Frames
 - A frame = one file: design/scenes/<scene>/<name>.tsx or .html. One frame, one surface.
 - It default-exports a React component. No imports from the tool are needed. Optional:
@@ -98,7 +121,9 @@ Two channels carry element-precise feedback - honor both:
   and each state (default / hover-styled / focus / disabled / loading) of one ui component.
 
 ## Rules
-- Do not edit design/boards/*.json while the canvas is open unless asked; the shell owns them.
+- Do not rearrange design/boards/*.json while the canvas is open unless asked - the shell
+  owns the layout fields (x/y/w/h, keys). APPENDING a node for a frame you just created is
+  always yours (Show the work, step 1).
 - Do not import from "design/" inside src/ or app/. The arrow points one way.
 - Do not add network calls, app stores, or auth to frames. Mocked data only.
 - Keep each frame self-sufficient: it must render from its file + fixtures + ui imports alone.
@@ -118,3 +143,25 @@ whitespace tokens, and the same grammar per scene for frames (columns align left
 edges; a variant-group name is one indivisible atom). BEFORE creating a board or
 publishing anything, read instructions/boards.md (the layout grammar, file format,
 publishing rules).
+
+## Upstream feedback (when marver itself misbehaves)
+
+You are also marver's eyes in the field. When the TOOL fails you - a canvas glitch, a CLI
+error, a broken promise in these instructions, a missing capability you genuinely needed -
+file it upstream so it gets fixed for everyone. This is about marver bugs, never about the
+owner's designs.
+
+- Search first, then file (one issue per problem):
+  `gh issue list --repo TNEP4/marver --search "<keywords>"` - comment on a match instead
+  of duplicating. Otherwise:
+  `gh issue create --repo TNEP4/marver --label bug --title "<symptom>" --body "<report>"`
+  (use `--label enhancement` for a capability wish). No `gh`? Give the owner the link:
+  `https://github.com/TNEP4/marver/issues/new` with your drafted title and body.
+- A useful report: the marver version (`npx marver --version`), what you did, what you
+  expected, what happened instead, and the smallest reproduction you can DESCRIBE -
+  e.g. "a board of 12 frames, one content frame with a mermaid diagram, hotkey 2".
+- **Privacy is hard law - the issue is public.** Never include the owner's code, file
+  contents or names, comment text, emails, screenshots, or anything that identifies this
+  repo or its product. Recreate the failure in neutral terms; if it cannot be described
+  without private detail, tell the owner instead of filing.
+- Tell the owner what you filed, with the link - it is their machine and their voice.

package/templates/instructions/publish.md

@@ -51,7 +51,7 @@ gitignored - it is built ON THE HOST at deploy time, never committed.**
 - a **persistent volume** mounted at some path, named by `MARVER_DATA_DIR`
 
 The `@marver-design/marver` dependency must resolve from the registry (a local
-`link:`/`file:` dep cannot ride to a remote host) - a normal `^0.4.0` in
+`link:`/`file:` dep cannot ride to a remote host) - a normal registry version (`npm i -D @marver-design/marver@latest`) in
 `package.json` is all it takes.
 
 ## Railway quickstart