schema standardization and bmad ide orchesatrtor can do anything
This commit is contained in:
Brian Madison
@@ -8,12 +8,24 @@ Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. architecture.md - The primary architecture document (check docs/architecture.md)
|
||||
2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
|
||||
3. Any system diagrams referenced in the architecture
|
||||
4. API documentation if available
|
||||
5. Technology stack details and version specifications
|
||||
3. frontend-architecture.md or fe-architecture.md - If this is a UI project (check docs/frontend-architecture.md)
|
||||
4. Any system diagrams referenced in the architecture
|
||||
5. API documentation if available
|
||||
6. Technology stack details and version specifications
|
||||
|
||||
IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
|
||||
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
- Does the architecture include a frontend/UI component?
|
||||
- Is there a frontend-architecture.md document?
|
||||
- Does the PRD mention user interfaces or frontend requirements?
|
||||
|
||||
If this is a backend-only or service-only project:
|
||||
- Skip sections marked with [[FRONTEND ONLY]]
|
||||
- Focus extra attention on API design, service architecture, and integration patterns
|
||||
- Note in your final report that frontend sections were skipped due to project type
|
||||
|
||||
VALIDATION APPROACH:
|
||||
For each section, you must:
|
||||
|
||||
@@ -104,7 +116,9 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Alternatives considered are documented with pros/cons
|
||||
- [ ] Selected stack components work well together
|
||||
|
||||
### 3.2 Frontend Architecture
|
||||
### 3.2 Frontend Architecture [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this entire section if this is a backend-only or service-only project. Only evaluate if the project includes a user interface.]]
|
||||
|
||||
- [ ] UI framework and libraries are specifically selected
|
||||
- [ ] State management approach is defined
|
||||
@@ -128,11 +142,63 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Data migration/seeding approach is specified
|
||||
- [ ] Data backup and recovery strategies are outlined
|
||||
|
||||
## 4. RESILIENCE & OPERATIONAL READINESS
|
||||
## 4. FRONTEND DESIGN & IMPLEMENTATION [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: This entire section should be skipped for backend-only projects. Only evaluate if the project includes a user interface. When evaluating, ensure alignment between the main architecture document and the frontend-specific architecture document.]]
|
||||
|
||||
### 4.1 Frontend Philosophy & Patterns
|
||||
|
||||
- [ ] Framework & Core Libraries align with main architecture document
|
||||
- [ ] Component Architecture (e.g., Atomic Design) is clearly described
|
||||
- [ ] State Management Strategy is appropriate for application complexity
|
||||
- [ ] Data Flow patterns are consistent and clear
|
||||
- [ ] Styling Approach is defined and tooling specified
|
||||
|
||||
### 4.2 Frontend Structure & Organization
|
||||
|
||||
- [ ] Directory structure is clearly documented with ASCII diagram
|
||||
- [ ] Component organization follows stated patterns
|
||||
- [ ] File naming conventions are explicit
|
||||
- [ ] Structure supports chosen framework's best practices
|
||||
- [ ] Clear guidance on where new components should be placed
|
||||
|
||||
### 4.3 Component Design
|
||||
|
||||
- [ ] Component template/specification format is defined
|
||||
- [ ] Component props, state, and events are well-documented
|
||||
- [ ] Shared/foundational components are identified
|
||||
- [ ] Component reusability patterns are established
|
||||
- [ ] Accessibility requirements are built into component design
|
||||
|
||||
### 4.4 Frontend-Backend Integration
|
||||
|
||||
- [ ] API interaction layer is clearly defined
|
||||
- [ ] HTTP client setup and configuration documented
|
||||
- [ ] Error handling for API calls is comprehensive
|
||||
- [ ] Service definitions follow consistent patterns
|
||||
- [ ] Authentication integration with backend is clear
|
||||
|
||||
### 4.5 Routing & Navigation
|
||||
|
||||
- [ ] Routing strategy and library are specified
|
||||
- [ ] Route definitions table is comprehensive
|
||||
- [ ] Route protection mechanisms are defined
|
||||
- [ ] Deep linking considerations addressed
|
||||
- [ ] Navigation patterns are consistent
|
||||
|
||||
### 4.6 Frontend Performance
|
||||
|
||||
- [ ] Image optimization strategies defined
|
||||
- [ ] Code splitting approach documented
|
||||
- [ ] Lazy loading patterns established
|
||||
- [ ] Re-render optimization techniques specified
|
||||
- [ ] Performance monitoring approach defined
|
||||
|
||||
## 5. RESILIENCE & OPERATIONAL READINESS
|
||||
|
||||
[[LLM: Production systems fail in unexpected ways. As you review this section, think about Murphy's Law - what could go wrong? Consider real-world scenarios: What happens during peak load? How does the system behave when a critical service is down? Can the operations team diagnose issues at 3 AM? Look for specific resilience patterns, not just mentions of "error handling".]]
|
||||
|
||||
### 4.1 Error Handling & Resilience
|
||||
### 5.1 Error Handling & Resilience
|
||||
|
||||
- [ ] Error handling strategy is comprehensive
|
||||
- [ ] Retry policies are defined where appropriate
|
||||
@@ -140,7 +206,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Graceful degradation approaches are defined
|
||||
- [ ] System can recover from partial failures
|
||||
|
||||
### 4.2 Monitoring & Observability
|
||||
### 5.2 Monitoring & Observability
|
||||
|
||||
- [ ] Logging strategy is defined
|
||||
- [ ] Monitoring approach is specified
|
||||
@@ -148,7 +214,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Alerting thresholds and strategies are outlined
|
||||
- [ ] Debugging and troubleshooting capabilities are built in
|
||||
|
||||
### 4.3 Performance & Scaling
|
||||
### 5.3 Performance & Scaling
|
||||
|
||||
- [ ] Performance bottlenecks are identified and addressed
|
||||
- [ ] Caching strategy is defined where appropriate
|
||||
@@ -156,7 +222,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Horizontal and vertical scaling strategies are outlined
|
||||
- [ ] Resource sizing recommendations are provided
|
||||
|
||||
### 4.4 Deployment & DevOps
|
||||
### 5.4 Deployment & DevOps
|
||||
|
||||
- [ ] Deployment strategy is defined
|
||||
- [ ] CI/CD pipeline approach is outlined
|
||||
@@ -164,11 +230,11 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Infrastructure as Code approach is defined
|
||||
- [ ] Rollback and recovery procedures are outlined
|
||||
|
||||
## 5. SECURITY & COMPLIANCE
|
||||
## 6. SECURITY & COMPLIANCE
|
||||
|
||||
[[LLM: Security is not optional. Review this section with a hacker's mindset - how could someone exploit this system? Also consider compliance: Are there industry-specific regulations that apply? GDPR? HIPAA? PCI? Ensure the architecture addresses these proactively. Look for specific security controls, not just general statements.]]
|
||||
|
||||
### 5.1 Authentication & Authorization
|
||||
### 6.1 Authentication & Authorization
|
||||
|
||||
- [ ] Authentication mechanism is clearly defined
|
||||
- [ ] Authorization model is specified
|
||||
@@ -176,7 +242,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Session management approach is defined
|
||||
- [ ] Credential management is addressed
|
||||
|
||||
### 5.2 Data Security
|
||||
### 6.2 Data Security
|
||||
|
||||
- [ ] Data encryption approach (at rest and in transit) is specified
|
||||
- [ ] Sensitive data handling procedures are defined
|
||||
@@ -184,7 +250,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Backup encryption is addressed if required
|
||||
- [ ] Data access audit trails are specified if required
|
||||
|
||||
### 5.3 API & Service Security
|
||||
### 6.3 API & Service Security
|
||||
|
||||
- [ ] API security controls are defined
|
||||
- [ ] Rate limiting and throttling approaches are specified
|
||||
@@ -192,7 +258,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] CSRF/XSS prevention measures are addressed
|
||||
- [ ] Secure communication protocols are specified
|
||||
|
||||
### 5.4 Infrastructure Security
|
||||
### 6.4 Infrastructure Security
|
||||
|
||||
- [ ] Network security design is outlined
|
||||
- [ ] Firewall and security group configurations are specified
|
||||
@@ -200,11 +266,11 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Least privilege principle is applied
|
||||
- [ ] Security monitoring strategy is outlined
|
||||
|
||||
## 6. IMPLEMENTATION GUIDANCE
|
||||
## 7. IMPLEMENTATION GUIDANCE
|
||||
|
||||
[[LLM: Clear implementation guidance prevents costly mistakes. As you review this section, imagine you're a developer starting on day one. Do they have everything they need to be productive? Are coding standards clear enough to maintain consistency across the team? Look for specific examples and patterns.]]
|
||||
|
||||
### 6.1 Coding Standards & Practices
|
||||
### 7.1 Coding Standards & Practices
|
||||
|
||||
- [ ] Coding standards are defined
|
||||
- [ ] Documentation requirements are specified
|
||||
@@ -212,7 +278,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Code organization principles are defined
|
||||
- [ ] Naming conventions are specified
|
||||
|
||||
### 6.2 Testing Strategy
|
||||
### 7.2 Testing Strategy
|
||||
|
||||
- [ ] Unit testing approach is defined
|
||||
- [ ] Integration testing strategy is outlined
|
||||
@@ -220,7 +286,17 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Performance testing requirements are outlined
|
||||
- [ ] Security testing approach is defined
|
||||
|
||||
### 6.3 Development Environment
|
||||
### 7.3 Frontend Testing [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this subsection for backend-only projects.]]
|
||||
|
||||
- [ ] Component testing scope and tools defined
|
||||
- [ ] UI integration testing approach specified
|
||||
- [ ] Visual regression testing considered
|
||||
- [ ] Accessibility testing tools identified
|
||||
- [ ] Frontend-specific test data management addressed
|
||||
|
||||
### 7.4 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is documented
|
||||
- [ ] Required tools and configurations are specified
|
||||
@@ -228,7 +304,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Source control practices are defined
|
||||
- [ ] Dependency management approach is specified
|
||||
|
||||
### 6.4 Technical Documentation
|
||||
### 7.5 Technical Documentation
|
||||
|
||||
- [ ] API documentation standards are defined
|
||||
- [ ] Architecture documentation requirements are specified
|
||||
@@ -236,11 +312,11 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] System diagrams and visualizations are included
|
||||
- [ ] Decision records for key choices are included
|
||||
|
||||
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||
## 8. DEPENDENCY & INTEGRATION MANAGEMENT
|
||||
|
||||
[[LLM: Dependencies are often the source of production issues. For each dependency, consider: What happens if it's unavailable? Is there a newer version with security patches? Are we locked into a vendor? What's our contingency plan? Verify specific versions and fallback strategies.]]
|
||||
|
||||
### 7.1 External Dependencies
|
||||
### 8.1 External Dependencies
|
||||
|
||||
- [ ] All external dependencies are identified
|
||||
- [ ] Versioning strategy for dependencies is defined
|
||||
@@ -248,7 +324,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Licensing implications are addressed
|
||||
- [ ] Update and patching strategy is outlined
|
||||
|
||||
### 7.2 Internal Dependencies
|
||||
### 8.2 Internal Dependencies
|
||||
|
||||
- [ ] Component dependencies are clearly mapped
|
||||
- [ ] Build order dependencies are addressed
|
||||
@@ -256,7 +332,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Circular dependencies are eliminated
|
||||
- [ ] Versioning strategy for internal components is defined
|
||||
|
||||
### 7.3 Third-Party Integrations
|
||||
### 8.3 Third-Party Integrations
|
||||
|
||||
- [ ] All third-party integrations are identified
|
||||
- [ ] Integration approaches are defined
|
||||
@@ -264,11 +340,11 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Error handling for integration failures is specified
|
||||
- [ ] Rate limits and quotas are considered
|
||||
|
||||
## 8. AI AGENT IMPLEMENTATION SUITABILITY
|
||||
## 9. AI AGENT IMPLEMENTATION SUITABILITY
|
||||
|
||||
[[LLM: This architecture may be implemented by AI agents. Review with extreme clarity in mind. Are patterns consistent? Is complexity minimized? Would an AI agent make incorrect assumptions? Remember: explicit is better than implicit. Look for clear file structures, naming conventions, and implementation patterns.]]
|
||||
|
||||
### 8.1 Modularity for AI Agents
|
||||
### 9.1 Modularity for AI Agents
|
||||
|
||||
- [ ] Components are sized appropriately for AI agent implementation
|
||||
- [ ] Dependencies between components are minimized
|
||||
@@ -276,7 +352,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Components have singular, well-defined responsibilities
|
||||
- [ ] File and code organization optimized for AI agent understanding
|
||||
|
||||
### 8.2 Clarity & Predictability
|
||||
### 9.2 Clarity & Predictability
|
||||
|
||||
- [ ] Patterns are consistent and predictable
|
||||
- [ ] Complex logic is broken down into simpler steps
|
||||
@@ -284,7 +360,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Examples are provided for unfamiliar patterns
|
||||
- [ ] Component responsibilities are explicit and clear
|
||||
|
||||
### 8.3 Implementation Guidance
|
||||
### 9.3 Implementation Guidance
|
||||
|
||||
- [ ] Detailed implementation guidance is provided
|
||||
- [ ] Code structure templates are defined
|
||||
@@ -292,7 +368,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Common pitfalls are identified with solutions
|
||||
- [ ] References to similar implementations are provided when helpful
|
||||
|
||||
### 8.4 Error Prevention & Handling
|
||||
### 9.4 Error Prevention & Handling
|
||||
|
||||
- [ ] Design reduces opportunities for implementation errors
|
||||
- [ ] Validation and error checking approaches are defined
|
||||
@@ -300,30 +376,48 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Testing patterns are clearly defined
|
||||
- [ ] Debugging guidance is provided
|
||||
|
||||
## 10. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
|
||||
|
||||
[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
|
||||
|
||||
### 10.1 Accessibility Standards
|
||||
|
||||
- [ ] Semantic HTML usage is emphasized
|
||||
- [ ] ARIA implementation guidelines provided
|
||||
- [ ] Keyboard navigation requirements defined
|
||||
- [ ] Focus management approach specified
|
||||
- [ ] Screen reader compatibility addressed
|
||||
|
||||
### 10.2 Accessibility Testing
|
||||
|
||||
- [ ] Accessibility testing tools identified
|
||||
- [ ] Testing process integrated into workflow
|
||||
- [ ] Compliance targets (WCAG level) specified
|
||||
- [ ] Manual testing procedures defined
|
||||
- [ ] Automated testing approach outlined
|
||||
|
||||
[[LLM: FINAL VALIDATION REPORT GENERATION
|
||||
|
||||
Now that you've completed the checklist, generate a comprehensive validation report that includes:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall architecture readiness (High/Medium/Low)
|
||||
- Critical risks identified
|
||||
- Key strengths of the architecture
|
||||
- Project type (Full-stack/Frontend/Backend) and sections evaluated
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section (percentage of items passed)
|
||||
- Most concerning failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
- Note any sections skipped due to project type
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations for each
|
||||
- Timeline impact of addressing issues
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
@@ -333,4 +427,10 @@ Now that you've completed the checklist, generate a comprehensive validation rep
|
||||
- Areas needing additional clarification
|
||||
- Complexity hotspots to address
|
||||
|
||||
After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]
|
||||
6. Frontend-Specific Assessment (if applicable)
|
||||
- Frontend architecture completeness
|
||||
- Alignment between main and frontend architecture docs
|
||||
- UI/UX specification coverage
|
||||
- Component design clarity
|
||||
|
||||
After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]
|
||||
@@ -1,480 +0,0 @@
|
||||
# Brownfield Enhancement Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for Product Owners to validate brownfield enhancements before development execution. It ensures thorough analysis of existing systems, proper integration planning, and risk mitigation for working with existing codebases.
|
||||
|
||||
[[LLM: CRITICAL INITIALIZATION - BROWNFIELD CONTEXT
|
||||
|
||||
This checklist requires extensive access to the existing project. Before proceeding, ensure you have:
|
||||
|
||||
1. brownfield-prd.md - The brownfield product requirements (check docs/brownfield-prd.md)
|
||||
2. brownfield-architecture.md - The enhancement architecture (check docs/brownfield-architecture.md)
|
||||
3. Existing Project Access:
|
||||
|
||||
- Full source code repository access
|
||||
- Current deployment configuration
|
||||
- Database schemas and data models
|
||||
- API documentation (internal and external)
|
||||
- Infrastructure configuration
|
||||
- CI/CD pipeline configuration
|
||||
- Current monitoring/logging setup
|
||||
|
||||
4. Optional but Valuable:
|
||||
- existing-project-docs.md
|
||||
- tech-stack.md with version details
|
||||
- source-tree.md or actual file structure
|
||||
- Performance benchmarks
|
||||
- Known issues/bug tracker access
|
||||
- Team documentation/wikis
|
||||
|
||||
IMPORTANT: If you don't have access to the existing project codebase, STOP and request access. Brownfield validation cannot be properly completed without examining the actual system being enhanced.
|
||||
|
||||
CRITICAL MINDSET: You are validating changes to a LIVE SYSTEM. Every decision has the potential to break existing functionality. Approach this with:
|
||||
|
||||
1. Extreme Caution - Assume every change could have unintended consequences
|
||||
2. Deep Investigation - Don't trust documentation alone, verify against actual code
|
||||
3. Integration Focus - The seams between new and old are where failures occur
|
||||
4. User Impact - Existing users depend on current functionality, preserve their workflows
|
||||
5. Technical Debt Awareness - Understand what compromises exist and why
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
|
||||
|
||||
## 1. EXISTING PROJECT ANALYSIS VALIDATION
|
||||
|
||||
[[LLM: Begin by conducting a thorough investigation of the existing system. Don't just read documentation - examine actual code, configuration files, and deployment scripts. Look for:
|
||||
|
||||
- Undocumented behaviors that users might depend on
|
||||
- Technical debt that could complicate integration
|
||||
- Patterns and conventions that new code must follow
|
||||
- Hidden dependencies not mentioned in documentation
|
||||
|
||||
As you validate each item below, cite specific files, code sections, or configuration details as evidence. For each check, provide specific examples from the codebase.]]
|
||||
|
||||
### 1.1 Project Documentation Completeness
|
||||
|
||||
- [ ] All required existing project documentation has been located and analyzed
|
||||
- [ ] Tech stack documentation is current and accurate
|
||||
- [ ] Source tree/architecture overview exists and is up-to-date
|
||||
- [ ] Coding standards documentation reflects actual codebase practices
|
||||
- [ ] API documentation exists and covers all active endpoints
|
||||
- [ ] External API integrations are documented with current versions
|
||||
- [ ] UX/UI guidelines exist and match current implementation
|
||||
- [ ] Any missing documentation has been identified and creation planned
|
||||
|
||||
### 1.2 Existing System Understanding
|
||||
|
||||
- [ ] Current project purpose and core functionality clearly understood
|
||||
- [ ] Existing technology stack versions accurately identified
|
||||
- [ ] Current architecture patterns and conventions documented
|
||||
- [ ] Existing deployment and infrastructure setup analyzed
|
||||
- [ ] Performance characteristics and constraints identified
|
||||
- [ ] Security measures and compliance requirements documented
|
||||
- [ ] Known technical debt and limitation areas identified
|
||||
- [ ] Active maintenance and support processes understood
|
||||
|
||||
### 1.3 Codebase Analysis Quality
|
||||
|
||||
- [ ] File structure and organization patterns documented
|
||||
- [ ] Naming conventions and coding patterns identified
|
||||
- [ ] Testing frameworks and patterns analyzed
|
||||
- [ ] Build and deployment processes understood
|
||||
- [ ] Dependency management approach documented
|
||||
- [ ] Configuration management patterns identified
|
||||
- [ ] Error handling and logging patterns documented
|
||||
- [ ] Integration points with external systems mapped
|
||||
|
||||
## 2. ENHANCEMENT SCOPE VALIDATION
|
||||
|
||||
[[LLM: The scope determines everything. Before validating, answer: Is this enhancement truly significant enough to warrant this comprehensive process, or would a simpler approach suffice? Consider:
|
||||
|
||||
- Could this be done as a simple feature addition?
|
||||
- Are we over-engineering the solution?
|
||||
- What's the minimum viable change that delivers value?
|
||||
- Are we addressing the root cause or just symptoms?
|
||||
|
||||
Be prepared to recommend a simpler approach if the current plan is overkill. If the enhancement could be done in 1-2 stories, suggest using brownfield-create-epic or brownfield-create-story instead.]]
|
||||
|
||||
### 2.1 Complexity Assessment
|
||||
|
||||
- [ ] Enhancement complexity properly assessed (significant vs. simple)
|
||||
- [ ] Scope justifies full PRD/Architecture process vs. simple epic/story creation
|
||||
- [ ] Enhancement type clearly categorized (new feature, modification, integration, etc.)
|
||||
- [ ] Impact assessment on existing codebase accurately evaluated
|
||||
- [ ] Resource requirements appropriate for enhancement scope
|
||||
- [ ] Timeline expectations realistic given existing system constraints
|
||||
- [ ] Success criteria defined and measurable
|
||||
- [ ] Rollback criteria and thresholds established
|
||||
|
||||
### 2.2 Integration Points Analysis
|
||||
|
||||
- [ ] All integration points with existing system identified
|
||||
- [ ] Data flow between new and existing components mapped
|
||||
- [ ] API integration requirements clearly defined
|
||||
- [ ] Database schema integration approach specified
|
||||
- [ ] UI/UX integration requirements documented
|
||||
- [ ] Authentication/authorization integration planned
|
||||
- [ ] External service integration impacts assessed
|
||||
- [ ] Performance impact on existing system evaluated
|
||||
|
||||
### 2.3 Compatibility Requirements
|
||||
|
||||
- [ ] Existing API compatibility requirements defined
|
||||
- [ ] Database schema backward compatibility ensured
|
||||
- [ ] UI/UX consistency requirements specified
|
||||
- [ ] Integration compatibility with existing workflows maintained
|
||||
- [ ] Third-party service compatibility verified
|
||||
- [ ] Browser/platform compatibility requirements unchanged
|
||||
- [ ] Performance compatibility maintained or improved
|
||||
- [ ] Security posture maintained or enhanced
|
||||
|
||||
## 3. RISK ASSESSMENT AND MITIGATION
|
||||
|
||||
[[LLM: This is the most critical section. Think like a pessimist - what's the worst that could happen? For each risk:
|
||||
|
||||
1. Identify specific code/configuration that could break
|
||||
2. Trace the potential cascade of failures
|
||||
3. Quantify the user impact (how many affected, how severely)
|
||||
4. Validate that mitigation strategies are concrete, not theoretical
|
||||
|
||||
Remember: In production, Murphy's Law is gospel. If it can fail, it will fail. For each risk identified, cite specific code locations and estimate blast radius.]]
|
||||
|
||||
### 3.1 Technical Risk Evaluation
|
||||
|
||||
- [ ] Risk of breaking existing functionality assessed
|
||||
- [ ] Database migration risks identified and mitigated
|
||||
- [ ] API breaking change risks evaluated
|
||||
- [ ] Deployment risks to existing system assessed
|
||||
- [ ] Performance degradation risks identified
|
||||
- [ ] Security vulnerability risks evaluated
|
||||
- [ ] Third-party service integration risks assessed
|
||||
- [ ] Data loss or corruption risks mitigated
|
||||
|
||||
### 3.2 Mitigation Strategy Completeness
|
||||
|
||||
- [ ] Rollback procedures clearly defined and tested
|
||||
- [ ] Feature flag strategy implemented for gradual rollout
|
||||
- [ ] Backup and recovery procedures updated
|
||||
- [ ] Monitoring and alerting enhanced for new components
|
||||
- [ ] Performance testing strategy includes existing functionality
|
||||
- [ ] Security testing covers integration points
|
||||
- [ ] User communication plan for changes prepared
|
||||
- [ ] Support team training plan developed
|
||||
|
||||
### 3.3 Testing Strategy Validation
|
||||
|
||||
- [ ] Regression testing strategy covers all existing functionality
|
||||
- [ ] Integration testing plan validates new-to-existing connections
|
||||
- [ ] Performance testing includes existing system baseline
|
||||
- [ ] Security testing covers enhanced attack surface
|
||||
- [ ] User acceptance testing includes existing workflows
|
||||
- [ ] Load testing validates system under enhanced load
|
||||
- [ ] Disaster recovery testing updated for new components
|
||||
- [ ] Automated test suite extended appropriately
|
||||
|
||||
## 4. ARCHITECTURE INTEGRATION VALIDATION
|
||||
|
||||
[[LLM: Architecture mismatches are subtle but deadly. As you review integration points:
|
||||
|
||||
1. Compare actual code patterns with proposed patterns - do they clash?
|
||||
2. Check version compatibility down to patch levels
|
||||
3. Verify assumptions about existing system behavior
|
||||
4. Look for impedance mismatches in data models, API styles, error handling
|
||||
5. Consider performance implications of integration overhead
|
||||
|
||||
If you find architectural incompatibilities, flag them as CRITICAL issues. Provide specific examples of pattern conflicts.]]
|
||||
|
||||
### 4.1 Technology Stack Alignment
|
||||
|
||||
- [ ] New technologies justified and compatible with existing stack
|
||||
- [ ] Version compatibility verified across all dependencies
|
||||
- [ ] Build process integration validated
|
||||
- [ ] Deployment pipeline integration planned
|
||||
- [ ] Configuration management approach consistent
|
||||
- [ ] Monitoring and logging integration maintained
|
||||
- [ ] Security tools and processes integration verified
|
||||
- [ ] Development environment setup updated appropriately
|
||||
|
||||
### 4.2 Component Integration Design
|
||||
|
||||
- [ ] New components follow existing architectural patterns
|
||||
- [ ] Component boundaries respect existing system design
|
||||
- [ ] Data models integrate properly with existing schema
|
||||
- [ ] API design consistent with existing endpoints
|
||||
- [ ] Error handling consistent with existing patterns
|
||||
- [ ] Authentication/authorization integration seamless
|
||||
- [ ] Caching strategy compatible with existing approach
|
||||
- [ ] Service communication patterns maintained
|
||||
|
||||
### 4.3 Code Organization Validation
|
||||
|
||||
- [ ] New code follows existing project structure conventions
|
||||
- [ ] File naming patterns consistent with existing codebase
|
||||
- [ ] Import/export patterns match existing conventions
|
||||
- [ ] Testing file organization follows existing patterns
|
||||
- [ ] Documentation approach consistent with existing standards
|
||||
- [ ] Configuration file patterns maintained
|
||||
- [ ] Asset organization follows existing conventions
|
||||
- [ ] Build output organization unchanged
|
||||
|
||||
## 5. IMPLEMENTATION PLANNING VALIDATION
|
||||
|
||||
[[LLM: Implementation sequence can make or break a brownfield project. Review the plan with these questions:
|
||||
|
||||
- Can each story be deployed without breaking existing functionality?
|
||||
- Are there hidden dependencies between stories?
|
||||
- Is there a clear rollback point for each story?
|
||||
- Will users experience degraded service during any phase?
|
||||
- Are we testing the integration points sufficiently at each step?
|
||||
|
||||
Pay special attention to data migrations - they're often the source of catastrophic failures. For each story, verify it maintains system integrity.]]
|
||||
|
||||
### 5.1 Story Sequencing Validation
|
||||
|
||||
- [ ] Stories properly sequenced to minimize risk to existing system
|
||||
- [ ] Each story maintains existing functionality integrity
|
||||
- [ ] Story dependencies clearly identified and logical
|
||||
- [ ] Rollback points defined for each story
|
||||
- [ ] Integration verification included in each story
|
||||
- [ ] Performance impact assessment included per story
|
||||
- [ ] User impact minimized through story sequencing
|
||||
- [ ] Value delivery incremental and testable
|
||||
|
||||
### 5.2 Development Approach Validation
|
||||
|
||||
- [ ] Development environment setup preserves existing functionality
|
||||
- [ ] Local testing approach validated for existing features
|
||||
- [ ] Code review process updated for integration considerations
|
||||
- [ ] Pair programming approach planned for critical integration points
|
||||
- [ ] Knowledge transfer plan for existing system context
|
||||
- [ ] Documentation update process defined
|
||||
- [ ] Communication plan for development team coordination
|
||||
- [ ] Timeline buffer included for integration complexity
|
||||
|
||||
### 5.3 Deployment Strategy Validation
|
||||
|
||||
- [ ] Deployment approach minimizes downtime
|
||||
- [ ] Blue-green or canary deployment strategy implemented
|
||||
- [ ] Database migration strategy tested and validated
|
||||
- [ ] Configuration management updated appropriately
|
||||
- [ ] Environment-specific considerations addressed
|
||||
- [ ] Health checks updated for new components
|
||||
- [ ] Monitoring dashboards updated for new metrics
|
||||
- [ ] Incident response procedures updated
|
||||
|
||||
## 6. STAKEHOLDER ALIGNMENT VALIDATION
|
||||
|
||||
[[LLM: Stakeholder surprises kill brownfield projects. Validate that:
|
||||
|
||||
1. ALL affected users have been identified (not just the obvious ones)
|
||||
2. Impact on each user group is documented and communicated
|
||||
3. Training needs are realistic (users resist change)
|
||||
4. Support team is genuinely prepared (not just informed)
|
||||
5. Business continuity isn't just assumed - it's planned
|
||||
|
||||
Look for hidden stakeholders - that batch job that runs at 2 AM, the partner API that depends on current behavior, the report that expects specific data formats. Check cron jobs, scheduled tasks, and external integrations.]]
|
||||
|
||||
### 6.1 User Impact Assessment
|
||||
|
||||
- [ ] Existing user workflows analyzed for impact
|
||||
- [ ] User communication plan developed for changes
|
||||
- [ ] Training materials updated for new functionality
|
||||
- [ ] Support documentation updated comprehensively
|
||||
- [ ] User feedback collection plan implemented
|
||||
- [ ] Accessibility requirements maintained or improved
|
||||
- [ ] Performance expectations managed appropriately
|
||||
- [ ] Migration path for existing user data validated
|
||||
|
||||
### 6.2 Team Readiness Validation
|
||||
|
||||
- [ ] Development team familiar with existing codebase
|
||||
- [ ] QA team understands existing test coverage
|
||||
- [ ] DevOps team prepared for enhanced deployment complexity
|
||||
- [ ] Support team trained on new functionality
|
||||
- [ ] Product team aligned on success metrics
|
||||
- [ ] Stakeholders informed of timeline and scope
|
||||
- [ ] Resource allocation appropriate for enhanced complexity
|
||||
- [ ] Escalation procedures defined for integration issues
|
||||
|
||||
### 6.3 Business Continuity Validation
|
||||
|
||||
- [ ] Critical business processes remain uninterrupted
|
||||
- [ ] SLA requirements maintained throughout enhancement
|
||||
- [ ] Customer impact minimized and communicated
|
||||
- [ ] Revenue-generating features protected during enhancement
|
||||
- [ ] Compliance requirements maintained throughout process
|
||||
- [ ] Audit trail requirements preserved
|
||||
- [ ] Data retention policies unaffected
|
||||
- [ ] Business intelligence and reporting continuity maintained
|
||||
|
||||
## 7. DOCUMENTATION AND COMMUNICATION VALIDATION
|
||||
|
||||
[[LLM: In brownfield projects, documentation gaps cause integration failures. Verify that:
|
||||
|
||||
1. Documentation accurately reflects the current state (not the ideal state)
|
||||
2. Integration points are documented with excessive detail
|
||||
3. "Tribal knowledge" has been captured in writing
|
||||
4. Change impacts are documented for every affected component
|
||||
5. Runbooks are updated for new failure modes
|
||||
|
||||
If existing documentation is poor, this enhancement must improve it - technical debt compounds. Check actual code vs documentation for discrepancies.]]
|
||||
|
||||
### 7.1 Documentation Standards
|
||||
|
||||
- [ ] Enhancement documentation follows existing project standards
|
||||
- [ ] Architecture documentation updated to reflect integration
|
||||
- [ ] API documentation updated for new/changed endpoints
|
||||
- [ ] User documentation updated for new functionality
|
||||
- [ ] Developer documentation includes integration guidance
|
||||
- [ ] Deployment documentation updated for enhanced process
|
||||
- [ ] Troubleshooting guides updated for new components
|
||||
- [ ] Change log properly maintained with detailed entries
|
||||
|
||||
### 7.2 Communication Plan Validation
|
||||
|
||||
- [ ] Stakeholder communication plan covers all affected parties
|
||||
- [ ] Technical communication includes integration considerations
|
||||
- [ ] User communication addresses workflow changes
|
||||
- [ ] Timeline communication includes integration complexity buffers
|
||||
- [ ] Risk communication includes mitigation strategies
|
||||
- [ ] Success criteria communication aligned with measurements
|
||||
- [ ] Feedback collection mechanisms established
|
||||
- [ ] Escalation communication procedures defined
|
||||
|
||||
### 7.3 Knowledge Transfer Planning
|
||||
|
||||
- [ ] Existing system knowledge captured and accessible
|
||||
- [ ] New functionality knowledge transfer plan developed
|
||||
- [ ] Integration points knowledge documented comprehensively
|
||||
- [ ] Troubleshooting knowledge base updated
|
||||
- [ ] Code review knowledge shared across team
|
||||
- [ ] Deployment knowledge transferred to operations team
|
||||
- [ ] Monitoring and alerting knowledge documented
|
||||
- [ ] Historical context preserved for future enhancements
|
||||
|
||||
## 8. SUCCESS METRICS AND MONITORING VALIDATION
|
||||
|
||||
[[LLM: Success in brownfield isn't just about new features working - it's about everything still working. Ensure:
|
||||
|
||||
1. Baseline metrics for existing functionality are captured
|
||||
2. Degradation thresholds are defined (when do we rollback?)
|
||||
3. New monitoring covers integration points, not just new components
|
||||
4. Success criteria include "no regression" metrics
|
||||
5. Long-term metrics capture gradual degradation
|
||||
|
||||
Without proper baselines, you can't prove the enhancement didn't break anything. Verify specific metrics and thresholds.]]
|
||||
|
||||
### 8.1 Success Criteria Definition
|
||||
|
||||
- [ ] Enhancement success metrics clearly defined and measurable
|
||||
- [ ] Existing system performance baselines established
|
||||
- [ ] User satisfaction metrics include existing functionality
|
||||
- [ ] Business impact metrics account for integration complexity
|
||||
- [ ] Technical health metrics cover enhanced system
|
||||
- [ ] Quality metrics include regression prevention
|
||||
- [ ] Timeline success criteria realistic for brownfield complexity
|
||||
- [ ] Resource utilization metrics appropriate for enhanced system
|
||||
|
||||
### 8.2 Monitoring Strategy Validation
|
||||
|
||||
- [ ] Existing monitoring capabilities preserved and enhanced
|
||||
- [ ] New component monitoring integrated with existing dashboards
|
||||
- [ ] Alert thresholds updated for enhanced system complexity
|
||||
- [ ] Log aggregation includes new components appropriately
|
||||
- [ ] Performance monitoring covers integration points
|
||||
- [ ] Security monitoring enhanced for new attack surfaces
|
||||
- [ ] User experience monitoring includes existing workflows
|
||||
- [ ] Business metrics monitoring updated for enhanced functionality
|
||||
|
||||
### 8.3 Feedback and Iteration Planning
|
||||
|
||||
- [ ] User feedback collection includes existing functionality assessment
|
||||
- [ ] Technical feedback loops established for integration health
|
||||
- [ ] Performance feedback includes existing system impact
|
||||
- [ ] Business feedback loops capture integration value
|
||||
- [ ] Iteration planning includes integration refinement
|
||||
- [ ] Continuous improvement process updated for enhanced complexity
|
||||
- [ ] Learning capture process includes integration lessons
|
||||
- [ ] Future enhancement planning considers established integration patterns
|
||||
|
||||
---
|
||||
|
||||
## CHECKLIST COMPLETION VALIDATION
|
||||
|
||||
### Final Validation Steps
|
||||
|
||||
- [ ] All sections completed with evidence and documentation
|
||||
- [ ] Critical risks identified and mitigation strategies implemented
|
||||
- [ ] Stakeholder sign-off obtained for high-risk integration decisions
|
||||
- [ ] Go/no-go decision criteria established with clear thresholds
|
||||
- [ ] Rollback triggers and procedures tested and validated
|
||||
- [ ] Success metrics baseline established and monitoring confirmed
|
||||
- [ ] Team readiness confirmed through final review and sign-off
|
||||
- [ ] Communication plan activated and stakeholders informed
|
||||
|
||||
### Documentation Artifacts
|
||||
|
||||
- [ ] Completed brownfield PRD with validated existing system analysis
|
||||
- [ ] Completed brownfield architecture with integration specifications
|
||||
- [ ] Risk assessment document with mitigation strategies
|
||||
- [ ] Integration testing plan with existing system coverage
|
||||
- [ ] Deployment plan with rollback procedures
|
||||
- [ ] Monitoring and alerting configuration updates
|
||||
- [ ] Team readiness assessment with training completion
|
||||
- [ ] Stakeholder communication plan with timeline and milestones
|
||||
|
||||
---
|
||||
|
||||
**Checklist Completion Date:** **\*\***\_\_\_**\*\***
|
||||
**Product Owner Signature:** **\*\***\_\_\_**\*\***
|
||||
**Technical Lead Approval:** **\*\***\_\_\_**\*\***
|
||||
**Stakeholder Sign-off:** **\*\***\_\_\_**\*\***
|
||||
|
||||
[[LLM: FINAL BROWNFIELD VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive brownfield validation report with special attention to integration risks:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Enhancement readiness: GO / NO-GO / CONDITIONAL
|
||||
- Critical integration risks identified
|
||||
- Estimated risk to existing functionality (High/Medium/Low)
|
||||
- Confidence level in success (percentage with justification)
|
||||
|
||||
2. Integration Risk Analysis
|
||||
|
||||
- Top 5 integration risks by severity
|
||||
- Specific code/components at risk
|
||||
- User impact if risks materialize
|
||||
- Mitigation effectiveness assessment
|
||||
|
||||
3. Existing System Impact
|
||||
|
||||
- Features/workflows that could be affected
|
||||
- Performance impact predictions
|
||||
- Security posture changes
|
||||
- Technical debt introduced vs. resolved
|
||||
|
||||
4. Go/No-Go Recommendation
|
||||
|
||||
- Must-fix items before proceeding
|
||||
- Acceptable risks with mitigation
|
||||
- Success probability assessment
|
||||
- Alternative approaches if No-Go
|
||||
|
||||
5. Rollback Readiness
|
||||
|
||||
- Rollback procedure completeness
|
||||
- Time to rollback estimate
|
||||
- Data recovery considerations
|
||||
- User communication plan
|
||||
|
||||
6. 30-60-90 Day Outlook
|
||||
- Expected issues in first 30 days
|
||||
- Monitoring focus areas
|
||||
- Success validation milestones
|
||||
- Long-term integration health indicators
|
||||
|
||||
After presenting this report, offer to deep-dive into any section, especially high-risk areas or failed validations. Ask if the user wants specific recommendations for reducing integration risks.]]
|
||||
@@ -1,315 +0,0 @@
|
||||
# Frontend Architecture Document Review Checklist
|
||||
|
||||
## Purpose
|
||||
|
||||
This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - FRONTEND ARCHITECTURE VALIDATION
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
|
||||
1. frontend-architecture.md or fe-architecture.md - The frontend architecture document (check docs/frontend-architecture.md or docs/fe-architecture.md)
|
||||
2. architecture.md - Main architecture document for alignment verification
|
||||
3. UI/UX specifications or design files (Figma, Sketch, etc.)
|
||||
4. Any component library documentation or design system references
|
||||
5. Technology stack specifications from main architecture
|
||||
|
||||
IMPORTANT: If the frontend architecture document is missing, immediately ask the user for its location. This checklist cannot proceed without it.
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Cross-Reference - Verify alignment with main architecture document
|
||||
2. Completeness - Ensure all template sections are properly filled
|
||||
3. Consistency - Check that patterns and conventions are uniform
|
||||
4. Implementability - Verify an AI agent could implement from these specs
|
||||
5. Best Practices - Ensure modern frontend practices are followed
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
|
||||
|
||||
---
|
||||
|
||||
## I. Introduction
|
||||
|
||||
[[LLM: Verify all links and references are present and functional. If any links are broken or missing, note them as failures. The introduction sets the context for the entire document.]]
|
||||
|
||||
- [ ] Is the `{Project Name}` correctly filled in throughout the Introduction?
|
||||
- [ ] Is the link to the Main Architecture Document present and correct?
|
||||
- [ ] Is the link to the UI/UX Specification present and correct?
|
||||
- [ ] Is the link to the Primary Design Files (Figma, Sketch, etc.) present and correct?
|
||||
- [ ] Is the link to a Deployed Storybook / Component Showcase included, if applicable and available?
|
||||
|
||||
## II. Overall Frontend Philosophy & Patterns
|
||||
|
||||
[[LLM: This section is critical for consistency. Verify that:
|
||||
|
||||
1. The chosen patterns align with the tech stack in the main architecture
|
||||
2. The philosophy is clear enough for consistent implementation
|
||||
3. State management approach matches the application's complexity
|
||||
4. No conflicting patterns are specified
|
||||
|
||||
Pay special attention to alignment with the main architecture document - any mismatches here will cause implementation problems.]]
|
||||
|
||||
- [ ] Are the chosen Framework & Core Libraries clearly stated and aligned with the main architecture document?
|
||||
- [ ] Is the Component Architecture (e.g., Atomic Design, Presentational/Container) clearly described?
|
||||
- [ ] Is the State Management Strategy (e.g., Redux Toolkit, Zustand) clearly described at a high level?
|
||||
- [ ] Is the Data Flow (e.g., Unidirectional) clearly explained?
|
||||
- [ ] Is the Styling Approach (e.g., CSS Modules, Tailwind CSS) clearly defined?
|
||||
- [ ] Are Key Design Patterns to be employed (e.g., Provider, Hooks) listed?
|
||||
- [ ] Does this section align with "Definitive Tech Stack Selections" in the main architecture document?
|
||||
- [ ] Are implications from overall system architecture (monorepo/polyrepo, backend services) considered?
|
||||
|
||||
## III. Detailed Frontend Directory Structure
|
||||
|
||||
[[LLM: The directory structure is the blueprint for code organization. Verify:
|
||||
|
||||
1. The ASCII diagram is clear and complete
|
||||
2. Structure follows the stated patterns from Section II
|
||||
3. Conventions are explicit (where do new components go?)
|
||||
4. Structure supports the chosen framework's best practices
|
||||
|
||||
An AI agent should be able to know exactly where to place any new file based on this structure.]]
|
||||
|
||||
- [ ] Is an ASCII diagram representing the frontend application's folder structure provided?
|
||||
- [ ] Is the diagram clear, accurate, and reflective of the chosen framework/patterns?
|
||||
- [ ] Are conventions for organizing components, pages, services, state, styles, etc., highlighted?
|
||||
- [ ] Are notes explaining specific conventions or rationale for the structure present and clear?
|
||||
|
||||
## IV. Component Breakdown & Implementation Details
|
||||
|
||||
[[LLM: Component specifications are crucial for consistent implementation. For this section:
|
||||
|
||||
1. Verify the template itself is complete with all required fields
|
||||
2. Check that any example components follow the template exactly
|
||||
3. Ensure naming conventions are clear and followable
|
||||
4. Validate that the level of detail is sufficient for implementation
|
||||
|
||||
The component template should be so clear that every component built follows the same pattern.]]
|
||||
|
||||
### Component Naming & Organization
|
||||
|
||||
- [ ] Are conventions for naming components (e.g., PascalCase) described?
|
||||
- [ ] Is the organization of components on the filesystem clearly explained (reiterating from directory structure if needed)?
|
||||
|
||||
### Template for Component Specification
|
||||
|
||||
- [ ] Is the "Template for Component Specification" itself complete and well-defined?
|
||||
- [ ] Does it include fields for: Purpose, Source File(s), Visual Reference?
|
||||
- [ ] Does it include a table structure for Props (Name, Type, Required, Default, Description)?
|
||||
- [ ] Does it include a table structure for Internal State (Variable, Type, Initial Value, Description)?
|
||||
- [ ] Does it include a section for Key UI Elements / Structure (textual or pseudo-HTML)?
|
||||
- [ ] Does it include a section for Events Handled / Emitted?
|
||||
- [ ] Does it include a section for Actions Triggered (State Management, API Calls)?
|
||||
- [ ] Does it include a section for Styling Notes?
|
||||
- [ ] Does it include a section for Accessibility Notes?
|
||||
- [ ] Is there a clear statement that this template should be used for most feature-specific components?
|
||||
|
||||
### Foundational/Shared Components (if any specified upfront)
|
||||
|
||||
- [ ] If any foundational/shared UI components are specified, do they follow the "Template for Component Specification"?
|
||||
- [ ] Is the rationale for specifying these components upfront clear?
|
||||
|
||||
## V. State Management In-Depth
|
||||
|
||||
[[LLM: State management is often where frontend apps become complex. Validate:
|
||||
|
||||
1. The chosen solution matches the app's needs (not over/under-engineered)
|
||||
2. Store structure is clearly defined with examples
|
||||
3. Patterns for async operations are specified
|
||||
4. Selector patterns promote performance
|
||||
5. The approach scales with application growth
|
||||
|
||||
Look for specific examples and templates, not just high-level descriptions.]]
|
||||
|
||||
- [ ] Is the chosen State Management Solution reiterated and rationale briefly provided (if not fully covered in main arch doc)?
|
||||
- [ ] Are conventions for Store Structure / Slices clearly defined (e.g., location, feature-based slices)?
|
||||
- [ ] If a Core Slice Example (e.g., `sessionSlice`) is provided:
|
||||
- [ ] Is its purpose clear?
|
||||
- [ ] Is its State Shape defined (e.g., using TypeScript interface)?
|
||||
- [ ] Are its Key Reducers/Actions listed?
|
||||
- [ ] Is a Feature Slice Template provided, outlining purpose, state shape, and key reducers/actions to be filled in?
|
||||
- [ ] Are conventions for Key Selectors noted (e.g., use `createSelector`)?
|
||||
- [ ] Are examples of Key Selectors for any core slices provided?
|
||||
- [ ] Are conventions for Key Actions / Reducers / Thunks (especially async) described?
|
||||
- [ ] Is an example of a Core Action/Thunk (e.g., `authenticateUser`) provided, detailing its purpose and dispatch flow?
|
||||
- [ ] Is a Feature Action/Thunk Template provided for feature-specific async operations?
|
||||
|
||||
## VI. API Interaction Layer
|
||||
|
||||
[[LLM: API integration is where frontend meets backend. Verify:
|
||||
|
||||
1. HTTP client setup is complete with all configurations
|
||||
2. Error handling is comprehensive (network, timeout, 4xx, 5xx)
|
||||
3. Service definitions follow a consistent pattern
|
||||
4. Authentication/authorization integration is clear
|
||||
5. Retry logic doesn't create cascading failures
|
||||
|
||||
This section should prevent any ambiguity in how the frontend communicates with backends.]]
|
||||
|
||||
- [ ] Is the HTTP Client Setup detailed (e.g., Axios instance, Fetch wrapper, base URL, default headers, interceptors)?
|
||||
- [ ] Are Service Definitions conventions explained?
|
||||
- [ ] Is an example of a service (e.g., `userService.ts`) provided, including its purpose and example functions?
|
||||
- [ ] Is Global Error Handling for API calls described (e.g., toast notifications, global error state)?
|
||||
- [ ] Is guidance on Specific Error Handling within components provided?
|
||||
- [ ] Is any client-side Retry Logic for API calls detailed and configured?
|
||||
|
||||
## VII. Routing Strategy
|
||||
|
||||
[[LLM: Routing defines the application's navigation structure. Check:
|
||||
|
||||
1. All major application routes are defined
|
||||
2. Protection mechanisms are clearly specified
|
||||
3. Route patterns are consistent and predictable
|
||||
4. Deep linking considerations are addressed
|
||||
5. Route guards integrate with authentication properly
|
||||
|
||||
The routing table should be comprehensive enough to understand the entire app structure.]]
|
||||
|
||||
- [ ] Is the chosen Routing Library stated?
|
||||
- [ ] Is a table of Route Definitions provided?
|
||||
- [ ] Does it include Path Pattern, Component/Page, Protection status, and Notes for each route?
|
||||
- [ ] Are all key application routes listed?
|
||||
- [ ] Is the Authentication Guard mechanism for protecting routes described?
|
||||
- [ ] Is the Authorization Guard mechanism (if applicable for roles/permissions) described?
|
||||
|
||||
## VIII. Build, Bundling, and Deployment
|
||||
|
||||
[[LLM: Build and deployment directly impact performance and reliability. Validate:
|
||||
|
||||
1. Build scripts are clearly documented
|
||||
2. Environment variable handling is secure and clear
|
||||
3. Optimization strategies are appropriate for the app size
|
||||
4. Deployment platform is compatible with the build output
|
||||
5. Caching strategies won't cause stale content issues
|
||||
|
||||
Look for specific commands and configurations, not general statements.]]
|
||||
|
||||
- [ ] Are Key Build Scripts (e.g., `npm run build`) listed and their purpose explained?
|
||||
- [ ] Is the handling of Environment Variables during the build process described for different environments?
|
||||
- [ ] Is Code Splitting strategy detailed (e.g., route-based, component-based)?
|
||||
- [ ] Is Tree Shaking confirmed or explained?
|
||||
- [ ] Is Lazy Loading strategy (for components, images, routes) outlined?
|
||||
- [ ] Is Minification & Compression by build tools mentioned?
|
||||
- [ ] Is the Target Deployment Platform (e.g., Vercel, Netlify) specified?
|
||||
- [ ] Is the Deployment Trigger (e.g., Git push via CI/CD) described, referencing the main CI/CD pipeline?
|
||||
- [ ] Is the Asset Caching Strategy (CDN/browser) for static assets outlined?
|
||||
|
||||
## IX. Frontend Testing Strategy
|
||||
|
||||
[[LLM: Testing ensures quality and prevents regressions. Verify:
|
||||
|
||||
1. Testing layers are appropriate (unit, integration, e2e)
|
||||
2. Tools are specified and compatible with the tech stack
|
||||
3. Test file locations follow a clear pattern
|
||||
4. Testing scope is realistic and valuable
|
||||
5. Test data management is addressed
|
||||
|
||||
The strategy should be specific enough to start writing tests immediately.]]
|
||||
|
||||
- [ ] Is there a link to the Main Testing Strategy document/section, and is it correct?
|
||||
- [ ] For Component Testing:
|
||||
- [ ] Is the Scope clearly defined?
|
||||
- [ ] Are the Tools listed?
|
||||
- [ ] Is the Focus of tests (rendering, props, interactions) clear?
|
||||
- [ ] Is the Location of test files specified?
|
||||
- [ ] For UI Integration/Flow Testing:
|
||||
- [ ] Is the Scope (interactions between multiple components) clear?
|
||||
- [ ] Are the Tools listed (can be same as component testing)?
|
||||
- [ ] Is the Focus of these tests clear?
|
||||
- [ ] For End-to-End UI Testing:
|
||||
- [ ] Are the Tools (e.g., Playwright, Cypress) reiterated from main strategy?
|
||||
- [ ] Is the Scope (key user journeys for frontend) defined?
|
||||
- [ ] Is Test Data Management for UI E2E tests addressed?
|
||||
|
||||
## X. Accessibility (AX) Implementation Details
|
||||
|
||||
[[LLM: Accessibility is not optional - it's a core requirement. Check:
|
||||
|
||||
1. Semantic HTML usage is emphasized
|
||||
2. ARIA guidance is practical and specific
|
||||
3. Keyboard navigation is comprehensively addressed
|
||||
4. Testing tools and processes are defined
|
||||
5. Accessibility is integrated into the development workflow
|
||||
|
||||
This section should prevent accessibility from being an afterthought.]]
|
||||
|
||||
- [ ] Is there an emphasis on using Semantic HTML?
|
||||
- [ ] Are guidelines for ARIA Implementation (roles, states, properties for custom components) provided?
|
||||
- [ ] Are requirements for Keyboard Navigation (all interactive elements focusable/operable) stated?
|
||||
- [ ] Is Focus Management (for modals, dynamic content) addressed?
|
||||
- [ ] Are Testing Tools for AX (e.g., Axe DevTools, Lighthouse) listed?
|
||||
- [ ] Does this section align with AX requirements from the UI/UX Specification?
|
||||
|
||||
## XI. Performance Considerations
|
||||
|
||||
[[LLM: Performance directly impacts user experience. Validate:
|
||||
|
||||
1. Image optimization strategies are concrete
|
||||
2. Code splitting approach matches app architecture
|
||||
3. Re-render optimization techniques are specified
|
||||
4. Performance monitoring is built-in from the start
|
||||
5. Performance budgets or targets are defined
|
||||
|
||||
Look for specific techniques and tools, not just aspirational statements.]]
|
||||
|
||||
- [ ] Is Image Optimization (formats, responsive images, lazy loading) discussed?
|
||||
- [ ] Is Code Splitting & Lazy Loading (impact on perceived performance) reiterated if necessary?
|
||||
- [ ] Are techniques for Minimizing Re-renders (e.g., `React.memo`) mentioned?
|
||||
- [ ] Is the use of Debouncing/Throttling for event handlers considered?
|
||||
- [ ] Is Virtualization for long lists/large data sets mentioned if applicable?
|
||||
- [ ] Are Client-Side Caching Strategies (browser cache, service workers) discussed if relevant?
|
||||
- [ ] Are Performance Monitoring Tools (e.g., Lighthouse, DevTools) listed?
|
||||
|
||||
## XII. Change Log
|
||||
|
||||
- [ ] Is the Change Log table present and initialized?
|
||||
- [ ] Is there a process for updating the change log as the document evolves?
|
||||
|
||||
---
|
||||
|
||||
## Final Review Sign-off
|
||||
|
||||
[[LLM: FINAL VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive frontend architecture validation report:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Document completeness (percentage of sections properly filled)
|
||||
- Alignment with main architecture (High/Medium/Low)
|
||||
- Implementation readiness (Ready/Needs Work/Not Ready)
|
||||
- Critical gaps identified
|
||||
|
||||
2. Section Analysis
|
||||
|
||||
- Pass rate for each major section
|
||||
- Most critical failures or gaps
|
||||
- Sections requiring immediate attention
|
||||
|
||||
3. Technical Concerns
|
||||
|
||||
- Potential implementation challenges
|
||||
- Inconsistencies between sections
|
||||
- Missing critical information
|
||||
- Over-engineering concerns
|
||||
|
||||
4. Recommendations
|
||||
|
||||
- Must-fix items before development
|
||||
- Should-fix items for better quality
|
||||
- Nice-to-have improvements
|
||||
|
||||
5. AI Implementation Assessment
|
||||
- Clarity score for AI implementation (1-10)
|
||||
- Ambiguous areas needing clarification
|
||||
- Missing examples or templates
|
||||
|
||||
After presenting the report, ask if the user wants detailed analysis of any specific section, especially those with failures or concerns.]]
|
||||
|
||||
- [ ] Have all placeholders (e.g., `{Project Name}`, `{e.g., ...}`) been filled in or removed where appropriate?
|
||||
- [ ] Has the document been reviewed for clarity, consistency, and completeness by the Design Architect?
|
||||
- [ ] Are all linked documents (Main Architecture, UI/UX Spec) finalized or stable enough for this document to rely on?
|
||||
- [ ] Is the document ready to be shared with the development team?
|
||||
@@ -1,83 +1,112 @@
|
||||
# Product Owner (PO) Validation Checklist
|
||||
# Product Owner (PO) Master Validation Checklist
|
||||
|
||||
This checklist serves as a comprehensive framework for the Product Owner to validate the complete MVP plan before development execution. The PO should systematically work through each item, documenting compliance status and noting any deficiencies.
|
||||
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.
|
||||
|
||||
[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
|
||||
|
||||
Before proceeding with this checklist, ensure you have access to:
|
||||
PROJECT TYPE DETECTION:
|
||||
First, determine the project type by checking:
|
||||
|
||||
1. prd.md - The Product Requirements Document (check docs/prd.md)
|
||||
2. architecture.md - The system architecture (check docs/architecture.md)
|
||||
3. frontend-architecture.md - If applicable (check docs/frontend-architecture.md or docs/fe-architecture.md)
|
||||
4. All epic and story definitions
|
||||
5. Any technical specifications or constraints
|
||||
1. Is this a GREENFIELD project (new from scratch)?
|
||||
|
||||
IMPORTANT: This checklist validates the COMPLETE MVP plan. All documents should be finalized before running this validation.
|
||||
- Look for: New project initialization, no existing codebase references
|
||||
- Check for: prd.md, architecture.md, new project setup stories
|
||||
|
||||
VALIDATION FOCUS:
|
||||
2. Is this a BROWNFIELD project (enhancing existing system)?
|
||||
|
||||
1. Sequencing - Are things built in the right order?
|
||||
2. Dependencies - Are all prerequisites in place before they're needed?
|
||||
3. Completeness - Is everything needed for MVP included?
|
||||
4. Clarity - Can developers implement without confusion?
|
||||
5. Feasibility - Is the plan realistic and achievable?
|
||||
- Look for: References to existing codebase, enhancement/modification language
|
||||
- Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
|
||||
|
||||
3. Does the project include UI/UX components?
|
||||
- Check for: frontend-architecture.md, UI/UX specifications, design files
|
||||
- Look for: Frontend stories, component specifications, user interface mentions
|
||||
|
||||
DOCUMENT REQUIREMENTS:
|
||||
Based on project type, ensure you have access to:
|
||||
|
||||
For GREENFIELD projects:
|
||||
|
||||
- prd.md - The Product Requirements Document
|
||||
- architecture.md - The system architecture
|
||||
- frontend-architecture.md - If UI/UX is involved
|
||||
- All epic and story definitions
|
||||
|
||||
For BROWNFIELD projects:
|
||||
|
||||
- brownfield-prd.md - The brownfield enhancement requirements
|
||||
- brownfield-architecture.md - The enhancement architecture
|
||||
- Existing project codebase access (CRITICAL - cannot proceed without this)
|
||||
- Current deployment configuration and infrastructure details
|
||||
- Database schemas, API documentation, monitoring setup
|
||||
|
||||
SKIP INSTRUCTIONS:
|
||||
|
||||
- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
|
||||
- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
|
||||
- Skip sections marked [[UI/UX ONLY]] for backend-only projects
|
||||
- Note all skipped sections in your final report
|
||||
|
||||
VALIDATION APPROACH:
|
||||
|
||||
1. Deep Analysis - Thoroughly analyze each item against documentation
|
||||
2. Evidence-Based - Cite specific sections or code when validating
|
||||
3. Critical Thinking - Question assumptions and identify gaps
|
||||
4. Risk Assessment - Consider what could go wrong with each decision
|
||||
|
||||
EXECUTION MODE:
|
||||
Ask the user if they want to work through the checklist:
|
||||
|
||||
- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
|
||||
- Section by section (interactive mode) - Review each section, get confirmation before proceeding
|
||||
- All at once (comprehensive mode) - Complete full analysis and present report at end]]
|
||||
|
||||
## 1. PROJECT SETUP & INITIALIZATION
|
||||
|
||||
[[LLM: Project setup is the foundation - if this is wrong, everything else fails. Verify:
|
||||
[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
|
||||
|
||||
1. The VERY FIRST epic/story creates the project structure
|
||||
2. No code is written before the project exists
|
||||
3. Development environment is ready before any development
|
||||
4. Dependencies are installed before they're imported
|
||||
5. Configuration happens before it's needed]]
|
||||
|
||||
### 1.1 Project Scaffolding
|
||||
### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
|
||||
|
||||
- [ ] Epic 1 includes explicit steps for project creation/initialization
|
||||
- [ ] If using a starter template, steps for cloning/setup are included
|
||||
- [ ] If building from scratch, all necessary scaffolding steps are defined
|
||||
- [ ] Initial README or documentation setup is included
|
||||
- [ ] Repository setup and initial commit processes are defined (if applicable)
|
||||
- [ ] Repository setup and initial commit processes are defined
|
||||
|
||||
### 1.2 Development Environment
|
||||
### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
|
||||
|
||||
- [ ] Existing project analysis has been completed and documented
|
||||
- [ ] Integration points with current system are identified
|
||||
- [ ] Development environment preserves existing functionality
|
||||
- [ ] Local testing approach validated for existing features
|
||||
- [ ] Rollback procedures defined for each integration point
|
||||
|
||||
### 1.3 Development Environment
|
||||
|
||||
- [ ] Local development environment setup is clearly defined
|
||||
- [ ] Required tools and versions are specified (Node.js, Python, etc.)
|
||||
- [ ] Required tools and versions are specified
|
||||
- [ ] Steps for installing dependencies are included
|
||||
- [ ] Configuration files (dotenv, config files, etc.) are addressed
|
||||
- [ ] Configuration files are addressed appropriately
|
||||
- [ ] Development server setup is included
|
||||
|
||||
### 1.3 Core Dependencies
|
||||
### 1.4 Core Dependencies
|
||||
|
||||
- [ ] All critical packages/libraries are installed early in the process
|
||||
- [ ] Package management (npm, pip, etc.) is properly addressed
|
||||
- [ ] All critical packages/libraries are installed early
|
||||
- [ ] Package management is properly addressed
|
||||
- [ ] Version specifications are appropriately defined
|
||||
- [ ] Dependency conflicts or special requirements are noted
|
||||
- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
|
||||
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
|
||||
## 2. INFRASTRUCTURE & DEPLOYMENT
|
||||
|
||||
[[LLM: Infrastructure must exist before it's used. Check sequencing carefully:
|
||||
|
||||
1. Databases exist before tables/collections
|
||||
2. Tables/collections exist before data operations
|
||||
3. APIs are configured before endpoints are added
|
||||
4. Auth is set up before protected routes
|
||||
5. Deployment pipeline exists before deployment stories]]
|
||||
[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
|
||||
|
||||
### 2.1 Database & Data Store Setup
|
||||
|
||||
- [ ] Database selection/setup occurs before any database operations
|
||||
- [ ] Database selection/setup occurs before any operations
|
||||
- [ ] Schema definitions are created before data operations
|
||||
- [ ] Migration strategies are defined if applicable
|
||||
- [ ] Seed data or initial data setup is included if needed
|
||||
- [ ] Database access patterns and security are established early
|
||||
- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
|
||||
- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
|
||||
|
||||
### 2.2 API & Service Configuration
|
||||
|
||||
@@ -85,31 +114,29 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Service architecture is established before implementing services
|
||||
- [ ] Authentication framework is set up before protected routes
|
||||
- [ ] Middleware and common utilities are created before use
|
||||
- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
|
||||
|
||||
### 2.3 Deployment Pipeline
|
||||
|
||||
- [ ] CI/CD pipeline is established before any deployment actions
|
||||
- [ ] CI/CD pipeline is established before deployment actions
|
||||
- [ ] Infrastructure as Code (IaC) is set up before use
|
||||
- [ ] Environment configurations (dev, staging, prod) are defined early
|
||||
- [ ] Environment configurations are defined early
|
||||
- [ ] Deployment strategies are defined before implementation
|
||||
- [ ] Rollback procedures or considerations are addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
|
||||
- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
|
||||
|
||||
### 2.4 Testing Infrastructure
|
||||
|
||||
- [ ] Testing frameworks are installed before writing tests
|
||||
- [ ] Test environment setup precedes test implementation
|
||||
- [ ] Mock services or data are defined before testing
|
||||
- [ ] Test utilities or helpers are created before use
|
||||
- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
|
||||
|
||||
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
||||
|
||||
[[LLM: External dependencies often block progress. Ensure:
|
||||
|
||||
1. All external accounts are created early
|
||||
2. API keys are obtained before integration stories
|
||||
3. User actions (like purchasing) are clearly marked
|
||||
4. Fallback options exist for external service issues
|
||||
5. Integration prerequisites are met before integration]]
|
||||
[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
|
||||
|
||||
### 3.1 Third-Party Services
|
||||
|
||||
@@ -117,6 +144,8 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] API key acquisition processes are defined
|
||||
- [ ] Steps for securely storing credentials are included
|
||||
- [ ] Fallback or offline development options are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
|
||||
- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
|
||||
|
||||
### 3.2 External APIs
|
||||
|
||||
@@ -124,6 +153,7 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] Authentication with external services is properly sequenced
|
||||
- [ ] API limits or constraints are acknowledged
|
||||
- [ ] Backup strategies for API failures are considered
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
|
||||
|
||||
### 3.3 Infrastructure Services
|
||||
|
||||
@@ -131,239 +161,270 @@ Ask the user if they want to work through the checklist:
|
||||
- [ ] DNS or domain registration needs are identified
|
||||
- [ ] Email or messaging service setup is included if needed
|
||||
- [ ] CDN or static asset hosting setup precedes their use
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
|
||||
|
||||
## 4. USER/AGENT RESPONSIBILITY DELINEATION
|
||||
## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
|
||||
|
||||
[[LLM: Clear ownership prevents confusion and delays. Verify:
|
||||
[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
|
||||
|
||||
1. User tasks are truly things only humans can do
|
||||
2. No coding tasks are assigned to users
|
||||
3. Account creation and payments are user tasks
|
||||
4. Everything else is assigned to appropriate agents
|
||||
5. Handoffs between user and agent are clear]]
|
||||
### 4.1 Design System Setup
|
||||
|
||||
### 4.1 User Actions
|
||||
- [ ] UI framework and libraries are selected and installed early
|
||||
- [ ] Design system or component library is established
|
||||
- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
|
||||
- [ ] Responsive design strategy is established
|
||||
- [ ] Accessibility requirements are defined upfront
|
||||
|
||||
- [ ] User responsibilities are limited to only what requires human intervention
|
||||
- [ ] Account creation on external services is properly assigned to users
|
||||
- [ ] Purchasing or payment actions are correctly assigned to users
|
||||
- [ ] Credential provision is appropriately assigned to users
|
||||
### 4.2 Frontend Infrastructure
|
||||
|
||||
### 4.2 Developer Agent Actions
|
||||
- [ ] Frontend build pipeline is configured before development
|
||||
- [ ] Asset optimization strategy is defined
|
||||
- [ ] Frontend testing framework is set up
|
||||
- [ ] Component development workflow is established
|
||||
- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
|
||||
|
||||
- [ ] All code-related tasks are assigned to developer agents
|
||||
- [ ] Automated processes are correctly identified as agent responsibilities
|
||||
- [ ] Configuration management is properly assigned
|
||||
- [ ] Testing and validation are assigned to appropriate agents
|
||||
### 4.3 User Experience Flow
|
||||
|
||||
## 5. FEATURE SEQUENCING & DEPENDENCIES
|
||||
- [ ] User journeys are mapped before implementation
|
||||
- [ ] Navigation patterns are defined early
|
||||
- [ ] Error states and loading states are planned
|
||||
- [ ] Form validation patterns are established
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
|
||||
|
||||
[[LLM: Dependencies create the critical path. Check rigorously:
|
||||
## 5. USER/AGENT RESPONSIBILITY
|
||||
|
||||
1. Nothing is used before it exists
|
||||
2. Shared components are built once, used many times
|
||||
3. The user can complete a meaningful flow early
|
||||
4. Each epic delivers value, not just infrastructure
|
||||
5. Dependencies don't create circular references]]
|
||||
[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
|
||||
|
||||
### 5.1 Functional Dependencies
|
||||
### 5.1 User Actions
|
||||
|
||||
- [ ] Features that depend on other features are sequenced correctly
|
||||
- [ ] User responsibilities limited to human-only tasks
|
||||
- [ ] Account creation on external services assigned to users
|
||||
- [ ] Purchasing or payment actions assigned to users
|
||||
- [ ] Credential provision appropriately assigned to users
|
||||
|
||||
### 5.2 Developer Agent Actions
|
||||
|
||||
- [ ] All code-related tasks assigned to developer agents
|
||||
- [ ] Automated processes identified as agent responsibilities
|
||||
- [ ] Configuration management properly assigned
|
||||
- [ ] Testing and validation assigned to appropriate agents
|
||||
|
||||
## 6. FEATURE SEQUENCING & DEPENDENCIES
|
||||
|
||||
[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
|
||||
|
||||
### 6.1 Functional Dependencies
|
||||
|
||||
- [ ] Features depending on others are sequenced correctly
|
||||
- [ ] Shared components are built before their use
|
||||
- [ ] User flows follow a logical progression
|
||||
- [ ] Authentication features precede protected routes/features
|
||||
- [ ] User flows follow logical progression
|
||||
- [ ] Authentication features precede protected features
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
|
||||
|
||||
### 5.2 Technical Dependencies
|
||||
### 6.2 Technical Dependencies
|
||||
|
||||
- [ ] Lower-level services are built before higher-level ones
|
||||
- [ ] Libraries and utilities are created before their use
|
||||
- [ ] Data models are defined before operations on them
|
||||
- [ ] API endpoints are defined before client consumption
|
||||
- [ ] Lower-level services built before higher-level ones
|
||||
- [ ] Libraries and utilities created before their use
|
||||
- [ ] Data models defined before operations on them
|
||||
- [ ] API endpoints defined before client consumption
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
|
||||
|
||||
### 5.3 Cross-Epic Dependencies
|
||||
### 6.3 Cross-Epic Dependencies
|
||||
|
||||
- [ ] Later epics build upon functionality from earlier epics
|
||||
- [ ] Later epics build upon earlier epic functionality
|
||||
- [ ] No epic requires functionality from later epics
|
||||
- [ ] Infrastructure established in early epics is utilized consistently
|
||||
- [ ] Incremental value delivery is maintained
|
||||
- [ ] Infrastructure from early epics utilized consistently
|
||||
- [ ] Incremental value delivery maintained
|
||||
- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
|
||||
|
||||
## 6. MVP SCOPE ALIGNMENT
|
||||
## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
|
||||
|
||||
[[LLM: MVP means MINIMUM viable product. Validate:
|
||||
[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
|
||||
|
||||
1. Every feature directly supports core MVP goals
|
||||
2. "Nice to haves" are clearly marked for post-MVP
|
||||
3. The user can achieve primary goals with included features
|
||||
4. Technical requirements don't add unnecessary scope
|
||||
5. The product is truly viable with just these features]]
|
||||
### 7.1 Breaking Change Risks
|
||||
|
||||
### 6.1 PRD Goals Alignment
|
||||
- [ ] Risk of breaking existing functionality assessed
|
||||
- [ ] Database migration risks identified and mitigated
|
||||
- [ ] API breaking change risks evaluated
|
||||
- [ ] Performance degradation risks identified
|
||||
- [ ] Security vulnerability risks evaluated
|
||||
|
||||
- [ ] All core goals defined in the PRD are addressed in epics/stories
|
||||
- [ ] Features directly support the defined MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope are included
|
||||
- [ ] Critical features are prioritized appropriately
|
||||
### 7.2 Rollback Strategy
|
||||
|
||||
### 6.2 User Journey Completeness
|
||||
- [ ] Rollback procedures clearly defined per story
|
||||
- [ ] Feature flag strategy implemented
|
||||
- [ ] Backup and recovery procedures updated
|
||||
- [ ] Monitoring enhanced for new components
|
||||
- [ ] Rollback triggers and thresholds defined
|
||||
|
||||
- [ ] All critical user journeys are fully implemented
|
||||
- [ ] Edge cases and error scenarios are addressed
|
||||
- [ ] User experience considerations are included
|
||||
- [ ] Accessibility requirements are incorporated if specified
|
||||
### 7.3 User Impact Mitigation
|
||||
|
||||
### 6.3 Technical Requirements Satisfaction
|
||||
- [ ] Existing user workflows analyzed for impact
|
||||
- [ ] User communication plan developed
|
||||
- [ ] Training materials updated
|
||||
- [ ] Support documentation comprehensive
|
||||
- [ ] Migration path for user data validated
|
||||
|
||||
- [ ] All technical constraints from the PRD are addressed
|
||||
- [ ] Non-functional requirements are incorporated
|
||||
- [ ] Architecture decisions align with specified constraints
|
||||
- [ ] Performance considerations are appropriately addressed
|
||||
## 8. MVP SCOPE ALIGNMENT
|
||||
|
||||
## 7. RISK MANAGEMENT & PRACTICALITY
|
||||
[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
|
||||
|
||||
[[LLM: Risks can derail the entire project. Ensure:
|
||||
### 8.1 Core Goals Alignment
|
||||
|
||||
1. Technical unknowns have research/spike stories
|
||||
2. External dependencies have fallback plans
|
||||
3. Complex features have validation milestones
|
||||
4. The timeline accounts for discovered complexity
|
||||
5. Critical risks are addressed early, not late]]
|
||||
- [ ] All core goals from PRD are addressed
|
||||
- [ ] Features directly support MVP goals
|
||||
- [ ] No extraneous features beyond MVP scope
|
||||
- [ ] Critical features prioritized appropriately
|
||||
- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
|
||||
|
||||
### 7.1 Technical Risk Mitigation
|
||||
### 8.2 User Journey Completeness
|
||||
|
||||
- [ ] Complex or unfamiliar technologies have appropriate learning/prototyping stories
|
||||
- [ ] High-risk components have explicit validation steps
|
||||
- [ ] Fallback strategies exist for risky integrations
|
||||
- [ ] Performance concerns have explicit testing/validation
|
||||
- [ ] All critical user journeys fully implemented
|
||||
- [ ] Edge cases and error scenarios addressed
|
||||
- [ ] User experience considerations included
|
||||
- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
|
||||
|
||||
### 7.2 External Dependency Risks
|
||||
### 8.3 Technical Requirements
|
||||
|
||||
- [ ] Risks with third-party services are acknowledged and mitigated
|
||||
- [ ] API limits or constraints are addressed
|
||||
- [ ] Backup strategies exist for critical external services
|
||||
- [ ] Cost implications of external services are considered
|
||||
- [ ] All technical constraints from PRD addressed
|
||||
- [ ] Non-functional requirements incorporated
|
||||
- [ ] Architecture decisions align with constraints
|
||||
- [ ] Performance considerations addressed
|
||||
- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
|
||||
|
||||
### 7.3 Timeline Practicality
|
||||
## 9. DOCUMENTATION & HANDOFF
|
||||
|
||||
- [ ] Story complexity and sequencing suggest a realistic timeline
|
||||
- [ ] Dependencies on external factors are minimized or managed
|
||||
- [ ] Parallel work is enabled where possible
|
||||
- [ ] Critical path is identified and optimized
|
||||
[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
|
||||
|
||||
## 8. DOCUMENTATION & HANDOFF
|
||||
### 9.1 Developer Documentation
|
||||
|
||||
[[LLM: Good documentation enables smooth development. Check:
|
||||
|
||||
1. Developers can start without extensive onboarding
|
||||
2. Deployment steps are clear and complete
|
||||
3. Handoff points between roles are documented
|
||||
4. Future maintenance is considered
|
||||
5. Knowledge isn't trapped in one person's head]]
|
||||
|
||||
### 8.1 Developer Documentation
|
||||
|
||||
- [ ] API documentation is created alongside implementation
|
||||
- [ ] API documentation created alongside implementation
|
||||
- [ ] Setup instructions are comprehensive
|
||||
- [ ] Architecture decisions are documented
|
||||
- [ ] Patterns and conventions are documented
|
||||
- [ ] Architecture decisions documented
|
||||
- [ ] Patterns and conventions documented
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
|
||||
|
||||
### 8.2 User Documentation
|
||||
### 9.2 User Documentation
|
||||
|
||||
- [ ] User guides or help documentation is included if required
|
||||
- [ ] Error messages and user feedback are considered
|
||||
- [ ] Onboarding flows are fully specified
|
||||
- [ ] Support processes are defined if applicable
|
||||
- [ ] User guides or help documentation included if required
|
||||
- [ ] Error messages and user feedback considered
|
||||
- [ ] Onboarding flows fully specified
|
||||
- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
|
||||
|
||||
## 9. POST-MVP CONSIDERATIONS
|
||||
### 9.3 Knowledge Transfer
|
||||
|
||||
[[LLM: Planning for success prevents technical debt. Verify:
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
|
||||
- [ ] Code review knowledge sharing planned
|
||||
- [ ] Deployment knowledge transferred to operations
|
||||
- [ ] Historical context preserved
|
||||
|
||||
1. MVP doesn't paint the product into a corner
|
||||
2. Future features won't require major refactoring
|
||||
3. Monitoring exists to validate MVP success
|
||||
4. Feedback loops inform post-MVP priorities
|
||||
5. The architecture can grow with the product]]
|
||||
## 10. POST-MVP CONSIDERATIONS
|
||||
|
||||
### 9.1 Future Enhancements
|
||||
[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
|
||||
|
||||
### 10.1 Future Enhancements
|
||||
|
||||
- [ ] Clear separation between MVP and future features
|
||||
- [ ] Architecture supports planned future enhancements
|
||||
- [ ] Technical debt considerations are documented
|
||||
- [ ] Extensibility points are identified
|
||||
- [ ] Architecture supports planned enhancements
|
||||
- [ ] Technical debt considerations documented
|
||||
- [ ] Extensibility points identified
|
||||
- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
|
||||
|
||||
### 9.2 Feedback Mechanisms
|
||||
### 10.2 Monitoring & Feedback
|
||||
|
||||
- [ ] Analytics or usage tracking is included if required
|
||||
- [ ] User feedback collection is considered
|
||||
- [ ] Monitoring and alerting are addressed
|
||||
- [ ] Performance measurement is incorporated
|
||||
- [ ] Analytics or usage tracking included if required
|
||||
- [ ] User feedback collection considered
|
||||
- [ ] Monitoring and alerting addressed
|
||||
- [ ] Performance measurement incorporated
|
||||
- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
|
||||
|
||||
## VALIDATION SUMMARY
|
||||
|
||||
[[LLM: FINAL PO VALIDATION REPORT GENERATION
|
||||
|
||||
Generate a comprehensive validation report for the complete MVP plan:
|
||||
Generate a comprehensive validation report that adapts to project type:
|
||||
|
||||
1. Executive Summary
|
||||
|
||||
- Overall plan readiness (percentage)
|
||||
- Project type: [Greenfield/Brownfield] with [UI/No UI]
|
||||
- Overall readiness (percentage)
|
||||
- Go/No-Go recommendation
|
||||
- Critical blocking issues count
|
||||
- Estimated development timeline feasibility
|
||||
- Sections skipped due to project type
|
||||
|
||||
2. Sequencing Analysis
|
||||
2. Project-Specific Analysis
|
||||
|
||||
- Dependency violations found
|
||||
- Circular dependencies identified
|
||||
- Missing prerequisites
|
||||
- Optimal vs actual sequencing
|
||||
FOR GREENFIELD:
|
||||
|
||||
- Setup completeness
|
||||
- Dependency sequencing
|
||||
- MVP scope appropriateness
|
||||
- Development timeline feasibility
|
||||
|
||||
FOR BROWNFIELD:
|
||||
|
||||
- Integration risk level (High/Medium/Low)
|
||||
- Existing system impact assessment
|
||||
- Rollback readiness
|
||||
- User disruption potential
|
||||
|
||||
3. Risk Assessment
|
||||
|
||||
- High-risk areas without mitigation
|
||||
- External dependency risks
|
||||
- Technical complexity hotspots
|
||||
- Timeline risks
|
||||
- Top 5 risks by severity
|
||||
- Mitigation recommendations
|
||||
- Timeline impact of addressing issues
|
||||
- [BROWNFIELD] Specific integration risks
|
||||
|
||||
4. MVP Completeness
|
||||
|
||||
- Core features coverage
|
||||
- Missing essential functionality
|
||||
- Scope creep identified
|
||||
- True MVP vs "MLP" (Most Lovable Product)
|
||||
- True MVP vs over-engineering
|
||||
|
||||
5. Implementation Readiness
|
||||
|
||||
- Developer clarity score (1-10)
|
||||
- Ambiguous requirements count
|
||||
- Missing technical details
|
||||
- Handoff completeness
|
||||
- [BROWNFIELD] Integration point clarity
|
||||
|
||||
6. Recommendations
|
||||
|
||||
- Must-fix before development
|
||||
- Should-fix for quality
|
||||
- Consider for improvement
|
||||
- Post-MVP deferrals
|
||||
|
||||
7. [BROWNFIELD ONLY] Integration Confidence
|
||||
- Confidence in preserving existing functionality
|
||||
- Rollback procedure completeness
|
||||
- Monitoring coverage for integration points
|
||||
- Support team readiness
|
||||
|
||||
After presenting the report, ask if the user wants:
|
||||
|
||||
- Detailed analysis of any failed sections
|
||||
- Specific story resequencing suggestions
|
||||
- Risk mitigation strategies
|
||||
- MVP scope refinement help]]
|
||||
- [BROWNFIELD] Integration risk deep-dive]]
|
||||
|
||||
### Category Statuses
|
||||
|
||||
| Category | Status | Critical Issues |
|
||||
| ----------------------------------------- | ------ | --------------- |
|
||||
| 1. Project Setup & Initialization | _TBD_ | |
|
||||
| 2. Infrastructure & Deployment Sequencing | _TBD_ | |
|
||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||
| 4. User/Agent Responsibility Delineation | _TBD_ | |
|
||||
| 5. Feature Sequencing & Dependencies | _TBD_ | |
|
||||
| 6. MVP Scope Alignment | _TBD_ | |
|
||||
| 7. Risk Management & Practicality | _TBD_ | |
|
||||
| 8. Documentation & Handoff | _TBD_ | |
|
||||
| 9. Post-MVP Considerations | _TBD_ | |
|
||||
| Category | Status | Critical Issues |
|
||||
| --------------------------------------- | ------ | --------------- |
|
||||
| 1. Project Setup & Initialization | _TBD_ | |
|
||||
| 2. Infrastructure & Deployment | _TBD_ | |
|
||||
| 3. External Dependencies & Integrations | _TBD_ | |
|
||||
| 4. UI/UX Considerations | _TBD_ | |
|
||||
| 5. User/Agent Responsibility | _TBD_ | |
|
||||
| 6. Feature Sequencing & Dependencies | _TBD_ | |
|
||||
| 7. Risk Management (Brownfield) | _TBD_ | |
|
||||
| 8. MVP Scope Alignment | _TBD_ | |
|
||||
| 9. Documentation & Handoff | _TBD_ | |
|
||||
| 10. Post-MVP Considerations | _TBD_ | |
|
||||
|
||||
### Critical Deficiencies
|
||||
|
||||
@@ -376,4 +437,5 @@ _To be populated during validation_
|
||||
### Final Decision
|
||||
|
||||
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
||||
- **REJECTED**: The plan requires revision to address the identified deficiencies.
|
||||
- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
|
||||
- **REJECTED**: The plan requires significant revision to address critical deficiencies.
|
||||
|
||||
Reference in New Issue
Block a user