# Mission: Audit ระบบ AI ที่กำลังรันอยู่ จากอีก workspace หนึ่ง

## บริบท

- ระบบ `[ชื่อ Assistant]` เป็น AI Assistant ที่รันต่อเนื่องมานาน ด้วยโมเดล `[Opus]` ซึ่งต่ำกว่านาย (นายคือ `[Fable]`)
- มันรันอยู่ใน `[herdr/tmux]` workspace `[ชื่อ]` คนละ workspace กับนาย แต่ใช้โฟลเดอร์โปรเจคเดียวกัน
- ระบบนี้สำคัญกับฉันมาก ต้องทำงานต่อได้ตลอดระหว่างที่นาย audit

## เป้าหมาย

1. หาจุดบกพร่องทั้งโปรเจค เรียงตามความรุนแรง
2. วางแผนปรับปรุงให้ระบบทำงานได้ถูกต้องขึ้น ถูกลง และตรวจสอบได้
3. ลงมือแก้ตามแผนโดยที่ระบบยังรันอยู่
4. ส่งตาราง before & after ที่มีตัวเลขจริงและระบุวิธีวัด

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

**ขั้น 1 อ่านอย่างเดียว:** กวาดโค้ด, config, hooks, scheduler, สคริปต์, log, transcript
รวมถึง **state ที่ harness เก็บไว้นอกโฟลเดอร์โปรเจค** ด้วย — config/cache ของเครื่องมือที่รันระบบอยู่, failure cache, log ของ plugin/MCP
ของแต่ละชิ้นที่พึ่ง harness ต้องตอบให้ได้ว่า **"ถ้าชิ้นนี้ crash ตอน start เครื่องมือจะจำอะไรไว้ และรอบหน้ามันจะทำตัวต่างไปยังไง"**
ยังไม่แก้อะไรทั้งสิ้น

**ขั้น 2 สงสัยอะไรให้ถาม `[ชื่อ Assistant]` ใน workspace `[ชื่อ]` โดยตรง**
โดยเฉพาะ: ไฟล์/โค้ด/โครงสร้างนี้ใช้ทำอะไร, สิ่งนี้เป็นบั๊กหรือฉันตั้งใจให้เป็นแบบนี้
รวมคำถาม-คำตอบไว้ในรายงาน และแยกให้ชัดว่าอะไรคือ "บั๊ก" อะไรคือ "policy ที่เจ้าของเลือกเอง"

**ขั้น 3 ส่งรายการ finding + แผน + สิ่งที่ต้องให้ฉันตัดสินใจ มาให้ฉันดูก่อนลงมือ**

**ขั้น 4 ลงมือแก้** ทีละ commit เล็ก ๆ ที่ระบบยังรันได้ระหว่างทาง

**ขั้น 5 วัดซ้ำหลังปล่อยของจริง** ไม่ใช่วัดตอนเขียนเสร็จ

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

- **ของที่พังเงียบ:** ทางแจ้งเตือนที่ไม่เคยยิงออกจริง, สคริปต์ที่ return สำเร็จแต่ผลไม่เกิด, งานที่ถูกส่งไปแล้วไม่มีใครอ่าน, job ที่หายไปเงียบ ๆ, log ที่ไม่มีใครดู
- **ต้นทุนต่อ turn:** ขนาด context จริงต่อ API call, มี compaction ไหม, โมเดลถูก pin ไหม, ไฟล์ที่ถูกโหลดทุก turn (CLAUDE.md, persona, skill frontmatter) ใหญ่แค่ไหน
- **ความขัดแย้งในเอกสาร instruction:** กฎที่ขัดกันเอง, ของที่ระบุไว้แต่ถูกลบไปแล้ว
- **race / single point of failure:** หลาย process แย่ง resource เดียวกัน, mapping ที่พังถ้าลำดับเปลี่ยน, error ที่ถูกกลืน
- **เส้นทางบูตเย็น:** ไล่ตั้งแต่ login / LaunchAgent / สคริปต์ startup จนถึงตอนที่ทุก process ขึ้นครบ แล้วตอบสามข้อ — เรียกซ้ำแล้วปลอดภัยไหม (idempotent), ถูก trigger ซ้อนสองทางพร้อมกันได้ไหม, ถ้า N process spawn ของชิ้นเดียวกันพร้อมกันในโฟลเดอร์เดียวกันจะชนกันไหม
- **ความปลอดภัย:** secret ใน plaintext, ใน argv, ใน git history, สิทธิ์ไฟล์, ใครสั่งของที่มีค่าใช้จ่ายได้
- **repo hygiene:** สคริปต์ที่ไม่มีใครเรียก, binary ที่ track อยู่, memory/ตัวจำที่โตขึ้นเรื่อย ๆ โดยไม่มีใครตัด

## กฎระหว่าง audit

- นายรันอยู่ในโฟลเดอร์เดียวกัน hook ชุดเดียวกันจะยิงใน session ของนายด้วย ตรวจก่อนว่า session ของนายจะไม่ไปกินคิว/inbox/lock ของระบบจริง ถ้าเลี่ยงไม่ได้ ให้บอกฉันก่อนว่าจะไปชนตรงไหน — แล้ว**ถามกลับอีกทิศด้วยว่า process ของระบบจริงแย่งกันเองตอน start หรือเปล่า** ไม่ใช่ระวังแค่ทิศที่นายจะไปชนมัน
- **ห้ามทำเองโดยเด็ดขาด ต้องถามฉันก่อน:** ลบไฟล์หรือข้อมูล, หมุน/เปลี่ยน token, แก้ access list หรือ allowlist, สั่งอะไรที่มีค่าใช้จ่าย, restart ระบบจริง
- ไม่ลบ ให้ archive แล้วบอกว่าย้ายไปไหน
- ทุกบั๊กที่แก้ต้องมี regression test อย่างน้อยหนึ่งเคส และ test เดิมต้องยังผ่านทั้งหมด
- แก้เสร็จแล้ว ต้องพิสูจน์ผลปลายทาง ไม่ใช่เชื่อว่า exit 0 หรือ "sent" คือสำเร็จ

## Deliverables

1. `docs/audit-[วันที่].md` มี: finding เรียงตามความรุนแรง, สิ่งที่ตรวจแล้วไม่พบปัญหา (เพื่อให้รู้ว่าขอบเขตครอบคลุมแค่ไหน), ตาราง before/after ที่มี 4 คอลัมน์ [metric | before | after | วัดด้วยอะไร], รายการที่ต้องให้ฉันตัดสินใจ (เป็นข้อสั้น ๆ ตอบ yes/no ได้)
2. ไฟล์ handoff สำหรับ `[ชื่อ Assistant]` เอง: อะไรเปลี่ยน ต้องอ่านอะไรใหม่ พฤติกรรมอะไรต้องเปลี่ยน
3. **ทดลองบูตเย็นจริงหนึ่งรอบ** (รีบูตเครื่อง หรือ logout/login) แล้ววัดว่าทุก process ขึ้นครบจริง — relaunch pane เดียวตอนระบบยังอุ่นอยู่ไม่นับ พร้อมขั้นตอน relaunch ที่ผ่านการทดลองนั้นแล้ว (ถ้าต้องสลับโมเดล/ตั้งค่าใหม่) และวิธี rollback ถ้าของใหม่พัง
4. commit แยกเป็นเรื่อง ๆ, git status สะอาด, ประวัติการตัดสินใจไปอยู่ใน changelog ไม่ใช่ในไฟล์ instruction หลัก
5. สรุปให้ฉันเป็นภาษาไทย สั้น ขึ้นต้นด้วยสิ่งที่ต้องตัดสินใจก่อน

> ถ้าไม่แน่ใจให้ถาม `[ชื่อ Assistant]` ก่อน ถ้ายังไม่แน่ใจให้ถามฉัน อย่าเดา