# ts-mitra-2-05 — §2 Multiple pending invites surfaced in Undangan list
# Spec ref: requirement/flow_mitra.mermaid.md §2
#
# Walks (target):
#   1. Login → home online
#   2. Navigate to Undangan (Curhat Baru)
#   3. Fire 2-3 customer blasts in rapid succession via customer_blast_now.js
#   4. Popup appears for ONE of them; remaining are queued in
#      chat_request_notifier._pendingQueue
#   5. Tolak the popup → next pending request flips into incoming state,
#      popup re-appears; loop until the list drains. At every step the
#      underlying Curhat Baru list has the queued invites.
#
# TODO: SKIPPED — customer_blast_now.js creates a fresh payment_session per
# call, but the backend's pairing service performs a blast and only a single
# pending pairing exists per (customer, mitra) tuple at a time. Without a
# second test-customer JWT in config.yaml (or a backend helper that emits N
# distinct blasts from different customers), the same script called twice
# either errors on the second confirm or replaces the first invite.
#
# Until either (a) the maestro/config.yaml grows TEST_CUSTOMER_JWT_2 +
# TEST_CUSTOMER_JWT_3 slots tied to distinct seeded customers, or (b) a new
# helper script fans out from multiple customer accounts in one call, this
# multi-invite path is left as a structural placeholder. The
# `_pendingQueue` queue-advance logic is still exercised indirectly by
# ts-mitra-2-04 (single Tolak path).
appId: com.mybestie.mitra
---
- launchApp:
    clearState: false
- takeScreenshot: ts-mitra-2-05-skipped-needs-multi-customer-helper