## ADDED Requirements

### Requirement: Host block at the foot of the invitation (P1)
The invitation SHALL name who is inviting the guest. Below the call to action, at the very
bottom of the supporting detail, the page SHALL render a **host block** containing the label
**"Invited By"**, the event's host name(s) and the event's host phone, centred horizontally,
as the last thing on the page.

The label SHALL be rendered above the name line, and SHALL be visually subordinate to the
names it introduces — it identifies what follows rather than competing with it.

The host block SHALL be server-rendered text present in the initial HTML, like every other
piece of invitation detail — it SHALL NOT depend on JavaScript to appear.

#### Scenario: Host block position
- **WHEN** a guest scrolls to the bottom of their invitation
- **THEN** the label, host name(s) and phone are the last content on the page, centred

#### Scenario: Label reads as a label
- **WHEN** the host block is rendered
- **THEN** "Invited By" appears above the names, styled less prominently than them, so the names remain what the guest reads first

#### Scenario: Present without JavaScript
- **WHEN** the invitation is loaded with scripting unavailable
- **THEN** the host names and phone are still readable in the page

#### Scenario: Shown on the open route too
- **WHEN** a visitor opens the tokenless `/e/{slug}` route
- **THEN** the same host block for that event is rendered, since it carries no guest data

#### Scenario: Host block carries no guest data
- **WHEN** the host block is rendered on any route
- **THEN** it contains only the label, the event's host names and host phone, and no information about the guest

### Requirement: Host name composition (P1)
The host names SHALL be composed into a single line according to how many were given. Where
only a primary host name exists, that name SHALL be rendered alone. Where a secondary host
name also exists, the two SHALL be rendered joined by the word **"And"**, in the order
primary then secondary. The phone SHALL be rendered beneath the name line, not on it.

#### Scenario: One host
- **WHEN** an event has a primary host name of "Abdul Karim" and no secondary name
- **THEN** the host block's name line reads "Abdul Karim"

#### Scenario: Two hosts
- **WHEN** an event has host names "Abdul Karim" and "Rahima Karim"
- **THEN** the host block's name line reads "Abdul Karim And Rahima Karim"

#### Scenario: Phone on its own line
- **WHEN** the host block is rendered with either one or two names
- **THEN** the phone appears on a separate line below the name line

#### Scenario: Long names
- **WHEN** two host names together exceed the width of the narrowest supported viewport
- **THEN** the line wraps without truncation or horizontal scrolling

### Requirement: Host phone is dialable (P1)
The host phone in the host block SHALL be actionable on a touch device: pressing it SHALL
start a call to that number rather than merely displaying it.

#### Scenario: Tapping the number
- **WHEN** a guest on a phone presses the host phone number
- **THEN** their device offers to dial that number

#### Scenario: Displayed form
- **WHEN** the host phone is rendered
- **THEN** the number a guest reads is the stored number, not a truncated or reformatted variant that would fail to dial

## REMOVED Requirements

### Requirement: Wedding-wide host phone on the invitation page
**Reason**: Superseded by the per-event host block. The wedding-wide number was the only host
contact on the invitation and it appeared unlabelled, with no name attached and the same value
for every event — which is wrong for a wedding whose ceremonies are hosted by different
families. Rendering both would show a guest two phone numbers on one page.

**Migration**: The per-event host block replaces it on the invitation surfaces (`/i/{token}`
and `/e/{slug}`). The wedding-wide value is retained in the wedding record and continues to be
used by the cancellation surface and the RSVP-closed message, which this change does not
alter. Every event is given host details on upgrade, so no invitation loses its host contact.

#### Scenario: Invitation page after this change
- **WHEN** a guest opens their invitation for an event whose host details are set
- **THEN** the event's host block is the only host contact rendered on the page, and the wedding-wide number does not additionally appear