❓ Open_Questions.md - Open Questions & Technical Assumptions (รายการคำถามประเด็นสำคัญและข้อตกลงเบื้องต้น)

This document lists the open design decisions, business logic uncertainties, and vendor considerations that must be resolved before freezing all subsystems.
เอกสารฉบับนี้รวบรวมประเด็นการตัดสินใจเชิงการออกแบบ ความไม่แน่นอนของตรรกะธุรกิจ และทางเลือกการจัดหาผู้ให้บริการภายนอกที่ต้องเคลียร์ให้เรียบร้อย


🇹🇭 ภาษาไทย (สำหรับผู้ใช้งาน)

📊 สรุปประเด็นตัดสินใจเชิงวิศวกรรมหลัก

  1. การจัดซื้อบริการแสกนตรวจสอบสลิปโอนเงิน (Slip Verification API Vendor):
    • คำถาม: จะเลือกผู้ให้บริการค่ายใดสำหรับการตรวจยอด Statement สลิปโอนเงินธนาคาร?
    • ตัวเลือก: SlipOK (ยอดนิยมในไทย ราคาเฉลี่ย 0.10 - 0.20 บาท/ครั้ง มีเอกสารเชื่อมต่อดี), EasySlip (ราคาสูสี มีพอร์ตสำรองหลังบ้าน) หรือเขียนดึงคีย์ Open API ของธนาคารโดยตรง (ไม่มีค่าบริการแต่ตั้งค่ายากมาก)
    • ข้อเสนอแนะ CTO: เริ่มงานในรุ่น MVP ด้วยการต่อเชื่อม SlipOK โดยเขียนโค้ดห่อหุ้มหลังเกตเวย์และจำกัดโควต้าแสกนรายวันรายคน ป้องกันงบบานปลาย
  2. โปรโตคอลการทำงานกล่องแชทข้อความแชร์หนี้ (Group Chat Protocol):
    • คำถาม: สถาปัตยกรรมห้องแชทส่งข้อความสดในกลุ่มควรทำผ่าน WebSockets, Server-Sent Events (SSE) หรือยิงผ่าน Firebase Cloud Messaging (FCM) ล้วน?
    • ตัวเลือก: WebSockets (สื่อสารสองทาง เร็วที่สุด ยอดนิยม แต่หลังบ้านต้องประมวลและกินแรมจำลอง Redis มาก), SSE (ส่งข้อมูลทางเดียวจากหลังบ้านมาหน้าจอ เขียนง่ายกว่า), หรือใช้ FCM (จัดทำง่ายสุดแต่ค้างส่งช้าและซิงค์ประวัติยาก)
    • ข้อเสนอแนะ CTO: เลือกเชื่อมโยงผสมผสาน โดยเปิดใช้ WebSockets ดึงแชทสดขณะเพื่อนเปิดแอป และตกหล่นเป็น FCM ส่ง Push Alert แจ้งข่าวตอนอยู่นอกแอป
  3. เกณฑ์คำนวณหักสถิติอารมณ์สัตว์เลี้ยงประจำกลุ่ม (Mochi Health Logic):
    • คำถาม: สูตรทางคณิตศาสตร์ในการลดคะแนน HP ของน้องโมจิเมื่อเพื่อนๆ จ่ายช้าควรมีอัตราทดเท่าไหร่?
    • ตัวเลือก: หักแบบคงที่ -10 HP ทุกๆ 24 ชั่วโมงต่อบิลค้างชำระของกลุ่ม หรือแปรผันตามยอดเงินที่ค้าง หรือแสดงผลแยกส่วนไม่ปนกลุ่มเพื่อป้องกันความขัดแย้งของเพื่อนในชีวิตจริง
    • ข้อเสนอแนะ CTO: ยึดหลักลบ -10 HP ทุกๆ 24 ชั่วโมงต่อยอดบิลค้าง เพื่อจูงใจให้ช่วยเหลือร่วมมือกัน และตั้ง Grace Period ระยะทดเวลาบาดเจ็บทวงเงิน 12 ชั่วโมงก่อนเริ่มหัก HP จริง

🇬🇧 English (For AI Agents)

🚨 Critical Open Decisions

  • 1. Bank Slip Verification API Vendor
    • Question: Which third-party bank verification API provider will be utilized to validate Mini-QR slip payloads?
    • Options:
      1. SlipOK: Popular in Thailand, reasonable cost (approx. 0.10 - 0.20 THB per scan). Good SDK support.
      2. EasySlip: Comparable pricing, offers backup endpoints.
      3. Direct Bank Open APIs (SCB, KBank): Zero cost for developer accounts but requires complex business registration.
    • CTO Recommendation: Start with SlipOK API wrapped inside an adapter repository interface. If costs escalate, transition to a custom bank webhook service.
  • 2. Group Chat Engine Protocol
    • Question: Should we implement real-time chat via WebSockets, Server-Sent Events (SSE), or rely on Firebase Cloud Messaging (FCM) push alerts exclusively?
    • Options:
      1. WebSockets: Full duplex, low latency. Requires persistent connections on the FastAPI backend, increasing Redis caching load.
      2. Server-Sent Events (SSE): Simpler to implement in FastAPI than WebSockets, unidirectional.
      3. Direct FCM: Easiest setup, but delivery can be delayed and message history syncing is harder.
    • CTO Recommendation: Implement WebSockets for active clients, backed by Redis Pub/Sub, and fallback to FCM push alerts for background delivery.
  • 3. Mochi Pet HP/Happiness Deduction Thresholds
    • Question: What is the exact mathematical equation for HP and Happiness deductions on overdue bills?
    • Options:
      1. Linear Penalty: -10 HP for every 24 hours of delay, group-wide penalty.
      2. Proportional Penalty: HP penalty is scaled based on the overdue bill amount.
      3. Individual-Based Penalty: Only show Mochi as sad to the individual debtors.
    • CTO Recommendation: Use Linear Penalty (-10 HP per 24 hours) to encourage cooperative behavior, but enable a “Grace Period” (e.g. 12 hours) before deductions begin.

📝 Documented Assumptions

  1. PromptPay Coverage: Assumes 100% of target users in Thailand have access to mobile banking apps supporting PromptPay QR transfers.
  2. Camera Hardware: Assumes users’ devices have cameras capable of capturing high-resolution photos of slips for OCR scanning.
  3. No Direct Gateway: Assumes SplitDee acts strictly as an expense manager, not processing actual money transfers (users transfer money externally using their mobile banking apps).