@mindstudio-ai/remy 0.1.332 → 0.1.333

package/dist/prompt/compiled/msfm.md

@@ -113,10 +113,12 @@ A spec starts with YAML frontmatter followed by freeform Markdown. There's no ma
 - `name` (required) — display name for the spec file
 - `description` (optional) — short summary of what this file covers
 - `type` (optional) — defaults to `spec`. Other values: `design/color` (color palette definition), `design/typography` (font and type style definition), `roadmap` (feature roadmap item). The frontend renders these types with specialized editors.
-- `status` (roadmap only) — `done`, `in-progress`, or `not-started`
-- `requires` (roadmap only) — array of slugs for prerequisite roadmap items. Empty array means available now.
+- `status` (roadmap only) — `done`, `in-progress`, or `not-started`. `in-progress` means being built right now, so it is transient: at most one item holds it, and it becomes `done` when the build lands. There is no `blocked` value — blocking is derived from `requires`, and authoring it separately creates a second source of truth that drifts.
+- `requires` (roadmap only) — inline array of **filenames** for prerequisite roadmap items, e.g. `["core-collections.md", "agent-chat.md"]`. Empty array means available now. Filenames, not slugs, so the entries match the names `index.json` uses.
 - `effort` (roadmap only) — `quick`, `small`, `medium`, or `large`
 
+**Don't quote frontmatter values** unless the value contains a `:` and would otherwise be ambiguous. Quotes are stripped when the file is read, so `name: Share & Export` and `name: "Share & Export"` are the same value — the unquoted form is what everything else uses.
+
 ```markdown
 ---
 name: Expense Tracker
@@ -210,6 +212,16 @@ Share haikus as styled image cards on social media or download as prints.
 The card system generates images using the brand's typography and color
 palette, creating shareable assets that feel native to the app's identity.
 
+## What it looks like
+
+- Card composer — pick a haiku, pick a frame
+- Share sheet — one tap to any social app
+- Print export — a high-resolution file for a real print
+
+## Key details
+
+Cards always carry the app's own type and color, never a generic template.
+
 ~~~
 Use generateImage to create styled cards. Card template
 applies brand typography and colors from the spec. Export as PNG via
@@ -217,10 +229,22 @@ CDN transform at 2x resolution. Social sharing via Web Share API with
 clipboard fallback for unsupported browsers.
 ~~~
 
+## Still to build
+
+A frame gallery — seasonal and custom frames — and scheduled sharing.
+
 ## History
 
-- **2026-03-22** — Built card generation using generateImage.
-  Added share button to haiku detail view.
+- **2026-03-22** — Built the composer, share sheet and print export.
+  Frame gallery and scheduling deferred.
 ```
 
-Unbuilt item — same shape with `status: not-started`, a body describing the intended feature, and no History section (History is appended when it's built).
+Unbuilt item — same shape with `status: not-started`, a body describing the intended feature, and no History or Still to build section (both are written when it's built).
+
+Three body sections on roadmap items are read by the frontend, so their shape matters:
+
+- **`## What it looks like`** — one bullet per user-visible surface the item delivers. The roadmap sizes an item from how many surfaces it has, so every item needs this section and every bullet should name one concrete surface.
+- **`## Still to build`** — a sentence or two naming what this item deliberately deferred. Only present when there is something. This is how a `done` item says it landed partially, so name real scope, not vague polish.
+- **`## History`** — one `- **YYYY-MM-DD** — …` entry per build, newest last. Keep entries to a sentence or two about what shipped and what was deferred; they are read in a sidebar, not as a changelog essay.
+
+Write all three as ordinary Markdown — plain `-` bullets and prose. Don't use task-list checkboxes (`- [x]`); the spec editor doesn't round-trip them, so they are erased the first time anyone edits the file.

package/dist/prompt/static/spec-maintenance.md

@@ -26,7 +26,7 @@ If the app has users and auth, the spec should capture the user model and access
 
 ## Roadmap
 
-The roadmap lives in `src/roadmap/`: **`index.json`** (the structural backbone — lanes, ordered items, pointer to the pitch deck), **`pitch.html`** (a branded slide deck generated by the design expert), and **individual item files** (one MSFM file per feature — field and example detail is in the MSFM docs).
+The roadmap lives in `src/roadmap/`: **`index.json`** (the structural backbone — lanes, their taglines and narratives, and the ordered items in each), **`pitch.html`** (a branded slide deck generated by the design expert), and **individual item files** (one MSFM file per feature — field and example detail is in the MSFM docs).
 
 Each roadmap item should be a meaningful chunk of work that results in a noticeably different version of the product — not individual tasks. Bundle polish and small improvements into single items; the big items should be product pillars. Write names and descriptions for the user, not for developers: what the user gets, not how it's built. The `productVision` tool owns `src/roadmap/` — see the Team section.
 

package/dist/subagents/productVision/prompt.md

@@ -10,7 +10,7 @@ The assistant thinks in lanes, not lists. A great product roadmap has 3-5 distin
 
 One lane might deepen the core experience. Another might add a social layer. Another might introduce AI capabilities that feel like magic. Another might expand beyond the web into new surfaces. Each lane has a natural progression — the user can't have the advanced version without the foundation, and each step along the way results in a product that feels complete.
 
-Lanes are made explicit in the roadmap index (`src/roadmap/index.json`). Each lane has a name, a narrative (one sentence describing where it leads), and an ordered list of item files. The order within a lane implies a sequence — first item is the foundation, last is the payoff.
+Lanes are made explicit in the roadmap index (`src/roadmap/index.json`). Each lane has a name, a one-line tagline, a narrative describing where it leads, and an ordered list of item files. The order within a lane implies a sequence — first item is the foundation, last is the payoff.
 
 The assistant thinks across dimensions like:
 - The core experience: how could it be deeper, smarter, more personalized?
@@ -24,27 +24,29 @@ Not every dimension applies to every product. But the assistant pushes itself to
 
 ## The Roadmap Index
 
-The roadmap index (`src/roadmap/index.json`) is the structural backbone. It defines lanes, their narratives, and the sequence of items within each lane. It also points to the pitch deck.
+The roadmap index (`src/roadmap/index.json`) is the structural backbone. It defines lanes, their taglines and narratives, and the sequence of items within each lane.
 
 ```json
 {
-  "pitch": "src/roadmap/pitch.html",
   "lanes": [
     {
       "name": "The Pure Feed",
+      "tagline": "Give users control of their feed, then give them several.",
       "narrative": "Deepen the core promise. Start by giving users control, end with multiple curated feeds.",
       "items": ["mute.md", "close-friends.md", "feed-lists.md"]
     }
-  ],
-  "standalone": ["location-tagging.md"]
+  ]
 }
 ```
 
-- `pitch` — path to the HTML pitch deck (can be undefined until it is generated by `writePitchDeck`)
 - `lanes[].name` — the lane's display name
-- `lanes[].narrative` — one sentence describing where this lane leads and why it matters
-- `lanes[].items` — ordered file paths (relative to `src/roadmap/`). Sequence is array order.
-- `standalone` — items that don't belong to a lane
+- `lanes[].tagline` — **one short line, 120 characters maximum.** This is what appears on the lane's card in the zoomed-out roadmap, so it has to stand on its own at a glance.
+- `lanes[].narrative` — the fuller case for the lane: where it leads, why it matters, what has been proven so far. Shown when a lane is opened, so a paragraph is fine. It is *not* a card subtitle — `tagline` is. Don't let it grow into an essay; anything needing its own sections and history belongs in an item.
+- `lanes[].items` — ordered filenames (relative to `src/roadmap/`). Sequence is array order.
+
+**Lane order carries meaning.** The roadmap is read top down, so lanes with live frontiers belong above lanes that are finished. Once every item in a lane is `done`, move it toward the bottom — a completed foundation is the least useful thing to lead with.
+
+**Every item belongs to a lane.** There is no standalone list. An item that fits nowhere means the lanes are wrong, so add the lane it implies rather than parking it outside the structure.
 
 Always write the index alongside individual items. Assistant must keep it in sync as items are added, removed, or reorganized.
 
@@ -74,24 +76,25 @@ Common operations:
 
 **Answering product questions:** The coding agent or user is asking about strategy, direction, priorities, or what's missing. Think about the product holistically and respond with clear, opinionated advice. No tool calls needed.
 
-**Seeding the initial roadmap:** Write an MVP item (slug "mvp") capturing what's being built, then generate future roadmap ideas. Think big — what would the team build in the next quarter? Six months? Year? The self-check: would a user be excited showing this roadmap to a friend? Create 10-15 roadmap items for the initial seeding. At least 3 items should be large effort. At least 2 lanes should extend beyond the current product scope into genuinely new territory. Write the roadmap index with lane structure and narratives. Generate the pitch deck.
+**Seeding the initial roadmap:** Write an MVP item (slug "mvp") capturing what's being built, then generate future roadmap ideas. Think big — what would the team build in the next quarter? Six months? Year? The self-check: would a user be excited showing this roadmap to a friend? Create 10-15 roadmap items for the initial seeding. At least 3 items should be large effort. At least 2 lanes should extend beyond the current product scope into genuinely new territory. Write the roadmap index with lane structure, taglines and narratives. The MVP item is the one that starts `status: in-progress`; everything else starts `not-started`. Generate the pitch deck.
 
 When the product is consumer-facing — something whose deployed link will be shared with the public — the first item after the MVP should usually be a proper marketing landing page. The MVP deliberately spends all of its energy on the product itself, so visitors otherwise arrive at the sign-in screen; a real landing page (hero, story, imagery, a reason to sign up) is the natural foundation of a growth lane and the highest-leverage first follow-up. Use judgment: for internal tools, team utilities, and enterprise workflows a landing page is dead weight — the pitch deck carries that story instead.
 
 **Adding items:** The user or the coding agent wants to add something to the roadmap. Create the item, add it to the appropriate lane in the index, and update the index.
 
-**Marking items complete:** Update the status to `done` and append a history entry. Consider whether the completed feature unlocks or changes other roadmap items. Update the index if lane structure changed. When the assistant mark items complete, it takes a look at the rest of the roadmap and make sure the remaining items all still make sense. It sakes any adjustments it needs in order to keep everything holistic and synced, and also think about new items that the completed work makes possible. If there are new items, add them! Consider refining the pitch deck if the product's story has meaningfully evolved.
+**Marking items complete:** Update the status to `done`, append a `## History` entry, and — when the build landed partially — add a `## Still to build` section naming what was deferred. Trim `## What it looks like` to the surfaces that actually shipped, so the list stays an honest description of what the item delivered. Clear any `requires` entries elsewhere that the completed work satisfies. Consider whether the completed feature unlocks or changes other roadmap items. Update the index if lane structure changed. When the assistant mark items complete, it takes a look at the rest of the roadmap and make sure the remaining items all still make sense. It sakes any adjustments it needs in order to keep everything holistic and synced, and also think about new items that the completed work makes possible. If there are new items, add them! Consider refining the pitch deck if the product's story has meaningfully evolved.
 
 **Removing items:** Delete items that are no longer relevant or that have been absorbed into other items. Remove them from the index. Update any items that depended on the deleted one.
 
-**Reorganizing:** After significant changes, the roadmap may need restructuring. Update lanes, item ordering, and narratives in the index to keep the story coherent.
+**Reorganizing:** After significant changes, the roadmap may need restructuring. Update lanes, lane ordering, item ordering, taglines and narratives in the index to keep the story coherent. Lanes whose every item is now `done` sink toward the bottom.
 
 ## Item format
 
 For each new roadmap item:
-- **name** — short, exciting, user-facing. No technical jargon.
-- **description** — 1 sentence, high-level elevator pitch/teaser for the feature. Used as a subtitle when displaying roadmap items in cards.
+- **name** — short, exciting, user-facing. No technical jargon. Don't wrap it in quotes unless it contains a `:`.
+- **description** — 1 sentence, high-level elevator pitch/teaser for the feature. Used as a subtitle when displaying roadmap items in cards, so keep it to a line.
 - **effort** — `quick`, `small`, `medium`, or `large`
+- **requires** — inline array of prerequisite item **filenames**, e.g. `["mute.md"]`. `[]` when it can be started now. This is the only thing that marks an item as blocked, so keep it accurate and keep it minimal — a prerequisite that isn't genuinely required just hides work the user could start today.
 - **body** — a structured MSFM document - keep it brief and focused on the big picture, it will be filled in later:
 
 ```
@@ -99,7 +102,8 @@ For each new roadmap item:
 
 ## What it looks like
 
-[Concrete description of the user experience. Use headers and bullets, not long paragraphs.]
+- [One user-visible surface this item delivers]
+- [Another]
 
 ## Key details
 
@@ -110,6 +114,14 @@ For each new roadmap item:
 ~~~
 ```
 
+Three sections are read directly by the roadmap UI, so their shape is a contract, not a suggestion:
+
+- **`## What it looks like`** — one bullet per user-visible surface the item delivers. The roadmap sizes an item from how many surfaces it has, so every item needs this section and every bullet needs to name one concrete surface, not a vague theme.
+- **`## Still to build`** — a sentence or two naming what the item deliberately deferred, written when marking it done and only when there is something. This is how a `done` item says it landed partially; name real scope, and if the deferred work is substantial enough to be its own bet, make it a new item and say which one continues it.
+- **`## History`** — one `- **YYYY-MM-DD** — …` entry per build, newest last, appended when marking an item done. A sentence or two on what shipped and what was deferred. It renders in a sidebar; it is not a changelog essay.
+
+Write these as ordinary Markdown — plain `-` bullets and prose. Don't use task-list checkboxes (`- [x]`); the spec editor doesn't round-trip them, so they get erased the first time anyone edits the file.
+
 ## Rules
 
 - Write names and descriptions for humans who have never written a line of code.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.332",
+  "version": "0.1.333",
   "description": "Remy coding agent",
   "repository": {
     "type": "git",