mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-21 20:28:24 +08:00
fix: plan-design-review agent guardrails for feedback loop
Four fixes to prevent agents from reinventing the feedback loop badly: 1. Sequential generate rule: explicit instruction that $D generate calls must run one at a time (API rate-limits concurrent image generation). 2. No-AskUserQuestion-for-feedback rule: agent reads feedback.json instead of re-asking what the user picked. 3. Remove file:// references: $B goto file:// was always rejected by url-validation.ts. The --serve flag handles everything. 4. Remove $B eval polling reference: no longer needed with HTTP POST. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -564,8 +564,6 @@ planning phase. Generating mockups during planning is the whole point.
|
||||
Allowed commands under this exception:
|
||||
- `mkdir -p ~/.gstack/projects/$SLUG/designs/...`
|
||||
- `$D generate`, `$D variants`, `$D compare`, `$D iterate`, `$D evolve`, `$D check`
|
||||
- `$B goto file:///` (to view comparison board in browser)
|
||||
- `$B eval document.getElementById(...)` (to read user feedback from comparison board)
|
||||
- `open` (fallback for viewing boards when `$B` is not available)
|
||||
|
||||
First, set up the output directory. Name it after the screen/feature being designed and today's date:
|
||||
@@ -579,6 +577,8 @@ echo "DESIGN_DIR: $_DESIGN_DIR"
|
||||
|
||||
Replace `<screen-name>` with a descriptive kebab-case name (e.g., `homepage-variants`, `settings-page`, `onboarding-flow`).
|
||||
|
||||
**Generate mockups ONE AT A TIME. Do not parallelize `$D generate` calls.** The underlying API rate-limits concurrent image generation. When 3 generates run in parallel, 1 succeeds and 2 get aborted.
|
||||
|
||||
For each UI screen/section in scope, construct a design brief from the plan's description (and DESIGN.md if present) and generate variants:
|
||||
|
||||
```bash
|
||||
@@ -684,6 +684,8 @@ Use AskUserQuestion to verify before proceeding.
|
||||
echo '{"approved_variant":"<V>","feedback":"<FB>","date":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","screen":"<SCREEN>","branch":"'$(git branch --show-current 2>/dev/null)'"}' > "$_DESIGN_DIR/approved.json"
|
||||
```
|
||||
|
||||
**Do NOT use AskUserQuestion to ask which variant the user picked.** Read `feedback.json` — it already contains their preferred variant, ratings, comments, and overall feedback. Only use AskUserQuestion to confirm you understood the feedback correctly, never to re-ask what they chose.
|
||||
|
||||
Note which direction was approved. This becomes the visual reference for all subsequent review passes.
|
||||
|
||||
**Multiple variants/screens:** If the user asked for multiple variants (e.g., "5 versions of the homepage"), generate ALL as separate variant sets with their own comparison boards. Each screen/variant set gets its own subdirectory under `designs/`. Complete all mockup generation and user selection before starting review passes.
|
||||
|
||||
@@ -176,8 +176,6 @@ planning phase. Generating mockups during planning is the whole point.
|
||||
Allowed commands under this exception:
|
||||
- `mkdir -p ~/.gstack/projects/$SLUG/designs/...`
|
||||
- `$D generate`, `$D variants`, `$D compare`, `$D iterate`, `$D evolve`, `$D check`
|
||||
- `$B goto file:///` (to view comparison board in browser)
|
||||
- `$B eval document.getElementById(...)` (to read user feedback from comparison board)
|
||||
- `open` (fallback for viewing boards when `$B` is not available)
|
||||
|
||||
First, set up the output directory. Name it after the screen/feature being designed and today's date:
|
||||
@@ -191,6 +189,8 @@ echo "DESIGN_DIR: $_DESIGN_DIR"
|
||||
|
||||
Replace `<screen-name>` with a descriptive kebab-case name (e.g., `homepage-variants`, `settings-page`, `onboarding-flow`).
|
||||
|
||||
**Generate mockups ONE AT A TIME. Do not parallelize `$D generate` calls.** The underlying API rate-limits concurrent image generation. When 3 generates run in parallel, 1 succeeds and 2 get aborted.
|
||||
|
||||
For each UI screen/section in scope, construct a design brief from the plan's description (and DESIGN.md if present) and generate variants:
|
||||
|
||||
```bash
|
||||
@@ -213,6 +213,8 @@ rate the others, remix elements, and click Submit when you're done."
|
||||
|
||||
{{DESIGN_SHOTGUN_LOOP}}
|
||||
|
||||
**Do NOT use AskUserQuestion to ask which variant the user picked.** Read `feedback.json` — it already contains their preferred variant, ratings, comments, and overall feedback. Only use AskUserQuestion to confirm you understood the feedback correctly, never to re-ask what they chose.
|
||||
|
||||
Note which direction was approved. This becomes the visual reference for all subsequent review passes.
|
||||
|
||||
**Multiple variants/screens:** If the user asked for multiple variants (e.g., "5 versions of the homepage"), generate ALL as separate variant sets with their own comparison boards. Each screen/variant set gets its own subdirectory under `designs/`. Complete all mockup generation and user selection before starting review passes.
|
||||
|
||||
Reference in New Issue
Block a user