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.

2.7 KiB Raw Permalink Blame History