chore(task): archive 07-02-operations-module-roadmap
This commit is contained in:
@@ -0,0 +1 @@
|
||||
{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python3 .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}
|
||||
@@ -0,0 +1,47 @@
|
||||
# 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.
|
||||
@@ -0,0 +1 @@
|
||||
{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python3 .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}
|
||||
@@ -0,0 +1,42 @@
|
||||
# Implementation Plan
|
||||
|
||||
## Execution Order
|
||||
|
||||
1. Start and implement `07-02-care-service-workspace` (`新增健康照护后台管理页`).
|
||||
2. Start and implement `07-02-care-execution-workspace` (`护理服务执行工作台`).
|
||||
3. Start and implement `07-02-emergency-incident-workspace` (`安全应急事件工作台`).
|
||||
4. Start and implement `07-02-elder-bed-context-optimization` (`老人床位联动优化`).
|
||||
5. Start and implement `07-02-operations-dashboard-integration` (`运营看板整合优化`).
|
||||
6. Review parent acceptance criteria after all children are complete.
|
||||
|
||||
## Per-Child Gate
|
||||
|
||||
Before starting each child:
|
||||
|
||||
- Read its `prd.md`.
|
||||
- For complex children, add or refresh `design.md` and `implement.md`.
|
||||
- Load `trellis-before-dev` and relevant backend/frontend/shared specs.
|
||||
|
||||
Before finishing each child:
|
||||
|
||||
- Run `pnpm lint`.
|
||||
- Run `pnpm type-check`.
|
||||
- Run `pnpm build`.
|
||||
- Run `pnpm db:generate` and review SQL when schema changes are made.
|
||||
- Confirm default workspace seed data is real persisted data when seed examples are added.
|
||||
|
||||
## Parent Completion Gate
|
||||
|
||||
The parent task is complete only after:
|
||||
|
||||
- Each child task is completed or explicitly moved out of scope by the user.
|
||||
- The dashboard reflects completed module data.
|
||||
- Existing elder, bed, admission, auth, settings, and audit workflows still pass validation.
|
||||
- Final `pnpm lint`, `pnpm type-check`, and `pnpm build` pass.
|
||||
|
||||
## Risk Notes
|
||||
|
||||
- Schema migrations across multiple children can conflict if implemented out of order.
|
||||
- Default seed file already has active edits; every child that touches it must read it before editing.
|
||||
- Permission additions must keep role seeding idempotent.
|
||||
- Dashboard integration should not start before the data sources exist.
|
||||
@@ -0,0 +1,106 @@
|
||||
# 运营模块完善总计划
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"id": "operations-module-roadmap",
|
||||
"name": "operations-module-roadmap",
|
||||
"title": "运营模块完善总计划",
|
||||
"description": "",
|
||||
"status": "completed",
|
||||
"dev_type": null,
|
||||
"scope": null,
|
||||
"package": null,
|
||||
"priority": "P2",
|
||||
"creator": "TalexDreamSoul",
|
||||
"assignee": "TalexDreamSoul",
|
||||
"createdAt": "2026-07-02",
|
||||
"completedAt": "2026-07-03",
|
||||
"branch": null,
|
||||
"base_branch": "main",
|
||||
"worktree_path": null,
|
||||
"commit": null,
|
||||
"pr_url": null,
|
||||
"subtasks": [],
|
||||
"children": [
|
||||
"07-02-care-service-workspace",
|
||||
"07-02-emergency-incident-workspace",
|
||||
"07-02-elder-bed-context-optimization",
|
||||
"07-02-care-execution-workspace",
|
||||
"07-02-operations-dashboard-integration"
|
||||
],
|
||||
"parent": null,
|
||||
"relatedFiles": [],
|
||||
"notes": "",
|
||||
"meta": {}
|
||||
}
|
||||
Reference in New Issue
Block a user