Phase 1 scaffold: auth for all apps

- 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>

requirement/scracthpad.md

@@ -0,0 +1,50 @@
+# Context for Halo-Bestie Chat App
+
+We are building chat application to help our user to share their feelings (Indonesian called it "curhat") to trainned professional. Our users will be called Customer, while our professional will be called Mitra. This is a paid service with trial period only available when user registering. The service is duration based paid service, configurable through control center. Trial period is configurable via control period, for both duration and availability.
+
+## Phase 1
+
+We build application for both mitra (our professional), and customer for them to communicate via chat. Control center also need to be build to manage communication (re routing, seeing whose live, etc), manage application and managing features. It should provide following functionality:
+
+1. Customer can do self register or go as anonymous. But only registered user that never do any transaction can have trial period
+2. Anonymity of the user can be enabled or disabled through control center
+3. When the anonymity is set to disable, anonymous user will be forced to register by either linking to their social login or through phone number OTP
+4. Customer registration can be done through mobile number with OTP or social login.
+5. Mitra is a user that registered through control center. They wont be able to do self register
+6. Mitra primary identification is phone number and logged on through OTP
+7. Note that Mitra and Customer can have same number. Because mitra is also human and need to vent as well.
+8. Control center user is managed by control center admin
+9. Mitra on boarding flow, is not yet covered in app. So it is a matter of creating Mitra's data, and set it to active or inactive
+10. Curhat session is a service that will be bound by time
+11. The timing is prepaid, that is sold per x minute based on configuration in control center
+12. 
+
+### Session Booking Flow
+
+1. Customer click CTA for mulai curhat
+2. System will look for available Mitra, and blast them that there is Customer waiting
+3. When one of mitra confirm, system will pair Mitra with Customer. Only one Mitra can be paired with Customer
+4. Check for trial eligibility
+   1. If allowed for trial, system will go for next process
+   2. If not then:
+      1. system will trigger package selection for payment
+      2. Customer will select package, and do CTA for payment
+      3. Once payment confirmed, system will go for next process
+5. Curhat session started. Timing must be done in back end
+6. When session is over (package time is over) there are 3 cases:
+   1. Customer want to extend, and mitra is confirmed the extension:
+      1. User will be triggered for another package selection and payment
+   2. Customer want to extend, but Mitra is rejecting:
+        * System will trigger session ending
+    3. Customer decide to end the session, system will trigger session ending
+7. Session ending will request both Mitra and Customer closing message. This message will be stored as closing message from both
+
+
+
+## Tech Stack
+- mitra app -> flutter for both ios and android
+- client_app -> flutter for both ios and android
+- backend -> fastify
+- payment gateway -> xendit
+- auth -> firebase auth
+- database -> postgresql