Scrutinize
ตรวจ change โดยแยกสิ่งที่ผู้เขียนกล่าวอ้างออกจากสิ่งที่พิสูจน์ได้จริง มองให้พ้นบริเวณ diff แต่รักษาขอบเขตตามเป้าหมายของผู้ใช้
1. ยืนยัน intent และขอบเขต
- สรุปเป้าหมายของ change เป็นหนึ่งประโยคด้วยถ้อยคำของตนเอง
- ระบุ artifact ที่ต้องตรวจ เช่น plan, branch, PR, staged diff หรือไฟล์ที่เจาะจง
- ถ้าอธิบายเป้าหมายไม่ได้จากข้อมูลที่มี ให้บอกข้อมูลที่ขาดและถามคำถามที่เฉพาะเจาะจงก่อน review ต่อ
- ถือว่าเป็นงาน read-only เว้นแต่ผู้ใช้สั่งให้แก้ไขอย่างชัดเจน
2. ท้าทายแนวทางก่อนตรวจรายละเอียด
ตรวจว่าปัญหานั้นมีอยู่จริงและ change นี้จำเป็นหรือไม่ จากนั้นพิจารณาทางเลือกต่อไปนี้:
- ใช้ capability ที่มีอยู่แล้วแทนการเพิ่ม surface ใหม่
- ลด change ให้เป็น slice ที่เล็กกว่าและตรวจสอบได้ง่ายกว่า
- ย้ายวิธีแก้ไปยัง layer ที่เหมาะกว่า เช่น config, framework, build หรือ runtime
- ไม่ทำ change เมื่อผลประโยชน์ไม่คุ้มกับ complexity และ regression risk
ถ้ามีทางเลือกที่ดีกว่า ให้รายงานก่อน findings ระดับบรรทัด พร้อมอธิบาย trade-off ที่เป็นรูปธรรม อย่าเสนอทางเลือกเพียงเพื่อให้ดูว่ามีตัวเลือก
3. ไล่ actual code path
สำหรับ behavior สำคัญแต่ละข้อ ให้ตามเส้นทางจริงตั้งแต่ต้นจนจบ:
- entry point และ caller ที่เกี่ยวข้อง
- branch, guard, config และ state ที่กำหนดเส้นทาง
- state mutation, persistence, network call หรือ side effect
- error path, retry, cleanup และค่าที่ส่งกลับ
- unchanged code ก่อนและหลังจุดที่แก้ เพราะ defect มักอยู่ตรงรอยต่อ
สำหรับ plan หรือ design ให้เทียบ proposed flow กับระบบปัจจุบัน และระบุ assumption ที่ยังไม่มีหลักฐานรองรับ
4. ตรวจ claims และความเสี่ยง
แยกแต่ละ claim ออกจากผลการตรวจ แล้วตอบให้ได้ว่า:
- code path สร้าง behavior ตาม claim จริงหรือไม่
- input หรือ state ใดทำให้พัง เช่น empty, null, unicode, ข้อมูลขนาดใหญ่, concurrency, partial failure หรือ out-of-order event
- change กระทบ contract, error semantics, performance, observability, storage หรือ wire format โดยไม่ตั้งใจหรือไม่
- tests วิ่งผ่าน path ที่ต้องการจริง หรือ mock/fixture ทำให้ข้ามจุดเสี่ยง
- สิ่งใดยังตรวจไม่ได้ และต้องใช้หลักฐานอะไรเพิ่ม
อย่าเปลี่ยนความไม่แน่ใจให้เป็นข้อเท็จจริง ให้ระบุระดับหลักฐานและข้อจำกัดของ review อย่างตรงไปตรงมา
5. รายงานผล
เรียง findings ตามระดับ blocker, major, minor, nit และใช้หนึ่งหัวข้อต่อหนึ่งปัญหา แต่ละ finding ต้องมี:
- Finding — ปัญหาที่เฉพาะเจาะจง พร้อม
file:line หรือ path เมื่อมี
- Impact — ผลที่เกิดกับผู้ใช้ ระบบ หรือการดูแลรักษา
- Evidence — code path, state หรือ test case ที่แสดงปัญหา
- Suggested change — วิธีแก้ที่เล็กและตรวจสอบได้
ปิดท้ายด้วย verdict หนึ่งบรรทัด: ship, fix-then-ship, rework หรือ reject พร้อมเหตุผลหลักหนึ่งข้อ
ถ้าไม่พบปัญหา อย่าตอบเพียง LGTM ให้สรุป paths, claims และ edge cases ที่ตรวจแล้ว รวมถึงสิ่งที่อยู่นอก coverage
1---2name: scrutinize3description: ตรวจสอบ plan, PR, diff, design document หรือ code change แบบ end-to-end จากมุมมองคนนอก โดยทบทวน intent มองหาวิธีที่เล็กกว่า ไล่ actual code path และยืนยันว่า change ทำตามที่กล่าวอ้างจริง ใช้เมื่อผู้ใช้ขอ review, audit, sanity-check, second opinion, ตรวจแผน หรือตรวจความเสี่ยงก่อน merge โดย default ให้รายงานอย่างเดียวและไม่แก้ไฟล์4---56# Scrutinize78ตรวจ change โดยแยกสิ่งที่ผู้เขียนกล่าวอ้างออกจากสิ่งที่พิสูจน์ได้จริง มองให้พ้นบริเวณ diff แต่รักษาขอบเขตตามเป้าหมายของผู้ใช้910## 1. ยืนยัน intent และขอบเขต11121. สรุปเป้าหมายของ change เป็นหนึ่งประโยคด้วยถ้อยคำของตนเอง132. ระบุ artifact ที่ต้องตรวจ เช่น plan, branch, PR, staged diff หรือไฟล์ที่เจาะจง143. ถ้าอธิบายเป้าหมายไม่ได้จากข้อมูลที่มี ให้บอกข้อมูลที่ขาดและถามคำถามที่เฉพาะเจาะจงก่อน review ต่อ154. ถือว่าเป็นงาน read-only เว้นแต่ผู้ใช้สั่งให้แก้ไขอย่างชัดเจน1617## 2. ท้าทายแนวทางก่อนตรวจรายละเอียด1819ตรวจว่าปัญหานั้นมีอยู่จริงและ change นี้จำเป็นหรือไม่ จากนั้นพิจารณาทางเลือกต่อไปนี้:2021- ใช้ capability ที่มีอยู่แล้วแทนการเพิ่ม surface ใหม่22- ลด change ให้เป็น slice ที่เล็กกว่าและตรวจสอบได้ง่ายกว่า23- ย้ายวิธีแก้ไปยัง layer ที่เหมาะกว่า เช่น config, framework, build หรือ runtime24- ไม่ทำ change เมื่อผลประโยชน์ไม่คุ้มกับ complexity และ regression risk2526ถ้ามีทางเลือกที่ดีกว่า ให้รายงานก่อน findings ระดับบรรทัด พร้อมอธิบาย trade-off ที่เป็นรูปธรรม อย่าเสนอทางเลือกเพียงเพื่อให้ดูว่ามีตัวเลือก2728## 3. ไล่ actual code path2930สำหรับ behavior สำคัญแต่ละข้อ ให้ตามเส้นทางจริงตั้งแต่ต้นจนจบ:31321. entry point และ caller ที่เกี่ยวข้อง332. branch, guard, config และ state ที่กำหนดเส้นทาง343. state mutation, persistence, network call หรือ side effect354. error path, retry, cleanup และค่าที่ส่งกลับ365. unchanged code ก่อนและหลังจุดที่แก้ เพราะ defect มักอยู่ตรงรอยต่อ3738สำหรับ plan หรือ design ให้เทียบ proposed flow กับระบบปัจจุบัน และระบุ assumption ที่ยังไม่มีหลักฐานรองรับ3940## 4. ตรวจ claims และความเสี่ยง4142แยกแต่ละ claim ออกจากผลการตรวจ แล้วตอบให้ได้ว่า:4344- code path สร้าง behavior ตาม claim จริงหรือไม่45- input หรือ state ใดทำให้พัง เช่น empty, null, unicode, ข้อมูลขนาดใหญ่, concurrency, partial failure หรือ out-of-order event46- change กระทบ contract, error semantics, performance, observability, storage หรือ wire format โดยไม่ตั้งใจหรือไม่47- tests วิ่งผ่าน path ที่ต้องการจริง หรือ mock/fixture ทำให้ข้ามจุดเสี่ยง48- สิ่งใดยังตรวจไม่ได้ และต้องใช้หลักฐานอะไรเพิ่ม4950อย่าเปลี่ยนความไม่แน่ใจให้เป็นข้อเท็จจริง ให้ระบุระดับหลักฐานและข้อจำกัดของ review อย่างตรงไปตรงมา5152## 5. รายงานผล5354เรียง findings ตามระดับ `blocker`, `major`, `minor`, `nit` และใช้หนึ่งหัวข้อต่อหนึ่งปัญหา แต่ละ finding ต้องมี:5556- **Finding** — ปัญหาที่เฉพาะเจาะจง พร้อม `file:line` หรือ path เมื่อมี57- **Impact** — ผลที่เกิดกับผู้ใช้ ระบบ หรือการดูแลรักษา58- **Evidence** — code path, state หรือ test case ที่แสดงปัญหา59- **Suggested change** — วิธีแก้ที่เล็กและตรวจสอบได้6061ปิดท้ายด้วย verdict หนึ่งบรรทัด: `ship`, `fix-then-ship`, `rework` หรือ `reject` พร้อมเหตุผลหลักหนึ่งข้อ6263ถ้าไม่พบปัญหา อย่าตอบเพียง `LGTM` ให้สรุป paths, claims และ edge cases ที่ตรวจแล้ว รวมถึงสิ่งที่อยู่นอก coverage
autsachi