Browse Source

docs: add MRC Demo MVP implementation plan

anubis 3 days ago
parent
commit
0d828edf52
1 changed files with 168 additions and 0 deletions
  1. 168 0
      docs/plans/2026-09-15-mrc-demo-mvp-implementation.md

+ 168 - 0
docs/plans/2026-09-15-mrc-demo-mvp-implementation.md

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