Files
teatea-pension/.trellis/tasks/archive/2026-07/07-02-care-execution-workspace/design.md

3.6 KiB

Care Execution Workspace Design

Summary

Replace the reserved /care module page with a real operational workspace backed by persisted care execution records. This task owns daily care execution only: task list, status movement, completion notes, and seeded examples.

Route Boundary

  • Unscoped route: app/(app)/app/care/page.tsx
  • Scoped route: app/(app)/app/[organizationSlug]/care/page.tsx
  • Navigation item remains in the 运营 group.
  • Permission should move from elder:update to explicit care permissions:
    • care:read
    • care:manage

The unscoped page should:

  1. Load getCurrentAuthContext().
  2. Redirect unauthenticated users to /login.
  3. Redirect users without care:read to the workspace dashboard.
  4. Require an active organization.
  5. Load care data through a focused server helper.
  6. Render a client workspace with canManage based on care:manage.

Data Model

Add one MVP table: care_tasks.

  • id
  • organizationId
  • elderId nullable, because some tasks can be room/public-area checks later
  • title
  • careType: daily_care | meal | medication | rehab | inspection | cleaning | other
  • priority: low | normal | high | urgent
  • status: pending | in_progress | completed | cancelled
  • scheduledAt
  • assigneeLabel
  • executionNotes
  • completedAt
  • createdByAccountId
  • completedByAccountId
  • createdAt
  • updatedAt

Indexes:

  • (organizationId, status, priority) for queues.
  • (organizationId, scheduledAt) for daily schedule ordering.

Server Helpers

Create modules/care/:

  • modules/care/types.ts
    • enum values, labels, DTOs, validators.
  • modules/care/server/operations.ts
    • listCareExecutionData(organizationId: string)
    • updateCareTaskStatus(input)
  • modules/care/components/CareWorkspaceClient.tsx
    • dense tabs/filters/table and status action dialogs.

Reads should batch the care tasks and elder names in one query shape. Mutations must filter by organizationId and update by task ID plus organization ID.

API Design

  • GET /api/care/tasks
    • permission: care:read
    • response: { success: true; reason: string; data: CareExecutionData }
  • PATCH /api/care/tasks/[id]
    • permission: care:manage
    • request: { status: "pending" | "in_progress" | "completed" | "cancelled"; executionNotes?: string }
    • completion sets completedAt and completedByAccountId
    • moving out of completed clears completion metadata
    • records audit log

All failures use { success: false; reason: string }.

UI Design

The care workspace should be operational and compact:

  • Metrics: pending, in-progress, completed today, high/urgent.
  • Filters: status, priority, care type, search by elder/title/assignee.
  • Table columns: task, elder, type, priority, status, scheduled time, assignee, completed time, actions.
  • Actions:
    • pending -> start
    • in-progress/pending -> complete with notes
    • completed/cancelled are visible but not primary work queue items
  • Users without care:manage can view but action buttons are disabled or hidden.

Default Workspace Data

Extend seedDefaultWorkspaceData() with care tasks after seeded elders exist. Examples should cover:

  • pending morning care
  • in-progress rehabilitation or inspection
  • completed meal/medication task
  • urgent/high overdue-style task scheduled in the past

Compatibility And Rollback

  • Existing /app/care placeholder is replaced only for this module.
  • New tables are additive; rollback is dropping generated care migration and removing modules/care, care API routes, and route/page changes.
  • Dashboard integration remains out of scope until the dedicated dashboard task.