teatea-pension/.trellis/tasks/07-02-operations-module-roadmap/design.md

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.