forked from jsnbuchanan/crowd-funder-for-time-pwa
a224aced85
- Reorganize cursor rules into logical domain-based directories - Implement meta-rule system for workflow-specific rule bundling - Move core rules to dedicated /core directory - Consolidate development rules under /development namespace - Add architectural patterns and implementation examples - Create workflow-specific meta-rules for common development tasks - Remove deprecated standalone rule files - Update package dependencies for new rule structure BREAKING CHANGE: Cursor rules file structure has been reorganized Files moved from root rules directory to domain-specific subdirectories
129 lines
3.8 KiB
Plaintext
129 lines
3.8 KiB
Plaintext
# Realistic Time Estimation — Development Guidelines
|
|
|
|
> **Agent role**: **DO NOT MAKE TIME ESTIMATES**. Instead, use phases,
|
|
> milestones, and complexity levels. Time estimates are consistently wrong
|
|
> and create unrealistic expectations.
|
|
|
|
## Purpose
|
|
|
|
Development time estimates are consistently wrong and create unrealistic
|
|
expectations. This rule ensures we focus on phases, milestones, and
|
|
complexity rather than trying to predict specific timeframes.
|
|
|
|
## Critical Rule
|
|
|
|
**NEVER provide specific time estimates** (hours, days, weeks) for
|
|
development tasks. Instead, use:
|
|
|
|
- **Complexity levels** (Low, Medium, High, Critical)
|
|
|
|
- **Phases and milestones** with clear acceptance criteria
|
|
|
|
- **Platform-specific considerations** (Web, Mobile, Desktop)
|
|
|
|
- **Testing requirements** and validation steps
|
|
|
|
## Planning Framework
|
|
|
|
### Complexity Assessment
|
|
|
|
- **Low**: Simple changes, existing patterns, minimal testing
|
|
|
|
- **Medium**: New features, moderate testing, some integration
|
|
|
|
- **High**: Complex features, extensive testing, multiple platforms
|
|
|
|
- **Critical**: Core architecture changes, full regression testing
|
|
|
|
### Platform Categories
|
|
|
|
- **Web**: Browser compatibility, responsive design, accessibility
|
|
|
|
- **Mobile**: Native APIs, platform-specific testing, deployment
|
|
|
|
- **Desktop**: Electron integration, system APIs, distribution
|
|
|
|
### Testing Strategy
|
|
|
|
- **Unit tests**: Core functionality validation
|
|
|
|
- **Integration tests**: Component interaction testing
|
|
|
|
- **E2E tests**: User workflow validation
|
|
|
|
- **Platform tests**: Cross-platform compatibility
|
|
|
|
## Process Guidelines
|
|
|
|
### Planning Phase
|
|
|
|
1. **Scope Definition**: Clear requirements and acceptance criteria
|
|
|
|
2. **Complexity Assessment**: Evaluate technical and business complexity
|
|
|
|
3. **Phase Breakdown**: Divide into logical, testable phases
|
|
|
|
4. **Milestone Definition**: Define success criteria for each phase
|
|
|
|
### Execution Phase
|
|
|
|
1. **Phase 1**: Foundation and core implementation
|
|
|
|
2. **Phase 2**: Feature completion and integration
|
|
|
|
3. **Phase 3**: Testing, refinement, and documentation
|
|
|
|
4. **Phase 4**: Deployment and validation
|
|
|
|
### Validation Phase
|
|
|
|
1. **Acceptance Testing**: Verify against defined criteria
|
|
|
|
2. **Platform Testing**: Validate across target platforms
|
|
|
|
3. **Performance Testing**: Ensure performance requirements met
|
|
|
|
4. **Documentation**: Update relevant documentation
|
|
|
|
## Remember
|
|
|
|
**Your first estimate is wrong. Your second estimate is probably still
|
|
wrong. Focus on progress, not deadlines.**
|
|
|
|
---
|
|
|
|
**See also**:
|
|
|
|
- `.cursor/rules/development/planning_examples.mdc` for detailed planning examples
|
|
|
|
- `.cursor/rules/development/complexity_assessment.mdc` for complexity evaluation
|
|
|
|
**Status**: Active development guidelines
|
|
**Priority**: High
|
|
**Estimated Effort**: Ongoing reference
|
|
**Dependencies**: None
|
|
**Stakeholders**: Development team, Project managers
|
|
|
|
## Model Implementation Checklist
|
|
|
|
### Before Time Estimation
|
|
|
|
- [ ] **Requirements Analysis**: Understand all requirements and acceptance criteria
|
|
- [ ] **Complexity Assessment**: Evaluate technical and business complexity
|
|
- [ ] **Platform Review**: Identify requirements across all target platforms
|
|
- [ ] **Stakeholder Input**: Gather input from all affected parties
|
|
|
|
### During Time Estimation
|
|
|
|
- [ ] **Phase Breakdown**: Divide work into logical, testable phases
|
|
- [ ] **Complexity Classification**: Assign complexity levels (Low/Medium/High/Critical)
|
|
- [ ] **Platform Considerations**: Account for platform-specific requirements
|
|
- [ ] **Testing Strategy**: Plan comprehensive testing approach
|
|
|
|
### After Time Estimation
|
|
|
|
- [ ] **Milestone Definition**: Define success criteria for each phase
|
|
- [ ] **Progress Tracking**: Set up monitoring and tracking mechanisms
|
|
- [ ] **Documentation**: Document estimation process and assumptions
|
|
- [ ] **Stakeholder Communication**: Share estimation approach and progress focus
|