ramadhan sjamsani
a7a2a32d27
- Backend: Fastify with two listeners (public + internal), routes, services, DB migration + seed - client_app: Flutter with BLoC, all auth screens (welcome, display name, register, OTP, force-register) - mitra_app: Flutter with BLoC, OTP-only login - control_center: React + Vite, email/password login, mitra/user management, anonymity settings - Docs: phase1 plan, API contract, client app mockup - CLAUDE.md and shared memory for all subprojects Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
963 B
name, description, type
| name | description | type |
|---|---|---|
| Mitra App Context | Stack, purpose, and API conventions for the Halo Bestie mitra Flutter app | project |
Flutter mobile app (iOS + Android) for trained mental health professionals (mitra/partners).
Stack: Flutter, Firebase Auth (firebase_auth + google_sign_in)
Auth: Google Sign-In (native), Apple Sign-In (native), Phone OTP — fully native, no WebView. JWT sent as Authorization: Bearer on every API call.
API: Calls /api/mitra/ and /api/shared/ routes only. Never call /api/client/ or /internal/.
Domain: Mitra = trained mental health professional. Flow: register + credential upload → await control center approval → set availability → accept sessions → chat with client → receive payout.
Important: Mitra accounts require approval from control center before going live. Mitra role must be verified server-side on every relevant request — never rely on client-side role checks.