# Mission: ตรวจสุขภาพโปรเจคประจำเดือน ด้วยโมเดลที่สูงกว่าตัวที่ทำงานประจำ

## บริบท

- โปรเจค `[ชื่อโปรเจค]` ในโฟลเดอร์นี้ ถูกสร้างและแก้มาตลอดทั้งเดือนด้วยโมเดลที่ **ต่ำกว่านาย** เพราะฉันประหยัดค่าใช้จ่ายในงานประจำวัน
- เดือนละครั้ง ฉันจะเปิด session ด้วยโมเดลระดับนายมากวาดทั้งโปรเจคหนึ่งรอบ นี่คือรอบนั้น
- นายแพงกว่า งานของนายจึงไม่ใช่ "แก้ทุกอย่างเอง" แต่คือ **มองให้เห็นสิ่งที่ตัวประจำวันมองไม่เห็น แล้ววางแผนให้ละเอียดพอที่ตัวประจำวันจะทำต่อได้โดยไม่ต้องคิดใหม่**
- รอบที่แล้ว: `[ลิงก์ issue สารบัญรอบก่อน หรือเขียนว่า "รอบแรก"]`
- ห้ามแตะโค้ดจนกว่าจะถึงขั้น 6 และฉันตอบแล้ว

## เป้าหมาย

1. หาสิ่งที่ควรแก้ทั้งโปรเจค เรียงตามความรุนแรง พร้อมหลักฐานที่ชี้ได้ว่าอยู่ไฟล์ไหนบรรทัดไหน
2. แยกให้ชัดทุกข้อว่า **"ตัวประจำวันทำได้ ถ้ามีแผนละเอียดพอ"** หรือ **"ต้องใช้นายเอง"**
3. เอาแผนขึ้น GitHub เป็น issue ที่ไล่ทำทีละข้อได้ ไม่ว่าใครจะเป็นคนทำ
4. จบด้วยการถามฉันว่าจะให้ใครทำต่อ

## ลำดับการทำงาน (ห้ามข้ามขั้น)

**ขั้น 1 อ่านอย่างเดียว:** `git log --since="1 month ago" --stat`, ไฟล์ instruction ของโปรเจค (CLAUDE.md / AGENTS.md / README), โครงสร้างโฟลเดอร์, dependency list, test ที่มี, ไฟล์ที่ถูกแก้บ่อยที่สุดในเดือนนี้, issue ที่เปิดค้างอยู่ และ issue สารบัญรอบก่อน (ถ้ามี) ยังไม่แก้อะไรทั้งสิ้น

**ขั้น 2 เทียบกับรอบก่อน:** ถ้ามีสารบัญรอบก่อน ให้ตอบสามอย่าง — ข้อไหนปิดไปแล้วจริง (พิสูจน์จากโค้ด ไม่ใช่จากสถานะ issue), ข้อไหนยังค้าง, ข้อไหน **กลับมาพังซ้ำ** ของที่พังซ้ำสำคัญกว่าของใหม่ เพราะแปลว่าแผนรอบก่อนไม่กันได้จริง

**ขั้น 3 ส่ง finding ให้ฉันคัดก่อนเปิด issue:** ตารางสั้น ๆ [finding | ความรุนแรง | ใครควรทำ | ทำไมถึงคิดว่าเป็นปัญหา] ตรงนี้ฉันจะตัดข้อที่เป็น policy ที่ฉันเลือกเองออก ถ้านายไม่แน่ใจว่าอะไรคือบั๊กหรือฉันตั้งใจ ให้ถามในขั้นนี้ อย่าเดา

**ขั้น 4 เปิด GitHub issue** ตามกติกาข้างล่าง เฉพาะข้อที่ฉันอนุมัติ

**ขั้น 5 เขียนไฟล์สรุปลงโปรเจค** แล้ว commit

**ขั้น 6 ถามฉันว่าจะไปต่อทางไหน** ด้วยเครื่องมือถามแบบมีตัวเลือก

## สิ่งที่ต้องหาเป็นพิเศษ

- **รอยต่อระหว่าง session:** โค้ดที่เขียนคนละวันโดยคนละ session มักมี logic ซ้ำกันคนละที่, pattern เดียวกันแต่เขียนคนละแบบ, abstraction ที่ควรรวมเป็นตัวเดียว, ของที่ copy แล้วแก้ไม่ครบ
- **เอกสารกับโค้ดไม่ตรงกัน:** กฎในไฟล์ instruction ที่โค้ดไม่ได้ทำตาม, ฟีเจอร์ที่ถูกถอดไปแล้วแต่เอกสารยังพูดถึง, กฎที่ขัดกันเองในไฟล์เดียวกัน
- **error ที่ถูกกลืน:** catch แล้วเงียบ, return สำเร็จทั้งที่ปลายทางไม่เกิดอะไร, fallback ที่ซ่อนปัญหาแทนที่จะฟ้อง
- **test ที่หลอกตา:** test ที่ผ่านเพราะไม่ได้ assert อะไรจริง, test ที่ถูก skip ค้างไว้, ส่วนที่สำคัญแต่ไม่มี test เลย
- **ความปลอดภัย:** secret ที่หลุดลง git history, input จากภายนอกที่ไม่ถูก validate, สิทธิ์หรือ allowlist ที่กว้างเกินจำเป็น
- **dependency:** ของที่มี advisory, ของที่ติดตั้งไว้แต่ไม่มีใคร import, version ที่ pin ไว้โดยไม่มีเหตุผล
- **performance ที่เห็นชัด:** query ซ้อนใน loop, โหลดทั้งก้อนเพื่อใช้ชิ้นเดียว, งานที่ทำซ้ำทุก request ทั้งที่ cache ได้
- **repo hygiene:** ไฟล์ที่ไม่มีใครเรียก, TODO ที่ค้างเกินเดือน, branch ที่ตายแล้ว, ไฟล์ใหญ่ที่ไม่ควรถูก track

## กติกา GitHub (ขั้น 4)

- ชื่อ issue ขึ้นต้นด้วย `[review YYYY-MM]` ตามด้วยใจความสั้น ๆ ที่อ่านแล้วรู้ว่าต้องแก้อะไร
- label ทุกใบต้องมี 3 ชั้น: `monthly-review` · ความรุนแรง `severity:critical` / `severity:high` / `severity:medium` / `severity:low` · ผู้ทำ `needs:strong-model` หรือ `ok:daily-model` — ถ้า label ไหนยังไม่มีใน repo ให้สร้างก่อน
- body ของแต่ละ issue ต้องให้โมเดลที่ต่ำกว่านายทำได้โดยไม่ต้องวิเคราะห์ซ้ำ: ไฟล์และบรรทัด, ตอนนี้เป็นอย่างไร, ควรเป็นอย่างไร, วิธีพิสูจน์ว่าแก้แล้ว (คำสั่งหรือ test ที่รันได้), ขอบเขตที่ห้ามแตะ, issue อื่นที่ต้องทำก่อน (ถ้ามี)
- **issue สารบัญ 1 ใบ** ชื่อ `[review YYYY-MM] สารบัญ` มี task list `- [ ] #เลข` เรียงตามลำดับที่ควรทำ (ความรุนแรงก่อน แล้วตาม dependency) ลิงก์ไปสารบัญรอบก่อน และสรุปสั้น ๆ ว่ารอบนี้โปรเจคอยู่ในสภาพไหน — pin ไว้
- ห้ามเปิดซ้ำกับ issue ที่ค้างอยู่แล้ว ถ้าเจอเรื่องเดิม ให้คอมเมนต์เพิ่มหลักฐานใหม่ในใบเดิม แล้วใส่ใบเดิมลงสารบัญรอบนี้แทน
- ห้ามปิด issue ที่นายไม่ได้เป็นคนแก้ในรอบนี้

## ไฟล์สรุป (ขั้น 5)

`docs/review/YYYY-MM.md` มี: ลิงก์ issue สารบัญ, ภาพรวมสภาพโปรเจคใน 5 บรรทัด, ตารางเทียบรอบก่อน [ข้อ | สถานะรอบก่อน | สถานะรอบนี้], **สิ่งที่ตรวจแล้วไม่พบปัญหา** (เพื่อให้รอบหน้ารู้ว่าขอบเขตครอบคลุมแค่ไหน), และข้อที่ฉันตัดออกในขั้น 3 พร้อมเหตุผลที่ฉันให้ — commit ด้วยข้อความ `chore: monthly review YYYY-MM` แยกจาก commit อื่น

## ขั้น 6 ถามฉันว่าจะไปต่อทางไหน

ใช้ `AskUserQuestion` ถ้านายรันใน Claude Code หรือเครื่องมือถามผู้ใช้แบบมีตัวเลือกที่ harness ของนายมี ห้ามพิมพ์คำถามลอย ๆ แล้วรอ ให้มีสามตัวเลือก (ตัดข้อ 3 ออกถ้าเครื่องนี้ไม่มี terminal ที่เปิด tab ให้ agent อื่นได้ เช่น herdr):

1. **สลับไปโมเดลประจำวัน แล้วไล่ทำตามสารบัญ** — นายต้องเตรียมข้อความสั้น ๆ ให้ฉันแปะใน session ใหม่ได้ทันที เช่น "อ่าน issue #[เลขสารบัญ] แล้วทำทีละข้อตามลำดับ ปิด issue ได้ต่อเมื่อพิสูจน์ตามวิธีที่ระบุไว้ในใบนั้นแล้ว ข้อที่ติด `needs:strong-model` ให้ข้ามแล้วบอกฉัน" ถ้าฉันเลือกข้อนี้ นายจบ session โดยไม่แตะโค้ด
2. **ให้นายทำเองเฉพาะข้อ `needs:strong-model` ก่อน แล้วค่อยสลับ** — ทำทีละข้อ commit แยกต่อ issue ปิด issue เมื่อพิสูจน์แล้ว ติ๊กในสารบัญ ทำครบแล้วกลับมาถามข้อ 1 อีกรอบพร้อมข้อความแปะที่อัปเดตแล้ว
3. **นายเป็นวาทยกร กระจายงานให้ tab ของโมเดลประจำวัน** — ใช้ได้เมื่อรันใน terminal ที่เปิด tab ใหม่ให้ agent อื่นได้ (เช่น `[herdr]`) นายไม่แตะโค้ดเอง แต่เปิด 2-3 tab ที่รันโมเดลประจำวันในโฟลเดอร์เดียวกัน แล้วแจก issue จากสารบัญให้ทีละ tab ตามกติกาข้างล่าง

## โหมดวาทยกร (ถ้าฉันเลือกข้อ 3)

- เปิดไม่เกิน 3 tab และแจก issue ให้แต่ละ tab **ไม่ชนไฟล์กัน** — ถ้าสอง issue แตะไฟล์เดียวกัน ให้อยู่ tab เดียวกันเรียงต่อกัน ไม่แยกขนาน
- ข้อที่ติด `needs:strong-model` นายทำเองใน tab นี้ระหว่างรอ ไม่แจกออกไป
- บรีฟที่ส่งให้แต่ละ tab ต้องมีครบ: เลข issue ที่ต้องทำตามลำดับ, คำสั่งว่า "อ่าน issue ด้วย `gh issue view` ก่อน ทำตามวิธีพิสูจน์ในใบนั้น commit แยกต่อ issue ห้ามแตะไฟล์นอกขอบเขตที่ใบนั้นระบุ", และรูปแบบรายงานกลับที่นายอยากได้ (issue ไหนเสร็จ commit อะไร พิสูจน์ด้วยอะไร ติดอะไร)
- ส่งงานแล้วต้องยืนยันว่า tab นั้น **เริ่มรันจริง** ก่อนไปแจก tab ถัดไป (เช่นใน herdr: `pane run` แล้ว `send-keys Enter` แล้วรอสถานะ `working` — พิมพ์ลงไปเฉย ๆ ยังไม่ถือว่าส่ง) แล้วค่อยรอจนสถานะ `idle` แล้วอ่านผล
- tab ไหนรายงานว่าติด ให้นายตัดสินใจเอง: แก้ให้เอง, ส่งคำสั่งเพิ่ม, หรือเอา issue นั้นกลับมาติด `needs:strong-model` แล้วบอกฉัน — อย่าปล่อยให้มันเดาต่อ
- tab ที่รายงานเสร็จแล้ว ให้นายตรวจก่อนรับ: `git log` ว่ามี commit ตามที่บอก, รันวิธีพิสูจน์ในใบ issue ซ้ำเองหนึ่งรอบ แล้วค่อยปิด issue และติ๊กในสารบัญ
- รับงานแล้ว **ปิด tab นั้น** — ปิดเฉพาะ tab ที่นายเปิดเองในรอบนี้ ห้ามปิด tab อื่นของฉัน
- ทุก tab ปิดหมดแล้ว ให้ push, อัปเดตสารบัญ, แล้วสรุปให้ฉันเป็นตาราง [issue | tab ไหนทำ | ผล | ต้องตัดสินใจอะไรต่อ] ใบไหนล้มเหลวให้บอกตรง ๆ อย่าซ่อน

## กฎตลอดรอบ

- ทุก finding ต้องมีหลักฐานที่ชี้ได้ (ไฟล์:บรรทัด หรือคำสั่งที่ reproduce ได้) ความรู้สึกว่า "น่าจะไม่ดี" ไม่นับ
- ห้ามทำเองโดยเด็ดขาด ต้องถามฉันก่อน: ลบไฟล์หรือข้อมูล, อัป dependency ข้าม major, แก้ setting ของ repo, force push, สั่งอะไรที่มีค่าใช้จ่าย
- ไม่ลบ ให้ archive แล้วบอกว่าย้ายไปไหน
- tab ที่นายเปิดในโหมดวาทยกร ใช้ hook และ config ชุดเดียวกับโฟลเดอร์นี้ ถ้าโปรเจคมี hook ที่ยิงของจริง (แจ้งเตือน, deploy) ให้บอกฉันก่อนเปิด tab
- ถ้ารอบนี้ไม่เจออะไรที่ควรแก้ ให้บอกตรง ๆ แล้วเปิดแค่สารบัญที่เขียนว่าตรวจอะไรไปบ้าง อย่าหาเรื่องแก้เพื่อให้มีงาน
- สรุปให้ฉันเป็นภาษาไทย สั้น ขึ้นต้นด้วยสิ่งที่ต้องตัดสินใจก่อน

> ถ้าไม่แน่ใจว่าเป็นบั๊กหรือฉันตั้งใจ ให้ถามในขั้น 3 ถ้าไม่แน่ใจเรื่องอื่น ให้ถามก่อนลงมือ อย่าเดา