# Operations Module Roadmap Design

## Boundary

This parent task is a coordination artifact. It should not directly implement schema, API, or UI changes unless a later requirement explicitly adds parent-level integration work.

Implementation belongs to child tasks:

- `07-02-care-service-workspace`: health data management page.
- `07-02-care-execution-workspace`: care execution workspace.
- `07-02-emergency-incident-workspace`: emergency event workspace.
- `07-02-elder-bed-context-optimization`: cross-module context on elder and bed workflows.
- `07-02-operations-dashboard-integration`: final dashboard summaries.

## Dependency Shape

The modules should be delivered in foundation-to-summary order:

1. Health data management creates health records.
2. Care execution creates care task/service records.
3. Emergency workspace operationalizes incident records.
4. Elder/bed context reads the new health/care/emergency records.
5. Dashboard integration summarizes all persisted data.

## Shared Technical Contracts

- Drizzle schema remains the persistence source of truth.
- New tables are additive migrations.
- Organization scoping is mandatory.
- Elder-linked records validate same-organization ownership.
- API responses use `{ success, reason, ... }`.
- Route handlers call `requirePermission`.
- Mutations record audit logs.
- Default workspace data creates real rows, not UI-only fixtures.

## UI Contract

- Operational pages should use dense work-focused layouts.
- Backend management pages belong under `管理系统`.
- Existing `/app/health` remains separate from backend `健康数据管理`.
- `护理服务` is daily execution work, not health data management.
- `安全应急` is event triage and closure.
- `运营看板` summarizes and routes; it is not a CRUD surface.

## Rollback

Rollback should happen per child task. Parent rollback means unlinking or archiving the roadmap task; child migrations and source changes must be reverted in their own rollback plans.