@mindstudio-ai/remy 0.1.211 → 0.1.213

package/dist/automatedActions/publish.md

@@ -9,7 +9,7 @@ The user wants to deploy their app. Pushing to the `main` branch triggers a prod
 Review the current state of the working tree — what has changed since the last commit, what's been committed since the last push, and the overall shape of recent work. Write a user-friendly changelog with `presentPublishPlan` — summarize what changed in plain language ("added vendor approval workflow", "fixed invoice totals", "updated the dashboard layout"). Reference specific code or file paths only when it helps clarity. This is what the user will see before deploying.
 
 If approved:
-- Stage and commit any uncommitted changes with a clean, descriptive commit message
+- Stage and commit any uncommitted changes with a clean, descriptive commit message. If the committed work resolves any open issues (`mindstudio-prod issues`), reference them in the commit message with a closing keyword — `fixes #42`, `closes #7` — so the deploy closes them automatically once it goes live.
 - Push to main
 - Use `mindstudio-prod releases status --wait` to poll the build until it completes. Let the user know it's deploying, then report back when it's live.
 - Once deployed, offer to help with next steps. This includes technical steps likesetting up a custom domain (`mindstudio-prod domains`), checking for errors (`mindstudio-prod requests stats`), seeding production data (`mindstudio-prod db`), managing env vars/secrets, or anything else they need for launch. It also includes going above and beyond and helping holistically. If it's the initial deploy, offer to help create collateral to announce the launch (e.g., an image for sharing on social media, text copy for a post, etc); if it's a meaningful incremental update, an annoucement post or something similar - go above and beyond here to help the user see that you care about the product from end-to-end, not just writing code! They will be appreciative, grateful, and pleased with your creativity here. Refer to the design guidance in the spec for how to talk about the product, and consider consulting the design expert to generate images or other marketing collateral.

package/dist/headless.js

@@ -7308,14 +7308,14 @@ function buildUploadHeader(results) {
   }
   if (succeeded.length === 1) {
     const r = succeeded[0];
-    const parts = [`[Uploaded file: ${r.localPath} (CDN: ${r.remoteUrl})`];
+    const parts = [`[Uploaded file: ${r.localPath}`];
     if (r.extractedTextPath) {
       parts.push(`extracted text: ${r.extractedTextPath}`);
     }
     return parts.join(" \u2014 ") + "]";
   }
   const lines = succeeded.map((r) => {
-    const parts = [`- ${r.localPath} (CDN: ${r.remoteUrl})`];
+    const parts = [`- ${r.localPath}`];
     if (r.extractedTextPath) {
       parts.push(`  extracted text: ${r.extractedTextPath}`);
     }

package/dist/index.js

@@ -8081,14 +8081,14 @@ function buildUploadHeader(results) {
   }
   if (succeeded.length === 1) {
     const r = succeeded[0];
-    const parts = [`[Uploaded file: ${r.localPath} (CDN: ${r.remoteUrl})`];
+    const parts = [`[Uploaded file: ${r.localPath}`];
     if (r.extractedTextPath) {
       parts.push(`extracted text: ${r.extractedTextPath}`);
     }
     return parts.join(" \u2014 ") + "]";
   }
   const lines = succeeded.map((r) => {
-    const parts = [`- ${r.localPath} (CDN: ${r.remoteUrl})`];
+    const parts = [`- ${r.localPath}`];
     if (r.extractedTextPath) {
       parts.push(`  extracted text: ${r.extractedTextPath}`);
     }

package/dist/prompt/static/coding.md

@@ -36,6 +36,8 @@ For counting visitor or funnel activity (signups, page interactions, checkout co
 
 When writing `db` filter predicates that reference outer-scope values (`input.*`, `auth.*`, foreign keys collected earlier, etc.), use the bindings form so the filter compiles to SQL — see `tables.md` "Filter Predicates" for patterns and the inline-comment convention.
 
+The SDK also includes a `reportIssue` method that can file bug reports on the app's platform-level issue tracker, if the user wants to build something to allow their users to report bugs in their app.
+
 ### Auth
 - Not every app needs auth, and even for apps that do need auth, not every screen needs auth. Think intentionally about places where auth is required. Don't make auth be the first thing a user sees - that's jarring. Only show auth at intuitive and natural moments in the user's journey - be thoughtful about how to implement auth in the UI.
 - Frontend interfaces are always untrusted. Always enforce auth in backend methods. Use frontend auth and role information as a hint to conditionally show/hide UI to make the experience pleasant and seamless for users depending on their state, but remember to always use backend methods for gating data that is conditional on auth.
@@ -79,6 +81,6 @@ You have access to the `mindstudio` CLI, which exposes every SDK action as a com
 ### Production App Management
 You have access to `mindstudio-prod`, a CLI for managing the user's production app. Use it via your bash tool. All output is JSON. Run `mindstudio-prod --help` or `mindstudio-prod <command> --help` to discover usage and available options.
 
-Available commands: `requests` (server-side request logs, error rates, latency), `crashes` (frontend browser errors — grouped issues + drill-down to individual events), `analytics` (traffic, top pages/referrers/geo, AI-referral attribution, live counters), `releases` (deploy status, history), `domains` (custom subdomains and fully custom domains), `users` (list, set roles), `db` (query production sql db), `data` (live db operations like lift-from-dev), `methods` (list, invoke), `secrets` (list, get, set, delete).
+Available commands: `requests` (server-side request logs, error rates, latency), `crashes` (frontend browser errors — grouped issues + drill-down to individual events), `analytics` (traffic, top pages/referrers/geo, AI-referral attribution, live counters), `releases` (deploy status, history), `domains` (custom subdomains and fully custom domains), `users` (list, set roles), `db` (query production sql db), `data` (live db operations like lift-from-dev), `methods` (list, invoke), `secrets` (list, get, set, delete), `issues` (reference and manage externally-reported bugs and issues. Do not use this to track work you are doing with the user - only read from it and resolve issues if the user asks for help fixing a bug from the issues tracker).
 
 Use when the user asks about production behavior (server errors via `requests`, browser crashes via `crashes`, traffic/engagement via `analytics`), wants to manage their live app (domains, users, roles), needs to seed or query production data, or wants to check release status.

package/package.json

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