## MODIFIED Requirements

### Requirement: Overview counts (FR-4.2, FR-4.3, P0)
The overview SHALL show one card per event **visible to the caller**, 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: guest records, total
accepted headcount, overall response rate, computed across the caller's visible events only.

For a Host that is the events they own; for a Super Admin it is every event in the system. A Host
whose aggregate row therefore differs from a Super Admin's is correct, not stale: the figures
SHALL describe the caller's own events and SHALL NOT be presented as system-wide. A Host who owns
no events SHALL be shown an empty state that invites them to create one, and SHALL NOT be shown a
zero that implies the system holds nothing.

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

#### Scenario: Host sees only their own cards
- **WHEN** a Host with two events opens the overview while the system holds twelve
- **THEN** two cards are shown and the aggregate row totals only those two

#### Scenario: Host with no events
- **WHEN** a Host who owns no events opens the overview
- **THEN** an empty state invites them to create an event, rather than zeroed counts

#### Scenario: Super admin sees the whole system
- **WHEN** a Super Admin opens the overview
- **THEN** every event has a card and the aggregate row totals all of them

## ADDED Requirements

### Requirement: Navigation matches role, scope and account kind (P1)
Admin navigation SHALL offer only what the signed-in admin may use: the admin-roster screen and
the audit log SHALL be absent for a Host, profile settings SHALL be reachable by every admin, and
every event picker, filter and selector anywhere in the dashboard SHALL list only the caller's
visible events. Hiding a control SHALL never be the only thing standing between a Host and a
forbidden action — the API refuses it independently — so a stale interface is a cosmetic fault
rather than a security one.

An admin confined by a temporary password SHALL be shown the password-change screen instead of
the dashboard, with navigation reduced to that screen and signing out, so the interface does not
offer routes the API will refuse.

#### Scenario: Host's navigation
- **WHEN** a Host signs in
- **THEN** the admin roster and audit log are not offered

#### Scenario: Profile is always reachable
- **WHEN** any admin signs in
- **THEN** profile settings are offered in navigation

#### Scenario: Event pickers are scoped
- **WHEN** a Host opens any screen offering a choice of event
- **THEN** only events they own are listed

#### Scenario: Confined admin sees only the password screen
- **WHEN** an admin holding a temporary password signs in
- **THEN** the password-change screen is shown, and navigation offers nothing but it and signing out

#### Scenario: Hidden is not enforced
- **WHEN** a Host calls an endpoint whose control the interface hid
- **THEN** the API refuses it on its own authority