Home Explore Help
Register Sign In
data_center_platform
/
PR_Min_APP_BA
10
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Branch: develop
Branches Tags
PR_Min_APP_BA
/
docs
/
plans
/
2026-09-15-mrc-demo-mvp-implementation.md

2026-09-15-mrc-demo-mvp-implementation.md 12 KB
Permalink History Raw

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.