# Feature Spec Template

Use this template for every net-new feature and major behavior change.

## Metadata

- Spec ID: SPEC-YYYYMMDD-<short-name>
- Owner:
- Date:
- Status: draft | approved | in-progress | done
- Related issue/PR:

## Problem Statement

Describe the user problem in 2-5 sentences.

## User Story

As a <user type>, I want <capability>, so that <outcome>.

## Scope

### In Scope

1. 
2. 
3. 

### Out of Scope

1. 
2. 

## Functional Requirements

1. 
2. 
3. 

## Acceptance Criteria

1. Given <state>, when <action>, then <result>.
2. Given <state>, when <action>, then <result>.
3. Failure handling is deterministic and user-visible.

## UX Notes

- Entry points (toolbar/panel/command):
- Empty/loading/error states:
- Keyboard shortcuts / accessibility expectations:

## API And Data Contracts

- Endpoints impacted:
- Request/response changes:
- Backward compatibility plan:
- Project schema impact (`shared/project-schema.json`):

## Architecture Impact

- Frontend files/components likely affected:
- Backend routers/services likely affected:
- Tauri/bridge changes required:

## Risks

1. 
2. 

## Test Plan

### Unit Tests

1. 
2. 

### Integration Tests

1. 
2. 

### E2E / Smoke Tests

1. 
2. 

### Regression Tests

List known regressions this spec must prevent.

## Observability

- New logs/error codes:
- Metrics/traces needed:
- Diagnostics artifacts expected on failure:

## Rollout Plan

1. Development and internal validation.
2. Staged rollout or feature flag (if applicable).
3. Rollback path.

## Open Questions

1. 
2. 

## Definition Of Done

1. Acceptance criteria pass.
2. Tests added and green.
3. Docs/instructions updated.
4. Risks and assumptions recorded in PR summary.