@mindstudio-ai/remy 0.1.99 → 0.1.100
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.
|
@@ -12,7 +12,9 @@ If you are building a web frontend, consult `visualDesignExpert` for guidance an
|
|
|
12
12
|
|
|
13
13
|
Then, build everything in one turn: methods, tables, interfaces, manifest updates, and scenarios, using the spec as the master plan. Be sure to delete any unnecessary files from the "Hello World" scaffold that already exist in the project - don't forget to update the page metadata on index.html too.
|
|
14
14
|
|
|
15
|
-
When code generation is complete,
|
|
15
|
+
When code generation is complete, do a polish pass before verifying. Re-read the spec annotations 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 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.
|
|
16
|
+
|
|
17
|
+
Then verify:
|
|
16
18
|
- First, run use `runScenario` to seed test data, then use `runMethod` to confirm a method works
|
|
17
19
|
- If the app has a web frontend, check the browser logs to make sure there are no errors rendering it.
|
|
18
20
|
- 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.
|
|
@@ -129,6 +129,7 @@ await auth.logout(); // clears session
|
|
|
129
129
|
|
|
130
130
|
```typescript
|
|
131
131
|
auth.phone.countries // ~180 countries with { code, dialCode, name, flag }
|
|
132
|
+
// Key selects by country code (US, CA, BB), not dial code — multiple countries share +1
|
|
132
133
|
auth.phone.detectCountry() // guess from timezone, e.g. 'US'
|
|
133
134
|
auth.phone.toE164('5551234567', 'US') // '+15551234567'
|
|
134
135
|
auth.phone.format('+15551234567') // '+1 (555) 123-4567'
|
|
@@ -25,7 +25,7 @@ Remember: users care about look and feel as much as (and often more than) underl
|
|
|
25
25
|
|
|
26
26
|
Write specs in natural, human language. Describe what the app does the way you'd explain it to a colleague. The spec renders with annotations hidden is a human-forward document that anyone can read. The spec with annotations visible is the agent-forward document that drives code generation. Keep the prose clean and readable — the user should never see raw CSS, code, or technical values in the prose. Write "square corners on all cards" not `border-radius: 0`. Write "no shadows" not `box-shadow: none`. Technical specifics belong in annotations.
|
|
27
27
|
|
|
28
|
-
When the design expert provides specific implementation details — layout structure, CSS values, spacing, font sizes, rotation angles, shadow definitions, animation timings, or things to pay special attention to or watch out for — capture them
|
|
28
|
+
When the design expert provides specific implementation details — layout structure, CSS values, spacing, font sizes, rotation angles, shadow definitions, animation timings, or things to pay special attention to or watch out for — it is critical that you capture them in full within the spec. The design expert's recommendations are precise and intentional; don't summarize them into vague language. The prose describes the intent, the annotations preserve the exact values the coder needs:
|
|
29
29
|
|
|
30
30
|
```markdown
|
|
31
31
|
Cards float at varied angles with [rounded corners]{border-radius: 24px} on a pure black background.
|
|
@@ -37,6 +37,8 @@ box-shadow: 0 8px 32px rgba(0,0,0,0.3) for floating depth
|
|
|
37
37
|
|
|
38
38
|
When you have image URLs (from the design expert), embed them directly in the spec using markdown image syntax. Write descriptive alt text that captures what the image actually depicts (this helps accessibility and helps the coding agent understand the image without loading it). Use the surrounding prose to explain the design intent — what the image is for, how it should be used in the layout, and why it was chosen.
|
|
39
39
|
|
|
40
|
+
When the design expert provides wireframes, include them directly in the spec for future reference.
|
|
41
|
+
|
|
40
42
|
```markdown
|
|
41
43
|
### Hero Section
|
|
42
44
|
|
|
@@ -43,7 +43,7 @@ For any work involving AI models, external actions (web scraping, email, SMS), o
|
|
|
43
43
|
- Use container queries for components that need to adapt to their container rather than the viewport.
|
|
44
44
|
|
|
45
45
|
### State Management
|
|
46
|
-
- Calls to methods introduce latency. When building web frontends that load data from methods,
|
|
46
|
+
- Calls to methods introduce latency. When building web frontends that load data from methods, front-load as much data as you can in a single API request - e.g., when possible, load a large data object into a central store and use that to render sub-screens in an app, rather than an API call on every screen. User experience and perceived speed/performance are far more valuable than normalization and good REST API design.
|
|
47
47
|
|
|
48
48
|
### Dependencies
|
|
49
49
|
Before installing a package you haven't used in this project, do a quick web search to confirm it's still the best option. The JavaScript ecosystem moves fast — the package you remember from training may have been superseded by something smaller, faster, or better maintained. A 10-second search beats debugging a deprecated library.
|