## 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: Event overview grid (P1)
The events screen SHALL present every event as a tile in a grid rather than as a stack of
full-width panels. The grid SHALL show three tiles per row on wide viewports and SHALL reduce
the number of tiles per row on narrower ones so no tile is clipped or horizontally scrolled.

#### Scenario: Several events on a wide viewport
- **WHEN** an admin with six events opens the events screen on a desktop-width viewport
- **THEN** the events are laid out three per row, in two rows

#### Scenario: Narrow viewport
- **WHEN** the same screen is opened on a phone-width viewport
- **THEN** the tiles stack to a single column, each fully readable without horizontal scrolling

#### Scenario: No events yet
- **WHEN** an admin with no events opens the screen
- **THEN** an empty state invites them to create one, and the Create event control remains available

### Requirement: Event tile is a read-only summary (P1)
Each tile SHALL display, as text rather than as form controls, every detail the event settings
form holds: the event name, its ceremony type, its start date and time in `Asia/Dhaka`, its
venue, its capacity, whether it is published, and its public address. Each tile SHALL also
state whether the event has a published invitation card. A tile SHALL NOT accept edits.

#### Scenario: Tile contents
- **WHEN** an admin views a tile for a published Walima on 25 Sept 2026 at Hotel Intercontinental with capacity 1000
- **THEN** the tile shows the name, the ceremony type, that date and time, the venue, the capacity, a published indicator and the `/e/{slug}` address

#### Scenario: Capacity not limited
- **WHEN** an event's capacity is unset or zero
- **THEN** the tile states that there is no limit rather than showing "0"

#### Scenario: Draft event
- **WHEN** an event is not published
- **THEN** the tile marks it as a draft, distinguishably from a published event

#### Scenario: Card design state
- **WHEN** an event has no published card design
- **THEN** the tile says so, so an admin can see at a glance which events are not ready for guests

#### Scenario: No editing from the tile
- **WHEN** an admin attempts to change a value shown on a tile
- **THEN** there is no control to do so; editing is reached only through the tile's Edit action

### Requirement: Event editor modal (P1)
Each tile SHALL carry an Edit control that opens a modal editor for that event. The modal SHALL
contain both the event's settings and its card design, SHALL offer a Save action, a Close
action and a distinct close (✕) control, and SHALL identify which event it is editing.

#### Scenario: Opening the editor
- **WHEN** an admin presses Edit on an event's tile
- **THEN** a modal opens naming that event and showing its settings and its card design together

#### Scenario: Saving settings
- **WHEN** an admin changes the date, venue, capacity or published state in the modal and presses Save
- **THEN** the change is submitted, the outcome is reported in the modal, and the tile behind it reflects the new values

#### Scenario: Closing without saving
- **WHEN** an admin has unsaved settings edits and presses Close, the ✕ control, Escape, or clicks outside the modal
- **THEN** the system asks them to confirm before discarding, and the edits survive if they decline

#### Scenario: Closing with nothing changed
- **WHEN** an admin opens the editor, changes nothing, and closes it by any means
- **THEN** it closes immediately with no confirmation

#### Scenario: Card design acts immediately
- **WHEN** an admin uploads, publishes or deletes a card design inside the modal
- **THEN** that action takes effect when pressed and does not wait for Save
- **AND** Save applies only to the settings fields

#### Scenario: Read-only role
- **WHEN** an admin without the content-editing permission views the events screen
- **THEN** editing controls are not offered, and the API refuses the underlying requests on its own authority regardless of what the screen shows

### Requirement: Consequential edits keep their warnings in the modal (P1)
The consequences the settings form reports today SHALL be preserved when that form moves into
the modal: moving an event's date SHALL warn before saving and report what it did to queued
reminders afterwards, SHALL offer to announce the change to accepted guests, and a date or
venue edit on an event with a published card SHALL warn that the printed card still states the
old details.

#### Scenario: Date change warning
- **WHEN** an admin edits the start date in the modal but has not yet saved
- **THEN** the modal warns that saving moves every queued reminder for this event and drops waves the new date puts in the past

#### Scenario: Date change outcome
- **WHEN** the date change is saved
- **THEN** the modal reports how many reminders were rescheduled, cancelled and created

#### Scenario: Announcing to guests
- **WHEN** a saved date change affects guests who already accepted
- **THEN** the modal offers a separate, explicit action to email them, and does not send anything without it

#### Scenario: Published card goes stale
- **WHEN** an admin edits the date or venue of an event that has a published invitation card
- **THEN** the modal warns that the card artwork still carries the old details and must be re-made and re-published

### Requirement: Deleting an event from the editor (P1)
The delete action for an event SHALL live inside the event editor modal rather than on its
tile, and SHALL keep the confirmation that states how many guest records and responses will be
destroyed.

#### Scenario: Delete is not on the tile
- **WHEN** an admin views the events grid
- **THEN** no tile offers a delete control

#### Scenario: Deleting from the modal
- **WHEN** an admin opens an event's editor and chooses to delete it
- **THEN** a confirmation states the number of guest records and responses that will be destroyed, and deletion proceeds only on confirmation

#### Scenario: After deletion
- **WHEN** an event is deleted
- **THEN** the modal closes and the grid no longer shows that event

### Requirement: Reaching an event's guests (P1)
Both the event tile and the event editor modal SHALL carry a Guests control that takes the
admin to the guest-management screen showing only that event's guests.

#### Scenario: From the tile
- **WHEN** an admin presses Guests on an event's tile
- **THEN** they arrive at the guest-management screen listing only that event's guests, with that event shown as the active filter

#### Scenario: From the modal
- **WHEN** an admin presses Guests inside the event editor modal
- **THEN** they arrive at the same screen, filtered to the same event

#### Scenario: Adding a guest after arriving
- **WHEN** an admin arrives at the guest screen through an event's Guests control
- **THEN** the add-guest action is available, and a guest added there belongs to that event

### Requirement: Per-event invitation messages (P1)
The Create event form and the event editor modal SHALL each offer two invitation message
fields — one for guests invited singly and one for guests invited with their family — in
English. Each field SHALL open showing the wording a guest would otherwise see, as editable
text rather than as a hint, and SHALL be limited to the same 100 characters as the
wedding-wide messages.

A message stored on an event SHALL apply to that event only. A field left at the wording it
inherited SHALL NOT store an override, so the event continues to follow the wedding-wide
setting if that setting later changes.

#### Scenario: Defaults are visible and editable
- **WHEN** an admin opens the Create event form or an event's editor
- **THEN** the single field reads "You are cordially invited" and the family field reads "You and your family are cordially invited", unless the wedding-wide panel sets different wording, in which case those are shown
- **AND** both are editable in place

#### Scenario: Overriding for one event
- **WHEN** an admin edits an event's family message and saves
- **THEN** guests invited with their family to that event read the new wording
- **AND** guests of every other event are unaffected

#### Scenario: Leaving the defaults alone
- **WHEN** an admin saves an event without altering either message field
- **THEN** no override is stored for that event
- **AND** a later change to the wedding-wide wording reaches that event's guests

#### Scenario: Clearing an override
- **WHEN** an admin empties a message field on an event that had an override and saves
- **THEN** the override is removed and the event falls back to the wedding-wide wording

#### Scenario: Over the limit
- **WHEN** an admin types a message longer than 100 characters
- **THEN** the form shows the overage as they type and the system refuses to save it, stating the limit and why it exists

#### Scenario: Markup pasted in
- **WHEN** a message is pasted carrying markup from a word processor
- **THEN** the markup is stripped and the remaining text is stored, measured against the limit after cleaning

#### Scenario: Bangla is not per-event
- **WHEN** an admin opens an event's messages
- **THEN** only the English fields are offered, and Bangla greetings continue to come from the wedding-wide setting or the built-in default

## REMOVED Requirements

### Requirement: Inline per-event guest list
**Reason**: The events screen embedded a capped, unfiltered, unpaginated list of an event's
guests behind a tab on each event panel. It duplicated the guest-management screen while
offering none of its search, filters, pagination, guest detail, export or QR generation, and
it is the single largest obstacle to fitting an event into a one-third-width tile.

**Migration**: The Guests control on the tile and in the editor modal navigates to the
guest-management screen pre-filtered to that event. Adding a guest to a specific event is
still supported there — the destination event comes from the active filter, so a guest still
cannot be added without naming the event that will own them.

### Requirement: Per-event tab strip
**Reason**: Each event panel carried a Settings / Guests / Card design tab strip, which put
three full editing surfaces inside a list. With the list becoming a grid of summaries, the
tabs have nothing to switch between: settings and card design live together in the editor
modal, and guests are a navigation.

**Migration**: Settings and Card design are sections of the event editor modal, reached by the
tile's Edit control. Guests is a navigation to the guest-management screen.