ทีมพี่น้อง — qa-team · requirement-team · advisor-team

ทั้ง 3 ตัวนี้เป็น preset ของ operating model เดียวกับ dev-team — ต่างกันแค่ intake / roster / gates / output ที่เหลือ (Five Execution Principles, progress ledger, verdict precedence, appetite breaker) ใช้ของ dev-team ทั้งหมด

1. /qa-team — งาน test อย่างเดียว

เส้นแบ่งที่แข็งที่สุดในชุดนี้: ห้ามแก้ production code เด็ดขาด

allowed_changed_files = ไฟล์ test เท่านั้น เจอ bug ระหว่างทาง → ไม่แก้ที่นี่ แต่บันทึกเป็น finding พร้อม repro ลง outcome-ledger.yaml ให้ Owner ส่งต่อเข้า dev-team · แก้ production code เพื่อให้ test ผ่าน = ละเมิดขอบเขตทันที

ลำดับการทำงาน

repo-scout (test stack + convention)
  → test-charter-writer (charter ก่อนเขียน test เสมอ)
  → tester ตาม stack (be-tester / fe-tester / tester)
  → build-runner (หลักฐานจริง)
  → reviewer (อ่าน diff ของ test)

• e2e-writer / e2e-runner เรียกเมื่อ Owner ขอ e2e เท่านั้น
• solution-skeptic ไม่บังคับ (งาน test มี semantic risk ต่ำ) เรียกเมื่อ charter ขัดกับ AC ของ Owner หรือ Owner สั่ง
• workflow-evaluator เฉพาะ medium/high, gate แดง, หรือ Owner สั่ง — low ใช้ manager stand-in

Intake ต้องชัดก่อนเริ่ม

• AC/behavior ที่ต้อง cover คืออะไร (และอะไรที่ ไม่ cover)
• test stack + คำสั่ง test จริง — อ่านจาก repo ไม่ใช่เดา
• ระดับ test ที่ตกลง: unit / integration / e2e (e2e ต่อเมื่อ Owner ขอ)
• appetite

2. /requirement-team — ทำให้ชัดก่อนลงมือ

ทำงาน บน main thread เป็นหลัก (cost ~0) เรียก agent ช่วยเฉพาะที่จำเป็น · เป็น advisory run (run_type: advisory) ไม่มี diff / build / review / evaluation

Appetite: ≤ 5 calls / 30 นาที

เลือกโหมดก่อน

หลักการของแต่ละโหมด

diverge: เข้าใจเจตนาก่อนกระโดดไปหาทางแก้ · ถามทีละเรื่อง ไม่ยิงคำถามรัว · ตัวเลือกต้องต่างกันจริง ไม่ใช่ของเดิม 3 สี

converge: ท้าทาย assumption ที่ แพงที่สุด ก่อน (ตัวที่ถ้าผิดแล้วเสียหายที่สุด) · edge case ถาม ไม่เดา — ที่ยังไม่รู้ลง unknowns ของ spec · solution-skeptic ท้าทาย spec ก่อน finalize (บังคับ) · จบเมื่อ Owner กับทีมเห็นภาพเดียวกัน

Spec ต้องมีอะไร

goal · scope in-out · AC ที่ทดสอบได้ · definition of done · unknowns · appetite ที่แนะนำสำหรับงาน implement

spec ใหญ่เกินหนึ่งก้อน → ตัดเป็น vertical slice ที่แต่ละชิ้นจบ end-to-end และทดสอบได้เอง พร้อมระบุ blocking edge ว่าชิ้นไหนต้องเสร็จก่อนชิ้นไหน — dev-team จะได้เรียงลำดับต่อได้โดยไม่ต้องเดา

3. /advisor-team — ความเห็นที่สอง

ไม่ใช่ dev run: ไม่มี worker, ไม่มี diff, ไม่มี run directory · memo คือ artifact เดียว

ขอบเขตแข็ง: read-only — ทั้ง skill และ counsel ห้าม Edit/Write ใน repo เป้าหมาย, ห้าม implement, ห้าม merge, ห้าม approve แทน Owner · ให้ความเห็น แล้ว Owner ตัดสินใจ

สิ่งที่ต้องส่งมาให้ (ไม่ครบ = ถามกลับ ไม่เดา)

1. คำถามตัดสินใจ 1 ข้อ — “เดินต่อด้วยอะไร / เลือกทางไหน / มันเสร็จจริงหรือยัง” ไม่ใช่คำถามค้นข้อมูลที่ตอบเองได้
2. pointer อย่างน้อย 1 อย่าง — run directory, branch, diff range, หรือ file path ที่คำถามยืนอยู่บนนั้น

โหมดและ appetite

โครงของ memo

question · pointers_read · verdict (proceed / adjust / stop / need-evidence) · reasons (อ้างหลักฐาน) · risks (เรียงตามผลกระทบ) · what-would-change-my-mind

เก็บสำเนาไว้ที่ .dev-team/advice/<DDMMYYYY>-<slug>.md เพื่อค้นย้อนหลังได้

จังหวะที่คุ้มที่สุดที่จะเรียก

ก่อน freeze approach · ตอนติด · ก่อนจะบอกว่าเสร็จ