1088 lines
47 KiB
Plaintext
1088 lines
47 KiB
Plaintext
==================== START: architect-checklist ====================
|
|
# Architect Solution Validation Checklist
|
|
|
|
This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
|
|
|
|
## 1. REQUIREMENTS ALIGNMENT
|
|
|
|
### 1.1 Functional Requirements Coverage
|
|
|
|
- [ ] Architecture supports all functional requirements in the PRD
|
|
- [ ] Technical approaches for all epics and stories are addressed
|
|
- [ ] Edge cases and performance scenarios are considered
|
|
- [ ] All required integrations are accounted for
|
|
- [ ] User journeys are supported by the technical architecture
|
|
|
|
### 1.2 Non-Functional Requirements Alignment
|
|
|
|
- [ ] Performance requirements are addressed with specific solutions
|
|
- [ ] Scalability considerations are documented with approach
|
|
- [ ] Security requirements have corresponding technical controls
|
|
- [ ] Reliability and resilience approaches are defined
|
|
- [ ] Compliance requirements have technical implementations
|
|
|
|
### 1.3 Technical Constraints Adherence
|
|
|
|
- [ ] All technical constraints from PRD are satisfied
|
|
- [ ] Platform/language requirements are followed
|
|
- [ ] Infrastructure constraints are accommodated
|
|
- [ ] Third-party service constraints are addressed
|
|
- [ ] Organizational technical standards are followed
|
|
|
|
## 2. ARCHITECTURE FUNDAMENTALS
|
|
|
|
### 2.1 Architecture Clarity
|
|
|
|
- [ ] Architecture is documented with clear diagrams
|
|
- [ ] Major components and their responsibilities are defined
|
|
- [ ] Component interactions and dependencies are mapped
|
|
- [ ] Data flows are clearly illustrated
|
|
- [ ] Technology choices for each component are specified
|
|
|
|
### 2.2 Separation of Concerns
|
|
|
|
- [ ] Clear boundaries between UI, business logic, and data layers
|
|
- [ ] Responsibilities are cleanly divided between components
|
|
- [ ] Interfaces between components are well-defined
|
|
- [ ] Components adhere to single responsibility principle
|
|
- [ ] Cross-cutting concerns (logging, auth, etc.) are properly addressed
|
|
|
|
### 2.3 Design Patterns & Best Practices
|
|
|
|
- [ ] Appropriate design patterns are employed
|
|
- [ ] Industry best practices are followed
|
|
- [ ] Anti-patterns are avoided
|
|
- [ ] Consistent architectural style throughout
|
|
- [ ] Pattern usage is documented and explained
|
|
|
|
### 2.4 Modularity & Maintainability
|
|
|
|
- [ ] System is divided into cohesive, loosely-coupled modules
|
|
- [ ] Components can be developed and tested independently
|
|
- [ ] Changes can be localized to specific components
|
|
- [ ] Code organization promotes discoverability
|
|
- [ ] Architecture specifically designed for AI agent implementation
|
|
|
|
## 3. TECHNICAL STACK & DECISIONS
|
|
|
|
### 3.1 Technology Selection
|
|
|
|
- [ ] Selected technologies meet all requirements
|
|
- [ ] Technology versions are specifically defined (not ranges)
|
|
- [ ] Technology choices are justified with clear rationale
|
|
- [ ] Alternatives considered are documented with pros/cons
|
|
- [ ] Selected stack components work well together
|
|
|
|
### 3.2 Frontend Architecture
|
|
|
|
- [ ] UI framework and libraries are specifically selected
|
|
- [ ] State management approach is defined
|
|
- [ ] Component structure and organization is specified
|
|
- [ ] Responsive/adaptive design approach is outlined
|
|
- [ ] Build and bundling strategy is determined
|
|
|
|
### 3.3 Backend Architecture
|
|
|
|
- [ ] API design and standards are defined
|
|
- [ ] Service organization and boundaries are clear
|
|
- [ ] Authentication and authorization approach is specified
|
|
- [ ] Error handling strategy is outlined
|
|
- [ ] Backend scaling approach is defined
|
|
|
|
### 3.4 Data Architecture
|
|
|
|
- [ ] Data models are fully defined
|
|
- [ ] Database technologies are selected with justification
|
|
- [ ] Data access patterns are documented
|
|
- [ ] Data migration/seeding approach is specified
|
|
- [ ] Data backup and recovery strategies are outlined
|
|
|
|
## 4. RESILIENCE & OPERATIONAL READINESS
|
|
|
|
### 4.1 Error Handling & Resilience
|
|
|
|
- [ ] Error handling strategy is comprehensive
|
|
- [ ] Retry policies are defined where appropriate
|
|
- [ ] Circuit breakers or fallbacks are specified for critical services
|
|
- [ ] Graceful degradation approaches are defined
|
|
- [ ] System can recover from partial failures
|
|
|
|
### 4.2 Monitoring & Observability
|
|
|
|
- [ ] Logging strategy is defined
|
|
- [ ] Monitoring approach is specified
|
|
- [ ] Key metrics for system health are identified
|
|
- [ ] Alerting thresholds and strategies are outlined
|
|
- [ ] Debugging and troubleshooting capabilities are built in
|
|
|
|
### 4.3 Performance & Scaling
|
|
|
|
- [ ] Performance bottlenecks are identified and addressed
|
|
- [ ] Caching strategy is defined where appropriate
|
|
- [ ] Load balancing approach is specified
|
|
- [ ] Horizontal and vertical scaling strategies are outlined
|
|
- [ ] Resource sizing recommendations are provided
|
|
|
|
### 4.4 Deployment & DevOps
|
|
|
|
- [ ] Deployment strategy is defined
|
|
- [ ] CI/CD pipeline approach is outlined
|
|
- [ ] Environment strategy (dev, staging, prod) is specified
|
|
- [ ] Infrastructure as Code approach is defined
|
|
- [ ] Rollback and recovery procedures are outlined
|
|
|
|
## 5. SECURITY & COMPLIANCE
|
|
|
|
### 5.1 Authentication & Authorization
|
|
|
|
- [ ] Authentication mechanism is clearly defined
|
|
- [ ] Authorization model is specified
|
|
- [ ] Role-based access control is outlined if required
|
|
- [ ] Session management approach is defined
|
|
- [ ] Credential management is addressed
|
|
|
|
### 5.2 Data Security
|
|
|
|
- [ ] Data encryption approach (at rest and in transit) is specified
|
|
- [ ] Sensitive data handling procedures are defined
|
|
- [ ] Data retention and purging policies are outlined
|
|
- [ ] Backup encryption is addressed if required
|
|
- [ ] Data access audit trails are specified if required
|
|
|
|
### 5.3 API & Service Security
|
|
|
|
- [ ] API security controls are defined
|
|
- [ ] Rate limiting and throttling approaches are specified
|
|
- [ ] Input validation strategy is outlined
|
|
- [ ] CSRF/XSS prevention measures are addressed
|
|
- [ ] Secure communication protocols are specified
|
|
|
|
### 5.4 Infrastructure Security
|
|
|
|
- [ ] Network security design is outlined
|
|
- [ ] Firewall and security group configurations are specified
|
|
- [ ] Service isolation approach is defined
|
|
- [ ] Least privilege principle is applied
|
|
- [ ] Security monitoring strategy is outlined
|
|
|
|
## 6. IMPLEMENTATION GUIDANCE
|
|
|
|
### 6.1 Coding Standards & Practices
|
|
|
|
- [ ] Coding standards are defined
|
|
- [ ] Documentation requirements are specified
|
|
- [ ] Testing expectations are outlined
|
|
- [ ] Code organization principles are defined
|
|
- [ ] Naming conventions are specified
|
|
|
|
### 6.2 Testing Strategy
|
|
|
|
- [ ] Unit testing approach is defined
|
|
- [ ] Integration testing strategy is outlined
|
|
- [ ] E2E testing approach is specified
|
|
- [ ] Performance testing requirements are outlined
|
|
- [ ] Security testing approach is defined
|
|
|
|
### 6.3 Development Environment
|
|
|
|
- [ ] Local development environment setup is documented
|
|
- [ ] Required tools and configurations are specified
|
|
- [ ] Development workflows are outlined
|
|
- [ ] Source control practices are defined
|
|
- [ ] Dependency management approach is specified
|
|
|
|
### 6.4 Technical Documentation
|
|
|
|
- [ ] API documentation standards are defined
|
|
- [ ] Architecture documentation requirements are specified
|
|
- [ ] Code documentation expectations are outlined
|
|
- [ ] System diagrams and visualizations are included
|
|
- [ ] Decision records for key choices are included
|
|
|
|
## 7. DEPENDENCY & INTEGRATION MANAGEMENT
|
|
|
|
### 7.1 External Dependencies
|
|
|
|
- [ ] All external dependencies are identified
|
|
- [ ] Versioning strategy for dependencies is defined
|
|
- [ ] Fallback approaches for critical dependencies are specified
|
|
- [ ] Licensing implications are addressed
|
|
- [ ] Update and patching strategy is outlined
|
|
|
|
### 7.2 Internal Dependencies
|
|
|
|
- [ ] Component dependencies are clearly mapped
|
|
- [ ] Build order dependencies are addressed
|
|
- [ ] Shared services and utilities are identified
|
|
- [ ] Circular dependencies are eliminated
|
|
- [ ] Versioning strategy for internal components is defined
|
|
|
|
### 7.3 Third-Party Integrations
|
|
|
|
- [ ] All third-party integrations are identified
|
|
- [ ] Integration approaches are defined
|
|
- [ ] Authentication with third parties is addressed
|
|
- [ ] Error handling for integration failures is specified
|
|
- [ ] Rate limits and quotas are considered
|
|
|
|
## 8. AI AGENT IMPLEMENTATION SUITABILITY
|
|
|
|
### 8.1 Modularity for AI Agents
|
|
|
|
- [ ] Components are sized appropriately for AI agent implementation
|
|
- [ ] Dependencies between components are minimized
|
|
- [ ] Clear interfaces between components are defined
|
|
- [ ] Components have singular, well-defined responsibilities
|
|
- [ ] File and code organization optimized for AI agent understanding
|
|
|
|
### 8.2 Clarity & Predictability
|
|
|
|
- [ ] Patterns are consistent and predictable
|
|
- [ ] Complex logic is broken down into simpler steps
|
|
- [ ] Architecture avoids overly clever or obscure approaches
|
|
- [ ] Examples are provided for unfamiliar patterns
|
|
- [ ] Component responsibilities are explicit and clear
|
|
|
|
### 8.3 Implementation Guidance
|
|
|
|
- [ ] Detailed implementation guidance is provided
|
|
- [ ] Code structure templates are defined
|
|
- [ ] Specific implementation patterns are documented
|
|
- [ ] Common pitfalls are identified with solutions
|
|
- [ ] References to similar implementations are provided when helpful
|
|
|
|
### 8.4 Error Prevention & Handling
|
|
|
|
- [ ] Design reduces opportunities for implementation errors
|
|
- [ ] Validation and error checking approaches are defined
|
|
- [ ] Self-healing mechanisms are incorporated where possible
|
|
- [ ] Testing patterns are clearly defined
|
|
- [ ] Debugging guidance is provided
|
|
|
|
==================== END: architect-checklist ====================
|
|
|
|
|
|
==================== START: change-checklist ====================
|
|
# Change Navigation Checklist
|
|
|
|
**Purpose:** To systematically guide the selected Agent and user through the analysis and planning required when a significant change (pivot, tech issue, missing requirement, failed story) is identified during the BMAD workflow.
|
|
|
|
**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
|
|
|
|
---
|
|
|
|
## 1. Understand the Trigger & Context
|
|
|
|
- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
|
|
- [ ] **Define the Issue:** Articulate the core problem precisely.
|
|
- [ ] Is it a technical limitation/dead-end?
|
|
- [ ] Is it a newly discovered requirement?
|
|
- [ ] Is it a fundamental misunderstanding of existing requirements?
|
|
- [ ] Is it a necessary pivot based on feedback or new information?
|
|
- [ ] Is it a failed/abandoned story needing a new approach?
|
|
- [ ] **Assess Initial Impact:** Describe the immediate observed consequences (e.g., blocked progress, incorrect functionality, non-viable tech).
|
|
- [ ] **Gather Evidence:** Note any specific logs, error messages, user feedback, or analysis that supports the issue definition.
|
|
|
|
## 2. Epic Impact Assessment
|
|
|
|
- [ ] **Analyze Current Epic:**
|
|
- [ ] Can the current epic containing the trigger story still be completed?
|
|
- [ ] Does the current epic need modification (story changes, additions, removals)?
|
|
- [ ] Should the current epic be abandoned or fundamentally redefined?
|
|
- [ ] **Analyze Future Epics:**
|
|
- [ ] Review all remaining planned epics.
|
|
- [ ] Does the issue require changes to planned stories in future epics?
|
|
- [ ] Does the issue invalidate any future epics?
|
|
- [ ] Does the issue necessitate the creation of entirely new epics?
|
|
- [ ] Should the order/priority of future epics be changed?
|
|
- [ ] **Summarize Epic Impact:** Briefly document the overall effect on the project's epic structure and flow.
|
|
|
|
## 3. Artifact Conflict & Impact Analysis
|
|
|
|
- [ ] **Review PRD:**
|
|
- [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
|
|
- [ ] Does the PRD need clarification or updates based on the new understanding?
|
|
- [ ] **Review Architecture Document:**
|
|
- [ ] Does the issue conflict with the documented architecture (components, patterns, tech choices)?
|
|
- [ ] Are specific components/diagrams/sections impacted?
|
|
- [ ] Does the technology list need updating?
|
|
- [ ] Do data models or schemas need revision?
|
|
- [ ] Are external API integrations affected?
|
|
- [ ] **Review Frontend Spec (if applicable):**
|
|
- [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
|
|
- [ ] Are specific FE components or user flows impacted?
|
|
- [ ] **Review Other Artifacts (if applicable):**
|
|
- [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
|
|
- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
|
|
|
|
## 4. Path Forward Evaluation
|
|
|
|
- [ ] **Option 1: Direct Adjustment / Integration:**
|
|
- [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
|
|
- [ ] Define the scope and nature of these adjustments.
|
|
- [ ] Assess feasibility, effort, and risks of this path.
|
|
- [ ] **Option 2: Potential Rollback:**
|
|
- [ ] Would reverting completed stories significantly simplify addressing the issue?
|
|
- [ ] Identify specific stories/commits to consider for rollback.
|
|
- [ ] Assess the effort required for rollback.
|
|
- [ ] Assess the impact of rollback (lost work, data implications).
|
|
- [ ] Compare the net benefit/cost vs. Direct Adjustment.
|
|
- [ ] **Option 3: PRD MVP Review & Potential Re-scoping:**
|
|
- [ ] Is the original PRD MVP still achievable given the issue and constraints?
|
|
- [ ] Does the MVP scope need reduction (removing features/epics)?
|
|
- [ ] Do the core MVP goals need modification?
|
|
- [ ] Are alternative approaches needed to meet the original MVP intent?
|
|
- [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
|
|
- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
|
|
|
|
## 5. Sprint Change Proposal Components
|
|
|
|
_(Ensure all agreed-upon points from previous sections are captured in the proposal)_
|
|
|
|
- [ ] **Identified Issue Summary:** Clear, concise problem statement.
|
|
- [ ] **Epic Impact Summary:** How epics are affected.
|
|
- [ ] **Artifact Adjustment Needs:** List of documents to change.
|
|
- [ ] **Recommended Path Forward:** Chosen solution with rationale.
|
|
- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
|
|
- [ ] **High-Level Action Plan:** Next steps for stories/updates.
|
|
- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
|
|
|
|
## 6. Final Review & Handoff
|
|
|
|
- [ ] **Review Checklist:** Confirm all relevant items were discussed.
|
|
- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
|
|
- [ ] **User Approval:** Obtain explicit user approval for the proposal.
|
|
- [ ] **Confirm Next Steps:** Reiterate the handoff plan and the next actions to be taken by specific agents.
|
|
|
|
---
|
|
|
|
==================== END: change-checklist ====================
|
|
|
|
|
|
==================== START: frontend-architecture-checklist ====================
|
|
# 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.
|
|
|
|
---
|
|
|
|
## I. Introduction
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
### 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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
|
|
|
|
- [ ] 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?
|
|
|
|
==================== END: frontend-architecture-checklist ====================
|
|
|
|
|
|
==================== START: pm-checklist ====================
|
|
# Product Manager (PM) Requirements Checklist
|
|
|
|
This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
|
|
|
|
## 1. PROBLEM DEFINITION & CONTEXT
|
|
|
|
### 1.1 Problem Statement
|
|
- [ ] Clear articulation of the problem being solved
|
|
- [ ] Identification of who experiences the problem
|
|
- [ ] Explanation of why solving this problem matters
|
|
- [ ] Quantification of problem impact (if possible)
|
|
- [ ] Differentiation from existing solutions
|
|
|
|
### 1.2 Business Goals & Success Metrics
|
|
- [ ] Specific, measurable business objectives defined
|
|
- [ ] Clear success metrics and KPIs established
|
|
- [ ] Metrics are tied to user and business value
|
|
- [ ] Baseline measurements identified (if applicable)
|
|
- [ ] Timeframe for achieving goals specified
|
|
|
|
### 1.3 User Research & Insights
|
|
- [ ] Target user personas clearly defined
|
|
- [ ] User needs and pain points documented
|
|
- [ ] User research findings summarized (if available)
|
|
- [ ] Competitive analysis included
|
|
- [ ] Market context provided
|
|
|
|
## 2. MVP SCOPE DEFINITION
|
|
|
|
### 2.1 Core Functionality
|
|
- [ ] Essential features clearly distinguished from nice-to-haves
|
|
- [ ] Features directly address defined problem statement
|
|
- [ ] Each Epic ties back to specific user needs
|
|
- [ ] Features and Stories are described from user perspective
|
|
- [ ] Minimum requirements for success defined
|
|
|
|
### 2.2 Scope Boundaries
|
|
- [ ] Clear articulation of what is OUT of scope
|
|
- [ ] Future enhancements section included
|
|
- [ ] Rationale for scope decisions documented
|
|
- [ ] MVP minimizes functionality while maximizing learning
|
|
- [ ] Scope has been reviewed and refined multiple times
|
|
|
|
### 2.3 MVP Validation Approach
|
|
- [ ] Method for testing MVP success defined
|
|
- [ ] Initial user feedback mechanisms planned
|
|
- [ ] Criteria for moving beyond MVP specified
|
|
- [ ] Learning goals for MVP articulated
|
|
- [ ] Timeline expectations set
|
|
|
|
## 3. USER EXPERIENCE REQUIREMENTS
|
|
|
|
### 3.1 User Journeys & Flows
|
|
- [ ] Primary user flows documented
|
|
- [ ] Entry and exit points for each flow identified
|
|
- [ ] Decision points and branches mapped
|
|
- [ ] Critical path highlighted
|
|
- [ ] Edge cases considered
|
|
|
|
### 3.2 Usability Requirements
|
|
- [ ] Accessibility considerations documented
|
|
- [ ] Platform/device compatibility specified
|
|
- [ ] Performance expectations from user perspective defined
|
|
- [ ] Error handling and recovery approaches outlined
|
|
- [ ] User feedback mechanisms identified
|
|
|
|
### 3.3 UI Requirements
|
|
- [ ] Information architecture outlined
|
|
- [ ] Critical UI components identified
|
|
- [ ] Visual design guidelines referenced (if applicable)
|
|
- [ ] Content requirements specified
|
|
- [ ] High-level navigation structure defined
|
|
|
|
## 4. FUNCTIONAL REQUIREMENTS
|
|
|
|
### 4.1 Feature Completeness
|
|
- [ ] All required features for MVP documented
|
|
- [ ] Features have clear, user-focused descriptions
|
|
- [ ] Feature priority/criticality indicated
|
|
- [ ] Requirements are testable and verifiable
|
|
- [ ] Dependencies between features identified
|
|
|
|
### 4.2 Requirements Quality
|
|
- [ ] Requirements are specific and unambiguous
|
|
- [ ] Requirements focus on WHAT not HOW
|
|
- [ ] Requirements use consistent terminology
|
|
- [ ] Complex requirements broken into simpler parts
|
|
- [ ] Technical jargon minimized or explained
|
|
|
|
### 4.3 User Stories & Acceptance Criteria
|
|
- [ ] Stories follow consistent format
|
|
- [ ] Acceptance criteria are testable
|
|
- [ ] Stories are sized appropriately (not too large)
|
|
- [ ] Stories are independent where possible
|
|
- [ ] Stories include necessary context
|
|
- [ ] Local testability requirements (e.g., via CLI) defined in ACs for relevant backend/data stories
|
|
|
|
## 5. NON-FUNCTIONAL REQUIREMENTS
|
|
|
|
### 5.1 Performance Requirements
|
|
- [ ] Response time expectations defined
|
|
- [ ] Throughput/capacity requirements specified
|
|
- [ ] Scalability needs documented
|
|
- [ ] Resource utilization constraints identified
|
|
- [ ] Load handling expectations set
|
|
|
|
### 5.2 Security & Compliance
|
|
- [ ] Data protection requirements specified
|
|
- [ ] Authentication/authorization needs defined
|
|
- [ ] Compliance requirements documented
|
|
- [ ] Security testing requirements outlined
|
|
- [ ] Privacy considerations addressed
|
|
|
|
### 5.3 Reliability & Resilience
|
|
- [ ] Availability requirements defined
|
|
- [ ] Backup and recovery needs documented
|
|
- [ ] Fault tolerance expectations set
|
|
- [ ] Error handling requirements specified
|
|
- [ ] Maintenance and support considerations included
|
|
|
|
### 5.4 Technical Constraints
|
|
- [ ] Platform/technology constraints documented
|
|
- [ ] Integration requirements outlined
|
|
- [ ] Third-party service dependencies identified
|
|
- [ ] Infrastructure requirements specified
|
|
- [ ] Development environment needs identified
|
|
|
|
## 6. EPIC & STORY STRUCTURE
|
|
|
|
### 6.1 Epic Definition
|
|
- [ ] Epics represent cohesive units of functionality
|
|
- [ ] Epics focus on user/business value delivery
|
|
- [ ] Epic goals clearly articulated
|
|
- [ ] Epics are sized appropriately for incremental delivery
|
|
- [ ] Epic sequence and dependencies identified
|
|
|
|
### 6.2 Story Breakdown
|
|
- [ ] Stories are broken down to appropriate size
|
|
- [ ] Stories have clear, independent value
|
|
- [ ] Stories include appropriate acceptance criteria
|
|
- [ ] Story dependencies and sequence documented
|
|
- [ ] Stories aligned with epic goals
|
|
|
|
### 6.3 First Epic Completeness
|
|
- [ ] First epic includes all necessary setup steps
|
|
- [ ] Project scaffolding and initialization addressed
|
|
- [ ] Core infrastructure setup included
|
|
- [ ] Development environment setup addressed
|
|
- [ ] Local testability established early
|
|
|
|
## 7. TECHNICAL GUIDANCE
|
|
|
|
### 7.1 Architecture Guidance
|
|
- [ ] Initial architecture direction provided
|
|
- [ ] Technical constraints clearly communicated
|
|
- [ ] Integration points identified
|
|
- [ ] Performance considerations highlighted
|
|
- [ ] Security requirements articulated
|
|
- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
|
|
|
|
### 7.2 Technical Decision Framework
|
|
- [ ] Decision criteria for technical choices provided
|
|
- [ ] Trade-offs articulated for key decisions
|
|
- [ ] Rationale for selecting primary approach over considered alternatives documented (for key design/feature choices)
|
|
- [ ] Non-negotiable technical requirements highlighted
|
|
- [ ] Areas requiring technical investigation identified
|
|
- [ ] Guidance on technical debt approach provided
|
|
|
|
### 7.3 Implementation Considerations
|
|
- [ ] Development approach guidance provided
|
|
- [ ] Testing requirements articulated
|
|
- [ ] Deployment expectations set
|
|
- [ ] Monitoring needs identified
|
|
- [ ] Documentation requirements specified
|
|
|
|
## 8. CROSS-FUNCTIONAL REQUIREMENTS
|
|
|
|
### 8.1 Data Requirements
|
|
- [ ] Data entities and relationships identified
|
|
- [ ] Data storage requirements specified
|
|
- [ ] Data quality requirements defined
|
|
- [ ] Data retention policies identified
|
|
- [ ] Data migration needs addressed (if applicable)
|
|
- [ ] Schema changes planned iteratively, tied to stories requiring them
|
|
|
|
### 8.2 Integration Requirements
|
|
- [ ] External system integrations identified
|
|
- [ ] API requirements documented
|
|
- [ ] Authentication for integrations specified
|
|
- [ ] Data exchange formats defined
|
|
- [ ] Integration testing requirements outlined
|
|
|
|
### 8.3 Operational Requirements
|
|
- [ ] Deployment frequency expectations set
|
|
- [ ] Environment requirements defined
|
|
- [ ] Monitoring and alerting needs identified
|
|
- [ ] Support requirements documented
|
|
- [ ] Performance monitoring approach specified
|
|
|
|
## 9. CLARITY & COMMUNICATION
|
|
|
|
### 9.1 Documentation Quality
|
|
- [ ] Documents use clear, consistent language
|
|
- [ ] Documents are well-structured and organized
|
|
- [ ] Technical terms are defined where necessary
|
|
- [ ] Diagrams/visuals included where helpful
|
|
- [ ] Documentation is versioned appropriately
|
|
|
|
### 9.2 Stakeholder Alignment
|
|
- [ ] Key stakeholders identified
|
|
- [ ] Stakeholder input incorporated
|
|
- [ ] Potential areas of disagreement addressed
|
|
- [ ] Communication plan for updates established
|
|
- [ ] Approval process defined
|
|
|
|
## PRD & EPIC VALIDATION SUMMARY
|
|
|
|
### Category Statuses
|
|
| Category | Status | Critical Issues |
|
|
|----------|--------|----------------|
|
|
| 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
|
|
| 2. MVP Scope Definition | PASS/FAIL/PARTIAL | |
|
|
| 3. User Experience Requirements | PASS/FAIL/PARTIAL | |
|
|
| 4. Functional Requirements | PASS/FAIL/PARTIAL | |
|
|
| 5. Non-Functional Requirements | PASS/FAIL/PARTIAL | |
|
|
| 6. Epic & Story Structure | PASS/FAIL/PARTIAL | |
|
|
| 7. Technical Guidance | PASS/FAIL/PARTIAL | |
|
|
| 8. Cross-Functional Requirements | PASS/FAIL/PARTIAL | |
|
|
| 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
|
|
|
|
### Critical Deficiencies
|
|
- List all critical issues that must be addressed before handoff to Architect
|
|
|
|
### Recommendations
|
|
- Provide specific recommendations for addressing each deficiency
|
|
|
|
### Final Decision
|
|
- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
|
|
- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
|
|
|
|
==================== END: pm-checklist ====================
|
|
|
|
|
|
==================== START: po-master-checklist ====================
|
|
# Product Owner (PO) 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.
|
|
|
|
## 1. PROJECT SETUP & INITIALIZATION
|
|
|
|
### 1.1 Project Scaffolding
|
|
- [ ] 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)
|
|
|
|
### 1.2 Development Environment
|
|
- [ ] Local development environment setup is clearly defined
|
|
- [ ] Required tools and versions are specified (Node.js, Python, etc.)
|
|
- [ ] Steps for installing dependencies are included
|
|
- [ ] Configuration files (dotenv, config files, etc.) are addressed
|
|
- [ ] Development server setup is included
|
|
|
|
### 1.3 Core Dependencies
|
|
- [ ] All critical packages/libraries are installed early in the process
|
|
- [ ] Package management (npm, pip, etc.) is properly addressed
|
|
- [ ] Version specifications are appropriately defined
|
|
- [ ] Dependency conflicts or special requirements are noted
|
|
|
|
## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
|
|
|
|
### 2.1 Database & Data Store Setup
|
|
- [ ] Database selection/setup occurs before any database 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
|
|
|
|
### 2.2 API & Service Configuration
|
|
- [ ] API frameworks are set up before implementing endpoints
|
|
- [ ] Service architecture is established before implementing services
|
|
- [ ] Authentication framework is set up before protected routes
|
|
- [ ] Middleware and common utilities are created before use
|
|
|
|
### 2.3 Deployment Pipeline
|
|
- [ ] CI/CD pipeline is established before any deployment actions
|
|
- [ ] Infrastructure as Code (IaC) is set up before use
|
|
- [ ] Environment configurations (dev, staging, prod) are defined early
|
|
- [ ] Deployment strategies are defined before implementation
|
|
- [ ] Rollback procedures or considerations are addressed
|
|
|
|
### 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
|
|
|
|
## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
|
|
|
|
### 3.1 Third-Party Services
|
|
- [ ] Account creation steps are identified for required services
|
|
- [ ] API key acquisition processes are defined
|
|
- [ ] Steps for securely storing credentials are included
|
|
- [ ] Fallback or offline development options are considered
|
|
|
|
### 3.2 External APIs
|
|
- [ ] Integration points with external APIs are clearly identified
|
|
- [ ] Authentication with external services is properly sequenced
|
|
- [ ] API limits or constraints are acknowledged
|
|
- [ ] Backup strategies for API failures are considered
|
|
|
|
### 3.3 Infrastructure Services
|
|
- [ ] Cloud resource provisioning is properly sequenced
|
|
- [ ] 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
|
|
|
|
## 4. USER/AGENT RESPONSIBILITY DELINEATION
|
|
|
|
### 4.1 User Actions
|
|
- [ ] 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 Developer Agent Actions
|
|
- [ ] 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
|
|
|
|
## 5. FEATURE SEQUENCING & DEPENDENCIES
|
|
|
|
### 5.1 Functional Dependencies
|
|
- [ ] Features that depend on other features are sequenced correctly
|
|
- [ ] Shared components are built before their use
|
|
- [ ] User flows follow a logical progression
|
|
- [ ] Authentication features precede protected routes/features
|
|
|
|
### 5.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
|
|
|
|
### 5.3 Cross-Epic Dependencies
|
|
- [ ] Later epics build upon functionality from earlier epics
|
|
- [ ] No epic requires functionality from later epics
|
|
- [ ] Infrastructure established in early epics is utilized consistently
|
|
- [ ] Incremental value delivery is maintained
|
|
|
|
## 6. MVP SCOPE ALIGNMENT
|
|
|
|
### 6.1 PRD Goals Alignment
|
|
- [ ] 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
|
|
|
|
### 6.2 User Journey Completeness
|
|
- [ ] 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
|
|
|
|
### 6.3 Technical Requirements Satisfaction
|
|
- [ ] All technical constraints from the PRD are addressed
|
|
- [ ] Non-functional requirements are incorporated
|
|
- [ ] Architecture decisions align with specified constraints
|
|
- [ ] Performance considerations are appropriately addressed
|
|
|
|
## 7. RISK MANAGEMENT & PRACTICALITY
|
|
|
|
### 7.1 Technical Risk Mitigation
|
|
- [ ] 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
|
|
|
|
### 7.2 External Dependency Risks
|
|
- [ ] 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
|
|
|
|
### 7.3 Timeline Practicality
|
|
- [ ] 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
|
|
|
|
## 8. DOCUMENTATION & HANDOFF
|
|
|
|
### 8.1 Developer Documentation
|
|
- [ ] API documentation is created alongside implementation
|
|
- [ ] Setup instructions are comprehensive
|
|
- [ ] Architecture decisions are documented
|
|
- [ ] Patterns and conventions are documented
|
|
|
|
### 8.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
|
|
|
|
## 9. POST-MVP CONSIDERATIONS
|
|
|
|
### 9.1 Future Enhancements
|
|
- [ ] Clear separation between MVP and future features
|
|
- [ ] Architecture supports planned future enhancements
|
|
- [ ] Technical debt considerations are documented
|
|
- [ ] Extensibility points are identified
|
|
|
|
### 9.2 Feedback Mechanisms
|
|
- [ ] Analytics or usage tracking is included if required
|
|
- [ ] User feedback collection is considered
|
|
- [ ] Monitoring and alerting are addressed
|
|
- [ ] Performance measurement is incorporated
|
|
|
|
## VALIDATION SUMMARY
|
|
|
|
### Category Statuses
|
|
| Category | Status | Critical Issues |
|
|
|----------|--------|----------------|
|
|
| 1. Project Setup & Initialization | PASS/FAIL/PARTIAL | |
|
|
| 2. Infrastructure & Deployment Sequencing | PASS/FAIL/PARTIAL | |
|
|
| 3. External Dependencies & Integrations | PASS/FAIL/PARTIAL | |
|
|
| 4. User/Agent Responsibility Delineation | PASS/FAIL/PARTIAL | |
|
|
| 5. Feature Sequencing & Dependencies | PASS/FAIL/PARTIAL | |
|
|
| 6. MVP Scope Alignment | PASS/FAIL/PARTIAL | |
|
|
| 7. Risk Management & Practicality | PASS/FAIL/PARTIAL | |
|
|
| 8. Documentation & Handoff | PASS/FAIL/PARTIAL | |
|
|
| 9. Post-MVP Considerations | PASS/FAIL/PARTIAL | |
|
|
|
|
### Critical Deficiencies
|
|
- List all critical issues that must be addressed before approval
|
|
|
|
### Recommendations
|
|
- Provide specific recommendations for addressing each deficiency
|
|
|
|
### Final Decision
|
|
- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
|
|
- **REJECTED**: The plan requires revision to address the identified deficiencies.
|
|
|
|
==================== END: po-master-checklist ====================
|
|
|
|
|
|
==================== START: story-dod-checklist ====================
|
|
# Story Definition of Done (DoD) Checklist
|
|
|
|
## Instructions for Developer Agent:
|
|
|
|
Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
|
|
|
|
## Checklist Items:
|
|
|
|
1. **Requirements Met:**
|
|
|
|
- [ ] All functional requirements specified in the story are implemented.
|
|
- [ ] All acceptance criteria defined in the story are met.
|
|
|
|
2. **Coding Standards & Project Structure:**
|
|
|
|
- [ ] All new/modified code strictly adheres to `Operational Guidelines`.
|
|
- [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
|
|
- [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
|
|
- [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
|
|
- [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
|
|
- [ ] No new linter errors or warnings introduced.
|
|
- [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
|
|
|
|
3. **Testing:**
|
|
|
|
- [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
|
- [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
|
|
- [ ] All tests (unit, integration, E2E if applicable) pass successfully.
|
|
- [ ] Test coverage meets project standards (if defined).
|
|
|
|
4. **Functionality & Verification:**
|
|
|
|
- [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
|
|
- [ ] Edge cases and potential error conditions considered and handled gracefully.
|
|
|
|
5. **Story Administration:**
|
|
- [ ] All tasks within the story file are marked as complete.
|
|
- [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
|
|
- [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
|
|
6. **Dependencies, Build & Configuration:**
|
|
|
|
- [ ] Project builds successfully without errors.
|
|
- [ ] Project linting passes
|
|
- [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
|
|
- [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
|
|
- [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
|
|
- [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
|
|
|
|
7. **Documentation (If Applicable):**
|
|
- [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
|
|
- [ ] User-facing documentation updated, if changes impact users.
|
|
- [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
|
|
|
|
## Final Confirmation:
|
|
|
|
- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
|
|
|
|
==================== END: story-dod-checklist ====================
|
|
|
|
|
|
==================== START: story-draft-checklist ====================
|
|
# Story Draft Checklist
|
|
|
|
The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
|
|
|
|
## 1. GOAL & CONTEXT CLARITY
|
|
|
|
- [ ] Story goal/purpose is clearly stated
|
|
- [ ] Relationship to epic goals is evident
|
|
- [ ] How the story fits into overall system flow is explained
|
|
- [ ] Dependencies on previous stories are identified (if applicable)
|
|
- [ ] Business context and value are clear
|
|
|
|
## 2. TECHNICAL IMPLEMENTATION GUIDANCE
|
|
|
|
- [ ] Key files to create/modify are identified (not necessarily exhaustive)
|
|
- [ ] Technologies specifically needed for this story are mentioned
|
|
- [ ] Critical APIs or interfaces are sufficiently described
|
|
- [ ] Necessary data models or structures are referenced
|
|
- [ ] Required environment variables are listed (if applicable)
|
|
- [ ] Any exceptions to standard coding patterns are noted
|
|
|
|
## 3. REFERENCE EFFECTIVENESS
|
|
|
|
- [ ] References to external documents point to specific relevant sections
|
|
- [ ] Critical information from previous stories is summarized (not just referenced)
|
|
- [ ] Context is provided for why references are relevant
|
|
- [ ] References use consistent format (e.g., `docs/filename.md#section`)
|
|
|
|
## 4. SELF-CONTAINMENT ASSESSMENT
|
|
|
|
- [ ] Core information needed is included (not overly reliant on external docs)
|
|
- [ ] Implicit assumptions are made explicit
|
|
- [ ] Domain-specific terms or concepts are explained
|
|
- [ ] Edge cases or error scenarios are addressed
|
|
|
|
## 5. TESTING GUIDANCE
|
|
|
|
- [ ] Required testing approach is outlined
|
|
- [ ] Key test scenarios are identified
|
|
- [ ] Success criteria are defined
|
|
- [ ] Special testing considerations are noted (if applicable)
|
|
|
|
## VALIDATION RESULT
|
|
|
|
| Category | Status | Issues |
|
|
| ------------------------------------ | ----------------- | ------ |
|
|
| 1. Goal & Context Clarity | PASS/FAIL/PARTIAL | |
|
|
| 2. Technical Implementation Guidance | PASS/FAIL/PARTIAL | |
|
|
| 3. Reference Effectiveness | PASS/FAIL/PARTIAL | |
|
|
| 4. Self-Containment Assessment | PASS/FAIL/PARTIAL | |
|
|
| 5. Testing Guidance | PASS/FAIL/PARTIAL | |
|
|
|
|
**Final Assessment:**
|
|
|
|
- READY: The story provides sufficient context for implementation
|
|
- NEEDS REVISION: The story requires updates (see issues)
|
|
- BLOCKED: External information required (specify what information)
|
|
|
|
==================== END: story-draft-checklist ====================
|
|
|
|
|