# Build collaboration modules

## Goal

Replace the four reserved "协同" navigation pages with real persisted business modules for 设备运维, 公告通知, 规则预警, and 家属服务 so the local养老机构工作台 can exercise end-to-end CRUD workflows backed by Drizzle/Postgres data.

## Confirmed Facts

- The current navigation already exposes `/devices`, `/notices`, `/alerts`, and `/family`.
- These routes currently render `ReservedModulePages`, and the frontend spec requires reserved modules not to fabricate operational data.
- The stack uses Next.js App Router, React client components, project-owned Kumo UI adapters, Drizzle/Postgres, route handlers under `app/api`, and permission gates through `requirePermission`.
- Existing seed data is organization-scoped and idempotent for already-initialized workspaces.

## Requirements

- Add real schema, migrations, server operations, API routes, UI pages, permissions, and seed data for all four collaboration modules.
- Implement complete CRUD for each module's core records, plus the key status transitions needed for daily operations.
- Keep all records organization-scoped and prevent cross-organization reads or mutations.
- Add audit logs for create, update, delete, and status transition mutations.
- Replace reserved pages for both unscoped and organization-scoped app routes.
- Keep UI consistent with existing workspaces: server page loads initial data, client workspace handles filters, tables, dialogs, and mutations.
- Preserve TypeScript strictness and avoid new external dependencies.

## Module Scope

- 设备运维: equipment/device assets and maintenance tickets.
- 公告通知: notices, publish/retract lifecycle, and account read receipts.
- 规则预警: alert rules and triggered alert records. V1 persists and manages rules/triggers but does not implement a background rule engine.
- 家属服务: family contacts, visit appointments, and family feedback. V1 does not add family login or external messaging.

## Acceptance Criteria

- [ ] Four collaboration nav pages render real data-backed workspaces instead of reserved module placeholders.
- [ ] Each module supports list, create, edit, delete, and relevant status transitions through API routes.
- [ ] New data is seeded for local/demo organizations without overwriting existing workspace data.
- [ ] New permissions are registered and assigned to system roles consistently.
- [ ] Mutation API routes require manage permissions, read API routes require read permissions, and cross-organization records cannot be mutated.
- [ ] `pnpm db:generate`, `pnpm type-check`, and `pnpm test` pass.

## Out of Scope

- Family-member authentication, family-facing mobile/client portal, SMS/push delivery, and automatic alert-rule evaluation jobs.