Phase 3.7: paid pairing flow + returning chat + extension flip

- Backend: payment_sessions + pairing_failures tables; payment.service.js and pairing-failure.service.js (new); rewritten pairing.service.js (payment-gated blast + targeted "Curhat lagi" + cancel + fallback); rewritten extension.service.js (data-driven auto-approve with offline safeguard, charge-at-approval); pricing.service.js (extension tiers without free trial); mitra-status.service.js (countAvailableMitras cached path); 60s sweeper for stale payment sessions - Backend routes: client.payment.routes, client.mitra-availability.routes, internal/failed-pairings.routes; client.chat.routes rewritten for payment-gated start + /returning + /cancel + /fallback-to-blast; internal/config.routes adds 4 new keys with Valkey invalidate publish - client_app: mitra-availability poll, payment screen + notifier, pairing notifier rewrite (PairingTargetedWaiting + PairingFailed states), targeted-waiting overlay + bestie-unavailable dialog, "Curhat lagi" CTA, failed-pairing terminal, extension via payment-session - mitra_app: PairingRequestType enum, returning-chat 20s countdown auto-dismiss, extension card "otomatis disetujui" copy - control_center: 4 new config rows in Settings, Failed Pairings page (filter + paginate + action menu), sidebar + route registered - Test infrastructure: Vitest backend (7/7 pass), Playwright CC (4/4 pass), Maestro mobile scaffold (CLI install pending) - Bugs found via Playwright + fixed: LoginPage labels not associated with inputs (a11y); backend internal CORS missing PATCH/PUT/DELETE in allow-methods (silent settings breakage in browsers since Stage 4) - Docs: phase3.7.md PRD, phase3.7-plan.md, phase3.7-questions.md (Q&A), phase3.7-testing.md (E2E checklist), phase3.7-test-run-2026-05-03.md (today's run results) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-03 23:02:49 +08:00
parent f3766813f3
commit d09e50af55
92 changed files with 9579 additions and 437 deletions
--- a/mitra_app/.maestro/README.md
+++ b/mitra_app/.maestro/README.md
@@ -0,0 +1,85 @@
+# mitra_app Maestro flows
+
+End-to-end UI automation for the mitra Flutter app using [Maestro](https://maestro.mobile.dev). Single-emulator + curl-as-customer pattern — when a flow needs a customer to "do something", it's simulated via backend API calls fired from `runScript` steps.
+
+## One-time install
+
+See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#one-time-install) — Maestro is a global CLI, install once and it serves both apps.
+
+You also need:
+- `adb` on your PATH (Android Studio platform-tools)
+- `jq` (`apt install jq` / `brew install jq`)
+- One Android emulator OR one connected device — **only one at a time** (per project decision)
+
+## Folder layout
+
+```
+.maestro/
+├── README.md                 # this file
+├── config.yaml               # shared env: app IDs, backend URL, test credentials
+├── flows/
+│   ├── 01_smoke.yaml
+│   ├── 02_online_offline_toggle.yaml
+│   └── 03_accept_general_blast.yaml
+└── scripts/
+    └── customer_blast_now.sh
+```
+
+## Configure for your environment
+
+Edit `.maestro/config.yaml` and fill in:
+- `BACKEND_URL` — must match the `--dart-define=API_BASE_URL=...` value the installed APK was built with
+- `TEST_CUSTOMER_ID` and `TEST_CUSTOMER_JWT` — used by the curl harness to fire blasts toward this mitra
+
+## Run a flow
+
+```bash
+maestro test mitra_app/.maestro/flows/01_smoke.yaml
+
+# all flows
+maestro test mitra_app/.maestro/flows/
+```
+
+If multiple devices are attached:
+```bash
+adb devices
+maestro --device emulator-5554 test mitra_app/.maestro/flows/01_smoke.yaml
+```
+
+## Per-machine overrides
+
+Override config.yaml values at runtime:
+
+```bash
+maestro test \
+  --env BACKEND_URL=http://192.168.99.10:3000 \
+  --env TEST_CUSTOMER_JWT=eyJhbGc... \
+  mitra_app/.maestro/flows/03_accept_general_blast.yaml
+```
+
+## Single-emulator + curl pattern
+
+This mirrors the client_app pattern. When a mitra-side flow needs the customer to act, the flow uses `runScript:` to fire the customer's API calls directly:
+
+1. Mitra app is on screen via Maestro on the only connected device
+2. `runScript: ../scripts/customer_blast_now.sh` creates + confirms a payment_session and fires a chat request as a "fake" customer
+3. The mitra app receives the blast via WS as it would from a real customer; Maestro asserts the overlay appears
+
+For the customer-side equivalent (drive customer with Maestro, simulate mitra via curl), see [`client_app/.maestro/`](../../client_app/.maestro/).
+
+## When to run mitra flows vs. client_app flows
+
+- **Default**: drive the customer side via `client_app/.maestro/`. Most Phase 3.7 assertions live there (CTA gating, payment screen, searching screen, failed-pairing terminal, "Curhat lagi" overlays).
+- **Run mitra flows when** you specifically need to assert mitra UI:
+  - Returning-chat 20s countdown actually visible + ticking
+  - Extension card copy reads "otomatis disetujui"
+  - Online/offline toggle behavior (Section J — mitra goes offline mid-session)
+  - Incoming-request overlay accept/decline buttons
+
+## Adding a new flow
+
+See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#adding-a-new-flow) — same pattern.
+
+## Troubleshooting
+
+See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#troubleshooting) — same checklist applies.
--- a/mitra_app/.maestro/config.yaml
+++ b/mitra_app/.maestro/config.yaml
@@ -0,0 +1,22 @@
+# Shared variables for all mitra_app Maestro flows.
+#
+# Override at runtime with `maestro test --env KEY=value` or by setting shell env vars.
+# See README.md for full setup + per-machine overrides.
+
+env:
+  # App identifiers
+  APP_ID_ANDROID: com.halobestie.mitra.mitra_app
+  APP_ID_IOS: com.halobestie.mitra
+
+  # Backend the app talks to — must match what the installed APK was built with.
+  BACKEND_URL: http://192.168.88.247:3000
+  BACKEND_INTERNAL_URL: http://192.168.88.247:3001
+
+  # Test mitra credentials — must exist in the mitras table on the target backend.
+  MITRA_PHONE: "+628200000001"
+  MITRA_OTP: "123456"
+
+  # If you need to drive a "second actor" (e.g., a customer creating a blast), the test
+  # flows curl the backend directly using these credentials.
+  TEST_CUSTOMER_ID: "REPLACE-WITH-A-REAL-CUSTOMER-UUID"
+  TEST_CUSTOMER_JWT: "REPLACE-WITH-A-VALID-CUSTOMER-JWT"
--- a/mitra_app/.maestro/flows/01_smoke.yaml
+++ b/mitra_app/.maestro/flows/01_smoke.yaml
@@ -0,0 +1,14 @@
+# Smoke test: launch the app and assert the home screen renders.
+# Use this flow first to verify Maestro can talk to your device/emulator at all.
+#
+# Run:
+#   maestro test mitra_app/.maestro/flows/01_smoke.yaml
+#
+# Pre-req: mitra_app debug APK installed on the connected device, signed in as a mitra.
+appId: ${APP_ID_ANDROID}
+---
+- launchApp:
+    clearState: false
+- assertVisible:
+    text: "Sesi Aktif|Riwayat Chat"
+    timeout: 10000
--- a/mitra_app/.maestro/flows/02_online_offline_toggle.yaml
+++ b/mitra_app/.maestro/flows/02_online_offline_toggle.yaml
@@ -0,0 +1,23 @@
+# Verifies the online/offline toggle works and reflects in the UI.
+# This is independent of the customer side — pure mitra UI test.
+#
+# Run:
+#   maestro test mitra_app/.maestro/flows/02_online_offline_toggle.yaml
+appId: ${APP_ID_ANDROID}
+---
+- launchApp:
+    clearState: false
+
+# Find the toggle and capture initial state.
+- assertVisible:
+    text: "Online|Offline"
+
+# Tap the toggle — it's a Switch widget; Maestro can tap by adjacent text label.
+- tapOn:
+    text: "Online|Offline"
+
+# After flipping, the opposite label should appear within ~2s
+# (status is server-confirmed via /api/mitra/status/online or /offline).
+- assertVisible:
+    text: "Online|Offline"
+    timeout: 5000
--- a/mitra_app/.maestro/flows/03_accept_general_blast.yaml
+++ b/mitra_app/.maestro/flows/03_accept_general_blast.yaml
@@ -0,0 +1,33 @@
+# Mirror of client_app's 03_payment_to_chat_happy.yaml — this drives the MITRA side
+# of the same flow. Use this when you specifically need to assert mitra-side UI
+# (the incoming overlay, accept tap behavior).
+#
+# Pre-req:
+#   1. Mitra signed in to the mitra_app and ONLINE
+#   2. TEST_CUSTOMER_ID and TEST_CUSTOMER_JWT in .maestro/config.yaml point at a real customer
+#   3. The customer has an existing confirmed payment_session ready to blast (use the
+#      seed_customer_pending_blast.sh helper)
+#
+# Run:
+#   maestro test mitra_app/.maestro/flows/03_accept_general_blast.yaml
+appId: ${APP_ID_ANDROID}
+---
+- launchApp:
+    clearState: false
+- assertVisible: "Online"   # ensure mitra is online before triggering the blast
+
+# Step 1: simulate a customer creating a confirmed payment + firing a general blast.
+# This script returns once the blast notification has been sent to this mitra.
+- runScript: ../scripts/customer_blast_now.sh
+
+# Step 2: incoming-request overlay appears on this device
+- assertVisible:
+    text: "Terima"
+    timeout: 10000
+- assertVisible: "Tolak"
+
+# Step 3: mitra accepts → overlay closes, chat opens
+- tapOn: "Terima"
+- assertVisible:
+    text: "Sesi Aktif"
+    timeout: 5000
--- a/mitra_app/.maestro/scripts/customer_blast_now.sh
+++ b/mitra_app/.maestro/scripts/customer_blast_now.sh
@@ -0,0 +1,36 @@
+#!/usr/bin/env bash
+# Seed a confirmed payment_session for the test customer and fire a general blast.
+# Used by Maestro flows that drive the mitra side and need a customer's request to
+# arrive without running a second app.
+#
+# Reads from .maestro/config.yaml env (BACKEND_URL, TEST_CUSTOMER_ID, TEST_CUSTOMER_JWT).
+
+set -euo pipefail
+
+: "${BACKEND_URL:?BACKEND_URL must be set in .maestro/config.yaml}"
+: "${TEST_CUSTOMER_JWT:?TEST_CUSTOMER_JWT must be set in .maestro/config.yaml}"
+
+# Step 1: create a payment session (paid tier, 30 minutes)
+echo "Creating payment session..."
+ps_response=$(curl -fsSL -X POST "$BACKEND_URL/api/client/payment-sessions" \
+  -H "Authorization: Bearer $TEST_CUSTOMER_JWT" \
+  -H "Content-Type: application/json" \
+  -d '{"duration_minutes": 30}')
+payment_session_id=$(echo "$ps_response" | jq -r '.data.id')
+echo "  payment_session_id=$payment_session_id"
+
+# Step 2: confirm the payment session
+echo "Confirming payment session..."
+curl -fsSL -X POST "$BACKEND_URL/api/client/payment-sessions/$payment_session_id/confirm" \
+  -H "Authorization: Bearer $TEST_CUSTOMER_JWT" \
+  -H "Content-Type: application/json" \
+  -d '{}' > /dev/null
+
+# Step 3: fire the chat request (general blast)
+echo "Firing general blast..."
+curl -fsSL -X POST "$BACKEND_URL/api/client/chat-requests" \
+  -H "Authorization: Bearer $TEST_CUSTOMER_JWT" \
+  -H "Content-Type: application/json" \
+  -d "{\"payment_session_id\":\"$payment_session_id\",\"topic_sensitivity\":\"regular\"}" > /dev/null
+
+echo "OK — blast fired. Mitra should receive the WS event within ~1s."