hash file change checking integrated
This commit is contained in:
Brian Madison
@@ -1,369 +0,0 @@
|
||||
# Project Planning Validation Checklist (Adaptive: All Levels)
|
||||
|
||||
**Scope**: This checklist adapts based on project level (0-4) and field type (greenfield/brownfield)
|
||||
|
||||
- **Level 0**: Tech-spec only validation
|
||||
- **Level 1-2**: PRD + Tech-spec + Epics validation
|
||||
- **Level 3-4**: PRD + Epics validation (no tech-spec)
|
||||
- **Greenfield**: Focus on setup sequencing and dependencies
|
||||
- **Brownfield**: Focus on integration risks and backward compatibility
|
||||
|
||||
## User Intent Validation (Critical First Check)
|
||||
|
||||
### Input Sources and User Need
|
||||
|
||||
- [ ] Product brief or initial context was properly gathered (not just project name)
|
||||
- [ ] User's actual problem/need was identified through conversation (not assumed)
|
||||
- [ ] Technical preferences mentioned by user were captured separately
|
||||
- [ ] User confirmed the description accurately reflects their vision
|
||||
- [ ] The PRD addresses what the user asked for, not what we think they need
|
||||
|
||||
### Alignment with User Goals
|
||||
|
||||
- [ ] Goals directly address the user's stated problem
|
||||
- [ ] Context reflects actual user-provided information (not invented)
|
||||
- [ ] Requirements map to explicit user needs discussed
|
||||
- [ ] Nothing critical the user mentioned is missing
|
||||
|
||||
## Document Structure
|
||||
|
||||
- [ ] All required sections are present
|
||||
- [ ] No placeholder text remains (all {{variables}} replaced)
|
||||
- [ ] Proper formatting and organization throughout
|
||||
|
||||
## Section 1: Description
|
||||
|
||||
- [ ] Clear, concise description of what's being built
|
||||
- [ ] Matches user's actual request (not extrapolated)
|
||||
- [ ] Sets proper scope and expectations
|
||||
|
||||
## Section 2: Goals (Step 2)
|
||||
|
||||
- [ ] Level 3: Contains 3-5 primary goals
|
||||
- [ ] Level 4: Contains 5-7 strategic goals
|
||||
- [ ] Each goal is specific and measurable where possible
|
||||
- [ ] Goals focus on user and project outcomes
|
||||
- [ ] Goals represent what success looks like
|
||||
- [ ] Strategic objectives align with product scale
|
||||
|
||||
## Section 3: Context (Step 3)
|
||||
|
||||
- [ ] 1-2 short paragraphs explaining why this matters now
|
||||
- [ ] Context was gathered from user (not invented)
|
||||
- [ ] Explains actual problem being solved
|
||||
- [ ] Describes current situation or pain point
|
||||
- [ ] Connects to real-world impact
|
||||
|
||||
## Section 4: Functional Requirements (Step 4)
|
||||
|
||||
- [ ] Level 3: Contains 12-20 FRs
|
||||
- [ ] Level 4: Contains 20-30 FRs
|
||||
- [ ] Each has unique FR identifier (FR001, FR002, etc.)
|
||||
- [ ] Requirements describe capabilities, not implementation
|
||||
- [ ] Related features grouped logically while maintaining granularity
|
||||
- [ ] All FRs are testable user actions
|
||||
- [ ] User provided feedback on proposed FRs
|
||||
- [ ] Missing capabilities user expected were added
|
||||
- [ ] Priority order reflects user input
|
||||
- [ ] Coverage comprehensive for target product scale
|
||||
|
||||
## Section 5: Non-Functional Requirements (Step 5 - Optional)
|
||||
|
||||
- [ ] Only included if truly needed (not arbitrary targets)
|
||||
- [ ] Each has unique NFR identifier
|
||||
- [ ] Business justification provided for each NFR
|
||||
- [ ] Compliance requirements noted if regulated industry
|
||||
- [ ] Performance constraints tied to business needs
|
||||
- [ ] Typically 0-5 for MVP (not invented)
|
||||
|
||||
## Section 6: User Journeys (Step 6)
|
||||
|
||||
- [ ] Level 3: 2-3 detailed user journeys documented
|
||||
- [ ] Level 4: 3-5 comprehensive journeys for major segments
|
||||
- [ ] Each journey has named persona with context
|
||||
- [ ] Journey shows complete path through system via FRs
|
||||
- [ ] Specific FR references included (e.g., "signs up (FR001)")
|
||||
- [ ] Success criteria and pain points identified
|
||||
- [ ] Edge cases and alternative paths considered
|
||||
- [ ] Journeys validate comprehensive value delivery
|
||||
|
||||
## Section 7: UX Principles (Step 7 - Optional)
|
||||
|
||||
- [ ] Target users and sophistication level defined
|
||||
- [ ] Design values stated (simple vs powerful, playful vs professional)
|
||||
- [ ] Platform strategy specified (mobile-first, web, native)
|
||||
- [ ] Accessibility requirements noted if applicable
|
||||
- [ ] Sets direction without prescribing specific solutions
|
||||
|
||||
## Section 8: Epics (Step 8)
|
||||
|
||||
- [ ] Level 3: 3-5 epics defined (targeting 12-40 stories)
|
||||
- [ ] Level 4: 5-8 epics defined (targeting 40+ stories)
|
||||
- [ ] Each epic represents significant, deployable functionality
|
||||
- [ ] Epic format includes: Title, Goal, Capabilities, Success Criteria, Dependencies
|
||||
- [ ] Related FRs grouped into coherent capabilities
|
||||
- [ ] Each epic references specific FR numbers
|
||||
- [ ] Post-MVP epics listed separately with their FRs
|
||||
- [ ] Dependencies between epics clearly noted
|
||||
- [ ] Phased delivery strategy apparent
|
||||
|
||||
## Section 9: Out of Scope (Step 9)
|
||||
|
||||
- [ ] Ideas preserved with FR/NFR references
|
||||
- [ ] Format: description followed by (FR###, NFR###)
|
||||
- [ ] Prevents scope creep while capturing future possibilities
|
||||
- [ ] Clear distinction from MVP scope
|
||||
|
||||
## Section 10: Assumptions and Dependencies (Step 10)
|
||||
|
||||
- [ ] Only ACTUAL assumptions from user discussion (not invented)
|
||||
- [ ] Technical choices user explicitly mentioned captured
|
||||
- [ ] Dependencies identified in FRs/NFRs listed
|
||||
- [ ] User-stated constraints documented
|
||||
- [ ] If none exist, states "No critical assumptions identified yet"
|
||||
|
||||
## Cross-References and Consistency
|
||||
|
||||
- [ ] All FRs trace back to at least one goal
|
||||
- [ ] User journeys reference actual FR numbers
|
||||
- [ ] Epic capabilities cover all FRs
|
||||
- [ ] Terminology consistent throughout
|
||||
- [ ] No contradictions between sections
|
||||
- [ ] Technical details saved to technical_preferences (not in PRD)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Requirements are strategic, not implementation-focused
|
||||
- [ ] Document maintains appropriate abstraction level
|
||||
- [ ] No premature technical decisions
|
||||
- [ ] Focus on WHAT, not HOW
|
||||
|
||||
## Readiness for Next Phase
|
||||
|
||||
- [ ] Sufficient detail for comprehensive architecture design
|
||||
- [ ] Clear enough for detailed solution design
|
||||
- [ ] Ready for epic breakdown into 12-40+ stories
|
||||
- [ ] Value delivery path supports phased releases
|
||||
- [ ] If UI exists, ready for UX expert collaboration
|
||||
- [ ] Scale and complexity match Level 3-4 requirements
|
||||
|
||||
## Scale Validation
|
||||
|
||||
- [ ] Project scope justifies PRD
|
||||
- [ ] Complexity matches Level 1-4 designation
|
||||
- [ ] Story estimate aligns with epic structure (12-40+)
|
||||
- [ ] Not over-engineered for actual needs
|
||||
|
||||
## Final Validation
|
||||
|
||||
- [ ] Document addresses user's original request completely
|
||||
- [ ] All user feedback incorporated
|
||||
- [ ] No critical user requirements missing
|
||||
- [ ] Ready for user final review and approval
|
||||
- [ ] File saved in correct location: {{output_folder}}/PRD.md
|
||||
|
||||
---
|
||||
|
||||
# Cohesion Validation (All Levels)
|
||||
|
||||
**Purpose**: Validate alignment between planning artifacts and readiness for implementation
|
||||
|
||||
## Project Context Detection
|
||||
|
||||
- [ ] Project level confirmed (0, 1, 2, 3, or 4)
|
||||
- [ ] Field type identified (greenfield or brownfield)
|
||||
- [ ] Appropriate validation sections applied based on context
|
||||
|
||||
## Section A: Tech Spec Validation (Levels 0, 1, 2 only)
|
||||
|
||||
### A.1 Tech Spec Completeness
|
||||
|
||||
- [ ] All technical decisions are DEFINITIVE (no "Option A or B")
|
||||
- [ ] Specific versions specified for all frameworks/libraries
|
||||
- [ ] Source tree structure clearly defined
|
||||
- [ ] Technical approach precisely described
|
||||
- [ ] Implementation stack complete with exact tools
|
||||
- [ ] Testing approach clearly defined
|
||||
- [ ] Deployment strategy documented
|
||||
|
||||
### A.2 Tech Spec - PRD Alignment (Levels 1-2 only)
|
||||
|
||||
- [ ] Every functional requirement has technical solution
|
||||
- [ ] Non-functional requirements addressed in tech spec
|
||||
- [ ] Tech stack aligns with PRD constraints
|
||||
- [ ] Performance requirements achievable with chosen stack
|
||||
- [ ] Technical preferences from user incorporated
|
||||
|
||||
## Section B: Greenfield-Specific Validation (if greenfield)
|
||||
|
||||
### B.1 Project Setup Sequencing
|
||||
|
||||
- [ ] Epic 0 or 1 includes project initialization steps
|
||||
- [ ] Repository setup precedes feature development
|
||||
- [ ] Development environment configuration included early
|
||||
- [ ] Core dependencies installed before use
|
||||
- [ ] Testing infrastructure set up before tests written
|
||||
|
||||
### B.2 Infrastructure Before Features
|
||||
|
||||
- [ ] Database setup before data operations
|
||||
- [ ] API framework before endpoint implementation
|
||||
- [ ] Authentication setup before protected features
|
||||
- [ ] CI/CD pipeline before deployment
|
||||
- [ ] Monitoring setup included
|
||||
|
||||
### B.3 External Dependencies
|
||||
|
||||
- [ ] Third-party account creation assigned to user
|
||||
- [ ] API keys acquisition process defined
|
||||
- [ ] Credential storage approach specified
|
||||
- [ ] External service setup sequenced properly
|
||||
- [ ] Fallback strategies for external failures
|
||||
|
||||
## Section C: Brownfield-Specific Validation (if brownfield)
|
||||
|
||||
### C.1 Existing System Integration
|
||||
|
||||
- [ ] Current architecture analyzed and documented
|
||||
- [ ] Integration points with existing system identified
|
||||
- [ ] Existing functionality preservation validated
|
||||
- [ ] Database schema compatibility assessed
|
||||
- [ ] API contract compatibility verified
|
||||
|
||||
### C.2 Risk Management
|
||||
|
||||
- [ ] Breaking change risks identified and mitigated
|
||||
- [ ] Rollback procedures defined for each integration
|
||||
- [ ] Feature flags or toggles included where appropriate
|
||||
- [ ] Performance degradation risks assessed
|
||||
- [ ] User impact analysis completed
|
||||
|
||||
### C.3 Backward Compatibility
|
||||
|
||||
- [ ] Database migrations maintain backward compatibility
|
||||
- [ ] API changes don't break existing consumers
|
||||
- [ ] Authentication/authorization integration safe
|
||||
- [ ] Configuration changes non-breaking
|
||||
- [ ] Existing monitoring preserved or enhanced
|
||||
|
||||
### C.4 Dependency Conflicts
|
||||
|
||||
- [ ] New dependencies compatible with existing versions
|
||||
- [ ] No version conflicts introduced
|
||||
- [ ] Security vulnerabilities not introduced
|
||||
- [ ] License compatibility verified
|
||||
- [ ] Bundle size impact acceptable
|
||||
|
||||
## Section D: Feature Sequencing (All Levels)
|
||||
|
||||
### D.1 Functional Dependencies
|
||||
|
||||
- [ ] Features depending on others sequenced correctly
|
||||
- [ ] Shared components built before consumers
|
||||
- [ ] User flows follow logical progression
|
||||
- [ ] Authentication precedes protected features
|
||||
|
||||
### D.2 Technical Dependencies
|
||||
|
||||
- [ ] Lower-level services before higher-level ones
|
||||
- [ ] Utilities and libraries created before use
|
||||
- [ ] Data models defined before operations
|
||||
- [ ] API endpoints before client consumption
|
||||
|
||||
### D.3 Epic Dependencies
|
||||
|
||||
- [ ] Later epics build on earlier epic functionality
|
||||
- [ ] No circular dependencies between epics
|
||||
- [ ] Infrastructure from early epics reused
|
||||
- [ ] Incremental value delivery maintained
|
||||
|
||||
## Section E: UI/UX Cohesion (if UI components exist)
|
||||
|
||||
### E.1 Design System (Greenfield)
|
||||
|
||||
- [ ] UI framework selected and installed early
|
||||
- [ ] Design system or component library established
|
||||
- [ ] Styling approach defined
|
||||
- [ ] Responsive design strategy clear
|
||||
- [ ] Accessibility requirements defined
|
||||
|
||||
### E.2 Design Consistency (Brownfield)
|
||||
|
||||
- [ ] UI consistent with existing system
|
||||
- [ ] Component library updates non-breaking
|
||||
- [ ] Styling approach matches existing
|
||||
- [ ] Accessibility standards maintained
|
||||
- [ ] Existing user workflows preserved
|
||||
|
||||
### E.3 UX Flow Validation
|
||||
|
||||
- [ ] User journeys mapped completely
|
||||
- [ ] Navigation patterns defined
|
||||
- [ ] Error and loading states planned
|
||||
- [ ] Form validation patterns established
|
||||
|
||||
## Section F: Responsibility Assignment (All Levels)
|
||||
|
||||
### F.1 User vs Agent Clarity
|
||||
|
||||
- [ ] Human-only tasks assigned to user
|
||||
- [ ] Account creation on external services → user
|
||||
- [ ] Payment/purchasing actions → user
|
||||
- [ ] All code tasks → developer agent
|
||||
- [ ] Configuration management properly assigned
|
||||
|
||||
## Section G: Documentation Readiness (All Levels)
|
||||
|
||||
### G.1 Developer Documentation
|
||||
|
||||
- [ ] Setup instructions comprehensive
|
||||
- [ ] Technical decisions documented
|
||||
- [ ] Patterns and conventions clear
|
||||
- [ ] API documentation plan exists (if applicable)
|
||||
|
||||
### G.2 Deployment Documentation (Brownfield)
|
||||
|
||||
- [ ] Runbook updates planned
|
||||
- [ ] Incident response procedures updated
|
||||
- [ ] Rollback procedures documented and tested
|
||||
- [ ] Monitoring dashboard updates planned
|
||||
|
||||
## Section H: Future-Proofing (All Levels)
|
||||
|
||||
### H.1 Extensibility
|
||||
|
||||
- [ ] Current scope vs future features clearly separated
|
||||
- [ ] Architecture supports planned enhancements
|
||||
- [ ] Technical debt considerations documented
|
||||
- [ ] Extensibility points identified
|
||||
|
||||
### H.2 Observability
|
||||
|
||||
- [ ] Monitoring strategy defined
|
||||
- [ ] Success metrics from planning captured
|
||||
- [ ] Analytics or tracking included if needed
|
||||
- [ ] Performance measurement approach clear
|
||||
|
||||
## Cohesion Summary
|
||||
|
||||
### Overall Readiness Assessment
|
||||
|
||||
- [ ] **Ready for Development** - All critical items pass
|
||||
- [ ] **Needs Alignment** - Some gaps need addressing
|
||||
- [ ] **Too Risky** (brownfield only) - Integration risks too high
|
||||
|
||||
### Critical Gaps Identified
|
||||
|
||||
_List any blocking issues or unacceptable risks:_
|
||||
|
||||
### Integration Risk Level (brownfield only)
|
||||
|
||||
- [ ] Low - well-understood integration with good rollback
|
||||
- [ ] Medium - some unknowns but manageable
|
||||
- [ ] High - significant risks require mitigation
|
||||
|
||||
### Recommendations
|
||||
|
||||
_Specific actions to improve cohesion before development:_
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user