修正 OALAUNCH1 登录与业务流回归（05-28-oalaunch1-parallel-closeout）

.trellis/spec/hyb-oa/frontend-react-vite-design.md

@@ -32,6 +32,75 @@ or hidden according to the active Issue; do not silently re-enable them.
 - Trial-facing PC lists must hide obvious TEST/SMOKE records by default when a
   page-level toggle exists; the toggle may reveal them for troubleshooting.
 
+## Scenario: Business Flow Tests And Frozen Modules
+
+### 1. Scope / Trigger
+
+- Trigger: Playwright or QA shell tests need to create workflow data while some
+  product modules are frozen for launch.
+- Applies to `client/tests/e2e/**`, `scripts/qa/run-business-flow-gates.sh`,
+  and frontend route/permission assertions.
+
+### 2. Signatures
+
+- QA command: `BUSINESS_FLOW_GROUPS=<groups> bash scripts/qa/run-business-flow-gates.sh local`.
+- Frozen-module API expectation: non-admin launch roles may receive `403` for
+  frozen module list/create/submit endpoints.
+- Enabled workflow test data sources should use active entities such as leave,
+  reimbursement or procurement unless the task explicitly reopens the frozen
+  module.
+
+### 3. Contracts
+
+- Do not use a frozen module as fixture setup for an unrelated enabled feature.
+  Example: mobile approval offline sync should not create a travel request when
+  travel permissions are intentionally frozen.
+- Permission direct-access tests must assert the frozen contract directly, such
+  as employee `GET /api/travel-requests?...` returning `403`.
+- UI route smoke may still verify that a frozen page displays a boundary state
+  without entering a management or write-capable mode.
+- Do not loosen roles or seed permissions merely to make old E2E data setup
+  pass.
+
+### 4. Validation & Error Matrix
+
+- Frozen role calls frozen module create/submit/list endpoint -> `403` or the
+  documented feature-gate status.
+- Enabled workflow feature needs pending task data -> create data through an
+  enabled workflow entity.
+- E2E fails with `PERM_001` while setting up unrelated feature data -> update
+  the test data source before changing app permissions.
+
+### 5. Good/Base/Bad Cases
+
+- Good: mobile approval offline test creates a submitted leave request, then
+  verifies pending-task deep link, offline queue, sync success and conflict.
+- Base: travel-specific tests are skipped or admin-scoped while travel remains
+  frozen.
+- Bad: grant employee `travel.create` only so a mobile approval test can build
+  a fixture.
+
+### 6. Tests Required
+
+- Focused E2E group that previously failed.
+- Full affected business-flow group after the focused fix.
+- `cd client && npm run typecheck && npm run build` when TypeScript test code
+  changes.
+
+### 7. Wrong vs Correct
+
+#### Wrong
+
+```ts
+await createSubmittedTravelRequestViaApi({ user: EMPLOYEE });
+```
+
+#### Correct
+
+```ts
+await createSubmittedLeaveViaApi({ user: EMPLOYEE });
+```
+
 ## Convention: PC Operation List Density
 
 **What**: PC list/workflow pages that combine status metrics, tabs/filters,