## Purpose

The host's control panel: live per-event and aggregate counts, the guest table with filters and detail timeline, event content editing with live preview, settings, and dashboard usability on a phone.

## ADDED Requirements

### Requirement: Overview counts (FR-4.2, FR-4.3, P0)
The overview SHALL show three event cards, each with Invited / Accepted (total headcount incl. plus-ones) / Declined / Pending / Cancelled, a response-rate progress bar, and a days-to-event countdown — plus an aggregate row: unique guests, total accepted headcount across events, overall response rate.

#### Scenario: Counts reflect state
- **WHEN** an event has 100 invitations: 60 accepted (headcount 90), 10 declined, 5 cancelled, 25 pending
- **THEN** the event card shows those numbers and a 75% response rate

#### Scenario: Cancellation reflected immediately
- **WHEN** a guest cancels
- **THEN** the next dashboard read shows the decremented headcount

### Requirement: Charts (FR-4.4, P1)
The dashboard SHALL show a response trend chart (accepts per day) and a channel breakdown of which channel produced responses.

#### Scenario: Trend data
- **WHEN** accepts occurred across several days
- **THEN** the trend chart plots accepts per day for the selected range

### Requirement: Guest table (FR-4.5, FR-4.6, P0)
The guest table SHALL support search and filters by event, status, side (bride/groom), group tag, channel, and date range, with inline per-guest actions: view detail, edit, resend invitation, mark accepted/declined manually (for phone RSVPs), delete (role-permitting). Tables paginate at 50/page and load in <1.5s with 1,500 guests (§7.5).

#### Scenario: Filter combination
- **WHEN** the admin filters status=pending AND event=Marriage AND tag=family
- **THEN** only guests matching all filters are listed

#### Scenario: Manual RSVP for elderly guest
- **WHEN** the admin marks a guest accepted with party size 3 on their behalf
- **THEN** the invitation becomes accepted, headcount updates, and the history records actor=admin

### Requirement: Guest detail timeline (FR-4.7, P1)
A guest detail drawer SHALL show the full timeline — invited → opened → accepted → reminders sent → cancelled — with timestamps and channels.

#### Scenario: Timeline view
- **WHEN** the admin opens a guest who accepted then received two reminders
- **THEN** each event appears in order with its timestamp and channel

### Requirement: Content editor with live preview (FR-4.12, P1)
Per event, admins SHALL edit titles, date/time, venue, map link, cover image, gallery images, theme selection, and Bangla/English text — with a live phone-frame preview of the invitation page.

#### Scenario: Edit and preview
- **WHEN** the admin changes the venue text
- **THEN** the phone-frame preview updates to show the new venue before saving

#### Scenario: Date change re-plans reminders
- **WHEN** the admin edits `starts_at` after invitations were sent
- **THEN** all future reminder jobs are re-planned to the new date and a "date changed" broadcast is offered (§12 risk 10)

### Requirement: Settings (FR-4.14, P0)
A settings area SHALL manage gateway credentials, sender IDs, wedding details, admin users, and rate limits — restricted per the role matrix. Secrets are write-only in the UI (never redisplayed in full) and never stored in plaintext in the database (§7.6).

#### Scenario: Co-host opens gateway settings
- **WHEN** a Co-host navigates to gateway settings
- **THEN** access is denied

### Requirement: Live refresh (FR-4.15, P1)
Dashboard counts SHALL refresh automatically (polling ≤30s or server push) without a manual reload.

#### Scenario: Background update
- **WHEN** an RSVP arrives while the dashboard is open
- **THEN** counts update within 30 seconds

### Requirement: Mobile dashboard (FR-4.16, P1)
The dashboard SHALL be usable on a phone.

#### Scenario: Phone viewport
- **WHEN** the dashboard is used at mobile width
- **THEN** overview, guest table, and send actions are all operable

### Requirement: Capacity warning (FR-4.17, P2)
When an event's accepted headcount exceeds its configured `capacity`, the dashboard SHALL show a warning banner.

#### Scenario: Over capacity
- **WHEN** accepted headcount is 520 and capacity is 500
- **THEN** a capacity warning banner appears on that event's card