# Recordings Library Specification

## Purpose

A browsable recordings list with storage usage and per-recording
rename/share/delete, constrained to what `servicio_grabacion_radio.dart`
already exposes. Traceable to WU15.

## Requirements

### Requirement: Storage Usage Display

The screen MUST show used vs. total storage as a progress bar with a
caption (used amount, total amount, retention/path info).

#### Scenario: Storage usage renders proportionally

- GIVEN recordings occupy 84 MB of a 200 MB budget
- WHEN the screen renders
- THEN the progress bar fill reflects 84/200 and the caption states both values

### Requirement: Browsable Recordings List

The screen MUST list individual recordings sourced from the recordings
folder, each row showing name, date, duration, and size, with inline
playback.

#### Scenario: Recordings on disk render as rows

- GIVEN 3 recording files exist in the recordings folder
- WHEN the screen loads
- THEN exactly 3 rows render, each with correct name/date/duration/size

#### Scenario: No recordings (edge case)

- GIVEN the recordings folder is empty
- WHEN the screen loads
- THEN an empty state renders, not an error

#### Scenario: Row playback starts and stops

- GIVEN a recording row is visible
- WHEN the user taps its play control
- THEN playback of that recording starts
- AND tapping again stops it

### Requirement: Per-Recording Menu Constrained to Rename/Share/Delete

The "⋮" menu on each recording row MUST expose exactly three actions —
Rename, Share, Delete — constrained to capabilities already exposed by
`servicio_grabacion_radio.dart`. It MUST NOT expose an action that service
does not support.

#### Scenario: Menu shows exactly 3 actions

- GIVEN any recording row
- WHEN its "⋮" menu opens
- THEN exactly Rename, Share, and Delete are shown, no other action

#### Scenario: Delete removes the file and its row

- GIVEN a recording row's menu is open
- WHEN the user selects Delete and confirms
- THEN the underlying file is removed and the row disappears from the list

#### Scenario: Rename updates the displayed name

- GIVEN a recording row's menu is open
- WHEN the user selects Rename and submits a new, non-empty name
- THEN the row displays the new name and it persists across a reload

#### Scenario: Share invokes the platform share sheet

- GIVEN a recording row's menu is open
- WHEN the user selects Share
- THEN the platform share sheet opens with that recording's file