ramadhan sjamsani
d09e50af55
- 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>
34 lines
1.2 KiB
YAML
34 lines
1.2 KiB
YAML
# 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
|