# Emergency Incident Workspace Design

## Summary

Replace `/app/emergency` with a real safety/emergency incident workspace using the existing `systemIncidents` Drizzle table. The MVP covers manual event creation, status triage, filters, and metrics.

## Route Boundary

- Unscoped route: `app/(app)/app/emergency/page.tsx`
- Scoped route: `app/(app)/app/[organizationSlug]/emergency/page.tsx`
- Navigation remains under `运营`.
- Permissions:
  - read: `incident:read`
  - mutate: `incident:manage`

Server Component behavior:

1. Load `getCurrentAuthContext()`.
2. Redirect unauthenticated users to `/login`.
3. Redirect users without `incident:read` to dashboard.
4. Require active organization.
5. Load incidents through `listEmergencyIncidentData(organizationId)`.
6. Render client workspace with `canManage`.

## Data Model

Use existing `system_incidents`:

- `organizationId`
- `severity`: `info | warning | critical`
- `status`: `open | acknowledged | resolved | closed`
- `title`
- `description`
- `source`
- acknowledgement / resolution account and time fields

No schema change is required for MVP. Elder/bed linking stays future work for the context optimization task.

## Server Helpers

Create `modules/emergency/`:

- `modules/emergency/types.ts`
  - labels, DTOs, create/status validators.
- `modules/emergency/server/operations.ts`
  - `listEmergencyIncidentData(organizationId: string)`
  - `createEmergencyIncident(input)`
  - `updateEmergencyIncidentStatus(input)`
- `modules/emergency/components/EmergencyWorkspaceClient.tsx`
  - metrics, filters, event table, create dialog, status actions.

## API Design

- `GET /api/emergency/incidents`
  - permission: `incident:read`
  - response: `{ success: true; reason: string; data }`
- `POST /api/emergency/incidents`
  - permission: `incident:manage`
  - request: `{ severity; title; description; source }`
  - creates an organization-scoped incident
- `PATCH /api/emergency/incidents/[id]`
  - permission: `incident:manage`
  - request: `{ status }`
  - updates only rows in the active organization

All create/update mutations write audit logs after successful persistence.

## UI Design

- Metrics: open, acknowledged, critical, resolved/closed today.
- Filters: status, severity, search by title/source/description.
- Dense table columns: event, severity, status, source, created time, updated time, actions.
- Actions: acknowledge, resolve, close.
- Manual creation dialog for authorized operators.
- Read-only users can see rows but not mutation controls.

## Compatibility

- Existing `/api/system/incidents/[id]` stays for system status settings.
- The emergency workspace uses dedicated `/api/emergency/...` routes so tests and UI contracts are local to the operational module.
