## ADDED Requirements

### Requirement: Send-invitation action on the guest row (P0)
Each row of the guest list SHALL carry an explicit action that opens that guest's detail
view for sending their invitation, presented alongside the row's other actions. The guest's
name SHALL be plain text and SHALL NOT itself be an interactive control, so the detail view
has exactly one named affordance rather than two that do the same thing.

#### Scenario: Opening from the row action
- **WHEN** an admin activates the send-invitation action on a guest row
- **THEN** that guest's detail view opens, showing their invitations and the send controls

#### Scenario: The name is not a control
- **WHEN** an admin clicks a guest's name in the list
- **THEN** nothing opens, and the name presents itself as text rather than as a link or button

#### Scenario: Reachable by keyboard
- **WHEN** an admin moves through the guest list by keyboard
- **THEN** the send-invitation action is focusable and its accessible name identifies the guest it belongs to

#### Scenario: Permission
- **WHEN** an admin without the send-messages permission views the guest list
- **THEN** the send-invitation action is not offered

### Requirement: Guest detail sections are separately identifiable (P0)
The guest detail view SHALL present its distinct jobs as separately identifiable sections,
each with a visible heading and its own visual container, so that copying a link, composing a
message and correcting an RSVP are told apart without reading their contents. The link
controls SHALL be headed "Send via copying the link" and the compose-and-send controls "Send
via messaging".

#### Scenario: Sections are distinguishable
- **WHEN** an admin opens a guest's detail view
- **THEN** each section is visually delimited from its neighbours and carries a heading naming what it is for

#### Scenario: Headings are structural
- **WHEN** the detail view is read by assistive technology
- **THEN** each section's heading is exposed as a heading, in the order the sections appear

#### Scenario: Contrast
- **WHEN** section surfaces, borders and text are rendered
- **THEN** their contrast meets the accessibility contrast requirement applied elsewhere in the admin

### Requirement: Compose-and-send panel in guest detail (P0)
Below the invitation-link controls, each invitation SHALL offer a compose panel showing the
message that would be sent — subject, header, body and footer — as editable text, with a
single control that sends it by email. The panel SHALL state the address it will send to, and
SHALL disable the send control with the reason shown when that guest cannot be emailed.

#### Scenario: Composed message is shown before sending
- **WHEN** an admin opens the compose panel
- **THEN** the full message that would be sent is shown as editable text, not as a summary or a preview of a template

#### Scenario: Recipient stated
- **WHEN** the compose panel is shown for a guest with an email address
- **THEN** the address the message will be sent to is visible in the panel

#### Scenario: Cannot be emailed
- **WHEN** the guest has no address, has opted out, or has hard-bounced
- **THEN** the send control is disabled and the panel states which of these applies

#### Scenario: One invitation at a time
- **WHEN** a guest holds an invitation to one event
- **THEN** the panel composes for that invitation, and the message names that event
