# Top Bar Integration

## Purpose

`TopBar` renders app-shell search, campus/role badges, notifications, and the profile menu (which delegates sign-out to the auth session) through the three-layer frontend architecture.

```text
View -> Business Logic -> API/Data Access -> Backend
```

TopBar does not own product content records. It owns shell UI state and delegates auth actions to the auth session.

## Frontend Layers

View:

- `frontend/src/components/frameworks/TopBar.tsx`
- `frontend/src/components/top-bar/TopBarView.tsx`
- `frontend/src/components/top-bar/TopBarSearch.tsx`
- `frontend/src/components/top-bar/TopBarBadges.tsx`
- `frontend/src/components/top-bar/TopBarNotifications.tsx`
- `frontend/src/components/top-bar/TopBarProfileMenu.tsx`

Business logic:

- `frontend/src/business/top-bar/hooks.ts`
- `frontend/src/business/top-bar/selectors.ts`
- `frontend/src/business/top-bar/types.ts`

Shared config:

- `frontend/src/shared/constants/topBar.ts`

## Behavior

- `TopBar.tsx` is a thin wrapper that reads auth session state and passes it into `useTopBarPage`.
- `useTopBarPage` owns profile menu state, notifications menu state, search query state, and sign-out error state.
- Selectors handle initials, campus label fallback, shared role labels, and unread notification count.
- View components receive a prepared page model and do not call API/data access modules.
- Profile and settings menu items are explicitly disabled until product workflows exist, instead of rendering silent no-op buttons.

## Data Ownership Rules

- Do not add notification seed data to frontend constants.
- Keep TopBar constants limited to role badge classes and static menu labels.
- Future persisted notifications should use a backend API and a dedicated business hook.
