|
|
@@ -0,0 +1,168 @@
|
|
|
+# MRC Demo MVP Implementation Plan
|
|
|
+
|
|
|
+> **For Codex:** REQUIRED SUB-SKILL: Use `subagent-driven-development` to implement this plan task-by-task. The project owner has explicitly authorized two isolated endpoint lanes to run in parallel; each lane remains serial internally and must pass specification review before quality review.
|
|
|
+
|
|
|
+**Goal:** Deliver the 11 approved MRC core frontend modules as locally runnable, prototype-aligned Demo pages for the mini program and HIS frontend by the next-morning acceptance window.
|
|
|
+
|
|
|
+**Architecture:** The two clients each implement the frozen `mrc-demo-state/v1` V1.1 semantics in a local in-memory Adapter; they never share a service, runtime, file, HTTP request, or state. The mini program adds only a `packageMRC/` subpackage, while HIS adds only `src/pages/mrcDemo/` and its permitted static route registration. The cross-end relationship is semantic parity of the five de-identified scenarios, not live synchronization.
|
|
|
+
|
|
|
+**Tech Stack:** Existing WeChat Mini Program source; existing React 16 / Ant Design HIS frontend; Node offline tests; HTML prototypes and approved OpenSpec changes as the visual and behavioral source of truth.
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## Immutable delivery boundary
|
|
|
+
|
|
|
+- Scope: `MRC-MP-BASE-001`, `MRC-MP-APPLY-001~005`, `MRC-MP-ORDER-001`, `MRC-PC-AUTH-001`, and `MRC-PC-ORDER-001~003` only.
|
|
|
+- Read-only contract: `04-新项目源码_source/项目源码/mrc-demo-platform/contracts/demo-state-v1.md`.
|
|
|
+- Prohibited: old input source changes, `pri-his-front`, `PRHIS-main`, existing-page edits, live identity/record/upload/payment/logistics calls, HTTP/network, persistent storage, cross-end sync, real user data, and production-completion claims.
|
|
|
+- Demo acceptance: visual layout and permitted local interaction align to the approved HTML prototype; prohibited capability is either not rendered or clearly unavailable; every screen carries a visible `Demo 数据` marker.
|
|
|
+- State lifecycle: module status changes only after factual code evidence; final integration to `develop` is serial and controlled by the PM Agent.
|
|
|
+
|
|
|
+## Task 1: Prepare isolated, verified endpoint workspaces
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Modify: `docs/plans/2026-09-15-mrc-demo-mvp-implementation.md` only if an execution fact changes.
|
|
|
+- Use: `.worktrees/codex-mrc-demo-mp-base-001/` and `.worktrees/codex-mrc-demo-pc-auth-001/`.
|
|
|
+
|
|
|
+**Step 1: Rebase the existing clean receipt branches onto current `develop`; do not retain an obsolete base.**
|
|
|
+
|
|
|
+Run: `git -C <worktree> rebase develop`
|
|
|
+
|
|
|
+Expected: branch starts at current Demo governance commit and remains clean.
|
|
|
+
|
|
|
+**Step 2: Verify the project-local worktree directory is ignored.**
|
|
|
+
|
|
|
+Run: `git check-ignore -q .worktrees`
|
|
|
+
|
|
|
+Expected: exit 0.
|
|
|
+
|
|
|
+**Step 3: Run the mini-program baseline checks before any code.**
|
|
|
+
|
|
|
+Run: `cd 04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram && npm test && npm run validate:source`
|
|
|
+
|
|
|
+Expected: all existing offline tests pass and source validation passes.
|
|
|
+
|
|
|
+**Step 4: Record the HIS baseline limitation rather than installing dependencies.**
|
|
|
+
|
|
|
+Run: `git diff --check` from the HIS worktree; inspect the existing `package.json` scripts and confirm no runnable test script is present.
|
|
|
+
|
|
|
+Expected: clean diff; full webpack build remains a documented non-blocking limitation because the existing dependency set lacks `rimraf` and no installation authorization exists.
|
|
|
+
|
|
|
+**Step 5: Commit only if rebase or baseline evidence requires a tracked documentation change.**
|
|
|
+
|
|
|
+## Task 2: Mini-program foundation and local Adapter (`MRC-MP-BASE-001`)
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Create: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/packageMRC/common/mrcDemoState.js`
|
|
|
+- Create: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/packageMRC/pages/entry/index.js`
|
|
|
+- Create: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/packageMRC/pages/entry/index.wxml`
|
|
|
+- Create: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/packageMRC/pages/entry/index.wxss`
|
|
|
+- Modify: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/app.json` (subpackage registration only)
|
|
|
+- Test: `04-新项目源码_source/项目源码/pri-smart-hospital-miniprogram/tests/mrc-demo-state.test.js`
|
|
|
+
|
|
|
+**Step 1: Write failing Node tests for `getSnapshot`, `activateScenario`, `resetScenario`, `createApplication`, and an unsupported transition.**
|
|
|
+
|
|
|
+Run: `node tests/mrc-demo-state.test.js`
|
|
|
+
|
|
|
+Expected: fail because `packageMRC/common/mrcDemoState.js` does not exist.
|
|
|
+
|
|
|
+**Step 2: Implement the smallest local, de-identified in-memory Adapter matching `mrc-demo-state/v1` V1.1.**
|
|
|
+
|
|
|
+**Step 3: Re-run the focused test, then all mini-program offline tests and source validation.**
|
|
|
+
|
|
|
+Run: `node tests/mrc-demo-state.test.js && npm test && npm run validate:source`
|
|
|
+
|
|
|
+Expected: all pass; test code contains no `wx.request`, HTTP URL, storage API, or service import.
|
|
|
+
|
|
|
+**Step 4: Add the MRC entry screen, visible Demo marker, scenario switch/reset, and approved navigation only.**
|
|
|
+
|
|
|
+**Step 5: Commit a focused change and update only factual module evidence.**
|
|
|
+
|
|
|
+## Task 3: Mini-program applicant and progress pages (`MRC-MP-APPLY-001~005`, `MRC-MP-ORDER-001`)
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Create: `packageMRC/pages/applications/*` (entry/list and application detail pages required by the approved prototypes)
|
|
|
+- Create: `packageMRC/pages/identity/*`, `packageMRC/pages/content/*`, `packageMRC/pages/legacy/*`, `packageMRC/pages/confirm/*`, and `packageMRC/pages/progress/*` only where the approved prototype requires a page or modal-equivalent state.
|
|
|
+- Modify: `packageMRC/common/mrcDemoState.js` only for contract operations proven in a failing test.
|
|
|
+- Test: `tests/mrc-demo-state.test.js` plus focused page-state test files named `tests/mrc-demo-<module>.test.js`.
|
|
|
+
|
|
|
+For each module, in this exact order: `APPLY-001` → `APPLY-002` → `APPLY-003` → `APPLY-004` → `APPLY-005` → `ORDER-001`:
|
|
|
+
|
|
|
+1. Read that module’s approved formal review, OpenSpec `tasks.md`, and source HTML prototype; enumerate every visible page, tab, dialog, form state, disabled/not-rendered capability, and navigation edge needed for Demo.
|
|
|
+2. Write one or more focused failing test assertions for the Adapter/state transformation or pure page-data helper introduced by that module. Run the focused test and preserve the expected RED result in the task evidence.
|
|
|
+3. Implement only the prototype-approved screen, data binding, allowed local interaction, error/empty state, and navigation; use de-identified static seed data.
|
|
|
+4. Run the focused test, all mini-program tests, and source validation. Inspect `git diff --check` and verify that changed runtime files are confined to `packageMRC/` plus `app.json` subpackage registration.
|
|
|
+5. Commit the single module change with `feat(demo): implement <module-code>`, then update its status/evidence only after the commit exists.
|
|
|
+
|
|
|
+## Task 4: HIS Demo identity foundation and local Adapter (`MRC-PC-AUTH-001`)
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/demoState.js`
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/DemoShell.jsx`
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/MrcAuthDemo.jsx`
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/mrcDemo.css`
|
|
|
+- Modify: `04-新项目源码_source/项目源码/cloudhis-pr/src/routers/StaticRouterData.js` (MRC route import/registration only)
|
|
|
+- Test: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/demoState.test.js`
|
|
|
+
|
|
|
+**Step 1: Write a Node-runnable failing test for fixed `pc.mrc` identity, scenario activation/reset, legal transition, and rejected illegal transition.**
|
|
|
+
|
|
|
+Run: `node src/pages/mrcDemo/demoState.test.js`
|
|
|
+
|
|
|
+Expected: fail because the Adapter file is absent.
|
|
|
+
|
|
|
+**Step 2: Implement the smallest CommonJS-compatible in-memory Adapter and test it green.**
|
|
|
+
|
|
|
+**Step 3: Implement the prototype-aligned MRC shell and fixed Demo identity page; show `Demo 数据`, scenario selector/reset, and no actual login/logout/network behavior.**
|
|
|
+
|
|
|
+**Step 4: Run focused Node tests, `git diff --check`, and static syntax/import checks applicable without dependency installation.**
|
|
|
+
|
|
|
+**Step 5: Commit a focused change and update factual module evidence.**
|
|
|
+
|
|
|
+## Task 5: HIS workstation, review/accounting, and delivery pages (`MRC-PC-ORDER-001~003`)
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/MrcOrderWorkbench.jsx`
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/MrcReviewAccounting.jsx`
|
|
|
+- Create: `04-新项目源码_source/项目源码/cloudhis-pr/src/pages/mrcDemo/MrcDelivery.jsx`
|
|
|
+- Modify: `src/pages/mrcDemo/DemoShell.jsx`, `demoState.js`, and `mrcDemo.css` only when driven by a failing focused test.
|
|
|
+- Test: `src/pages/mrcDemo/demoState.test.js` and focused `src/pages/mrcDemo/<module>.test.js` Node tests for pure state/data helpers.
|
|
|
+
|
|
|
+For each module, in this exact order: `ORDER-001` → `ORDER-002` → `ORDER-003`:
|
|
|
+
|
|
|
+1. Read the module formal review, OpenSpec `tasks.md`, and actual HTML prototype to build the module-specific visual checklist before editing files.
|
|
|
+2. Add a focused failing test for the newly allowed order action/state mapping, execute it, and verify the failure is caused by missing behavior.
|
|
|
+3. Build the visual layout using the project’s existing Ant Design `Table` and other public components; do not modify shared components. Keep excluded actions absent or explicitly disabled as specified.
|
|
|
+4. Re-run focused and aggregate Node tests, run `git diff --check`, and perform a route/import/static source review. Do not call backend APIs or claim a webpack build.
|
|
|
+5. Commit the single module with factual status/evidence updates after code and tests exist.
|
|
|
+
|
|
|
+## Task 6: Endpoint review gates and serial integration
|
|
|
+
|
|
|
+**Files:**
|
|
|
+- Modify: the exact relevant module `tasks.md` / delivery record only to record actual test commands, commit SHA, review result, and remaining limitation.
|
|
|
+- Modify: `01-项目文档_docs/00-项目管理/03-交付验收/功能模块总进度表.md` only during the PM-controlled serial integration.
|
|
|
+
|
|
|
+**Step 1: For each endpoint lane, dispatch a fresh specification reviewer after the implementer reports all assigned modules.**
|
|
|
+
|
|
|
+Reviewer must compare changed files against all seven/four module formal review records, OpenSpec requirements, the frozen state contract, source-root boundaries, and prototype visual checklists. Any gap returns to the same implementer for correction and re-review.
|
|
|
+
|
|
|
+**Step 2: Dispatch a fresh code-quality reviewer only after specification compliance is explicitly approved.**
|
|
|
+
|
|
|
+Reviewer checks test-first evidence, state isolation, deterministic seed data, route safety, prohibited API usage, regression risk, and maintainability. Any issue is fixed and re-reviewed.
|
|
|
+
|
|
|
+**Step 3: Integrate endpoint branches one at a time into `develop`.**
|
|
|
+
|
|
|
+Before each integration: rebase the lane branch, run the required endpoint checks again, inspect `git diff --check`, and resolve documentation-row conflicts centrally. Never merge two worktree branches concurrently.
|
|
|
+
|
|
|
+**Step 4: Change module status to `待验收(Demo)` only after its integrated source, passing allowed checks, review evidence, and visual acceptance checklist exist.**
|
|
|
+
|
|
|
+**Step 5: Run final cross-end acceptance from the five contract scenarios.**
|
|
|
+
|
|
|
+Verify semantic parity, not data sharing: scenario switch/reset, applicant submission/progress, HIS review/accounting, HIS delivery, illegal-action feedback, and visible Demo/limited-capability markers. Record actual limitations, especially the existing HIS build dependency block.
|
|
|
+
|
|
|
+## Acceptance evidence required before the next-morning review
|
|
|
+
|
|
|
+1. A traceable commit and source-root-limited diff for each of the 11 modules.
|
|
|
+2. Test-first RED/green evidence for every new Adapter/state behavior and all allowed offline tests passing.
|
|
|
+3. Module-by-module visual checklist against the approved HTML prototypes, including dialogs, empty/error states, and unimplemented controls.
|
|
|
+4. Separate mini-program and HIS demo walkthrough instructions; no implication that they live-sync.
|
|
|
+5. PM integration report showing status, residual risk, and the explicit limitation that no real interface, production build authorization, or backend verification occurred.
|