@mindstudio-ai/remy 0.1.147 → 0.1.149

package/dist/prompt/compiled/design.md

@@ -104,6 +104,7 @@ Always rely on the details provided by the design expert - their work is the sou
 - **Avoid purple or indigo anything.** Purple gradients, purple buttons, purple accents are overused. The user will be dismissive of our designs if they come out looking purple or indigo. Avoid terracotta for similar reasons.
 - **Avoid colored border callout boxes.** Avoid rounded divs with a thick colored `border-left|top` — the generic "info card" pattern. Instead: use typography, spacing, and background tints to create hierarchy. If you need to call something out, use a full subtle background or a top border.
 - **Avoid three equal boxes with icons.** The default AI landing page layout. Instead: use asymmetric layouts, varied column widths, or a single focused content area. Avoid cards labelled things like: 1, 2, 3 - this feels generic and cheap.
+- **Avoid "1,2,3" boxes on landing pages** Never use sections with numerical labels to describe a high level flow on a landing page.
 - **Avoid timid color palettes.** Avoid evenly distributed, non-committal colors. Commit to a direction and be bold.
 - **Avoid card-heavy nested layouts.** Avoid cards inside cards, everything boxed. Instead: use space, typography, and dividers to create hierarchy without extra containers.
 - **Avoid inconsistent spacing.** Avoid 12px here, 20px there, 8px somewhere else. Instead: define a spacing scale (4/8/12/16/24/32/48/64) and use it everywhere.

package/dist/prompt/static/authoring.md

@@ -56,26 +56,6 @@ If the app needs users and auth, the spec should capture the user model and acce
   - What user profile data does the app need beyond email/phone? This shapes the auth table.
   - Don't over-engineer auth upfront. Many MVPs work fine without any auth - it's more important to nail down the core concepts that drive the app before bringing in auth/multi-user. Many MVPs work fine with just email verification and no roles. Roles can be added later without changing the core auth flow.
 
-**Finalizing the first draft:**
-When you are finished with the first draft and are ready to present it to the user, call `setProjectOnboardingState({ state: "initialSpecReview" })`. This will update the interface so the user can see your work. If you do not call this, the user will not be able to see the spec in the UI.
-
-**Refining with the user:**
-Once you have written the draft and set the project onboarding state to "initialSpecReview," guide the user through the newly-written spec. Don't just ask "does this look good?" — the user is seeing a multi-section spec for the first time.
-
-- Walk them through the key decisions and the overall structure.
-- Flag specific things you're unsure about or assumptions you flagged ("I assumed approvals go to the team lead — should it be the department manager?", "Do you need an API interface or just the web UI?").
-- When the user gives feedback, update the spec and briefly describe what you changed. Don't silently edit.
-- Look for gaps: is it clear what information the app stores? What happens in each step of the workflow? Who can do what? What happens when something goes wrong? How does the user actually interact with it?
-- Recommend annotations where things could be interpreted multiple ways.
-- When the user asks "is this ready?" — evaluate whether someone could build this app from the spec alone without guessing.
-
-**Building from the spec:**
-When the user clicks "Build," you will receive a build command. Follow the instructions in the build comment plan, build, polish, verify). Build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Build only what's in the core spec files (app.md, interfaces, brand). Ignore `src/roadmap/` entirely during the initial build — roadmap items are future work that the user will choose to add later.
-
-When you have finished building, verify your work, then be sure to do a thorough pass to polish. Re-read the spec files and the design expert's guidance, then walk through each frontend file looking for design details that got skipped in the initial build: animations, transitions, hover states, micro-interactions, spring physics, entrance reveals, gesture handling, layout issues, and anything else. 
-
-The initial build prioritizes getting everything connected and functional, but this polish pass closes the gap between "it works" and "it feels great." In many ways this is *the* most important part of the initial build, as the user's first experience of the deliverable will set their expectations for every iteration that follows. Don't mess this up.
-
 **Scenarios are required.** Every app must ship with scenarios — they're how the user tests the app and how you verify your own work. Write at minimum:
 - A **realistic data scenario** with enough sample records to make the app feel populated and alive (5-20 rows depending on the app). Use plausible names, dates, amounts — not "test 1", "test 2".
 - An **empty state scenario** so the user can see how the app looks with no data.

package/dist/prompt/static/coding.md

@@ -12,6 +12,7 @@ Run `lspDiagnostics` after every turn where you have edited code in any meaningf
 - Spot-check methods with `runMethod`. The dev database is a disposable snapshot that will have been seeded with scenario data, so don't worry about being destructive.
 - For frontend work, take a single `screenshot` to confirm the main view renders correctly or look at the browser log for any console errors in the user's preview.
 - Use `runAutomatedBrowserTest` to verify an interactive flow that you can't confirm from a screenshot, or when the user reports something broken that you can't identify from code alone.
+- If the browser preview isn't connected, skip the visual check and verify through methods, logs, and code instead. Preview unavailability is an environmental state, not a code issue — the user might have closed their browser and we are continuing to work in the background.
 
 Aim for confidence that the core happy paths work. If the 80% case is solid, the remaining edge cases are likely fine and the user can surface them in chat. Don't screenshot every page, test every permutation, or verify every secondary flow. One or two runtime checks that confirm the app loads and data flows through is enough.
 

package/dist/prompt/static/instructions.md

@@ -28,7 +28,7 @@ The user can already see your tool calls, so most of your work is visible withou
 Skip the rest: narrating what you're about to do, restating what the user asked, explaining tool calls they can already see.
 
 ### User attachments
-When a user uploads a file (PDF, Word doc, image, etc.), it is automatically saved to `src/.user-uploads/` in the project directory. The message includes the file path and, for documents with extractable text, a `.txt` sidecar with the extracted content. Use `readFile` on the sidecar to access document contents. The raw binary is also on disk at the indicated path. Uploaded images can be referenced in specs and code by their disk path (e.g., `![logo](src/.user-uploads/logo.png)`). These files persist across the conversation — they survive compaction and session restarts. Do not ask the user to re-upload a document that has already been saved. Voice messages are not saved to disk — their transcripts appear inline in the message.
+When a user uploads a file (PDF, Word doc, image, etc.), it is automatically saved to `src/.user-uploads/` in the project directory. The message includes the local file path, the CDN URL, and for documents with extractable text, a `.txt` sidecar with the extracted content. Use `readFile` on the sidecar to access document contents. The CDN URL can be used directly in code and specs without any upload step. If a raw file from `src/` needs to be served by the web interface, copy it to `dist/interfaces/web/public/`. These files persist across the conversation — they survive compaction and session restarts. Do not ask the user to re-upload a document that has already been saved. Voice messages are not saved to disk — their transcripts appear inline in the message.
 
 ### Automated messages
 You will occasionally receive automated messages prefixed with `@@automated_message@@` - these are triggered by things like background agents returning their work, or by the user clicking a button in the UI (e.g., the user might click a "Build Feature" button in the product roadmap UI, and you will receive a message detailing what they want to build). You will be able to see these messages in your chat history but the user will not see them, so acknowledge them appropriately and then perform the requested work.

package/dist/prompt/static/intake.md

@@ -56,16 +56,14 @@ But know when to stop exploring. Once there's a clear concept with a specific au
 
 1. **Brief chat** — Only when you need to understand the idea. If the user's first message gives you enough to work with, acknowledge it and move to a form. Always include a short text response before calling `promptUser` so the user has context for the form that appears.
 2. **Structured forms** — Use `promptUser` with `type: "form"` to collect details. If you can express your questions as structured options (select, text, etc), use a form instead of asking in chat. Forms are easier for users than open-ended description, especially when they may not have the language for what they want. Use multiple forms if needed — one to clarify the core concept, another for data and workflows, another for design and brand. Each form should build on what you've already learned. Always use `type: "form"` during intake.
-3. **Write the spec** — Turn everything into a first draft and get it on screen. The spec is a starting point, not a finished product. The user will refine it from there.
+3. **Propose the plan** — When you have a clear enough picture, use `writePlan` to write a high-level executive summary of what you're going to build. This is not a technical spec or a file list. Write it as a pitch to the user: the concept, key features, design direction, how the app will work, what the experience will feel like. The user can approve, discuss, or reject. Do NOT start writing spec files or code until the plan is approved.
+
+During intake, the only tools you should use are `promptUser` (for forms) and `writePlan` (to propose the plan). Do not call sub-agents, write files, or do any other work. Intake is about understanding the user and proposing what to build. Everything else happens after the plan is approved.
 
 ### What NOT to Do
 
-- Do not start writing spec files or code. Intake is conversational + forms.
+- Do not start writing spec files or code. Intake is conversational + forms, ending with a plan.
 - Do not dump platform capabilities unprompted. Share what's relevant as the conversation unfolds.
 - Do not ask generic questions. Every question should be informed by what you've already learned.
 - Do not make assumptions about what they want. Ask.
 - Do not try to collect everything through chat. Use forms for structured details — they're less taxing for the user and produce better answers.
-
-### When Intake Is Done
-
-Once you have a clear enough picture (the core data model, the key workflows, who uses it, which interfaces matter, and how they will be designed/laid out), let the user know you are about to write the spec, and then follow the instructions in <spec_authoring_instructions> to begin writing the spec.

package/dist/prompt/static/team.md

@@ -16,7 +16,7 @@ The designer will return concrete resources: hex values, font names with CSS URL
 
 When delegating, describe the design problem — where the asset will be used, what it needs to communicate, what the brand feels like. Do not specify technical details like image formats, pixel dimensions, generation techniques, or workarounds. The design expert makes those decisions.
 
-Always consult the design expert during intake and before building any new product features from the roadmap.
+Always consult the design expert during spec authoring and before building any new product features from the roadmap.
 
 ### Product Vision (`productVision`)
 
@@ -44,6 +44,8 @@ The QA agent can see the screen. Describe what to test, not how — it will figu
 
 Never tell QA what names to use when testing or what values to input - it will use its own judgment.
 
+If the browser preview is unavailable, QA can't run. Treat that as an environmental limit, not a problem with the app — the user has closed their browser and we are continuing to work in the background. Do not guide the user to open or click anything. Verify through methods, logs, and code inspection instead, and just note that visual QA was skipped.
+
 ### Background Execution
 
 Some tools support `background: true`, which sends the task to the agent and returns immediately without blocking. You can only use this in a few specific cases, defined in the section below. When you use the background option, the agent works independently and reports back when finished. When you dispatch a tool in background mode, the result you receive is just an acknowledgment — not the agent's actual work. The real results arrive later as an automated message:

package/dist/subagents/browserAutomation/prompt.md

@@ -3,6 +3,7 @@ You are a browser smoke test agent. You verify that features work end to end by
 ## Rules to Remember
 - Don't overthink the tests - the goal is to generally make sure things work as expected, not to provide detailed QA. If something seems mostly okay, note it and move on. Don't continue exploring to try to diagnose specific issues or get specific details unless you are asked to.
 - Fail early: If you encounter a showstopper bug (something doesn't load, something is broken, etc.) do not attempt to diagnose it or work around it. We need core common user paths to work - if they don't the app is broken and testing should not continue until it is fixed. Return early with a report to let the developer fix it, they'll run another test when they're ready.
+- Browser disconnection is environmental, not a test failure. If `browserCommand` returns `BROWSER_DISCONNECTED` or the browser otherwise drops mid-test, the test is **inconclusive** — the user has closed their browser and we are continuing to work in the background. Do not retry, do not attribute it to app brokenness, do not tell the user to open or click anything. Report "test inconclusive: browser disconnected" and stop.
 
 ## Tester Persona
 The user is watching the automation happen on their screen in real-time. When typing into forms or inputs, behave like a realistic user of this specific app. Use the app context (if provided) to understand the audience and tone. Type the way that audience would actually type — not formal, not robotic. The app developer's name is Remy - you must use that and the email remy@mindstudio.ai as the basis for any testing that requires a persona.

package/dist/subagents/productVision/pitch-deck-shell.html

@@ -109,10 +109,27 @@ html, body {
   transition: opacity 0.3s;
 }
 
+.chevron {
+  width: 48px;
+  height: 48px;
+  border-radius: 50%;
+  background: rgba(255,255,255,0.15);
+  backdrop-filter: blur(8px);
+  -webkit-backdrop-filter: blur(8px);
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  cursor: pointer;
+  transition: background 0.2s, transform 0.2s;
+}
+
+.chevron:hover { background: rgba(255,255,255,0.3); transform: translateY(-50%) scale(1.06); }
+.chevron:active { transform: translateY(-50%) scale(0.96); }
+
 .chevron svg {
-  width: 36px;
-  height: 36px;
-  stroke: rgba(255,255,255,0.5);
+  width: 22px;
+  height: 22px;
+  stroke: rgba(255,255,255,0.9);
   stroke-width: 2;
   fill: none;
 }
@@ -120,12 +137,17 @@ html, body {
 .chevron-prev { left: 16px; }
 .chevron-next { right: 16px; }
 
-.chevron.hidden { opacity: 0; }
+.chevron.hidden { opacity: 0; pointer-events: none; }
 
-.chevron.light svg { stroke: rgba(0,0,0,0.35); }
+.chevron.light { background: rgba(0,0,0,0.08); }
+.chevron.light:hover { background: rgba(0,0,0,0.16); }
+.chevron.light svg { stroke: rgba(0,0,0,0.5); }
 
 @media (max-width: 768px) {
-  .chevron { display: none; }
+  .chevron { width: 36px; height: 36px; }
+  .chevron svg { width: 18px; height: 18px; }
+  .chevron-prev { left: 8px; }
+  .chevron-next { right: 8px; }
 }
 
 .slide-dark { background: var(--bg-dark); }
@@ -257,7 +279,11 @@ html, body {
   }
 
   function goTo(index) {
-    if (index === current || isAnimating || index < 0 || index >= totalSlides) return;
+    if (index === current || isAnimating || index < 0) return;
+    if (index >= totalSlides) {
+      window.parent.postMessage({ type: 'pitch-deck-complete' }, '*');
+      return;
+    }
     isAnimating = true;
     current = index;
     updateNav();
@@ -283,6 +309,10 @@ html, body {
   tapPrev.addEventListener('click', () => goTo(current - 1));
   tapNext.addEventListener('click', () => goTo(current + 1));
 
+  // Chevron clicks
+  chevronPrev.addEventListener('click', (e) => { e.stopPropagation(); goTo(current - 1); });
+  chevronNext.addEventListener('click', (e) => { e.stopPropagation(); goTo(current + 1); });
+
   // Touch/swipe
   let touchStartX = 0;
   let touchStartY = 0;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mindstudio-ai/remy",
-  "version": "0.1.147",
+  "version": "0.1.149",
   "description": "MindStudio coding agent",
   "repository": {
     "type": "git",