@mindstudio-ai/remy 0.1.309 → 0.1.311

package/dist/prompt/compiled/interfaces.md

@@ -125,7 +125,7 @@ analytics.track('checkout_completed', { itemCount: 3, total: 47.99 });
 
 - **Apps can also READ their own analytics from backend methods** — the agent SDK's `analytics` namespace (lifetime per-page metrics, live visitor count, traffic sources, event stats), so an admin view can show real traffic next to the app's own data. Consult `askMindStudioSdk` for the query API when building one.
 
-- **Live UI updates come from the events namespace, not polling** — backend code publishes to named channels (`events.publish`, agent SDK) and the page receives them instantly via `events.connect` (interface SDK). Live dashboards, notifications, chat, multi-tab sync. Load the `realtime` skill before designing with it.
+- **Live UI updates come from the events namespace, not polling** — backend code publishes to named channels (`events.publish`, agent SDK) and the page receives them instantly via `events.connect` (interface SDK). Live dashboards, notifications, chat, multi-tab sync. Load the `realtimeEvents` skill before designing with it.
 
 Analytics is **cookie-banner-free by design**: per-app scoping, IP discarded after geo lookup, country-level only, query strings server-scrubbed except for a UTM whitelist (`utm_*`, `ref`, `source`, `gclid`, `fbclid`, `msclkid`), no fingerprinting, no third-party scripts. If a user asks about GDPR cookie consent for analytics, you can explain why it is not needed.
 

package/dist/prompt/compiled/sdk-actions.md

@@ -157,4 +157,4 @@ For multi-step tasks where the model needs to autonomously compose actions (rese
 
 ### Realtime Events
 
-Server→client push, no polling: `events.publish(channels, data)` from any method/cron/webhook reaches connected clients instantly; `events.grant(channels)` in a method (after your auth checks) mints the subscribe token the frontend's `events.connect` consumes. This is how live dashboards, notifications, chat, and multi-tab sync work — whenever you're about to write a frontend polling loop against your own backend, reach for this instead. Load the `realtime` skill before designing with it: channel shape (per-user fan-out vs broadcast) is the decision that matters, and the skill carries it.
+Server→client push, no polling: `events.publish(channels, data)` from any method/cron/webhook reaches connected clients instantly; `events.grant(channels)` in a method (after your auth checks) mints the subscribe token the frontend's `events.connect` consumes. This is how live dashboards, notifications, chat, and multi-tab sync work — whenever you're about to write a frontend polling loop against your own backend, reach for this instead. Load the `realtimeEvents` skill before designing with it: channel shape (per-user fan-out vs broadcast) is the decision that matters, and the skill carries it.

package/dist/prompt/static/instructions.md

@@ -38,7 +38,7 @@ You will occasionally receive automated messages prefixed with `@@automated_mess
 
 ## Style
 - Your messages are rendered as markdown. Use formatting (headers, bold, lists, code blocks) when it helps readability. You can include images using `![alt](url)` — use this to show the user screenshots, generated images, or other visual references inline in your messages.
-- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links: `[label](suggest:message sent on click)`. The label renders as a tappable chip and should be a few words — chip-sized, not sentence-sized. The `suggest:` payload can be longer; that's what gets sent as the user's next message when clicked. A run of links on its own line, or at the end of a line, is lifted out of your message and rendered as chips beneath it; a link written mid-sentence keeps its label in the sentence and offers the chip as well. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
+- When offering suggestions or options the user might want to quickly select in a conversation, format them as clickable suggestion links, usually a run of them on their own line: `[Rework it](suggest:Rework the cursor interpolation to use damped smoothing) · [Prototype both](suggest:Prototype the current and damped versions side by side) · [Leave it](suggest:Leave the latency work for now)`. The label renders as a tappable chip and should be a few words — chip-sized, not sentence-sized. The `suggest:` payload can be longer; that's what gets sent as the user's next message when clicked. A run of links on its own line, or at the end of a line, is lifted out of your message and rendered as chips beneath it; a link written mid-sentence keeps its label in the sentence and offers the chip as well. Use these liberally: when brainstorming, offering directions, listing options, or any time you're asking a question the user could answer with a quick tap. When explicitly gathering information from the user, however, always use the `promptUser` tool instead.
 - When pointing the user to a specific page in their running app, format the link as `[label](preview:/path)` — clicking it navigates the live preview there. The payload is a path-relative URL (just `/...`, with optional query/hash); for external URLs, use a plain markdown link.
 - Keep language accessible. Describe what the app *does*, not how it's implemented, unless the user demonstrates technical fluency.
 - Always use full paths relative to the project root when mentioning files (`dist/interfaces/web/src/App.tsx`, not `App.tsx`). Paths will be rendered as clickable links for the user.

package/package.json

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