## Purpose

Events as records an admin creates and owns: named, typed, any number of them, each holding its own guest list and its own invitation card — so onboarding a customer is a person filling in a screen rather than an engineer editing a seed script.

## ADDED Requirements

### Requirement: Admin-created events (P0)
Admins holding the content-editing permission SHALL be able to create an event by choosing one of the three ceremony types, giving it a name, and supplying its date and venue. Events SHALL no longer be limited to one per type.

#### Scenario: Creating an event
- **WHEN** an admin creates an event of type Walima named "Walima — Dhaka" with a date and venue
- **THEN** the event exists, is listed, and can receive guests and a card design

#### Scenario: Two events of the same type
- **WHEN** an admin creates a second event of type Marriage
- **THEN** the system accepts it and both events exist independently with their own guest lists and cards

#### Scenario: Missing required detail
- **WHEN** an admin submits an event without a type, name, date or venue
- **THEN** the system refuses and names the missing field

### Requirement: Event addressing (P0)
Each event SHALL carry a URL-safe identifier derived from its name, unique across the system, allocated automatically and stable for the life of the event.

#### Scenario: Derived identifier
- **WHEN** an event named "Walima — Dhaka" is created
- **THEN** it receives a URL-safe identifier derived from that name and its open route resolves

#### Scenario: Name collision
- **WHEN** an admin creates a second event whose name would derive an identifier already in use
- **THEN** the system allocates a distinct identifier without rejecting the create

#### Scenario: Renaming
- **WHEN** an admin renames an existing event
- **THEN** its identifier does not change, so links already shared keep working

### Requirement: Deleting an event (P0)
An admin holding the content-editing permission SHALL be able to delete an event. Because deletion destroys that event's guests, invitations and RSVPs, the system SHALL require explicit confirmation stating what will be lost.

#### Scenario: Confirmed deletion
- **WHEN** an admin deletes an event holding 40 guests and confirms
- **THEN** the event, its guest records, invitations and RSVPs are removed and its links stop resolving

#### Scenario: Confirmation states the cost
- **WHEN** an admin begins deleting an event
- **THEN** the confirmation names the number of guests and responses that will be destroyed

### Requirement: Event-scoped guest lists (P0)
A guest record SHALL belong to exactly one event. Guests SHALL be added, listed, edited and deleted from within the event that owns them, and a guest list SHALL never mix events.

#### Scenario: Adding a guest to an event
- **WHEN** an admin opens an event and adds a guest
- **THEN** that guest belongs to that event and appears only in its list
- **AND** an invitation and token for that event are created for them

#### Scenario: The same person at two events
- **WHEN** the same person is to attend two events
- **THEN** they are added separately under each event and exist as two independent guest records

#### Scenario: Listing
- **WHEN** an admin views an event's guest list
- **THEN** only guests belonging to that event are shown, with that event's response counts

### Requirement: Per-event guest uniqueness (P0)
A phone number and an email address SHALL each be unique within an event. The same phone or email MAY appear under a different event. Duplicate detection, including on bulk import, SHALL operate within the event only.

#### Scenario: Duplicate within an event
- **WHEN** an admin adds a guest whose phone already exists under the same event
- **THEN** the system refuses and points at the existing guest

#### Scenario: Same phone under a different event
- **WHEN** the same phone number is added under a different event
- **THEN** the system accepts it as a separate guest record

#### Scenario: Bulk import
- **WHEN** a CSV is imported into an event and two rows share an email
- **THEN** the second is reported as a duplicate of the first within that event, and rows matching guests of other events are not treated as duplicates

### Requirement: Per-event contact suppression (P0)
Because a person exists once per event, contact suppression SHALL apply to the event whose message carried the opt-out, and messaging SHALL state which event an opt-out covers so the guest is not misled.

#### Scenario: Unsubscribing
- **WHEN** a guest uses the unsubscribe link in a message about one event
- **THEN** that event stops messaging them
- **AND** their records under other events are unaffected

#### Scenario: Opt-out wording
- **WHEN** an unsubscribe link is rendered in a message
- **THEN** the accompanying copy names the event the opt-out applies to

#### Scenario: Hard bounce
- **WHEN** an address hard-bounces for one event
- **THEN** that event's record is marked undeliverable and other events continue to attempt delivery

### Requirement: Counts reflect records, not people (P0)
Because a person attending several events exists as several records, aggregate figures SHALL be reported per event, and any total spanning events SHALL be labelled as a count of guest records rather than of people.

#### Scenario: Per-event counts
- **WHEN** an admin views an event
- **THEN** its invited, accepted, declined and pending counts and its headcount are correct for that event

#### Scenario: Aggregate figure
- **WHEN** a figure spanning more than one event is displayed
- **THEN** it is labelled as guest records, not as unique people

### Requirement: No cross-event linking for guests (P0)
Because guest records are independent per event, the invitation page SHALL NOT offer navigation between a guest's invitations to different events.

#### Scenario: Guest with records under two events
- **WHEN** a guest holding separate records under two events opens either invitation link
- **THEN** no link to the other event's invitation is shown, and each link resolves only to its own event