dev-team — ผู้จัดการงานพัฒนา

/dev-team คือ agent ที่หนักที่สุดในชุด — ทำตัวเป็น ผู้จัดการของบริษัทเล็กๆ ทีมเดียว: รับงานจาก Owner, ถามจนมั่นใจ, ประชุมกับ deputy, สั่งงาน, เก็บหลักฐาน, แล้วส่ง “sprint mail” กลับมา

KPI มีแค่ 2 ข้อ: (1) คุณภาพงาน (2) cost ที่สมกับงาน — ทุกกลไกในนี้รับใช้สองข้อนี้ ไม่ใช่จำนวน role หรือความอลังการของพิธี

1. ใช้เมื่อไหร่ / ไม่ใช้เมื่อไหร่

2. ภาพรวมการทำงาน

flowchart TD
    A["0. Preflight<br/>เช็ค capability ของ runtime"] --> B["1. Intake<br/>ถามจนมั่นใจ + ตกลง appetite"]
    B --> C["2. Executive meeting<br/>Task Ledger + sizing + เรียก deputy 1-3 ตัว"]
    C --> D["3. Risk → เลือก gates + tell/ask mode"]
    D --> E["5. สร้าง run directory<br/>.dev-team/runs/&lt;task-id&gt;/"]
    E --> F["6. Progress ledger loop<br/>ตอบ 5 คำถามทุกครั้งก่อน call ถัดไป"]
    F --> G["7. build/test จริง + hash"]
    G --> F
    F --> H["8. Independent review<br/>+ validator + evaluation"]
    H --> I["9. Sprint mail<br/>ส่ง Owner เป็นภาษาไทย"]

3. Intake — ถามจนมั่นใจ ก่อน call แรก

Intake ทำบน main thread (cost ~0) และต้องผ่าน checklist ให้ครบก่อนออกจากขั้นนี้

• goal ชัด · definition of done ชัด · ขอบเขตชัด · appetite ตกลงแล้ว · ไม่มี unknown ที่ต้องเดา

ข้อไหนไม่ผ่าน → ถาม Owner ต่อ และบันทึกลง question_log (ห้ามเงียบแล้วเดา)

ก่อนหยุดถามทุกครั้ง ต้อง persist ก่อน — scaffold .dev-team/runs/<task-id>/ และเขียน intake.yaml จริง เพราะคำถามที่อยู่แต่ในแชทคือ audit trail ที่หายไป

Appetite — เพดานที่ตกลงกัน ไม่ใช่ estimate

กันงบ closing gates ไว้ก่อนตกลงเพดาน — เพดานครอบทั้ง run รวม gate ปิดงาน: review 1 call (ทุก tier) + evaluation 1 call (บังคับที่ medium/high) งบ implement = เพดาน − ส่วนที่กันไว้

ก่อน spawn ทุกครั้งต้องเขียนเลขลงใน ledger: budget: used=X reserved=Y remaining=Z — Z ≤ 0 → ห้าม spawn ตัดวงจรทันที

4. Executive meeting — Task Ledger + เลือกขนาดทีม

เรียก deputy 1-2 ตัวเท่าที่จำเป็น (เพดาน 3 สำหรับงาน complex/high-risk) ยิงขนานครั้งเดียว จาก agent ที่มีอยู่แล้ว: repo-scout, contract-designer, solution-skeptic, db-advisor/security-advisor, test-charter-writer

ผลลัพธ์สังเคราะห์เป็น Task Ledger ใน decision.yaml:

task_ledger:
  facts_given: []      # Owner บอกมา
  facts_to_look_up: [] # ต้องไปหาใน repo/docs
  facts_to_derive: []  # คำนวณ/อนุมานจากของที่รู้
  educated_guesses: [] # สมมติฐานความมั่นใจต่ำสุด — ต้องมองเห็นได้เสมอ

ต้องปรึกษา deputy เสมอเมื่อ: stack/domain ไม่คุ้น · requirement ขัดกัน · semantic risk medium/high · ไม่ชัดว่าจะ verify ยังไง · failure cost สูง · confidence ในการวินิจฉัยต่ำ

5. Risk → gates + โหมด tell/ask

Risk ไม่ได้กำหนดจำนวนคน — มันกำหนด (ก) gate ที่ต้องมีหลักฐาน (ข) โหมด tell/ask ของแต่ละ lane

การเปลี่ยน public behavior/API/signature ที่ มีคนอื่นพึ่งพาอยู่ (signature, response shape, wire format, schema, หรือ key/value ใน shared status map ที่ consumer เอาไป switch) = อย่างน้อย medium แม้แตะแค่ ≤ 2 ไฟล์

ลด risk ต่ำกว่าที่คำนวณได้ ทำได้ทางเดียว: Owner override ที่บันทึกเหตุผล + timestamp ใน decision.yaml.owner_overrides

6. Run directory — หลักฐานที่ตรวจย้อนหลังได้

งานที่แตะ repo จริงจะสร้าง .dev-team/runs/<task-id>/ และบันทึก baseline git rev-parse HEAD

Scaffold ครบทุกไฟล์ตั้งแต่วินาทีที่สร้าง run dir (เป็น stub ที่มีค่า pending) — turn สุดท้ายมีหน้าที่ เติม ไม่ใช่ สร้าง เพราะ stub ที่ค้าง validator จับได้เสมอ แต่ไฟล์ที่ไม่เคยถูกสร้างต้องพึ่งความจำตอนจบ ซึ่งพังใน scenario ยาว

งาน read-only ที่ไม่มี diff (audit, comprehension, review) ใช้ advisory profile: run_type: advisory + อย่างน้อย 1 ไฟล์ใน deliverable/ — ไม่มี diff.patch/build evidence เพราะไม่มีอะไรเปลี่ยน แต่ ยังต้อง scaffold และผ่าน validator เหมือนเดิม

7. Progress ledger loop — หยุดให้เป็น

หลังทุก worker call ต้องตอบ 5 คำถามลง progress-ledger.yaml ก่อน เรียกตัวถัดไป

ledger:
  complete: <bool>           # งานจบหรือยัง
  looping: <bool>            # วนซ้ำที่เดิมหรือเปล่า
  forward_progress: <bool>   # เดินหน้าจริงไหม
  who_next: <string>         # ใครทำต่อ
  next_instruction: <string> # ด้วยคำสั่งอะไร

• ไม่มี forward progress หรือวนลูป → stall_count +1
• stall_count > 2 → บังคับ กลับไปแก้ Task Ledger (re-plan) หรือ re-bet กับ Owner — ห้ามเรียก worker ตัวถัดไปบน loop ที่ค้าง
• appetite หมด → appetite.status: exceeded, หยุด, persist หลักฐานเท่าที่มี, re-bet กับ Owner

Scope ห้ามขยายตอนถูกกดดัน — งบใกล้หมดแล้วยังห้ามแตะไฟล์นอก whitelist แม้เจตนาดี (เพิ่ม test, cleanup) งานนอก scope เป็น proposal ใน unresolved ไม่ใช่ diff · หลังประกาศหยุดแล้ว ห้ามเติมไฟล์เข้า approved_file_plan เอง

8. Review + evaluation — 3 gate ที่แยกหน้าที่กันชัด

การเลือกผู้รับรอง (deterministic): risk low → manager เขียน evaluation.yaml เองในฐานะ stand-in (ไม่เรียก evaluator agent — เคยเจอจริงว่า evaluator เต็มรูปแบบบน diff 3 บรรทัดกิน elapsed cap หมดคนเดียว) · medium/high หรือ gate แดง หรือ Owner สั่ง → เรียก workflow-evaluator

ก่อนเรียก evaluator ต้องรัน validator แล้วแนบผลเป็นหลักฐาน:

python "${CLAUDE_PLUGIN_ROOT}/core/tools/validate_run.py" check --run-dir ".dev-team/runs/<task-id>"

exit 0 = ผ่านครบ · exit 1 = พิมพ์ CODE ของแต่ละข้อที่พัง ห้ามปิดงาน · exit 2 = IO/usage error — และ workflow-evaluator จะรัน validator เองซ้ำ ไม่เชื่อผลที่ orchestrator ส่งมา

ลำดับ verdict: blocked > fail > replan > pass_with_conditions > degraded > pass — replan/blocked ห้าม implement ต่อ

9. กลไกที่กัน agent โกงตัวเอง

ส่วนนี้คือเหตุผลที่ dev-team แพงกว่า /coding — มันซื้อความเชื่อถือได้ของผลลัพธ์

10. Sprint mail — สิ่งที่ Owner ได้กลับมา

รายงานปิดงานเป็นภาษาไทย นำด้วย KPI สองข้อ:

• ส่งมอบอะไร + หลักฐาน — ไฟล์ที่เปลี่ยน, AC evidence, ผล build/test/review/evaluation
• appetite ที่ใช้ vs เพดาน — จำนวน call, นาทีที่ใช้
• cost report จริง — จาก cost_report.py ดึง token/USD จาก transcript จริง (ดึงไม่ได้ = unknown ไม่เดา ไม่ block การปิดงาน)
• การตัดสินใจโหมด Tell — พร้อมเหตุผลที่ปกป้องได้
• unresolved + ข้อเสนอถัดไป, learning loop, หลักฐานที่ degraded/stale
• knowledge delta — +N facts, M superseded (รายงาน 0 ด้วย)

11. ตัวอย่างสั่งงาน

/dev-team เพิ่ม endpoint POST /api/fx/outstanding/ack ใน Backend_NotificationService
- repo: C:\SourceCode\Work\Backend_NotificationService
- AC: user กด ack แล้ว notification เปลี่ยนเป็น read + ตอบ 204, ack ซ้ำต้องไม่ error
- appetite: standard พอ (~10 calls / 45 นาที)

สิ่งที่ควรใส่มาให้ครบตั้งแต่แรก เพื่อไม่ต้องเสียรอบถาม: repo path · goal · AC ที่ทดสอบได้ · ขอบเขตที่ห้ามแตะ · appetite ที่รับได้