## MODIFIED 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. Every event SHALL have exactly one owning admin account,
recorded when the event is created and never absent: an event created by a Host is owned by that
Host, and an event created by a Super Admin is owned by that Super Admin unless they name another
active account as the owner in the same action.

#### 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: A host owns what they create
- **WHEN** a Host creates an event
- **THEN** that event is owned by them and appears in their event list immediately

#### Scenario: A super admin creates on someone's behalf
- **WHEN** a Super Admin creates an event and names an active Host as its owner
- **THEN** the event is owned by that Host and appears in the Host's event list

#### 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

## ADDED Requirements

### Requirement: The visible-event set (P0)
Every admin request SHALL be answered against the set of events visible to the caller: for a
Super Admin that is every event in the system; for a Host it is exactly the events they own. This
set SHALL be applied when the records are selected, not filtered out of an answer already
assembled, so a record outside the set is never read, counted, exported, sent to, or reported on.

An event outside the caller's set SHALL be indistinguishable from an event that does not exist.
Requesting one by id SHALL produce the same response as requesting a fabricated id, so the API
cannot be used to discover which events exist or how many there are.

This rule governs every admin surface without exception — event lists and detail, guest lists and
guest detail, invitations, dashboard counts and trends, message logs and retries, sends and
broadcasts, reminder schedules, CSV and XLSX exports, QR generation, card design upload and
publication, and import.

#### Scenario: Listing events
- **WHEN** a Host lists events while the system holds twelve, three of which they own
- **THEN** exactly those three are returned and no count or hint of the other nine appears

#### Scenario: Reaching a foreign event by id
- **WHEN** a Host requests an event they do not own, by its real id
- **THEN** the response is identical to the response for an id that does not exist

#### Scenario: Reaching a foreign guest by id
- **WHEN** a Host requests a guest, invitation, message or card design belonging to an event they do not own
- **THEN** the request is refused and the response reveals nothing about the record's existence

#### Scenario: Counts are scoped
- **WHEN** a Host opens the dashboard
- **THEN** every figure shown is computed from their own events only, and the aggregate row totals only those

#### Scenario: Exports are scoped
- **WHEN** a Host exports guests without naming an event
- **THEN** the file contains guests from their own events only

#### Scenario: Sends are scoped
- **WHEN** a Host addresses a send or a broadcast at an audience
- **THEN** only guests of events they own can be in that audience, and naming another event's id does not widen it

#### Scenario: Super admin sees everything
- **WHEN** a Super Admin performs any of the above
- **THEN** every event in the system is in scope

#### Scenario: Scope survives the interface
- **WHEN** any scoped endpoint is called directly with hand-written parameters
- **THEN** the same scope applies, because it is enforced where the records are selected

### Requirement: Hosts delete only their own (P0)
A Host SHALL be able to delete an event they own, and guests belonging to events they own, with
the same confirmation the deletion already requires. A Host SHALL NOT be able to delete an event
or a guest outside their visible set, and the refusal SHALL disclose nothing about the target. A
Super Admin SHALL be able to delete any event and any guest.

#### Scenario: Host deletes their own event
- **WHEN** a Host deletes an event they own and confirms
- **THEN** the event, its guests, invitations and RSVPs are removed as they would be for a Super Admin

#### Scenario: Host attempts a foreign event
- **WHEN** a Host issues a delete for an event they do not own
- **THEN** nothing is deleted and the response is the same as for a non-existent event

#### Scenario: Host attempts a foreign guest
- **WHEN** a Host issues a delete for a guest under another owner's event
- **THEN** nothing is deleted and the response discloses nothing

#### Scenario: Delete impact is scoped too
- **WHEN** a Host asks what a deletion would destroy for an event they do not own
- **THEN** the request is refused rather than answered with counts

### Requirement: The owner is visible and stable (P0)
Each event SHALL show who owns it wherever events are administered, and an event SHALL NOT be
left without an owner. Ownership SHALL change only by a Super Admin's deliberate transfer;
editing an event's other details SHALL never change its owner, and a Host SHALL NOT be able to
change ownership of anything, including events they own.

#### Scenario: Owner shown
- **WHEN** a Super Admin views the event list
- **THEN** each event names its owner

#### Scenario: Editing does not reassign
- **WHEN** a Super Admin edits the date and venue of an event owned by a Host
- **THEN** the owner is unchanged

#### Scenario: Host cannot hand an event away
- **WHEN** a Host attempts to change the owner of an event they own
- **THEN** the attempt is refused

#### Scenario: Events created before ownership existed
- **WHEN** events that predate ownership are read after the change is deployed
- **THEN** each has an owner and none is unreachable