self-check

name	self-check
description	ตรวจงานก่อนบอกว่าเสร็จ — รัน เทสต์ หาบั๊ก แก้ แล้วค่อยจบ ใช้ทุกครั้งหลังทำงานโค้ด/สร้างไฟล์เสร็จ ก่อนสรุปว่าจบงาน

Skill: self-check (ตรวจก่อนส่ง)

อย่าเพิ่งบอกว่า "เสร็จแล้ว" จนกว่าจะผ่านขั้นตอนนี้ — โค้ดที่ "ดูครบ" มักพังเงียบๆ ที่ edge case

ขั้นตอน

1. นิยาม "ถูกต้อง" คืออะไร — ก่อนเทสต์ ระบุให้ชัดว่าผลลัพธ์ที่ถูกควรเป็นยังไง (ค่าที่คาด, พฤติกรรมที่ควรเกิด)
2. รันจริง — รันโค้ด/ไฟล์/เทสต์ผ่าน bash. โค้ดที่รันไม่ได้ = ยังไม่เสร็จ
   • เว็บ/JS: node --check file.js เช็ค syntax ก่อน; แยก logic มารันใน node ได้
   • Python: รันไฟล์ หรือ python -m py_compile
3. หาบั๊ก เชิงรุก — พยายามทำให้มันพัง:
   • happy path (เคสปกติ) ✓
   • edge case: ค่าว่าง, 0, ลบ, ใหญ่มาก, ซ้อนกัน, input แปลกๆ
   • เคสที่ตรงข้ามกับที่ควร match/ทำงาน (ควรได้ false/error)
4. เทียบ ground truth ถ้ามี — ถ้ามีของอ้างอิง (ผลที่รู้ว่าถูก, library มาตรฐาน, spec) ให้รันเทียบ เช่น regex engine → เทียบ RegExp จริง; คณิต → เทียบผลที่คำนวณมือ; parser → เทียบ output ที่คาด
5. ตรวจว่า "ถูก" ไม่ใช่แค่ "รันได้" — output ที่ออกมาถูกต้องจริงไหม ไม่ใช่แค่ไม่ error
6. เจอบั๊ก → แก้ (ดู skill debug) → เทสต์ใหม่ วนจนผ่าน
7. สรุปตามจริง: บอกว่าเทสต์อะไรไป ผ่าน/ไม่ผ่านอะไร ถ้ามีจุดที่ยังไม่ชัวร์หรือ skip ให้บอกตรงๆ — อย่าเคลมว่า "เสร็จสมบูรณ์" ถ้ายังไม่ได้ตรวจ

กฎ

• งานที่ verify ไม่ได้ในเครื่อง (เช่น UI ต้องเปิดเบราว์เซอร์) → อย่างน้อยเช็ค syntax + แยก logic มาเทสต์ + บอกผู้ใช้ว่าส่วนไหนต้องลองเอง
• ถ้าผู้ใช้จะเอาไปใช้จริง อย่าส่งของที่ "น่าจะถูก" โดยไม่ตรวจ — รันให้เห็นก่อน
• จบงานที่ผ่านการตรวจแล้ว = พูดได้เต็มปากว่าเสร็จ; จบงานที่ไม่ได้ตรวจ = หลอกตัวเองและผู้ใช้