คุณเป็นทีมวิศวกรรมและออกแบบที่รับผิดชอบปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/
ทำงานใน repository ของแอปที่ผูกกับ deployment จริง ไม่ใช่แก้เว็บไซต์รายงาน
วัตถุประสงค์: แก้ความถูกต้อง UX/UI การใช้คำ และความเร็วตาม UAT รอบ 2 พร้อมตรวจข้อบกพร่องเดิม

เริ่มจากอ่าน AGENTS.md และ source ปัจจุบัน ยืนยันว่าแต่ละข้อยังเกิดบน revision นี้ แยก confirmed bug, design improvement, business decision และ measurement proposal ก่อนลงมือ
ลำดับ: ความถูกต้อง R2-01–05 → keyboard/mobile/error/loading → wording/components → cache/data loading/bundle ใช้ component และ framework ที่มีอยู่ รักษาผล UAT เดิมจนกว่าจะมี retest ใหม่
รอบ 2 ตรวจ UI, DOM, public frontend และ DevTools ฝั่ง Admin; ไม่ใช่การตรวจ backend ทั้งระบบ และ Sales/Delivery workspace ยังติด login อย่าสมมติว่าทดสอบผ่าน
Performance ที่มีเป็นตัวอย่าง local บนเครื่องเดียว ไม่ใช่ p75 ผู้ใช้จริง ต้องวัด cold/warm, list→detail→back, filter และ slow network ด้วย dataset/อุปกรณ์/เงื่อนไขเดียวกันก่อนและหลังแก้
cache ต้องผูก organization/role/branch/permission scope; ตรวจราคา สต็อก สิทธิ์ และเงินล่าสุดก่อนยืนยัน ห้าม public-cache ข้อมูลผู้ใช้ ห้าม prefetch mutation หรือแสดงสำเร็จทางการเงินล่วงหน้า
ใช้ fixture สังเคราะห์ใน local/test ไม่จ่ายเงินจริง ไม่ส่งไฟแนนซ์จริง ไม่ลบหลักฐาน และไม่เปลี่ยน production เพื่อทดสอบ ส่งงานเป็นชุดตรวจทานได้ พร้อมหลักฐานก่อน/หลัง test และข้อจำกัด; ไม่ merge/deploy แอป production โดยไม่มีคำสั่งเพิ่มเติม

=== งานรอบ 2 ===
ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-01 — ใช้ขอบเขตเดียวกันสำหรับจำนวนงานเปิด
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Dashboard · งานขาย · Reports
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI และ frontend
สิ่งที่พบ: หน้างานขายระบุ 67 งานที่เปิดอยู่ แต่ผลรวม 8 ขั้นและ Reports ระบุ 65 งาน; รายการมีทั้งสถานะเสร็จสิ้นและยกเลิก ใน frontend หัวข้อใช้จำนวนรายการทั้งหมด
แนวทาง: แยกทั้งหมด / เปิดอยู่ / เสร็จสิ้น / ยกเลิก ใช้กติกา active เดียวกันใน API และทุกหน้าจอ พร้อมระบุขอบเขตของตัวกรอง
เกณฑ์รับงาน: ข้อมูลชุดเดียวกันและ filter เดียวกันต้องได้ยอดตรงกัน; เคส completed/cancelled ไม่เพิ่มตัวนับ active
อ้างอิงภายใน: R2-E01, E02, E07 · ต่อเนื่องจาก D04 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: ยืนยันกับกติกาธุรกิจและ source code ปัจจุบัน

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-02 — คอลัมน์กำไรแสดงค่าคอมมิชชัน และซ่อนค่า 0
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · ตัวเลขค่าตอบแทน
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก frontend ที่เผยแพร่
สิ่งที่พบ: คอลัมน์ “กำไร (สด)” render จาก commission_amount และใช้เงื่อนไข truthy ทำให้ 0 แสดงเป็นขีด ไม่ได้เป็นเพียงปัญหาถ้อยคำ
แนวทาง: ตกลงนิยามกำไรกับค่าคอมมิชชัน แล้วผูกแต่ละคอลัมน์กับฟิลด์ที่ถูกต้อง ใช้ null/undefined แทนกรณีไม่มีข้อมูล และแสดง 0 เป็น 0 บาท
เกณฑ์รับงาน: fixture กำไรและคอมมิชชันคนละค่า, ศูนย์, null และค่าติดลบ แสดงความหมายถูกต้องทั้ง list/detail/report
อ้างอิงภายใน: R2-E02 · source-notes · เกี่ยวข้อง D14 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: ยืนยันกับกติกาธุรกิจและ source code ปัจจุบัน

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-03 — แยกข้อความตัวอย่างออกจากข้อมูลวิเคราะห์จริง
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · AI summary
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI และ frontend
สิ่งที่พบ: ข้อความ AI เรื่องคอขวด ค่าเฉลี่ย 1.1/2.4 วัน และปิดเร็วกว่า 1.8 วันเป็น literal ในไฟล์หน้า Sales; ข้อความ AI แสดงแม้ข้อมูลรายการยังโหลดไม่เสร็จ
แนวทาง: นำข้อความตายตัวออกจาก insight จริง หรือระบุ “ตัวอย่างการวิเคราะห์” ให้ชัด ก่อนเปิดใช้จริงต้องมีข้อมูลอ้างอิง ช่วงเวลา จำนวนตัวอย่าง เวลาอัปเดต และลิงก์ดูรายการที่เกี่ยวข้อง
เกณฑ์รับงาน: เปลี่ยน dataset/ช่วงเวลาแล้ว insight เปลี่ยนตาม; ไม่มีข้อมูลหรือโหลดผิดพลาดต้องไม่สร้างข้อสรุปเชิงข้อเท็จจริง
อ้างอิงภายใน: R2-E02, E04 · source-notes (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-04 — เครื่องหมายถูกต้องหมายถึงผ่านเงื่อนไขจริง
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: รายละเอียดงานขาย · เอกสาร
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI; กติกาต้องตรวจต่อใน backend
สิ่งที่พบ: งานทดสอบเดิมที่ยังไม่มี VIN แสดงเครื่องหมายถูกครบ 7 ขั้น และสถานะภายใน delivery; ส่วนเอกสารมีทั้งสร้างแล้ว/ยืนยันแล้ว จึงอาจถูกอ่านว่าเสร็จสมบูรณ์ทั้งกระบวนการ
แนวทาง: ใช้ progress indicator ที่แยกเสร็จแล้ว / ขั้นปัจจุบัน / ยังไม่เริ่ม / ติดเงื่อนไข โดยอ้างอิงสถานะและหลักฐานรายขั้น แยกเอกสารร่างออกจากฉบับออกจริง
เกณฑ์รับงาน: fixture ไม่ครบ prerequisite ต้องไม่เห็นเครื่องหมายสำเร็จ; การแก้ UI ต้องไม่ข้าม validation ฝั่ง server
อ้างอิงภายใน: R2-E05 · ต่อเนื่อง D09/D10 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: ยืนยันกับกติกาธุรกิจและ source code ปัจจุบัน

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-05 — ตัวกรองสาขาไม่ตรงกับรายการจริง
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · ตัวกรองสาขา
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ทดสอบ UI และตรวจ frontend
สิ่งที่พบ: เลือกบางนาแล้วไม่พบรายการ ทั้งที่รายการทั้งหมดมีสาขาบางนา; ไม่มีรังสิตใน dropdown ใน frontend ตัวเลือกเขียนตายตัวและเทียบ branch_name กับข้อความที่เลือกโดยตรง
แนวทาง: ใช้ branch_id เป็น value และใช้ชื่อเพื่อแสดงผล ดึงตัวเลือกจาก master data ตามสิทธิ์ เพิ่มจำนวนผลลัพธ์และปุ่มล้างตัวกรอง
เกณฑ์รับงาน: ทุกสาขาที่มีข้อมูลกรองได้ครบ; เปลี่ยนชื่อสาขาไม่ทำให้กรองเสีย; สาขาที่ไม่มีสิทธิ์ไม่ปรากฏหรือเรียกข้อมูลได้
อ้างอิงภายใน: R2-E02, E14 · ต่อเนื่อง D05 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-06 — ใช้ link/button จริงกับสิ่งที่กดได้
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · รายละเอียด · แถบเครื่องมือ
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก DOM และ frontend
สิ่งที่พบ: การ์ดขั้นเป็น div onClick, แถวเป็น tr onClick, “เปิด →” และ “ดู PDF” เป็น a ไม่มี href; ช่องค้นหา Sales ไม่มี label หรือ aria-label ใน DOM
แนวทาง: ใช้ button พร้อม aria-pressed สำหรับกรองขั้น และ link href จริงสำหรับเปิดงาน/PDF ใส่ชื่อ action ที่สื่อความหมายและชื่อช่องค้นหา รองรับ Tab, Enter/Space และ focus ที่เห็นชัด
เกณฑ์รับงาน: ทำ flow ค้นหา → กรองขั้น → เปิดงานได้ด้วย keyboard; ชื่อ control อ่านรู้เรื่อง; action ที่ยังใช้ไม่ได้บอกเหตุผล
อ้างอิงภายใน: R2-E02, E05 · source-notes (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-07 — ยกระดับตัวอักษรที่ใช้ตัดสินใจให้อ่านง่าย
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Dashboard · ตารางและข้อความรอง
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: วัด computed style จาก DOM
สิ่งที่พบ: พบข้อความรอง 10–11px หลายตำแหน่งและหัวข้อ panel 14px ทำให้ข้อมูลหนาแน่นแม้จอ desktop 1280px; ขนาดเล็กเพียงอย่างเดียวไม่ใช่ข้อสรุปว่าไม่ผ่าน WCAG
แนวทาง: กำหนด type tokens: เนื้อหา 16px, ตาราง/label ประจำ 14px, metadata 12–13px, หัวข้อหน้า 24–28px ใช้ line-height ที่อ่านภาษาไทยชัดและ tabular numbers สำหรับยอดเงิน
เกณฑ์รับงาน: อ่านข้อความสำคัญได้ที่ขนาดปกติและขยาย 200%; ไม่ตัดหน่วยเงิน สถานะ หรือวันครบกำหนด; ตรวจ contrast ของคู่สีจริง
อ้างอิงภายใน: R2-E01 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/elements/typography/overview/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-08 — ทำ icon และสีให้สื่อความหมายชุดเดียวกัน
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Dashboard · Sales · Settings
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: สังเกต UI และแนวทางออกแบบ
สิ่งที่พบ: มี Carbon outline icons ปน ⏱, ⭐, ⚠, 🛈, 🧪; สถานะเริ่มงานบางขั้นใช้ tag สีเหลือง แม้ไม่ได้ระบุความเสี่ยงหรือเกินกำหนด
แนวทาง: คง mood เรียบ ชัด น่าเชื่อถือ ใช้ icon ชุดเดียวขนาด 16/20px; สีฟ้าสำหรับ action/กำลังทำ สีเขียวสำหรับสำเร็จ สีเหลืองเมื่อควรระวัง สีแดงเมื่อผิดพลาดหรืออันตราย ใช้ข้อความกำกับทุกสถานะ; ดาวใช้กับคะแนนได้
เกณฑ์รับงาน: สถานะเดียวกันใช้สีและคำเดียวกันทุกหน้า; แยกสถานะได้เมื่อมองแบบ grayscale; icon-only มี accessible name และเป้ากดเหมาะกับอุปกรณ์
อ้างอิงภายใน: R2-E01, E02, E11 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/elements/color/usage/; https://carbondesignsystem.com/elements/typography/overview/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-09 — หยุดการล้นแนวนอนของทั้งหน้า
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · mobile 390px
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ทดสอบ viewport และวัด DOM
สิ่งที่พบ: ที่ viewport 390px เมื่อปิดเมนูแล้ว document scrollWidth ยังเป็น 661px; เนื้อหาตารางและชุด Funnel ไม่พอดีกับพื้นที่ใช้งาน
แนวทาง: ให้ page layout ยุบตามจอ จัด Funnel เป็นชุดที่อ่านได้และใช้ card/list รายงานขายบนมือถือ หรือให้เลื่อนเฉพาะกรอบตารางที่มีชื่อกำกับ เก็บ action หลักให้เห็น
เกณฑ์รับงาน: 320/390/768px ไม่มีการเลื่อนทั้งหน้าแนวนอน; เปิดงานและกรองได้ด้วย touch; ข้อยกเว้นตาราง 2 มิติใช้เฉพาะบริเวณตาราง
อ้างอิงภายใน: R2-E12 · ต่อเนื่อง D13 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html; https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-10 — แสดง loading ตามส่วน พร้อมเก็บข้อมูลเดิมตอน refresh
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Dashboard · Sales · ส่งมอบ · ค่าตอบแทน
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ทดสอบการเปลี่ยนหน้าและกลับหน้าซ้ำ
สิ่งที่พบ: กลับหน้า Sales แล้วเห็น “กำลังโหลดข้อมูล...” ใหม่; หน้า Delivery ระหว่างโหลดแสดงตัวนับ 0 ก่อนเปลี่ยนเป็นข้อมูลจริง ข้อความ AI ยังแสดงอยู่ในช่วงนั้น
แนวทาง: เข้าแรกใช้ skeleton ขนาดตรงกับ panel/table; refresh ใช้ข้อมูลเดิมพร้อมสถานะ “กำลังอัปเดต” และเวลาอัปเดตล่าสุด; action บันทึกใช้ inline loading เฉพาะปุ่ม แยก 0 ออกจากยังไม่ทราบ
เกณฑ์รับงาน: ไม่มี 0 หรือ success ปลอมช่วงโหลด; หน้าจอไม่กระโดดเมื่อข้อมูลมาถึง; role=status/aria-busy แจ้งผลโดยไม่แย่ง focus; retry ไม่ล้างข้อมูลที่ยังใช้ได้
อ้างอิงภายใน: R2-E04, E06, E08 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/loading/usage/; https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-11 — แยก error ออกจากไม่มีรายการ
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · กรณีโหลดผิดพลาด
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ตรวจเส้นทาง error ใน frontend; ยังไม่ได้จำลอง API ล่ม
สิ่งที่พบ: getAdminSales ถูกเรียกใน useEffect; catch เขียน console.error แล้ว finally ปิด loading โดยไม่มี error state จึงมีเส้นทางที่แสดงตารางว่างเมื่อเรียกข้อมูลไม่สำเร็จ
แนวทาง: เพิ่ม error state พร้อมลองใหม่ เก็บข้อมูลล่าสุดถ้ามี และแยก no data / no match / no permission / session expired ออกจากกัน
เกณฑ์รับงาน: ทดสอบ 500, timeout, 401/403 และ empty response ในสภาพแวดล้อมทดสอบ; error ต้องไม่แสดงเป็นไม่มีงานขาย และ retry กลับมาทำงานได้
อ้างอิงภายใน: source-notes · R2-E03 สำหรับ empty state (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-12 — เตรียมตารางสำหรับข้อมูลโต โดยลดงานค้นหาต่อ keystroke
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: งานขาย · search และ table
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: พบรูปแบบใน frontend; ยังไม่ benchmark ข้อมูลขนาดใหญ่
สิ่งที่พบ: render 67 แถวพร้อมกัน และ filter ด้วย JSON.stringify(record).toLowerCase() ทุก record ทุกครั้งที่ค้นหา ไม่มี pagination ในหน้าที่ตรวจ
แนวทาง: เริ่มจากค้นเฉพาะฟิลด์ที่ผู้ใช้คาดหวังและ normalize ครั้งเดียว; เมื่อข้อมูลโตใช้ server filtering/sorting + pagination 25/50 รายการ เก็บ query ใน URL; ถ้าค้นผ่าน network ค่อย debounce 200–300ms และยกเลิก request เก่า
เกณฑ์รับงาน: dataset 1k/10k ที่สร้างเพื่อทดสอบ: จำนวน DOM rows จำกัด, ผลค้นถูกต้อง, request เก่าไม่ทับคำค้นล่าสุด; วัด latency ก่อนตัดสินใจใช้ virtualization
อ้างอิงภายใน: R2-E02 · source-notes (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-13 — ลด revalidation ของไฟล์ที่มี hash
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: JS/CSS static assets
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: วัด Network และตรวจ response headers
สิ่งที่พบ: warm reload มี 304 หลายรายการ; ตัวอย่าง JS ที่มี hash ใช้ Cache-Control: public, max-age=0, must-revalidate จึงยังต้องถามเซิร์ฟเวอร์ แม้ไม่ดาวน์โหลด body ซ้ำ
แนวทาง: สำหรับ asset ที่ชื่อเปลี่ยนตามเนื้อหาและไม่ถูกเขียนทับ ใช้ max-age ระยะยาว + immutable พร้อมเก็บ asset รุ่นเก่ารองรับ tab ที่เปิดค้าง; กำหนดนโยบาย HTML และข้อมูลผู้ใช้แยกต่างหาก
เกณฑ์รับงาน: repeat load ของ asset hash เดิมอ่าน browser cache โดยไม่ revalidate โดยไม่จำเป็น; deploy ใหม่ได้ชื่อใหม่และโหลดครบ; ห้ามนำ public immutable ไปใช้กับข้อมูลส่วนบุคคล/ราคา/สิทธิ์
อ้างอิงภายใน: R2-N01, N02 · asset headers (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-14 — ให้การกลับหน้าเดิมใช้ข้อมูลที่โหลดแล้วได้
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Sales navigation · ข้อมูลอ้างอิง
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: UI และ frontend ยืนยัน mount fetch; วิธีแก้เป็นข้อเสนอ
สิ่งที่พบ: หน้า Sales เรียก getAdminSales ตอน mount และเก็บข้อมูลใน state ของหน้า จึงโหลดใหม่เมื่อกลับเข้ามา; ยังไม่ได้ตรวจ cache ที่ backend
แนวทาง: เลือกรูปแบบ server-first หรือ client query cache ให้สอดคล้อง stack ปัจจุบัน คงผลรายการระหว่าง navigation, deduplicate request ที่ใช้ key เดียวกัน และ prefetch เฉพาะหน้าที่มีแนวโน้มเปิด ไม่ทุกดีล
เกณฑ์รับงาน: เปิด list → detail → back รักษา filter/scroll และแสดงข้อมูลเดิมทันที; ข้อมูลหมดอายุค่อย refresh; เปลี่ยนผู้ใช้หรือสิทธิ์ต้องไม่เห็น cache ของ session เดิม
อ้างอิงภายใน: R2-E04, N02 · source-notes (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://nextjs.org/docs/app/getting-started/linking-and-navigating; https://tanstack.com/query/latest/docs/framework/react/guides/important-defaults

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-15 — ตรวจส่วนประกอบ bundle ก่อนเพิ่มเทคนิคซับซ้อน
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Frontend bundle · ฟอนต์
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ขนาดไฟล์ที่วัดได้; ยังไม่ได้วัด unused coverage
สิ่งที่พบ: ไฟล์ CSS หลักประมาณ 793kB และ JS shared ประมาณ 708kB หลังคลายบีบอัด; warm reload รวม resource 2.3MB แต่ส่งผ่านเครือข่าย 25.8kB จึงไม่ควรเรียก 2.3MB ว่า download รอบนั้น
แนวทาง: ใช้ bundle analyzer/coverage หา component, icon, styles ที่เกินจำเป็น แยก PDF/กราฟหนักโหลดเมื่อเปิด เลือก font family/weight ที่ใช้จริง คง Thai glyphs และกำหนดขนาดกราฟ/ภาพล่วงหน้า
เกณฑ์รับงาน: เทียบ compressed transfer, parse/evaluate time และ coverage ก่อน/หลังใน cold/warm load เดียวกัน; ไม่ตัด style ที่จำเป็นและไม่ lazy-load เนื้อหา LCP หลัก
อ้างอิงภายใน: R2-N01 · asset downloads (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://web.dev/articles/vitals; https://nextjs.org/docs/app/getting-started/linking-and-navigating

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-16 — บอกช่วงเวลาและนิยามตัวเลขให้ครบ
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Dashboard · Reports
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI
สิ่งที่พบ: หัวข้อ Dashboard ใช้ “วันนี้” แต่มีเดือนนี้และ YTD ปนกัน; Pipeline เรียง 1,8,4,6,7,5,2,3; Reports ใช้ “ยอดจัด/มูลค่า” ซึ่งรวมสองความหมายไว้ในหัวข้อเดียว
แนวทาง: เรียกหน้าว่า “ภาพรวมการขาย” แสดงช่วงเวลาแต่ละ metric และ data as-of; เรียงขั้นธุรกิจ 1–8 แยกสถานะปลายทาง; แยกยอดขาย/ยอดจัดไฟแนนซ์และแสดงนิยามใน tooltip หรือรายละเอียด
เกณฑ์รับงาน: ผู้อ่านระบุช่วงเวลา ฐานนับ และหน่วยได้โดยไม่เดา; Dashboard/Reports ใช้ stage ordering และนิยามชุดเดียวกัน
อ้างอิงภายใน: R2-E01, E07 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-17 — เปลี่ยนคิวส่งมอบให้เห็นสิ่งที่ต้องทำก่อน
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Admin · คิวส่งมอบ
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI; เป็นข้อเสนอการจัดงาน
สิ่งที่พบ: ตารางที่เรียงตามกำหนดแสดงงานส่งมอบแล้วก่อนงานค้าง และมีงานค้างที่วันกำหนดผ่านมาแล้วโดยไม่มีป้ายเกินกำหนด; คะแนนทีมไม่มีจำนวนผู้ประเมินให้เห็นในตาราง
แนวทาง: default เป็นคิวต้องทำ แบ่งเกินกำหนด/วันนี้/ถัดไป มี filter ดูงานเสร็จแล้ว; เพิ่ม next action, owner และเหตุที่ติด พร้อมจำนวนรีวิว/ช่วงเวลาของคะแนน
เกณฑ์รับงาน: หางานเร่งด่วนได้โดยไม่ไล่อ่านทั้งตาราง; งานเสร็จไม่ปะปนในคิวที่ต้องทำ; สีแดง/เหลืองเกิดจากเงื่อนไขที่นิยามไว้
อ้างอิงภายใน: R2-E06 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/; https://carbondesignsystem.com/elements/color/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-18 — เลือก component ให้เหมาะกับข้อมูลรถที่มีหลายรุ่น
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: Inventory · ฟอร์มเพิ่มสต็อก
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ตรวจฟอร์มโดยไม่บันทึก
สิ่งที่พบ: รายการรุ่นย่อยใน native select มีประมาณ 30 ตัวเลือก หลายรายการซ้ำชื่อแบรนด์/รุ่น; สถานะ in_production แสดงเป็นรหัสภายในในตาราง และข้อความ VIN ใช้ “17 หลัก”
แนวทาง: ใช้ searchable ComboBox เมื่อรายการยาว แสดงแบรนด์/รุ่น/รุ่นย่อยแบบไม่ซ้ำ; branch ใช้ select สั้นได้ ใส่ required/optional ชัดเจน และเปลี่ยน VIN เป็น “เลขตัวถัง 17 ตัวอักษร”
เกณฑ์รับงาน: เลือกด้วยการพิมพ์ค้นและ keyboard ได้; label เชื่อม field; รหัสสถานะมีคำแปลและ fallback; ทดสอบฟอร์มแคบโดยไม่ซ่อนปุ่มยกเลิก
อ้างอิงภายใน: R2-E09, E10 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://carbondesignsystem.com/components/data-table/usage/

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-19 — ใช้คำที่ตรวจสอบได้แทนคำรับรองเชิงโฆษณา
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: ค่าตอบแทน · หน้าว่าง
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI; นโยบายการจ่ายยังไม่ได้รับรอง
สิ่งที่พบ: มีคำว่า “โปร่งใส ไม่ต้องทวง”, “โอนภายใน 2 วันทำการ” และ “กำไรสุทธิเสร็จสิ้นแล้ว”; ตารางที่ไม่มีรายการยังไม่มีข้อความอธิบายสถานะว่างในหน้าที่ตรวจ
แนวทาง: แสดงสถานะจริงและกำหนดโอนของแต่ละรายการ ถ้าเป็น SLA ให้ระบุเงื่อนไขและวันเริ่มนับ; หน้าว่างใช้ “ยังไม่มีรายการค่าตอบแทนในช่วงนี้” พร้อมช่วงเวลาที่เลือก
เกณฑ์รับงาน: ผู้ใช้แยกยอดประมาณการ/อนุมัติ/จ่ายแล้วได้; ไม่แสดงคำรับรองที่ไม่มี business rule รองรับ; กรณีไม่มีข้อมูลไม่คล้ายโหลดค้าง
อ้างอิงภายใน: R2-E08 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ


ตรวจและปรับแอป Sales Deal Platform ที่ https://sale-deal-platform.rome.agency/ ตาม R2-20 — ใช้คำไทยชุดเดียวและแยกรหัสออกจากข้อความผู้ใช้
ขอบเขต: repository ของแอปที่ผูกกับ deployment นี้ ไม่ใช่เว็บไซต์รายงาน UAT
หน้า: ทุกหน้า · ภาษาและคำศัพท์
หลักฐานรอบ 2 วันที่ 12 กันยายน 2569: ยืนยันจาก UI
สิ่งที่พบ: พบ walk_in, referral, delivery, in_production, N/A, Active และคำ Sale/เซลล์/ผู้ขาย รวมถึงข้อความ login error ภาษาอังกฤษใน UI ภาษาไทย
แนวทาง: สร้าง glossary และตัวแปลง enum กลาง แยกไม่ทราบ/ยังไม่ระบุ/ไม่เกี่ยวข้อง/0 ให้ชัด ใช้ชื่อ action ภาษาไทยที่บอกผล เช่น “ดูรายละเอียดงานขาย” และ “กำลังโหลดรายการงานขาย…”
เกณฑ์รับงาน: สำรวจข้อความทุกหน้าแล้วไม่หลุดรหัสภายใน; คำเดียวกันหมายถึงสิ่งเดียวกัน; error บอกสิ่งที่เกิดและทางแก้โดยไม่เปิดเผยข้อมูลบัญชี
อ้างอิงภายใน: R2-E01, E05, E09, E11, E13 (ขอเข้าถึงชุดภายในที่ได้รับอนุญาตหากจำเป็น)
หลักการ: ยืนยันกับกติกาธุรกิจและ source code ปัจจุบัน

อ่านแนวทาง repository และยืนยันบน revision ปัจจุบันก่อนแก้ แยก UI observation ออกจากข้อสรุป backend ที่ยังไม่ได้ตรวจ ใช้ fixture สังเคราะห์บน local/test environment และทำส่วนที่ไม่ขึ้นกับนิยามที่ขาดต่อได้
ใช้ design tokens และ component ที่มีอยู่ รองรับภาษาไทย keyboard และ mobile อย่าเพิ่ม library หรือ cache layer โดยไม่มีความจำเป็น วัดก่อน/หลังหากเป็น performance
ส่งมอบ code ที่แก้, สาเหตุ, ผลทดสอบตามเกณฑ์, ข้อจำกัด และวิธีย้อนกลับเมื่อเกี่ยวข้อง ห้ามเปลี่ยนผล UAT เป็น PASS โดยไม่มี retest และอย่าทำธุรกรรมจริง เปลี่ยนสิทธิ์ หรือตั้งค่า production เพื่อทดสอบ

=== เทคนิคให้ประเมินตามหลักฐาน ไม่จำเป็นต้องทำทั้งหมด ===
แสดงข้อมูลหลักจาก server ก่อน
ส่ง summary/หน้าแรกพร้อม route แล้วค่อยเติม panel รองด้วย streaming หรือโหลดแยกส่วน ลดการรอ client mount ก่อนเริ่มเรียกข้อมูล เลือกใช้ตาม runtime ที่ deploy จริง
ข้อกำกับ: ยังต้องตรวจสิทธิ์ทุก request; ไม่ย้ายข้อมูลส่วนบุคคลไป shared cache
วัดผล: วัด click → data-ready และ waterfall ก่อน/หลัง

cache ตามข้อมูลและสิทธิ์
ตัวอย่าง query key: [sales, organization, permissionVersion, branch, status, dateRange, page] ทดลอง stale window สั้น 30–60 วินาทีสำหรับ read list; master data ที่เปลี่ยนไม่บ่อยอาจนานกว่า
ข้อกำกับ: ช่วงเวลาเป็นค่าทดลอง; ราคา สต็อก สิทธิ์ และเงินต้องตรวจล่าสุดก่อนยืนยัน การออกจากระบบต้องล้าง cache ของผู้ใช้
วัดผล: จำนวน request ซ้ำ, cache-hit และอายุข้อมูลสูงสุด

prefetch เมื่อเห็นเจตนาจะเปิด
อุ่น route/data เมื่อ hover, keyboard focus หรือใกล้เลื่อนถึงหน้าถัดไป จำกัดจำนวนและอายุ ใช้ prefetch ของ framework ที่มีอยู่ก่อนเพิ่มระบบใหม่
ข้อกำกับ: ไม่ prefetch ทุกดีลหรือเอกสารลูกค้า และไม่ trigger mutation; เคารพการประหยัดข้อมูล/เครือข่ายช้าเมื่อรองรับ
วัดผล: detail data-ready เทียบ bandwidth ที่เพิ่ม

invalidate เฉพาะข้อมูลที่ได้รับผล
ใช้ผลบันทึกอัปเดต detail แล้ว invalidate list/summary ที่เกี่ยวข้อง Deduplicate request ที่พร้อมกันด้วย query key เดียว และยกเลิกคำค้นเก่าที่ไม่ต้องใช้
ข้อกำกับ: ไม่แสดงสำเร็จก่อน server ยืนยันเรื่องเงิน/สิทธิ์/VIN; ถ้า optimistic UI ใช้กับงานเสี่ยงต่ำต้องมี rollback
วัดผล: request ต่อหนึ่ง action และจำนวนข้อมูลเก่าหลังบันทึก

summary query แยกจากรายละเอียด
คืนเฉพาะ count/sum ที่ dashboard ต้องใช้; list ส่งเฉพาะคอลัมน์ที่แสดงพร้อม cursor/page โหลดรายละเอียดเมื่อเปิดจริง ตรวจ query plan และ index จากเงื่อนไขจริงก่อนเพิ่ม
ข้อกำกับ: ยังไม่พบหลักฐานว่า backend ปัจจุบัน query ช้า; ต้อง profile ก่อน ไม่เพิ่ม index หรือ materialized view โดยเดา
วัดผล: query latency p95, response bytes, จำนวนแถวที่อ่าน

อัปเดตเฉพาะสิ่งที่เปลี่ยน
เริ่ม polling เฉพาะตอน tab visible; ถ้าความสดจำเป็นค่อยพิจารณา SSE พร้อม event/version เพื่อ invalidate cache แทนโหลดทั้งหน้า
ข้อกำกับ: เป็นทางเลือกต่อยอดหลังวัดความต้องการ ไม่ใช่ข้อกำหนดว่าต้องใช้ WebSocket; event ต้องผูกสิทธิ์และ reconnect ได้
วัดผล: ความสดของสถานะ, request/นาที และ reconnect failures

=== ข้อบกพร่องและกติกาจาก UAT รอบแรก: ยืนยัน revision ปัจจุบันอีกครั้ง ===
คุณเป็นวิศวกรผู้รับผิดชอบปรับปรุง Sales Deal Platform ตามรายงาน UAT วันที่ 12 กันยายน 2026 ให้ตรวจ source code ปัจจุบันและแก้ข้อบกพร่องที่ยืนยันได้ทั้ง 14 รายการให้ครบ พร้อม regression tests ที่เหมาะสม

ขอบเขต: แอป repository ของแอปที่ผูกกับ deployment นี้ ที่ https://sale-deal-platform.rome.agency/ ไม่ใช่การแก้เว็บไซต์รายงาน
Baseline: 65 เคส — PASS 40 / FAIL 15 / BLOCKED 5 / NOT_RUN 5; 14 defects — P1 4 / P2 8 / P3 2
ตัวอย่างหลัก: [ดีลทดสอบ], ลูกค้า [ลูกค้าทดสอบ], MG4 ELECTRIC X สีดำ Pebble, ไม่มี VIN, วงเงิน 50,000 ส่วนลด 10,000 dealer freebie 2,200 รายได้ 37,800; ดีลถูกข้ามจาก quotation เป็น delivery โดยยังไม่ชำระเงิน ห้ามแก้หรือลบรายการนี้เพื่อซ่อน defect ให้ใช้ fixture ใหม่สำหรับ retest

แผนดำเนินงาน:
A. ทำความเข้าใจโครงสร้างและยืนยันแต่ละปัญหาบน revision ปัจจุบัน แยกสิ่งที่แก้แล้ว สิ่งที่ยังทำซ้ำได้ และนิยามธุรกิจที่ต้องยืนยัน
B. จัดการความถูกต้องของ transition/checklist ก่อน: D01, D12 แล้วความถูกต้องและการเปิดเอกสาร: D02, D03
C. แก้ข้อมูลข้ามหน้าจอและข้ามบทบาท: D09, D10, D14 แล้วตัวชี้วัด/สาขา/summary: D04, D05, D07
D. แก้ validation และการใช้งาน: D06, D13, D08, D11
E. รัน regression ตามเคสด้านล่างและทดสอบ happy path ตั้งแต่สร้างดีลจนส่งมอบบนระบบทดสอบ ถ้า sandbox ของเงินจอง/ไฟแนนซ์/Payroll ยังไม่พร้อม ให้ระบุ blocker ตามจริง ไม่ทำเครื่องหมายผ่าน

ประเด็นที่ห้ามสรุปเป็น defect เพิ่มโดยไม่มีหลักฐาน: O01 สิทธิ์อ่านข้ามเจ้าของ/สาขา ต้องมี RBAC matrix; O02 ฐาน finance ก่อน/หลังส่วนลดต้องมี business rule; O03 QR/บัญชี/สลิปต้องมี test configuration; O04 timezone/รายงานรายเดือนต้องยืนยัน; O05 ปุ่มปิด Delivery ที่ checklist ว่างยังไม่ได้ทดสอบ submit ที่ server; O06 เก็บดีล UAT ไว้ทำซ้ำ

วิธีทำงาน:
1. เปิด repository แอป repository ของแอปที่ผูกกับ deployment นี้ และอ่าน AGENTS.md/แนวทางโครงการก่อน เริ่มจาก route ที่เกี่ยวข้องแล้วตามไปยัง service, schema และ endpoint จริง ห้ามแก้เพียงเว็บไซต์รายงาน UAT
2. รายงานนี้เป็นหลักฐานจาก UI เมื่อ 12 ก.ย. 2026 ไม่ใช่การตรวจ source code จึงต้องยืนยันปัญหาบน revision ปัจจุบันและหาสาเหตุจาก code ก่อนแก้ ถ้าแก้ไปแล้วให้ตรวจ regression และรายงานหลักฐาน
3. แก้เป็นส่วนที่ตรวจทานได้ รักษา public contract และกฎธุรกิจเดิมที่ถูกต้อง ถ้าขาดนิยามธุรกิจให้ระบุคำถามเฉพาะและทำส่วนที่ไม่ขึ้นกับคำตอบต่อ ห้ามเดากฎสำคัญเพื่อให้ test ผ่าน
4. ใช้ fixture หรือข้อมูลสังเคราะห์ใน local/test environment ทดสอบทั้ง positive, negative, reload/persistence และ role ที่เกี่ยวข้อง ห้ามจ่ายเงินจริง ส่งไฟแนนซ์จริง ลบข้อมูลจริง หรือเปลี่ยนสิทธิ์/ราคา production
5. สรุป root cause, ไฟล์ที่แก้, test ที่รันและผล, ข้อจำกัด, migration/backfill ที่จำเป็น และวิธี rollback หากเกี่ยวข้อง อย่าเปลี่ยนผล UAT เดิมเป็น PASS จนกว่าจะมีการ retest ที่ระบุวันและ revision ชัดเจน
6. ทำ implementation และตรวจสอบให้เสร็จใน branch งานนี้; ไม่ merge หรือ deploy production โดยไม่มีคำสั่งเพิ่มเติม

รายการงานและเกณฑ์รับงานทั้งหมด:

D01 (P1) ข้ามใบจองไปออกรถได้โดยยังไม่รับเงินจอง
วิธีทำซ้ำ: ใช้ [ดีลทดสอบ] ที่ Step 5 รอชำระ → กดแท็บ 7 เตรียมรถ → ถึงวันนัด ไปส่งมอบ → รีโหลด/เปิดรายการ → เปิด Audit
ผลที่พบ: Audit บันทึก quotation → delivery; Admin ยืนยัน current stage delivery; ไม่มี VIN ไม่มีงานเตรียม ไม่ได้ชำระเงิน
แนวทาง: ค้นหาเส้นทางเปลี่ยน stage จากแท็บ ขั้นถัดไป และ endpoint ที่เกี่ยวข้อง รวมการอัปเดตแบบทั่วไป ใช้กฎ transition ร่วมกันที่ server ตรวจสถานะปัจจุบันและ prerequisite ภายใน transaction; UI ใช้กฎเดียวกันเพื่อสื่อสารเหตุผล ห้ามให้การเปิดแท็บเปลี่ยน stage เอง กฎเงินจอง VIN และไฟแนนซ์ต้องตรง workflow ที่เจ้าของธุรกิจรับรอง โดยแยกเส้นทางซื้อสดจากสินเชื่อ
เกณฑ์: ดีล quotation ที่ยังไม่ชำระต้องไป delivery ไม่ได้ผ่านทั้ง UI และ API; การอ่านแท็บไม่เปลี่ยนข้อมูล; คำขอซ้ำหรือพร้อมกันไม่ข้ามเงื่อนไข; happy path ที่ prerequisite ครบยังทำงาน; audit บันทึกเฉพาะ transition สำเร็จ
หลักฐาน: E47, E52, E55, E66b, E67

D12 (P1) Checklist ส่งมอบมีรายการสำเร็จและของแถมที่ไม่ได้เลือก
วิธีทำซ้ำ: ดีล UAT เลือกกันสาดและสปอยเลอร์ → เปิด Step 8 ก่อนมี VIN/งานเตรียม
ผลที่พบ: ติ๊ก 3/5 ล่วงหน้า รวมตรวจ VIN และ wallbox ติดตั้งแล้ว ทั้งที่ไม่ได้เลือก wallbox
แนวทาง: ตรวจการสร้าง checklist และค่าเริ่มต้นของ VIN/ของแถม/wallbox ผูก item กับตัวเลือกของดีลและงานจริง ห้ามติ๊กสำเร็จเพียงเพราะสร้างดีล กำหนดผู้ยืนยันและเวลายืนยัน ตรวจข้อจำกัดก่อนปิดงานที่ server และรักษาประวัติเมื่อเปลี่ยนของแถม
เกณฑ์: ดีลไม่มี VIN และไม่ได้เลือก wallbox ต้องไม่มีรายการ wallbox ติดตั้งแล้วหรือ VIN ยืนยันแล้ว; dealer/OEM freebies ที่เลือกปรากฏถูกต้อง; ปิดงานไม่ได้เมื่อ required checklist ไม่ครบ; ตรวจว่าการอ่านหน้าไม่แก้สถานะ
หลักฐาน: E38, E50

D02 (P1) ใบจองแสดงสีรถผิดจากสเปกที่เลือก
วิธีทำซ้ำ: เลือก MG4 ELECTRIC X สีดำ Pebble → บันทึก → Step 4 โปร 0%/48 งวด → เปิด Step 5
ผลที่พบ: ใบจองแสดง NEW MG4 ELECTRIC X · ขาว Arctic
แนวทาง: ตรวจ mapping สีจาก ordered specification และ VIN รวม template ใบจอง ลบ fallback สีที่ทำให้เอกสารดูเหมือนยืนยันข้อมูลจริง หากยังไม่ทราบให้แสดงสถานะข้อมูลขาด กำหนด snapshot/version ของใบจองเมื่อยืนยัน และไม่เปลี่ยนเอกสารที่ออกแล้วเงียบ ๆ
เกณฑ์: เลือก MG4 ELECTRIC X สีดำ Pebble แล้วบันทึก/รีโหลด/เปิดใบจอง ต้องเป็นสีเดียวกัน; ทดสอบสีอื่นและดีลไม่มี VIN; หากจัด VIN สีต่างจากสเปกต้องแจ้ง conflict
หลักฐาน: E37, E47

D03 (P1) ดู PDF จากหน้า Admin ไม่เปิดเอกสาร
วิธีทำซ้ำ: Admin → /sales/18 → คลิก ดู PDF แถวใบเสนอราคา
ผลที่พบ: ไม่เกิดเอกสาร/การนำทาง; A ของทั้งสามแถวไม่มี href
แนวทาง: ตรวจว่าระบบมี PDF generator หรือ document storage อยู่แล้วหรือไม่ ผูกปุ่มกับเอกสารของดีลที่ถูกต้อง ตรวจสิทธิ์ตอนอ่านและสร้างเอกสาร แสดงสถานะกำลังสร้าง/ยังไม่พร้อม/ผิดพลาด อย่าแสดงลิงก์พร้อมใช้งานโดยไม่มีปลายทาง และอย่าแทน PDF ด้วยหน้าว่างหรือข้อมูล mock
เกณฑ์: คลิกแล้วเปิดหรือดาวน์โหลด PDF ที่อ่านได้ เนื้อหาและเลขดีลถูกต้อง; ทดสอบไม่มีเอกสาร การสร้างล้มเหลว และผู้ใช้ไม่มีสิทธิ์; ไม่มีลิงก์หมดอายุที่ UI ยังบอกว่าใช้ได้
หลักฐาน: E08

D09 (P2) สเปกสั่งจองไม่ถูกแสดงครบในหน้าปลายทาง
วิธีทำซ้ำ: บันทึกรุ่น MG4 X BEV โดยรอจัด VIN → เปิด Step 4, รายการ Sales และห้อง payment
ผลที่พบ: Step 4 แจ้งไม่มีประเภทพลังงาน; รายการแสดงยังไม่ระบุ; payment แสดง Model N/A
แนวทาง: ตรวจ resolver/view model ที่อ่านรุ่น รุ่นย่อย สี และขุมพลัง ปัจจุบันหน้าสเปกมีข้อมูลแต่ finance/payment/listing บางแห่งไม่มี กำหนดแหล่งข้อมูลสำหรับ ordered specification ก่อนมี VIN และใช้ VIN หลังจัดรถตามกฎที่รับรอง แสดง conflict เมื่อข้อมูลไม่ตรง และอย่าสร้างค่าขุมพลังจากชื่อรุ่นด้วยการเดา
เกณฑ์: ดีล MG4 ELECTRIC X ไม่มี VIN แสดงรุ่น/สี/BEV สอดคล้องบนข้อเสนอ finance payment และรายการ; หลังจัด VIN ข้อมูลถูกต้อง; missing specification แสดงข้อผิดพลาดที่เข้าใจได้แทน N/A เงียบ ๆ
หลักฐาน: E37, E44, E48, E52, E66b

D10 (P2) สถานะเอกสารยืนยันก่อนมีการดำเนินการจริง
วิธีทำซ้ำ: เปิด /sales/76 ของดีลใหม่ที่ยังไม่ยื่นไฟแนนซ์หรือออกประกัน
ผลที่พบ: ระบุสัญญา สร้างแล้ว กรมธรรม์ ยืนยันแล้ว และครบ 4/7 โดยยังไม่มีขั้นตอนเหล่านี้ในรอบทดสอบ
แนวทาง: ตรวจ source ของสถานะกรมธรรม์ HP และตัวนับเอกสาร ไม่สรุป root cause ว่าเป็น mock จนกว่าจะเห็น code แยกสถานะยังไม่เริ่ม รอข้อมูล กำลังสร้าง ออกแล้ว และผิดพลาดตาม lifecycle จริง จำนวน numerator/denominator ต้องอธิบายชุดเอกสารที่ต้องมีได้
เกณฑ์: ดีลสังเคราะห์ที่ยังไม่ยื่นไฟแนนซ์/ประกันต้องไม่แสดงว่ายืนยันหรือสร้างสำเร็จ; หลังสร้างเอกสารจริงสถานะและจำนวนเปลี่ยนถูกต้อง; retry ล้มเหลวไม่แสดงสำเร็จ
หลักฐาน: E66b

D14 (P2) รายได้ดีลเดียวกันต่างกันระหว่าง Sales และ Admin
วิธีทำซ้ำ: บันทึกดีล allowance ที่ส่วนลด 10,000 ของแถมต้นทุน 2,200 → เทียบ /deals/[ตัวอย่าง] และ /sales/76
ผลที่พบ: Sales รายได้งานขาย 37,800; Admin กำไร (เซลล์) 0; คอลัมน์รายการแสดง —
แนวทาง: ตรวจ field และสูตรของ “รายได้งานขาย” ฝั่ง Sales กับ “กำไร(เซลล์)” ฝั่ง Admin ในดีลแบบ Allowance ถ้าเป็น metric เดียวกันให้คำนวณร่วมจากข้อมูลบันทึกจริง ถ้าต่างกันให้แก้ label/คำอธิบายและแสดงความหมาย ไม่บังคับค่าเท่ากันโดยไม่ตรวจนิยาม และห้าม backfill ข้อมูลการเงินจริงโดยพลการ
เกณฑ์: กรณี 50,000 − 10,000 − 2,200 = 37,800 แสดงตัวเลขหรือคำอธิบายที่สอดคล้องทุกบทบาท; ของแถม OEM ไม่ถูกหักซ้ำ; ทดสอบดีลมี VIN/ไม่มี VIN และค่า null ที่ต้องแยกจากศูนย์
หลักฐาน: E43, E52, E66b

D04 (P2) จำนวนงานเปิดใน Funnel รวมงานที่ปิด/ยกเลิก
วิธีทำซ้ำ: เทียบ /dashboard /sales /reports ก่อนสร้างดีลทดสอบ
ผลที่พบ: 64 เทียบกับหัว Funnel 66; ส่วนต่างเท่ากับงานจบ 1 และยกเลิก 1
แนวทาง: ตรวจนิยาม active/open และสถานะ terminal ตาม enum จริง สร้าง query หรือ selector ร่วมกันสำหรับ Dashboard, Funnel, Reports ใช้ตัวกรองสาขา เจ้าของ ช่วงเวลา และ timezone แบบเดียวกัน แยกจำนวนทั้งหมดจากจำนวนงานเปิดในคำกำกับ
เกณฑ์: fixture 66 งาน มี completed 1 cancelled 1 ต้องแสดง active 64 ตามนิยามที่ยืนยัน; ผลรวมขั้นเท่ากับ active หลังใช้ filter เดียวกัน; ตรวจกรณีไม่มีข้อมูล
หลักฐาน: E03, E04, E10

D05 (P2) ตัวเลือกสาขาในงานขายไม่ตรง master data
วิธีทำซ้ำ: เปิดตัวกรองสาขา /sales → ค้นหา SDP005-D04 → เทียบ /branches
ผลที่พบ: ตัวกรองมีบางแค แต่ไม่มีรังสิต แม้สาขารังสิตเปิดใช้งาน
แนวทาง: ตรวจรายการ dropdown ที่ hardcode หรือ mapping ไม่ครบ ใช้ branch ID และรายการสาขาที่ผู้ใช้มีสิทธิ์เข้าถึงจากแหล่งเดียวกับ master รักษาการแสดงชื่อสาขาเก่าที่ถูกปิดในข้อมูลย้อนหลังโดยไม่เปิดให้เลือกสร้างงานใหม่ผิดกฎ
เกณฑ์: ตัวกรองมีรังสิตและไม่มีบางแคที่ไม่อยู่ใน master ของรอบทดสอบ; filter รังสิตคืนงานที่ถูกต้อง; ตรวจ branch ที่ไม่มีงาน ปิดใช้งาน และสิทธิ์ต่างบทบาท
หลักฐาน: E06, E21

D07 (P2) ข้อความสรุปงานของ Sales ไม่ตรงกับ Funnel
วิธีทำซ้ำ: เปิด /deals และเทียบ Funnel กับข้อความใต้แผนภาพ
ผลที่พบ: ข้อความ งานเปิด 4 / ยื่นไฟแนนซ์ 2 คงอยู่ ขณะที่ Funnel 46→47 และยื่นไฟแนนซ์ 1
แนวทาง: ตรวจว่าข้อความงานเปิด ปิดเดือนนี้ และงานไฟแนนซ์เป็นค่า mock หรือ query คนละ scope ใช้ข้อมูลจริงร่วมกับ Funnel ระบุช่วงเวลาและเจ้าของเดียวกัน จัดการ refresh หลังสร้างหรือย้าย stage
เกณฑ์: จำนวนงานเปิด/ไฟแนนซ์ตรงกับรายการที่กรองด้วย owner และช่วงเวลาเดียวกัน; สร้างดีลใหม่แล้วตัวเลขเปลี่ยนถูกต้อง; ทดสอบต้นเดือน สิ้นเดือน และไม่มีข้อมูล
หลักฐาน: E31, E52

D06 (P2) บันทึกเบอร์โทร abc ได้
วิธีทำซ้ำ: Step 1 ใส่ abc ในเบอร์โทร โดยเลขบัตรว่าง → ไปเลือกรถ → Reload → Step 1
ผลที่พบ: abc คงอยู่หลังรีโหลด; ยืนยันด้วยดีลที่สร้างในรอบนี้
แนวทาง: รับรองรูปแบบโทรศัพท์ที่ธุรกิจรองรับ เช่น ไทยและรหัสประเทศ แล้ว normalize อย่างชัดเจน ใช้ validation ฝั่ง client และ server ที่สอดคล้องกัน ปฏิเสธตัวอักษรอย่าง abc โดยคงค่าที่ผู้ใช้กรอกและอธิบายวิธีแก้ ไม่เติมเบอร์ปลอมหรือแก้ข้อมูลเดิมจำนวนมากอัตโนมัติ
เกณฑ์: abc ถูกปฏิเสธและไม่ persist; ตรวจค่าว่างตามกติกา draft, รูปแบบ valid, ช่องว่าง/ขีด/รหัสประเทศตามกติกาที่รับรอง; reload ไม่ทำให้ข้อมูล invalid กลายเป็นค่าที่บันทึกได้
หลักฐาน: E36

D13 (P2) หน้าจอ Sales บนมือถือแสดงสรุปงานไม่ครบ
วิธีทำซ้ำ: ตั้ง 390×844 → เปิด /deals/[ตัวอย่าง] → ปิดเมนูด้านข้าง
ผลที่พบ: แผงสรุปด้านขวาถูกตัดนอกจอ ขณะที่ document กว้าง 390; หัวแอปตัดบรรทัดซ้อน
แนวทาง: ตรวจ layout 390×844 โดยปิดเมนูแล้ว พิจารณาจัดสรุปข้อเสนอเป็นแถวเดียวหรือแผงขยายที่เข้าถึงได้ แก้ min-width/grid/overflow และหัวข้อที่ชนกัน ให้ข้อมูลและปุ่มหลักยังเข้าถึงได้ ไม่ซ่อนปัญหาด้วย overflow:hidden ทั้งหน้า
เกณฑ์: ที่ 390×844 และ 360px ข้อมูลรายได้/ยอดรวมและปุ่มสำคัญอ่านและกดได้; ตารางที่กว้างเลื่อนในกรอบได้; ไม่มี clipping; desktop 1280px ยังใช้งานได้และ keyboard focus ไม่หลุด
หลักฐาน: E59

D08 (P3) ข้อความข้อมูลบังคับขัดกับกติกาบันทึก draft
วิธีทำซ้ำ: เปิด Step 1 ว่าง → ไปเลือกรถ; ลองเลขบัตร 123 เพื่ออ่านข้อความ validation
ผลที่พบ: ข้ามด้วยเลขบัตรว่างได้ และ error ระบุเว้นว่างก่อนได้ แต่หัวฟอร์มบอกเป็นข้อมูลขั้นต่ำบังคับ
แนวทาง: ตรวจ flow ที่ยอมให้บันทึก draft โดยยังไม่มีเลขบัตร เปลี่ยนเครื่องหมายบังคับและคำอธิบายให้ตรงกับกฎจริง ระบุว่าข้อมูลใดต้องครบในขั้นใด ห้ามเพิ่มข้อบังคับเลขบัตรทุกขั้นจากการคาดเดา เพราะหน้าจอปัจจุบันระบุให้เว้นไว้ได้
เกณฑ์: ข้อความขั้นต่ำ/เครื่องหมาย * และ error ไม่ขัดกัน; draft ที่ถูกกฎยังบันทึกได้; เลขบัตร 123 ยังถูกปฏิเสธ; ขั้นที่ต้องใช้ข้อมูลครบตรวจได้ตาม requirement
หลักฐาน: E32, E33, E34

D11 (P3) แจ้งปัญหาสิทธิ์เมื่อจำนวนงวดผิดเงื่อนไข
วิธีทำซ้ำ: โปร 0% สูงสุด 48 งวด → ใส่ 60 → กดปุ่มไปใบเสนอราคาด้านบน
ผลที่พบ: แสดง คุณอาจไม่มีสิทธิ์แก้ไขงานขายนี้; ปุ่มล่างกลับ disabled ด้วยเหตุผลถูกต้อง
แนวทาง: ตรวจ response เมื่อเลือก 60 งวดในโปรสูงสุด 48 งวด แยก validation error จาก permission/network error ให้ปุ่มบนและล่างใช้เงื่อนไขเดียวกัน พร้อมระบุจำนวนงวดสูงสุดโดยไม่ทำให้ server ยอมรับข้อมูลที่ผิด
เกณฑ์: 60 งวดในโปร 48 ถูกปฏิเสธทั้งสองปุ่มด้วยเหตุผลเรื่องจำนวนงวด; 48 งวดผ่านเมื่อเงื่อนไขอื่นครบ; กรณีไม่มีสิทธิ์จริงยังแสดง permission error
หลักฐาน: E45

รูปแบบส่งมอบ: ตาราง D01–D14 ระบุ status ของการแก้, root cause ที่ตรวจยืนยัน, ไฟล์/commit, tests/ผล, UAT case ที่ควร retest และข้อจำกัดที่เหลือ แนบคำสั่งทดสอบจริงและผลที่ได้ พร้อมสรุปผลกระทบต่อ schema/API/ข้อมูลเดิมหากมี