ai-workflow-init 7.1.0 → 7.2.1
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/.claude/CLAUDE.md +1 -1
- package/.claude/agents/requirement-sa.md +39 -6
- package/.claude/agents/spec-review.md +180 -0
- package/.claude/commands/clarify-requirements.md +76 -16
- package/cli.js +0 -13
- package/docs/ai/requirements/req-template.md +41 -6
- package/docs/ai/requirements/templates/sa-template.md +15 -7
- package/package.json +1 -1
package/.claude/CLAUDE.md
CHANGED
|
@@ -27,7 +27,7 @@
|
|
|
27
27
|
|
|
28
28
|
### 2. Deep Understanding
|
|
29
29
|
- If unclear about requirements, edge cases, or expected behavior → **Ask first**
|
|
30
|
-
-
|
|
30
|
+
- Batch related questions into a single block (avoid asking one at a time)
|
|
31
31
|
- Never assume or guess - clarification prevents wasted effort
|
|
32
32
|
- Key questions:
|
|
33
33
|
- "What should happen when X occurs?"
|
|
@@ -137,7 +137,35 @@ Propose specific technologies:
|
|
|
137
137
|
|
|
138
138
|
---
|
|
139
139
|
|
|
140
|
-
## Step 5:
|
|
140
|
+
## Step 5: Technical Edge Cases
|
|
141
|
+
|
|
142
|
+
**Identify technical edge cases that BA may not cover:**
|
|
143
|
+
|
|
144
|
+
| Category | What to Check |
|
|
145
|
+
|----------|---------------|
|
|
146
|
+
| **Concurrency** | Multiple users editing same resource, race conditions |
|
|
147
|
+
| **Data boundaries** | Empty states, max limits, overflow, special characters |
|
|
148
|
+
| **Network** | Timeouts, retries, offline handling, partial failures |
|
|
149
|
+
| **Security** | Input sanitization, SQL injection, XSS, CSRF, auth bypass |
|
|
150
|
+
| **Performance** | Large datasets, N+1 queries, memory leaks, slow queries |
|
|
151
|
+
| **Integration** | API downtime, rate limits, schema changes, version mismatches |
|
|
152
|
+
| **State** | Stale data, cache invalidation, session expiry |
|
|
153
|
+
|
|
154
|
+
**Output format:**
|
|
155
|
+
|
|
156
|
+
```markdown
|
|
157
|
+
## Technical Edge Cases
|
|
158
|
+
|
|
159
|
+
| ID | Category | Edge Case | Expected Behavior | Priority |
|
|
160
|
+
|----|----------|-----------|-------------------|----------|
|
|
161
|
+
| TE-01 | Concurrency | Two users edit same record | Last-write-wins / Optimistic locking | Must |
|
|
162
|
+
| TE-02 | Data | Empty dataset on first load | Show empty state with CTA | Should |
|
|
163
|
+
| TE-03 | Network | API timeout after 30s | Show retry option, preserve user input | Must |
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
## Step 6: Risk Assessment
|
|
141
169
|
|
|
142
170
|
### Technical Risks
|
|
143
171
|
|
|
@@ -154,7 +182,7 @@ Propose specific technologies:
|
|
|
154
182
|
|
|
155
183
|
---
|
|
156
184
|
|
|
157
|
-
## Step
|
|
185
|
+
## Step 7: Implementation Guidance
|
|
158
186
|
|
|
159
187
|
### Suggested Phases
|
|
160
188
|
|
|
@@ -189,7 +217,7 @@ Propose specific technologies:
|
|
|
189
217
|
|
|
190
218
|
---
|
|
191
219
|
|
|
192
|
-
## Step
|
|
220
|
+
## Step 8: Generate SA Document
|
|
193
221
|
|
|
194
222
|
**Read template:** `docs/ai/requirements/templates/sa-template.md`
|
|
195
223
|
|
|
@@ -211,16 +239,20 @@ Propose specific technologies:
|
|
|
211
239
|
- Technology stack
|
|
212
240
|
- Reuse opportunities
|
|
213
241
|
|
|
214
|
-
4. **
|
|
242
|
+
4. **Technical Edge Cases**
|
|
243
|
+
- Concurrency, data boundaries, network, security
|
|
244
|
+
- Expected behavior for each edge case
|
|
245
|
+
|
|
246
|
+
5. **Risk Assessment**
|
|
215
247
|
- Technical risks with mitigations
|
|
216
248
|
- Complexity flags
|
|
217
249
|
|
|
218
|
-
|
|
250
|
+
6. **Implementation Guidance**
|
|
219
251
|
- Suggested phases
|
|
220
252
|
- Dependencies
|
|
221
253
|
- Constraints
|
|
222
254
|
|
|
223
|
-
|
|
255
|
+
7. **Open Technical Questions**
|
|
224
256
|
- Items needing POC
|
|
225
257
|
- Items needing research
|
|
226
258
|
|
|
@@ -232,6 +264,7 @@ Before finalizing, verify:
|
|
|
232
264
|
|
|
233
265
|
- [ ] All FRs have feasibility assessment
|
|
234
266
|
- [ ] Technology choices are justified
|
|
267
|
+
- [ ] Technical edge cases are identified with expected behavior
|
|
235
268
|
- [ ] Risks are identified with mitigations
|
|
236
269
|
- [ ] Reuse opportunities are identified
|
|
237
270
|
- [ ] Implementation phases are logical
|
|
@@ -0,0 +1,180 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: spec-review
|
|
3
|
+
description: Tech Lead reviews requirement specs for ambiguity, missing requirements, and technical risks before implementation.
|
|
4
|
+
tools: Read, Glob, Grep
|
|
5
|
+
model: inherit
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
You are a **Senior Tech Lead** reviewing requirement specification documents before they are used for implementation planning.
|
|
9
|
+
|
|
10
|
+
Your role is to ensure specs are **complete, unambiguous, and implementation-ready** — NOT to check formatting.
|
|
11
|
+
|
|
12
|
+
## Context
|
|
13
|
+
|
|
14
|
+
- Requirement specs are created by `/clarify-requirements` and consumed by `/create-plan` or `/manage-epic`
|
|
15
|
+
- Poor specs lead to wrong plans, scope creep, and missed edge cases
|
|
16
|
+
- You review the consolidated `req-{name}.md` and its agent outputs
|
|
17
|
+
|
|
18
|
+
## When Invoked
|
|
19
|
+
|
|
20
|
+
1. Read the provided requirement spec
|
|
21
|
+
2. Read related agent outputs (BA, SA, UI/UX, Research) if available
|
|
22
|
+
3. Read project context:
|
|
23
|
+
- `docs/ai/project/CODE_CONVENTIONS.md`
|
|
24
|
+
- `docs/ai/project/PROJECT_STRUCTURE.md`
|
|
25
|
+
4. Evaluate against 4 critical criteria
|
|
26
|
+
5. Output actionable review with clear verdict
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## 4 Critical Evaluation Criteria
|
|
31
|
+
|
|
32
|
+
### 1. Ambiguity Detection
|
|
33
|
+
|
|
34
|
+
**Ask yourself:**
|
|
35
|
+
- Are all requirements specific enough to implement without guessing?
|
|
36
|
+
- Would two different developers interpret each FR the same way?
|
|
37
|
+
- Are success/failure conditions explicitly defined?
|
|
38
|
+
- Are quantities, limits, and thresholds specified (not "some", "many", "quickly")?
|
|
39
|
+
|
|
40
|
+
**Red flags:**
|
|
41
|
+
- "System should respond quickly" → no response time target
|
|
42
|
+
- "Handle errors appropriately" → no error handling spec
|
|
43
|
+
- "Support multiple formats" → which formats exactly?
|
|
44
|
+
- "Similar to X feature" → what aspects are similar?
|
|
45
|
+
- "Users can manage their data" → what operations? what data?
|
|
46
|
+
- Vague acceptance criteria that can't be tested
|
|
47
|
+
|
|
48
|
+
**Output format per issue:**
|
|
49
|
+
```markdown
|
|
50
|
+
| Issue | Location | Current | Suggestion |
|
|
51
|
+
|-------|----------|---------|------------|
|
|
52
|
+
| Ambiguous requirement | FR-03 | "system should respond quickly" | Define response time: < 200ms for API, < 1s for page load |
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
### 2. Missing Requirements Detection
|
|
56
|
+
|
|
57
|
+
**Check for gaps in:**
|
|
58
|
+
|
|
59
|
+
| Category | What to Look For |
|
|
60
|
+
|----------|------------------|
|
|
61
|
+
| **Error handling** | What happens when things fail? Network errors, invalid data, timeouts |
|
|
62
|
+
| **Edge cases** | Empty states, max limits, concurrent access, boundary values |
|
|
63
|
+
| **Security** | Authentication, authorization, input validation, data sanitization |
|
|
64
|
+
| **Data lifecycle** | Creation, update, deletion, archival, migration |
|
|
65
|
+
| **User states** | First-time user, returning user, admin, guest |
|
|
66
|
+
| **Integrations** | API failures, rate limits, data format changes |
|
|
67
|
+
| **Performance** | Load expectations, caching needs, pagination |
|
|
68
|
+
| **Accessibility** | Keyboard navigation, screen readers, color contrast |
|
|
69
|
+
|
|
70
|
+
**Red flags:**
|
|
71
|
+
- Only happy path described, no error flows
|
|
72
|
+
- No mention of validation rules
|
|
73
|
+
- Missing concurrent access handling (e.g., two users editing same record)
|
|
74
|
+
- No data retention/deletion policy
|
|
75
|
+
- Missing rate limiting or abuse prevention
|
|
76
|
+
- No mention of what happens during downtime of dependencies
|
|
77
|
+
|
|
78
|
+
### 3. Technical Risk Detection
|
|
79
|
+
|
|
80
|
+
**Ask yourself:**
|
|
81
|
+
- Are there technology choices that could be problematic?
|
|
82
|
+
- Are there scalability concerns not addressed?
|
|
83
|
+
- Are there security vulnerabilities in the proposed approach?
|
|
84
|
+
- Are there performance bottlenecks waiting to happen?
|
|
85
|
+
- Are dependencies stable and well-supported?
|
|
86
|
+
|
|
87
|
+
**Risk categories:**
|
|
88
|
+
- **Security risks**: SQL injection, XSS, CSRF, insecure auth, exposed secrets
|
|
89
|
+
- **Performance risks**: N+1 queries, missing pagination, unbounded data loads
|
|
90
|
+
- **Scalability risks**: Single point of failure, no caching strategy
|
|
91
|
+
- **Integration risks**: Unstable APIs, missing retry logic, no circuit breaker
|
|
92
|
+
- **Data risks**: No backup strategy, missing migrations, data loss scenarios
|
|
93
|
+
|
|
94
|
+
### 4. Consistency Check
|
|
95
|
+
|
|
96
|
+
**Verify internal consistency:**
|
|
97
|
+
- Do user stories align with functional requirements?
|
|
98
|
+
- Do acceptance criteria match the FRs they validate?
|
|
99
|
+
- Does SA assessment align with BA scope?
|
|
100
|
+
- Are priorities consistent across sections?
|
|
101
|
+
- Does UI/UX design cover all user stories?
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
## Output Format
|
|
106
|
+
|
|
107
|
+
```markdown
|
|
108
|
+
## Spec Review: {feature-name}
|
|
109
|
+
|
|
110
|
+
### Verdict
|
|
111
|
+
**Status**: ✅ Ready for Planning | ⚠️ Needs Revision | ❌ Not Ready
|
|
112
|
+
|
|
113
|
+
**Implementation Readiness**: {0-100}%
|
|
114
|
+
(How ready is this spec for /create-plan or /manage-epic)
|
|
115
|
+
|
|
116
|
+
---
|
|
117
|
+
|
|
118
|
+
### 1. Ambiguity Issues
|
|
119
|
+
|
|
120
|
+
**Found**: {count} issues
|
|
121
|
+
|
|
122
|
+
| # | Location | Current Text | Problem | Suggestion |
|
|
123
|
+
|---|----------|--------------|---------|------------|
|
|
124
|
+
| 1 | {section/ID} | "{quoted text}" | {why it's ambiguous} | {specific fix} |
|
|
125
|
+
|
|
126
|
+
### 2. Missing Requirements
|
|
127
|
+
|
|
128
|
+
**Found**: {count} gaps
|
|
129
|
+
|
|
130
|
+
| # | Category | What's Missing | Impact | Suggestion |
|
|
131
|
+
|---|----------|----------------|--------|------------|
|
|
132
|
+
| 1 | {category} | {description} | {High/Med/Low} | {what to add} |
|
|
133
|
+
|
|
134
|
+
### 3. Technical Risks
|
|
135
|
+
|
|
136
|
+
**Found**: {count} risks
|
|
137
|
+
|
|
138
|
+
| # | Risk | Severity | In Spec? | Suggestion |
|
|
139
|
+
|---|------|----------|----------|------------|
|
|
140
|
+
| 1 | {risk description} | 🔴 High / 🟡 Medium / 🟢 Low | Yes/No | {mitigation} |
|
|
141
|
+
|
|
142
|
+
### 4. Consistency Issues
|
|
143
|
+
|
|
144
|
+
**Found**: {count} issues
|
|
145
|
+
|
|
146
|
+
| # | Conflict | Between | Suggestion |
|
|
147
|
+
|---|----------|---------|------------|
|
|
148
|
+
| 1 | {description} | {Section A} vs {Section B} | {how to resolve} |
|
|
149
|
+
|
|
150
|
+
---
|
|
151
|
+
|
|
152
|
+
### Summary
|
|
153
|
+
|
|
154
|
+
**Critical Issues (Must Fix Before Planning)**:
|
|
155
|
+
1. {Issue} → {Fix}
|
|
156
|
+
|
|
157
|
+
**Warnings (Should Fix)**:
|
|
158
|
+
1. {Issue} → {Fix}
|
|
159
|
+
|
|
160
|
+
**Suggestions (Nice to Have)**:
|
|
161
|
+
1. {Improvement}
|
|
162
|
+
|
|
163
|
+
---
|
|
164
|
+
|
|
165
|
+
### Recommendation
|
|
166
|
+
{Clear next action: ready for planning / revise specific sections / needs major rework}
|
|
167
|
+
|
|
168
|
+
If ⚠️ or ❌: list exactly which sections need revision and what to add.
|
|
169
|
+
```
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
## Review Mindset
|
|
174
|
+
|
|
175
|
+
- Think like you're preventing scope creep and bugs BEFORE planning starts
|
|
176
|
+
- A spec missing edge cases = a plan missing tasks = bugs in production
|
|
177
|
+
- Ambiguity in specs gets amplified through planning and implementation
|
|
178
|
+
- Be specific and actionable — vague feedback like "needs more detail" is useless
|
|
179
|
+
- Focus on substance, not formatting
|
|
180
|
+
- Every issue should have a concrete suggestion for how to fix it
|
|
@@ -65,21 +65,46 @@ Analyze user prompt to determine:
|
|
|
65
65
|
| **Feature Type** | Keywords: UI, API, page, endpoint, database | `UI` / `API` / `Data` / `Full-stack` |
|
|
66
66
|
| **Complexity** | Scope indicators, number of features | `Simple` / `Medium` / `Complex` |
|
|
67
67
|
| **Domain Terms** | Industry jargon, unfamiliar terms | List of terms needing research |
|
|
68
|
-
| **UI
|
|
69
|
-
|
|
68
|
+
| **UI Needed** | Mentions of screens, forms, flows, pages | Boolean: needs UI/UX |
|
|
69
|
+
|
|
70
|
+
### Determine Workflow Mode
|
|
71
|
+
|
|
72
|
+
Based on Complexity, ask user to confirm mode:
|
|
73
|
+
|
|
74
|
+
```
|
|
75
|
+
AskUserQuestion(questions=[{
|
|
76
|
+
question: "Feature complexity detected as {Simple/Medium/Complex}. Which workflow mode?",
|
|
77
|
+
header: "Mode",
|
|
78
|
+
options: [
|
|
79
|
+
{ label: "Light mode", description: "BA → SA → Consolidate (fast, low token cost)" },
|
|
80
|
+
{ label: "Full mode", description: "BA → SA → Researcher/UI/UX → Consolidate (thorough)" }
|
|
81
|
+
],
|
|
82
|
+
multiSelect: false
|
|
83
|
+
}])
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
**Light Mode** (for Simple features or when user prefers speed):
|
|
87
|
+
- Agents: BA → SA → Consolidate
|
|
88
|
+
- Skip Researcher and UI/UX agents
|
|
89
|
+
- Fewer Q&A rounds (1-2 max)
|
|
90
|
+
- Smaller consolidated output
|
|
91
|
+
|
|
92
|
+
**Full Mode** (for Complex features or when user wants thoroughness):
|
|
93
|
+
- Full agent workflow as described in subsequent steps
|
|
94
|
+
- All conditional agents evaluated
|
|
70
95
|
|
|
71
96
|
### Determine Agent Strategy
|
|
72
97
|
|
|
73
|
-
Based on analysis:
|
|
98
|
+
Based on analysis and mode:
|
|
74
99
|
|
|
75
|
-
| Scenario | Agents to Run | Execution |
|
|
76
|
-
|
|
77
|
-
| Simple API feature | BA → SA | Sequential |
|
|
78
|
-
|
|
|
79
|
-
|
|
|
80
|
-
| Complex full-stack | BA → SA → UI/UX | Sequential |
|
|
81
|
-
| Domain-specific | BA + Researcher (parallel) → SA → UI/UX | Mixed |
|
|
82
|
-
|
|
|
100
|
+
| Scenario | Mode | Agents to Run | Execution |
|
|
101
|
+
|----------|------|---------------|-----------|
|
|
102
|
+
| Simple API feature | Light | BA → SA | Sequential |
|
|
103
|
+
| Simple UI feature | Light | BA → SA | Sequential |
|
|
104
|
+
| Complex API feature | Full | BA → SA | Sequential |
|
|
105
|
+
| Complex full-stack | Full | BA → SA → UI/UX | Sequential |
|
|
106
|
+
| Domain-specific | Full | BA + Researcher (parallel) → SA → UI/UX | Mixed |
|
|
107
|
+
| Any feature | Light | BA → SA | Sequential |
|
|
83
108
|
|
|
84
109
|
### Decision Output
|
|
85
110
|
|
|
@@ -89,13 +114,13 @@ Based on analysis:
|
|
|
89
114
|
**Feature**: {derived name}
|
|
90
115
|
**Type**: {UI / API / Full-stack / Data}
|
|
91
116
|
**Complexity**: {Simple / Medium / Complex}
|
|
92
|
-
**
|
|
117
|
+
**Mode**: {Light / Full}
|
|
93
118
|
|
|
94
119
|
**Agents Required**:
|
|
95
120
|
- [x] BA Agent (always)
|
|
96
121
|
- [x] SA Agent (always)
|
|
97
|
-
- [ ] Researcher Agent (domain terms detected: {list})
|
|
98
|
-
- [ ] UI/UX Agent (UI components needed)
|
|
122
|
+
- [ ] Researcher Agent (domain terms detected: {list}) — Full mode only
|
|
123
|
+
- [ ] UI/UX Agent (UI components needed) — Full mode only
|
|
99
124
|
|
|
100
125
|
**Execution Plan**:
|
|
101
126
|
1. {Step 1}
|
|
@@ -346,6 +371,9 @@ Create `docs/ai/requirements/req-{name}.md` with:
|
|
|
346
371
|
### Technology Stack
|
|
347
372
|
{From SA document - stack table}
|
|
348
373
|
|
|
374
|
+
### Technical Edge Cases
|
|
375
|
+
{From SA document - edge cases table}
|
|
376
|
+
|
|
349
377
|
### Risks
|
|
350
378
|
{From SA document - risk table}
|
|
351
379
|
|
|
@@ -402,6 +430,35 @@ Create `docs/ai/requirements/req-{name}.md` with:
|
|
|
402
430
|
|
|
403
431
|
---
|
|
404
432
|
|
|
433
|
+
---
|
|
434
|
+
|
|
435
|
+
## 13. Implementation Readiness Score
|
|
436
|
+
|
|
437
|
+
**Score**: {0-100}%
|
|
438
|
+
|
|
439
|
+
| Criteria | Status | Weight |
|
|
440
|
+
|----------|--------|--------|
|
|
441
|
+
| All FRs have testable acceptance criteria | ✅ / ❌ | 20% |
|
|
442
|
+
| No critical open questions | ✅ / ❌ | 20% |
|
|
443
|
+
| Technical risks have mitigations | ✅ / ❌ | 15% |
|
|
444
|
+
| Business rules are explicit | ✅ / ❌ | 15% |
|
|
445
|
+
| Error/edge cases defined | ✅ / ❌ | 15% |
|
|
446
|
+
| UI/UX specs complete (if applicable) | ✅ / ❌ / N/A | 15% |
|
|
447
|
+
|
|
448
|
+
**Missing for 100%**:
|
|
449
|
+
- {item 1}
|
|
450
|
+
- {item 2}
|
|
451
|
+
|
|
452
|
+
---
|
|
453
|
+
|
|
454
|
+
## 14. Changelog
|
|
455
|
+
|
|
456
|
+
| Date | Change |
|
|
457
|
+
|------|--------|
|
|
458
|
+
| {YYYY-MM-DD} | Initial version |
|
|
459
|
+
|
|
460
|
+
---
|
|
461
|
+
|
|
405
462
|
## Next Steps
|
|
406
463
|
|
|
407
464
|
1. Review this requirement document
|
|
@@ -488,10 +545,13 @@ UI/UX Agent:
|
|
|
488
545
|
|
|
489
546
|
```
|
|
490
547
|
Simple (1-2 Q&A rounds):
|
|
491
|
-
└──
|
|
548
|
+
└── Default to Light mode. User can override to Full mode.
|
|
549
|
+
|
|
550
|
+
Medium (2-3 Q&A rounds):
|
|
551
|
+
└── Ask user to choose Light or Full mode.
|
|
492
552
|
|
|
493
553
|
Complex (many unknowns):
|
|
494
|
-
└──
|
|
554
|
+
└── Default to Full mode. Recommend breaking down into smaller requirements.
|
|
495
555
|
```
|
|
496
556
|
|
|
497
557
|
---
|
package/cli.js
CHANGED
|
@@ -419,19 +419,6 @@ function installClaudeCode() {
|
|
|
419
419
|
run(`wget -qO ${claudeMdPath} ${RAW_BASE}/.claude/CLAUDE.md`);
|
|
420
420
|
}
|
|
421
421
|
|
|
422
|
-
// Download settings.json from repo (project-level, shareable with team)
|
|
423
|
-
step("🚚 Downloading Claude Code hooks (.claude/settings.json)...");
|
|
424
|
-
const claudeSettingsPath = ".claude/settings.json";
|
|
425
|
-
if (existsSync(claudeSettingsPath)) {
|
|
426
|
-
skip(`Skipping (already exists): ${claudeSettingsPath}`);
|
|
427
|
-
} else {
|
|
428
|
-
try {
|
|
429
|
-
run(`curl -fsSL ${RAW_BASE}/.claude/settings.json -o ${claudeSettingsPath}`);
|
|
430
|
-
} catch (_) {
|
|
431
|
-
run(`wget -qO ${claudeSettingsPath} ${RAW_BASE}/.claude/settings.json`);
|
|
432
|
-
}
|
|
433
|
-
success(`Downloaded: ${claudeSettingsPath}`);
|
|
434
|
-
}
|
|
435
422
|
|
|
436
423
|
// Download skills folder (always overwrite to get latest)
|
|
437
424
|
step("🚚 Downloading Claude Code skills (.claude/skills)...");
|
|
@@ -155,7 +155,15 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
155
155
|
|
|
156
156
|
---
|
|
157
157
|
|
|
158
|
-
## 10. Edge Cases
|
|
158
|
+
## 10. Technical Edge Cases
|
|
159
|
+
|
|
160
|
+
| ID | Category | Edge Case | Expected Behavior | Priority |
|
|
161
|
+
|----|----------|-----------|-------------------|----------|
|
|
162
|
+
| TE-01 | {Concurrency/Data/Network/Security/Performance} | {Description} | {How system should handle it} | Must/Should |
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
166
|
+
## 11. Edge Cases & Constraints
|
|
159
167
|
|
|
160
168
|
### Edge Cases
|
|
161
169
|
|
|
@@ -171,7 +179,7 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
171
179
|
|
|
172
180
|
---
|
|
173
181
|
|
|
174
|
-
##
|
|
182
|
+
## 12. Out of Scope
|
|
175
183
|
|
|
176
184
|
> Explicitly excluded from this requirement
|
|
177
185
|
|
|
@@ -180,7 +188,7 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
180
188
|
|
|
181
189
|
---
|
|
182
190
|
|
|
183
|
-
##
|
|
191
|
+
## 13. Open Questions
|
|
184
192
|
|
|
185
193
|
| ID | Question | Owner | Status |
|
|
186
194
|
|----|----------|-------|--------|
|
|
@@ -188,7 +196,7 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
188
196
|
|
|
189
197
|
---
|
|
190
198
|
|
|
191
|
-
##
|
|
199
|
+
## 14. Acceptance Criteria
|
|
192
200
|
|
|
193
201
|
### Scenario 1: {Happy Path - Main Flow}
|
|
194
202
|
|
|
@@ -210,7 +218,7 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
210
218
|
|
|
211
219
|
---
|
|
212
220
|
|
|
213
|
-
##
|
|
221
|
+
## 15. Implementation Guidance
|
|
214
222
|
|
|
215
223
|
### Suggested Phases
|
|
216
224
|
|
|
@@ -228,7 +236,34 @@ See: [UI/UX Design Document](agents/uiux-{name}.md)
|
|
|
228
236
|
|
|
229
237
|
---
|
|
230
238
|
|
|
231
|
-
##
|
|
239
|
+
## 16. Implementation Readiness Score
|
|
240
|
+
|
|
241
|
+
**Score**: {0-100}%
|
|
242
|
+
|
|
243
|
+
| Criteria | Status | Weight |
|
|
244
|
+
|----------|--------|--------|
|
|
245
|
+
| All FRs have testable acceptance criteria | ✅ / ❌ | 20% |
|
|
246
|
+
| No critical open questions | ✅ / ❌ | 20% |
|
|
247
|
+
| Technical risks have mitigations | ✅ / ❌ | 15% |
|
|
248
|
+
| Business rules are explicit | ✅ / ❌ | 15% |
|
|
249
|
+
| Error/edge cases defined | ✅ / ❌ | 15% |
|
|
250
|
+
| UI/UX specs complete (if applicable) | ✅ / ❌ / N/A | 15% |
|
|
251
|
+
|
|
252
|
+
**Missing for 100%**:
|
|
253
|
+
- {item 1}
|
|
254
|
+
- {item 2}
|
|
255
|
+
|
|
256
|
+
---
|
|
257
|
+
|
|
258
|
+
## 17. Changelog
|
|
259
|
+
|
|
260
|
+
| Date | Change |
|
|
261
|
+
|------|--------|
|
|
262
|
+
| {YYYY-MM-DD} | Initial version |
|
|
263
|
+
|
|
264
|
+
---
|
|
265
|
+
|
|
266
|
+
## 18. References
|
|
232
267
|
|
|
233
268
|
- **Related Docs**: {links to related requirements, designs}
|
|
234
269
|
- **External Links**: {Jira tickets, Figma, API docs}
|
|
@@ -87,7 +87,15 @@
|
|
|
87
87
|
|
|
88
88
|
---
|
|
89
89
|
|
|
90
|
-
## 4.
|
|
90
|
+
## 4. Technical Edge Cases
|
|
91
|
+
|
|
92
|
+
| ID | Category | Edge Case | Expected Behavior | Priority |
|
|
93
|
+
|----|----------|-----------|-------------------|----------|
|
|
94
|
+
| TE-01 | {Concurrency/Data/Network/Security/Performance/Integration/State} | {Description} | {How system should handle it} | Must/Should |
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## 5. Risk Assessment
|
|
91
99
|
|
|
92
100
|
### Technical Risks
|
|
93
101
|
|
|
@@ -104,9 +112,9 @@
|
|
|
104
112
|
|
|
105
113
|
---
|
|
106
114
|
|
|
107
|
-
##
|
|
115
|
+
## 6. Implementation Guidance
|
|
108
116
|
|
|
109
|
-
###
|
|
117
|
+
### 6.1 Suggested Phases
|
|
110
118
|
|
|
111
119
|
#### Phase 1: Foundation
|
|
112
120
|
**Priority**: High | **Complexity**: Low
|
|
@@ -133,7 +141,7 @@
|
|
|
133
141
|
| {Enhancement 1} | {What to add} |
|
|
134
142
|
| {Polish} | {Final touches} |
|
|
135
143
|
|
|
136
|
-
###
|
|
144
|
+
### 6.2 Technical Constraints
|
|
137
145
|
|
|
138
146
|
| Constraint | Description | Impact |
|
|
139
147
|
|------------|-------------|--------|
|
|
@@ -141,7 +149,7 @@
|
|
|
141
149
|
| Security | {Requirement} | {How it affects design} |
|
|
142
150
|
| Compatibility | {Requirement} | {How it affects design} |
|
|
143
151
|
|
|
144
|
-
###
|
|
152
|
+
### 6.3 Data Model (if applicable)
|
|
145
153
|
|
|
146
154
|
```
|
|
147
155
|
┌──────────────────┐ ┌──────────────────┐
|
|
@@ -156,7 +164,7 @@
|
|
|
156
164
|
|
|
157
165
|
---
|
|
158
166
|
|
|
159
|
-
##
|
|
167
|
+
## 7. Open Technical Questions
|
|
160
168
|
|
|
161
169
|
| ID | Question | Impact | Suggested Action |
|
|
162
170
|
|----|----------|--------|------------------|
|
|
@@ -164,7 +172,7 @@
|
|
|
164
172
|
|
|
165
173
|
---
|
|
166
174
|
|
|
167
|
-
##
|
|
175
|
+
## 8. Alternatives Considered
|
|
168
176
|
|
|
169
177
|
| Alternative | Pros | Cons | Why Not Chosen |
|
|
170
178
|
|-------------|------|------|----------------|
|