@mindstudio-ai/remy 0.1.50 → 0.1.51
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/automatedActions/buildFromInitialSpec.md +19 -0
- package/dist/automatedActions/buildFromRoadmap.md +15 -0
- package/dist/automatedActions/publish.md +16 -0
- package/dist/automatedActions/reviseFromAnnotatedImage.md +5 -0
- package/dist/automatedActions/sync.md +23 -0
- package/dist/headless.js +11 -1
- package/dist/index.js +11 -1
- package/package.json +1 -1
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
trigger: buildFromInitialSpec
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
This is an automated action triggered by the user pressing "Build" in the editor after reviewing the spec.
|
|
6
|
+
|
|
7
|
+
The user has reviewed the spec and is ready to build.
|
|
8
|
+
|
|
9
|
+
Think about your approach and then get a quick sanity check from `codeSanityCheck` to make sure you aren't missing anything.
|
|
10
|
+
|
|
11
|
+
Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan.
|
|
12
|
+
|
|
13
|
+
When code generation is complete, verify your work:
|
|
14
|
+
- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works
|
|
15
|
+
- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
|
|
16
|
+
- Ask the `visualDesignExpert` to take a screenshot and verity that the visual design looks correct. Fix any issues it flags - we want the user's first time seeing the finished product to truly wow them.
|
|
17
|
+
- Finally, use `runAutomatedBrowserTest` to smoke-test the main UI flow. The dev database is a disposable snapshot, so don't worry about being destructive. Fix any errors before finishing.
|
|
18
|
+
|
|
19
|
+
When everything is working, use `productVision` to mark the MVP roadmap item as done, then call `setProjectOnboardingState({ state: "onboardingFinished" })`.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
---
|
|
2
|
+
trigger: buildFromRoadmap
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
This is an automated action triggered by the user pressing "Build Now" on the roadmap item {{path}}
|
|
6
|
+
|
|
7
|
+
First, review the specific item and think about how it fits with the existing spec and the existing codebase.
|
|
8
|
+
|
|
9
|
+
Then, ask the user clarifying questions about anything that is ambiguous or requires additional input. Consult the team for any design work, architecture review, or SDK guidance - even if they're just quick questions (that's what the team is there for - they want to help and feel valuable!).
|
|
10
|
+
|
|
11
|
+
Then, put together a plan to build out the feature. Present the plan to the user for their approval.
|
|
12
|
+
|
|
13
|
+
When they've approved the plan, be sure to update the spec first - remember, the spec is the source of truth about the product. Then, build everything in one turn, using the spec as the master plan.
|
|
14
|
+
|
|
15
|
+
When you're finished, verify your work, then tell`productVision` what was done so it can update the roadmap to reflect the progress. Give the user a summary of what was done.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
trigger: publish
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
This is an automated action triggered by the user pressing "Publish" in the editor.
|
|
6
|
+
|
|
7
|
+
The user wants to deploy their app. Pushing to the `main` branch triggers a production deploy.
|
|
8
|
+
|
|
9
|
+
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.
|
|
10
|
+
|
|
11
|
+
If approved:
|
|
12
|
+
- Stage and commit any uncommitted changes with a clean, descriptive commit message
|
|
13
|
+
- Push to main
|
|
14
|
+
- Let the user know their app is deploying
|
|
15
|
+
|
|
16
|
+
If dismissed, acknowledge and do nothing.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
trigger: sync
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
This is an automated action triggered by the user pressing "Sync" in the editor.
|
|
6
|
+
|
|
7
|
+
The user has manually edited files since the last sync. The `refs/sync-point` git ref marks the last known-good sync state. It's created using a temporary git index that captures the full working tree (including unstaged changes) as a tree object — so it represents exactly what the files looked like at sync time, not just what was committed.
|
|
8
|
+
|
|
9
|
+
To see what the user changed, run: `git diff refs/sync-point -- src/ dist/`
|
|
10
|
+
|
|
11
|
+
This compares the sync-point tree against the current working tree. Do not add `HEAD` or any other ref — the command as written diffs directly against the working tree, which is what you want.
|
|
12
|
+
|
|
13
|
+
In the diff output: lines prefixed with `-` are what was in the file at last sync. Lines prefixed with `+` are the user's current edits. Sync should bring the other side in line with the `+` side.
|
|
14
|
+
|
|
15
|
+
Analyze the changes and write a sync plan with `presentSyncPlan` — a clear markdown summary of what changed and what you intend to update. Write it for a human: describe changes in plain language ("renamed the greeting field", "added a note about error handling"), not as a list of file paths and code diffs. Reference specific code or file paths only when it helps clarity. The user will review and approve before you make changes.
|
|
16
|
+
|
|
17
|
+
If approved:
|
|
18
|
+
- If spec files (`src/`) changed, update the corresponding code in `dist/` to match
|
|
19
|
+
- If code files (`dist/`) changed, update the corresponding spec in `src/` to match
|
|
20
|
+
- If both changed, reconcile — spec is the source of truth for intent, but respect code changes that add implementation detail
|
|
21
|
+
- When all files are synced, call `clearSyncStatus`
|
|
22
|
+
|
|
23
|
+
If dismissed, acknowledge and do nothing.
|
package/dist/headless.js
CHANGED
|
@@ -5280,7 +5280,17 @@ ${xmlParts}
|
|
|
5280
5280
|
);
|
|
5281
5281
|
}
|
|
5282
5282
|
let userMessage = parsed.text ?? "";
|
|
5283
|
-
|
|
5283
|
+
let resolved = null;
|
|
5284
|
+
try {
|
|
5285
|
+
resolved = resolveAction(userMessage);
|
|
5286
|
+
} catch (err) {
|
|
5287
|
+
emit(
|
|
5288
|
+
"completed",
|
|
5289
|
+
{ success: false, error: err.message || "Failed to resolve action" },
|
|
5290
|
+
requestId
|
|
5291
|
+
);
|
|
5292
|
+
return;
|
|
5293
|
+
}
|
|
5284
5294
|
if (resolved !== null) {
|
|
5285
5295
|
userMessage = resolved;
|
|
5286
5296
|
}
|
package/dist/index.js
CHANGED
|
@@ -5876,7 +5876,17 @@ ${xmlParts}
|
|
|
5876
5876
|
);
|
|
5877
5877
|
}
|
|
5878
5878
|
let userMessage = parsed.text ?? "";
|
|
5879
|
-
|
|
5879
|
+
let resolved = null;
|
|
5880
|
+
try {
|
|
5881
|
+
resolved = resolveAction(userMessage);
|
|
5882
|
+
} catch (err) {
|
|
5883
|
+
emit(
|
|
5884
|
+
"completed",
|
|
5885
|
+
{ success: false, error: err.message || "Failed to resolve action" },
|
|
5886
|
+
requestId
|
|
5887
|
+
);
|
|
5888
|
+
return;
|
|
5889
|
+
}
|
|
5880
5890
|
if (resolved !== null) {
|
|
5881
5891
|
userMessage = resolved;
|
|
5882
5892
|
}
|