feat: build collaboration workspaces

.trellis/tasks/07-03-collaboration-modules/design.md

@@ -0,0 +1,50 @@
+# Design
+
+## Architecture
+
+Add four module slices following existing patterns:
+
+- `modules/devices`, `modules/notices`, `modules/alerts`, and `modules/family`
+- each module owns `types.ts`, `server/operations.ts`, and a client workspace component
+- route handlers under `app/api/<module>` validate permissions, input, organization context, and audit mutations
+- app route pages remain Server Components and pass initial data plus `canManage` into client components
+
+## Data Model
+
+Add Postgres enums and tables to `modules/core/server/schema.ts`:
+
+- devices: asset status, ticket status, ticket priority; device assets and maintenance tickets
+- notices: notice status; notices and notice read receipts
+- alerts: rule type/status, trigger status; alert rules and alert triggers
+- family: relation/status, visit status, feedback status/type; family contacts, visit appointments, feedback records
+
+All business tables include `organizationId`, timestamps, and indexes for list/status lookups. FK references use cascade for organization-owned children and set-null where historical records should survive related record deletion.
+
+## Permissions
+
+Extend `Permission` and seeded permission definitions:
+
+- `device:read`, `device:manage`
+- `notice:read`, `notice:manage`
+- `alert:read`, `alert:manage`
+- `family:read`, `family:manage`
+
+`org_admin` and `manager` receive read/manage for all four modules. `viewer` receives read permissions. `caregiver` receives read permissions for devices, alerts, and family plus existing care/health/facility access.
+
+## UI Flow
+
+Each workspace should provide:
+
+- metric cards for key counts
+- search and status/type filters
+- tables with stable widths and empty states
+- dialogs for create/edit/delete confirmation or status updates
+- optimistic local refresh by refetching the module API after successful mutations
+
+## Compatibility
+
+Generate a Drizzle migration from schema changes. Existing installations need to run migrations before using the pages. Existing reserved-page component can remain for future modules but must no longer be used by these four routes.
+
+## Rollback
+
+The rollback point is the generated migration plus module files. If implementation gets too large, keep schema and API for all modules but reduce UI duplication by sharing small local helper components only where it does not obscure module boundaries.