docs(education): update migration status and add EDU-017~033 tickets

docs/education/migration/issues/EDU-012-classes-relationships.md

@@ -3,7 +3,7 @@
 - **Status:** implemented
 - **Type:** bounded vertical capability
 - **Phase:** 4
-- **Decision:** Education owns tenant-local classes and student/teacher relationships to existing Member identities. System RBAC remains the action-authorization boundary; class roles never become System roles. No platform tenant-ignore endpoint or supervision model is introduced in this slice.
+- **Decision:** Education owns tenant-local classes, student/teacher relationships, learning-risk rules, and follow-up tasks. System RBAC, AdminUser, departments, and data-permission policy remain authoritative; Member owns student accounts. Class roles never become System roles.
 
 ## Tenant-admin outcome
 
@@ -25,7 +25,10 @@ Tenant administrators manage classes, student education relationships, invitatio
 - Management permissions are independent: `education:class:create`, `education:class:query`, `education:class-member:query`, and `education:class-invitation:create`. Permissions are provisioned separately by System RBAC and are not represented in class relationships.
 - All aggregate tenant IDs come from `TenantContextHolder`; tenant-qualified mapper predicates and PostgreSQL triggers reject cross-tenant relationships.
 - Invitation creation is idempotent per tenant, actor, and key with request-hash conflict detection. Acceptance locks the invitation, checks invitee and expiry, and writes relationship plus audit in one transaction.
-- This bounded slice intentionally excludes account creation, password handling, platform tenant-ignore operations, education profile duplication, and supervision relationships.
+- This capability intentionally excludes account creation, password handling, platform tenant-ignore operations, and education profile duplication.
+- V4270 adds supervision without changing account ownership: risk evidence is aggregated from existing Education practice, wrong-question, session, and vocabulary tables; Member and System data are API projections only.
+- Classes, rules, and follow-ups carry only `dept_id`/`owner_user_id` authorization projections and are registered with RuoYi `DeptDataPermissionRule` for department/self row scope.
+- Risk preview, rule authoring, idempotent task generation, and optimistic task handling have independent System permissions. `(tenant_id, batch_key, student_user_id)` is the retry-safe generation key; atomic PostgreSQL conflict-ignore and a subsequent scoped read return the same committed task to concurrent callers without recovering from a failed transaction.
 
 ## Role and permission semantics
 
@@ -42,6 +45,9 @@ Tenant administrators manage classes, student education relationships, invitatio
 - [x] Invitation acceptance is idempotent and auditable.
 - [x] Platform-admin tenant-ignore operations are explicit and permission guarded (none are exposed by this bounded capability).
 - [x] Database changes use `flyway-postgresql`.
+- [x] Risk preview and follow-up reads respect tenant plus System department/self data scope, including an unfiltered-class CTE aggregation path verified against a real `LoginUser`/`DeptDataPermissionRespDTO` PostgreSQL context.
+- [x] Supervision assignees are validated by `AdminUserApi`, and students are enriched by `MemberUserApi`.
+- [x] Follow-up generation and handling are duplicate-safe and stale-write-safe.
 
 ## Risk and rollback
 

docs/education/migration/issues/EDU-014-extended-learning.md

@@ -16,7 +16,7 @@
 | Video entitlement and progress | Entitlement owner unresolved; media delivery outside Education | **Explicitly retired from this wave.** No video endpoint, token, progress write, or metadata-based access bypass is added. Legacy video/progress data is retained until an entitlement-led child slice defines import and deletion policy. | P3 blocked | Capability manifest must expose no video interface |
 | Recommendation and AI generation | AI public services plus Education authorization | **Explicitly deferred.** No student profile or learning history is sent to AI, and no AI recommendation endpoint is exposed. Legacy recommendation data remains retained but non-authoritative. | P3 blocked | Capability manifest must expose no AI interface |
 | Notifications and reminders | Education schedule + System `NotifyMessageSendApi` | **Migrated for exam reminders.** Education owns claim/retry state; System owns message rendering/storage. A stable `education_exam_reminder` template is conditionally seeded. | P1 | Due claim, retry, tenant context, notify-port tests |
-| Points, badges, check-ins, feedback, exam countdowns | Education orchestration + Member `MemberPointApi`; feedback/reminders Education | **Partially migrated.** Fixed server-side learning awards, one badge family, feedback, and exam reminder/countdown data are delivered. Generic check-in/task exchange remains Member-owned/deferred. | P1 bounded | Duplicate award, fixed-value, port failure, feedback ownership |
+| Points, badges, check-ins, feedback, exam countdowns | Education orchestration + Member `MemberPointApi`; feedback/reminders/badge rules Education; System Notify | **Partially migrated.** Fixed server-side learning awards, configurable tenant badge definitions, automatic practice/vocabulary/feedback rules, lifetime-once manual grants, tenant-admin handling/audit, bounded resolved-feedback rewards, and exam reminder/countdown data are delivered. Generic check-in/task exchange and badge triggers that depend on not-yet-migrated check-in/mock-exam/activity domains remain deferred. | P1 bounded | Duplicate award/grant, invalid rule, optimistic conflict, notify failure, feedback ownership |
 | Learning analytics, leaderboard, trends, reports | Education projections over immutable reports/vocabulary/awards | **Partially migrated.** Own summary and bounded tenant leaderboard are delivered. Leaderboard is anonymized and contains no user IDs or report details. Trend/export surfaces are deferred. | P1 bounded | Tenant isolation, deterministic ranking, redaction |
 
 ## Executable APIs
@@ -29,6 +29,9 @@ Student identity and tenant are always derived from the authenticated context; n
 - Learning award orchestration: `/app-api/education/learning/awards`
 - Own learning summary: `/app-api/education/learning/summary`
 - Anonymous tenant leaderboard: `/app-api/education/learning/leaderboard`
+- Tenant-admin learning operations: `/admin-api/education/learning-operations/*`
+- Student badge projection: `/app-api/education/engagement/badges`
+- Tenant-admin badge definitions and grants: `/admin-api/education/badge/*`
 - Scheduled dispatch bean: `examReminderSendJob` using System Notify public API
 
 ## Security and reversibility
@@ -37,6 +40,9 @@ Student identity and tenant are always derived from the authenticated context; n
 - Client requests cannot choose point values, badge codes, notify templates, delivery users, or leaderboard tenant.
 - Exam reminder delivery uses a token-fenced, expiring database claim. An interrupted `SENDING` row is reclaimed after lease expiry, attempts are bounded, and exhausted claims become observable `FAILED` rows through V4200.
 - Award rows and reminder rows are durable retry authorities; cross-module tables are never written directly by Education application code.
+- Education point calls use stable Member ledger business keys backed by V4250 uniqueness. Feedback rewards require `RESOLVED` state, a separate reward permission, and a bounded server-validated value.
+- Badge definitions and automatic rules are tenant-owned. Badge grants reuse the Education award ledger, validate manual targets through Member, project administrators through System, and use a partial unique key for lifetime-once delivery. A failed System notification is recorded as `FAILED` without undoing the grant.
+- Automatic badge rules can subscribe only to implemented Education events (`PRACTICE_SUBMIT`, `VOCABULARY_REVIEW`, `FEEDBACK_RESOLVED`); absent legacy domains are not represented as fake triggers.
 - Leaderboard output uses deterministic tenant-local aliases and aggregate score only. No phone, profile, member ID, answer, explanation, feedback content, or report detail is exported.
 - Rollback disables/removes executable application paths while retaining V4160 data. Destructive rollback is not provided; later correction uses a higher forward migration.
 - Video and AI remain fail-closed: this wave exposes no executable interface and establishes no entitlement through access metadata.

docs/education/migration/issues/EDU-017-tenant-appearance.md

@@ -0,0 +1,38 @@
+# EDU-017 — Tenant appearance, public settings, and theme lifecycle
+
+- **Status:** done — bounded appearance/theme slice implemented and verified
+- **Type:** tenant administration / public presentation configuration
+- **Phase:** 4 / tenant operations
+- **Blockers:** EDU-003, System Tenant authority, Vben admin foundation
+
+## Decision
+
+System Tenant remains authoritative for tenant identity, display name, lifecycle, and bound websites. Education owns only presentation-specific configuration: branding extensions, student/admin feature flags, public runtime configuration, and draft/published theme state. The public tenant locator response remains the minimal EDU-003 contract; appearance is exposed separately under the normal request tenant context.
+
+Platform theme templates are global trusted configuration and are explicitly excluded from MyBatis tenant injection. Tenant appearance rows extend `TenantBaseDO`, retain one live row per tenant, and use optimistic versions for every update. RuoYi System RBAC, tenant validation, admin projection, API access/operation logging, and the normal `tenant-id` security filter remain authoritative.
+
+## Delivered contract
+
+- Admin read, branding write, settings write, theme preview, and theme publish endpoints with independent permissions.
+- `GET /education/tenant-appearance/public` is anonymous but not tenant-ignored; it requires the normal validated tenant header/context and returns no admin flags or draft data.
+- System tenant name is the lazy-row default and fallback; no duplicate Education tenant identity or domain authority is created.
+- Three legacy-compatible templates are seeded: `classic`, `focus`, and `high-contrast`.
+- Theme preview is a shallow template/override merge. Publication revalidates the persisted draft and clears it atomically.
+- Recursively rejects secret/password/token/private-key/API-key-like public keys except `secretRef`; theme tokens, CSS variables, icons, assets, colors, radii, modes, and density are allowlisted and unsafe renderable strings fail closed.
+- Vben page `education/tenant-appearance/index` manages branding, JSON settings, templates, draft preview, and explicit publication with client-side preflight checks.
+
+## Verification
+
+- Policy unit tests cover recursive secret rejection, closed theme/asset key sets, colors/radii/CSS, URLs, and shallow merge.
+- Service unit tests cover System-name fallback, optimistic conflict, sanitized draft persistence, and public projection.
+- Method-security contract tests prove query, branding, settings, and theme permissions are independent.
+- Real PostgreSQL service tests prove lazy defaults, shared templates, settings, draft/publish, public projection, stale-version rejection, and cross-tenant isolation through the production MyBatis interceptor.
+- Flyway tests prove the V4290 schema, exact template seeds, menu shape, unique tenant row, and draft/publish database state.
+
+## Explicitly open
+
+- Domains stay in System Tenant `websites`; no Education domain CRUD authority is planned.
+- Payment-account configuration must compose Pay rather than copy the legacy table.
+- Authentication-provider configuration must reuse System/Member authentication seams.
+- Tenant secret storage/rotation needs a dedicated encrypted private-storage decision and must never be added to the public appearance table.
+- Activation codes and coupons need a Mall Promotion/Member entitlement ownership and idempotent redemption decision.

docs/education/migration/issues/EDU-018-native-payment-social-admin.md

@@ -0,0 +1,33 @@
+# EDU-018 — Reuse native payment and social-provider administration
+
+- **Status:** done — bounded native-administration reuse implemented and verified
+- **Type:** tenant administration / module reuse
+- **Phase:** 4 / tenant operations
+- **Blockers:** EDU-017, Pay module, System social-client module, Vben admin foundation
+
+## Decision
+
+Legacy `tenant_payment_accounts` and supported OAuth-provider administration must not become Education-owned shadow tables. Payment applications/channels remain authoritative in Pay; tenant third-party login clients remain authoritative in System. V4300 places their existing Vben pages under the Education menu and grants only their original granular permissions.
+
+The duplicated menu locations use unique route names, so roles may receive Education-scoped navigation without changing the original Pay/System routes. All requests still reach the native controllers and services. No credential is copied into Education and no compatibility facade invents a second status model.
+
+## Delivered contract
+
+- Education menu entry for native `pay/app/index` with Pay App and Pay Channel query/create/update/delete permissions.
+- Education menu entry for native `system/social/client/index.vue` with Social Client query/create/update/delete permissions.
+- Fail-closed Flyway menu-shape validation and collision detection.
+- Existing Pay/System Vben forms, controllers, tenant interception, and validation are reused. EDU-020/V4320 subsequently activates the Pay runtime and supplies the missing tenant-scoped App/Channel PostgreSQL contract.
+
+## Verification
+
+- Real PostgreSQL Flyway test verifies both route components, unique route names, all twelve native permissions, and V4300 history.
+- A conflicting pre-existing menu ID causes V4300 to fail rather than silently binding the wrong permission.
+- The existing Vben production build already compiles both reused native pages; V4300 adds no frontend source or dependency.
+
+## Explicitly open
+
+- EDU-021 now maps bounded `tenant_collect` WeChat/Alipay accounts into native Pay with a redacted audit. Platform/service-provider modes, XPay/Xunhu replacement, and production bulk export/runbook work remain open.
+- `system_sms_channel` is global and `@TenantIgnore`; it is not legacy tenant-level auth-provider equivalence.
+- Aliyun PNVS has no proven native target provider and remains a separate auth/SMS slice.
+- Generic tenant secret storage/rotation remains separate. Native Pay/System credentials stay owned by those modules.
+- Activation codes and coupons remain a Mall Promotion/Member entitlement and idempotent-redemption slice.

docs/education/migration/issues/EDU-019-learning-activation-codes.md

@@ -0,0 +1,34 @@
+# EDU-019 — Secure learning activation codes
+
+## Status
+
+Done for the bounded V4310 contract. Legacy activation-code import and coupons remain separate.
+
+## Decision
+
+Activation codes are Education learning-access credentials, not Mall Promotion coupons. They reference a Mall-owned SPU through the existing tenant-scoped `education_resource_product_binding`, authenticate redemption with the existing Member principal, and grant access through the existing idempotent `EducationEntitlementService` event pipeline. No product, member, coupon, or second entitlement ledger is introduced.
+
+## Delivered contract
+
+- Tenant-owned activation-code batches and codes with database constraints, tenant-composite foreign keys, optimistic versions, and separate query/manage/generate permissions.
+- Admin batch page/create/update/generate and masked code page/disable endpoints.
+- Member-only app check/redeem endpoints; administrator and anonymous principals fail closed.
+- Cryptographically random codes normalized for redemption. Plaintext is returned only by the successful generation response; persistence stores SHA-256 digest and a mask.
+- `SELECT ... FOR UPDATE` serializes redemption. A successful grant writes the existing entitlement event/aggregate, marks the code redeemed, and increments the batch count in one transaction.
+- Same-member retry returns the existing entitlement idempotently; another member receives an already-used conflict.
+- Batch SPU, duration, and prefix become immutable after generation. Disabled batches, codes, or resource bindings cannot be redeemed. `durationDays=0` intentionally means no expiry.
+- Vben page `education/activation-code/index` provides batch and masked-code tables, create/edit/generate flows, copy/download, unsaved-plaintext dismissal warning, and disable confirmation. Closing the generation modal clears plaintext.
+
+## Verification
+
+- PostgreSQL Flyway verifies both tables, constraints, cross-tenant batch references, four menu rows, and migration history through V4310.
+- Controller contracts verify independent admin permissions and Member-only app access.
+- Unit tests verify digest/mask persistence, entitlement composition, replay/conflict, target validation, and generated-batch immutability.
+- Real PostgreSQL service tests verify digest-only persistence, tenant isolation, entitlement/event creation, same/different-member behavior, disabled dependencies, and one winner under concurrent redemption.
+- Vben formatting, lint, Vue typecheck, and production build cover the fifteenth custom Education page.
+
+## Explicit non-goals
+
+- Importing or preserving plaintext from legacy activation-code rows.
+- Coupon templates, claims, discounts, stacking, or redemption; those remain Mall Promotion-owned.
+- Payment/order/refund fulfillment, legacy payment mode/provider mapping, tenant PNVS, or generic encrypted secret rotation.

docs/education/migration/issues/EDU-020-native-pay-runtime.md

@@ -0,0 +1,36 @@
+# EDU-020 — Activate tenant-scoped native Pay administration
+
+- **Status:** done — bounded Pay App/Channel runtime activation implemented and verified
+- **Type:** platform reuse / tenant security / database takeover
+- **Phase:** 4 / tenant operations
+- **Blockers:** EDU-018, native Pay module, PostgreSQL Flyway
+
+## Problem
+
+V4300 deliberately reused the native Pay App/Channel controllers, permissions, and Vben page, but the repository reactor and `yudao-server` still excluded `yudao-module-pay`, and the active PostgreSQL baseline had no `pay_app` or `pay_channel` tables. The menu was therefore only navigational evidence, not an operational payment-configuration backend.
+
+Stock/global Pay tables are also unsafe to adopt silently in a multi-tenant education deployment. A channel supplied with an arbitrary `appId` must not bind to an application outside the current tenant.
+
+## Delivered contract
+
+- `yudao-module-pay` is included in the reactor and server runtime.
+- V4320 creates Pay-owned `pay_app` and `pay_channel` tables with tenant columns, logical-delete audit fields, active-row uniqueness, status checks, and tenant-first indexes.
+- Existing Pay tables without `tenant_id` fail migration with an explicit mapping error; V4320 never assigns legacy credentials to tenant `0` or another guessed tenant.
+- `PayAppDO` explicitly extends `TenantBaseDO`, so framework MyBatis tenant interception is a declared contract rather than an implicit table convention.
+- Channel create/update verifies that the referenced application is visible to the current tenant before persisting the channel.
+- `/pay/app/list` now uses the actual `pay:app:query` permission already granted by V4300 instead of the obsolete `pay:merchant:query` permission.
+- The existing `pay/app/index` Vben page remains authoritative; no Education payment form or credential table is duplicated.
+
+## Verification
+
+- 17 `PayChannelServiceTest` checks pass, including missing/cross-tenant-parent rejection seams.
+- Two Pay tenant/permission contract checks pass.
+- All 45 current PostgreSQL Flyway tests pass through V4380, including same `app_key` across tenants, duplicate rejection within a tenant, channel uniqueness, V4320 history, and fail-closed adoption of a global `pay_app` table.
+- `mvn -pl yudao-server -am -DskipTests compile` includes and compiles the native Pay module.
+
+## Explicitly open
+
+- EDU-021 now provides an explicit, audited single-account import for `tenant_collect` WeChat/Alipay manifests. Platform/service-provider modes, unsupported providers, and production bulk export/runbook work remain open.
+- EDU-022 now activates tenant-scoped native Pay order, refund, and notification persistence/UI; EDU-023 adds bounded terminal legacy transaction import; EDU-024 activates native Transfer/Wallet persistence and UI without inventing opening balances.
+- Payment credentials remain Pay-owned. Generic tenant secret encryption/rotation and PNVS remain separate slices.
+- EDU-025 delivers native Mall Product activation. Explicit legacy product import, Promotion/Trade, coupon redemption, purchase fulfillment, refund-to-entitlement revocation, and reconciliation remain separate commercialization slices.

docs/education/migration/issues/EDU-021-legacy-pay-account-import.md

@@ -0,0 +1,51 @@
+# EDU-021 — Import legacy tenant payment accounts into native Pay
+
+- **Status:** done — bounded single-account import, audit, and native Pay UI entry implemented and verified
+- **Type:** legacy data bridge / payment security / tenant isolation
+- **Phase:** 4 / tenant operations
+- **Blockers:** EDU-020, native Pay App/Channel runtime, PostgreSQL Flyway
+
+## Problem
+
+The legacy `tenant_payment_accounts` and `app_private.tenant_secrets` records cannot be copied directly into native Pay. Provider aliases, collection modes, channel variants, callback ownership, credential shapes, and status values are not one-to-one. Guessing any of them can route money or callbacks to the wrong party.
+
+The migration also needs durable evidence without creating an Education payment shadow model or persisting a second plaintext credential copy.
+
+## Delivered contract
+
+- The bridge is Pay-owned and creates native `pay_app` and `pay_channel` rows through `PayAppService` and `PayChannelService`; Education owns neither a payment account nor a credential table.
+- `POST /pay/legacy-account-import/import` imports exactly one explicitly reviewed manifest. It requires both `pay:app:create` and `pay:channel:create`.
+- `GET /pay/legacy-account-import/page` exposes tenant-filtered audit history and requires both Pay App and Channel query permissions.
+- The existing `pay/app/index` Vben page adds a **迁移旧支付账号** action and JSON manifest modal. The button uses explicit AND permission visibility, matching the controller.
+- Import request-body logging is disabled for database access logs, non-production request logs, and unexpected-error logs so the manifest does not become a plaintext logging side channel.
+- Only `tenant_collect` is accepted. `platform_collect` and `service_provider` fail closed because their settlement and merchant ownership semantics are not equivalent.
+- Historical WeChat and Alipay aliases normalize to `wechat_pay` or `alipay`. Non-equivalent providers such as XPay/Xunhu fail closed.
+- Operators must explicitly select a native channel such as `wx_lite`, `wx_pub`, or an Alipay variant. Provider family and channel family must match; the importer never guesses a WeChat client type.
+- WeChat V3 and Alipay public-key configurations map into native Pay configuration objects. Multiple rotating WeChat platform keys require an explicit choice. Alipay accepts only the native production or sandbox official gateway.
+- Old provider callbacks are not reused. The manifest must provide new business order/refund callbacks and may provide a transfer callback.
+- `active` maps to enabled. `disabled` and `pending` map to disabled with an audit note.
+- Within the current target tenant, `sourceAccountId` is the idempotency key. A replay with the same source SHA-256 returns the existing mapping; a different checksum is rejected rather than overwriting it.
+
+## Audit and database contract
+
+V4330 creates tenant-scoped `pay_legacy_account_import` with source identifiers/checksum, normalized provider/config digest, target App/Channel IDs, mapping notes, operator, and timestamp. It deliberately has no `config_public`, `secret_json`, raw config, or secret-value column.
+
+Composite foreign keys `(tenant_id,target_app_id)` and `(tenant_id,target_channel_id)` prevent an audit row from pointing across tenants. A target tenant may import the same legacy UUID independently, while duplicate active source IDs inside one tenant are rejected. An existing global audit table without `tenant_id` causes migration failure and requires explicit disposition.
+
+Credentials still enter native `pay_channel.config` using Pay's existing configuration storage. EDU-021 prevents an extra audit copy; it does not introduce generic encryption or key rotation for native Pay credentials.
+
+## Verification
+
+- Nine focused importer tests pass for WeChat/Alipay mapping, aliases, disabled-state mapping, replay, checksum conflict, unsupported modes/providers, channel mismatch, unsafe endpoints/rotating keys, and audit redaction. A controller contract verifies dual write permission and request-body logging suppression.
+- The combined Pay selection passes 29 tests, including the prior tenant App/Channel contracts.
+- All 45 PostgreSQL Flyway integration tests pass through V4380. V4330 coverage verifies tenant-independent legacy UUID reuse, no raw credential columns, cross-tenant composite-FK rejection, mode constraints, migration history, and fail-closed global-table adoption.
+- The Vben `@vben/web-antd` typecheck passes with the import API, modal, and explicit dual-permission button.
+
+## Explicitly open
+
+- Audit history currently has a backend/Vben API contract but no dedicated history table in the account-import modal. EDU-023 provides its own recent transaction-import history table on the native order page.
+- A controlled export job from the legacy database and operator runbook are still required before production bulk migration. The UI template contains placeholders and must never be submitted unchanged.
+- Concurrent first imports of the same source account rely on the database unique constraint and transaction rollback; a friendly concurrent-replay response is not claimed.
+- Platform/service-provider settlement, XPay/Xunhu replacement, generic credential encryption/rotation, and tenant PNVS require separate decisions.
+- EDU-022 activates tenant-scoped native Pay order, refund, and notification ledgers; EDU-023 adds bounded terminal legacy transaction import; EDU-024 activates empty native Transfer/Wallet ledgers. Production bulk tooling and reviewed opening-balance migration remain open.
+- EDU-025 delivers native Mall Product activation. Explicit legacy product import, Promotion/Trade, coupon import/redemption, purchase fulfillment, refunds-to-entitlement revocation, and reconciliation remain separate commercialization work.

docs/education/migration/issues/EDU-022-native-pay-transactions.md

@@ -0,0 +1,45 @@
+# EDU-022 — Activate tenant-scoped native Pay transactions
+
+- **Status:** done — bounded order/refund/notification takeover and native administration UI verified
+- **Type:** platform reuse / financial isolation / database takeover
+- **Phase:** 4 / commercialization foundation
+- **Blockers:** EDU-020, EDU-021, native Pay runtime, PostgreSQL Flyway
+
+## Problem
+
+EDU-020 made native Pay application/channel configuration operational, but the active PostgreSQL baseline still had no order, order-extension, refund, notification-task, or notification-log tables. The existing Pay controllers and Vben pages therefore could not administer real transaction state.
+
+The stock transaction data objects were also inconsistent: notification tasks were tenant-aware, while orders, order extensions, refunds, and notification logs inherited only `BaseDO`. Silently creating global financial tables or assigning existing rows to a guessed tenant would make callbacks, exports, and background retries cross tenant boundaries.
+
+## Delivered contract
+
+- V4340 creates Pay-owned `pay_order`, `pay_order_extension`, `pay_refund`, `pay_notify_task`, and `pay_notify_log` tables for PostgreSQL. Education does not create a parallel order, refund, or webhook ledger.
+- `PayOrderDO`, `PayOrderExtensionDO`, `PayRefundDO`, `PayNotifyTaskDO`, and `PayNotifyLogDO` all inherit `TenantBaseDO`, so normal MyBatis tenant interception scopes native admin queries and mutations.
+- Composite tenant foreign keys bind orders to Pay applications/channels, extensions to orders/channels, refunds to their application/channel/order, and logs to their notification task. Cross-tenant references fail in PostgreSQL even if application code is bypassed.
+- Active merchant order/refund identifiers are unique inside a tenant application but may be reused by another tenant. Native Pay numbers and extension numbers are tenant-scoped.
+- One active notification task is allowed for each `(tenant_id,type,data_id)`. This closes duplicate terminal-callback races; a deliberately soft-deleted task may be recreated.
+- Existing transaction tables without `tenant_id` fail V4340. No global financial row is assigned to tenant `0` or inferred from an application ID.
+- The native order/refund callback entry points continue to resolve the channel first and execute the business update inside `TenantUtils.execute(channel.tenantId, ...)`. The existing notification retry job continues to use `@TenantJob`.
+- Existing Pay controllers remain authoritative: `/pay/order` and `/pay/refund` provide tenant-filtered query/export contracts, while `/pay/notify` provides tenant-filtered task/detail reads and the provider callback entry points.
+- V4340 exposes the existing `pay/order/index`, `pay/refund/index`, and `pay/notify/index` Vben pages below Education with the original `pay:order:*`, `pay:refund:*`, and `pay:notify:query` permissions. No custom Education transaction page was added.
+
+## Database safety
+
+The circular order/extension relationship is created in two steps. The final `fk_pay_order_extension` installation is guarded through `pg_constraint`: an equivalent named composite tenant foreign key is accepted, a conflicting named constraint fails closed, and a missing constraint is installed. V4340 also verifies the complete required column shape after table creation.
+
+The migration intentionally creates empty native transaction ledgers. It does **not** import legacy `orders`, `payments`, `payment_events`, or `commerce_refund_requests`; importing those records requires an explicit, reconciled mapping with amount/status/identifier/callback ownership rules.
+
+## Verification
+
+- All 45 PostgreSQL Flyway integration tests pass through V4380. V4340 coverage proves same merchant order ID across tenants, composite-FK cross-tenant rejection, active notification-task uniqueness and soft-delete recreation, native menu/permission shape, successful migration history, and fail-closed adoption of a global `pay_order` table.
+- The combined native Pay transaction regression passes 86 tests: 46 order, 28 refund, 11 notification, and one tenant-inheritance contract.
+- The previously disabled `PayNotifyServiceTest` is active; its asynchronous scheduling assertions and retry-count fixtures now match the production contract.
+- `mvn -pl yudao-server -am -DskipTests compile` and the Vben `@vben/web-antd` typecheck are the closing reactor/UI gates for this slice.
+
+## Explicitly open
+
+- EDU-023 now supplies a bounded, terminal-only reconciled import. Production export tooling, reviewed Member-ID mapping, dry-run/runbook evidence, and operator sign-off remain required; direct table copying is still forbidden.
+- EDU-024 now activates tenant-aware native Pay Transfer and Wallet persistence plus the existing administration pages. Historical opening balances remain deliberately unpopulated pending a reviewed source artifact.
+- EDU-025 delivers native Mall Product activation and EDU-026 delivers native Promotion Coupon activation. Explicit legacy product/code-coupon import, Trade/other Promotion activation, and automatic purchase-to-entitlement fulfillment are not delivered.
+- Refund completion does not yet revoke or shorten Education entitlements; commerce reconciliation must define partial-refund and replay semantics first.
+- Coupons, commissions, referrals, dunning, settlement/reconciliation, generic Pay credential encryption/rotation, tenant PNVS, production deployment, and browser/API integration evidence remain separate work.

docs/education/migration/issues/EDU-023-legacy-pay-transactions.md

@@ -0,0 +1,41 @@
+# EDU-023 — Import reconciled terminal legacy Pay transactions
+
+- **Status:** done — bounded terminal aggregate import, redacted audit, and native Pay order-page UI verified
+- **Type:** legacy data bridge / financial reconciliation / privacy
+- **Phase:** 4 / commercialization foundation
+- **Blockers:** EDU-021, EDU-022, PostgreSQL Flyway
+
+## Problem
+
+The legacy `orders`, `payments`, `payment_events`, and `commerce_refund_requests` rows cannot be copied into native Pay independently. Their statuses, identifiers, and totals form one aggregate; importing a live or inconsistent aggregate could make native jobs, callbacks, or operators charge or refund it again. Raw provider payloads and error bodies also contain data that does not belong in a second audit store.
+
+## Delivered contract
+
+- `POST /pay/legacy-transaction-import/import` imports one explicitly reviewed aggregate and requires `pay:legacy-transaction:import`. `GET /pay/legacy-transaction-import/page` exposes tenant-filtered audit history under `pay:legacy-transaction:query`.
+- Only terminal order, payment, and refund states are accepted. Amounts are already denominated in cents and must reconcile exactly: one verifiable successful payment at most, payment amount equals order price, successful refund sum equals `refundedPrice`, and order/refund status agrees with that sum.
+- Every aggregate must reference an EDU-021 `pay_legacy_account_import` from the same source tenant. All payment and refund provider families must match that reviewed mapping.
+- Imported data is written into Pay-owned `pay_order`, `pay_order_extension`, and `pay_refund`; Education does not gain a financial shadow ledger.
+- Import does not call a provider SDK, enqueue notification tasks, invoke business callbacks, or copy provider credentials. `raw_payload`, event payloads, channel notification bodies, and error originals are excluded. Payment-event evidence is reduced to a count and SHA-256 digest.
+- A target tenant uses source order UUID as its idempotency key. The same checksum replays the audit result without rewriting native ledgers; a different checksum is rejected. Native merchant order, payment extension, and refund-number collisions fail with a reconciliation error before writes.
+- The legacy model has no reliable client IP or channel fee. Native rows therefore use `0.0.0.0` and zero fee, and the audit records that limitation.
+- `targetUserId` is an explicit optional native Member ID. The importer does not infer a UUID-to-Member mapping and Pay does not depend directly on Member, avoiding a module cycle. Export tooling or the operator owns that reviewed mapping.
+- Request-body access logging is disabled. The existing native `pay/order/index` page exposes a permission-aware JSON manifest modal and the most recent 50 audit rows; no raw provider payload is rendered.
+
+## Database contract
+
+V4350 adds tenant-scoped `pay_legacy_transaction_import`, `pay_legacy_transaction_payment_import`, and `pay_legacy_transaction_refund_import`. Composite tenant foreign keys bind audit rows to the reviewed account mapping and native App, Channel, Order, Extension, and Refund targets. Existing global tables fail closed. The same legacy source UUID may be imported independently by distinct target tenants.
+
+The schema enforces terminal status sets, non-negative counts/totals, event-count/digest consistency, lowercase SHA-256 shapes, tenant-scoped source uniqueness, and exact expected table shape. None of the three tables contains a raw payload, credential, notification body, or error-original column.
+
+## Verification
+
+- Nine focused service/controller tests pass, covering reconciled full-refund import, redaction, replay, checksum conflict, provider mismatch, refund/status mismatch, event digest mismatch, refund-without-payment rejection, native-number collision, permission, and request-log suppression.
+- All 45 PostgreSQL Flyway integration tests pass through V4380. V4350 coverage proves composite cross-tenant rejection, per-target-tenant source reuse, event digest consistency, sensitive-column absence, exact menu/permission shape, migration history, and fail-closed global-table adoption.
+- Vben lint, formatting, and `@vben/web-antd` typecheck pass for the API, import/history modal, and native order-page integration.
+
+## Explicitly open
+
+- A controlled legacy export tool, Member-ID mapping artifact, operator runbook, dry-run report, backup, and production reconciliation sign-off are required before bulk import. The UI template contains placeholders and is not an unattended bulk migrator.
+- Concurrent first imports and native-number races still rely on database uniqueness and transaction rollback; a friendlier conflict replay is not claimed.
+- Failed/cancelled historical attempts are preserved as closed native extensions/refunds only inside a reconciled terminal aggregate. No live state is resumed.
+- EDU-024 activates native Pay Transfer/Wallet with empty tenant-owned ledgers, and EDU-025 activates an empty native Product catalog. Reviewed opening balances, explicit legacy product import, Promotion/Trade, automatic purchase fulfillment, refund-to-entitlement revocation, settlement reconciliation, coupons, commissions, referrals, dunning, generic credential encryption/rotation, tenant PNVS, and production browser/API evidence remain separate slices.

docs/education/migration/issues/EDU-024-native-pay-transfer-wallet.md

@@ -0,0 +1,41 @@
+# EDU-024 — Activate native Pay Transfer and Wallet
+
+- **Status:** done — tenant-owned native ledgers, security hardening, existing Pay APIs/UI, and PostgreSQL evidence delivered
+- **Type:** native module takeover / financial ledger / tenant isolation
+- **Phase:** 4 / commercialization foundation
+- **Blockers:** EDU-020, EDU-022, PostgreSQL Flyway
+
+## Problem
+
+RuoYi already provides Transfer and Wallet services, callbacks, jobs, permissions, and Vben pages, but their persistence was not activated by the Education PostgreSQL migration line and the corresponding data objects were not tenant-aware. Reimplementing those capabilities inside Education would create a second financial ledger. Inferring a wallet balance from the legacy backend would be unsafe because the legacy schema has no equivalent authoritative balance aggregate.
+
+## Delivered contract
+
+- Existing native Pay contracts remain authoritative: `/pay/transfer`, `/pay/wallet`, `/pay/wallet-transaction`, `/pay/wallet-recharge`, and `/pay/wallet-recharge-package`. No Education transfer, balance, recharge, or transaction controller was added.
+- `PayTransferDO`, `PayWalletDO`, `PayWalletTransactionDO`, `PayWalletRechargeDO`, and `PayWalletRechargePackageDO` now extend `TenantBaseDO`. Transfer synchronization keeps `@TenantJob`, and framework tenant injection scopes all normal mapper access.
+- Wallet locks now use `pay_wallet:lock:{tenantId}:{walletOrUserId}` so the same native identifier in two tenants cannot serialize against or interfere with the other tenant's operation.
+- Amount-changing service methods reject null, zero, and negative amounts. Administrator balance reductions use the conditional subtract path and cannot create a negative balance or incorrectly increase the member's lifetime expense total. `Integer.MIN_VALUE` cannot be negated through the admin request contract.
+- Wallet recharge refund completion uses the persisted recharge `walletId`; it does not dereference a separately loaded wallet. The refund action has its own `pay:wallet-recharge:refund` permission.
+- Wallet-provider transfer status lookup uses the native transfer number, matching the business key used when the wallet transaction was created.
+- Request DTOs validate positive user/package IDs, valid wallet business types, positive add amounts, non-zero admin adjustments, package name/amount/status shape, and non-negative bonus amounts.
+- The existing Vben `pay/transfer/index`, `pay/wallet/balance/index`, and `pay/wallet/rechargePackage/index` pages and APIs are reused. Member administration continues to provide the permission-aware balance-adjustment action.
+
+## Database contract
+
+V4360 creates empty tenant-scoped `pay_transfer`, `pay_wallet`, `pay_wallet_transaction`, `pay_wallet_recharge`, and `pay_wallet_recharge_package` ledgers. It never imports or invents a historical wallet balance.
+
+Composite tenant foreign keys bind transfers to native Pay App/Channel and wallet rows to their Wallet, Package, Order, and Refund owners. Balances, frozen amounts, and cumulative totals cannot be negative. A tenant can have only one active wallet per `(userId,userType)`, while the same identifiers remain valid in another tenant. Non-administrator transaction business keys are tenant-idempotent. Existing global tables fail closed instead of being silently adopted.
+
+V4360 also seeds the existing Vben routes and granular Transfer query/export, Wallet query/update, Recharge Package CRUD, and Recharge refund permissions.
+
+## Verification
+
+- Twelve focused Pay tests pass across transfer service behavior, tenant-aware DO/job/permission contracts, tenant-qualified Redis locking, safe positive/negative admin adjustments, non-positive amount rejection, recharge-refund wallet identity, and wallet-provider transfer lookup.
+- All 45 PostgreSQL Flyway integration tests pass through V4380. V4360 coverage proves same identifiers across tenants, same-tenant wallet uniqueness, cross-tenant Wallet Transaction and Transfer foreign-key rejection, database rejection of negative balances, exact menu/permission shape, migration history, and fail-closed global-wallet adoption.
+- The existing Vben Transfer/Wallet/Recharge Package APIs and pages pass formatting, lint, and `@vben/web-antd` typecheck as part of the combined UI verification.
+
+## Explicitly open
+
+- Production opening balances require a separately reviewed, reconciled source artifact and operator runbook. This slice deliberately creates empty wallet ledgers because the legacy system has no equivalent balance authority.
+- Transfer initiation, wallet recharge, channel callbacks, and refunds still require target-environment credentials, App/Channel setup, explicit role grants, and browser/API integration evidence.
+- EDU-025 now activates native Mall Product persistence and existing administration without importing legacy display rows. Promotion/Trade, explicit legacy product import, automatic purchase fulfillment, refund-driven entitlement revocation, settlement reconciliation, commissions, referrals, dunning, generic credential encryption/rotation, tenant PNVS, legacy activation-code import, coupons, and production bulk financial migration remain separate slices.

docs/education/migration/issues/EDU-025-native-mall-product.md

@@ -0,0 +1,58 @@
+# EDU-025 — Activate native Mall Product
+
+- **Status:** done — tenant-owned native Product persistence, existing Product APIs/UI, RBAC, and PostgreSQL evidence delivered
+- **Type:** native module takeover / product catalog / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-013, PostgreSQL Flyway
+
+## Problem
+
+RuoYi Vue Pro already provides Product controllers, services, mappers, permissions, and Vben pages for brands, categories, properties, SPUs, SKUs, comments, favorites, and browse history. The Mall reactor and Product server dependency were disabled, however, and the Product data objects were not tenant-aware. Rebuilding those capabilities inside Education would create a second product catalog.
+
+The legacy `public.products` object is only a tenant/region presentation projection with `title`, a display `price_label`, links, tags, cover/iframe/detail images, ordering, and lifecycle status. It has no authoritative SKU, integer price, stock, brand, property, delivery, commission, or sales model. An automatic conversion would invent commercial facts.
+
+## Delivered contract
+
+- The root build now includes `yudao-module-mall`, while `yudao-server` activates only `yudao-module-product`. Promotion, Trade, and Statistics runtime dependencies remain off until their own tenant-ledger slices are verified.
+- Existing native `/product/brand`, `/product/category`, `/product/property`, `/product/property/value`, `/product/spu`, `/product/comment`, `/product/favorite`, and `/product/browse-history` controllers remain authoritative. No Education product controller or duplicate catalog service was added.
+- `ProductBrandDO`, `ProductCategoryDO`, `ProductPropertyDO`, `ProductPropertyValueDO`, `ProductSpuDO`, `ProductSkuDO`, `ProductCommentDO`, `ProductFavoriteDO`, and `ProductBrowseHistoryDO` now extend `TenantBaseDO`, so normal MyBatis access participates in framework tenant injection.
+- Existing Vben pages are reused for SPU/SKU authoring, category trees, brands, property/value management, and comment moderation. V4370 seeds their original permissions below an Education `商品中心` route with unique component names.
+- The Product Vben scope passes typecheck, oxlint, and oxfmt. The formatter normalized one pre-existing multiline expression in the SPU form without changing behavior.
+
+## Database contract
+
+V4370 creates tenant-scoped PostgreSQL tables:
+
+- `product_brand`
+- `product_category`
+- `product_property`
+- `product_property_value`
+- `product_spu`
+- `product_sku`
+- `product_comment`
+- `product_favorite`
+- `product_browse_history`
+
+Every table uses `(tenant_id,id)` as its primary ownership key, allowing an explicit native identifier to be reused in another tenant while keeping every reference tenant-qualified. Composite foreign keys enforce Property Value → Property, SPU → Category/Brand, SKU → SPU, Comment → SPU/SKU, and Favorite/Browse History → SPU. Category root `parent_id=0` remains a sentinel; a trigger requires non-root parents to exist in the same tenant and limits the native category model to two levels.
+
+Database checks reject negative prices, stock, sales, integral, commission, weight, volume, and browse counts, and restrict comment scores to 1–5. Partial unique indexes protect active brand/property/value names, one active favorite per member/SPU, one active browse-history row per member/SPU, and one active comment per member/order item. Existing global Product tables fail closed instead of being silently assigned to a tenant.
+
+V4370 seeds menu IDs 6920–6944 for the Product root, five native pages, and the exact SPU, Category, Brand, Property, and Comment controller permissions.
+
+## Legacy data decision
+
+V4370 creates an empty native catalog and does not read or transform legacy `public.products`. A later import, if required, must provide an explicit reviewed mapping for tenant UUIDs, region semantics, integer prices, SPU/SKU structure, stock authority, brand/category/property ownership, delivery mode, media admission, and Education resource bindings. A display price label or URL is not sufficient evidence for any of those fields.
+
+## Verification
+
+- The focused Product tenant contract passes and proves all nine native Product records inherit `TenantBaseDO`.
+- The Product reactor test run succeeds; the repository's 33 pre-existing Product service tests remain disabled by their existing test configuration, while the new tenant contract executes successfully.
+- All 45 PostgreSQL Flyway integration tests pass through V4380. V4370 coverage proves cross-tenant ID reuse, same-tenant uniqueness, composite foreign-key rejection, category parent isolation/two-level enforcement, amount/stock and score checks, exact menu shape, migration history, and fail-closed global-table adoption.
+- `mvn -pl yudao-server -am -DskipTests compile` succeeds with Product enabled.
+- `@vben/web-antd` typecheck and scoped Product oxlint/oxfmt checks pass.
+
+## Explicitly open
+
+- Native Product pages require target-environment role grants, browser/API smoke evidence, media/file configuration, and deliberate catalog population.
+- Promotion coupons are delivered by EDU-026; Promotion discounts and other activity families, Trade cart/order/after-sale/delivery, Statistics, automatic purchase fulfillment, refund-driven entitlement revocation, and Education product-binding workflows remain separate slices.
+- Legacy `products` import remains blocked on an explicit semantic mapping and reconciled source artifact; no SKU, stock, price, or category is inferred.

docs/education/migration/issues/EDU-026-native-mall-coupon.md

@@ -0,0 +1,51 @@
+# EDU-026 — Activate native Mall Promotion coupons
+
+- **Status:** done — tenant-owned native coupon templates/instances, existing APIs/UI, RBAC, and PostgreSQL evidence delivered
+- **Type:** native module takeover / coupon lifecycle / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-025, PostgreSQL Flyway
+
+## Problem
+
+RuoYi Vue Pro already provides coupon-template and issued-coupon controllers, services, Product-scope validation, Member lookup, registration issuance, expiry processing, permissions, and Vben pages. The Promotion server dependency was disabled and its two coupon records inherited only `BaseDO`, so reimplementing coupons inside Education would create a second marketing ledger without fixing tenant ownership.
+
+Legacy `public.coupons` are code-based campaign rules with plan/region restrictions, first-order rules, usage counters, and `coupon_redemptions`. Native Promotion coupons are templates that issue member-owned coupon instances before order use. They are not losslessly interchangeable.
+
+## Delivered contract
+
+- `yudao-server` now activates `yudao-module-promotion` in addition to Product; Trade and Statistics remain disabled until their own ledger slices are verified.
+- Existing native `/promotion/coupon-template`, `/promotion/coupon`, `/app-api/promotion/coupon-template`, and `/app-api/promotion/coupon` contracts remain authoritative. Education adds no coupon controller or duplicate service.
+- `CouponTemplateDO` and `CouponDO` extend `TenantBaseDO`, so native mapper/service access participates in the framework tenant interceptor.
+- Native template creation reuses Product SPU/category validation. Native coupon administration reuses Member lookup, direct/admin/registration issuance, expiry processing, use/return, and soft-delete recovery rules.
+- Promotion's unrelated bargain/combination beans require `TradeOrderApi`. EDU-027 now activates the native Trade implementation and removes the temporary fail-closed adapter that was used while Trade was absent.
+- V4380 mounts the existing Vben template and issued-coupon pages below an Education `优惠券中心` using the original seven controller permissions and unique component names.
+
+## Database contract
+
+V4380 creates tenant-scoped PostgreSQL tables:
+
+- `promotion_coupon_template`
+- `promotion_coupon`
+
+Both use `(tenant_id,id)` ownership keys and explicitly named identity sequences. Coupon → Template is a tenant-qualified composite foreign key, so an identifier valid in another tenant cannot be referenced. Checks enforce native status/take/scope/validity/discount enums, fixed-date or relative-term validity, non-negative thresholds and discounts, issue/use counter consistency, positive members/orders, and complete used-coupon state. Indexes support template discovery, member/status lookup, template issuance lookup, and expiry jobs. Existing global coupon tables fail closed instead of being silently assigned to a tenant.
+
+V4380 seeds menu IDs 6950–6959 for the coupon root, template page, issued-coupon page, and exact query/create/update/delete/send permissions.
+
+## Legacy data decision
+
+V4380 starts the native coupon ledger empty. It does not reinterpret a legacy code campaign as a pre-issued member coupon, invent template/instance IDs, discard plan/region/first-order semantics, or attach historical redemptions to unverified native orders and members. A later compatibility/import slice must explicitly decide whether to preserve code redemption as a separate adapter or transform reviewed campaigns and redemption history.
+
+## Verification
+
+- The Promotion coupon tenant contract proves both native coupon records inherit `TenantBaseDO`; EDU-027 separately verifies the native Trade dependency that replaced the temporary fallback.
+- The focused V4380 Flyway scenario passes and proves same IDs can exist across tenants, cross-tenant template references fail, invalid counters/discounts/used state fail, explicit sequences exist, exact menus/permissions are installed, and global-table adoption fails closed.
+- All 45 PostgreSQL Flyway integration tests pass.
+- `mvn -pl yudao-server -am -DskipTests compile` succeeds with Product and Promotion enabled.
+- `@vben/web-antd` typecheck and scoped Coupon oxlint/oxfmt checks pass.
+
+## Explicitly open
+
+- Legacy code-campaign and redemption compatibility/import remains a separate mapping slice.
+- EDU-027 activates the tenant-scoped normal-order core. Coupon-to-special-order and refund composition still depend on deferred Promotion and Trade after-sale slices.
+- Discount/reward/seckill/combination/bargain/point/Diy/KeFu Promotion families are not activated at the database/menu level by this slice.
+- Target-environment role grants, browser/API smoke evidence, and deliberate template population remain operational work.

docs/education/migration/issues/EDU-027-native-mall-trade-order.md

@@ -0,0 +1,53 @@
+# EDU-027 — Activate native Mall Trade order core
+
+- **Status:** done — tenant-owned order core, native APIs/UI, RBAC, and PostgreSQL evidence delivered
+- **Type:** native module takeover / order lifecycle / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-020, EDU-024, EDU-025, EDU-026, PostgreSQL Flyway
+
+## Problem
+
+RuoYi Vue Pro already provides the normalized Trade order aggregate, cart and price orchestration, Pay/Product/Promotion/Member composition, administrator order/config controllers, jobs, permissions, and Vben pages. The Server dependency was disabled and its core data objects inherited only `BaseDO`. Rebuilding orders inside Education would create a second commerce ledger and duplicate native payment, member, catalog, and coupon boundaries.
+
+Legacy orders cannot be copied safely from terminal payment aggregates or display-only product rows. Native Trade requires verified Member identities, SPU/SKU line items, price allocation, delivery mode, payment linkage, status history, and promotion state that those projections do not contain.
+
+## Delivered contract
+
+- `yudao-server` activates `yudao-module-trade`; native `TradeOrderApiImpl` is now authoritative and the temporary Promotion fallback from EDU-026 is removed.
+- Existing `/trade/order`, `/trade/config`, `/app-api/trade/order`, and `/app-api/trade/cart` contracts remain owned by Trade. Education adds no shadow order or cart API. This slice proves the administrator order/config interface and core persistence; it does not yet claim successful app checkout.
+- `TradeOrderDO`, `TradeOrderItemDO`, `TradeOrderLogDO`, `TradeConfigDO`, and `CartDO` extend `TenantBaseDO`, so their native mapper/service access participates in framework tenant injection.
+- V4390 mounts the existing order and trade-config Vben pages below an Education `交易中心` with the exact native query/update/pick-up/config permissions.
+- Deferred after-sale, delivery-master-data, and brokerage tables are not silently activated. V4390 rejects any pre-existing version of those tables until a dedicated tenant-safe slice owns their schema and UI.
+
+## Database contract
+
+V4390 creates tenant-scoped PostgreSQL tables:
+
+- `trade_config`
+- `trade_cart`
+- `trade_order`
+- `trade_order_item`
+- `trade_order_log`
+
+All use `(tenant_id,id)` ownership keys and explicitly named identity sequences. Order Item → Order/Cart/Product and Order Log → Order references are tenant-qualified. Cart → Product, Order → Pay Order, and Order → Promotion Coupon references are also tenant-qualified. Checks enforce native order/type/terminal/delivery/refund/cancel/log enums, amount/count bounds, payment/cancel/delivery shapes, after-sale reference shape, and one active config per tenant. Indexes match administrator paging, member history, cart selection, auto-cancel/receive jobs, order details, and log history.
+
+V4390 seeds menu IDs 6960–6967 for the Trade root, order page, config page, and exact five controller permissions.
+
+## Legacy data decision
+
+The native Trade ledger starts empty. V4390 does not fabricate line items from Pay totals, guess tenant/member/SPU/SKU links, translate terminal statuses into a richer order lifecycle, or attach historical coupons and refunds without reviewed source identities. A later import slice requires an explicit reconciliation contract and quarantine path.
+
+## Verification
+
+- The focused Trade tenant contract proves all five activated records inherit `TenantBaseDO`.
+- The focused V4390 Flyway scenario proves same IDs can exist across tenants, cross-tenant Cart/Order Item references fail, invalid cancel/config states fail, five explicit sequences exist, exact menus/permissions are installed, core global-table adoption fails closed, and deferred Trade tables fail closed.
+- The full PostgreSQL Flyway suite passes with 46 scenarios through V4390.
+- `mvn -pl yudao-server -am -DskipTests compile` succeeds with Product, Promotion, and Trade enabled.
+- The existing Vben order/config pages pass the web app typecheck and scoped lint/format checks.
+
+## Explicitly open
+
+- Native after-sale, delivery express/template/pick-up-store, and brokerage persistence/UI require later tenant-safe slices.
+- Normal checkout still invokes native Promotion discount and reward lookups whose tables are deferred, and special orders require additional Promotion families. V4390 therefore does not claim end-to-end purchase creation, seckill, bargain, combination, point, discount, or reward orders.
+- Legacy order import, automatic education-entitlement fulfillment, refund-driven revocation, and production reconciliation/runbooks remain separate work.
+- Target-environment role grants, scheduled-job deployment, and browser/API smoke evidence remain operational work.

docs/education/migration/issues/EDU-028-native-checkout-promotions.md

@@ -0,0 +1,36 @@
+# EDU-028 — Activate native checkout Promotion activities
+
+- **Status:** done — tenant-owned discount/reward persistence, native APIs/UI, RBAC, and PostgreSQL evidence delivered
+- **Type:** native module takeover / checkout dependency / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-025, EDU-026, EDU-027, PostgreSQL Flyway
+
+## Problem
+
+Every normal RuoYi Trade price calculation invokes the native limited-time discount and reward calculators. Those calculators call `DiscountActivityApi` and `RewardActivityApi` even when no activity is configured, so V4390's order core still failed with missing Promotion tables before it could return an empty promotion result. Replacing these APIs inside Education would duplicate Promotion ownership and bypass the native administration UI.
+
+## Delivered contract
+
+- `DiscountActivityDO`, `DiscountProductDO`, and `RewardActivityDO` extend `TenantBaseDO`; their existing services, mappers, controllers, and public APIs remain authoritative.
+- V4400 creates tenant-scoped `promotion_discount_activity`, `promotion_discount_product`, and `promotion_reward_activity` tables with explicit PostgreSQL sequences and `(tenant_id,id)` ownership keys.
+- Discount Product → Activity/SPU/SKU references are tenant-qualified. Active SKU uniqueness, status/time, discount type/value, reward condition/scope, and JSON reward-rule checks fail closed in PostgreSQL.
+- The native cross-database `MyBatisUtils.findInSetWithParamIndex` already renders PostgreSQL `POSITION(...)` against the comma-separated `LongListTypeHandler` value; no mapper fork or Education shadow interface is introduced.
+- Menu IDs 6970–6982 mount the existing `mall/promotion/discountActivity/index` and `mall/promotion/rewardActivity/index` Vben pages with the exact ten native controller permissions.
+
+## Legacy data decision
+
+V4400 starts both activity families empty. Legacy coupon/code campaigns are not equivalent to time-boxed SKU discounts or structured full-reduction/gift rules, and no activity, product scope, time range, or reward rule is inferred.
+
+## Verification
+
+- The Promotion tenant contract proves all three activated records participate in framework tenant isolation.
+- The focused V4400 scenario proves cross-tenant identifier reuse, composite reference rejection, active-SKU uniqueness, PostgreSQL scope membership semantics, reward-rule/scope rejection, three explicit sequences, exact routes/permissions, and fail-closed global-table adoption.
+- A Spring/MyBatis integration test invokes the real `DiscountActivityApiImpl` and `RewardActivityApiImpl` against migrated PostgreSQL tables and proves empty normal-checkout lookups return empty lists rather than missing-table errors.
+- The full PostgreSQL Flyway suite passes 47 scenarios through V4400.
+
+## Explicitly open
+
+- This slice removes the normal price pipeline's discount/reward missing-table blocker; it does not claim end-to-end order creation. Delivery express/template/pick-up persistence and configured Pay App/Channel runtime data remain prerequisites for applicable checkout modes.
+- Seckill, bargain, combination, point, and other special-order Promotion tables remain separate tenant-safe activations.
+- Legacy Product/campaign/order import, purchase-driven Education entitlement fulfillment, refund-driven revocation, and production API/browser smoke evidence remain separate work.
+

docs/education/migration/issues/EDU-029-native-trade-delivery.md

@@ -0,0 +1,34 @@
+# EDU-029 — Activate native Trade delivery
+
+- **Status:** done — tenant-owned delivery persistence, native checkout calculation, RBAC, UI, and PostgreSQL evidence delivered
+- **Type:** native module takeover / checkout dependency / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-025, EDU-027, EDU-028, PostgreSQL Flyway
+
+## Problem
+
+Normal native Trade checkout supports express delivery and store pickup. Express pricing reads Product SPU delivery-template IDs, Member addresses, per-tenant Trade configuration, template charge/free rules, and delivery areas. Pickup validates an enabled store. The source backend has no equivalent physical-shipping aggregate, so implementing an Education-owned delivery API would duplicate RuoYi Trade and leave its existing administration UI disconnected.
+
+## Delivered contract
+
+- `DeliveryExpressDO`, `DeliveryExpressTemplateDO`, `DeliveryExpressTemplateChargeDO`, `DeliveryExpressTemplateFreeDO`, and `DeliveryPickUpStoreDO` extend `TenantBaseDO`; the native services, mappers, controllers, calculators, and Vben pages remain authoritative.
+- V4410 creates all five tables with explicit sequences, `(tenant_id,id)` ownership, tenant-qualified template-child references, and a charge-mode-qualified reference that prevents child/template mode drift.
+- Comma-separated area/user IDs are validated in the database using the formats consumed by `IntegerListTypeHandler` and `LongListTypeHandler`. Amounts, counts, charge modes, status, address, business hours, and coordinates fail closed.
+- Product SPU → delivery template and Trade Order → pickup store references are tenant-qualified. Pickup orders require a store; relevant lookup indexes are installed.
+- Menu IDs 6990–7006 mount the existing Express, Express Template, and Pickup Store pages with the exact thirteen permissions exposed by the native controllers.
+
+## Legacy data decision
+
+V4410 starts delivery configuration empty. The source backend contains no authoritative express company, freight rule, delivery area, store, coordinates, hours, or verifier mapping. No product is silently assigned a template and no store is fabricated.
+
+## Verification
+
+- The delivery tenant contract proves all five activated records participate in framework tenant isolation.
+- The focused V4410 Flyway scenario proves cross-tenant identifier reuse, Product/template and Order/store ownership, charge-mode consistency, area/location checks, pickup-order shape, five explicit sequences, exact routes/permissions, and fail-closed global-table adoption.
+- A Spring/MyBatis PostgreSQL integration test uses the production tenant SQL interceptor, creates same-named native templates in two tenants, proves isolated mapper results, reads real charge/free rules, and drives `TradeDeliveryPriceCalculator` through the persisted express template to a 700-cent delivery fee.
+- The full Flyway suite passes 48 scenarios through V4410; server and Vben verification are recorded in the migration UI report.
+
+## Explicitly open
+
+- Delivery persistence and calculation are active, but configured Pay App/Channel data and a target-environment order/payment smoke remain prerequisites for an end-to-end paid checkout claim.
+- Trade after-sale and brokerage, special-order Promotion families, explicit legacy Product/coupon/order import, purchase-driven Education entitlement fulfillment, and refund-driven revocation remain separate slices.

docs/education/migration/issues/EDU-030-native-trade-after-sale.md

@@ -0,0 +1,36 @@
+# EDU-030 — Activate native Trade after-sale
+
+- **Status:** done — tenant-owned after-sale persistence, native state machine, Pay Refund bridge, RBAC, corrected Vben UI, and PostgreSQL evidence delivered
+- **Type:** native module takeover / refund lifecycle / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-022, EDU-025, EDU-027, EDU-029, PostgreSQL Flyway
+
+## Problem
+
+The source backend stores order-level UUID rows in `public.commerce_refund_requests` and append-only `public.commerce_refund_events`, with statuses `requested`, `approved`, `processing`, `succeeded`, `failed`, `rejected`, and `cancelled`. RuoYi already owns a richer line-item after-sale state machine: Member application, administrator agree/disagree, return logistics, receipt/refusal, Pay Refund creation/callback, order-item state updates, immutable operation logs, exact RBAC, and an existing Vben list/detail page. Reimplementing that lifecycle in Education would create a second refund ledger and bypass native Trade/Pay coordination.
+
+## Delivered contract
+
+- `AfterSaleDO` and `AfterSaleLogDO` extend `TenantBaseDO`; existing app/admin controllers, `AfterSaleServiceImpl`, `AfterSaleLogServiceImpl`, order updates, and `PayRefundApi` remain authoritative.
+- V4420 creates `trade_after_sale` and `trade_after_sale_log` with explicit sequences and `(tenant_id,id)` ownership. Order, order item, SPU, SKU, Pay Refund, delivery express, log, and order-item back-reference constraints are tenant-qualified.
+- Database checks enforce native status/type/way values, non-negative amounts, required audit/return/refund facts, JSON arrays, valid log actor/operation/status values, unique tenant numbers, and at most one active after-sale per order item.
+- Menu IDs 7010–7015 reuse `mall/trade/afterSale/index` with exactly `trade:after-sale:query`, `agree`, `disagree`, `receive`, and `refund` permissions.
+- The Vben page sends the backend's `auditReason` field, requires `refuseMemo` in a locked/validated refusal modal, displays the actual application `createTime`, and guards every action with its exact permission. Backend request validation now rejects blank refusal notes and the detail response exposes `createTime`.
+
+## Legacy data decision
+
+V4420 starts the native after-sale ledger empty. A source request identifies an aggregate UUID order but does not identify a verified native Member, `trade_order_item`, SPU/SKU allocation, return quantity, delivery company, or Pay Refund row. Its status history also does not prove the native line-item and return-logistics transitions. Automatic import would invent ownership and lifecycle facts, so explicit legacy refund import is deferred until legacy Product, Order, Order Item, and Member mappings are reviewed.
+
+## Verification
+
+- The after-sale tenant contract proves both native records participate in framework tenant isolation.
+- The focused V4420 Flyway scenario proves cross-tenant identifier reuse, tenant-qualified ownership/back-references, two explicit sequences, audit/log rejection, exact route/permissions, and fail-closed adoption of a pre-existing global table.
+- A Spring/MyBatis PostgreSQL integration test imports the real services and production tenant SQL interceptor, creates same-ID Product/Order/Order Item fixtures in tenants 10 and 20, and proves isolated create, page, detail, and log reads plus order-item update calls.
+- The full PostgreSQL Flyway suite passes 49 scenarios through V4420. The server reactor compiles, and the corrected Vben page passes typecheck plus scoped oxlint/oxfmt checks.
+
+## Explicitly open
+
+- Trade brokerage and special-order Promotion families remain separate native activation slices.
+- Legacy Product/coupon/order/refund import requires explicit UUID-to-native mappings and reconciliation artifacts; V4420 does not reinterpret source refunds.
+- Configured target Pay App/Channel data and a deployed order/payment/refund smoke are still required for end-to-end production evidence.
+- Purchase-driven Education entitlement fulfillment and refund-driven entitlement revocation remain separate orchestration work.

docs/education/migration/issues/EDU-031-native-trade-brokerage.md

@@ -0,0 +1,43 @@
+# EDU-031 — Activate native Trade brokerage
+
+- **Status:** done — native tenant-owned relationships, commission records, withdrawal/Pay Transfer bridge, exact RBAC, corrected Vben UI, and PostgreSQL evidence delivered
+- **Type:** native module takeover / two-level commission / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-024, EDU-027, PostgreSQL Flyway
+
+## Problem
+
+The source backend has referral codes, leads, team edges, tracks, QR codes, CRM assignment, tenant commission settings, settlement aggregates/items, and proof/export events. RuoYi already owns a different but substantial Trade brokerage lifecycle: Member-backed promoter relationships, first/second-level order commissions, freeze/unfreeze, cancellation, withdrawals, Pay Transfer composition, app/admin APIs, scheduled settlement work, exact permissions, and three Vben administration pages. Rebuilding those overlapping behaviors in Education would create a second commission ledger and bypass native Member/Trade/Pay coordination.
+
+Primary source evidence remains in:
+
+- `/Users/tiku1/code/tiku-backend/supabase/migrations/202606210006_growth_referral_crm.sql`
+- `/Users/tiku1/code/tiku-backend/supabase/migrations/202606290009_commission_settlements.sql`
+- `/Users/tiku1/code/tiku-backend/supabase/migrations/202606290027_commission_settlement_proofs.sql`
+
+## Delivered contract
+
+- `BrokerageUserDO`, `BrokerageRecordDO`, and `BrokerageWithdrawDO` extend `TenantBaseDO`; native app/admin controllers, services, mappers, jobs, Member lookups, Trade order integration, and Pay Transfer API remain authoritative.
+- V4430 creates `trade_brokerage_user`, `trade_brokerage_record`, and `trade_brokerage_withdraw` with `(tenant_id,id)` ownership, explicit record/withdraw sequences, tenant-qualified relationship/source/withdrawal/Pay Transfer/Trade Order references, commission idempotency, amount/state/account/audit/transfer checks, and a 0–99 withdrawal-fee range.
+- Menu IDs 7020–7031 reuse the existing user, record, and withdrawal pages with exactly eight controller permissions: user query/create/update-bind/clear-bind/update-enable, record query, and withdrawal query/audit.
+- The Vben user page uses those real permissions for both drill-downs, disables the eligibility switch without update permission, exposes responsive forms/tables, and its API types now match the backend responses. Withdrawal rejection trims and requires a non-blank reason on both sides.
+- Immediate-settlement commission records now persist a settlement time, so the native time-range summary and ranking SQL includes zero-freeze commissions.
+
+## Legacy data decision
+
+V4430 activates the native ledger empty. Source referral/settlement rows use UUID identities and carry CRM lead assignment, referral-code/track attribution, settlement-batch state, and proof/export semantics that have no verified one-to-one mapping to native Member IDs, `trade_order` rows, two-level promoter relations, Pay Transfer rows, or immutable evidence artifacts. Importing them now would invent identity and settlement facts. Explicit referral CRM and commission-settlement import stays deferred until Member, lead, Order, payment, and proof mappings are reviewed; those source-only semantics are not declared retired.
+
+## Verification
+
+- The focused V4430 scenario proves table/sequence/check/index shape, same-number cross-tenant identities, tenant-qualified references, exact routes/permissions, and fail-closed adoption of a pre-existing global table.
+- The tenant contract proves all three native records participate in framework tenant isolation and withdrawal inputs reject missing type, non-positive price, and blank audit reason.
+- A Spring/MyBatis PostgreSQL integration test imports the real user/record services and production tenant SQL interceptor. Tenants 10 and 20 create the same Member IDs and business ID with different commission percentages; relationship/page reads, balances, MyBatis-Join summaries, and native annotated summary/ranking SQL remain isolated.
+- The corrected Vben pages pass workspace typecheck and scoped oxlint/oxfmt checks.
+- The full PostgreSQL Flyway suite passes 50 scenarios through V4430, and the server clean reactor compiles all 28 modules.
+
+## Explicitly open
+
+- Source referral code/lead/team-edge/track/QR/CRM-assignment semantics and settlement proof/export aggregates require dedicated mapping/import slices.
+- Special-order Promotion families and explicit legacy Product/coupon/order/refund import remain separate.
+- Purchase-driven Education entitlement fulfillment and refund-driven entitlement revocation remain separate orchestration work.
+- Configured Pay runtime, scheduled unfreeze/transfer operation, and deployed order-to-commission-to-withdrawal smoke evidence remain required for production acceptance.

docs/education/migration/issues/EDU-032-native-promotion-seckill.md

@@ -0,0 +1,39 @@
+# EDU-032 — Activate native Promotion seckill
+
+- **Status:** done — native tenant-owned seckill configuration, activities, SKU stock, Trade Order bridge, exact RBAC, corrected Vben UI, and PostgreSQL evidence delivered
+- **Type:** native module takeover / special-order promotion / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-025, EDU-027, PostgreSQL Flyway
+
+## Problem
+
+The source backend has no seckill table, endpoint, job, or administration surface. RuoYi already owns a complete Promotion seckill lifecycle: time configurations, SPU/SKU activity authoring, atomic stock changes, Trade Order integration, app/admin APIs, exact permissions, and two Vben administration pages. Rebuilding those behaviors in Education would create a second promotion inventory and bypass native Product, Promotion, Trade, Member, and tenant/RBAC coordination.
+
+Repository-wide source inventory under `/Users/tiku1/code/tiku-backend` found no seckill or 秒杀 capability. That absence is a data decision: the target capability starts empty and no legacy records are invented.
+
+## Delivered contract
+
+- `SeckillConfigDO`, `SeckillActivityDO`, and `SeckillProductDO` extend `TenantBaseDO`; the native controllers, services, mappers, Product APIs, Trade Order fields, and Vben pages remain authoritative.
+- V4440 creates `promotion_seckill_config`, `promotion_seckill_activity`, and `promotion_seckill_product` with `(tenant_id,id)` ownership, explicit PostgreSQL sequences, tenant-qualified Product SPU/SKU and activity references, JSON/time/price/stock/limit/state constraints, and fail-closed adoption of pre-existing global tables.
+- Tenant-aware triggers validate every configured time slot, keep product activity snapshots aligned, and reject deletion of a slot still used by an activity. `trade_order` gains a tenant-qualified seckill-activity reference and an order-type/activity consistency constraint.
+- Menu IDs 7040–7051 reuse the existing activity and time-config pages with exactly nine controller permissions: five activity permissions and four configuration permissions.
+- Service validation rejects duplicate SKUs, seckill prices above native SKU prices, stock above native SKU stock, invalid limit relationships, and unsafe stock restoration. Closing an activity transactionally disables its product snapshots; a used time configuration cannot be deleted.
+- The Vben pages use the real backend field shapes and permissions, validate time/limit/product relationships, handle empty products and prices safely, use the correct `0=enabled` switch direction, and provide responsive forms.
+
+## Legacy data decision
+
+V4440 activates all three native tables empty. There is no source seckill state to import, reconcile, or retire. This ticket does not reinterpret ordinary products, coupons, referral campaigns, or aggregate orders as seckill activities.
+
+## Verification
+
+- All 51 PostgreSQL Flyway scenarios pass through V4440, including the focused table/sequence/constraint/trigger/menu shape and fail-closed adoption cases.
+- A Spring/MyBatis PostgreSQL integration test imports the real native seckill services and production tenant SQL interceptor. Tenants 10 and 20 create the same numeric config/activity/product IDs; page and detail reads remain isolated; two concurrent attempts for the final unit produce exactly one success; restoration, close-state propagation, and used-slot deletion protection are verified.
+- Promotion contract tests prove the three records participate in framework tenant isolation and activity/config/product requests reject invalid time, limit, SKU, price, stock, status, and slider-image inputs.
+- The scoped Vben seckill files pass oxlint and oxfmt checks, and the complete `@vben/web-antd` typecheck passes.
+- The non-clean Maven reactor install through Education succeeds across 26 required modules without stopping the running server.
+
+## Explicitly open
+
+- Combination, Bargain, Point, and any other special-order Promotion families require separate tenant-safe activation slices.
+- Explicit legacy Product/coupon/order/refund/referral/settlement-proof import remains separate; no source seckill import is needed.
+- Purchase-driven Education entitlement fulfillment, refund-driven entitlement revocation, configured Pay runtime, and deployed end-to-end seckill checkout evidence remain required for production acceptance.

docs/education/migration/issues/EDU-033-native-promotion-combination.md

@@ -0,0 +1,39 @@
+# EDU-033 — Activate native Promotion combination
+
+- **Status:** done — native tenant-owned combination activities, SKU pricing, group records, Trade Order bridge, exact RBAC, corrected Vben UI, and PostgreSQL concurrency evidence delivered
+- **Type:** native module takeover / special-order promotion / tenant isolation
+- **Phase:** 5 / commercialization foundation
+- **Blockers:** EDU-025, EDU-027, PostgreSQL Flyway
+
+## Problem
+
+RuoYi already owns the complete group-buying lifecycle: SPU/SKU activity authoring, head/member records, group capacity and expiry, Trade Order integration, app/admin APIs, Member and Product lookups, permissions, and Vben administration. Rebuilding it in Education would create a second promotion/order aggregate and bypass the native Product, Promotion, Trade, Member, tenant, and RBAC boundaries.
+
+The source backend has no group-buying capability. Its only `combination` value appears in `docs/pb_schema.json` and `apps/api/src/features/tenant-content/imports.ts`, where it means an education combination-question type. It must not be interpreted as a promotion activity, product, order, or group record.
+
+## Delivered contract
+
+- `CombinationActivityDO`, `CombinationProductDO`, and `CombinationRecordDO` extend `TenantBaseDO`; native controllers, services, mappers, Product/Member/Trade APIs, jobs, app endpoints, and Vben pages remain authoritative.
+- V4450 creates `promotion_combination_activity`, `promotion_combination_product`, and `promotion_combination_record` with `(tenant_id,id)` ownership, PostgreSQL sequences, tenant-qualified Product SPU/SKU/activity/order/head references, snapshot/time/price/limit/state constraints, and fail-closed adoption of pre-existing global tables.
+- Product triggers require activity/SPU/SKU/status/time consistency and prevent a combination price above the native SKU price. Record and Trade triggers lock the head row, enforce capacity and activity/order/user/head consistency, allow the order-before-record bridge state, and reject deletion of an activity with group records.
+- Menu IDs 7060–7067 reuse the existing activity and record pages with exactly six controller permissions: five activity permissions and one record query permission.
+- Request and service validation reject blank/oversized names, invalid time and limit relationships, groups smaller than two, duplicate or mismatched SKUs, non-positive identifiers/prices/counts, prices above the native SKU price, and cross-activity parent groups. Closing an activity transactionally disables product snapshots; activity updates retain and refresh snapshot status/time.
+- Head creation returns the persisted head-record ID rather than the `0` sentinel. Joining locks the head before validation/insertion, preventing concurrent over-capacity membership.
+- The Vben activity and record pages use the backend VO shapes and combination-record dictionary, validate positive/time/limit/product inputs, handle missing prices/products, pass the correct head ID to the member dialog, expose exact permission guards, and use viewport-bounded dialogs and keyboard-operable showcase controls.
+
+## Legacy data decision
+
+V4450 activates the native tables empty. No legacy rows are imported or invented. Education combination questions remain Education content and are not mapped to Mall group buying; ordinary products and aggregate orders are likewise not reinterpreted.
+
+## Verification
+
+- All 52 PostgreSQL Flyway scenarios pass through V4450, including focused table/sequence/constraint/trigger/menu shape, order bridge, cross-tenant same-ID, and fail-closed adoption cases.
+- A Spring/MyBatis PostgreSQL integration test imports the real native activity and record services plus the production tenant SQL interceptor. Tenants 10 and 20 create the same numeric activity/product IDs; page, record, and summary reads remain isolated; activity edits and closure propagate product snapshots; a head returns its real record ID; two concurrent members competing for the final place produce exactly one success; cross-activity joins and deletion with records fail closed; Trade Order/record/head references remain consistent.
+- Promotion contract tests prove all three records participate in framework tenant isolation, request DTOs carry the required validation annotations and relationship checks, and the head response conversion never returns the sentinel.
+- Scoped Vben combination files pass oxlint and oxfmt checks, and the complete `@vben/web-antd` typecheck passes.
+
+## Explicitly open
+
+- Bargain, Point, and any other special-order Promotion families require separate tenant-safe activation slices.
+- Explicit legacy Product/coupon/order/refund/referral/settlement-proof import remains separate; no source combination import is needed.
+- Purchase-driven Education entitlement fulfillment, refund-driven entitlement revocation, configured Pay runtime, virtual-group expiry job operations, and deployed end-to-end combination checkout evidence remain required for production acceptance.

docs/education/migration/issues/README.md

@@ -48,6 +48,25 @@ Commerce ownership decisions
 All owner/contract decisions
   └── EDU-014 Extended learning waves               bounded representative wave delivered; blocked families explicitly deferred
         └── EDU-015 Operational independence        contracts implemented; release/deployment evidence remains
+
+EDU-003 + tenant-admin inventory
+        └── EDU-017 Tenant appearance/theme               bounded appearance/settings/theme lifecycle delivered; integrations/secrets/codes deferred
+              └── EDU-018 Native payment/social admin      Pay/System controllers, RBAC, and Vben pages reused
+              ├── EDU-019 Learning activation codes  bounded generation/redemption, entitlement composition, and Vben page delivered
+              └── EDU-020 Native Pay activation       Pay module plus tenant App/Channel schema and parent isolation delivered
+                    └── EDU-021 Legacy Pay import      explicit tenant-account mapping into native Pay with redacted audit delivered
+                          └── EDU-022 Native Pay transactions tenant order/refund/notify ledgers and native UI delivered
+                                └── EDU-023 Legacy Pay transactions reconciled terminal import and redacted audit delivered
+                                      └── EDU-024 Native Pay Transfer/Wallet tenant ledgers and native UI delivered
+                                            └── EDU-025 Native Mall Product tenant catalog and native UI delivered
+                                                  └── EDU-026 Native Mall Promotion coupon templates/instances and native UI delivered
+                                                        └── EDU-027 Native Mall Trade order core and native UI delivered
+                                                              └── EDU-028 Native checkout discount/reward activities and native UI delivered
+                                                                    └── EDU-029 Native Trade delivery and native UI delivered
+                                                                          └── EDU-030 Native Trade after-sale and corrected native UI delivered
+                                                                                └── EDU-031 Native Trade brokerage and corrected native UI delivered
+                                                                                      └── EDU-032 Native Promotion Seckill and corrected native UI delivered
+                                                                                            └── EDU-033 Native Promotion Combination and corrected native UI delivered
 ```
 
 ## Recommended execution order
@@ -55,7 +74,8 @@ All owner/contract decisions
 1. Complete production release evidence for **EDU-015** using the Pilot runbook and target-only `JAVA_READ` deployment.
 2. Add deferred EDU-011 scanner/parser/export adapters only when their owning platform contracts and deployment are available.
 3. Add automatic EDU-013 fulfillment only after Mall/Pay/CRM expose the recorded public events; keep manual trusted fulfillment and access fail-closed meanwhile.
-4. Select the next EDU-014 family only after its entitlement, privacy, and owner decisions are recorded.
+4. EDU-025 activates native Product, EDU-026 activates coupons, EDU-027 activates the normal Trade order core, EDU-028 activates discount/reward, EDU-029 activates delivery, EDU-030 activates after-sale/Pay Refund, EDU-031 activates native brokerage, EDU-032 activates native Seckill, and EDU-033 activates native Combination activities, group records, atomic capacity, exact RBAC, and corrected administration pages. Continue with Bargain/Point and other Promotion families, source referral CRM/settlement-proof import, explicit legacy product/coupon/order/refund import, automatic Mall/Pay fulfillment, refund-driven entitlement revocation, production export/runbook evidence, legacy activation-code import, tenant PNVS, and encrypted generic secret storage as separate slices.
+5. Select the next EDU-014 family only after its entitlement, privacy, and owner decisions are recorded.
 
 ## Phase 0 completion caveat