43 lines
2.7 KiB
Markdown
43 lines
2.7 KiB
Markdown
# 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.
|