## ADDED Requirements

### Requirement: Event host identity (P1)
Every event SHALL carry the identity of its host: a **primary host name** that is required, a
**secondary host name** that is optional, and a **host phone** that is required. These belong
to the event, not to the wedding — two events of the same wedding MAY be hosted by different
people and SHALL be able to hold different values.

The host phone SHALL be normalised and stored the same way every other phone number in the
system is, so that a number typed as `01711223344` and one typed as `+8801711223344` are
stored identically and are dialable from the invitation.

#### Scenario: Both host names given
- **WHEN** an admin sets the primary host name to "Abdul Karim", the secondary to "Rahima Karim" and the phone to a valid number
- **THEN** all three are stored against that event and none of them affects any other event

#### Scenario: Only the required fields given
- **WHEN** an admin sets a primary host name and a phone but leaves the secondary name empty
- **THEN** the event is stored with no secondary host name, and this is a complete, valid event

#### Scenario: Two events, two hosts
- **WHEN** the Mehedi's host is set to one family and the Walima's to another
- **THEN** each event keeps its own host name(s) and phone, and neither overwrites the other

#### Scenario: Phone normalisation
- **WHEN** an admin enters a Bangladeshi number in local form
- **THEN** it is stored in E.164 form, exactly as a guest's phone number would be

### Requirement: Host fields are collected when an event is created (P1)
The Create event form SHALL collect the primary host name, the secondary host name and the
host phone. The primary host name and the host phone SHALL be required: the form SHALL NOT
submit without them, and the API SHALL reject a create request that omits either. The
secondary host name SHALL be clearly marked optional.

#### Scenario: Creating with complete host details
- **WHEN** an admin fills in the ceremony, name, venue, host name and host phone and submits
- **THEN** the event is created carrying those host details

#### Scenario: Missing the required host name
- **WHEN** an admin submits the create form with the primary host name left empty
- **THEN** the event is not created, and the form states which field is missing

#### Scenario: Missing the phone
- **WHEN** an admin submits the create form with the host phone left empty
- **THEN** the event is not created, and the form states that a host phone is required

#### Scenario: API called directly without host details
- **WHEN** a client calls the event-creation endpoint without a primary host name or without a host phone
- **THEN** the request is rejected as invalid and no event is created

#### Scenario: Malformed phone
- **WHEN** an admin enters a host phone that is not a recognisable number
- **THEN** the event is not created, and the error names the phone field rather than failing generically

### Requirement: Host details are editable in the event editor (P1)
The event editor SHALL present the host fields in their own labelled section, positioned
**after** the event settings and **immediately before** the Card design section. Editing them
SHALL follow the same staged-save behaviour as the rest of the settings — changes take effect
when the editor's Save is pressed, not on each keystroke.

The editor SHALL enforce the same requiredness as creation: an event SHALL NOT be saved with
its primary host name or host phone cleared.

#### Scenario: Section placement
- **WHEN** an admin opens the event editor
- **THEN** a host section appears between the settings section and the Card design section

#### Scenario: Editing a host name
- **WHEN** an admin changes the secondary host name and presses Save
- **THEN** the new value is stored and appears the next time the editor is opened

#### Scenario: Unsaved edits are not applied
- **WHEN** an admin types a new host phone and closes the editor without saving
- **THEN** the stored host phone is unchanged

#### Scenario: Clearing a required field
- **WHEN** an admin empties the primary host name or the host phone and presses Save
- **THEN** the save is refused and the editor states which field is required

#### Scenario: Removing the optional name
- **WHEN** an admin empties the secondary host name and presses Save
- **THEN** the event is saved with no secondary host name

### Requirement: Existing events are given host details on upgrade (P1)
Events that existed before this capability SHALL NOT be left without host details, because
the invitation page renders the host block for every event. On upgrade each existing event
SHALL be given a primary host name and a host phone, and SHALL be left with no secondary host
name.

The host is a parent of the couple, and no stored value names one. The upgrade SHALL NOT
substitute the couple's own names for the host's: an invitation stating that the bride and
groom host themselves is a false statement, not an approximation. Each existing event SHALL
instead be given a **host name placeholder** that an admin opening the editor recognises
immediately as needing correction.

The host phone SHALL be taken from the wedding's recorded contact number, which is a genuine
family contact. Where the wedding holds no such number, the event SHALL be given a
**placeholder phone** that is visibly not a real number and that does not connect a caller to
an unrelated person.

#### Scenario: Wedding has a contact phone
- **WHEN** an existing event belongs to a wedding whose contact phone is set
- **THEN** that event's host phone is that number

#### Scenario: Wedding has no contact phone
- **WHEN** an existing event belongs to a wedding with no contact phone recorded
- **THEN** the event is given a placeholder host phone that an admin can recognise as needing correction, and that reaches nobody if dialled

#### Scenario: Host name on an upgraded event
- **WHEN** an existing event is upgraded
- **THEN** its primary host name is a recognisable placeholder, its secondary host name is absent, and neither the bride's nor the groom's name has been written as a host

#### Scenario: Placeholders are editable, not locked
- **WHEN** an admin opens an event that received placeholder host details
- **THEN** the fields are ordinary editable fields showing those values, and saving the real host details replaces them permanently

#### Scenario: No event is left invalid
- **WHEN** the upgrade completes
- **THEN** every event has a primary host name and a host phone, and the invitation page can render a host block for all of them