spec-agent 2.0.6 → 2.0.7

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.

Potentially problematic release.


This version of spec-agent might be problematic. Click here for more details.

@@ -29,7 +29,7 @@ When user intent is about running `spec-agent`, apply this workflow:
29
29
 
30
30
  4. Keep responses action-oriented:
31
31
  - Provide exact commands.
32
- - Explain expected output paths (`output/handoff`, `output/execution`).
32
+ - Explain expected output paths (`output/handoff`, `output/execution`, `output/prototypes`, `output/prototype_index.json`).
33
33
  - Avoid claiming completion without command evidence.
34
34
  - Prefer invoking `spec-agent-product-dev-agent` when user asks requirement-to-development end-to-end.
35
35
 
@@ -44,3 +44,8 @@ When user intent is about running `spec-agent`, apply this workflow:
44
44
  - Frontend-only implementation by default.
45
45
  - Prioritize pages, routes, UI states, forms, interactions, and mock data.
46
46
  - Backend/API/database tasks are marked as "deferred" and not executed in current round unless user explicitly requests backend implementation.
47
+
48
+ 7. Prototype-aware implementation policy:
49
+ - If `output/prototype_index.json` exists, prioritize prototype-linked tasks.
50
+ - For task execution, first read `output/handoff/tasks/<TASK_ID>.md` and use "Prototype References" as primary UI evidence.
51
+ - Treat "Prototype Candidates" as optional references that need human confirmation.
@@ -87,6 +87,8 @@ Inspect:
87
87
 
88
88
  - `output/execution/inbox/*.md`
89
89
  - `output/execution/execution_report.json`
90
+ - `output/prototype_index.json` (if exists)
91
+ - `output/prototypes/*` (if exists)
90
92
 
91
93
  Return a concise batch summary:
92
94
 
@@ -94,6 +96,7 @@ Return a concise batch summary:
94
96
  - pending/running/succeeded/failed/blocked counts
95
97
  - which task to execute first
96
98
  - frontend-only kept tasks vs deferred backend tasks
99
+ - high-confidence prototype references per task
97
100
 
98
101
  ### Step 4: Collect outcomes
99
102
 
@@ -55,6 +55,12 @@ spec-agent round --workspace ./output --input ./docs --target cursor --max-paral
55
55
 
56
56
  `pipeline` manual-first; `round` auto-run when possible.
57
57
 
58
+ If requirement docs include prototype images, verify these artifacts after `pipeline`:
59
+
60
+ - `output/prototypes/*`
61
+ - `output/prototype_index.json`
62
+ - `output/prototype_index.md`
63
+
58
64
  ## Step 3: Multi-Agent Execution Bootstrap (Optional)
59
65
 
60
66
  ```bash
@@ -90,3 +96,4 @@ spec-agent execute --workspace ./output --fail T003 --error "compile failed"
90
96
  - Do not skip verification commands.
91
97
  - Use `spec-agent round` as the primary one-round action.
92
98
  - `handoff` / `round` can be auto-run; `pipeline` remains manual-first.
99
+ - When `prototype_index.json` exists, remind user to use task-level prototype references in `output/handoff/tasks/*.md`.
@@ -84,9 +84,17 @@ Read:
84
84
 
85
85
  - `output/execution/inbox/*.md`
86
86
  - `output/orchestrator_context.json`
87
+ - `output/prototype_index.json` (if exists)
88
+ - `output/prototypes/*` (if exists)
87
89
 
88
90
  Then guide user to execute current inbox tasks in coding sessions, with frontend-first filtering.
89
91
 
92
+ Prototype-first task guidance:
93
+
94
+ - In each `output/handoff/tasks/<TASK_ID>.md`, use `Prototype References` as the main UI evidence.
95
+ - `Prototype Candidates (medium/low)` should be treated as optional, require human confirmation.
96
+ - If a task has no high-confidence prototype, ask for manual prototype confirmation before heavy UI coding.
97
+
90
98
  Frontend-first task filter:
91
99
 
92
100
  - Keep: 页面、路由、组件、表单、校验、状态管理、交互细节、UI 可用性。