Files
ruoyi-vue-pro/docs/education/migration/08-slice-roadmap.md

12 KiB
Raw Blame History

Vertical Slice Roadmap

Phase 0 static assessment generated on 2026-07-29. No build, test, application startup, PostgreSQL connection, or Flyway migration was executed during this assessment.

Tickets are vertical behaviors, not technical layers. Work blockers first and use a fresh implementation context per ticket.

EDU-P0-S0 — Baseline, completeness, and architecture decision gate

  • Outcome: Verified baseline, capability/API/database/module-reuse maps, commit reviews, decision register, corrected documentation plan, and bounded first-slice specification.
  • Risk: High provenance and operational risk; no implementation should begin from an unclassified dirty baseline.
  • Blockers:
  • Obtain or explicitly approve source baseline main/033701a because no source feature/education-core-loop ref exists.
  • Record current target status and preserve all 65 modified tracked and 97 untracked entries.
  • Complete the ten GOAL.md Phase 0 artifact dispositions and separate committed, dirty, absent, and runtime-unverified behavior.
  • Decide tenant origin-binding, principal policy, provider authority, option schema, and PUBLIC graph semantics.
  • Verification:
  • Read GOAL.md and target/source rules and module documentation.
  • Record both Git statuses, histories, and refs without destructive commands.
  • Review 11e9cc6, 0f846fd, and committed core-loop evidence ce02f8a.
  • Confirm no tests, builds, PostgreSQL connections, Flyway migrations, or runtime flows were executed.
  • Inventory Auth/Profile/extended Learning, granular tenant-admin, platform-admin, worker/scanner, and database object surfaces.

EDU-P0-S1 — Provider-neutral safe question and session restoration

  • Outcome: Both provider modes and restored sessions fail closed for malformed/unavailable published question content while preserving tenant scope and safe projections.
  • Risk: Medium implementation risk and high assessment-integrity/security risk if any alternate path remains fail-open.
  • Blockers:
  • EDU-P0-S0 provider and option-contract decisions.
  • Existing dirty provider/session files must be separated from unrelated work.
  • Safe response and question-type option semantics must be fixed.
  • Verification:
  • Provider contract tests for Scalar and Java.
  • Browsing, collection, practice-create/restore, malformed, unavailable, unpublished, cross-tenant, PUBLIC, and sensitive-field tests.
  • Run focused tests/compile/diff checks only after authorization and report exact results.

EDU-P2-S2 — Create and restore practice

  • Outcome: A student creates and restores a tenant-scoped practice session from valid published content without client-supplied identity or tenant IDs.
  • Risk: Medium; session ownership, graph scope, and schema packaging require negative tests.
  • Blockers:
  • EDU-P0-S1 safe-content contract.
  • Core-loop schema must be promoted into active module-owned Flyway history.
  • Provider authority and existing dirty session implementation classification.
  • Verification:
  • Tenant/user context and Member-principal tests.
  • Restore ownership, cross-tenant denial, PUBLIC-scope tests.
  • PostgreSQL uniqueness, transaction, packaging, and migration execution checks if schema changes are approved.

EDU-P2-S3 — Idempotent answer save

  • Outcome: A student saves one answer idempotently with explicit duplicate/conflicting-payload semantics and no sensitive-field exposure.
  • Risk: Medium-to-high due to concurrent writes, stale versions, and answer leakage.
  • Blockers:
  • EDU-P2-S2 session state.
  • Existing answer/idempotency schema and option snapshot contract.
  • Entitlement decision for non-public/private content.
  • Verification:
  • Same-payload duplicate and conflicting-payload tests.
  • Concurrent PostgreSQL uniqueness/transaction tests.
  • Tenant isolation, stale-version, safe-response, and malformed-snapshot tests.

EDU-P2-S4 — Atomic submit, report, wrong questions, and favorites

  • Outcome: A student atomically claims and submits a session, reads an immutable report, and receives consistent wrong-question/favorite projections.
  • Risk: High; current check-then-insert submit idempotency is not sufficient.
  • Blockers:
  • EDU-P2-S3 answer state.
  • Atomic submit-key reservation and crash recovery design.
  • Scoring/report immutability and entitlement decisions.
  • Verification:
  • ON CONFLICT/atomic claim concurrency tests.
  • Processing-row crash recovery and retry semantics.
  • Immutable report/scoring, duplicate submission, wrong-question/favorite idempotency, sensitive-field, tenant, and unauthorized tests.

EDU-P3-S5 — Tenant content publication and graph integrity

  • Outcome: Tenant administrators author, classify, publish, and safely retire question content with tenant-consistent graph integrity.
  • Risk: High due to publication, admin scope, public graph, and student-read consistency.
  • Blockers:
  • Core loop verified.
  • Provider and education content model decisions.
  • System RBAC/DataPermission policy.
  • Verification:
  • Admin permission/row-scope tests.
  • Composite tenant/scope relationship constraint or equivalent enforcement tests.
  • Publication visibility/provider consistency and safe-projection regression tests.

EDU-P3-S6 — Content imports, exports, assets, and scanning

  • Outcome: Tenant administrators import/export education content with durable business state, leases, retries, duplicate-safe processing, file security, and audit.
  • Risk: High operational and security risk.
  • Blockers:
  • Publication model.
  • Infra File contract and scanner ownership.
  • Infra Job/MQ durable claim/lease semantics.
  • Verification:
  • Preview/execute state machine.
  • Atomic claim/lease/heartbeat/expiry/retry/dead-letter tests.
  • MIME/size/object-key/scan fail-closed tests.
  • Tenant propagation, audit redaction, and partial-failure tests.

EDU-P4-S7 — Classes and education relationships

  • Outcome: Tenant administrators manage classes, education student relationships, invitations, supervision, and education operations with explicit scope.
  • Risk: High authorization risk.
  • Blockers:
  • Education relationship model.
  • System RBAC/DataPermission scope rules.
  • Member relationship contract and CRM supervision decision.
  • Verification:
  • Student/teacher/class permission matrix.
  • Cross-class/cross-tenant negative and duplicate invitation tests.
  • Audit redaction and operation-log tests.

EDU-P4-S8 — Tenant configuration, integrations, and access operations

  • Progress: V4290/EDU-017 completed bounded appearance, public settings, and theme lifecycle. V4300V4360 reuse and activate native Pay/System integration, transaction, import, Transfer, and Wallet capabilities. V4310/EDU-019 delivers secure learning activation codes and entitlement composition. V4370/EDU-025 activates Product; V4380/EDU-026 activates coupons; V4390/EDU-027 activates normal Trade order; V4400/EDU-028 activates Discount/Reward; V4410/EDU-029 activates delivery; V4420/EDU-030 activates after-sale/Pay Refund; V4430/EDU-031 activates native brokerage; V4440/EDU-032 activates tenant-aware Seckill; V4450/EDU-033 activates tenant-aware Combination activities, SKU pricing, group records, atomic capacity, Trade Order/head bridges, exact permissions, and corrected Vben pages. Domains remain with their RuoYi owners; source referral CRM/settlement-proof import, Bargain/Point and other Promotion families, explicit legacy Product/code-coupon/order/refund import, production bulk export/runbooks and reviewed balances, automatic fulfillment/refund revocation, non-equivalent provider/mode replacement, tenant PNVS, legacy activation-code import, generic private secrets, and public-bank access remain separate.
  • Outcome: Selected tenant appearance, integrations, secrets, activation codes, coupons, and public-bank access capabilities have explicit owners and safe contracts.
  • Risk: High because secret, payment configuration, redemption, and public-bank synchronization boundaries differ.
  • Blockers:
  • Appearance/domain/integration/secrets/codes ownership decisions.
  • System tenant configuration and secret APIs.
  • Mall/Pay/Member entitlement and coupon contracts; EDU-019 resolves bounded new activation codes, EDU-021EDU-024 resolve bounded Pay activation/import/ledgers, EDU-025 resolves Product, EDU-026 resolves coupons, EDU-027 resolves normal Trade order, EDU-028 resolves Discount/Reward, EDU-029 resolves delivery, EDU-030 resolves after-sale, EDU-031 resolves native brokerage, EDU-032 resolves native Seckill, and EDU-033 resolves native Combination activation. Explicit legacy Product/code-coupon/order/refund/referral/settlement-proof import, Bargain/Point and other Promotion families, legacy activation-code import, production financial bulk migration and reviewed opening balances, fulfillment, and refund revocation remain open.
  • Verification:
  • Secret redaction/rotation and authorization tests.
  • Domain/auth-provider/payment-account configuration tests; EDU-021 covers bounded account mapping/replay/redaction, EDU-022 covers transaction tenant inheritance, composite database references, notification uniqueness, native service regressions, and menu shape, EDU-023 covers terminal reconciliation, redacted audit, idempotency/conflict, and native order-page UI, EDU-024 covers Transfer/Wallet tenant inheritance, tenant-qualified locks, amount safety, composite references, and native UI/menu shape, and EDU-025 covers nine Product tenant records, catalog graph references, category parent isolation, amount/score safety, global-table refusal, and native UI/menu shape.
  • Native coupon tenant/reference/counter/discount/use-state and menu-shape tests are delivered by V4380. V4390 adds Trade tenant inheritance, composite Order/Cart/Product references, state/amount checks, global/deferred-table refusal, sequences, and exact order/config UI/menu shape. Legacy code and order import/reconciliation remain open. V4310 already covers activation-code digest, tenant, replay, conflict, disabled dependency, entitlement-event, and concurrent-winner behavior.
  • Public-bank grant/sync and cross-tenant tests.

EDU-P5-S9 — Education commercialization binding

  • Outcome: Education products bind to commerce purchases and Member entitlements without duplicated financial ledgers.
  • Risk: High financial and authorization risk.
  • Blockers:
  • Product binding model; EDU-025 supplies the tenant-scoped native Product owner but binding authoring/import semantics remain open.
  • Mall/Pay public APIs; Product, native coupons, normal Trade order/delivery/after-sale, native brokerage, Seckill, and Combination are active, while Bargain/Point and other Promotion families, source referral/settlement-proof mapping, and purchase/refund-to-entitlement composition remain open.
  • Member entitlement decision and callback/refund semantics.
  • Verification:
  • Order/payment/refund callback contracts.
  • Entitlement issuance/revocation/expiry and idempotent fulfillment.
  • Reconciliation, commission/referral, authorization, and audit tests.

EDU-P5-S10 — Extended student and secondary learning waves

  • Outcome: Selected Auth/Profile/extended Learning/scoreline/vocabulary/video/AI/notification/badge/exam capabilities are migrated, replaced, retired, or deferred with traceable decisions.
  • Risk: Medium-to-high due to omitted student contracts, media entitlement, and unclear ownership.
  • Blockers:
  • Explicit scope for each secondary capability.
  • AI/File/Member/System/Infra contracts and entitlement model.
  • Verification:
  • Per-capability endpoint/data/authorization contract tests.
  • Progress/report/vocabulary state tests.
  • Media entitlement, safe export/redaction, tenant isolation, and retirement compatibility tests.

EDU-P6-S11 — Operational independence and legacy exit

  • Outcome: Background and platform operations run independently of NestJS with documented retries, scanning, audit, notifications, observability, and deployment evidence.
  • Risk: High deployment and reliability risk.
  • Blockers:
  • All owner and contract decisions.
  • Operational deployment, scanner, observability, and legacy exit plan.
  • Verification:
  • Worker/job deployment smoke tests.
  • At-least-once duplicate/dead-letter and scanner health/security tests.
  • PostgreSQL migration execution evidence.
  • Runbook and documentation consistency review.