2026-07-15-health-report

🏥 Project Health Report (รายงานสุขภาพของโครงการ - 2026-07-15)

Project (โครงการ): SplitDee
Role (บทบาท): Lead AI Engineer & CTO
Date (วันที่): 2026-07-15

---

📈 1. Overall Project Health Status (สถานะสุขภาพภาพรวมของโครงการ)

• Overall Status (สถานะภาพรวม): 🟢 Healthy (Design Phase) | 🟢 แข็งแรงสมบูรณ์ (เฟสการออกแบบ)
• Status Details (รายละเอียดสถานะ): There is currently no production codebase written (both backend and frontend are skeletons), meaning there is no code technical debt. The system architecture, API specifications, and database schemas are fully defined and documented. (ปัจจุบันยังไม่มีโค้ดโปรดักชันเขียนขึ้นมา ทั้งหลังบ้านและหน้าบ้านเป็นเพียงคลาสโครงร่างสเกเลตัน ทำให้ยังไม่มีหนี้สินทางเทคนิคของซอร์สโค้ด โครงสร้างระบบ สเปก API และความสัมพันธ์ฐานข้อมูลได้รับการเขียนระบุไว้ครบถ้วนสมบูรณ์แล้ว)
• Architecture Integrity (ความถูกต้องของสถาปัตยกรรม): 100%. Follows Clean Architecture in both FastAPI and Flutter. Boundary layers are cleanly separated. (100% สอดคล้องตามหลักสถาปัตยกรรมสะอาดทั้งฝั่ง FastAPI และ Flutter โดยมีการแยกขอบเขตเลเยอร์อย่างชัดเจน)

---

❓ 2. Open Questions & Assumptions (ข้อสงสัยและสมมติฐานระบบ)

During our audit and design review, we identified several questions that must be resolved before/during implementation:
จากการตรวจสอบเอกสารการออกแบบ เราได้ระบุคำถามประเด็นสำคัญที่ต้องได้รับการขอยืนยันเพื่อนำไปกำหนดสเปก:

1. AI Slip Verification Service Cost & Vendor (ค่าบริการและเวนเดอร์ระบบตรวจสอบสลิปโอนเงิน):
   • Question (คำถาม): Which bank confirmation API/vendor will be used for validating the Mini-QR data from slips? (e.g., EasySlip, SlipOK, or direct bank partner APIs). (จะใช้บริการระบบ API ธนาคารค่ายใดในการตรวจสอบข้อมูลสลิป เช่น EasySlip, SlipOK หรือ API ตรงจากคู่ค้าธนาคาร)
   • Impact (ผลกระทบ): Affects operational costs and infrastructure setup. (มีผลต่อต้นทุนการดูแลระบบและการเชื่อมต่อเครือข่ายหลังบ้าน)
2. Firebase Cloud Messaging (FCM) vs In-App Local WebSockets (สถาปัตยกรรมการยิงข้อความ):
   • Question (คำถาม): Should we use FCM exclusively for chat message notifications, or build WebSockets/SSE for real-time messaging and FCM only for background push alerts? (ควรใช้ FCM ส่งข้อความแชทตลอดเวลา หรือเขียนโปรโตคอล WebSockets/SSE สื่อสารสดเมื่อเข้าแอป และให้ FCM ทำหน้าที่ส่ง Push Alert ตอนอยู่หลังบ้านเท่านั้น)
   • Impact (ผลกระทบ): WebSockets are faster for active chats, FCM is better for background. (WebSockets ตอบสนองเร็วกว่าในขณะแชทคุย ส่วน FCM ประหยัดพลังงานเมื่ออยู่เบื้องหลัง)
3. Mochi Pet HP/Happiness Deduction Cron Schedule (ความถี่และเกณฑ์การหักพลังชีวิตน้องโมจิ):
   • Question (คำถาม): What are the exact thresholds for Mochi’s HP deduction? (e.g., -10 HP for every 24 hours of delay per user, or group-wide status). (เกณฑ์คำนวณหัก HP น้องโมจิที่ค้างชำระมีสูตรอย่างไร เช่น หัก -10 HP ทุกๆ 24 ชั่วโมงต่อยอดหนี้ของแต่ละคน หรือคำนวณในนามภาพรวมของกลุ่ม)
   • Impact (ผลกระทบ): Direct influence on the gamification balance and user engagement. (มีผลต่อสมดุลเกมน้องโมจิและการมีส่วนร่วมของผู้ใช้งาน)

---

🛠️ 3. Technical Debt List (รายการหนี้สินทางเทคนิค)

Although no code has been written, we identified documentation and design technical debt:
แม้จะยังไม่มีโค้ดโปรดักชัน แต่เราได้ระบุหนี้สินทางเทคนิคในระดับการตั้งค่าและการออกแบบระบบเอกสารไว้ดังนี้:

Tech Debt ID	Category	Description	Severity	Action Plan
TD-DOC-001	Documentation	Duplicate files and overlapping principles (AI_MEMORY.md, PRINCIPLES.md, TEAM_AGREEMENT.md, etc.).	Medium	Consolidation and cleanup during this session.
TD-DOC-002	Naming	Legacy Obsidian links and naming formats in Dashboard.md and README.md.	Low	Update quick links and Obsidian bracket paths.
TD-SCH-001	Database Design	No database indexes specified on bills.group_id and expense_shares.user_id in the initial draft schema.	Medium	Added index strategy to Database_Design.md.
TD-SEC-001	Security	Missing JWT token rotation and blacklisting specifications for logged-out/compromised accounts.	High	Specify JWT blacklist/refresh token pattern in API Design.