Cliq Product & Planning Hub

Product + Planning • iOS Vertical Slice • AI Triage

Cliq Product & Planning Hub

ศูนย์รวมสถานะผลิตภัณฑ์ ฟีเจอร์ iOS, AI triage, clinic discovery, booking/queue workflow, architecture, safety, PDPA และ roadmap ของ Cliq

ดูสถานะโปรเจกต์ Knowledge Map 25 ภาพ

97% Overall project progress โดยประมาณ

25 ภาพสรุปโครงสร้างและ decision points

2 Modes Patient + Clinic Staff connected flow

Cliq

⌁

เช็กอาการ ค้นหาคลินิก
จองและรับคิวอย่างเป็นธรรม

⌕ ค้นหาคลินิก อาการ หรือประเภทแพทย์...

AI Triage + Smart Clinic Matching คัดกรองความเร่งด่วนและแนะนำคลินิกตามบริบทผู้ป่วย

⌘

Patient Mode ค้นหา แผนที่ จอง ติดตามนัด และเช็กอินใกล้คลินิก

盾

Clinic Staff Mode ยืนยันนัด รับคนไข้ จัดคิว Walk-in ตาราง และรูปคลินิก

฿

Safety by Design Emergency routing, consent, de-identification และ fair queue rules

✓

Production-connected iOS Application

Patient และ Clinic Staff flow เชื่อม Supabase production โดย PostgreSQL เป็น source of truth สำหรับคลินิก แพทย์ ตาราง รูป การจอง คิว กิจกรรม billing และประวัติการเช็กอาการ; AI Gateway ทำงานผ่าน Firebase Functions

↗

Managed Backend Foundation Deployed

Supabase production project ที่ Singapore ทำงานแล้ว พร้อม schema, Email/Password Auth, custom SMTP บน cliq.care, track ผู้ป่วยและคลินิกแยกกัน, clinic verification, RLS, Storage, Realtime, iOS data adapter, transactional booking/queue RPC, notification/email/error, privacy/TestFlight และ operations/support baseline สำหรับ production soft launch แล้ว

สถานะการดำเนินงาน / Project Status

แยกสถานะการวางแผนออกจากการลงมือพัฒนาจริง เพื่อให้เห็นทันทีว่าอะไรทำแล้ว กำลังทำ หรือยังไม่ได้เริ่ม

Production / Soft Launch Preparation

Patient และ Clinic Staff core flow ผ่าน owner testing บน Supabase production แล้ว: email/LINE authentication ที่แยกบัญชีกัน, mandatory patient profile, clinic opening/verification, profile-change approval, doctor evidence, clinic catalog/media/schedule, booking, proximity check-in, fair queue, reviews, triage persistence, backend-driven billing และ production push notification ใช้ DB เป็น source of truth; Firebase Functions ดูแล AI Gateway, monthly invoice, health monitor, push delivery และ daily data retention พร้อม Crashlytics ฝั่ง iOS. Owner real-device regression smoke สำหรับ LINE lifecycle, account deletion/re-registration, Push deep-link, doctor-assigned booking/queue และ profile editing ผ่านเมื่อ 23 ก.ค. 2026 เหลือ final App Store archive/submission, controlled launch, clinical validation ต่อเนื่อง, formal external legal/privacy approval และ Admin operations modules บางส่วนที่ยังเป็น shell

RC Prep

97%

Overall Cliq Project Progress

อัปเดตล่าสุด: 27 ส.ค. 2026 iOS: Production DB-first • email และ LINE เป็นคนละบัญชีและห้าม linking • LINE ไม่ขอ email และบังคับผู้ป่วยกรอกชื่อ/เบอร์เอง • หน้า Account แสดงและแก้ชื่อ/เบอร์ของบัญชีปัจจุบัน • เข้าใช้แบบผู้ชมต้องสร้างบัญชีก่อนจอง • clinic opening/profile approval รองรับ exact specialty หลายสาขาต่อแพทย์และ derived clinic types • doctor schedule รองรับหลายช่วงเวลา/ความจุ/วันหยุดรายแพทย์ • activity/deep-link/badge sync ใช้ production read state • ไทย/อังกฤษมี key และ format-placeholder parity • Billing Center เป็น backend-driven Release: iOS config ปัจจุบัน 0.1.0 (29), iOS 17, bundle com.yourjarvis.cliq • owner signed real-device regression smoke ของ current baseline ผ่าน 23 ก.ค. 2026 • final release number, archived build และ App Store package/submission ยังเป็นขั้นตอนของ owner AI Gateway: HTTPS health passed • Dr Pom ultra wide 7,884-example input-retrieval clinical teaching set v0.8 deployed • clinical routing + official specialty code mapping aligned with iOS search Database: Production project gormehvuezrienkgmvav เป็น source of truth เดียว • local/remote migration history ตรงกันและ dry-run สะอาดถึง 202607240005 • no mock/demo seed promoted • verification, profile-change approval, doctor evidence, schedule, billing, notification, account deletion, retention/legal hold, LINE/email identity separation และ clinic owner/staff invariants เป็น DB-first Admin PWA: https://admin.cliq.care deployed on Cloudflare Pages • clinic verification, profile-change review, media/doctor evidence preview, billing invoice/slip/payment confirmation และ privacy-safe Notification delivery dashboard ใช้งานกับ production Clinic Web: https://clinic.cliq.care active บน Cloudflare Pages project cliq-clinic • production workflow แยกจาก Android โดยสิ้นเชิง • iOS และ Clinic Web ถูกล็อกไว้ระหว่างทำ Android และไม่มีการแก้ production schema/RPC/RLS เพื่อรองรับ Android Android: native Kotlin + Jetpack Compose สำหรับ Patient และ Clinic ปิด production functional UAT แล้วเมื่อ 27 ส.ค. 2026 โดยใช้ production Supabase/Auth/RPC/Storage/Realtime contract เดียวกับ iOS • ผ่าน signed Release/R8, lint, security preflight, restricted Maps key, LINE OAuth callback, FCM/Crashlytics, 300m geofence และ paired iOS/Android visual review ของทุก app-controlled surface • production journeys ครอบคลุม account lifecycle, booking/cancel/check-in/queue, triage routing, clinic application, schedule, team access, doctor add/edit/remove, billing/payment slip, notification preferences และ account deletion • เหลือ Play release package/store submission, controlled rollout และ password-recovery parity decision ที่ติดข้อจำกัดจาก locked iOS route Notifications: APNs/FCM ผ่าน Firebase project cliq-8a29a ใช้งานจริงบนอุปกรณ์ 2 เครื่อง • Supabase outbox เป็น source of truth • post-commit wake ส่งทันทีและ minute scheduler เป็น retry/fallback • Patient LINE Login ใช้งานกับ Auth แล้ว โดย LINE OA/LIFF ถูกตัดออกจาก product scope Observability: Firebase Crashlytics สำหรับ iOS, five-minute production health monitor และ server-side alerting สำหรับ Auth, Booking, Queue, Storage, Email, AI Gateway และ push delivery โดย redact ข้อมูลส่วนบุคคล อาการ token และ request payload Booking/Queue: production RPC + server-authoritative capacity/check-in/arrival/walk-in/no-show/completion • geofence baseline 300 ม., freshness 2 นาที, accuracy 100 ม., −30/+15 นาที Clinical Safety: Soft-launch baseline + internal clinical boundary review ปิดแล้ว • formal external validation เป็น hardening ก่อน scale ใหญ่ Platform Scope: Patient = iOS + Android • Clinic = iOS + Desktop-first Clinic Web App + Android • ไม่มี Patient PWA/LIFF/LINE OA และไม่มี Clinic PWA requirement • Admin PWA/Hub/Public web แยกต่างหาก

ความหมายของสถานะ

สถานะนี้หมายถึงการลงมือทำจริง ไม่ใช่เพียงมีแนวคิดหรือมีแผนแล้ว

Decision Pendingยังต้องเลือกแนวทางก่อนเริ่มทำ

Selectedตัดสินใจแล้ว แต่ยังไม่ได้หมายความว่าเริ่ม implement

Not Startedยังไม่ได้เริ่ม implement

In Progressกำลังลงมือพัฒนา

Limited Launchเปิดใช้งานจริงแบบจำกัดกลุ่มก่อนขยายวงกว้าง

Doneทำเสร็จตาม scope ที่กำหนด

Blockedติดเงื่อนไขที่ต้องแก้ก่อนทำต่อ

97% หมายถึงความคืบหน้าของ Cliq ทั้งโปรเจกต์

เป็นคะแนนประมาณการแบบถ่วงน้ำหนักจาก Product/UX, iOS, AI/Clinical, Backend/Data/Auth, Security/Operations/Billing, Web/Admin, Android และ Launch โดย core production flow ผ่าน owner testing แล้ว และ Android ปิด production functional UAT ของ Patient/Clinic พร้อม signed Release, external integrations และ visual evidence แล้ว คะแนนนี้ไม่ใช่ release certification: ยังเหลือ App Store/Google Play packaging และ submission, controlled rollout, password-recovery parity decision, Clinic Web owner/role action smoke, clinical false-negative validation ต่อเนื่อง, formal external legal/privacy approval และ Admin PWA modules ที่ยังเป็น placeholder

Product Scope & Requirements

Production Core Validated

ตกผลึกและ owner-test flow คนไข้/คลินิกแล้ว รวม pediatric/pregnancy routing, emergency hospital escalation, clinic opening gate, booking confirmation, proximity check-in, fair queue, profile approval และ billing; AI/clinical routing ยังปรับต่อจาก feedback ของหมอป๋อม

Planning

Architecture & Platform Strategy

Selected Baseline

เลือก SwiftUI iOS-first, Supabase Managed PostgreSQL Singapore + Auth/Storage/Realtime เป็น production core, Firebase Functions เป็น AI Gateway/automation/monitoring และ Firebase Crashlytics สำหรับ iOS โดยตั้งใจแยกหน้าที่ ไม่ใช่การย้ายฐานข้อมูลกลับ Firebase

Planning

Clinic Web App UI Stack

Production Deployed

Clinic Web App ใช้ Vite + React 19 + TypeScript + Tailwind CSS + Framer Motion และออกแบบ desktop-first สำหรับงานประจำวันของคลินิก พร้อม responsive fallback; deploy แยกที่ Cloudflare Pages project cliq-clinic / clinic.cliq.care และไม่ได้กำหนด installable/offline PWA เป็น requirement

Decision

Mobile UI/UX Direction

Implemented Baseline

ใช้ iOS-first, SwiftUI codebase เดียวแต่แยก account track ผู้ป่วย/คลินิก, borderless elevated cards, Liquid Glass capsule headers และ localized Thai/English components เป็น baseline แล้ว

Design Direction

Native App Stack

Selected

เลือก SwiftUI สำหรับสร้าง iOS App ก่อน ใช้ native iOS controls และเพิ่ม Liquid Glass แบบ progressive enhancement บนระบบที่รองรับ แล้วใช้เป็น functional/design reference สำหรับ Desktop-first Clinic Web App และ Android ทั้งสอง track โดย Web App ต้องปรับ interaction ให้เหมาะกับ desktop operations

Decision

iOS App Build Decisions

Owner Tested

SwiftUI, iOS/iPadOS 17, localization, app identity, repository boundary, navigation และ Patient + Clinic Staff vertical slice ผ่าน owner testing แล้ว รวม fresh LINE consent/profile/relaunch, email isolation, account deletion/re-registration, Push open/deep-link, doctor-assigned booking/queue, profile editing และไทย/อังกฤษบนอุปกรณ์จริง ขั้นถัดไปคือ final archived production build และ App Store package ที่ owner จะดำเนินการเอง

Build Gate

iOS Release Readiness

90–94% • Owner-tested baseline

P0/P1 release baseline ผ่าน owner testing แล้ว รวม DB-first booking/queue, email/LINE Auth isolation, mandatory patient profile, account deletion/re-registration, Push deep-link, clinic verification, profile-change approval, doctor evidence, billing, Crashlytics, localization/accessibility และ privacy manifest; owner จะเป็นผู้ทำ final archived build, version/build และ App Store package

Release Gate

Production Readiness

RC prep ready

Production Supabase, migrations through 202607240005, email/LINE Auth separation, SMTP, platform admin, Admin PWA, restore drill, booking/queue, clinic review, verification/profile approval, doctor evidence, billing automation/payment review, Crashlytics, server monitoring, backup/incident/legal/clinical runbooks และ focused owner device smoke พร้อมแล้ว; ยังต้องทำ final archived version/build, App Store package และควบคุม launch จริงก่อนถือว่า release สำเร็จ

Production Gate

Patient Platforms

Native Apps Only

กำหนด scope เป็น iOS และ Android App เท่านั้น ยกเลิก Patient PWA, LIFF และ LINE OA โดยคง Patient LINE Login ที่ใช้งานจริงไว้

Scope Decision

Desktop-first Clinic Web App

Production Shell Verified

เปิดใช้งานที่ clinic.cliq.care แยกใน project cliq-clinic แล้ว ใช้ production Supabase/Auth/RPC ชุดเดียวกับ iOS มี browser/Home Screen/Android manifest icons และ navigation หลักครบ 5 หน้า; ข้อมูลอัปเดตแบบ Realtime-triggered authoritative refresh พร้อม polling สำรองทุก 15 วินาทีและ refresh เมื่อกลับเข้า tab/focus/online เพื่อให้พฤติกรรมเทียบ iOS โดยขั้นถัดไปคือ full owner/role action smoke

Production Web

Cliq Team PWA

Ops + Billing Console

Admin PWA ที่ admin.cliq.care มี overview, clinic verification, profile-change review, logo/building/doctor/evidence preview, monitoring links, backend-driven billing พร้อม invoice/slip/payment confirmation และ Notification delivery dashboard ใช้งานจริง ส่วน general support, queue operations, review moderation, email delivery และ audit center ยังเป็น shell

Product Build

Native Mobile Apps

iOS Live • Android UAT Closed

iOS SwiftUI ยังเป็น source of truth และถูกล็อกไว้; Android native Kotlin + Jetpack Compose สำหรับ Patient และ Clinic เชื่อม production contract เดียวกันและปิด signed production functional UAT เมื่อ 27 ส.ค. 2026 แล้ว พร้อม bilingual behavior, reviewed screenshot parity, signed Release/security gate, Maps, LINE, FCM/Crashlytics และ geofence evidence. ขั้นถัดไปคือ store packaging/submission, controlled rollout และตัดสินใจ password-recovery parity ที่ iOS route ปัจจุบันยังไม่เปิดใช้งาน

Product Build

Backend / API

iOS Connected • Production

iOS เชื่อม Supabase production ผ่าน repository/gateway สำหรับ Auth, snapshot, profile/media/schedule, verification/profile approval, doctor evidence, booking, proximity check-in, arrival, queue, walk-in/no-show, staff team, triage และ billing; Realtime มี schema/publication baseline ส่วน client ใช้ controlled refresh ในหลายหน้าจอ และ automated server monitoring ทำงานทุกห้านาทีแล้ว

Core Platform

Database / Storage

Source of Truth • Production

Production migrations ครอบคลุม identity/clinic/doctor schedule, booking/check-in/queue, verification, profile-change approval, doctor evidence, reviews, staff team, notification, consent/triage, backend-driven billing, monthly invoice, payment slip, observability events, RLS, Realtime, Storage, retention/legal hold และ LINE/email identity separation โดย runtime หลักใช้ PostgreSQL เป็น source of truth; migration ล่าสุดคือ 202607240005

Core Platform

Authentication & Roles

Foundation Implemented

Supabase Email/Password Auth, email confirmation, password recovery และ patient-only LINE Login เชื่อมกับ iOS แล้ว บัญชี LINE กับอีเมลแยก Auth identity กันอย่างเด็ดขาด ปิด Manual Linking, ไม่ขอ LINE email และบังคับกรอกชื่อ/เบอร์ผ่าน verified patient RPC; Resend/Supabase SMTP บน auth.cliq.care, track enrollment ผู้ป่วย/คลินิก, clinic membership แบบเจ้าของหนึ่งคนและพนักงาน, staff invitation และ RLS tenant boundary ใช้งานจริง โดยไม่มีบทบาทผู้ดูแลหรือการสืบทอดเจ้าของอัตโนมัติ

Security

AI Triage

Production-connected Validation

Hybrid Rule-based + GPT-5.4 mini ทำงานผ่าน production AI Gateway, prompt v0.15, red-flag override, de-identification, structured output, semantic teaching-example retrieval และ official specialty mapping; iOS เรียกใช้งานจริงได้ แต่ clinical review/false-negative validation ของหมอป๋อมยังดำเนินต่อ

Clinical & AI

Clinical Validation & QA

In Progress

กำลังทดสอบ AI triage แบบ batch ด้วยเคสจำลอง สร้าง Clinical Review PDF และนำ feedback ของหมอป๋อมกลับมาปรับ priority ของคลินิก สาขา และอนุสาขา

Clinical & AI

Patient LINE Login

Production

Patient LINE Login ใช้งานจริงผ่าน production Supabase custom OAuth2 provider และ LINE channel ที่ Published แล้ว โดยใช้เฉพาะ openid/profile, แยกจากบัญชีอีเมลและผ่าน owner real-device lifecycle smoke; LINE OA, LIFF และ Patient PWA ถูกตัดออกจาก product scope

Integration

Notification

Soft-launch baseline

in-app activity, account email และ APNs/FCM production delivery ใช้งานแล้ว พร้อม track separation, production read state, privacy-safe payload, per-track preference, event-driven wake, durable retry และ delivery dashboard; LINE OA ไม่อยู่ใน scope และ SMS ยังไม่ทำ

Integration

Billing & Payment

Backend-driven Billing Center

iOS render ข้อมูลและ action จาก backend: รอบบิล ยอดประมาณการ verified check-in invoice statement PromptPay QR อัปโหลดสลิป สถานะตรวจสอบ และ paid PDF; Admin PWA ออก invoice ดูหลักฐานและบันทึกชำระได้ พร้อมออก invoice อัตโนมัติหลังสิ้นเดือนเวลา 08:30

Business Model

Security / PDPA Controls

Technical Baseline

มี consent, server-side API key, de-identification, RLS, audit/activity, retention policy 2026-07-22-v1, daily expiry worker, audited scoped legal hold, privacy manifest, incident runbook, Crashlytics และ server alerts ที่ redact PII/symptom/token/payload แล้ว; formal controller/processor และ external privacy/security/legal approval ยังไม่ปิด

Governance

Clinic Soft Launch

Owner tested

ผ่านการทดสอบของ owner แล้ว และล้าง test accounts/clinic aliases สำหรับ retest รอบใหม่แล้ว ขั้นต่อไปคือ soft launch แบบควบคุมจำนวนคลินิกและผู้ใช้จริง พร้อม production safeguards

Operations

00A

ฟีเจอร์ iOS ที่ทำแล้ว / Implemented Product Snapshot

สรุปความสามารถใน iOS + production Supabase/Firebase stack และ Android native workstream ปัจจุบัน อัปเดต 27 ส.ค. 2026; iOS owner testing ของ core flow ผ่านแล้ว, Clinic Web deploy แยก production แล้ว และ Android Kotlin + Jetpack Compose ปิด production functional UAT พร้อม signed Release, visual parity และ external-integration evidence แล้ว โดย iOS/Clinic Web ยังคงถูกล็อกระหว่างงาน Android

AI Symptom Check

Functional UI + Gateway

รับอาการปัจจุบัน อาการพบบ่อย ระยะเวลา กลุ่มผู้ป่วยผู้ใหญ่/เด็ก/ตั้งครรภ์ และเพศ พร้อม consent; แตะตัวเลือกซ้ำเพื่อยกเลิกและล้างข้อมูลได้

Thai / EnglishCommon symptomsPatient context

Clinical Routing & Safety

Clinical Validation

กรองคลินิกเด็กเฉพาะเด็ก แยก pregnancy/sex context จัด primary vs specialist clinic ตามแนวทางหมอป๋อม และเคสฉุกเฉินพาไปโรงพยาบาล/1669 โดยไม่เสนอคลินิกฉุกเฉินแทน ER

Red flags firstEmergency booking blockHospital routing

Clinic Discovery + Maps

Production DB

ค้นหาชื่อ/สาขา/อาการจาก verified clinic catalog, ส่ง specialty filters จาก triage, แสดงสถานะเปิดตาม working days และใช้ตำแหน่ง/ระยะทางกับ Google Maps

Google MapsOpen-now filterProvince + distance

Clinic Identity & Photo

Implemented

Clinic Staff อัปโหลด/เปลี่ยนโลโก้และรูปอาคารได้ โดย approved profile ใน production DB เป็นแหล่งเดียวของชื่อ ที่อยู่ เบอร์โทร ตาราง แพทย์ และ media ที่ patient/admin เห็น

Consistent clinic dataImage fallbackShared components

Booking Experience

Production-connected

เลือกวัน/เวลาจากตารางและ capacity ใน DB, ปิดสล็อตที่ใช้ไม่ได้, ยืนยันก่อนส่ง booking ผ่าน server RPC และติดตามสถานะในหน้าการจอง; Maps/โทรศัพท์/รายละเอียดใช้งานแล้ว

Localized datesCapacity-aware slotsConfirmation dialog

Fair Queue & Proximity Check-in

Rules Modeled

การจองจากบ้านไม่ออกเลขคิว ปุ่มรับคิวปลดล็อกหลังคลินิกยืนยัน และ server ตรวจระยะไม่เกิน 300 เมตร, location freshness 2 นาที, accuracy 100 เมตร และช่วง −30/+15 นาทีจากเวลานัด

Server-authoritativeLocation evidenceFair queue

Arrival Confirmation & No-show

Production-connected

หลังผู้ป่วยเช็กอินและได้เลขคิว ต้องไปถึงคลินิกและแสดงหน้าการจอง Cliq ที่จุดรับคิวภายใน 30 นาที ให้พนักงานยืนยันการมาถึงก่อนเปลี่ยนเป็น in-queue; เกินเวลาจะเป็น No-show

30-minute holdClinic confirmationStaff override

Clinic Staff Operations

Production-connected

แท็บวันนี้ คิว ตาราง กิจกรรม และบัญชีรองรับยืนยันคำจอง ยืนยันการมาถึง No-show จบคิว เพิ่ม Walk-in เรียงคิวจริงก่อนนัดที่ยังไม่เช็กอิน และแยกเลขคิวออกจากเวลาจอง

Queue orderingWalk-inAppointment requests

Operating Hours & Booking Availability

Database-backed

กำหนดวันทำการ หลายช่วงเวลา ความยาวสล็อต capacity ปิดรับจอง และ closure dates ได้ โดย schedule/working days sync ลง production DB และใช้คำนวณสถานะเปิด/สล็อตฝั่งผู้ป่วย

Multiple periodsSpecial closure dates17:00–20:00 default

iOS UI System

Implemented Baseline

ใช้การ์ดขาวไม่มีเส้นขอบและเงาแบบเดียวกับหน้าเช็กอาการ, Liquid Glass capsule header, selected state สีน้ำเงิน, keyboard dismiss toolbar, notification popover และ navigation 5 แท็บต่อ mode

SwiftUILiquid Glass fallbackNo horizontal drift

ขอบเขตสำคัญของ snapshot นี้

ชื่อคลาส MockAppStore ยังเหลือจากช่วง prototype แต่ runtime หลักเชื่อม Supabase และใช้ PostgreSQL เป็น source of truth สำหรับ clinic, booking, queue, activity, schedule และ media แล้ว ส่วนที่ยังเป็น local/optimistic state และ Pilot gaps ถูกแจกแจงใน checklist ถัดไป

00P

iOS Release Readiness Checklist

อัปเดตจากเอกสาร “สรุปตรง ๆ” เทียบกับโค้ด iOS และ Supabase ณ 23 มิ.ย. 2026 — สถานะหมายถึงสิ่งที่ลงมือทำจริง ไม่ใช่เพียงมี schema หรือมีแผน

เส้นทางหลักของผลิตภัณฑ์

ทำแล้ว

ทำแล้ว
เช็กอาการ → แนะนำคลินิก → ค้นหา/กรอง/แผนที่
รองรับกลุ่มผู้ใหญ่ เด็ก ตั้งครรภ์ เพศ red flags และ emergency hospital escalation
ทำแล้ว
รายละเอียดคลินิก โทร นำทาง จอง และยกเลิก
วัน เวลา สล็อตเต็ม สถานะเปิด/ปิด และปุ่ม action เชื่อม flow แล้ว
ทำแล้ว
ยืนยันคำจองและ proximity check-in
คลินิกต้องยืนยันก่อน เช็กอินได้ในระยะ 300 เมตร ช่วง −30/+15 นาที และยืนยันถึงคลินิกภายใน 30 นาที
ทำแล้ว
วันทำการ วันปิด ความจุต่อสล็อต แพทย์ และรูปคลินิก
Clinic Mode ตั้งค่าช่วงเวลา จำนวนเคส แพทย์ โลโก้และรูปอาคารได้ และบันทึกลงฐานข้อมูล

P0 • คิวรายวัน

Release ready

ทำแล้ว
Database แยกคิวด้วย service_date
มี queue_days, เลขคิวรายวัน, unique clinic/date/number และ Walk-in timestamp ใน PostgreSQL
ทำแล้ว
iOS แสดงคิวตามวันอย่างสม่ำเสมอ
QueueEntry มี serviceDate จาก database snapshot แล้ว หน้าวันนี้กรองวันปัจจุบัน พร้อมตัด completed/declined/cancelled/no-show ออกจาก active
ทำแล้ว
แยก วันนี้ / ล่วงหน้า / ประวัติ ครบทุกหน้าคิว
หน้าคิวคลินิกมี scope วันนี้ ล่วงหน้า และประวัติ พร้อม filter กำลังดำเนินการ/เสร็จสิ้น/ทั้งหมด และ empty state

P0 • Persistence และ Source of Truth

Release ready

ทำแล้ว
ย้ายข้อมูลหลักจาก local ไป PostgreSQL
คลินิก แพทย์ ตาราง รูป การจอง คิว กิจกรรม และผล triage มี schema/RPC และ iOS gateway แล้ว
ทำแล้ว
บัญชีจริงและ role boundary
Email/Password Auth, patient/clinic enrollment, clinic membership และ RLS ทำแล้ว
ทำแล้ว
ทุก state ต้องรอดหลังปิด–เปิดแอป
ข้อมูลหลักโหลดกลับจาก database, snapshot cache ใช้เป็น fallback, notification read-state persist ตาม user และ mutation ต้องผ่าน RPC + refresh ก่อนถือว่าสำเร็จ
ทำแล้ว
เครื่องมือ reset/seed สำหรับทดสอบภายในที่ควบคุมสิทธิ์
มี RPC สำหรับ reset/seed คิวรายวัน จำกัดสิทธิ์ตาม clinic membership พร้อมปุ่มใน Clinic Account สำหรับเริ่ม scenario คิวรายวันใหม่เฉพาะ environment ที่อนุญาต

P0 • Booking & Queue Lifecycle

Soft-launch baseline

ทำแล้ว
ขอจอง ยืนยัน ยกเลิก เช็กอิน ยืนยันมาถึง No-show Walk-in และจบคิว
มี UI และ RPC สำหรับเส้นทางหลักเหล่านี้
ทำแล้ว
ป้องกันผู้ป่วยจองซ้ำเวลาเดียวกัน
Database มี unique active appointment ต่อ patient/starts_at
ทำแล้ว
ปฏิเสธคำจองและเรียกคิว
iOS เชื่อม decline_booking และ start_queue_service แล้ว พร้อม popup ยืนยัน และ terminal state ไม่ปนกับคิว active
Soft-launch policy
เสนอเวลาใหม่ เลื่อนนัด เรียกซ้ำ ข้ามคิว และ queue progress
Soft launch ใช้สถานะ requested/confirmed/on_the_way/checked_in/in_queue/serving/completed เป็น queue progress หลัก; การเลื่อนนัดหรือเสนอเวลาใหม่ใช้ cancel + rebook เพื่อลด state ซับซ้อน ส่วนเรียกซ้ำ/ข้ามคิวถูกกันไว้เป็น P1 หลัง soft launch
ทำแล้ว
ผลกระทบเมื่อคลินิกปิดวันที่มีนัดอยู่แล้ว
กติกา soft launch คือวันปิดหยุดรับจองใหม่ แต่นัดเดิมยัง active และระบบส่ง notification ให้ผู้ป่วยที่มีนัดในวันที่ถูกปิด

P0 • Known State Bugs

Release baseline

ทำแล้ว
Home ต้องเลือก active booking ที่ถูกต้อง
หน้าแรกผู้ป่วยเลือก booking ที่ยัง active จริงแทน bookings.first และตัด completed/declined/cancelled/no-show ออกจากการ์ดนัดหมาย
ทำแล้ว
ลบปุ่มสลับ mode ที่ยังค้างในหน้า Account
ถอด switch mode card ออกจากบัญชีผู้ป่วยและบัญชีคลินิกแล้ว เหลือ track separation ผ่าน flow เข้าใช้งาน/สมัครของแต่ละฝั่ง
ทำแล้ว
Account/profile state ต้องไม่พังเมื่อ auth user มีแต่ profile หาย
เพิ่ม database self-healing migration: get_account_state, register_patient_account และ register_clinic_account จะ ensure profile/user identity ก่อนทำงาน
ทำแล้ว
Database mutation ต้องไม่ทำให้ UI ค้างหรือข้อมูลย้อนกลับ
iOS mutation ถูก serialize, optimistic state ต้องรอ RPC + refresh สำเร็จจึงถือว่าสำเร็จ และ rollback ไป snapshot ล่าสุด/แคชเมื่อ refresh ล้มเหลว

P0 • Clinic Verification & Track Separation

Release baseline

ทำแล้ว
แยกการสมัครผู้ป่วยและคลินิกในบัญชีเดียวกัน
ใช้เมลเดียวกันสมัครได้ทั้งสอง track แต่ source of truth แยกกันชัดเจน: patient_full_name/patient_phone สำหรับผู้ป่วย และ clinic_owner_full_name/clinic_owner_phone สำหรับฝั่งคลินิก; iOS และ RPC อ่านค่าตาม track ไม่เอาชื่อ/เบอร์ของอีกฝั่งมาทับกันอีก
ทำแล้ว
คลินิกใหม่ต้องรอการตรวจสอบก่อนเผยแพร่
register_clinic_account สร้างคลินิกใหม่เป็น pending; ผู้ป่วยและ search/discovery เห็นเฉพาะคลินิก verified แต่เจ้าของคลินิกยังเห็นคลินิกตัวเองเพื่อแก้ข้อมูลได้
ทำแล้ว
Admin flow สำหรับอนุมัติ ระงับ และตรวจ ownership
เพิ่ม PWA Admin ที่ admin.cliq.care สำหรับทีม Cliq: ดู queue คลินิก, อนุมัติ, ขอแก้ไข, ไม่ผ่าน หรือระงับ พร้อมบันทึก audit event และแจ้งเตือนคลินิก
ทำแล้ว
คลินิกเห็นสถานะการตรวจใน iOS
หน้าบัญชีคลินิกแสดงสถานะ pending/verified/changes requested/rejected/suspended และ note จากทีม Cliq
ทำแล้ว
เอาปุ่มสลับ mode ออกจาก Account ให้ครบ
ถอดปุ่มสลับจากหน้าบัญชีทั้งสอง track แล้ว ลดความเสี่ยง notification และ state ของผู้ป่วย/คลินิกปนกัน

P0 • Auth, Email & Account Recovery

Release baseline

ทำแล้ว
Email/Password Auth, ยืนยันอีเมล และ session restore
iOS เชื่อม Supabase Auth, Keychain และ cliq://auth/callback แล้ว
ทำแล้ว
ระบบส่งอีเมลสำหรับ Production
ผูกโดเมน cliq.care, ตั้ง auth.cliq.care กับ Resend/Supabase SMTP และรองรับ redirect URL สำหรับ iOS auth callback แล้ว
ทำแล้ว
ลืมรหัสผ่าน ตั้งรหัสใหม่ และกู้บัญชีพื้นฐาน
iOS มีปุ่มลืมรหัสผ่าน ส่ง reset email ผ่าน Supabase, รับ cliq://auth/callback แบบ recovery และเปิดหน้าตั้งรหัสผ่านใหม่ในแอป
ทำแล้ว
เชิญพนักงานและจัดการสิทธิ์คลินิก
เพิ่ม clinic_invitations, clinic_team_events และ RPC สำหรับสร้างคำเชิญด้วยอีเมล/ตอบรับ/ยกเลิกคำเชิญ/ถอนสิทธิ์ พร้อม iOS Clinic Account UI และ RLS tenant boundary; เจ้าของคนเดียวจัดการทีม คำเชิญให้สิทธิ์พนักงานเท่านั้น และไม่มีการโอนความเป็นเจ้าของ; email delivery แยกสำหรับ invitation เป็น P1 หลัง soft launch

P0 • Production Environment & Release Safety

Release baseline

ทำแล้ว
Release configuration
เพิ่ม APP_ENVIRONMENT ลง iOS config/Info.plist แล้ว ค่า default คือ Development และมี environment-specific xcconfig สำหรับ override เมื่อเลือก Supabase project; iOS runtime ใช้ค่านี้ gate dev shortcuts และ internal test tools แล้ว
ทำแล้ว
แยก Development / Production และ seed policy
บันทึกกฎ environment separation: dev project ห้ามใช้ข้อมูลผู้ป่วยจริง, seed/mock ใช้เฉพาะ development และการ promote migration ต้องตรวจได้
ทำแล้ว
Rollback playbook
เพิ่ม docs/rollback-playbook.md ครอบคลุม rollback trigger, iOS build rollback, database rollback และ post-incident review; Git baseline จริงให้ทำตอนตัด release candidate เพื่อไม่รวม secret/untracked ผิดไฟล์
ทำแล้ว
TestFlight build checklist และ Release smoke test
เพิ่ม docs/release-checklist.md สำหรับตรวจ version/build, endpoint, deep link, location permission, media upload, check-in bypass, email และ booking/queue smoke ก่อนส่ง tester

P0 • Regression & Acceptance Tests

Release baseline

ทำแล้ว
อัปเดต test ขั้นพื้นฐานบางส่วน
มี unit tests สำหรับ triage context, schedule และภาษา รวมถึง UI tests ของ account entry
ผ่านแล้ว
Booking/capacity/closure/check-in/queue state suite
เพิ่มและรันผ่าน supabase/tests/database/002_booking_queue_acceptance.test.sql กับ linked Supabase dev project แล้ว ครอบคลุม verified/pending clinic, idempotency, duplicate slot, booking pause, closure, slot full, check-in reason codes, arrival confirmation, walk-in, start/complete/no-show และ queue number uniqueness
ผ่านแล้ว
Database integration และ RLS acceptance suite
SQL suite ผ่าน 26/26, 38/38 และ notification/email 18/18 บน project dfbbzmocdfmgfckragkq; เพิ่ม production-shaped restore smoke 004 ผ่านกับ project gormehvuezrienkgmvav restore clone ครอบคลุม public discovery, snapshot, bucket, booking/check-in/queue/walk-in และ tenant separation
ทำแล้ว
Manual iOS smoke checklist
เพิ่ม docs/regression-acceptance-checklist.md สำหรับ run book ก่อน release candidate; ตามข้อตกลง คุณเป็นคนรัน iOS เอง ส่วน database suite/restore smoke มีหลักฐานล่าสุดใน docs/production-smoke-report-2026-06-28.md

P1 • Clinical Safety

Soft-launch baseline

ทำแล้ว
Adult/Child/Pregnancy, sex, red-flag routing และ specialty mapping
ส่งเข้า AI Gateway และบันทึก triage session ได้ พร้อม Dr Pom ultra wide 7,884-example input-retrieval clinical teaching set v0.8 ที่เทียบอาการกับคอลัมน์ input ทั้ง 7,884 รายการก่อน แล้วใช้ semantic guardrail กัน track สำคัญไม่ให้หลุดหลังเชื่อม database
Soft-launch policy
อายุจริง อายุครรภ์ โรคประจำตัว ยา และแพ้ยาใน UI
ไม่อยู่ใน scope ของ soft launch รอบแรก เพื่อลดภาระฟอร์มและข้อมูลสุขภาพละเอียด; บันทึกไว้เป็น future enhancement หลัง clinical/privacy review
Soft-launch baseline
Clinical validation โดยหมอป๋อม
Soft launch ใช้กรอบ safety แบบไม่วินิจฉัย: red flags ต้องพาไปโรงพยาบาล/1669, non-emergency ใช้ routing คลินิกแบบ conservative และเก็บ full false-negative benchmark เป็น production gate หลัง soft launch
Soft-launch policy
แนบสรุปอาการกับคำจองเมื่อผู้ป่วยยินยอม
เลื่อนเป็นหลัง soft launch เพื่อไม่ส่งต่อข้อมูลสุขภาพเกินจำเป็นให้คลินิก ก่อน consent copy, staff access policy และหน้าคลินิกสำหรับอ่านสรุปจะถูกออกแบบครบ

P1 • Notification, Errors & Email

Soft-launch baseline

ทำแล้ว
In-app notifications แยก patient/clinic
ฐานข้อมูลมี audience แยก track, welcome/booking/queue activity และ iOS mark-read sync กลับ read_at ใน database พร้อม local cache ต่อ user
Production verified
Push notification, activity routing และ deep link
APNs/FCM production delivery ทำงานบนอุปกรณ์จริงแล้ว ใช้ payload ทั่วไปที่ไม่เปิดเผยข้อมูลสุขภาพ; activity แต่ละรายการมี read state และ navigation metadata เพื่อเปิด Bookings, Queue, Today, Account, clinic search หรือ review ตามบริบท พร้อม minute scheduler เป็น durable retry/fallback. LINE/SMS ยังไม่ทำ
Soft-launch baseline
Failure UX
มี database retry gate, snapshot fallback หลังโหลดสำเร็จ, safe copy สำหรับ AI/location/check-in/media/profile/slot race และ iOS ซ่อน error ดิบจาก Supabase ใน auth/database gate สำหรับผู้ใช้จริง
ทำแล้ว
อีเมลยืนยันบัญชีและกู้รหัสผ่าน
ตั้งค่าโดเมน cliq.care, auth.cliq.care และ Resend/Supabase SMTP แล้ว; flow ใน iOS รองรับยืนยันอีเมลและกู้รหัสผ่านผ่าน cliq://auth/callback
ผ่านแล้ว
Database acceptance
เพิ่มและรันผ่าน supabase/tests/database/003_notification_error_email_acceptance.test.sql แล้ว ครอบคลุม notification RLS, audience separation, read_at, content tamper guard และ account enrollment RPC

P1 • Localization & Accessibility

Release baseline

ทำแล้ว
ภาษาไทย/อังกฤษและวันเวลา
Thai/English catalogs มี key และ format-placeholder parity แบบ duplicate-free ครอบคลุม clinic schedule/application/profile, doctor evidence, billing/tax/invoice/PromptPay และ production-facing validation/error UI; official production codes, จังหวัดไทย, Doctor Pom/TMC values และ user-generated text คง canonical payload เดิมและแปลงเฉพาะตอนแสดงผล
Release baseline
Dynamic Type, VoiceOver, contrast และ Reduce Motion
เพิ่ม VoiceOver labels/combined elements ให้ notification, team member, invitation และ team actions; animation หลักที่เป็น cosmetic เคารพ Reduce Motion แล้ว
ทำแล้ว
iPhone จอเล็กและ iPad ทุก orientation
ผู้ใช้ตรวจ visual layout บนเครื่องจริงระหว่างพัฒนาอย่างต่อเนื่องแล้ว จึงถือว่าผ่านสำหรับ release baseline; final release candidate ยังควร smoke test ซ้ำก่อนส่ง TestFlight

P1 • Privacy & TestFlight

Release baseline

ทำแล้ว
Privacy policy และ Terms
เพิ่มหน้า https://cliq.care/privacy และ https://cliq.care/terms โดย framing Cliq เป็น clinic discovery/booking/queue platform ไม่ใช่แอปวินิจฉัยโรค พร้อมอธิบาย symptom check ว่าเป็น routing aid เท่านั้น
ทำแล้ว
PrivacyInfo.xcprivacy และข้อมูลที่ต้อง disclose
เพิ่ม PrivacyInfo.xcprivacy เข้า iOS target แล้ว ระบุ no tracking, no tracking domains และข้อมูลที่ใช้เพื่อ app functionality เช่น account/contact, location, optional symptom input, media และ user id
Release baseline
TestFlight readiness
เพิ่ม privacy/TestFlight policy และ release checklist สำหรับ Privacy Policy URL, beta review notes, test account/signup instructions, App Store Connect privacy answers และ support contact [email protected]
Soft-launch policy
ลบข้อมูลผู้ใช้และถอนความยินยอม
สำหรับ soft launch ให้ติดต่อ [email protected] เพื่อขอลบ/แก้ไขข้อมูลและปิด location permission จาก iOS Settings; self-service deletion flow เป็น improvement หลังเปิดใช้งานจริงระยะแรก

P1 • Operations, Monitoring & Support

Soft-launch baseline

Soft-launch policy
Crash reporting และ server-side alerting
สำหรับ soft launch ใช้ manual monitoring ผ่าน Supabase, Firebase Functions, Cloudflare Pages และ Resend dashboard เป็น baseline; Sentry/Crashlytics และ alert automation เป็น production hardening หลังเห็น volume จริง
ทำแล้ว
Audit log และ incident review
ฐานข้อมูลมี audit/activity สำหรับ clinic verification, team actions, booking และ queue lifecycle แล้ว พร้อม runbook ให้ทีมตรวจ incident จาก Supabase/Admin PWA ก่อนทำ dashboard เต็ม
Soft-launch baseline
Backup, restore drill และแผน downtime
เพิ่ม monitoring/backup checklist ระบุ daily checks, pre-release checks, backup/restore drill, downtime plan และข้อจำกัดว่า Free tier เหมาะกับ small soft launch ไม่ใช่ production volume ใหญ่
ทำแล้ว
ช่องทาง Feedback และคู่มือ Support
เพิ่ม https://cliq.care/support, support email [email protected], severity levels, incident workflow และ template สำหรับรับปัญหาแล้ว

สถานะ Release gate: P0/P1 release baseline ปิดครบแล้ว

พร้อมเข้าสู่ขั้นเตรียม production release package หลังคุณรัน iOS smoke บนเครื่องจริงแล้ว โดย verified restore drill, manual operations cadence, legal/PDPA sanity checklist และ clinical boundary review ผ่านแล้ว; อย่างไรก็ตามยังไม่ควรเปิดรับผู้ใช้วงกว้างจนกว่าจะผ่าน App Store/TestFlight package, release freeze และ final production smoke บน build ที่จะส่งจริง

00R

Production Readiness Checklist

Pilot และ production real-flow smoke ผ่านแล้วตาม owner testing; รายการนี้คือ gate สุดท้ายก่อนเปิดใช้งานจริงแบบควบคุม โดยแยกสิ่งที่ทำแล้วในระบบจริงออกจากสิ่งที่ต้องจัดการด้าน release, operation และ risk

P0 • Production Environment

Real-flow smoke passed

ทำแล้ว
Production environment runbook
เพิ่ม docs/production-environment-runbook.md ระบุ Development / Staging / Production, migration promotion, secrets rule, smoke checklist และ launch scale rule
ทำแล้ว
Production Supabase project แยกจาก dev
สร้าง production project `gormehvuezrienkgmvav` แยกจาก dev `dfbbzmocdfmgfckragkq`, apply production-safe migrations รวม public discovery RPC hardening, ตั้ง Auth/SMTP/Storage/Realtime และไม่ promote seed/mock data
ผ่านแล้ว
Backup/PITR หรือ restore drill
ทำ verified SQL dump restore drill แล้วเมื่อ 28 มิ.ย. 2026 โดย dump production core schemas public/storage/private และ restore เข้าฐาน local PostgreSQL สำเร็จ; owner ตัดสินใจไม่เปิด paid PITR ตอนนี้และยอมรับความเสี่ยงสำหรับ controlled launch โดยต้องใช้ manual/daily backup cadence และ revisit PITR ก่อน scale กว้างหรือมีข้อมูล production ปริมาณมาก
ทำแล้ว
Production client contract
iOS ใช้ production Supabase URL/publishable key เป็น tracked baseline ใน App.xcconfig โดย Secrets.xcconfig เก็บเฉพาะ Maps key; Hub/Admin PWA และ Android contract ใช้ publishable key เท่านั้น พร้อม preflight ปฏิเสธ dev project และ service-role key
ผ่านแล้ว
Production real-flow smoke
Owner ทดสอบคลินิกจริง 1 แห่งครบ: สมัคร/ยืนยันอีเมล/กรอกข้อมูล/อัปโหลดรูป/ตั้งวันเวลา-คิว-แพทย์/approve ผ่าน admin.cliq.care และฝั่งคนไข้ค้นหาเจอเฉพาะหลัง verified แล้ว

P0 • App Store / Release Package

RC prep ready

ทำแล้ว
Submission notes
เพิ่ม docs/app-store-production-submission.md พร้อม positioning, review notes, URLs, metadata checklist, release note draft และถ้อยคำว่าไม่ใช่แอปวินิจฉัยโรค
ทำแล้ว
Public pages
Privacy, Terms และ Support URL live บน cliq.care แล้ว โดยใช้ production/soft-launch wording
ทำแล้ว
Release candidate freeze policy
เพิ่ม docs/release-candidate-freeze.md พร้อมกติกา freeze, RC notes template, preflight command และ backup command สำหรับงาน risky production change
ผ่านแล้ว
Release candidate repo preflight
รัน AI Gateway tests และ iOS Debug build ผ่าน; production Supabase smoke, admin billing/verification hardening และ clinic verification/account UI build ผ่านแล้ว เหลือ archived production build smoke ก่อนส่ง App Store
ต้องทำใน App Store Connect
Metadata, screenshots, privacy answers และ build upload
ต้องใช้ Apple Developer/App Store Connect และ iOS project จริงในการอัปโหลด build, กรอก privacy answers, screenshot และ review notes
ต้องทำก่อนส่งจริง
ใส่ version/build จริง และ final production build smoke
หยุดเพิ่มฟีเจอร์ใหม่, ตัด release candidate, archive/build ตัวที่จะส่งจริง แล้ว owner รัน smoke สั้น ๆ บนเครื่องจริงอีกครั้งก่อนส่งขึ้น App Store

P0 • Security, Privacy & Clinical Boundary

Internal sanity baseline

ทำแล้ว
Clinic booking platform framing
Public terms/privacy และ App Store notes ระบุชัดว่า Cliq เป็น clinic discovery/booking/queue platform ไม่ใช่ medical diagnosis หรือ emergency service
ทำแล้ว
RLS, tenant boundary และ clinic verification gate
Supabase migrations มี RLS, clinic membership, track separation และ verified clinic visibility gate แล้ว
ทำแล้ว
Legal/PDPA sanity check
เพิ่ม docs/legal-pdpa-sanity-check.md เพื่อย้ำ public pages, data processor awareness, support/deletion channel, no auto billing และบทบาทของ Cliq เป็น clinic discovery/booking/queue platform ไม่ใช่แอปวินิจฉัยโรค
ทำแล้ว
Clinical boundary review
เพิ่ม docs/clinical-boundary-review.md ระบุ boundary ว่า symptom check เป็น routing aid เท่านั้น มี red-flag/hospital escalation, child/pregnancy/context routing และ review cadence หลังเปิดใช้งานจริง

P0 • Operations & Monitoring

Manual cadence established

ทำแล้ว
Support page, runbook และ feedback template
มี https://cliq.care/support, support runbook, feedback template และ support email [email protected]
ทำแล้ว
Monitoring/backup checklist
เพิ่ม monitoring/backup checklist และโยงเข้ากับ release checklist แล้ว
ทำแล้ว
Manual production monitoring cadence
เพิ่ม docs/production-operations-cadence.md ให้ owner เช็ก Supabase, Resend, Cloudflare, Firebase/AI Gateway, support inbox, booking/queue health และ verification gate ทุก active production day
ทำแล้ว
Runnable health check และ backup helper
เพิ่ม scripts/production_health_check.sh, scripts/production_backup.sh และ scripts/release_candidate_preflight.sh เพื่อเช็ก public endpoints, SQL go-live checks เมื่อมี DATABASE_URL, AI Gateway tests/build และ iOS production preflight
ทำแล้ว
Production ops playbook
เพิ่ม docs/production-ops-playbook.md เป็นคู่มือสั้นสำหรับ daily start, risky production work, incident triage, pause trigger และ post-incident closeout
ทำแล้ว
Daily operator และ escalation owner
กำหนด owner/operator เป็น launch/support/rollback owner จนกว่าจะ delegate พร้อม pause/rollback trigger และ incident log ที่ docs/production-incident-log.md
หลังเริ่มมี volume
Crash/error reporting automation
เพิ่ม Sentry หรือ Crashlytics และ server-side alerting สำหรับ Auth, Booking, Queue, Storage, Email และ AI Gateway เป็น production hardening ถัดไป

P1 • Business Operations

Post soft-launch

เปิด baseline แล้ว
Billing/payment
ออก invoice manual/อัตโนมัติและรับหลักฐาน PromptPay ได้แล้ว แต่ยังไม่มี automatic charging, payment gateway, dispute UI หรือ tax automation เต็มรูปแบบ
ทำแล้ว
Production push delivery
APNs/FCM, permission, device registration, per-track preference, event-driven wake, scheduled retry, delivery tracking และ Admin monitoring ใช้งานแล้ว; LINE/SMS ยังไม่อยู่ใน scope
หลัง soft launch
Admin support console เต็มรูปแบบ
Admin PWA ตอนนี้รองรับ clinic verification; support console สำหรับ incident/user lookup/billing เป็นงานถัดไป

สถานะ Production gate: core production flow ผ่านแล้ว พร้อมเข้าสู่ release freeze

Supabase production project, migrations, Auth redirect, Resend SMTP, platform admin, Admin PWA production deploy, iOS production preflight, verified restore drill, go-live checks, production-shaped database smoke, first real clinic smoke, booking lifecycle, email, admin action, review, persistence/reinstall smoke, manual/daily backup cadence, monitoring/support owner, incident log, legal/PDPA sanity check และ clinical boundary review ผ่านแล้ว ขั้นถัดไปเหลือ release freeze, App Store Connect/build upload และ final production smoke บน build ที่จะส่งจริง

Production Checklist Production Smoke Report Environment Runbook Launch Day Checklist RC Freeze Ops Playbook App Store Notes Support Runbook Operations Cadence Incident Log Legal/PDPA Sanity Data Retention Policy Clinical Boundary

00B

จากแอปเวอร์ชันแรกถึงวันนี้ / Product Evolution

บันทึกลำดับการพัฒนาแบบสะสม ไม่ใช่เฉพาะงานรอบล่าสุด เพื่อให้เห็นว่า product และกติกาการใช้งานค่อย ๆ ตกผลึกอย่างไร

Product Foundation

Established

กำหนดบทบาท Patient, Clinic Staff และ Cliq Team
วาง Knowledge Map, business model, safety, PDPA และ architecture candidates
เลือก iOS-first, SwiftUI codebase เดียวแต่แยก account track ผู้ป่วย/คลินิก และ Clinic Web App stack แบบ desktop-first

Native iOS Foundation

Implemented

สร้าง app identity, launch/onboarding และโครง navigation แยกสอง mode
รองรับ iPhone/iPad, iOS 17+, ภาษาไทย/อังกฤษ และสลับภาษาในแอป
วาง feature-first architecture, design system และ shared MockAppStore

Patient + Clinic Vertical Slice

Implemented

Patient: หน้าหลัก คลินิก การจอง กิจกรรม และบัญชี
Clinic: วันนี้ คิว ตาราง กิจกรรม และบัญชี
สถานะการจองและคิวเปลี่ยนข้ามสอง mode ด้วยข้อมูล mock ชุดเดียวกัน

AI Triage & Smarter Matching

Validating

เพิ่มอาการ ระยะเวลา กลุ่มผู้ใหญ่/เด็ก/ตั้งครรภ์ เพศ และ consent
เชื่อม red-flag rules + GPT structured output และ specialty catalog
กรองเด็กเฉพาะคลินิกเด็ก จัดสาขาตามบริบท และแยกฉุกเฉินไปโรงพยาบาล/1669

Discovery, Maps & Clinic Identity

Implemented

ค้นหา/กรองคลินิกจากหน้าแรกและผล AI พร้อม active filters ในหน้าถัดไป
ปรับกล้อง map ให้เห็นผู้ใช้และหมุดที่กรองร่วมกัน พร้อม keyboard dismiss
ทำ Maps/โทร/รายละเอียดให้ใช้งานได้ และให้คลินิกจัดการรูปพร้อม default fallback

Booking, Fair Queue & UI Refinement

Owner Tested

เพิ่ม popup ยืนยัน จองแล้ว jump ไปหน้าการจอง และรอคลินิกยืนยันก่อนรับคิว
แยก appointment ออกจาก queue ใช้ proximity/time gate และ clinic arrival confirmation 30 นาที
ปรับการ์ดไร้เส้นขอบมีเงา, Liquid Glass headers, selection/toggle/clear, notification popover และ adaptive layout ไม่เลื่อนซ้ายขวา

iOS Release Hardening

Passed

แก้ daily queue model, local persistence และ booking/queue lifecycle ให้ครบ
อัปเดต test suite พร้อม acceptance cases ของ Patient และ Clinic Staff
ปิด P0/P1 release baseline และผ่าน owner testing แล้ว; ถัดไปคือ production environment, App Store package และ soft launch

ภาพรวมโปรเจกต์ / Project Overview

Cliq คือ healthcare platform สำหรับช่วยให้คนไข้ต่างจังหวัดเข้าถึงคลินิกและแพทย์ที่เหมาะกับอาการได้ง่ายขึ้น

ประสบการณ์คนไข้

Production-connected iOS

เช็กอาการพร้อมบริบทผู้ใหญ่/เด็ก/ตั้งครรภ์ ค้นหาคลินิกและแผนที่ จองเวลานัด ติดตามสถานะ รับคิวเมื่ออยู่ใกล้คลินิก และแสดงหลักฐานการจองเมื่อมาถึง

ใช้ฟรี เริ่มใช้ง่าย ต่างจังหวัด

ประสบการณ์คลินิก

Production-connected iOS

ดูและยืนยันคำจอง ยืนยันการมาถึง จัดคิวจริง/No-show/Walk-in ดูตาราง กิจกรรม บัญชี verification/profile approval และ backend-driven invoice/payment flow

Clinic-funded Queue operations Notifications

ทีม Cliq และ Core Platform

Core Admin Live

ทีม Cliq อนุมัติคลินิก/การแก้โปรไฟล์ ตรวจหลักฐานแพทย์ ออก invoice ตรวจสลิป และติดตาม production health ได้แล้ว; support/queue/review/notification/audit console เต็มรูปแบบยังไม่เปิด

Shared backend Admin oversight Auditability

บทบาทที่ตกผลึกแล้ว

หมอป๋อมดูแล clinical direction, validate AI triage, พูดคุยกับคลินิก และ onboard แพทย์/คลินิก ส่วน technical, product และ architecture กำลังพัฒนา connected product และวางรากฐานก่อน soft launch จริง

กลุ่มผู้ใช้ / User Groups

ผู้ใช้หลัก 3 กลุ่มมีเป้าหมายต่างกัน โดย Patient/Clinic Staff ใช้ production-connected iOS และทีม Cliq มี core Admin PWA แล้ว แต่ operations modules บางส่วนยังเป็น shell

1. คนไข้

iOS Live • Android UAT Closed

เป้าหมาย: ไปพบคลินิกหรือแพทย์ที่เหมาะกับอาการ โดยไม่เสียเวลาเดินทางเปล่า

Pain point: ไม่รู้ควรพบแพทย์สาขาใด คลินิกเปิดไหม หรือคิวเหลือไหม
Platforms: iOS App, Android App — ไม่มี Patient PWA, LIFF หรือ LINE OA
Features: symptom input, clinic discovery, booking, queue, notification, arrival, check-in

2. คลินิก

iOS Production-connected

เป้าหมาย: รับคนไข้ใหม่และจัดการ booking, arrival, check-in และคิวได้อย่างเป็นระบบ

Pain point: โทรถามซ้ำ คิวไม่ชัดเจน ตารางเปลี่ยน และไม่รู้ล่วงหน้าว่าคนไข้กำลังมา
Platforms: Desktop-first Clinic Web App, Android App, iOS App
Features: dashboard, notification, queue, schedule, walk-in, invoice, staff permissions

3. ทีม Cliq

Admin Deployed

เป้าหมาย: ดูแลระบบ สนับสนุนผู้ใช้ และตรวจสอบเหตุการณ์สำคัญได้จากหลังบ้านเดียว

Pain point: ต้องเห็นภาพรวมหลายคลินิกโดยไม่ละเมิดขอบเขตข้อมูล
Platform: PWA แบบ responsive dashboard
Features: verification, profile-change/evidence review, billing invoice/slip/payment, monitoring links และ Notification delivery dashboard ใช้งานจริง; general support, booking/queue operations, review moderation, email delivery และ audit/incident ยังเป็น shell

แผนผังแพลตฟอร์ม / Platform Mapping

SwiftUI + Supabase production เป็น mobile/data baseline, Patient LINE Login ใช้งานจริง, Firebase Functions/Crashlytics ดูแล AI/automation/monitoring/push delivery และ Cloudflare Pages แยกสี่เว็บ; Patient ใช้ iOS/Android เท่านั้น ส่วน Clinic มี Desktop-first Web App เป็น customer web surface แยกที่ clinic.cliq.care

PAT

คนไข้

iOS Production-connected

Android App iOS App

ใช้ iOS App ที่สร้างด้วย SwiftUI เป็น mobile reference หลัก; Patient Android เป็น native Kotlin + Jetpack Compose บน production contract เดียวกันและผ่าน signed production journeys ของ Auth/LINE, triage, booking, geofence/check-in, activity, profile และ account lifecycle แล้ว ไม่มี Patient PWA, LIFF หรือ LINE OA

CLN

คลินิก

iOS + Web Live • Android UAT Closed

Desktop-first Web App Android App iOS App

ใช้ iOS App เดียวกับคนไข้ แล้วแสดง Clinic Staff, Clinic Owner หรือ Doctor Mode ตาม role; Clinic Web App เป็น desktop operations ที่ deploy แยกอยู่แล้ว และ Android native Kotlin + Jetpack Compose ผ่าน production UAT ของ application, queue, schedule, team, doctor profile, billing และ account lifecycle โดยไม่เปลี่ยน backend contract

OPS

ทีม Cliq

Planned

PWA Mobile PWA Desktop Dashboard

ทีม Cliq ยังไม่จำเป็นต้องมี native app ในช่วงแรก ใช้ responsive PWA สำหรับ support, operations, billing และ audit

CORE

Cliq Core Platform หลายหน้าบ้านเชื่อมผ่าน backend/API เดียว ใช้กฎธุรกิจและข้อมูลกลางร่วมกัน พร้อม security boundary ตาม role และคลินิก

Technology Pending

03A

Mobile UI/UX Direction: iOS-first

เลือก SwiftUI เพื่อสร้าง iOS App เป็น functional/design reference ก่อน แล้วนำ workflow ไปออกแบบใหม่ให้เหมาะกับ Desktop-first Clinic Web App จากนั้นจึงถ่ายทอดไป Android ทั้งสอง track

One Cliq App Experience

คนไข้และคลินิกใช้ iOS App เดียวกัน หลัง login ระบบแสดง mode ตาม role จากนั้น Clinic Web App รองรับงานคลินิกแบบ desktop-first และ Android รองรับทั้งสอง track โดยไม่มี Patient LIFF/PWA หรือ Clinic PWA requirement

Direction Selected

iOS-first Mobile ExperienceiOS App เป็น design reference และ source ของ interaction pattern หลัก

SwiftUI Native Stackใช้ native iOS controls เป็นฐาน และเพิ่ม Liquid Glass เมื่อระบบรองรับ

One App, Role-based Modesแอปเดียวรองรับ Patient, Clinic Staff, Clinic Owner และ Doctor Mode

Platform Build OrderiOS baseline → Desktop-first Clinic Web App → Android สำหรับ Patient + Clinic

Stack & Design Source

Selected

เลือก native stack และลำดับ platformแล้ว พร้อม implement design source หลักใน SwiftUI ทั้ง Patient และ Clinic Staff Mode แล้ว

Selected Native StackSwiftUI สำหรับ iOS App; Liquid Glass ใช้บน iOS/iPadOS 26+ พร้อม fallback สำหรับระบบเก่า

Implemented Clinic Web StackVite + React 19 + TypeScript + Tailwind CSS + Framer Motion

Design Source of TruthSwiftUI iOS App + Figma/iOS-first design system สำหรับ component, spacing, motion และ interaction patterns

Platform SequenceiOS App → Desktop-first Clinic Web App → Android native implementation สำหรับ Patient + Clinic

Desktop-first Clinic Web Appใช้ dashboard layout และ interaction ที่เหมาะกับงานคลินิกบน desktop พร้อม responsive fallback โดยรักษา design language เดียวกับ mobile app

Mobile Design Rules

Selected

กติกากลางสำหรับทุก mobile view โดยต่างกันได้เฉพาะ native capability ของแต่ละ device

Bottom tab navigation

Large title

Borderless elevated cards

iOS-like sheet / modal

Rounded button

Soft shadow

Status badge

Pull to refresh

Notification center

Swipe action เมื่อเหมาะสม

Role-based App Structure

Selected

ใช้แอปเดียว แล้วปรับ navigation, dashboard และสิทธิ์ตาม role หลัง login

Patient Mode

Clinic Staff Mode

Clinic Owner Mode

Doctor Mode

Allowed Platform Differences

Principle

หน้าตาและ workflow หลักต้องเหมือนกัน ต่างได้เฉพาะ capability ที่เกิดจาก platform หรืออุปกรณ์

Push notification

Camera

Biometric

Haptic feedback

Technology decisions ที่ยัง Pending หลัง production core Android Native StackPatient Login ChannelPush ChannelAnalyticsPayment GatewayLong-term Web Architecture

03B

iOS App Decisions & Current Baseline

บันทึกเส้นทางจาก connected-ready prototype มาสู่ production-connected iOS และแยก decision ที่ยังเหลือก่อน scale

เส้นทางปัจจุบัน: Production-connected iOS App

เริ่มจาก connected-ready UI และย้าย core runtime ไป Supabase production แล้ว โดยคง repository boundary และชื่อ `MockAppStore` แบบ legacy; Auth, clinic, booking, queue, verification, billing และ triage persistence ใช้ backend จริง

Core Connected

UI Prototype • Historicalช่วงแรกใช้ทดสอบ visual language และ interaction

Connected-ready • Historicalสร้าง repository/service boundary ก่อนเชื่อมข้อมูลจริง

Production-connected • CurrentSupabase production เป็น source of truth และ Firebase Functions/Crashlytics ดูแล AI, automation และ observability

Build decisions ที่เลือกและใช้แล้ว

Implemented

รายการเหล่านี้เป็น baseline ของ project structure, screen scope และ production integration ปัจจุบัน

Native App Stack

สร้าง iOS App ด้วย SwiftUI ก่อน ใช้ native controls และ progressive Liquid Glass เป็น reference จากนั้นทำ Desktop-first Clinic Web App และ Android native ทั้งสอง track

SwiftUI • SelectedClinic Web Stack • SelectedKotlin + Jetpack Compose • Selected + Implemented

Selected

ระดับการเริ่มพัฒนา

วางโครง SwiftUI app ให้พร้อมเชื่อม API ภายหลัง โดยช่วงแรกใช้ mock data และไม่เก็บข้อมูลจริง

Connected-ready UI App + Mock Data • SelectedBackend Integration • Later

Selected

Role แรกที่จะทำ

สร้าง Patient Mode และ Clinic Staff Mode ให้ทำงานต่อเนื่องกันเป็น vertical slice แรก

Patient + Clinic Staff Vertical Slice • SelectedClinic Owner / Doctor • Later

Selected

Flow แรกที่จะสร้าง

ทำ UI flow ให้ครบทั้งสองฝั่งด้วย mock data: บอกอาการ/ค้นหาคลินิก → จอง → คลินิกรับ booking → เดินทาง → arrival/check-in → queue → จบคิว รวม cancel/no-show และ walk-in ที่เกี่ยวข้อง

Full Patient + Clinic Staff Connected-ready Flow • SelectedReal Integrations • Later

Selected

Navigation ของแต่ละ Mode

ใช้ iOS-first bottom navigation 5 รายการ แยก Patient Mode และ Clinic Staff Mode พร้อม route/sheet ตาม feature

Navigation Structure v1 • Implemented

Implemented

Supported Devices & Orientation

รองรับ iPhone เฉพาะแนวตั้ง และรองรับ iPad ทั้งแนวตั้งกับแนวนอน โดยผู้ใช้ตรวจ build บนเครื่องจริงผ่าน Xcode

iPhone Portrait • SelectediPad Portrait + Landscape • SelectedReal Device via Xcode • Selected

Selected

Minimum OS Version

กำหนด iOS 17.0 และ iPadOS 17.0 เป็น minimum deployment target โดยใช้ SwiftUI design system เป็น baseline และเปิด native Liquid Glass แบบ progressive enhancement บนระบบที่รองรับ

iOS 17.0 • SelectediPadOS 17.0 • SelectedLiquid Glass on supported OS

Selected

ภาษาและ Localization

รองรับภาษาไทยและอังกฤษตั้งแต่แรกผ่าน String Catalog โดยไม่เขียนข้อความ user-facing ฝังตรงใน View

ไทย + อังกฤษตั้งแต่แรก • SelectedString Catalog

Selected

Distribution รอบแรก

เริ่มทดสอบแบบ local บน iPhone เครื่องจริงผ่าน Xcode ก่อน ส่วน TestFlight ใช้เมื่อพร้อมให้คนอื่นทดสอบ

Local + Real Device via Xcode • SelectedTestFlight • Later

Selected

App Identity

ใช้ชื่อ Cliq ทั้งใต้ไอคอนและบน App Store พร้อม Bundle ID ปัจจุบัน com.yourjarvis.cliq ภายใต้ Apple Developer แบบ Individual

Display Name: CliqApp Store Name: CliqBundle ID: com.yourjarvis.cliqIndividual Developer

Selected

Design Workflow

ใช้ Figma tokens กำหนด visual language และใช้ SwiftUI code prototype ตรวจ interaction, adaptive layout, fallback UI และ Liquid Glass บนอุปกรณ์ที่รองรับ

Hybrid: Figma Tokens + Code Prototype • Selected

Selected

Repository Strategy

เริ่มด้วย repository แยกสำหรับ iOS/mobile app แล้วค่อยพิจารณา monorepo เมื่อ mobile, Clinic Web App, Admin PWA และ backend มี shared contracts ที่ชัดเจน

Separate Mobile Repository • SelectedFuture Monorepo Review

Selected

Technical App Architecture

ใช้ feature-first SwiftUI + shared app store/repository boundary เพื่อให้ flow mock ทำงานร่วมกัน และเตรียมเปลี่ยนเป็น API repositories ภายหลัง

Technical Architecture v1 • Implemented Baseline

Implemented

Navigation Structure v1

Implemented

ใช้ bottom tabs ไม่เกิน 5 รายการต่อ mode และวาง notification center, search, settings หรือ action รองไว้ใน toolbar/sheet เพื่อให้ navigation หลักนิ่งและเหมือน iOS app จริง

Patient Mode • First Vertical Slice

เริ่มจากค้นหาการดูแล จอง และติดตามสถานะของตัวเอง

หน้าหลักค้นหาคลินิกการจองและคิวกิจกรรมโปรไฟล์

Clinic Staff Mode • First Vertical Slice

เน้นงานวันนี้และการจัดการ arrival/check-in/queue ที่ต้องตอบสนองเร็ว

วันนี้คิวตารางกิจกรรมเพิ่มเติม

Clinic Owner Mode • Later

เน้นภาพรวมการดำเนินงาน การตั้งค่า และรายงาน

ภาพรวมคิวตารางรายงานจัดการ

Doctor Mode • Later

เน้นตารางตรวจและบริบทที่จำเป็นต่อการให้บริการ โดยจำกัดข้อมูลตามสิทธิ์

วันนี้คิวของฉันตารางกิจกรรมโปรไฟล์

App Identity

Selected

กำหนดตัวตนของ iOS App แล้ว โดยชื่อกฎหมายส่วนบุคคลของ Apple Developer แบบ Individual จะปรากฏเป็น seller บน App Store

Home-screen Display Name Cliq • Selected
สั้น อ่านง่าย และไม่จำกัดภาพลักษณ์เฉพาะ patient หรือ clinic เพราะเป็นแอปเดียวหลาย role

App Store Name Cliq • Selected
ต้องตรวจ availability ใน App Store Connect ก่อนสร้าง app record

Bundle ID com.yourjarvis.cliq • Current
ตรงกับ Xcode/Firebase/APNs ปัจจุบัน และต้องยืนยันเป็น release identifier ก่อน upload build

ข้อควรระวังเรื่องประเภทแอป

Cliq ไม่ได้เป็น regulated medical device เพียงเพราะช่วยจับคู่คลินิก แต่เมื่อมี symptom input และ AI triage แอปยังจัดการข้อมูล health/medical ที่ละเอียดอ่อน จึงต้องรักษา privacy disclosure, consent และขอบเขตว่า AI ไม่วินิจฉัยโรค

Selected UI Style Reference

โทนหลักน้ำเงินสด น้ำเงินเข้ม ขาว และพื้นหลังเทาอมฟ้า สื่อความน่าเชื่อถือแบบ healthcare-tech

ใช้การ์ดพื้นขาวไร้เส้นขอบกับเงานุ่ม ระยะห่างโปร่ง มุมโค้ง และ capsule header แบบ Liquid Glass; ตัวเลือกที่เลือกใช้พื้นน้ำเงินชัดเจน

ใช้ gradient blue กับ hero, primary CTA และข้อมูลสำคัญ โดยรักษา contrast และ readability

ใช้ SF Symbols, status badge, queue number และข้อมูลที่ scan ได้เร็วเป็นลำดับแรก

SwiftUI native controls เป็นฐานทุกเวอร์ชัน; Liquid Glass ใช้กับ navigation/chrome บน iOS/iPadOS 26+ โดยมี fallback ที่ยังคงความชัดเจนบน 16–25

iPad ปรับเป็น adaptive layout ทั้งแนวตั้งและแนวนอน ไม่เพียงขยายหน้าจอ iPhone

Technical App Architecture v1

Implemented Baseline

ข้อเสนอคือ Feature-first MVVM + Repository + App Environment: เรียบพอสำหรับเริ่มเร็ว แต่แยก boundary ชัดพอให้เปลี่ยน mock data เป็น API ภายหลังโดยไม่รื้อ SwiftUI views

App Shell & Role RouterSwiftUI App เป็น composition root, จัด session/mode และแยก Patient กับ Clinic Staff navigation อย่างชัดเจน

Feature-first Modulesแบ่งตาม feature เช่น Discovery, Triage, Booking, Arrival, Queue และ Clinic Today แทนการกองไฟล์ตามชนิดเทคนิค

State & View Modelsใช้ ObservableObject + @Published เป็น baseline สำหรับ iOS 17 และ @MainActor feature models; หลีกเลี่ยง global singleton และ state ที่แชร์โดยไม่จำเป็น

Typed Navigationใช้ TabView, NavigationStack และ NavigationSplitView บน iPad พร้อม Route/Sheet enum ที่ทดสอบได้

Repository BoundaryViewModel เรียก protocol เช่น ClinicRepository, BookingRepository และ QueueRepository; รอบแรก inject Mock implementations

Concurrency & DIใช้ Swift async/await และ actors เมื่อมี shared mutable state; inject dependency ผ่าน AppEnvironment และ initializer

Design System & Localizationสร้าง Cliq tokens/components จาก Figma, ใช้ SF Symbols และ String Catalog ภาษาไทย/อังกฤษตั้งแต่วันแรก

Testing BaselineSwift Testing สำหรับ domain/view model, XCTest UI smoke tests สำหรับ vertical slice และ SwiftUI previews หลาย device/orientation

Environmentsแยก Mock, Staging และ Production configuration; Connected-ready รอบแรกใช้ Mock เท่านั้นและไม่มีข้อมูลสุขภาพจริง

Repository Layoutแยก mobile repository โดยใช้โฟลเดอร์ App, Core, DesignSystem, Features, Data, Mocks, Resources และ Tests

Production decisions: เลือกแล้วและยังเหลือ

Current Decision Map

core data/auth/backend/maps/AI/billing/monitoring ถูกเลือกและใช้งานแล้ว ส่วน channel, analytics, policy และ platform expansion ยังต้องปิดก่อน scale

Auth & Login • Email selectedEmail/password, confirmation/recovery และ track-separated aliases ใช้งานแล้ว; Phone OTP/LINE/Apple ยังไม่เลือก

Role Membership & Switching • Baseline livepatient/clinic enrollment, clinic membership แบบเจ้าของหนึ่งคนและพนักงาน และ staff invitation ใช้งานแล้ว; multi-clinic policy ยังต้องขยาย

Backend / API • SelectedSupabase generated API + transactional RPC เป็น core backend และ Firebase Functions ดูแล AI/automation/monitoring

Database & Tenant Isolation • SelectedSupabase Managed PostgreSQL + Row Level Security แยก patient และ clinic membership

Booking Model • Productionจองเวลาจากระยะไกลได้ แต่ไม่ออกเลขคิวจนผ่าน server-authoritative proximity check-in หลังคลินิกยืนยัน

Check-in & Arrival • ProductionGPS evidence + time window + clinic physical-arrival confirmation พร้อม staff operation

Realtime & Offline Strategyคิว sync อย่างไรเมื่อ internet ไม่เสถียร และข้อมูลใดต้องใช้ offline ได้

Notification ระยะถัดไปAPNs/FCM production baseline ทำแล้ว; เหลือกำหนด LINE/SMS หรือ fallback channel อื่นเมื่อมีเหตุผลด้านผลิตภัณฑ์และ consent รองรับ

Maps & Location • SelectedGoogle Maps + current location ใช้งานแล้ว พร้อม geofence evidence baseline

AI รุ่นแรก • SelectedHybrid rule + GPT-5.4 mini ผ่าน production gateway; clinical validation ดำเนินต่อ

Security / PDPAConsent, privacy notice, retention, account deletion, controller/processor และ incident response

Monitoring selected / Analytics pendingCrashlytics + five-minute server monitor ใช้งานแล้ว; product analytics ยังไม่เลือกและห้ามส่งข้อมูลสุขภาพละเอียด

Billing Trigger & Payment • Baseline liveverified check-in -> invoice -> PromptPay slip -> admin confirm; gateway/auto charge/dispute/tax automation ภายหลัง

ยังไม่จำเป็นต่อ controlled launch รอบแรก Payment GatewayDesktop-first Clinic Web AppAndroid ImplementationAdvanced AnalyticsHIS / EMR IntegrationFull Admin Ops Suite

แบบฟอร์มสำหรับกลับมาตอบภายหลัง

ตอบเฉพาะข้อที่เลือกแล้วได้ ข้อใดต้องการมอบให้ผมตัดสินใจให้เขียนว่า “ให้ Codex เสนอ”

1. Native stack: SwiftUI • Selected
2. ระดับการเริ่ม: Connected-ready UI App + Mock Data • Selected
3. Role แรก: Patient + Clinic Staff Vertical Slice • Selected
4. Flow แรก: Full Patient + Clinic Staff Connected-ready Flow • Selected
5. Navigation: Navigation Structure v1 • Implemented
6. Device: iPhone Portrait + iPad Portrait/Landscape + Real Device via Xcode • Selected
7. Minimum OS: iOS 17.0 + iPadOS 17.0 • Selected
8. ภาษา: ไทย + อังกฤษผ่าน String Catalog • Selected
9. Distribution: Local + Real Device via Xcode • Selected / TestFlight ภายหลัง
10. Identity: Cliq / Cliq / com.yourjarvis.cliq / Individual Developer • Current
11. Design workflow: Hybrid Figma Tokens + Code Prototype • Selected
12. Repository: Separate Mobile Repository • Selected / Future Monorepo Review
13. Technical architecture: Feature-first SwiftUI + Repository Boundary • Implemented Baseline

App Store & Healthcare Guardrails ที่ต้องเผื่อตั้งแต่ต้น

Medical apps ที่อาจให้ข้อมูลไม่ถูกต้องหรือถูกใช้ประกอบการวินิจฉัย/รักษาจะถูกตรวจละเอียดขึ้น จึงต้องรักษาขอบเขต AI triage ว่าไม่ใช่การวินิจฉัยโรค
เมื่อเก็บข้อมูลจริง ต้องเปิดเผย health/medical data, location และข้อมูลที่ SDK ภายนอกเก็บใน App Privacy Details ให้ตรงกับพฤติกรรมจริง
บัญชี Apple Developer แบบ Individual ใช้ชื่อกฎหมายส่วนบุคคลเป็น seller บน App Store; หากภายหลังต้องการให้ชื่อบริษัทแสดงเป็น seller ต้องใช้บัญชี Organization ที่ผ่านการยืนยัน
Beta สำหรับผู้ทดสอบภายนอกควรใช้ TestFlight และเมื่อส่ง review ระบบ backend/login ที่จำเป็นต้องพร้อมให้ผู้ตรวจเข้าถึงหรือมี demo mode
อ้างอิง: Apple App Review Guidelines, App Privacy Details, Apple Liquid Glass, SwiftUI

ภาพรวมสถาปัตยกรรม / Architecture

ภาพรวมแบบ layer: หลายหน้าบ้าน → backend กลาง → data และ services โดยมี Security / PDPA ครอบทุกชั้น

Frontend / PlatformsSwiftUI iOS App มี Patient + Clinic Staff production flow และถูกล็อกเป็น source of truth; Desktop-first Clinic Web App deploy แยกที่ clinic.cliq.care; Android Kotlin + Jetpack Compose ใช้ repository/service architecture และ production contract เดียวกัน โดยปิด production functional UAT, visual parity, signed Release และ Maps/LINE/FCM integration evidence แล้ว เหลือ store submission และ controlled rollout

iOS + Web Live • Android UAT Closed

Backend / APISupabase RPC สำหรับ booking, queue, proximity check-in, clinic arrival confirmation, capacity, status transition, clinic verification และ billing baseline ถูก deploy เป็น server-authoritative transactions แล้ว; AI Gateway ยังอยู่ Firebase Functions

Production Deployed

Database / StorageSupabase Managed PostgreSQL Singapore production project ทำงานแล้ว พร้อม RLS, PostGIS, Realtime, clinic media Storage, doctor photo storage mapping, audit, restore drill และ retention schema

Production Active

AI LayerHybrid Rule-based + GPT-5.4 mini ผ่าน production Firebase Functions; มี red-flag override, de-identification, structured schema, teaching-example retrieval และ clinical review loop

Production-connected

Notification Layerin-app activity, account email และ APNs/FCM production delivery ใช้งานแล้ว โดย Supabase outbox/read state เป็น source of truth, Firebase เป็นช่องส่ง, post-commit wake ส่งทันที, minute scheduler retry และ Admin แสดง delivery status แบบ privacy-safe; LINE Login เป็น Auth integration แยกต่างหาก, LINE OA ไม่อยู่ใน scope และ SMS ยังไม่ทำ

Production Active

Security / PDPA Layerconsent, role permissions, tenant isolation, RLS, team audit, encryption, retention และ incident response

Foundation

Infrastructure / Hostingruntime, network boundary, secrets, environment guardrail, support URL, monitoring checklist, backup policy และ downtime runbook พร้อมระดับ soft launch แล้ว; production alerting/PITR เป็นขั้นถัดไป

Soft-launch Baseline

Admin & Billingadmin.cliq.care มี platform_admin guard, clinic verification, profile-change approval, evidence preview, invoice/slip/payment review, settings และ Notification delivery dashboard ใช้งานจริง; general support, queue operations, review moderation และ audit dashboard ยังเป็น phase ถัดไป

Core Ops Live

โมดูลหลัก / Core Modules

สถานะโมดูลสะท้อน production-connected iOS + Supabase/Firebase runtime ปัจจุบัน และแยกส่วนที่ยังเป็น UI shell หรือยังรอ policy decision

1. User Module

Auth Foundation

identity, profile, consent, patient/clinic enrollment และ membership แบบเจ้าของหนึ่งคนกับพนักงานเชื่อมกับ Supabase Auth + PostgreSQL แล้ว; social/phone login ยังเป็นงานถัดไป

ทุกกลุ่มEmail/PasswordTeam invitation

2. Clinic Module

Pilot Connected

แสดงข้อมูลคลินิก แพทย์ สาขา เวลาเปิด-ปิด ที่อยู่ ช่องทางติดต่อ รูปคลินิก และรองรับเจ้าของคนเดียวเชิญหรือถอนสิทธิ์พนักงานใน iOS โดยข้อมูลหลักอยู่ใน PostgreSQL และพนักงานไม่สามารถรับช่วงความเป็นเจ้าของอัตโนมัติ

Patient + ClinicDatabase source of truth

3. Schedule / Slot Module

Database-backed

ตารางคลินิก/แพทย์, closure, slot availability และ capacity snapshot อยู่ใน production DB; booking ใช้ server-authoritative RPC/constraints และวันทำการแพทย์ sync กับ schedule

Patient + ClinicServer authority

4. Booking Module

Production RPC

คนไข้เลือกวัน/เวลาและส่งคำจองเข้า production DB; คลินิกยืนยัน/ปฏิเสธ, คนไข้ยกเลิกได้ และ remote appointment จะยังไม่กลายเป็น queue จนผ่าน check-in

Patient + ClinicServer-authoritativeRemote appointment ≠ queue

5. Check-in Module

Rules Modeled

อนุญาตรับคิวเมื่อคลินิกยืนยันแล้ว อยู่ภายใน 300 ม. ตำแหน่งใหม่ไม่เกิน 2 นาที accuracy ไม่เกิน 100 ม. และอยู่ในช่วง −30/+15 นาที; จากนั้นต้องให้คลินิกยืนยันการมาถึงภายใน 30 นาที

GPS + Time WindowStaff confirmationDev bypass เฉพาะ distance/time

6. Queue Module

Server-authoritative

ออกเลขคิวหลัง proximity check-in, จัด fair queue และรองรับ clinic confirmation, arrival, serving, no-show, cancel, walk-in และ completion ผ่าน production RPC/constraints

Fair queuePatient + ClinicProduction DB

7. AI Triage Module

Production-connected Validation

Hybrid Rule-based + GPT-5.4 mini ผ่าน production AI Gateway: semantic teaching-track selection, structured patient context, red-flag override, specialist/subspecialist ordering และ hospital-only emergency escalation

Smart clinic filteringหมอป๋อม validate ต่อเนื่องNot a diagnosis

8. Notification Module

Production Active

activity feed แยก patient/clinic, server-backed read state, actionable routing, Home Screen badge sync, account email และ APNs/FCM production push ใช้งานจริง พร้อม privacy-safe payload, per-track preference, durable outbox, event-driven wake, retry/fallback และ Admin delivery monitoring

In-appAPNs/FCMSupabase outboxFirebase delivery

9. Billing Module

Backend-driven

มี billable event, monthly/manual invoice, PromptPay QR, statement, slip evidence, admin payment review และ paid PDF โดย iOS render contract จาก backend; dispute และ payment gateway พักไว้ภายหลัง

คลินิกทีม CliqProduction DB

10. Admin Module

Ops Console Ready

มี Admin Operations Console สำหรับทีม Cliq ที่ admin.cliq.care: overview, clinic verification, profile-change/evidence review, monitoring cockpit, billing invoice/slip/payment และ privacy-safe Notification delivery dashboard ใช้งานจริง; general support, queue operations, review moderation และ audit/incident ยังเป็น shell

ทีม CliqOperationsadmin.cliq.care

ศูนย์รวมการตัดสินใจ / Decision Center

ศูนย์รวม decision ที่เลือกแล้วและตัวเลือกที่ยัง Pending เพื่อใช้ติดตาม trade-off, launch needs, security และความสามารถของทีม

Clinic Web App UI Stack Decision

Selected

Clinic Web App ใช้ Vite + React 19 + TypeScript + Tailwind CSS + Framer Motion โดยให้ความสำคัญกับคุณภาพ UI และประสิทธิภาพของงานคลินิกบนจอใหญ่ ทั้ง Clinic Web และ Cliq Team Admin ถูก deploy แยก Pages project แล้ว ส่วน Clinic Web App เป็น responsive web application ปกติ ไม่ได้กำหนด installable/offline PWA; Patient PWA ถูกยกเลิก

Priority สูงสุด UI สวยแบบ premium healthcare-tech, professional, app-like บนมือถือ และ dashboard-like บน desktop

Vite + React 19 + TypeScript + Tailwind CSS + Framer Motion

Selected

ใช้เป็น Clinic Web App stack เพราะเหมาะกับ static Cloudflare Pages, desktop dashboard และ workflow งานคลินิก ทำ UI แบบ healthcare SaaS ได้ดี รองรับ design system กลางและ responsive fallback สถานะการพัฒนาจริง: Admin PWA และ Desktop-first Clinic Web App deploy แยก production project แล้ว โดย Clinic Web authenticated shell render navigation หลักครบและยังต้องผ่าน full owner/role action smoke; ไม่มี Patient PWA ใน scope

Nuxt + Tailwind + Nuxt UI

มี ecosystem สำหรับ Vue/Nuxt ที่ครบและสร้าง desktop dashboard/responsive web app คุณภาพสูงได้ดี ควรเทียบ component flexibility และ team fit

SvelteKit + Tailwind

เหมาะกับ UI ที่ลื่นและ bundle กระชับ แต่ต้องประเมิน ecosystem, component library และการดูแลเมื่อระบบขยาย

Flutter Web

ให้ประสบการณ์ app-like และควบคุมหน้าตาได้มาก แต่ต้องเทียบ desktop web behavior, accessibility และ web ecosystem

React + Vite + Tailwind

ยืดหยุ่นและสร้าง responsive SPA ได้ตรงไปตรงมา แต่ต้องวาง routing, conventions และ design system integration เพิ่มเอง

Desktop-first Clinic Web App Cliq Team PWA Admin PWA Live • Clinic Web Deployed

1. Frontend / Clinic Web App

Production Deployed

Vite + React 19 + TypeScript + Tailwind CSS + Framer MotionNext.jsVue / NuxtSvelteKitFlutter Web

เหตุผลที่เลือกรองรับ Desktop-first Clinic Web App, dashboard workflow, responsive fallback, healthcare SaaS UI และ deploy แบบ static แยก project บน Cloudflare Pages

สถานะการทำจริงClinic Web App deploy ที่ project cliq-clinic / clinic.cliq.care แล้ว มี favicon และ Home Screen/Android manifest icons; authenticated shell normalize production contracts และ render navigation หลักครบ โดยยังรอ full owner/role action smoke และไม่มี PWA install/offline requirement ส่วน Patient PWA ถูกยกเลิก; Admin PWA ที่ admin.cliq.care ยังคงเป็นคนละระบบและคนละ deployment

PrototypeMVP PilotProduction

2. Mobile App

Android Production UAT Closed

SwiftUI สำหรับ iOS AppKotlin + Jetpack Compose สำหรับ AndroidReact Native / Expo • Not ChosenFlutter • Not Chosen

เหตุผลที่เลือกใช้ native iOS controls เป็น functional/visual reference และใช้ Kotlin + Jetpack Compose เพื่อสร้าง Android native โดยไม่ redesign เป็น Material UI และไม่เปลี่ยน server-authoritative business rules

สถานะการทำจริงAndroid repository แยกและเชื่อม production client contract เดียวกับ iOS; ปิด production functional UAT เมื่อ 27 ส.ค. 2026 พร้อม bilingual behavior, reviewed iOS/Android screenshots, signed Release/R8, restricted Maps key, LINE OAuth, FCM/Crashlytics และ geofence evidence. เหลือ store packaging/submission, controlled rollout และ password-recovery parity decision

SwiftUI Source of TruthKotlin + Compose UAT ClosedProduction Contract SharedStore Submission Pending

3. Backend / API

Supabase-first Selected

Supabase API + PostgreSQL RPCFirebase Functions • AI GatewayCustom API Later If Needed

เหตุผลที่เลือกได้ server-authoritative transaction, Auth, RLS, Realtime และ Storage เร็วโดยไม่ต้องดูแล API infrastructure ทั้งชุดเอง

สถานะการทำจริงProduction Supabase project, RPC, iOS integration, clinic verification, media/doctor photo sync และ billing baseline deploy แล้ว; monitoring automation เป็น hardening ถัดไป

PrototypeMVP PilotProduction

4. Database

Selected

Supabase Managed PostgreSQL • SingaporeCloud SQL PostgreSQL • Future OptionFirestore • Not Main DB

เหตุผลที่เลือกเหมาะกับ relational booking/queue, concurrency, reporting, PostGIS, tenant RLS และเส้นทางย้าย PostgreSQL ในอนาคต

สถานะการทำจริงCore schema, constraints, production-safe migrations, RLS, storage, restore drill และ database test suite มีแล้ว; production project ใช้งานจริงที่ `gormehvuezrienkgmvav`

PrototypeMVP PilotProduction

5. Auth / Login

Platform Selected

Supabase AuthPatient LINE Login • ProductionEmail/Password • ProductionPhone OTP • Later Choice

เหตุผลที่เลือกเชื่อม auth.uid กับ PostgreSQL RLS และ clinic membership โดยตรง พร้อมให้ผู้ป่วยเลือกบัญชี LINE หรืออีเมลที่แยกจากกัน

สถานะการทำจริงSupabase Auth production ใช้งานกับ iOS และ admin.cliq.care แล้ว; LINE/email linking ถูกปิด, LINE ไม่ขอ email, mandatory name/phone gate และ deletion/re-registration lifecycle ผ่าน owner device smoke ส่วน Phone OTP เป็นทางเลือกภายหลัง

MVP PilotProduction

6. Realtime / Sync

Selected

Supabase RealtimePostgreSQL Source of TruthPolling Fallback 15s

เหตุผลที่เลือกappointments, queue_entries และ notifications กระจายสถานะตาม RLS จากข้อมูลกลางชุดเดียว

งานที่เหลือเชื่อม subscription/reconnect ใน iOS และทดสอบ duplicate/out-of-order events

MVP PilotProduction

7. Notification

Soft-launch baseline selected

Firebase Cloud Messaging • ProductionIn-app notification • ProductionAccount Email • ProductionSMS • LaterLINE OA • Out of Scope

สถานะที่เลือกใช้ Supabase notification/outbox เป็น source of truth และ Firebase/APNs เป็นช่องส่ง พร้อม permission, preference, retry, delivery tracking และ Admin monitoring

งานภายหลังพิจารณา SMS เมื่อมี use case, consent, opt-out, cost และ support ownership ชัดเจน; LINE OA ถูกตัดออกจาก scope และไม่เกี่ยวกับ LINE Login ที่ใช้งานแล้ว

MVP PilotProduction

8. File Storage

Selected

Supabase StorageExternal Object Storage • Future Review

สถานะสร้าง clinic-media bucket contract และ RLS ตาม clinic UUID สำหรับ logo, building, gallery และ doctor profile photos แล้ว พร้อม preview ใน iOS/admin

ข้อจำกัดไฟล์สุขภาพส่วนตัวต้องใช้ private bucket/signed URL แยกต่างหากเมื่อมี use case

MVP PilotProduction

9. Search / Location / Map

Core Selected

PostgreSQL + PostGISGoogle Maps • iOS CurrentDedicated Search • Later If Needed

ข้อดีรองรับค้นหาตามพื้นที่ ระยะทาง สาขาแพทย์ เวลาเปิด และความพร้อม

ข้อจำกัดต้องควบคุมค่าใช้จ่าย API, ranking quality และความถูกต้องของ location

PrototypeMVP PilotProduction

10. Billing / Payment

Production Baseline

Backend-driven invoicePromptPay QR + slipAdmin payment reviewMonthly auto issue 08:30Payment Gateway • Later

สถานะที่เลือกใช้ตอนนี้ออก invoice ได้ทั้ง manual และอัตโนมัติหลังสิ้นเดือน คลินิกดู statement ชำระผ่าน PromptPay และอัปโหลดสลิปให้ admin ตรวจ ก่อนรับ paid PDF

ข้อจำกัดpayment gateway, auto debit, dispute และ tax automation เต็มรูปแบบพักไว้สำหรับ phase ถัดไป

MVP PilotProduction

11. Analytics

Decision Pending

SQL dashboardMetabasePostHogMixpanelGoogle Analytics แบบระวังข้อมูลสุขภาพ

ข้อดีช่วยวัด conversion, arrival, no-show, adoption และ safety review

ข้อจำกัดต้องไม่ส่ง symptom หรือข้อมูลสุขภาพละเอียดเข้า third-party analytics

MVP PilotProduction

12. Monitoring / Logs

Automated Baseline

Firebase CrashlyticsServer-side alertsCloud LogsDatabase Audit LogGrafana / Prometheus • Later

สถานะiOS crash/error และ Auth, Booking, Queue, Storage, Email, AI Gateway มี automated reporting/alert baseline แล้ว

Privacy guardrailตัดข้อมูลส่วนบุคคล อาการ token และ request payload ออกจากรายงาน และแยก operational log จาก audit evidence

MVP PilotProduction

13. Infrastructure / Hosting

Managed Baseline Selected

Supabase Singapore • Production Core DataFirebase Functions • AI GatewayCloudflare Pages • cliq.careCloudflare Pages • admin.cliq.careCloudflare Pages • hub.cliq.careCloudflare Pages • clinic.cliq.care

ข้อดีเลือกได้ตั้งแต่ managed launch ไปจนถึง cloud control สำหรับ production

ข้อจำกัดต้องเทียบ security ownership, backup, cost, region และ operational skill

PrototypeMVP PilotProduction

14. AI Layer

Selected

Rule-based onlyLLM onlyHybrid Rule + LLM • SelectedRAG • LaterTrain model เอง • Later

Selected provider/modelOpenAI API ผ่าน AI Gateway เท่านั้น และใช้ GPT-5.4 mini ใน prototype ปัจจุบัน

ข้อจำกัดPilot ใช้กรอบ clinical safety แบบไม่วินิจฉัยแล้ว; สำหรับ production ยังต้อง clinical validation, false-negative review, prompt/model versioning, vendor data review และ production security hardening

PrototypeMVP PilotProduction

15. Security / PDPA Approach

Technical Foundation

ConsentPrivacy NoticeRole-based accessRLSAudit LogEncryptionData retentionIncident responseDe-identify before AI

ข้อดีเป็น guardrail ข้ามทุก layer และลดความเสี่ยงของข้อมูลสุขภาพ

ข้อจำกัดต้องกำหนด controller/processor, policy owner และวิธีตรวจสอบจริง

PrototypeMVP PilotProduction

Current Selected Stack / เทคโนโลยีที่เลือกใช้

สถาปัตยกรรมหลักที่เลือกและใช้งานจริงใน production พร้อมขอบเขตของ platform ถัดไป

Client & Web Platforms

Selected

SwiftUI • iOS Production
Kotlin + Jetpack Compose • Android Production UAT Closed
Vite + React 19 + TypeScript • Clinic Web Deployed
Tailwind CSS
Framer Motion
Cloudflare Pages • Isolated Web Hosting

Patient ใช้ iOS และ Android native เท่านั้น ส่วน Clinic ใช้ iOS, Desktop-first responsive Web App และ Android native; Clinic Web App ไม่ใช่ PWA requirement. Android ใช้ Kotlin, Jetpack Compose, Coroutines/Flow และ production Supabase contract เดียวกับ iOS

Data, Auth & Business Core

Production

Supabase Managed PostgreSQL • Singapore
Supabase Auth
PostgreSQL RPC + RLS
Supabase Storage
Supabase Realtime
PostGIS

Production Supabase gormehvuezrienkgmvav เป็น source of truth เดียว กฎสำคัญของ booking, queue, billing, account lifecycle และ tenant authorization อยู่ฝั่ง database/RPC ไม่กระจายใน UI

AI, Automation & Observability

Production

Firebase Functions • Node.js 22
OpenAI API ผ่าน Cliq AI Gateway
Firebase Cloud Messaging + APNs
Firebase Crashlytics
Scheduled + Event-driven Workers
Supabase Outbox • Notification Source of Truth

Firebase ไม่ใช่ฐานข้อมูลหลัก แต่รับผิดชอบ AI Gateway, automation, monitoring, retention worker และช่องส่ง Push โดยข้อมูลธุรกิจและสถานะการส่งยังยึด Supabase เป็น authoritative source

ข้อสรุปปัจจุบัน: ใช้ Hybrid Production Stack

SwiftUI และ Kotlin/Jetpack Compose เป็น mobile clients, Desktop-first Clinic Web App ใช้ Vite + React 19 stack, Supabase/PostgreSQL เป็น data/Auth/business core, Firebase ดูแล AI/automation/Push/Crashlytics และ Cloudflare Pages แยก deployment สำหรับเว็บแต่ละตัวอย่างชัดเจน. Android ใช้ contract เดิม ไม่สร้าง backend ใหม่ และปิด production functional UAT/visual parity/signed Release evidence แล้ว โดยยังรอ store submission และ controlled rollout

แผนความปลอดภัย AI Triage

AI เป็นระบบช่วยคัดกรองเบื้องต้นและแนะนำสาขาแพทย์ ไม่ใช่การวินิจฉัยโรค และไม่แนะนำยา

Implemented in prototype: ใช้ red_flag_rules_v0.1 ก่อนเรียก AI; เคสฉุกเฉินไม่เรียก LLM และ block booking

Implemented in prototype: GPT-5.4 mini ตอบผ่าน Structured Outputs และ validate schema ก่อนส่งกลับ iOS

Implemented in prototype: consent, safety message และ disclaimer ชัดเจนว่าไม่ใช่การวินิจฉัยโรค

Implemented in prototype: ใช้อาการ ระยะเวลา กลุ่มผู้ใหญ่/เด็ก/ตั้งครรภ์ และเพศเป็นบริบทในการคัดสายคลินิก

Implemented in prototype: เมื่อเลือกเด็กจะแสดงเฉพาะสายที่รองรับเด็ก และไม่ปะปนคลินิกผู้ใหญ่ที่ไม่เกี่ยวข้อง

Implemented in prototype: เคสฉุกเฉินพาไปโรงพยาบาล/1669 และไม่แทรกคลินิกเวชศาสตร์ฉุกเฉินในรายการคลินิกที่จองได้

Soft-launch baseline: ใช้ขอบเขต safety แบบไม่วินิจฉัยและ routing แบบ conservative; หมอป๋อม/ทีมแพทย์ควร validate false negative เชิงลึกก่อนขยายวงกว้าง

Implemented in prototype: response เก็บ model, prompt และ rule-engine version พร้อม metadata log ที่ไม่เก็บ symptom text เต็ม

Implemented in prototype: mask เบอร์โทร เลขบัตร อีเมล ชื่อและที่อยู่เบื้องต้นก่อนส่ง OpenAI; ยังต้อง privacy review ก่อนขยายวงกว้าง

Symptom Input

Red Flag Rules

AI Gateway

Specialty Recommendation

Clinic Matching

Clinical boundary

AI ต้องช่วยแนะนำความเร่งด่วนและสาขาแพทย์เท่านั้น สำหรับ soft launch ปิดกรอบ safety แล้วด้วย red flags, hospital/1669 escalation และ conservative clinic routing; clinical validation เชิงลึกและ false-negative benchmark เป็น production gate หลัง soft launch

แผน Security / PDPA

ข้อมูลอาการและข้อมูลสุขภาพเป็นข้อมูลอ่อนไหว จึงต้องวาง privacy และ security เป็นเงื่อนไขก่อนเริ่มเก็บข้อมูลจริง

ขอ consent ก่อนเก็บอาการ และมี privacy notice ที่อธิบายวัตถุประสงค์อย่างชัดเจน

แยกข้อมูลแต่ละคลินิก: คลินิก A ห้ามเห็นข้อมูลของคลินิก B

คนไข้เห็นเฉพาะข้อมูลของตัวเอง และพนักงานเห็นเท่าที่จำเป็นต่อหน้าที่

ใช้ role permission, tenant isolation และ policy enforcement ที่ตรวจสอบได้

มี audit log สำหรับ action สำคัญ เช่น เปลี่ยนคิว ดูข้อมูล และแก้ invoice

เข้ารหัสข้อมูลสำคัญ ทั้งระหว่างส่งและขณะจัดเก็บตามระดับความเสี่ยง

Data retention/deletion matrix และ legal-hold workflow ติดตั้งแล้ว; เหลือแต่งตั้ง owner/controller/processor และ external legal sign-off ก่อน broad launch

มี incident response plan, escalation contact และวิธีประเมินผลกระทบ

ห้าม log symptom text แบบเต็มใน system logs และต้อง redact sensitive fields

de-identify ข้อมูลก่อนส่ง AI vendor หากเป็นไปได้ และทบทวน data processing terms

คำถามเชิง governance ที่ยังต้องตอบ

ใครเป็น data controller / data processor, คลินิกมีฐานกฎหมายและสิทธิ์เห็นข้อมูลระดับใด, เก็บ symptom นานเท่าไร และใครเป็นผู้อนุมัติ incident response

ร่างแผนฐานข้อมูล / Database Draft

Supabase Managed PostgreSQL project gormehvuezrienkgmvav ใช้เป็น core production database และ source of truth เดียว พร้อม schema/RPC, RLS, Storage, verified restore drill, production smoke และ iOS/admin integration; legacy development project ไม่ใช่ execution target ของงานปัจจุบัน

ตารางหลักที่คาดว่าจะต้องมี

PostgreSQL Migrations Implemented

usersrolesclinicsclinic_mediaclinic_membersdoctorsspecialtiesclinic_schedulesclinic_slotsbookingsarrival_attemptscheckinsqueue_entriesqueue_eventstriage_sessionsnotificationsinvoicespaymentsaudit_logsconsents

ความสัมพันธ์หลัก

Implemented Baseline

users ↔ roles และ clinic_members สำหรับสิทธิ์และขอบเขตคลินิก
clinics ↔ clinic_media / doctors / specialties / schedules / slots
bookings คือ appointment; เลขคิวแยกอยู่ใน queue_entries และเกิดหลัง check-in เท่านั้น
bookings ↔ arrival_attempts ↔ checkins ↔ queue_entries / queue_events ↔ notifications
bookings / billable events ↔ invoices ↔ payments
users ↔ consents และทุก action สำคัญ ↔ audit_logs

ข้อมูลที่ต้องระวัง

High Sensitivity

symptom text และ triage_sessions จำกัดสิทธิ์และลบอัตโนมัติเมื่อครบ 90 วัน หรือลบทันทีเมื่อผู้ป่วยลบบัญชี เว้นแต่มี legal hold ที่ยังมีผล
audit_logs ต้องไม่กลายเป็นที่เก็บข้อมูลสุขภาพแบบเต็มโดยไม่ตั้งใจ
clinic membership และ tenant boundary ต้องป้องกัน cross-clinic access
consent version และ purpose ต้องตรวจสอบย้อนหลังได้
arrival evidence เก็บเฉพาะที่จำเป็นต่อ check-in และลบพิกัดละเอียดอัตโนมัติเมื่อครบ 30 วัน โดยสถานะบริการที่ไม่ใช่พิกัดยังอยู่ตามอายุ booking

หลักคิดก่อนขยาย schema

Production Baseline

เลือก Supabase/PostgreSQL และ tenant/RLS isolation เป็น baseline แล้ว
ทำ booking/check-in/queue transition เป็น server-side transaction และ idempotent command
billing ใช้ verified check-in เป็น billable event, ออก invoice manual/รายเดือนอัตโนมัติ และรับ slip review แล้ว; remote booking อย่างเดียวไม่ถือเป็นรายการคิดเงิน
clinical data minimum และ AI data boundary มี soft-launch baseline แล้ว ต้อง review ก่อน scale
ทดสอบ access matrix และ deletion flow ก่อนขยายวงกว้าง

10A

PostgreSQL-first & Provider Portability

Supabase เป็น provider เริ่มต้นเพื่อความเร็วของ MVP/Pilot แต่ PostgreSQL และ Cliq domain model เป็นแกนกลางระยะยาว

Cliq uses Supabase Postgres as the initial managed PostgreSQL platform, but the system must be designed as PostgreSQL-first and provider-portable. Supabase is the starting provider, not a permanent lock-in.

Cliq ใช้ Supabase Postgres เป็น Managed PostgreSQL เริ่มต้น แต่โครงสร้างระบบต้องยึด PostgreSQL เป็นแกนกลาง และต้องไม่ผูกติดกับ Supabase จนย้าย provider ภายหลังไม่ได้

Database Decision

Selected

Engine: PostgreSQL
Initial provider: Supabase Postgres • Singapore • Production project gormehvuezrienkgmvav • Deployed
Reason: relational consistency, transaction, concurrency, reporting, PostGIS และ auditability
Long-term: ใช้ Supabase ต่อได้ หรือย้ายไป RDS, Cloud SQL, Neon, DigitalOcean หรือ PostgreSQL provider อื่น

Portability Strategy

Required Day One

ทุก schema change อยู่ใน SQL migration file
business role และ clinic membership อยู่ในตารางของ Cliq
RLS เป็น defense layer ไม่ใช่ business logic ทั้งหมด
Auth, Storage และ Realtime อยู่หลัง provider adapter
critical commands ต้องย้ายไป Cliq Backend API ได้โดยไม่เปลี่ยน UI contract

Current Boundary

Architecture Foundation

Production project ใช้งานจริงแล้วและเป็น source of truth ของ iOS/admin ตอนนี้ยังไม่ย้ายออกจาก Supabase แต่ยังคงเก็บ migration ใน repo, ใช้ service/repository boundary และรักษา provider portability เผื่อย้าย PostgreSQL provider หรือเพิ่ม backend API เต็มรูปแบบในอนาคต

Service Layer Rule

UI Screen → ViewModel → Service / Repository → Supabase Adapter หรือ Cliq Backend API → PostgreSQL โดย UI ห้ามรู้ว่า data source คือ Mock, Supabase หรือ provider ใด และห้ามเรียก OpenAI จาก client

SwiftUI/Clinic Web App UI ห้ามเรียก Supabase query หรือ Realtime channel โดยตรง

ใช้ AuthService, StorageService และ RealtimeService เป็น adapter boundary

ใช้ Clinic, Booking, Queue, CheckIn, Triage, Notification และ Billing repositories

ห้าม hard-code Supabase Storage URL ใน UI หรือ domain model

ห้ามเก็บ role สำคัญไว้ใน Supabase Auth metadata อย่างเดียว

ห้ามสร้าง RLS ผ่าน dashboard อย่างเดียวโดยไม่มี migration SQL

Edge Functions ใช้เป็น helper/prototype ไม่ใช่ที่อยู่เดียวของ core business logic

Booking, check-in, billing, notification และ audit ต้องพร้อมย้ายหลัง Backend API

Migration Risk

ส่วนของระบบ	ย้ายง่ายไหม	วิธีลดความเสี่ยง
PostgreSQL tables	ง่าย	ใช้ standard PostgreSQL และ SQL migration
Data rows	ง่าย	ใช้ pg_dump/restore และ reconciliation checklist
Schema / indexes	ง่าย	เก็บ migration ทุกครั้งใน repo
Supabase Auth	ปานกลาง	แยก profile, identity, role และ clinic membership ของ Cliq
RLS policies	ปานกลาง	เขียนเป็น SQL และแยก provider identity helper
Supabase Storage	ปานกลาง	ใช้ StorageService และเก็บ object metadata แบบ portable
Edge Functions	ยากถ้าใช้มาก	ไม่วาง business logic หลักไว้ที่เดียว
Realtime	ปานกลาง	ใช้ RealtimeService และให้ PostgreSQL เป็น source of truth
Client code	ง่ายเมื่อมี service layer	ห้าม UI import หรือเรียก Supabase โดยตรง

Long-term statement

Cliq จะเริ่มต้นด้วย Supabase Postgres เพื่อความเร็วในการพัฒนาและความเหมาะสมกับ MVP/Pilot แต่ architecture หลักจะยึด PostgreSQL-first และ provider-portable เพื่อไม่ให้ระบบผูกติดกับ Supabase มากเกินไป หากระบบเติบโตในอนาคต Cliq สามารถเพิ่ม Backend API เต็มรูปแบบและย้าย PostgreSQL ไปยัง Managed PostgreSQL provider อื่นได้ โดยไม่ต้องเปลี่ยน core database model

Database Strategy Supabase Portability Migration Playbook Service Layer Rules

Roadmap 3 ระยะ

Pilot ผ่าน owner testing แล้ว ตอนนี้โฟกัสคือ App Store release, final archived smoke และ controlled clinic retest/soft launch บน production database จริง

Prototype / Planning

Done

ทำความเข้าใจ product และ user workflows
วาง platform และ architecture plan
รวบรวม Decision Center และ open questions
สร้าง connected-ready iOS prototype และ AI Gateway เพื่อ validate flow และ clinical routing
ทำ clinic discovery/map, booking confirmation, fair proximity queue, clinic arrival confirmation และ clinic photo management

MVP Pilot

Passed

ถือว่าผ่านตาม owner testing ของ workflow หลัก
ย้าย booking, check-in, notification และ clinic operations จาก mock state ไป backend จริง
invoice basic และ AI triage ภายใต้ safety plan
วัด adoption, arrival, no-show และ clinical safety

Production / Controlled Launch

Current

Production Supabase project แยกจาก dev ทำแล้ว
ทำ verified restore drill แล้ว; defer paid PITR ได้ใน soft launch เล็ก ๆ แต่ต้อง revisit ก่อน scale กว้างหรือข้อมูล production ปริมาณมาก
ระบบรีวิวคลินิก 5 ดาวทำแล้ว: ผู้ป่วยรีวิวหลังจบ booking, เก็บใน Supabase production และแสดงคะแนนเฉลี่ยใน iOS
clinic verification/account hardening ทำแล้ว: DB-first pending/verified state, upload previews, current-location helper, tax ID checksum, review-before-submit, doctor photo requirement และ doctor avatar sync
profile change approval ทำแล้ว: ข้อมูล public เดิมยังใช้งานจน admin อนุมัติ, วันทำการแพทย์บันทึกตรงได้, draft ไม่ถูก polling refresh ทับ และแพทย์ใหม่ต้องแนบหลักฐานครบ
Admin PWA production hardening ทำแล้ว: verification, profile-change review, logo/building/doctor/evidence preview, billing invoice/slip/payment confirmation
Backend-driven Billing Center ทำแล้ว พร้อม PromptPay QR, statement, slip-only payment report, paid PDF และ monthly auto invoice เวลา 08:30
Crashlytics และ server-side alerting ทำแล้ว พร้อม privacy redaction
production retest cleanup ทำแล้วสำหรับ test aliases สำคัญ เพื่อให้สมัครใหม่และส่งคำขอเปิดคลินิกใหม่ได้บนข้อมูล production จริง
manual operations cadence, backup cadence, incident log, legal/PDPA sanity และ clinical boundary review ทำแล้ว
เตรียม App Store package, production build และ final smoke
เริ่ม controlled production launch แบบคุมจำนวนก่อน scale

ยังไม่ทำตอนนี้ / Later Phase

สิ่งเหล่านี้ยังไม่ควรอยู่ในช่วงแรก เพราะเพิ่ม scope, regulatory risk และ operational complexity ก่อนพิสูจน์ core workflow

ระบบจ่ายเงินออนไลน์เต็มรูปแบบTelemedicineVideo callPrescriptionเวชระเบียนChat หมอ-คนไข้AI แนะนำยาAI วินิจฉัยโรคAnalytics ซับซ้อนEnterprise multi-branch เต็มรูปแบบHIS / EMR integrationInsurance claimLoyalty program

MVP ที่ดีไม่ใช่ระบบที่มีทุกอย่าง

MVP ที่ดีคือระบบที่เล็กพอจะทำทัน ปลอดภัยพอสำหรับ soft launch และชัดพอจะ validate ว่า workflow หลักสร้างคุณค่าให้คนไข้และคลินิกจริงหรือไม่

Production Launch Gates / Open Decisions

Pilot ผ่านแล้ว; รายการนี้คือ decision และ external gate ที่ต้องปิดก่อนเปิด production/soft launch กับผู้ใช้จริง

จะเปิด paid PITR เมื่อไร ก่อน scale กว้าง/ข้อมูลเยอะ หรือเมื่อ recovery requirement เข้มขึ้น?

หลังเลือก SwiftUI และลำดับ iOS App ก่อนแล้ว จะเลือก Android native stack อะไรเพื่อ clone design/UX จาก iOS?

LINE Login และอีเมลเป็น production choices ที่แยกบัญชีกันแล้ว; จะเพิ่ม Phone OTP เป็นช่องทางผู้ป่วยภายหลังหรือไม่?

billing baseline และ monthly auto invoice มีแล้ว; ก่อน scale ต้องยืนยัน pricing/monthly cap, tax document process และตัดสินใจว่าจะเปิด payment gateway/dispute เมื่อไร?

15 บาทต่อ check-in ยังเป็น pricing hypothesis หลักหรือไม่ และจะมี monthly cap ไหม?

ใครเป็น data controller / data processor ในแต่ละ workflow?

จะเก็บ symptom text และ triage_sessions นานเท่าไร?

Retention และ privacy notice สำหรับ triage กำหนดแล้วที่ raw payload 90 วัน; ใครเป็น controller/processor owner และเมื่อใดจะปิด vendor review/external legal sign-off?

หมอป๋อมจะออกแบบและ validate red flags, specialty mapping, false negatives และ acceptance test ของ GPT-5.4 mini อย่างไร?

soft launch แรกจะเริ่มกี่คลินิก กี่ผู้ใช้ และใครเป็น daily operator?

หลัง support/incident baseline พร้อมแล้ว ใครจะเป็น owner ระยะยาวของ support console, dispute และ SLA เมื่อเปิดใช้วงกว้าง?

identity, track enrollment, staff invitation และ tenant RLS มีแล้ว; ก่อน scale ต้องกำหนด policy สำหรับผู้ใช้หลายบทบาท/หลายคลินิกและ recovery/escalation ให้ชัดเพียงใด?

กฎ 300 ม., location freshness 2 นาที, accuracy 100 ม., ช่วง −30/+15 นาที และ clinic confirmation 30 นาที ต้องปรับตามข้อมูล soft launch หรือไม่?

สถานะปัจจุบัน: Pilot passed • Production hardening active

Patient + Clinic Staff iOS ใช้ Supabase production เป็น source of truth พร้อม Auth/RLS, clinic opening/profile approval, doctor evidence, booking/check-in/queue, media, reviews, triage persistence, backend-driven billing และ retention/legal hold; Firebase Functions ให้ AI Gateway, monthly invoice, five-minute health monitoring, push delivery และ daily retention พร้อม Crashlytics ฝั่ง iOS ส่วนงานที่ยังเหลือคือ final App Store archive/submission, controlled launch, clinical validation ต่อเนื่อง, external legal/privacy sign-off และ Admin operations modules ที่ยังเป็น shell

ไม่พบหัวข้อที่ค้นหา ลองเปลี่ยนคำค้นหาหรือล้างตัวกรองครับ

North Star

Cliq ช่วยให้คนไข้ต่างจังหวัดพบคลินิกที่เหมาะกับอาการได้เร็วขึ้น พร้อมลด friction ของคลินิกในการรับคนไข้ใหม่และจัดการคิว

Design Principles

เก็บข้อมูลสุขภาพเท่าที่จำเป็นต่อการ triage และ booking
ออกแบบทุก action สำคัญให้ตรวจสอบย้อนหลังได้
ทำให้ workflow ฝั่งคลินิกเรียบง่ายพอสำหรับ soft launch จริง

CliqHub

เข้าสู่ระบบผู้ดูแล