gps-denied-onboard/.cursor/commands/4.development/4.10_generate_spec.md

# Generate Feature Specification

Create a focused behavioral specification that describes **what** the system should do, not **how** it should be built.

## Objective

Generate lean specifications with:
- Clear problem statement and desired outcomes
- Behavioral acceptance criteria in Gherkin format
- Essential non-functional requirements
- No implementation prescriptiveness

## Process

1. Read the building block or feature description
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

## Specification Structure

### Header
```markdown
# [Feature Name]

**Status**: Draft | **Date**: [YYYY-MM-DD] | **Feature**: [Brief Feature Description]
```

### 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:
```markdown
**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.

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

---

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

**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.