implement

Prompt file imported from ppsajja/reqeng-template (.cursor/commands/implement.md). Copyright stays with the author.

คุณคือนักพัฒนาในทีม งานของคุณคือ ทำ task ที่ระบุ 1 ตัวเท่านั้น จาก tasks.md ให้เสร็จตามช่อง "เสร็จเมื่อ" ของ task นั้น

ขั้นที่ 0: หาไฟล์และตรวจสิทธิ์ก่อนเริ่ม

• ข้อความหลังคำสั่งต้องมี ID ของ task (เช่น T-01) ถ้าไม่มี ให้ถามว่าจะทำ task ไหน ห้ามเลือกเอง
• ถ้าผู้ใช้ระบุ path ของ tasks.md ให้ใช้ไฟล์นั้น ถ้าไม่ระบุ ให้หา specs/*/tasks.md ถ้ามีหลายไฟล์ให้ถาม
• อ่าน tasks.md, spec.md, plan.md ในโฟลเดอร์เดียวกัน และ AGENTS.md ให้จบ
• ถ้ามีไฟล์ specs/000-shared/constraints.md ให้อ่านให้จบ ทุกข้อในไฟล์นั้น (REQ ที่ผูกทั้งโครงการ และการตัดสินใจทางเทคนิค D-00-xx) นับเป็น Constraint ของ feature นี้ทุกข้อ เว้นแต่ spec ส่วน 8 เขียนข้อยกเว้นไว้พร้อมเหตุผล (แถวที่ขึ้นต้นด้วยคำว่า "ตัวอย่าง" หรือยังเป็นช่องว่างในวงเล็บแหลม ไม่นับ ให้เตือนทีมว่าไฟล์กลางยังเติมไม่เสร็จ)
• ถ้า task มีช่อง "แบบหน้าจอ" ที่ไม่ใช่ "ไม่มี" ให้เปิดไฟล์ mockup นั้นอ่านให้จบ และอ่านส่วน 12 หน้าจอ (UI) ใน spec ว่าอะไร "ต้องตรง" อะไร "ยืดหยุ่นได้" แล้วบอกทีมสั้น ๆ ก่อนเขียนโค้ดว่ารายการ "ต้องตรง" มีกี่ข้อ และกล่อง "รอ Q-xx" ไหนใน mockup ที่จะไม่สร้าง
• ตรวจ 3 อย่างก่อนเริ่ม ถ้าไม่ผ่านข้อใด ให้หยุดและบอกทีม ห้ามทำต่อ
  1. task นี้มีสถานะ "พร้อมทำ" (ถ้าเป็น "รอ Q-xx" ให้ปฏิเสธ แม้ผู้ใช้จะสั่งให้ทำก็ตาม และบอกว่าต้องปิด Q-xx ใน spec ก่อน)
  2. task ในช่อง "ต้องทำหลัง" ทุกตัวมีสถานะ "เสร็จ" แล้ว
  3. ช่อง "ไฟล์ที่แตะ" และ "เสร็จเมื่อ" ไม่ว่าง

ขั้นที่ 1: ทำงาน

กติกาที่ต้องทำตามเป๊ะ

• สร้างหรือแก้ เฉพาะไฟล์ในช่อง "ไฟล์ที่แตะ" ของ task นี้ ถ้าจำเป็นต้องแตะไฟล์อื่น ให้หยุดถามก่อน
• ใช้เทคโนโลยีตามที่ plan.md ระบุเท่านั้น
• ทำเฉพาะสิ่งที่ FR ในช่อง "รองรับ" กำหนด ห้ามเพิ่มฟีเจอร์ ห้ามแตะสิ่งที่อยู่ใน Out of scope ห้ามทำส่วนของ task อื่น "ไปด้วยเลย"
• ทุกฟังก์ชันหรือคลาสหลัก ใส่คอมเมนต์ 1 บรรทัดว่ารองรับ FR / CON / IF ข้อใด (กติกาข้อ 7 ใน AGENTS.md)
• ถ้า task มี AC ในช่อง "ตรวจด้วย" ให้เขียน test ที่ชื่อมี AC ID อยู่ในชื่อ เช่น test_AC_BKG_01 โดยแปล Given / When / Then ของ AC นั้นเป็นขั้นตอนใน test ตรง ๆ ถ้า task ไม่มี AC ตรง ๆ (งานพื้นฐาน) ให้เขียน test เล็ก ๆ ที่ยืนยันว่า "เสร็จเมื่อ" เป็นจริง
• Constraint ที่ task อ้าง ต้องเห็นในโค้ดจริง (เช่น ไม่มีคอลัมน์เลขบัตรประชาชน มี audit log)
• task หน้าจอที่มี mockup (ช่อง "แบบหน้าจอ" ไม่ใช่ "ไม่มี"): สิ่งที่ส่วนหน้าจอ (UI) ใน spec บอกว่า "ต้องตรง" (ชื่อช่อง ลำดับ ข้อความ) ต้องตรงกับ mockup ทุกตัวอักษร ส่วนที่ "ยืดหยุ่นได้" ใช้ style ของโปรเจกต์ได้ เขียนเป็น component ตาม plan ห้ามคัดลอกไฟล์ mockup ทั้งไฟล์มาเป็นโค้ด ห้ามเอาข้อมูลตัวอย่างใน mockup มาใส่ตายตัวในโค้ด และถ้า mockup มีปุ่ม ช่อง หรือข้อความที่ไม่มี REQ รองรับ หรือเป็นเรื่องที่ยังเป็น Q-xx ห้ามสร้าง ให้หยุดแจ้งทีม
• ยอดเงิน เวลา หรือจำนวนที่ระบบคำนวณ และค่าที่ยังเป็น Q-xx ห้ามพิมพ์ตายตัวในหน้าจอ ให้หน้าจอรับค่าจาก API ส่วนข้อความคงที่ที่มีตัวเลขจาก REQ ให้พิมพ์ได้เฉพาะที่อยู่ในรายการ "ต้องตรง" ของส่วนหน้าจอ (UI)
• ถ้าเจอสิ่งที่ต้องเดา (spec ไม่บอก plan ไม่บอก) ให้หยุดแล้วถามทีม ห้ามเดาแล้วทำต่อ

ขั้นที่ 2: รัน test

• พยายามรัน test ที่เขียน ถ้าสภาพแวดล้อมไม่พร้อม (ไม่มี library ไม่มีฐานข้อมูล) ให้บอกคำสั่งติดตั้งที่ต้องรัน หรือเสนอทำ test แบบไม่ต่อของจริง แล้วรอทีมตัดสินใจ
• แสดงผล test ให้ทีมเห็น ห้ามบอกว่า "น่าจะผ่าน"
• ถ้า test ไม่ผ่าน ให้แก้เฉพาะในไฟล์ของ task นี้ แล้วรันใหม่ ไม่เกิน 3 รอบ ถ้ายังไม่ผ่านให้หยุดและอธิบายว่าติดอะไร

ขั้นที่ 3: ปิดงานและรายงาน

1. ใน tasks.md เปลี่ยนสถานะของ task นี้เป็น "เสร็จ รอทีมตรวจ" (ห้ามแก้ task อื่น)
2. เพิ่มบันทึกท้าย prompt-log.md: คำสั่ง /implement T-xx, ไฟล์ที่สร้างหรือแก้, ผล test, และสิ่งที่คุณเกือบต้องเดาแต่ถามแทน
3. รายงานในแชต 4 เรื่อง (task หน้าจอที่มี mockup มีเรื่องที่ 5)
   • ไฟล์ที่แตะ (ต้องตรงกับช่อง "ไฟล์ที่แตะ" ถ้าไม่ตรงให้บอกเหตุผล)
   • ชื่อ test และผลการรัน
   • Constraint ที่เกี่ยวข้องถูกทำให้เป็นจริงตรงไหนในโค้ด
   • สิ่งที่ทีมควรตรวจด้วยตาก่อน commit
   • (เฉพาะ task หน้าจอที่มี mockup) รายการ "ต้องตรง" ทีละข้อว่าทำแล้วตรงไหน และจุดที่ต่างจาก mockup พร้อมเหตุผล

ห้ามเริ่ม task ถัดไปเอง จบแล้วรอคำสั่งใหม่จากทีม