# Feature Documentation

## Context

Module: {{MODULE_NAME}}
Feature: {{FEATURE_NAME}}
Feature description: {{FEATURE_DESCRIPTION}}
Research context: {{RESEARCH_CONTEXT}}

## Instructions

Write a feature documentation file for the {{FEATURE_NAME}} feature.

1. Read existing feature docs in `{{MODULES_ROOT}}/{{MODULE_NAME}}/docs/feature/` for style reference
2. Scaffold the file:
   ```bash
   erp-kit module generate doc feature {{FEATURE_SLUG}} -p {{MODULES_ROOT}}/{{MODULE_NAME}}
   ```
3. Fill in the scaffolded file following the structure below

## Feature Doc Structure

### Overview

1-2 paragraphs explaining what the feature does and why it exists.

### Business Purpose

Bulleted list of business needs this feature addresses.

### Process Flow

Mermaid flowchart showing the main workflow. Use `flowchart TD` format.

### Scenario Patterns

Bulleted list of concrete usage scenarios. Each pattern:

- **Pattern name**: Brief description of when/how this scenario occurs

### Test Cases

Bulleted list of testable assertions. Each test case should be a single sentence starting with a verb or condition:

- "Creating X with valid data should succeed"
- "X must be unique (no duplicates)"
- "Deactivating X while Y should be prevented"

Cover: happy paths, uniqueness/validation, authorization, edge cases.

### Reference Links (optional)

Links to relevant standards, specs, or external documentation.

## Guidelines

- Keep the overview concise (~100-200 words)
- Scenario patterns should reflect real business use cases, not implementation details
- Test cases should be verifiable from the feature spec alone (no implementation knowledge needed)
- Use the research context to inform realistic scenarios and edge cases
- Do not reference other features' internal details; describe integration points at a high level