# 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:_

---