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

ขอบเขต: แอป romeagency/Sales-Deal-Platform ที่ 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 แอป romeagency/Sales-Deal-Platform และอ่าน 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/ข้อมูลเดิมหากมี