mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-23 11:16:37 +00:00
review of all AI-dev system #01
add refactoring phase complete implementation phase fix wrong links and file names
This commit is contained in:
@@ -3,13 +3,15 @@ Create a focused behavioral specification that describes **what** the system sho
|
||||
|
||||
## Input parameter
|
||||
building_block.md
|
||||
Example: `03_building_blocks/01-dashboard-export-example.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
|
||||
@@ -18,8 +20,8 @@ Generate lean specifications with:
|
||||
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 the `03_feature_specs/spec.md`
|
||||
Example: `03_feature_specs/01-dashboard-export-example.md`
|
||||
6. Save the specification into `_docs/iterative/feature_specs/spec.md`
|
||||
Example: `_docs/iterative/feature_specs/01-dashboard-export-example.md`
|
||||
|
||||
## Specification Structure
|
||||
|
||||
@@ -28,6 +30,8 @@ Generate lean specifications with:
|
||||
# [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
|
||||
@@ -72,7 +76,7 @@ Use sub-sections with bullet points.
|
||||
- Initial data and conditions
|
||||
- What should be tested
|
||||
- How system should behave
|
||||
- List of Non-functional requiremnts to be met
|
||||
- List of Non-functional requirements to be met
|
||||
|
||||
### Constraints
|
||||
|
||||
@@ -90,6 +94,13 @@ 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
|
||||
@@ -97,6 +108,8 @@ Each risk should have:
|
||||
- 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)
|
||||
@@ -173,4 +186,4 @@ And the filename should include a timestamp
|
||||
- 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.
|
||||
**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