fix: ChatBubble crash and DeepSeek API compatibility
- Fix ChatBubble to handle non-string content with String() wrapper - Fix API route to use generateText for non-streaming requests - Add @ai-sdk/openai-compatible for non-OpenAI providers (DeepSeek, etc.) - Use Chat Completions API instead of Responses API for compatible providers - Update ChatBubble tests and fix component exports to kebab-case - Remove stale PascalCase ChatBubble.tsx file
This commit is contained in:
Max
@@ -0,0 +1,173 @@
|
||||
---
|
||||
name: 'step-04-review'
|
||||
description: 'Review and finalize the tech-spec'
|
||||
|
||||
workflow_path: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec'
|
||||
wipFile: '{implementation_artifacts}/tech-spec-wip.md'
|
||||
---
|
||||
|
||||
# Step 4: Review & Finalize
|
||||
|
||||
**Progress: Step 4 of 4** - Final Step
|
||||
|
||||
## RULES:
|
||||
|
||||
- MUST NOT skip steps.
|
||||
- MUST NOT optimize sequence.
|
||||
- MUST follow exact instructions.
|
||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||
|
||||
## CONTEXT:
|
||||
|
||||
- Requires `{wipFile}` from Step 3.
|
||||
- MUST present COMPLETE spec content. Iterate until user is satisfied.
|
||||
- **Criteria**: The spec MUST meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
|
||||
|
||||
## SEQUENCE OF INSTRUCTIONS
|
||||
|
||||
### 1. Load and Present Complete Spec
|
||||
|
||||
**Read `{wipFile}` completely and extract `slug` from frontmatter for later use.**
|
||||
|
||||
**Present to user:**
|
||||
|
||||
"Here's your complete tech-spec. Please review:"
|
||||
|
||||
[Display the complete spec content - all sections]
|
||||
|
||||
"**Quick Summary:**
|
||||
|
||||
- {task_count} tasks to implement
|
||||
- {ac_count} acceptance criteria to verify
|
||||
- {files_count} files to modify
|
||||
|
||||
Does this capture your intent? Any changes needed?"
|
||||
|
||||
### 2. Handle Review Feedback
|
||||
|
||||
a) **If user requests changes:**
|
||||
|
||||
- Make the requested edits to `{wipFile}`
|
||||
- Re-present the affected sections
|
||||
- Ask if there are more changes
|
||||
- Loop until user is satisfied
|
||||
|
||||
b) **If the spec does NOT meet the "Ready for Development" standard:**
|
||||
|
||||
- Point out the missing/weak sections (e.g., non-actionable tasks, missing ACs).
|
||||
- Propose specific improvements to reach the standard.
|
||||
- Make the edits once the user agrees.
|
||||
|
||||
c) **If user has questions:**
|
||||
|
||||
- Answer questions about the spec
|
||||
- Clarify any confusing sections
|
||||
- Make clarifying edits if needed
|
||||
|
||||
### 3. Finalize the Spec
|
||||
|
||||
**When user confirms the spec is good AND it meets the "Ready for Development" standard:**
|
||||
|
||||
a) Update `{wipFile}` frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
# ... existing values ...
|
||||
status: 'ready-for-dev'
|
||||
stepsCompleted: [1, 2, 3, 4]
|
||||
---
|
||||
```
|
||||
|
||||
b) **Rename WIP file to final filename:**
|
||||
- Using the `slug` extracted in Section 1
|
||||
- Rename `{wipFile}` → `{implementation_artifacts}/tech-spec-{slug}.md`
|
||||
- Store this as `finalFile` for use in menus below
|
||||
|
||||
### 4. Present Final Menu
|
||||
|
||||
a) **Display completion message and menu:**
|
||||
|
||||
```
|
||||
**Tech-Spec Complete!**
|
||||
|
||||
Saved to: {finalFile}
|
||||
|
||||
---
|
||||
|
||||
**Next Steps:**
|
||||
|
||||
[a] Advanced Elicitation - refine further
|
||||
[r] Adversarial Review - critique of the spec (highly recommended)
|
||||
[b] Begin Development - start implementing now (not recommended)
|
||||
[d] Done - exit workflow
|
||||
[p] Party Mode - get expert feedback before dev
|
||||
|
||||
---
|
||||
|
||||
Once you are fully satisfied with the spec (ideally after **Adversarial Review** and maybe a few rounds of **Advanced Elicitation**), it is recommended to run implementation in a FRESH CONTEXT for best results.
|
||||
|
||||
Copy this prompt to start dev:
|
||||
|
||||
\`\`\`
|
||||
quick-dev {finalFile}
|
||||
\`\`\`
|
||||
|
||||
This ensures the dev agent has clean context focused solely on implementation.
|
||||
```
|
||||
|
||||
b) **HALT and wait for user selection.**
|
||||
|
||||
#### Menu Handling:
|
||||
|
||||
- **[a]**: Load and execute `{advanced_elicitation}`, then return here and redisplay menu
|
||||
- **[b]**: Load and execute `{quick_dev_workflow}` with the final spec file (warn: fresh context is better)
|
||||
- **[d]**: Exit workflow - display final confirmation and path to spec
|
||||
- **[p]**: Load and execute `{party_mode_exec}`, then return here and redisplay menu
|
||||
- **[r]**: Execute Adversarial Review:
|
||||
1. **Invoke Adversarial Review Task**:
|
||||
> With `{finalFile}` constructed, invoke the review task. If possible, use information asymmetry: run this task, and only it, in a separate subagent or process with read access to the project, but no context except the `{finalFile}`.
|
||||
<invoke-task>Review {finalFile} using {project-root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
|
||||
> **Platform fallback:** If task invocation not available, load the task file and execute its instructions inline, passing `{finalFile}` as the content.
|
||||
> The task should: review `{finalFile}` and return a list of findings.
|
||||
|
||||
2. **Process Findings**:
|
||||
> Capture the findings from the task output.
|
||||
> **If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
|
||||
> Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
|
||||
> DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
|
||||
> Order findings by severity.
|
||||
> Number the ordered findings (F1, F2, F3, etc.).
|
||||
> If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
|
||||
|
||||
3. Return here and redisplay menu.
|
||||
|
||||
### 5. Exit Workflow
|
||||
|
||||
**When user selects [d]:**
|
||||
|
||||
"**All done!** Your tech-spec is ready at:
|
||||
|
||||
`{finalFile}`
|
||||
|
||||
When you're ready to implement, run:
|
||||
|
||||
```
|
||||
quick-dev {finalFile}
|
||||
```
|
||||
|
||||
Ship it!"
|
||||
|
||||
---
|
||||
|
||||
## REQUIRED OUTPUTS:
|
||||
|
||||
- MUST update status to 'ready-for-dev'.
|
||||
- MUST rename file to `tech-spec-{slug}.md`.
|
||||
- MUST provide clear next-step guidance and recommend fresh context for dev.
|
||||
|
||||
## VERIFICATION CHECKLIST:
|
||||
|
||||
- [ ] Complete spec presented for review.
|
||||
- [ ] Requested changes implemented.
|
||||
- [ ] Spec verified against **READY FOR DEVELOPMENT** standard.
|
||||
- [ ] `stepsCompleted: [1, 2, 3, 4]` set and file renamed.
|
||||
Reference in New Issue
Block a user