feat: add health data management workspace

.trellis/tasks/07-02-operations-module-roadmap/prd.md

@@ -0,0 +1,106 @@
+# 运营模块完善总计划
+
+## Goal
+
+Turn the six operation-side sidebar entries into a coherent persisted operating system for the pension workspace:
+
+1. 运营看板
+2. 老人档案
+3. 床位房间
+4. 健康照护
+5. 护理服务
+6. 安全应急
+
+The work should be delivered as separate, independently verifiable child tasks, then integrated back into the dashboard. This parent task owns scope, ordering, and cross-module acceptance criteria. Implementation should happen in child tasks.
+
+## Confirmed Facts
+
+- `运营看板` already renders real Drizzle-backed elders, beds, admissions, and incidents data.
+- `老人档案` already supports real persisted elder CRUD.
+- `床位房间` already has a real bed/admission workspace backed by rooms, beds, elders, and admissions.
+- `健康照护`, `护理服务`, and `安全应急` currently render placeholders or are not complete operational modules.
+- The current Drizzle schema has core operational tables but no dedicated health or care-service tables yet.
+- `systemIncidents` already provides a useful base for safety/emergency event state flow.
+- Static module pages must not fabricate operational data before a real persisted source exists.
+- The user wants all of these operation modules planned and completed, not only the currently selected sidebar item.
+
+## Task Map
+
+### Child 1: 新增健康照护后台管理页
+
+- Path: `.trellis/tasks/07-02-care-service-workspace`
+- Note: The slug is historical, but the task title and artifacts now describe the health data management page.
+- Scope: Add backend management page for health profiles, vital signs, chronic conditions, and abnormal reviews.
+- Dependency: None. This can be implemented first because it creates the health data foundation.
+
+### Child 2: 护理服务执行工作台
+
+- Path: `.trellis/tasks/07-02-care-execution-workspace`
+- Scope: Add care task/service execution records, status flow, completion notes, and seeded examples.
+- Dependency: Can use existing elder/admission data. Does not depend on health admin unless a care item links to abnormal health reviews later.
+
+### Child 3: 安全应急事件工作台
+
+- Path: `.trellis/tasks/07-02-emergency-incident-workspace`
+- Scope: Replace the placeholder with an emergency event workspace using and extending persisted incident data.
+- Dependency: Can build on `systemIncidents` and existing incident status actions.
+
+### Child 4: 老人床位联动优化
+
+- Path: `.trellis/tasks/07-02-elder-bed-context-optimization`
+- Scope: Improve elder and bed screens so operators can see linked health, care, admission, and incident context where available.
+- Dependency: Should run after health/care/emergency have at least basic persisted data.
+
+### Child 5: 运营看板整合优化
+
+- Path: `.trellis/tasks/07-02-operations-dashboard-integration`
+- Scope: Integrate health, care, emergency, elder, bed, and admission summaries into the dashboard.
+- Dependency: Should run after the relevant child data surfaces exist.
+
+## Delivery Order
+
+1. Health data management page.
+2. Care execution workspace.
+3. Emergency event workspace.
+4. Elder/bed cross-module context improvements.
+5. Dashboard integration.
+
+This order creates data foundations first, then links records to existing operator workflows, then summarizes everything in the dashboard.
+
+## Cross-Module Requirements
+
+- All new operational records must be Drizzle/PostgreSQL backed.
+- New data must be scoped by active organization.
+- New data tied to elders must reference real elders in the same organization.
+- Default workspace seed data must create real persisted rows, not UI-only demo objects.
+- All API responses must follow `{ success, reason, ... }`.
+- Permission checks must happen on the server.
+- Mutations must record audit logs.
+- Navigation labels should remain clear:
+  - `健康照护` remains the operational health entry.
+  - backend health management can live under `管理系统` as `健康数据管理`.
+  - `护理服务` remains daily service execution.
+  - `安全应急` remains event response and closure.
+- The app must not show hero/marketing-style module introductions for operational pages.
+
+## Acceptance Criteria
+
+- [ ] Each child task has its own PRD and implementation scope.
+- [ ] Health, care, and emergency modules no longer rely on fabricated UI-only data.
+- [ ] Existing elder and bed workflows remain functional after new modules are added.
+- [ ] Default workspace seed data covers elders, beds, health, care, and incidents once all child tasks are complete.
+- [ ] Dashboard metrics include the new persisted health/care/emergency data after integration.
+- [ ] `pnpm lint` passes for each implementation child.
+- [ ] `pnpm type-check` passes for each implementation child.
+- [ ] `pnpm build` passes before the parent task is considered complete.
+
+## Out Of Scope
+
+- Doing all child tasks in a single implementation pass.
+- Replacing Route Handlers with oRPC.
+- Replacing current auth/session implementation.
+- Billing, family app notifications, device telemetry integrations, and AI recommendations unless created as separate future tasks.
+
+## Open Questions
+
+- None blocking the plan. Implementation should start with Child 1 unless the user explicitly changes priority.