# 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.