# ตัวอย่างการเตรียมความรู้ให้ Coding Agent ทำงานต่อ

ตัวอย่างนี้เป็นข้อมูลสมมติของระบบ **Atlas Billing** สถานะเป็น draft เพื่อสาธิตการกรอก ห้ามใช้เป็นความรู้จริงหรือผลทดสอบจริง

## Use case และ dataflow

งาน: agent ตัวใหม่ต้องแก้การสร้างใบแจ้งหนี้ซ้ำหลัง worker retry โดยไม่ต้องถามทีมซ้ำว่าเคยออกแบบไว้แบบไหน

```mermaid
flowchart TD
    S[Spec และ Incident สมมติ] --> I[02 Source intake]
    I --> K[03 Knowledge: การป้องกันใบแจ้งหนี้ซ้ำ]
    I --> D[04 Decision: ใช้ request key เดิมเมื่อ retry]
    I --> M[05 Memory: เคยพบการสร้าง key ใหม่ตอน retry]
    T[06 Task handoff] --> R[Agent อ่านและค้นบริบท]
    K --> R
    D --> R
    M --> R
    R --> V[ตรวจ code และ tests ปัจจุบัน]
    V --> U[Use case: แก้ worker retry]
    U --> E[ตรวจผลและสกัดบทเรียน]
    E --> G[10 Publication checklist]
    G -->|ผ่านและมีสิทธิ์| P[Publish และตรวจ search]
    G -->|หลักฐานยังขาด| W[คง draft และระบุสิ่งที่ขาด]
    P --> K
```

## 1 รับต้นทาง

| รายการ | ค่าตัวอย่าง |
|---|---|
| Source ID | example-source-001 |
| Scope | Atlas Billing / invoice creation |
| ต้นทาง | `example://spec/invoice-v2` และ `example://incident/INC-042` |
| ข้อความใน spec สมมติ | การ retry คำขอเดิมต้องใช้ request key เดิม |
| สิ่งที่ incident สมมติพบ | worker สร้าง key ใหม่ทุก retry |
| สิ่งที่ยังไม่ยืนยัน | code ปัจจุบันยังมีพฤติกรรมนี้หรือไม่ |

`example://` เป็นป้ายกำกับหลักฐานสมมติ ไม่ใช่ URL ที่เปิดได้ ก่อนใช้งานจริงต้องแทนด้วยแหล่งที่ตรวจได้

## 2 จัดเป็น Knowledge

```yaml
id: example-knowledge-001
type: knowledge
status: draft
owner: Billing Team
scope: Atlas Billing / invoice creation v2
access: team
last_verified: unknown
review_due: event-based
```

**คำตอบที่ต้องรู้:** ตาม spec สมมติ การ retry คำขอสร้างใบแจ้งหนี้เดิมต้องใช้ request key เดิม ต้องตรวจการรับ key และการบังคับ uniqueness ใน code/schema จริงก่อนแก้

**ขอบเขต:** ยังสรุปไม่ได้ว่า key เดียวใช้ข้าม tenant หรือข้าม endpoint ได้ ต้องมีหลักฐานเรื่องขอบเขต key เพิ่ม

**เหตุให้ทบทวน:** เปลี่ยน API, schema หรือวิธีสร้าง key

## 3 บันทึก Decision

- ID: example-decision-001
- Decision state: proposed
- ข้อเสนอ: คง key เดิมเมื่อ retry คำขอเดิม
- เหตุผล: ให้ระบบแยก retry ออกจากคำขอสร้างรายการใหม่ได้ตาม spec สมมติ
- Tradeoff: ต้องกำหนดอายุและ scope ของ key
- หลักฐานการยืนยันโดยผู้มีอำนาจ: ไม่มีในตัวอย่างนี้

Agent อ่านได้ว่าเป็นข้อเสนอ แต่ยังใช้แทน decision ที่ accepted ไม่ได้

## 4 เก็บ Memory ที่มีขอบเขต

- ID: example-memory-001
- Kind: gotcha
- สิ่งที่จำ: incident สมมติเคยพบการสร้าง key ใหม่ใน retry path
- Scope: worker รุ่นที่เกิด incident เท่านั้น
- ใช้เมื่อ: ตรวจเส้นทาง retry ของ invoice creation
- ข้อจำกัด: ไม่ได้ยืนยันว่า code ปัจจุบันยังมี bug
- ถอนหรือแก้เมื่อ: มี code revision และผลทดสอบใหม่ยืนยันว่าแก้แล้ว

## 5 ส่งงานต่อ

- เป้าหมาย: retry แล้วไม่สร้างใบแจ้งหนี้เพิ่ม และคำขอใหม่ยังสร้างได้
- เสร็จเมื่อ: ผ่านทั้ง retry case, new-request case และ isolation case ตาม spec จริง
- ทำแล้ว: รวบรวม spec และ incident สมมติ
- ยังไม่ทำ: ตรวจ code/schema ปัจจุบันและรันทดสอบ
- ขั้นแรก: ตรวจ repo instructions, branch และ revision จากนั้นอ่าน retry path
- คำถามจำเป็น: หากไม่มีหลักฐาน scope ของ key ต้องหาจาก spec/schema หรือถามเจ้าของระบบก่อนเปลี่ยน behavior

## 6 Runbook สำหรับการตรวจตัวอย่าง

1. ตรวจ request key จากต้นคำขอถึง worker โดยไม่เปิดเผยข้อมูลลูกค้าจริง
2. ตรวจเงื่อนไข deduplication ใน schema/service ของ environment ทดสอบ
3. ทดสอบคำขอเดิมซ้ำ แล้วทดสอบคำขอใหม่และ scope isolation
4. บันทึกคำสั่งจริง revision และผลจริง อย่าเติมคำสั่งที่ยังไม่รู้

## 7 ผล Publication checklist ของตัวอย่าง

| เกณฑ์ | ผล | เหตุผล |
|---|---|---|
| ประเภทและ scope | pass | แยก knowledge, decision, memory และ task |
| หลักฐานเปิดตรวจได้ | fail | ต้นทางเป็นข้อมูลสมมติ |
| ตรวจ code ปัจจุบัน | fail | ยังไม่ได้ตรวจ |
| ผลทดสอบจริง | fail | ยังไม่ได้รัน |
| สิทธิ์ publish | fail | ยังไม่มีนโยบายของคลังจริง |

**Verdict: needs_revision — คง draft**

นี่คือพฤติกรรมที่ต้องการ: agent อ่านแล้วทำงานเตรียมต่อได้ รู้สิ่งที่ขาด และไม่ทำให้ข้อมูลสมมติกลายเป็นความรู้ที่รับรองแล้ว

## การขยายเป็น Use case อื่น

| Use case | ใช้ template หลัก | ข้อมูลสดที่ต้องตรวจ |
|---|---|---|
| แก้ incident | Source + Memory + Runbook | Logs, metrics, config |
| วิจัยเลือก vendor | Source + Knowledge + Comparison | Docs และเงื่อนไขปัจจุบัน |
| ผู้ช่วยรายงานทีม | Knowledge + Decision + Task | สถานะ issue และการตัดสินใจล่าสุด |
| งานหลาย session | Task + Memory | Workspace, branch, diff และผลตรวจล่าสุด |