Ramadhan Sjamsani
fbc94daac7
Brings the mitra app to figma-bestie parity for Home (§1), Undangan
inbox with Curhat Baru + Perpanjang tabs (§2), and the incoming-popup
+ active-chat flow (§3). Home now lives inside a StatefulShellRoute
with BestieTabBar so Profil + Undangan + Home share one shell.
- Shell: features/shell/ (StatefulShellRoute, BestieTabBar, 3 branches)
- Undangan: features/undangan/ — Curhat Baru reads
chatRequestProvider.pendingInvites; row Terima delegates accept to
the notifier and ChatRequestOverlay owns nav (no double-push).
Perpanjang tab stubbed (empty state) until backend exposes
pendingExtensionsProvider.
- Profil: features/profile/ — Bestie-styled stub
- Home: refactored to body-only (shell owns chrome)
- Popup: chat_request_overlay + chat_request_notifier updated to
serve the list rows, not just the modal
- Chat: mitra_chat_screen polish
- Theme: accentAmber tokens for the Perpanjang tab + halo_orb widget
(loading spinner used by undangan list states)
- Login: replace broken GoRouterState location guard with
_expectOtpPush flag — was stacking duplicate /otp pages on OTP
resend (see project-otp-nav-bug-fixed-2026-05-21)
Maestro:
- 17 new flows under .maestro/flows/ts-mitra-{1,2,3}-* covering home
online/offline variants, undangan empty/populated/tolak states,
popup curhat-baru → accept → chat → ended banner, plus popup
dismiss/expire/cancelled edge cases
- 4 new §A OTP flows (07/08/09/10) for invalid/mismatch/expired/cooldown
- Helper scripts: force_mitra_online/offline, force_pairing_timeout,
force_session_expires_at, delete_mitra_status_row,
customer_blast_now (js), customer_cancel_latest_blast
- Backend: POST /internal/_test/delete-mitra-status-row supports the
"fresh mitra with no status row" test setup
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
32 lines
1.5 KiB
YAML
32 lines
1.5 KiB
YAML
# 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
|