teatea-pension/.trellis/tasks/archive/2026-07/07-02-operations-module-roadmap/prd.md

运营模块完善总计划

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.