appiq-solution 1.4.2 → 1.4.4
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/#Tools/APPIQ-METHOD/.cursor/commands/analyze.md +1 -1
- package/#Tools/APPIQ-METHOD/.cursor/commands/appiq.md +1 -1
- package/#Tools/APPIQ-METHOD/.cursor/commands/help.md +1 -1
- package/#Tools/APPIQ-METHOD/.cursor/commands/story.md +1 -1
- package/#Tools/APPIQ-METHOD/bmad-core/agents/init-flow-po.md +219 -0
- package/#Tools/APPIQ-METHOD/commands/analyze.md +1 -1
- package/#Tools/APPIQ-METHOD/commands/appiq.md +1 -1
- package/#Tools/APPIQ-METHOD/commands/help.md +1 -1
- package/#Tools/APPIQ-METHOD/commands/story.md +1 -1
- package/#Tools/APPIQ-METHOD/package.json +1 -1
- package/#Tools/APPIQ-METHOD/tools/appiq-installer.js +196 -104
- package/#Tools/APPIQ-METHOD/tools/cli.js +1 -1
- package/#Tools/APPIQ-METHOD/tools/setup-ide-commands.js +40 -37
- package/#Tools/APPIQ-METHOD/tools/smart-installer.js +16 -13
- package/bmad-core/agent-teams/team-all.yaml +14 -0
- package/bmad-core/agent-teams/team-flutter-mobile.yaml +114 -0
- package/bmad-core/agent-teams/team-fullstack.yaml +28 -0
- package/bmad-core/agent-teams/team-ide-minimal.yaml +10 -0
- package/bmad-core/agent-teams/team-no-ui.yaml +13 -0
- package/bmad-core/agents/analyst.md +85 -0
- package/bmad-core/agents/architect.md +90 -0
- package/bmad-core/agents/bmad-master.md +108 -0
- package/bmad-core/agents/bmad-orchestrator.md +150 -0
- package/bmad-core/agents/bmad-smart-launcher.md +170 -0
- package/bmad-core/agents/dev.md +95 -0
- package/bmad-core/agents/init-flow-po.md +219 -0
- package/bmad-core/agents/pm.md +85 -0
- package/bmad-core/agents/po.md +76 -0
- package/bmad-core/agents/qa.md +86 -0
- package/bmad-core/agents/sm.md +67 -0
- package/bmad-core/agents/ux-expert.md +71 -0
- package/bmad-core/bmad-core/user-guide.md +0 -0
- package/bmad-core/checklists/architect-checklist.md +443 -0
- package/bmad-core/checklists/change-checklist.md +182 -0
- package/bmad-core/checklists/pm-checklist.md +375 -0
- package/bmad-core/checklists/po-master-checklist.md +441 -0
- package/bmad-core/checklists/security-validation-checklist.md +332 -0
- package/bmad-core/checklists/story-dod-checklist.md +101 -0
- package/bmad-core/checklists/story-draft-checklist.md +156 -0
- package/bmad-core/core-config.yaml +20 -0
- package/bmad-core/core-config.yaml.bak +20 -0
- package/bmad-core/data/backend-services-integration.md +686 -0
- package/bmad-core/data/bmad-kb.md +803 -0
- package/bmad-core/data/brainstorming-techniques.md +36 -0
- package/bmad-core/data/elicitation-methods.md +134 -0
- package/bmad-core/data/shadcn-ui-integration.md +388 -0
- package/bmad-core/data/technical-preferences.md +149 -0
- package/bmad-core/enhanced-ide-development-workflow.md +43 -0
- package/bmad-core/tasks/advanced-elicitation.md +117 -0
- package/bmad-core/tasks/brownfield-create-epic.md +160 -0
- package/bmad-core/tasks/brownfield-create-story.md +147 -0
- package/bmad-core/tasks/correct-course.md +70 -0
- package/bmad-core/tasks/create-brownfield-story.md +304 -0
- package/bmad-core/tasks/create-deep-research-prompt.md +289 -0
- package/bmad-core/tasks/create-flutter-story.md +197 -0
- package/bmad-core/tasks/create-next-story.md +112 -0
- package/bmad-core/tasks/document-project.md +341 -0
- package/bmad-core/tasks/facilitate-brainstorming-session.md +136 -0
- package/bmad-core/tasks/generate-ai-frontend-prompt.md +51 -0
- package/bmad-core/tasks/index-docs.md +179 -0
- package/bmad-core/tasks/intelligent-epic-creation.md +234 -0
- package/bmad-core/tasks/kb-mode-interaction.md +75 -0
- package/bmad-core/tasks/review-story.md +145 -0
- package/bmad-core/tasks/shard-doc.md +187 -0
- package/bmad-core/tasks/smart-project-analysis.md +289 -0
- package/bmad-core/tasks/validate-next-story.md +134 -0
- package/bmad-core/templates/architecture-tmpl.yaml +650 -0
- package/bmad-core/templates/brainstorming-output-tmpl.yaml +156 -0
- package/bmad-core/templates/brownfield-architecture-tmpl.yaml +476 -0
- package/bmad-core/templates/brownfield-prd-tmpl.yaml +280 -0
- package/bmad-core/templates/competitor-analysis-tmpl.yaml +293 -0
- package/bmad-core/templates/flutter-mobile-prd-tmpl.yaml +330 -0
- package/bmad-core/templates/flutter-story-tmpl.yaml +376 -0
- package/bmad-core/templates/flutter-ui-spec-tmpl.yaml +415 -0
- package/bmad-core/templates/front-end-architecture-tmpl.yaml +206 -0
- package/bmad-core/templates/front-end-spec-tmpl.yaml +349 -0
- package/bmad-core/templates/fullstack-architecture-tmpl.yaml +812 -0
- package/bmad-core/templates/market-research-tmpl.yaml +252 -0
- package/bmad-core/templates/prd-tmpl.yaml +202 -0
- package/bmad-core/templates/project-brief-tmpl.yaml +221 -0
- package/bmad-core/templates/story-tmpl.yaml +137 -0
- package/bmad-core/user-guide.md +251 -0
- package/bmad-core/workflows/brownfield-fullstack.yaml +311 -0
- package/bmad-core/workflows/brownfield-service.yaml +187 -0
- package/bmad-core/workflows/brownfield-ui.yaml +197 -0
- package/bmad-core/workflows/greenfield-fullstack.yaml +284 -0
- package/bmad-core/workflows/greenfield-service.yaml +206 -0
- package/bmad-core/workflows/greenfield-ui.yaml +235 -0
- package/bmad-core/working-in-the-brownfield.md +373 -0
- package/package.json +1 -1
- package/tools/appiq-installer.js +196 -104
- package/tools/cli.js +1 -1
- package/tools/setup-ide-commands.js +40 -37
- package/tools/smart-installer.js +16 -13
@@ -0,0 +1,441 @@
|
|
1
|
+
# Product Owner (PO) Master Validation Checklist
|
2
|
+
|
3
|
+
This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
|
4
|
+
|
5
|
+
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
|
6
|
+
|
7
|
+
PROJECT TYPE DETECTION:
|
8
|
+
First, determine the project type by checking:
|
9
|
+
|
10
|
+
1. Is this a GREENFIELD project (new from scratch)?
|
11
|
+
|
12
|
+
- Look for: New project initialization, no existing codebase references
|
13
|
+
- Check for: prd.md, architecture.md, new project setup stories
|
14
|
+
|
15
|
+
2. Is this a BROWNFIELD project (enhancing existing system)?
|
16
|
+
|
17
|
+
- Look for: References to existing codebase, enhancement/modification language
|
18
|
+
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
19
|
+
|
20
|
+
3. Does the project include UI/UX components?
|
21
|
+
- Check for: frontend-architecture.md, UI/UX specifications, design files
|
22
|
+
- Look for: Frontend stories, component specifications, user interface mentions
|
23
|
+
|
24
|
+
DOCUMENT REQUIREMENTS:
|
25
|
+
Based on project type, ensure you have access to:
|
26
|
+
|
27
|
+
For GREENFIELD projects:
|
28
|
+
|
29
|
+
- prd.md - The Product Requirements Document
|
30
|
+
- architecture.md - The system architecture
|
31
|
+
- frontend-architecture.md - If UI/UX is involved
|
32
|
+
- All epic and story definitions
|
33
|
+
|
34
|
+
For BROWNFIELD projects:
|
35
|
+
|
36
|
+
- brownfield-prd.md - The brownfield enhancement requirements
|
37
|
+
- brownfield-architecture.md - The enhancement architecture
|
38
|
+
- Existing project codebase access (CRITICAL - cannot proceed without this)
|
39
|
+
- Current deployment configuration and infrastructure details
|
40
|
+
- Database schemas, API documentation, monitoring setup
|
41
|
+
|
42
|
+
SKIP INSTRUCTIONS:
|
43
|
+
|
44
|
+
- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
|
45
|
+
- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
|
46
|
+
- Skip sections marked [[UI/UX ONLY]] for backend-only projects
|
47
|
+
- Note all skipped sections in your final report
|
48
|
+
|
49
|
+
VALIDATION APPROACH:
|
50
|
+
|
51
|
+
1. Deep Analysis - Thoroughly analyze each item against documentation
|
52
|
+
2. Evidence-Based - Cite specific sections or code when validating
|
53
|
+
3. Critical Thinking - Question assumptions and identify gaps
|
54
|
+
4. Risk Assessment - Consider what could go wrong with each decision
|
55
|
+
|
56
|
+
EXECUTION MODE:
|
57
|
+
Ask the user if they want to work through the checklist:
|
58
|
+
|
59
|
+
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
60
|
+
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
61
|
+
|
62
|
+
## 1. PROJECT SETUP & INITIALIZATION
|
63
|
+
|
64
|
+
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
65
|
+
|
66
|
+
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
67
|
+
|
68
|
+
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
69
|
+
- [ ] If using a starter template, steps for cloning/setup are included
|
70
|
+
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
71
|
+
- [ ] Initial README or documentation setup is included
|
72
|
+
- [ ] Repository setup and initial commit processes are defined
|
73
|
+
|
74
|
+
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
75
|
+
|
76
|
+
- [ ] Existing project analysis has been completed and documented
|
77
|
+
- [ ] Integration points with current system are identified
|
78
|
+
- [ ] Development environment preserves existing functionality
|
79
|
+
- [ ] Local testing approach validated for existing features
|
80
|
+
- [ ] Rollback procedures defined for each integration point
|
81
|
+
|
82
|
+
### 1.3 Development Environment
|
83
|
+
|
84
|
+
- [ ] Local development environment setup is clearly defined
|
85
|
+
- [ ] Required tools and versions are specified
|
86
|
+
- [ ] Steps for installing dependencies are included
|
87
|
+
- [ ] Configuration files are addressed appropriately
|
88
|
+
- [ ] Development server setup is included
|
89
|
+
|
90
|
+
### 1.4 Core Dependencies
|
91
|
+
|
92
|
+
- [ ] All critical packages/libraries are installed early
|
93
|
+
- [ ] Package management is properly addressed
|
94
|
+
- [ ] Version specifications are appropriately defined
|
95
|
+
- [ ] Dependency conflicts or special requirements are noted
|
96
|
+
- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
|
97
|
+
|
98
|
+
## 2. INFRASTRUCTURE & DEPLOYMENT
|
99
|
+
|
100
|
+
[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
|
101
|
+
|
102
|
+
### 2.1 Database & Data Store Setup
|
103
|
+
|
104
|
+
- [ ] Database selection/setup occurs before any operations
|
105
|
+
- [ ] Schema definitions are created before data operations
|
106
|
+
- [ ] Migration strategies are defined if applicable
|
107
|
+
- [ ] Seed data or initial data setup is included if needed
|
108
|
+
- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
|
109
|
+
- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
|
110
|
+
|
111
|
+
### 2.2 API & Service Configuration
|
112
|
+
|
113
|
+
- [ ] API frameworks are set up before implementing endpoints
|
114
|
+
- [ ] Service architecture is established before implementing services
|
115
|
+
- [ ] Authentication framework is set up before protected routes
|
116
|
+
- [ ] Middleware and common utilities are created before use
|
117
|
+
- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
|
118
|
+
- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
|
119
|
+
|
120
|
+
### 2.3 Deployment Pipeline
|
121
|
+
|
122
|
+
- [ ] CI/CD pipeline is established before deployment actions
|
123
|
+
- [ ] Infrastructure as Code (IaC) is set up before use
|
124
|
+
- [ ] Environment configurations are defined early
|
125
|
+
- [ ] Deployment strategies are defined before implementation
|
126
|
+
- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
|
127
|
+
- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
|
128
|
+
|
129
|
+
### 2.4 Testing Infrastructure
|
130
|
+
|
131
|
+
- [ ] Testing frameworks are installed before writing tests
|
132
|
+
- [ ] Test environment setup precedes test implementation
|
133
|
+
- [ ] Mock services or data are defined before testing
|
134
|
+
- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
|
135
|
+
- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
|
136
|
+
|
137
|
+
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
138
|
+
|
139
|
+
[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
|
140
|
+
|
141
|
+
### 3.1 Third-Party Services
|
142
|
+
|
143
|
+
- [ ] Account creation steps are identified for required services
|
144
|
+
- [ ] API key acquisition processes are defined
|
145
|
+
- [ ] Steps for securely storing credentials are included
|
146
|
+
- [ ] Fallback or offline development options are considered
|
147
|
+
- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
|
148
|
+
- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
|
149
|
+
|
150
|
+
### 3.2 External APIs
|
151
|
+
|
152
|
+
- [ ] Integration points with external APIs are clearly identified
|
153
|
+
- [ ] Authentication with external services is properly sequenced
|
154
|
+
- [ ] API limits or constraints are acknowledged
|
155
|
+
- [ ] Backup strategies for API failures are considered
|
156
|
+
- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
|
157
|
+
|
158
|
+
### 3.3 Infrastructure Services
|
159
|
+
|
160
|
+
- [ ] Cloud resource provisioning is properly sequenced
|
161
|
+
- [ ] DNS or domain registration needs are identified
|
162
|
+
- [ ] Email or messaging service setup is included if needed
|
163
|
+
- [ ] CDN or static asset hosting setup precedes their use
|
164
|
+
- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
|
165
|
+
|
166
|
+
## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
|
167
|
+
|
168
|
+
[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
|
169
|
+
|
170
|
+
### 4.1 Design System Setup
|
171
|
+
|
172
|
+
- [ ] UI framework and libraries are selected and installed early
|
173
|
+
- [ ] Design system or component library is established
|
174
|
+
- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
|
175
|
+
- [ ] Responsive design strategy is established
|
176
|
+
- [ ] Accessibility requirements are defined upfront
|
177
|
+
|
178
|
+
### 4.2 Frontend Infrastructure
|
179
|
+
|
180
|
+
- [ ] Frontend build pipeline is configured before development
|
181
|
+
- [ ] Asset optimization strategy is defined
|
182
|
+
- [ ] Frontend testing framework is set up
|
183
|
+
- [ ] Component development workflow is established
|
184
|
+
- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
|
185
|
+
|
186
|
+
### 4.3 User Experience Flow
|
187
|
+
|
188
|
+
- [ ] User journeys are mapped before implementation
|
189
|
+
- [ ] Navigation patterns are defined early
|
190
|
+
- [ ] Error states and loading states are planned
|
191
|
+
- [ ] Form validation patterns are established
|
192
|
+
- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
|
193
|
+
|
194
|
+
## 5. USER/AGENT RESPONSIBILITY
|
195
|
+
|
196
|
+
[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
|
197
|
+
|
198
|
+
### 5.1 User Actions
|
199
|
+
|
200
|
+
- [ ] User responsibilities limited to human-only tasks
|
201
|
+
- [ ] Account creation on external services assigned to users
|
202
|
+
- [ ] Purchasing or payment actions assigned to users
|
203
|
+
- [ ] Credential provision appropriately assigned to users
|
204
|
+
|
205
|
+
### 5.2 Developer Agent Actions
|
206
|
+
|
207
|
+
- [ ] All code-related tasks assigned to developer agents
|
208
|
+
- [ ] Automated processes identified as agent responsibilities
|
209
|
+
- [ ] Configuration management properly assigned
|
210
|
+
- [ ] Testing and validation assigned to appropriate agents
|
211
|
+
|
212
|
+
## 6. FEATURE SEQUENCING & DEPENDENCIES
|
213
|
+
|
214
|
+
[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
|
215
|
+
|
216
|
+
### 6.1 Functional Dependencies
|
217
|
+
|
218
|
+
- [ ] Features depending on others are sequenced correctly
|
219
|
+
- [ ] Shared components are built before their use
|
220
|
+
- [ ] User flows follow logical progression
|
221
|
+
- [ ] Authentication features precede protected features
|
222
|
+
- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
|
223
|
+
|
224
|
+
### 6.2 Technical Dependencies
|
225
|
+
|
226
|
+
- [ ] Lower-level services built before higher-level ones
|
227
|
+
- [ ] Libraries and utilities created before their use
|
228
|
+
- [ ] Data models defined before operations on them
|
229
|
+
- [ ] API endpoints defined before client consumption
|
230
|
+
- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
|
231
|
+
|
232
|
+
### 6.3 Cross-Epic Dependencies
|
233
|
+
|
234
|
+
- [ ] Later epics build upon earlier epic functionality
|
235
|
+
- [ ] No epic requires functionality from later epics
|
236
|
+
- [ ] Infrastructure from early epics utilized consistently
|
237
|
+
- [ ] Incremental value delivery maintained
|
238
|
+
- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
|
239
|
+
|
240
|
+
## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
|
241
|
+
|
242
|
+
[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
|
243
|
+
|
244
|
+
### 7.1 Breaking Change Risks
|
245
|
+
|
246
|
+
- [ ] Risk of breaking existing functionality assessed
|
247
|
+
- [ ] Database migration risks identified and mitigated
|
248
|
+
- [ ] API breaking change risks evaluated
|
249
|
+
- [ ] Performance degradation risks identified
|
250
|
+
- [ ] Security vulnerability risks evaluated
|
251
|
+
|
252
|
+
### 7.2 Rollback Strategy
|
253
|
+
|
254
|
+
- [ ] Rollback procedures clearly defined per story
|
255
|
+
- [ ] Feature flag strategy implemented
|
256
|
+
- [ ] Backup and recovery procedures updated
|
257
|
+
- [ ] Monitoring enhanced for new components
|
258
|
+
- [ ] Rollback triggers and thresholds defined
|
259
|
+
|
260
|
+
### 7.3 User Impact Mitigation
|
261
|
+
|
262
|
+
- [ ] Existing user workflows analyzed for impact
|
263
|
+
- [ ] User communication plan developed
|
264
|
+
- [ ] Training materials updated
|
265
|
+
- [ ] Support documentation comprehensive
|
266
|
+
- [ ] Migration path for user data validated
|
267
|
+
|
268
|
+
## 8. MVP SCOPE ALIGNMENT
|
269
|
+
|
270
|
+
[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
|
271
|
+
|
272
|
+
### 8.1 Core Goals Alignment
|
273
|
+
|
274
|
+
- [ ] All core goals from PRD are addressed
|
275
|
+
- [ ] Features directly support MVP goals
|
276
|
+
- [ ] No extraneous features beyond MVP scope
|
277
|
+
- [ ] Critical features prioritized appropriately
|
278
|
+
- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
|
279
|
+
|
280
|
+
### 8.2 User Journey Completeness
|
281
|
+
|
282
|
+
- [ ] All critical user journeys fully implemented
|
283
|
+
- [ ] Edge cases and error scenarios addressed
|
284
|
+
- [ ] User experience considerations included
|
285
|
+
- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
|
286
|
+
- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
|
287
|
+
|
288
|
+
### 8.3 Technical Requirements
|
289
|
+
|
290
|
+
- [ ] All technical constraints from PRD addressed
|
291
|
+
- [ ] Non-functional requirements incorporated
|
292
|
+
- [ ] Architecture decisions align with constraints
|
293
|
+
- [ ] Performance considerations addressed
|
294
|
+
- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
|
295
|
+
|
296
|
+
## 9. DOCUMENTATION & HANDOFF
|
297
|
+
|
298
|
+
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
299
|
+
|
300
|
+
### 9.1 Developer Documentation
|
301
|
+
|
302
|
+
- [ ] API documentation created alongside implementation
|
303
|
+
- [ ] Setup instructions are comprehensive
|
304
|
+
- [ ] Architecture decisions documented
|
305
|
+
- [ ] Patterns and conventions documented
|
306
|
+
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
307
|
+
|
308
|
+
### 9.2 User Documentation
|
309
|
+
|
310
|
+
- [ ] User guides or help documentation included if required
|
311
|
+
- [ ] Error messages and user feedback considered
|
312
|
+
- [ ] Onboarding flows fully specified
|
313
|
+
- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
|
314
|
+
|
315
|
+
### 9.3 Knowledge Transfer
|
316
|
+
|
317
|
+
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
318
|
+
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
319
|
+
- [ ] Code review knowledge sharing planned
|
320
|
+
- [ ] Deployment knowledge transferred to operations
|
321
|
+
- [ ] Historical context preserved
|
322
|
+
|
323
|
+
## 10. POST-MVP CONSIDERATIONS
|
324
|
+
|
325
|
+
[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
|
326
|
+
|
327
|
+
### 10.1 Future Enhancements
|
328
|
+
|
329
|
+
- [ ] Clear separation between MVP and future features
|
330
|
+
- [ ] Architecture supports planned enhancements
|
331
|
+
- [ ] Technical debt considerations documented
|
332
|
+
- [ ] Extensibility points identified
|
333
|
+
- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
|
334
|
+
|
335
|
+
### 10.2 Monitoring & Feedback
|
336
|
+
|
337
|
+
- [ ] Analytics or usage tracking included if required
|
338
|
+
- [ ] User feedback collection considered
|
339
|
+
- [ ] Monitoring and alerting addressed
|
340
|
+
- [ ] Performance measurement incorporated
|
341
|
+
- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
|
342
|
+
|
343
|
+
## VALIDATION SUMMARY
|
344
|
+
|
345
|
+
[[LLM: FINAL PO VALIDATION REPORT GENERATION
|
346
|
+
|
347
|
+
Generate a comprehensive validation report that adapts to project type:
|
348
|
+
|
349
|
+
1. Executive Summary
|
350
|
+
|
351
|
+
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
352
|
+
- Overall readiness (percentage)
|
353
|
+
- Go/No-Go recommendation
|
354
|
+
- Critical blocking issues count
|
355
|
+
- Sections skipped due to project type
|
356
|
+
|
357
|
+
2. Project-Specific Analysis
|
358
|
+
|
359
|
+
FOR GREENFIELD:
|
360
|
+
|
361
|
+
- Setup completeness
|
362
|
+
- Dependency sequencing
|
363
|
+
- MVP scope appropriateness
|
364
|
+
- Development timeline feasibility
|
365
|
+
|
366
|
+
FOR BROWNFIELD:
|
367
|
+
|
368
|
+
- Integration risk level (High/Medium/Low)
|
369
|
+
- Existing system impact assessment
|
370
|
+
- Rollback readiness
|
371
|
+
- User disruption potential
|
372
|
+
|
373
|
+
3. Risk Assessment
|
374
|
+
|
375
|
+
- Top 5 risks by severity
|
376
|
+
- Mitigation recommendations
|
377
|
+
- Timeline impact of addressing issues
|
378
|
+
- [BROWNFIELD] Specific integration risks
|
379
|
+
|
380
|
+
4. MVP Completeness
|
381
|
+
|
382
|
+
- Core features coverage
|
383
|
+
- Missing essential functionality
|
384
|
+
- Scope creep identified
|
385
|
+
- True MVP vs over-engineering
|
386
|
+
|
387
|
+
5. Implementation Readiness
|
388
|
+
|
389
|
+
- Developer clarity score (1-10)
|
390
|
+
- Ambiguous requirements count
|
391
|
+
- Missing technical details
|
392
|
+
- [BROWNFIELD] Integration point clarity
|
393
|
+
|
394
|
+
6. Recommendations
|
395
|
+
|
396
|
+
- Must-fix before development
|
397
|
+
- Should-fix for quality
|
398
|
+
- Consider for improvement
|
399
|
+
- Post-MVP deferrals
|
400
|
+
|
401
|
+
7. [BROWNFIELD ONLY] Integration Confidence
|
402
|
+
- Confidence in preserving existing functionality
|
403
|
+
- Rollback procedure completeness
|
404
|
+
- Monitoring coverage for integration points
|
405
|
+
- Support team readiness
|
406
|
+
|
407
|
+
After presenting the report, ask if the user wants:
|
408
|
+
|
409
|
+
- Detailed analysis of any failed sections
|
410
|
+
- Specific story reordering suggestions
|
411
|
+
- Risk mitigation strategies
|
412
|
+
- [BROWNFIELD] Integration risk deep-dive]]
|
413
|
+
|
414
|
+
### Category Statuses
|
415
|
+
|
416
|
+
| Category | Status | Critical Issues |
|
417
|
+
| --------------------------------------- | ------ | --------------- |
|
418
|
+
| 1. Project Setup & Initialization | _TBD_ | |
|
419
|
+
| 2. Infrastructure & Deployment | _TBD_ | |
|
420
|
+
| 3. External Dependencies & Integrations | _TBD_ | |
|
421
|
+
| 4. UI/UX Considerations | _TBD_ | |
|
422
|
+
| 5. User/Agent Responsibility | _TBD_ | |
|
423
|
+
| 6. Feature Sequencing & Dependencies | _TBD_ | |
|
424
|
+
| 7. Risk Management (Brownfield) | _TBD_ | |
|
425
|
+
| 8. MVP Scope Alignment | _TBD_ | |
|
426
|
+
| 9. Documentation & Handoff | _TBD_ | |
|
427
|
+
| 10. Post-MVP Considerations | _TBD_ | |
|
428
|
+
|
429
|
+
### Critical Deficiencies
|
430
|
+
|
431
|
+
(To be populated during validation)
|
432
|
+
|
433
|
+
### Recommendations
|
434
|
+
|
435
|
+
(To be populated during validation)
|
436
|
+
|
437
|
+
### Final Decision
|
438
|
+
|
439
|
+
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
440
|
+
- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
|
441
|
+
- **REJECTED**: The plan requires significant revision to address critical deficiencies.
|