Files

Ramadhan Sjamsani fbc94daac7 Mitra Bestie §1–§3: shell + Undangan + popup + chat polish

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>

2026-05-21 11:14:30 +08:00

flows

Mitra Bestie §1–§3: shell + Undangan + popup + chat polish

2026-05-21 11:14:30 +08:00

scripts

Mitra Bestie §1–§3: shell + Undangan + popup + chat polish

2026-05-21 11:14:30 +08:00

config.yaml

App ID + launcher icon rename: halobestie.* → mybestie

2026-05-21 11:13:47 +08:00

README.md

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

2026-05-03 23:02:49 +08:00

README.md

mitra_app Maestro flows

End-to-end UI automation for the mitra Flutter app using Maestro. 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 — 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

maestro test mitra_app/.maestro/flows/01_smoke.yaml

# all flows
maestro test mitra_app/.maestro/flows/

If multiple devices are attached:

adb devices
maestro --device emulator-5554 test mitra_app/.maestro/flows/01_smoke.yaml

Per-machine overrides

Override config.yaml values at runtime:

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:

Mitra app is on screen via Maestro on the only connected device
runScript: ../scripts/customer_blast_now.sh creates + confirms a payment_session and fires a chat request as a "fake" customer
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/.

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 — same pattern.

Troubleshooting

See client_app/.maestro/README.md — same checklist applies.