ฉลากกินไม่แบ่งเบื้องหลังการสร้าง

กระบวนการพัฒนา

แอปใช้ ui-click สั้นสำหรับปุ่มและเมนู มีสวิตช์เสียงใน Profile และบันทึก preference ระบบเสียงเป็นบริการร่วม ไม่สร้าง player ใหม่ในทุกปุ่ม

1. โหลด preference และเตรียม AudioPool แบบใช้ซ้ำหนึ่งชุด
2. ต่อเสียงผ่าน interaction ของ Material controls และแยก disabled controls
3. จำกัด pool ไม่เกินสาม player และเรียกเล่นเสียงแบบไม่รอให้จบ

ข้อจำกัดในการออกแบบ

เสียงอาจไม่พร้อมเมื่อแตะครั้งแรก หรือ native audio plugin อาจไม่พร้อมใน widget test หาก flow หลักรอเสียง การตอบสนองของแอปจะผูกกับบริการที่ล้มได้

วิธีแก้ในระบบ

ถ้า pool ยังไม่พร้อมให้เริ่ม initialize แล้วกลับทันที จัดการ error ภายในบริการ ใช้ ambient session บน iOS และไม่แย่ง audio focus บน Android

ผลและขอบเขตการตรวจ

source มี widget tests สำหรับปุ่มที่กดได้ต้องขอเสียงหนึ่งครั้ง และปุ่ม disabled ต้องไม่ขอเสียง สิ่งนี้ตรวจ interaction contract ไม่ได้ยืนยันเสียงที่ได้ยินจากลำโพง

อ้างอิง: apps/mobile/lib/core/feedback/ui_sounds.dart + apps/mobile/test/core/ui_sounds_test.dart

กระบวนการพัฒนา

วงจรเลือกฉลากต้องเชื่อมค้นหาในเครื่อง ตะกร้า checkout และ settlement ฝั่งเซิร์ฟเวอร์ ใน monorepo ที่ Flutter กับ Go ใช้ Protobuf contract ร่วมกัน

1. ค้นหา inventory ในเครื่อง และส่งรายการเมื่อผู้เล่นยืนยัน checkout
2. ส่ง idempotency key พร้อม request fingerprint เพื่อระบุการ retry ของรายการเดิม
3. commit order, ticket blob, request record และเครดิตใน transaction เดียว

ข้อจำกัดในการออกแบบ

network timeout ทำให้ client ไม่รู้ว่า server รับรายการไปแล้วหรือยัง ถ้า retry สร้างรายการใหม่ ผู้เล่นอาจถูกหักเครดิตซ้ำ ส่วน worker ที่ล้มกลาง settlement ต้องทำต่อโดยไม่สุ่มผลใหม่

วิธีแก้ในระบบ

key เดิมและ payload เดิมคืน order เดิม ถ้า payload ไม่ตรงให้ปฏิเสธ ผล draw ที่บันทึกแล้วแก้ทับไม่ได้ และมี marker กัน leaderboard บวกยอดซ้ำ

ผลและขอบเขตการตรวจ

atomicity contract ระบุวิธี recovery และ rejection ชัดเจน ขณะที่ production API lane ใช้ read-only checks ไม่สร้างรายการหรือออกรางวัลจริงเพื่อสาธิต

อ้างอิง: docs/atomicity-and-idempotency.md + docs/ticket-purchase-ux.md

กระบวนการพัฒนา

ก่อน redesign มี audit จาก source, widget tests และภาพ Android ที่เก็บไว้ เพราะช่วงนั้นยังเปิด runtime ของทุก target ไม่ได้ จึงต้องแยกข้อค้นพบจากภาพกับผลการกดใช้งานจริง

1. ทำ problem map เรื่อง hierarchy, type, color, navigation และ state ของแต่ละหน้า
2. กำหนด screen ownership, domain components และ design tokens แทนชุด card ซ้ำ ๆ
3. ตรวจ flow เลือกเลข–ตรวจรายการ–ผลลัพธ์ และข้อความที่ผู้ใช้เห็นให้เป็นศัพท์ของ product

ปัญหาที่บันทึกไว้

Home มี implementation เก่าซ่อน Offstage คู่กับหน้าใหม่ สี cream/navy/red ใน feature ขัดกับ theme สีน้ำเงิน และบางหน้ามีข้อความ gRPC, hash หรือ UID ที่ไม่ช่วยให้ผู้ใช้ตัดสินใจ

วิธีแก้ในระบบ

รายงานวางทางแก้ที่ระดับ shared theme และเจ้าของหน้าจอ พร้อมใช้คำอย่างฉลาก เครดิต และผลรอบ แทนการเผยรายละเอียดระบบใน flow หลัก

ผลและขอบเขตการตรวจ

นี่คือข้อค้นพบและแนวทางจาก audit 5 ส.ค. ไม่ใช่คำยืนยันว่าทุกข้อถูกปิดแล้ว หลักฐาน runtime และ acceptance ของแต่ละการแก้ต้องตรวจแยก

อ้างอิง: docs/ui-redesign-audit.md · 5 Aug 2026

กระบวนการพัฒนา

startup และ navigation ใช้ local cache เป็นภาพแรก แล้ว refresh จากเครือข่ายเบื้องหลัง เพื่อไม่ให้ทุกการเปลี่ยนหน้ารอ API ซ้ำ

1. เก็บ Protobuf snapshot ของ bootstrap, รอบ, orders, ผล, อันดับ และ profile
2. rehydrate เมื่อกลับ foreground และคง content ไว้ระหว่าง network refresh
3. ล้าง order เก่าหาก server ยืนยันว่ารอบปัจจุบันยังไม่มีรายการ

ปัญหาที่บันทึกไว้

refresh ที่แทนทั้งหน้าด้วย loading ทำให้ข้อมูลที่อ่านได้อยู่แล้วหายชั่วคราว อีกด้านหนึ่ง cache ที่ไม่ผูกกับรอบอาจเอาฉลากของรอบเก่ามาแสดงเป็นของวันนี้

วิธีแก้ในระบบ

ให้ cache เป็น first render source เฉพาะ snapshot ที่มีความหมาย แล้ว reconcile กับ server โดยไม่ทิ้ง content ทั้งหน้า พร้อม invalidate ข้อมูลของรอบเก่า

ผลและขอบเขตการตรวจ

รายงาน 11 ส.ค. ระบุ Flutter 126 tests, Android cache-first E2E และ purchase E2E 2 กรณีผ่าน เป็นรายงานคนละชุดกับ store-readiness ที่มี 116 tests

อ้างอิง: docs/qa/cache-first-startup-e2e-2026-08-11.md

การรวมระบบ

1. เริ่มจาก monorepo ที่มี Flutter app, Go API, Protobuf contract, infrastructure และ scripts ในที่เดียว
2. ทำเส้นทาง anonymous login → ค้นหาเลข → ส่งฉลาก → settlement ฝั่งเซิร์ฟเวอร์ → ผลและอันดับ ให้เชื่อมกันครบ
3. แยกการทดสอบที่แก้ข้อมูลออกจาก production read-only checks เพื่อเช็กระบบจริงโดยไม่ออกรางวัลหรือเพิ่มเครดิตระหว่าง QA

ผลตรวจ

รายงาน 11 ส.ค. 2026 บันทึก Go tests, Flutter 116 tests, static analysis และ journey catalog 100 รายการผ่าน พร้อมตรวจ API แบบ authenticated read-only ข้อมูลนี้เป็นหลักฐาน ณ วันที่รายงาน ไม่ใช่การรันทดสอบซ้ำในวันนี้

การส่งขึ้น Store

เตรียม production flavor และ AAB โดยตรวจ package และ Firebase configuration ให้ตรงกับบริการจริง รายงาน 11 ส.ค. 2026 บันทึก health check, authenticated API แบบ read-only, notification และ artifact ก่อนขึ้น Store หน้า product มีลิงก์ดาวน์โหลดทั้ง Android และ iOS

บันทึกอ้างอิง

• docs/ticket-template-art-manifest.md + docs/ux-ui-redesign/asset-reviews/29-ticket-public-share-v4.md
• apps/mobile/lib/core/feedback/ui_sounds.dart + apps/mobile/test/core/ui_sounds_test.dart
• docs/atomicity-and-idempotency.md + docs/ticket-purchase-ux.md
• docs/ui-redesign-audit.md · 5 Aug 2026
• docs/qa/cache-first-startup-e2e-2026-08-11.md
• README.md
• docs/architecture.md
• docs/qa/gcp-e2e-store-readiness-2026-08-11.md