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

ใช้บัญชี admin ชุดเดียวกับที่เข้า admin.cliq.care

Cliq.

Product Hub • Advanced iOS Prototype

Product + Planning • iOS Vertical Slice • AI Triage
Cliq

Cliq Product & Planning Hub

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

ดูสถานะโปรเจกต์ Knowledge Map 25 ภาพ
+
82% Overall project progress โดยประมาณ
25 ภาพสรุปโครงสร้างและ decision points
2 Modes Patient + Clinic Staff connected flow
00

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

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

Production / Soft Launch Preparation

Patient Mode และ Clinic Staff Mode ผ่าน owner testing และ production real-flow smoke แล้ว ใช้ Supabase Managed PostgreSQL เป็น source of truth สำหรับ clinic catalog, doctor schedule, media, booking, proximity check-in, fair queue, triage consent/result, review และ audit; production project แยกจริงแล้ว พร้อม migrations/Auth/SMTP/iOS config, platform admin, restore drill, first real clinic verification, booking lifecycle, email, admin action, persistence/reinstall smoke, manual operations cadence, backup cadence, incident log, legal/PDPA sanity checklist, clinical boundary review, DB-first clinic verification hardening, doctor photo sync, Admin PWA image preview, billing draft filter และ production retest cleanup. เหลือ release freeze, App Store package และ final archived production build smoke ที่ owner จะทำเอง

RC Prep
82%
Overall Cliq Project Progress
อัปเดตล่าสุด: 8 ก.ค. 2026 iOS: Owner testing + production real-flow smoke passed • Clinic account/verification UI hardened • DB-first pending/verified state, doctor photo requirement, upload previews, current-location helper, tax ID checksum, review-before-submit และ account-card order polish build ผ่านแล้ว Production readiness: Supabase production project gormehvuezrienkgmvav created • migrations/Auth/SMTP/iOS preflight/platform admin/restore drill/Admin PWA/service smoke/first real clinic/booking lifecycle/email/admin/clinic reviews/manual ops/backup/legal boundary passed • เพิ่ม doctor photo DB-first mapping, billing draft-clinic filter, Admin PWA media preview และ production retest cleanup แล้ว • เหลือ App Store package, ใส่ version/build จริง และ final archived production build smoke 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: Dev project dfbbzmocdfmgfckragkq แยกจาก Production project gormehvuezrienkgmvav • production-safe migrations applied • no mock/demo seed promoted • verification payload/doctor photos/billing dashboard now DB-first Admin PWA: https://admin.cliq.care deployed on Cloudflare Pages • production Supabase • clinic verification row/detail UI, logo/building/doctor image preview, step 5 PDPA copy และ billing ที่ซ่อน draft clinics ใช้งานแล้ว Fair queue + proximity check-in modeled Clinical Safety: Soft-launch baseline + internal clinical boundary review ปิดแล้ว • formal external validation เป็น hardening ก่อน scale ใหญ่ Scope: iOS + AI/Clinical + Backend/Data/Auth + Security/Operations + PWA/Android/Admin + Production
82% หมายถึงความคืบหน้าของ Cliq ทั้งโปรเจกต์

เป็นคะแนนประมาณการแบบถ่วงน้ำหนักจาก Product/UX 15%, iOS 20%, AI + Clinical 15%, Backend + Database + Auth 20%, Security + Operations + Billing 10%, PWA + Android + Admin 10% และ Launch + Production 10% โดย owner testing และ production real-flow smoke ผ่านแล้ว: Supabase production project แยก, production-safe migrations, Auth redirect, Resend SMTP, platform admin, Admin PWA production config, iOS production preflight, verified restore drill, service smoke, first real clinic verification, booking lifecycle, email, admin, persistence/reinstall smoke, manual monitoring/support cadence, backup cadence, incident log, legal/PDPA sanity, clinical boundary review, RC freeze policy, production backup helper, health-check helper, release preflight, DB-first clinic verification hardening, doctor photo sync, billing draft filter, Admin PWA image preview และ retest cleanup พร้อมแล้ว แต่ยังไม่เท่ากับ submitted production app จนกว่าจะใส่ version/build จริง, ทำ App Store package และ final archived production build smoke

Product Scope & Requirements

Validated in Prototype

ตกผลึก flow คนไข้และคลินิกจาก iOS prototype แล้ว รวม pediatric/pregnancy routing, emergency hospital escalation, booking confirmation และ fair queue check-in; ยังปรับต่อจาก clinical feedback

Planning

Architecture & Platform Strategy

Selected Baseline

เลือก SwiftUI iOS-first, Supabase Managed PostgreSQL Singapore, Supabase Auth/Storage/Realtime และคง Firebase Functions สำหรับ AI Gateway ระหว่างการย้ายระบบ

Planning

PWA UI Stack

Selected

เลือก Next.js + TypeScript + Tailwind CSS + shadcn/ui + Framer Motion เป็น long-term stack แล้ว; ตอนนี้มี static Cloudflare Pages Admin Operations Console ที่ admin.cliq.care โดย clinic verification ใช้งานจริง, preview รูปโลโก้/อาคาร/แพทย์ได้, billing dashboard ใช้งานแบบ manual admin และซ่อน draft clinics แล้ว

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 บนระบบที่รองรับ แล้วใช้เป็น design source สำหรับ Android/PWA

Decision

iOS App Build Decisions

Owner Tested

SwiftUI, iOS/iPadOS 17, localization, app identity, repository boundary, navigation และ Patient + Clinic Staff vertical slice ผ่าน owner testing แล้ว; เพิ่ม production config template, runtime guardrails, support/legal links, clinic verification DB-first flow, doctor photo/upload preview, current-location helper, tax ID checksum และ preflight script แล้ว ขั้นถัดไปคือ App Store package และ final real-device smoke บน archived production build ที่ owner จะรันเอง

Build Gate

iOS Release Readiness

90–94% • Owner-tested baseline

P0/P1 release baseline ผ่าน owner testing แล้ว รวมคิวรายวัน, persistence/source of truth, booking/queue lifecycle, auth/email, clinic verification, staff invitation, clinical safety, notification/error/email, localization/accessibility, privacy/TestFlight และ operations/support; clinic verification/account UI hardening build ผ่านแล้ว ถัดไปคือ App Store package และ final archived build smoke

Release Gate

Production Readiness

RC prep ready

สร้าง Supabase production project `gormehvuezrienkgmvav`, apply production-safe migrations แบบไม่ promote mock/demo seed, ตั้ง Auth redirect, Resend SMTP, platform admin, iOS production config/preflight, Admin PWA production deploy, verified restore drill, production-shaped smoke, first real clinic smoke, booking lifecycle, email, admin action, clinic review, persistence/reinstall smoke, manual ops cadence, backup cadence, incident log, legal/PDPA sanity checklist, clinical boundary review, RC freeze policy, backup script, health-check script, release preflight, doctor photo DB-first mapping, billing draft-clinic filter และ retest cleanup แล้ว; ยังต้องใส่ version/build จริง, ทำ App Store package และ final production build smoke ก่อนส่งจริง

Production Gate

Patient PWA

Not Started

ยังไม่ได้เริ่มสร้างหน้าค้นหาหมอ บอกอาการ จองคิว หรือติดตามคิว

Product Build

Clinic PWA

Not Started

ยังไม่ได้เริ่มสร้าง dashboard, booking, check-in, queue หรือ clinic operations

Product Build

Cliq Team PWA

Ops + Billing Console

Admin PWA บน Cloudflare Pages ที่ admin.cliq.care ถูกยกระดับเป็น Operations Console แล้ว: มี overview, clinic verification ที่ทำงานจริง, preview uploaded logo/building/doctor images, monitoring cockpit, manual billing dashboard ที่ซ่อน draft clinics และ shell สำหรับ support, queue, reviews, email/notification, audit และ settings

Product Build

Native Mobile Apps

Advanced iOS Prototype

iOS SwiftUI มี Patient + Clinic Staff connected flow, Google Maps interaction, in-app notification popover, working contact actions, clinic photo upload และ bilingual UI; Android จะทำภายหลังโดย clone design/UX จาก iOS

Product Build

Backend / API

iOS Connected • Production

iOS เชื่อม Supabase production ผ่าน repository/gateway แล้วสำหรับ Auth, snapshot, clinic profile/media/schedule, verification payload, doctor photos, booking, confirmation, proximity check-in, arrival, queue, walk-in, no-show, staff invitation/team permissions และ triage persistence; Realtime/automated monitoring เป็น hardening ถัดไป

Core Platform

Database / Storage

Source of Truth • Production

Production migrations ครอบคลุม user/clinic/doctor schedule, appointment, staff booking snapshot, check-in evidence, queue capacity/wait metrics, clinic verification, doctor photo sync, staff invitation/team audit, notification, consent, triage payload, billing/invoice/payment/dispute baseline, audit, RLS, Realtime, Storage และ retention โดยเลิกใช้ local mock persistence ใน runtime หลัก

Core Platform

Authentication & Roles

Foundation Implemented

Supabase Email/Password Auth, email confirmation, password recovery พื้นฐาน, Resend/Supabase SMTP บน auth.cliq.care, profile provisioning, track enrollment ผู้ป่วย/คลินิก, clinic membership, owner/admin/staff roles, staff invitation และ RLS tenant boundary เชื่อมกับ iOS แล้ว

Security

AI Triage

Functional Prototype

Hybrid Rule-based + GPT-5.4 mini ทำงานผ่าน server-side AI Gateway แล้ว มี red-flag engine, de-identification, structured output, catalog 101 สาขา, iOS live service, Dr Pom ultra wide 7,884-example input-retrieval clinical teaching set v0.8 และ mapping จาก official specialty code ไปยัง clinic search bucket ที่ align กับ iOS แล้ว

Clinical & AI

Clinical Validation & QA

In Progress

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

Clinical & AI

LINE OA / LIFF

Not Started

ยังไม่ได้เชื่อม LINE OA, LINE Login, LIFF หรือ messaging flow จริง

Integration

Notification

Soft-launch baseline

เลือก in-app notification + activity feed และ account email เป็น soft-launch baseline แล้ว พร้อม track separation และ database acceptance test; APNs, LINE, SMS และ production delivery pipeline เป็นงานหลัง soft launch

Integration

Billing & Payment

Manual Admin Baseline

มี admin billing dashboard/RPC สำหรับ manual invoice/payment/dispute baseline แล้ว และซ่อน draft clinics จาก billing; payment collection, pricing approval, automation และ formal operations ยังเป็นงานถัดไป

Business Model

Security / PDPA Controls

Planning

AI triage prototype มี consent, server-side API key และ de-identification เบื้องต้นแล้ว พร้อม RLS, audit/activity, retention policy และ incident runbook ระดับ soft launch; production security review และ automated monitoring เป็น phase ถัดไป

Governance

Clinic Soft Launch

Owner tested

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

Operations
00A

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

สรุปความสามารถที่มีใน SwiftUI + Supabase development stack ปัจจุบัน อัปเดต 27 มิ.ย. 2026; owner testing ผ่านแล้ว และกำลังเตรียม production/soft-launch gate

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

Functional Prototype

ค้นหาชื่อ/สาขา/อาการ กรองหลายประเภทจากผล triage ส่ง filter ไปหน้า clinic search อัตโนมัติ กรองเฉพาะคลินิกที่เปิดอยู่ และปรับกล้องแผนที่ให้เห็นหมุดคลินิกกับตำแหน่งผู้ใช้ร่วมกัน

Google MapsOpen-now filterProvince + distance

Clinic Identity & Photo

Implemented

Clinic Staff อัปโหลด เปลี่ยน และลบโลโก้กับรูปอาคารได้ ข้อมูล mock ของที่อยู่ เบอร์โทร เวลาเปิด–ปิด สถานะปิดเฉพาะวัน และรูปคลินิกอ้างแหล่งเดียวกันในรายการ แผนที่ รายละเอียด และหน้าจอง

Consistent clinic dataImage fallbackShared components

Booking Experience

Connected Mock Flow

เลือกวัน/เวลาจากตารางคลินิก แสดงสล็อตเต็มแบบ disabled ใช้ชื่อวันและเดือนตามภาษาแอป เปิด popup ยืนยันก่อนจอง และ jump ไปหน้าการจองหลังส่งคำขอ; ปุ่ม Google Maps โทรศัพท์ และรายละเอียดทำงานแล้ว

Localized datesCapacity-aware slotsConfirmation dialog

Fair Queue & Proximity Check-in

Rules Modeled

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

Server-authoritative contractSimulated location blockDebug distance bypass

Arrival Confirmation & No-show

Connected Mock Flow

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

30-minute holdClinic confirmationStaff override

Clinic Staff Operations

Functional Prototype

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

Queue orderingWalk-inAppointment requests

Operating Hours & Booking Availability

Functional Prototype

กำหนดวันทำการปกติ เพิ่มหลายช่วงเวลาในแต่ละวัน ตั้งความยาวสล็อตและจำนวนคนต่อสล็อต ปิดรับจองทั้งหมด และเลือกวันที่ปิดคลินิกเฉพาะผ่านปฏิทินได้ ค่าเริ่มต้น mock คือ 17:00–20:00

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 สำหรับ owner/admin และ 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

  • Soft-launch policy
    Local/push reminder และ deep link ไปนัด

    สำหรับ soft launch ใช้ in-app activity และหน้าการจองเป็น baseline; APNs/SMS/LINE/background reminder เลื่อนเป็นหลัง soft launch เพราะต้องมี permission, delivery tracking, consent/opt-out และ support monitoring

  • 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
  • ทำแล้ว
    ภาษาไทย/อังกฤษและวันเวลา

    UI หลัก localized แล้ว และเพิ่ม localization ให้ clinic team management, clinic verification status และ role names; AI result, user-generated text, seed data และคำนำหน้าแพทย์ นพ./พญ. เป็นข้อยกเว้นตาม domain

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

    iOS ชี้ production Supabase URL/publishable key ใน Secrets.xcconfig, Admin PWA ชี้ production Supabase แล้ว และ preflight/scan ผ่าน; service-role, SMTP API key และ database password ไม่ถูกใส่ใน iOS/static PWA

  • ผ่านแล้ว
    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
  • ยังไม่เปิด
    Billing/payment

    ยังไม่ควรคิดเงินอัตโนมัติจนกว่า pricing, invoice, dispute และ accounting workflow จะอนุมัติ

  • หลัง soft launch
    Push/LINE/SMS reminder

    ใช้ in-app/account email ต่อไปก่อน แล้วค่อยเพิ่ม APNs/LINE/SMS เมื่อ consent, opt-out, delivery tracking และ support monitoring พร้อม

  • หลัง 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 Clinical Boundary
00B

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

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

1

Product Foundation

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

Native iOS Foundation

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

Patient + Clinic Vertical Slice

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

AI Triage & Smarter Matching

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

Discovery, Maps & Clinic Identity

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

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 ไม่เลื่อนซ้ายขวา
7

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
01

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

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

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

Advanced iOS Prototype

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

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

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

Advanced iOS Prototype

ดูและยืนยันคำจอง ยืนยันการมาถึง จัดคิวจริง/No-show/Walk-in ดูตาราง กิจกรรม บัญชี และอัปโหลดรูปคลินิก; invoice ยังเป็น later phase

Clinic-funded Queue operations Notifications

ทีม Cliq และ Core Platform

Planning Only

ทีม Cliq ดูแลระบบ สนับสนุนผู้ใช้ ตรวจ booking/check-in/invoice และทุกหน้าบ้านจะเชื่อมผ่าน backend และข้อมูลกลางชุดเดียวกัน

Shared backend Admin oversight Auditability
บทบาทที่ตกผลึกแล้ว

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

02

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

ผู้ใช้หลัก 3 กลุ่มมีเป้าหมายและ pain point ต่างกัน โดย Patient และ Clinic Staff flow ถูกนำมาทดลองใน iOS prototype แล้ว ส่วนทีม Cliq/admin ยังเป็นแผน

1. คนไข้

iOS Prototype

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

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

2. คลินิก

iOS Prototype

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

  • Pain point: โทรถามซ้ำ คิวไม่ชัดเจน ตารางเปลี่ยน และไม่รู้ล่วงหน้าว่าคนไข้กำลังมา
  • Platforms: PWA, 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: Admin Operations Console พร้อมใช้งานที่ admin.cliq.care; clinic verification ใช้งานจริงแล้ว และมี shell สำหรับ support, booking/queue operations, review moderation, email/notification monitoring, billing และ audit/incident พร้อมข้อความ “แล้วพบกันเร็ว ๆ นี้” ในส่วนที่ยังไม่เปิด backend action
03

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

เลือก SwiftUI, PWA UI stack และ Supabase Managed PostgreSQL/Auth/Storage/Realtime เป็น platform baseline แล้ว ส่วน push, billing, analytics และ production operations ยังต้องตัดสินใจต่อ

PAT

คนไข้

iOS Prototype
LINE OA LIFF / PWA Android App iOS App

ใช้ iOS App ที่สร้างด้วย SwiftUI เป็น mobile reference หลัก โดยคนไข้เข้า Patient Mode; LINE OA, LIFF/PWA และ Android จะตามมาในลำดับภายหลัง

CLN

คลินิก

iOS Prototype
PWA Android App iOS App

ใช้ iOS App เดียวกับคนไข้ แล้วแสดง Clinic Staff, Clinic Owner หรือ Doctor Mode ตาม role; Android และ PWA จะ clone design/UX จาก iOS

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 เป็น native design source ก่อน แล้วค่อย clone design language และ UX ไป Android กับ PWA

One Cliq App Experience

คนไข้และคลินิกใช้ iOS App เดียวกัน หลัง login ระบบแสดง mode ตาม role จากนั้น Android และ LIFF/PWA mobile view จะ clone หน้าตาและ UX จาก iOS ให้ใกล้เคียงที่สุด

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 Orderสร้าง iOS App ก่อน แล้วค่อยทำ Android และ LIFF/PWA ตาม design source จาก iOS

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 สำหรับระบบเก่า
Selected PWA StackNext.js + TypeScript + Tailwind + shadcn/ui + Framer Motion
Design Source of TruthSwiftUI iOS App + Figma/iOS-first design system สำหรับ component, spacing, motion และ interaction patterns
Platform SequenceiOS App → Android native implementation → LIFF/PWA mobile adaptation
Desktop PWAใช้ dashboard layout ที่เหมาะกับ desktop แต่รักษา 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 Android Native StackCore BackendDatabaseAuthHostingPush ChannelPayment
03B

iOS App Decisions & Current Baseline

บันทึกสิ่งที่เลือกและนำไปใช้แล้วใน iOS prototype พร้อมแยก decision ที่ยังต้องตอบก่อนเชื่อมข้อมูลและบริการ production จริง

เส้นทางที่เลือก: Connected-ready iOS App

ตัวแอปและ business flow หลักถูกสร้างบน mock repositories แล้ว จึงทดลอง interaction ข้าม Patient/Clinic Mode ได้ครบโดยยังไม่เก็บข้อมูลสุขภาพจริง ส่วน backend, database, auth และ PDPA operating model เป็น build gate ของ production

Starting Path Selected
UI Prototypeเน้นหน้าตาและ interaction ใช้ mock data แบบอาจทิ้งภายหลัง เหมาะสำหรับทดลอง design เร็ว
Connected-ready UI App • Selectedสร้างโครงแอปจริงที่พร้อมเชื่อม API ภายหลัง แต่ช่วงแรกใช้ mock data และไม่เก็บข้อมูลสุขภาพจริง
Connected MVPเชื่อม auth, backend และข้อมูลจริงตั้งแต่ต้น ต้องตัดสินใจ architecture, security และ PDPA ก่อนเริ่ม

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

Implemented

รายการเหล่านี้เป็น baseline ของ project structure, screen scope และวิธีทดสอบใน prototype ปัจจุบัน

01

Native App Stack

สร้าง iOS App ด้วย SwiftUI ก่อน ใช้ native controls และ progressive Liquid Glass แล้วค่อย clone design/UX ไป Android และ PWA

SwiftUI • SelectedAndroid Stack • เลือกภายหลังPWA Stack • Selected แยกแล้ว
Selected
02

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

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

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

Role แรกที่จะทำ

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

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

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
05

Navigation ของแต่ละ Mode

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

Navigation Structure v1 • Implemented
Implemented
06

Supported Devices & Orientation

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

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

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
08

ภาษาและ Localization

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

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

Distribution รอบแรก

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

Local + Real Device via Xcode • SelectedTestFlight • Later
Selected
10

App Identity

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

Display Name: CliqApp Store Name: CliqBundle ID: com.cliq.appIndividual Developer
Selected
11

Design Workflow

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

Hybrid: Figma Tokens + Code Prototype • Selected
Selected
12

Repository Strategy

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

Separate Mobile Repository • SelectedFuture Monorepo Review
Selected
13

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.cliq.app • Selected
ต้องตรงกับ Xcode และเปลี่ยนไม่ได้หลัง upload build
ข้อควรระวังเรื่องประเภทแอป

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

Cliq iOS UI visual reference

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

เลือกเพิ่มเมื่อจะเชื่อมระบบจริง

Later Build Gate

ไม่จำเป็นสำหรับ Connected-ready UI App ที่ใช้ mock data แต่ต้องตอบก่อนเก็บข้อมูลคนไข้จริงหรือทดสอบ workflow แบบ end-to-end

Auth & LoginGuest browsing, Phone OTP, LINE Login, Sign in with Apple และวิธีเชิญ clinic staff
Role Membership & Switchingผู้ใช้หนึ่งคนมีหลาย role ได้ไหม ใครอนุมัติ role และสลับ mode อย่างไร
Backend / API • SelectedSupabase generated API + transactional RPC เป็น core backend และคง Firebase Functions สำหรับ AI Gateway ระหว่าง transition
Database & Tenant Isolation • SelectedSupabase Managed PostgreSQL + Row Level Security แยก patient และ clinic membership
Booking Model • Selected in PrototypeHybrid: จองเวลาจากระยะไกลได้ แต่ไม่ออกเลขคิวจนกว่าจะเช็กอินใกล้คลินิกหลังคลินิกยืนยัน
Check-in & Arrival • Selected in Prototypeใช้ GPS + time window + clinic physical-arrival confirmation; มี staff override เมื่อ location มีปัญหา
Realtime & Offline Strategyคิว sync อย่างไรเมื่อ internet ไม่เสถียร และข้อมูลใดต้องใช้ offline ได้
NotificationAPNs/FCM, event ที่ต้องแจ้ง, permission timing, retry และ fallback channel
Maps & LocationApple MapKit, Google Maps หรือ Mapbox และใช้ precise/coarse location ระดับใด
AI รุ่นแรกHybrid rule + AI จริง พร้อม soft-launch safety boundary และ production clinical validation ภายหลัง
Security / PDPAConsent, privacy notice, retention, account deletion, controller/processor และ incident response
Monitoring & AnalyticsCrash/error/usage analytics โดยห้ามส่งข้อมูลสุขภาพละเอียดเข้าสู่ third party
Billing Trigger & PaymentCheck-in จริง หรือ qualified booking + arrival + dispute; payment automation เลือกภายหลังได้
ยังไม่จำเป็นต้องเลือกเพื่อเริ่ม Connected-ready UI App Payment Gateway จริงProduction AI hardeningAndroid ImplementationLINE OA IntegrationAdvanced AnalyticsHIS / EMR Integration

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

ตอบเฉพาะข้อที่เลือกแล้วได้ ข้อใดต้องการมอบให้ผมตัดสินใจให้เขียนว่า “ให้ 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.cliq.app / Individual Developer • Selected
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
04

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

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

01
Frontend / PlatformsSwiftUI iOS App มี Patient + Clinic Staff vertical slice, production-connected role navigation และ DB-first clinic workflow แล้ว; PWA stack เลือกแล้ว ส่วน Android และ LINE ยัง Pending
iOS Production Connected
02
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
03
Database / StorageSupabase Managed PostgreSQL Singapore production project ทำงานแล้ว พร้อม RLS, PostGIS, Realtime, clinic media Storage, doctor photo storage mapping, audit, restore drill และ retention schema
Production Active
04
AI Layerเลือก Hybrid Rule-based + LLM และ GPT-5.4 mini; มี red flag rules, AI Gateway, de-identification และ schema validation ระดับ functional prototype
Prototype
05
Notification Layerin-app notification, activity feed, account email และ track-scoped notification table เป็น soft-launch baseline แล้ว; APNs/FCM, SMS/LINE, delivery analytics และ production event pipeline เป็นงานหลัง soft launch
Soft-launch Baseline
06
Security / PDPA Layerconsent, role permissions, tenant isolation, RLS, team audit, encryption, retention และ incident response
Foundation
07
Infrastructure / Hostingruntime, network boundary, secrets, environment guardrail, support URL, monitoring checklist, backup policy และ downtime runbook พร้อมระดับ soft launch แล้ว; production alerting/PITR เป็นขั้นถัดไป
Soft-launch Baseline
08
Admin & BillingAdmin Operations Console deploy แล้วที่ admin.cliq.care พร้อม platform_admin guard; clinic verification ใช้งานจริงพร้อมรูป preview และ billing dashboard/manual invoice/payment/dispute baseline ใช้งานแล้ว โดย support console, queue operations, review moderation และ audit dashboard ยังเป็น phase ถัดไป
Admin + Billing Baseline
05

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

สถานะโมดูลสะท้อนสิ่งที่ทำงานได้ใน iOS mock prototype และแยกให้ชัดจากส่วนที่ยังต้องมี backend/production infrastructure

1. User Module

Auth Foundation

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

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

2. Clinic Module

Pilot Connected

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

Patient + ClinicDatabase source of truth

3. Schedule / Slot Module

UI Prototype

เลือกวันและช่วงเวลาจอง ปิดใช้งาน slot ที่ผ่านไปแล้ว และแสดงความพร้อมใน Patient/Clinic flow; capacity และ realtime locking ยังต้องอยู่บน backend

Patient + ClinicServer locking pending

4. Booking Module

Connected Mock Flow

คนไข้เลือกวัน/เวลา ยืนยันผ่าน popup ส่งคำจองและ jump ไปหน้าการจอง; คลินิกยืนยันหรือปฏิเสธได้ และปุ่มรับคิวจะยัง disabled ระหว่างรอ

Patient + ClinicRemote 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

Connected Mock Flow

ออกเลขคิวหลังผ่าน proximity check-in เท่านั้น จัดลำดับผู้ที่รับคิวแล้วก่อน appointment ที่ยังไม่มาถึง และรองรับ clinic confirmation, no-show, cancel, walk-in และจบคิว

Fair queuePatient + ClinicServer authority pending

7. AI Triage Module

Functional Prototype

Hybrid Rule-based + GPT-5.4 mini ผ่าน server-side AI Gateway: รับอาการ ระยะเวลา กลุ่มผู้ใหญ่/เด็ก/ตั้งครรภ์และเพศ, red flag screening ก่อน LLM, structured urgency/specialty output และ hospital-only emergency escalation

Smart clinic filteringหมอป๋อม validateNot a diagnosis

8. Notification Module

Soft-launch Baseline

กระดิ่งหน้าหลักเปิด notification popover ได้จริง มี activity/สถานะ booking ใน app, track separation, read-state ต่อ user และ email auth/recovery baseline; production push, delivery tracking และ fallback channel เป็นงานหลัง soft launch

In-appAccount emailAPNs/FCM after soft launch

9. Billing Module

Manual Baseline

มี billable event, invoice, payment status และ dispute baseline สำหรับ admin manual operation แล้ว โดย billing dashboard ไม่แสดงคลินิก draft; payment automation และ pricing approval เป็นงานถัดไป

คลินิกทีม CliqManual admin

10. Admin Module

Ops Console Ready

มี Admin Operations Console สำหรับทีม Cliq ที่ admin.cliq.care: overview, ตรวจคลินิก/อนุมัติ/ขอแก้ไข/ไม่ผ่าน/ระงับใช้งานจริง, preview รูปโลโก้/อาคาร/แพทย์, monitoring cockpit, billing dashboard พร้อมลิงก์ production และ shell สำหรับ support, queue, review, notification, audit และ settings

ทีม CliqOperationsadmin.cliq.care
06

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

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

PWA UI Stack Decision

Selected

เลือกใช้ stack นี้ร่วมกันสำหรับ Patient PWA, Clinic PWA และ Cliq Team PWA โดยให้ความสำคัญกับคุณภาพ UI มากกว่าความง่ายหรือความเร็วในการพัฒนา ตอนนี้ Cliq Team Admin PWA ถูก deploy ใช้งานจริงแล้ว ส่วน Patient/Clinic PWA ยังเป็น later phase

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

Next.js + TypeScript + Tailwind CSS + shadcn/ui + Framer Motion

Selected

เลือกเป็น PWA UI stack เพราะเหมาะกับทั้ง mobile-like PWA และ desktop dashboard ทำ UI แบบ healthcare SaaS ได้ดี รองรับ design system กลาง และใช้ component ร่วมกันได้หลาย platform สถานะการพัฒนาจริง: Admin PWA production ใช้งานแล้ว ส่วน Patient/Clinic PWA ยังไม่ได้เริ่ม

Nuxt + Tailwind + Nuxt UI

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

SvelteKit + Tailwind

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

Flutter Web

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

React + Vite + Tailwind

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

Patient PWA Clinic PWA Cliq Team PWA Admin PWA Live • Patient/Clinic Later

1. Frontend / Web / PWA

Selected
Next.js + TypeScript + Tailwind + shadcn/ui + Framer MotionReact + ViteVue / NuxtSvelteKitFlutter Web
เหตุผลที่เลือกรองรับ mobile-like PWA, desktop dashboard, design system กลาง และ healthcare SaaS UI
สถานะการทำจริงPatient และ Clinic PWA ยังไม่เริ่ม ส่วน Cliq Team PWA มี static Cloudflare Pages Admin Operations Console แล้วที่ admin.cliq.care โดย verification, image preview และ manual billing ใช้งานจริง
PrototypeMVP PilotProduction

2. Mobile App

iOS Stack Selected
SwiftUI สำหรับ iOS AppAndroid Native Stack • PendingReact Native / Expo • Not ChosenFlutter • Not Chosen
เหตุผลที่เลือกใช้ native iOS controls, progressive Liquid Glass และ SwiftUI App เป็น source of truth ก่อน clone design/UX ไป Android และ PWA
สถานะการทำจริงiOS SwiftUI เชื่อม production Supabase แล้วและผ่าน owner testing/production smoke หลัก; Android App และ Patient/Clinic PWA ยังเป็น later phase
SwiftUI SelectediOS App FirstAndroid/PWA LateriOS Build In Progress

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 AuthPhone OTP • Provider Setup PendingEmail • Staff FallbackLINE Login • Later Review
เหตุผลที่เลือกเชื่อม auth.uid กับ PostgreSQL RLS และ clinic membership โดยตรง
สถานะการทำจริงSupabase Auth production ใช้งานกับ iOS และ admin.cliq.care แล้ว; account alias แยก patient/clinic, cleanup/retest flow ใช้จริง ส่วน SMS/LINE, staff invitation และ recovery policy เป็น hardening ถัดไป
MVP PilotProduction

6. Realtime / Sync

Selected
Supabase RealtimePostgreSQL Source of TruthPolling Fallback
เหตุผลที่เลือกappointments, queue_entries และ notifications กระจายสถานะตาม RLS จากข้อมูลกลางชุดเดียว
งานที่เหลือเชื่อม subscription/reconnect ใน iOS และทดสอบ duplicate/out-of-order events
MVP PilotProduction

7. Notification

Soft-launch baseline selected
Firebase Cloud Messaging • LaterLINE OA Messaging • LaterIn-app notification • Soft launchAccount Email • Soft launchSMS • Later
เหตุผลที่เลือกSoft launch ใช้ in-app + account email ก่อน เพราะควบคุมง่ายกว่าและลดความเสี่ยงเรื่อง consent/delivery
งานหลัง soft launchเพิ่ม APNs/SMS/LINE พร้อม delivery tracking, retry, preference, opt-out และ support monitoring
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

Manual Baseline
Invoice + manual adminโอนเงิน + admin mark paidQR PromptPayPayment GatewayAuto debit
สถานะที่เลือกใช้ตอนนี้เริ่มจาก manual invoice/payment/dispute ใน admin.cliq.care และซ่อน draft clinics จาก billing dashboard
ข้อจำกัดpricing, payment collection automation, tax document process และ dispute SLA ยังต้อง approve ก่อน scale
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

Audit Foundation
SentryUptime MonitorGrafana / PrometheusCloud LogsDatabase Audit Log
ข้อดีตรวจ error, downtime, performance และ action สำคัญย้อนหลังได้
สถานะ/ข้อจำกัดmanual operations cadence, backup cadence และ incident log มี baseline แล้ว; Sentry/uptime automation ยังต้องเลือก โดยต้อง redact ข้อมูลสุขภาพและแยก operational log ออกจาก audit evidence
MVP PilotProduction

13. Infrastructure / Hosting

Managed Baseline Selected
Supabase Singapore • Production Core DataFirebase Functions • AI GatewayFirebase Hosting • Planning HubCloudflare Pages • Admin PWA
ข้อดีเลือกได้ตั้งแต่ 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
07

Candidate Stacks ที่น่าพิจารณา (ยังไม่ใช่ข้อสรุป)

ชุดตัวเลือกสำหรับช่วยคุย trade-off เท่านั้น ยังไม่ใช่การตัดสินใจสุดท้ายและยังไม่ได้เริ่ม implement

Candidate A: Pilot เร็ว

ยังไม่ได้เลือก
  • Next.js
  • Supabase Postgres
  • Supabase Auth + Realtime
  • SwiftUI • Selected for iOS
  • Firebase Cloud Messaging
  • Sentry

น่าสนใจเมื่อเป้าหมายคือทดสอบ workflow กับคลินิกกลุ่มเล็กอย่างรวดเร็ว โดยยอมรับ managed-service trade-off

Candidate B: Production จริงจัง

ยังไม่ได้เลือก
  • Next.js
  • NestJS
  • PostgreSQL + Redis
  • SwiftUI • Selected for iOS
  • Firebase Cloud Messaging
  • S3-compatible Storage + Monitoring

น่าสนใจเมื่อ domain และ operating model ชัดพอที่จะลงทุนกับ control, auditability และ production operations

Candidate C: Firebase-centric Services

ยังไม่ได้เลือก
  • SwiftUI • Selected for iOS
  • Firebase
  • Firestore
  • Firebase Auth
  • Firebase Cloud Messaging
  • Firebase Storage

น่าสนใจเมื่อ mobile experience และ notification เป็น priority สูง โดย native UI ใช้ SwiftUI แต่ backend services ยังต้องตัดสินใจว่าจะยอมรับ Firebase-centric architecture หรือไม่

เลือก production baseline แล้ว แต่ยังเก็บ candidate stack ไว้เป็น reference

SwiftUI ถูกเลือกสำหรับ iOS App, Supabase/PostgreSQL เป็น production data core, Firebase Functions เป็น AI Gateway, Cloudflare Pages เป็น Admin PWA และ Firebase Hosting เป็น hub แล้ว ส่วน Candidate A/B/C ยังเป็น reference สำหรับ phase ถัดไป เช่น Android, custom backend หรือ monitoring stack ที่ลึกขึ้น

08

แผนความปลอดภัย 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

09

แผน Security / PDPA

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

ขอ consent ก่อนเก็บอาการ และมี privacy notice ที่อธิบายวัตถุประสงค์อย่างชัดเจน
แยกข้อมูลแต่ละคลินิก: คลินิก A ห้ามเห็นข้อมูลของคลินิก B
คนไข้เห็นเฉพาะข้อมูลของตัวเอง และพนักงานเห็นเท่าที่จำเป็นต่อหน้าที่
ใช้ role permission, tenant isolation และ policy enforcement ที่ตรวจสอบได้
มี audit log สำหรับ action สำคัญ เช่น เปลี่ยนคิว ดูข้อมูล และแก้ invoice
เข้ารหัสข้อมูลสำคัญ ทั้งระหว่างส่งและขณะจัดเก็บตามระดับความเสี่ยง
กำหนด data retention, deletion process และผู้รับผิดชอบแต่ละประเภทข้อมูล
มี 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

10

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

Supabase Managed PostgreSQL ใช้เป็น core production database แล้ว พร้อม schema/RPC foundation, RLS, storage, verified restore drill, production smoke และ iOS/admin integration; dev project ยังใช้สำหรับทดลองก่อน push production

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

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 ต้องกำหนด retention และ access อย่างจำกัด
  • audit_logs ต้องไม่กลายเป็นที่เก็บข้อมูลสุขภาพแบบเต็มโดยไม่ตั้งใจ
  • clinic membership และ tenant boundary ต้องป้องกัน cross-clinic access
  • consent version และ purpose ต้องตรวจสอบย้อนหลังได้
  • arrival evidence ต้องเก็บระยะทาง, sampled_at, horizontal accuracy, time-window result, clinic-confirmed_at และ expiry โดยจำกัด retention

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

Production Baseline
  • เลือก Supabase/PostgreSQL และ tenant/RLS isolation เป็น baseline แล้ว
  • ทำ booking/check-in/queue transition เป็น server-side transaction และ idempotent command
  • billing baseline ใช้ invoice/payment/dispute แบบ manual admin แล้ว; automation ต้องยึด proximity check-in และ clinic arrival confirmation โดยไม่ถือ 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/PWA 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
11

Roadmap 3 ระยะ

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

1

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
2

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
3

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
  • Admin PWA production hardening ทำแล้ว: verification queue/detail UI, logo/building/doctor image preview, step 5 PDPA copy และ billing dashboard ซ่อน draft clinics
  • 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
12

ยังไม่ทำตอนนี้ / 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 หลักสร้างคุณค่าให้คนไข้และคลินิกจริงหรือไม่

13

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, phone OTP หรือวิธีอื่นเป็นหลัก?
manual billing baseline มีแล้ว; ก่อน scale ต้อง approve pricing, payment automation, tax document process และ dispute SLA อย่างไร?
15 บาทต่อ check-in ยังเป็น pricing hypothesis หลักหรือไม่ และจะมี monthly cap ไหม?
ใครเป็น data controller / data processor ในแต่ละ workflow?
จะเก็บ symptom text และ triage_sessions นานเท่าไร?
หลังเลือก OpenAI และทำ de-identification เบื้องต้นแล้ว จะกำหนด retention, vendor review และ privacy notice สำหรับ triage อย่างไร?
หมอป๋อมจะออกแบบและ 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 เมื่อเปิดใช้วงกว้าง?
จะผูก role switching ที่มีใน prototype เข้ากับ identity, staff invitation, approval และ tenant permission จริงอย่างไร?
กฎ 300 ม., location freshness 2 นาที, accuracy 100 ม., ช่วง −30/+15 นาที และ clinic confirmation 30 นาที ต้องปรับตามข้อมูล soft launch หรือไม่?
สถานะปัจจุบัน: Pilot passed • Production hardening active

Patient + Clinic Staff iOS flow ใช้ Supabase PostgreSQL production เป็น source of truth แล้ว พร้อม Auth/RLS, booking, proximity check-in, fair queue, clinic media, doctor photo sync, triage persistence, audit, support runbook และ polling refresh; production environment แยกจริงถูกสร้าง, migrate, grant platform admin, deploy Admin PWA production, verified restore drill, production smoke, first real clinic smoke, booking lifecycle, email, admin, persistence/reinstall smoke, manual operations cadence, backup cadence, incident log, legal/PDPA sanity, clinical boundary review, clinic verification/account hardening, billing dashboard baseline และ retest cleanup ผ่านแล้ว ขั้นต่อไปคือ release freeze, App Store package และ final archived production build smoke

คลังภาพ Cliq Knowledge Map

เรียงจากภาพรวมธุรกิจและระบบ ไปจนถึง platform, stack, security, billing และ operations

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

North Star

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

Design Principles

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