mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-23 03:16:35 +00:00
organize structure for .roo and for ai in general
rework rulels
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,189 @@
|
||||
# Generate Feature Specification
|
||||
Create a focused behavioral specification that describes **what** the system should do, not **how** it should be built.
|
||||
|
||||
## Input parameter
|
||||
building_block.md
|
||||
Example: `_docs/iterative/building_blocks/01-dashboard-export-example.md`
|
||||
|
||||
## Objective
|
||||
Generate lean specifications with:
|
||||
- Clear problem statement and desired outcomes
|
||||
- Behavioral acceptance criteria in Gherkin format
|
||||
- Essential non-functional requirements
|
||||
- Complexity estimation
|
||||
- Feature dependencies
|
||||
- No implementation prescriptiveness
|
||||
|
||||
## Process
|
||||
1. Read the building_block.md
|
||||
2. Analyze the codebase to understand context
|
||||
3. Generate a behavioral specification using the structure below
|
||||
4. **DO NOT** include implementation details, file structures, or technical architecture
|
||||
5. Focus on behavior, user experience, and acceptance criteria
|
||||
6. Save the specification into `_docs/iterative/feature_specs/spec.md`
|
||||
Example: `_docs/iterative/feature_specs/01-dashboard-export-example.md`
|
||||
|
||||
## Specification Structure
|
||||
|
||||
### Header
|
||||
```markdown
|
||||
# [Feature Name]
|
||||
|
||||
**Status**: Draft | **Date**: [YYYY-MM-DD] | **Feature**: [Brief Feature Description]
|
||||
**Complexity**: [1|2|3|5|8] points
|
||||
**Dependencies**: [List dependent features or "None"]
|
||||
```
|
||||
|
||||
### Problem
|
||||
Clear, concise statement of the problem users are facing.
|
||||
|
||||
### Outcome
|
||||
Measurable or observable goals/benefits (use bullet points).
|
||||
|
||||
### Scope
|
||||
#### Included
|
||||
What's in scope for this feature (bullet points).
|
||||
#### Excluded
|
||||
Explicitly what's **NOT** in scope (bullet points).
|
||||
|
||||
### Acceptance Criteria
|
||||
Each acceptance criterion should be:
|
||||
- Numbered sequentially (AC-1, AC-2, etc.)
|
||||
- Include a brief title
|
||||
- Written in Gherkin format (Given/When/Then)
|
||||
|
||||
Example:
|
||||
**AC-1: Export Availability**
|
||||
Given the user is viewing the dashboard
|
||||
When the dashboard loads
|
||||
Then an "Export to Excel" button should be visible in the filter/actions area
|
||||
|
||||
### Non-Functional Requirements
|
||||
Only include essential non-functional requirements:
|
||||
- Performance (if relevant)
|
||||
- Compatibility (if relevant)
|
||||
- Reliability (if relevant)
|
||||
|
||||
Use sub-sections with bullet points.
|
||||
|
||||
### Unit tests based on Acceptance Criteria
|
||||
- Acceptance criteria references
|
||||
- What should be tested
|
||||
- Required outcome
|
||||
|
||||
### Integration tests based on Acceptance Criteria and/or Non-Functional requirements
|
||||
- Acceptance criteria references
|
||||
- Initial data and conditions
|
||||
- What should be tested
|
||||
- How system should behave
|
||||
- List of Non-functional requirements to be met
|
||||
|
||||
### Constraints
|
||||
|
||||
High-level constraints that guide implementation:
|
||||
- Architectural patterns (if critical)
|
||||
- Technical limitations
|
||||
- Integration requirements
|
||||
- No breaking changes (if applicable)
|
||||
|
||||
### Risks & Mitigation
|
||||
|
||||
List key risks with mitigation strategies (if applicable).
|
||||
|
||||
Each risk should have:
|
||||
- *Risk*: Description
|
||||
- *Mitigation*: Approach
|
||||
|
||||
## Complexity Points Guide
|
||||
- 1 point: Trivial, self-contained, no dependencies
|
||||
- 2 points: Non-trivial, low complexity, minimal coordination
|
||||
- 3 points: Multi-step, moderate complexity, potential alignment needed
|
||||
- 5 points: Difficult, interconnected logic, medium-high risk
|
||||
- 8 points: High ambiguity, multiple components, very high risk (consider splitting)
|
||||
|
||||
## Output Guidelines
|
||||
**DO:**
|
||||
- Focus on behavior and user experience
|
||||
- Use clear, simple language
|
||||
- Keep acceptance criteria testable
|
||||
- Include realistic scope boundaries
|
||||
- Write from the user's perspective
|
||||
- Include complexity estimation
|
||||
- Note dependencies on other features
|
||||
|
||||
**DON'T:**
|
||||
- Include implementation details (file paths, classes, methods)
|
||||
- Prescribe technical solutions or libraries
|
||||
- Add architectural diagrams or code examples
|
||||
- Specify exact API endpoints or data structures
|
||||
- Include step-by-step implementation instructions
|
||||
- Add "how to build" guidance
|
||||
|
||||
|
||||
|
||||
## Example
|
||||
|
||||
```markdown
|
||||
# Dashboard Export to Excel
|
||||
|
||||
**Status**: Draft | **Date**: 2025-01-XX | **Feature**: Export Dashboard Data to Excel
|
||||
|
||||
## Problem
|
||||
|
||||
Users currently have no efficient way to export dashboard data for offline analysis, reporting, or sharing. Manual copy-paste is time-consuming, error-prone, and lacks context about active filters.
|
||||
|
||||
## Outcome
|
||||
- Eliminate manual copy-paste workflows
|
||||
- Enable accurate data sharing with proper context
|
||||
- Measurable time savings (target: <30s vs. several minutes)
|
||||
- Improved data consistency for offline analysis
|
||||
|
||||
## Scope
|
||||
### Included
|
||||
- Export filtered dashboard data to Excel
|
||||
- Single-click export from dashboard view
|
||||
- Respect all active filters (status, date range)
|
||||
### Excluded
|
||||
- CSV or PDF export options
|
||||
- Scheduled or automated exports
|
||||
- Email export functionality
|
||||
|
||||
## Acceptance Criteria
|
||||
**AC-1: Export Button Visibility**
|
||||
Given the user is viewing the dashboard
|
||||
When the dashboard loads
|
||||
Then an "Export to Excel" button should be visible in the actions area
|
||||
|
||||
**AC-2: Basic Export Functionality**
|
||||
Given the user is viewing the dashboard with data
|
||||
When the user clicks the "Export to Excel" button
|
||||
Then an Excel file should download to their default location
|
||||
And the filename should include a timestamp
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
**Performance**
|
||||
- Export completes in <2 seconds for up to 1000 records
|
||||
- Support up to 10,000 records per export
|
||||
|
||||
**Compatibility**
|
||||
- Excel files openable in Microsoft Excel, Google Sheets, and LibreOffice
|
||||
- Standard Excel format (.xlsx)
|
||||
|
||||
## Constraints
|
||||
- Must respect all currently active filters
|
||||
- Must follow existing hexagonal architecture patterns
|
||||
- No breaking changes to existing functionality
|
||||
|
||||
## Risks & Mitigation
|
||||
**Risk 1: Excel File Compatibility**
|
||||
- *Risk*: Generated files don't open correctly in all spreadsheet applications
|
||||
- *Mitigation*: Use standard Excel format, test with multiple applications
|
||||
```
|
||||
|
||||
## Implementation Notes
|
||||
- Use descriptive but concise titles
|
||||
- Keep specifications focused and scoped appropriately
|
||||
- Remember: This is a **behavioral spec**, not an implementation plan
|
||||
|
||||
**CRITICAL**: Generate the spec file ONLY. Do NOT modify code, create files, or make any implementation changes at this stage.
|
||||
Reference in New Issue
Block a user