<!--
Body template for requirements.md
Loaded by /reversa-requirements and updated by /reversa-clarify.

FILLING RULES:
- Keep the order of mandatory sections.
- Do not delete sections marked as mandatory, even when empty (use "n/a" if necessary).
- Inline comments (between <!-- -->) should only be removed when the corresponding section is fully filled in.
- Use 🟢 / 🟡 / 🔴 according to the confidence level of the _reversa_sdd/ source that backs the statement.
- Mark with [DOUBT] any point where information is missing; maximum of three markers in the initial document.
-->

# Requirements: <FEATURE NAME>

> Identifier: `<NNN>-<short-name>`
> Date: `YYYY-MM-DD`
> Reverse extraction folder: `_reversa_sdd/`
> Confidence: 🟢 CONFIRMED, 🟡 INFERRED, 🔴 GAP / DOUBT

## 1. Executive summary

<!--
Up to five lines. State what the feature delivers, for whom, and what legacy problem it solves.
Do NOT describe how it will be implemented.
-->

## 2. Context from the legacy

<!--
List the reverse pipeline artifacts that support this feature.
Each citation in the format _reversa_sdd/<file>#<section>.
Use confidence inherited from the original source.
-->

| Source | Relevant excerpt | Confidence |
|--------|-----------------|------------|
| `_reversa_sdd/architecture.md#<section>` | <summary> | 🟢 |
| `_reversa_sdd/domain.md#<section>` | <summary> | 🟢 |
| `_reversa_sdd/code-analysis.md#<component>` | <summary> | 🟡 |

## 3. Personas and usage scenarios

<!-- Who uses it, with what goal, and at what frequency. -->

| Persona | Goal | Key scenario |
|---------|------|--------------|
| <persona> | <goal> | <description in one sentence> |

## 4. New or changed business rules

<!--
Each rule as a numbered item. For rules that CHANGE a confirmed legacy rule,
reference the original rule via `_reversa_sdd/domain.md#<id>`.
Mark each rule with 🟢 / 🟡 / 🔴.
-->

1. **BR-01:** <description> 🟢
   - Legacy origin: `_reversa_sdd/domain.md#<id>` (if applicable)
   - Type: new | changed | removed
2. **BR-02:** ...

## 5. Functional Requirements

| ID | Requirement | Priority | Acceptance criterion | Confidence |
|----|-------------|----------|----------------------|------------|
| RF-01 | <description> | Must | <verifiable criterion> | 🟢 |
| RF-02 | <description> | Should | <verifiable criterion> | 🟡 |

## 6. Non-Functional Requirements

| Type | Requirement | Evidence or rationale | Confidence |
|------|-------------|-----------------------|------------|
| Performance | <requirement> | <source or rationale> | 🟢 |
| Security | <requirement> | <source or rationale> | 🟡 |
| Observability | <requirement> | <source or rationale> | 🟡 |

## 7. Acceptance Criteria

```gherkin
Scenario: <title>
  Given <precondition>
  When <actor action>
  Then <observable result>

Scenario: <title of negative case>
  Given <precondition>
  When <invalid action>
  Then <expected failure behavior>
```

## 8. MoSCoW Priority

| Item | MoSCoW | Rationale |
|------|--------|-----------|
| RF-01 | Must | <reason> |
| RF-02 | Should | <reason> |
| Performance RNF | Should | <reason> |

## 9. Clarifications

<!--
This section is filled in ONLY by /reversa-clarify.
Before the first doubt session, keep the section with the notice below.
-->

> No doubt session recorded yet. Run `/reversa-clarify` when there is a pending `[DOUBT]`.

## 10. Gaps

<!--
List unanswered points. Gaps resolved by /reversa-clarify are removed from here and recorded in the history.
-->

- 🔴 [DOUBT] <unanswered point>
- 🔴 [DOUBT] <unanswered point>

## 11. Change history

| Date | Change | Author |
|------|--------|--------|
| YYYY-MM-DD | Initial version generated by `/reversa-requirements` | reversa |
