---
name: data-api-design
description: >-
  ช่วยออกแบบและจัดทำเอกสาร Database Schema และ API Spec ของโปรเจกต์ Projexa
  ในระดับ **Conceptual/Logical เท่านั้น** (ยังไม่ผูกมัดกับ DBMS, ORM, หรือ
  API framework ใดๆ) ครอบคลุมอย่างน้อย: รายละเอียดแต่ละตาราง (ฟิลด์/ชนิดข้อมูล
  เชิงแนวคิด/key/ความสัมพันธ์), ER Diagram, และรายการ resource/endpoint ของ
  API พร้อมสิทธิ์การเข้าถึง โดยสังเคราะห์จาก Projexa-System-Design-R1.md
  (§2 บทบาท, §4 Data Model, §5 รายการหน้าจอ, §7 AI component, §8 การสร้าง
  เอกสาร), spec รายหน้าจอ, และ backlog.md ด้วยการถามผู้ใช้งานแบบเข้มข้นทุก
  ครั้งที่การตัดสินใจเชิงแนวคิดไม่มีข้อมูลชัดเจนในเอกสารโปรเจกต์ (พร้อมตัวเลือก
  อย่างน้อย 3 แนวทางและข้อดี-ข้อเสีย) แสดงผลให้รีวิวก่อนเขียนไฟล์เสมอ บันทึกผล
  ลงเป็น docs/02-design/02-technical/database-schema.md และ
  docs/02-design/02-technical/api-spec.md ใช้ skill นี้เมื่อ user ขอสร้าง/
  ปรับปรุงเอกสาร database schema, database spec, data model เชิงเทคนิค,
  หรือ API spec/API design ของระบบ
---

# Database Schema & API Spec (Conceptual)

Skill นี้คุมขั้นตอนออกแบบและจัดทำเอกสาร **Database Schema** และ **API Spec**
ของโปรเจกต์ Projexa ที่ `docs/02-design/02-technical/database-schema.md` และ
`docs/02-design/02-technical/api-spec.md` ทั้งสองไฟล์อยู่ใน**ระดับ
Conceptual/Logical เท่านั้น** — ชนิดข้อมูลใช้คำเชิงแนวคิด (Text / Number /
Boolean / DateTime / Enum / JSON-flexible / Reference) ไม่ใช่ type ของ DBMS
จริง (เช่น `VARCHAR(255)`, `JSONB`) และ endpoint ใช้ resource/verb เชิง
แนวคิด ไม่ผูกกับ framework จริง (เช่น NestJS decorator, FastAPI route) —
แม้ `docs/02-design/02-technical/tech-stack.md` จะเลือกเทคโนโลยีไว้แล้ว
เอกสาร 2 ฉบับนี้ก็**ต้องคงความเป็น engine-agnostic**เสมอ ใช้ `tech-stack.md`
เป็นบริบทประกอบเท่านั้น (เช่น รู้ว่ามี JSON field แบบยืดหยุ่นให้ใช้จริง) ไม่ใช่
ข้อบังคับให้เขียน type เฉพาะเจาะจง

ตามหลัก **Human-in-the-loop** ของ Projexa (ดู `CLAUDE.md`): ทุกการตัดสินใจ
เชิงแนวคิด (ID strategy, audit scope, รูปแบบ API ฯลฯ) ที่ไม่มีข้อมูลจริงจาก
เอกสารโปรเจกต์ต้องถาม user เท่านั้น ห้ามเดาแทน และเอกสารผลลัพธ์ทั้งสองฉบับ
**ไม่ใช่**มุมมองสรุปแบบ `feature-list.md`/`user-journey.md` — ห้ามเขียนทับ
ตาราง/resource ที่เคย Confirmed แล้วโดยไม่ถาม ถ้าล้าสมัยจริงให้แนะนำย้ายไป
`docs/00-archived/` แทนการลบ/ทับ

**สำคัญ:** ทำขั้นตอนที่ 1–9 ด้านล่างเองใน main loop (ห้ามส่งให้ sub agent ทำ)
เพราะต้องสัมภาษณ์-ออกแบบ-ขอยืนยันกับ user แบบ interactive ส่วน "การเขียนไฟล์
จริง" ให้มอบหมายให้ sub agent ชื่อ `data-api-writer` ผ่าน Agent tool เมื่อ
ทุกอย่างถูกออกแบบและยืนยันแล้วเท่านั้น sub agent ตัวนี้ทำงานแบบ one-shot และ
ถามคำถามกลับ user ไม่ได้ — **ห้ามให้ sub agent เป็นคนออกแบบตาราง/ฟิลด์/
endpoint เอง** หน้าที่นั้นเป็นของขั้นตอนในสกิลนี้เท่านั้น

## ขั้นตอน

### 1. รับสโคปประเภทเอกสาร

ถ้า user ระบุมาแล้ว (เช่น "ทำ ER diagram ให้หน่อย", "ออกแบบ API ของ SCR-004")
ให้ resolve ว่าต้องทำ Database Schema / API Spec / ทั้งสอง ถ้า **ไม่ได้ระบุ**
ให้ถามด้วย `AskUserQuestion` (multiSelect) อย่างน้อย 3 ตัวเลือก เช่น:

- ตัวเลือก 1 (แนะนำ): ทำทั้งสองพร้อมกัน — ข้อดี: ตาราง/entity กับ endpoint
  ออกแบบให้สอดคล้องกันตั้งแต่ต้น ข้อเสีย: ใช้เวลาสัมภาษณ์นานกว่า
- ตัวเลือก 2: เฉพาะ Database Schema ก่อน — ข้อดี: เร็ว เหมาะถ้ายังไม่พร้อมคุย
  เรื่อง API ข้อเสีย: ทำ API Spec รอบหน้าต้องย้อนกลับมาเทียบ entity อีกครั้ง
- ตัวเลือก 3: เฉพาะ API Spec ก่อน (ถ้ามี Database Schema อยู่แล้ว) — ข้อดี:
  เร็ว ใช้ entity เดิมอ้างอิงได้เลย ข้อเสีย: ถ้า schema เดิมไม่ครบ endpoint
  บางตัวอาจออกแบบได้ไม่สมบูรณ์

### 2. รับสโคปรายการเอนทิตี/หน้าจอ

ถ้า user ระบุมาแล้ว (รหัส SCR, ชื่อโมดูล, ชื่อ entity, หรือ "ทั้งหมด") ให้
resolve เทียบกับ §4.1/§5 ของ `Projexa-System-Design-R1.md` และ
`backlog.md` ถ้า **ไม่ได้ระบุ** ต้องถามด้วย `AskUserQuestion` อย่างน้อย 3
แนวทาง เช่น:

- ตัวเลือก 1: เฉพาะ MVP RAISE (13 หน้าจอ ตาม §10) และ entity ที่เกี่ยวข้อง —
  ข้อดี: ตรงกับสโคปที่จะพัฒนาจริงก่อน ข้อเสีย: entity ของ Phase 2 (เช่น
  DocTemplate/GeneratedDocument บางส่วน) จะยังไม่ถูกออกแบบละเอียด
- ตัวเลือก 2: ทั้งหมด 19 entity ใน §4.1 และ 26 หน้าจอ — ข้อดี: ได้ schema/API
  ที่สมบูรณ์ทั้งระบบไว้อ้างอิงล่วงหน้า ข้อเสีย: ใช้เวลาออกแบบ/สัมภาษณ์มาก และ
  บาง entity ของ Phase 2 อาจเปลี่ยนตอนถึงเวลาจริง
- ตัวเลือก 3: ระบุเจาะจงเอง (พิมพ์รายชื่อ entity/รหัส SCR)

### 3. ตรวจเอกสารตัดสินใจเดิม

`Glob`/`Read` `docs/02-design/02-technical/database-schema.md` และ
`docs/02-design/02-technical/api-spec.md` ถ้ามีอยู่แล้ว: อ่านเพื่อรู้ว่า
ตาราง/resource ใด**สถานะ Confirmed**แล้ว (มีวันที่ยืนยัน) กับอันไหนยัง
`Draft (suggested)`/ยังไม่มี — ใช้กำหนดว่าขั้นตอน 6 ต้องถามอะไรเพิ่ม **ห้าม
ถามซ้ำสิ่งที่ Confirmed แล้ว** เว้นแต่ user ขอทบทวนใหม่อย่างชัดเจน

ถ้าในบทสนทนานี้เอง**มีข้อมูล/ผลออกแบบอยู่แล้ว** (เช่นเพิ่งคุยโครงสร้างตารางกัน
มาก่อนหน้าข้อความล่าสุด) ให้ใช้ข้อมูลเดิมได้เลยไม่ต้องสัมภาษณ์ซ้ำ ถามเฉพาะ
ส่วนที่ยังขาดหรือยังไม่ชัดพอจะเขียนเป็นเอกสารทางการได้

### 4. ตรวจเอกสารต้นทางของโปรเจกต์ให้ครบก่อนเริ่ม

`Glob`/`Read` (แจ้ง user และแนะนำ skill ที่ควรรันก่อนถ้าขาด):

- เสมอ: `Projexa-System-Design-R1.md` §2 (บทบาท/สิทธิ์ — ใช้กำหนดสิทธิ์ต่อ
  endpoint), §3 (สถาปัตยกรรม — AI Layer ต้องแยกจาก Document Generator ชัดเจน,
  AI คืนค่า JSON เท่านั้น), §4 (Data Model + เส้น Traceability — ฐานของ
  Database Schema), §5 (รายการหน้าจอ — ใช้ผูก entity/endpoint กับหน้าจอที่ใช้
  งานจริง), §6 (วงจรสถานะหน้าจอ — กำหนด field สถานะ/ประวัติที่ต้องบังคับบันทึก),
  §7 (กติกา AI component — input/output ของ AI แต่ละตัว, "คืนค่า JSON เท่านั้น",
  "ทุก output ต้องผ่าน Review ก่อนบันทึกจริง"), §8 (ขั้นตอนสร้างเอกสาร — ฐาน
  ของ endpoint สร้างเอกสารส่งมอบ), §10 (ขอบเขต MVP + ข้อจำกัดที่ประกาศไว้แล้ว)
- `docs/01-requirements/backlog.md`, `docs/01-requirements/feature-list.md`
  (ถ้าขาด แนะนำ skill `gen-feature-journey` ก่อน)
- ไฟล์ spec ใน `docs/01-requirements/01-spec/` ของทุก SCR ในสโคป (ดึง
  Acceptance Criteria, ความสามารถ, business rule ที่กระทบ field/endpoint จริง
  — ถ้าขาด แนะนำ skill `requirement` ก่อน)
- `docs/02-design/02-technical/tech-stack.md` (ถ้ามี) — อ่านเป็นบริบทประกอบ
  เท่านั้น (ดูหัวข้อบนสุดของสกิลนี้ — ห้ามให้ผลลัพธ์ผูกมัดกับ engine ที่เลือก)
- ถ้าสโคปมี prototype ที่เกี่ยวข้อง: `Glob`
  `docs/02-design/01-prototypes/v*/` หาเวอร์ชันล่าสุดที่มี field/interaction
  จริงของ SCR ในสโคป (เสริมความคมของ field list ไม่บังคับต้องมี)

### 5. สรุปข้อเท็จจริง vs ช่องว่างที่ต้องถาม (การตัดสินใจเชิงแนวคิด)

รวบรวมจากขั้นตอน 4 แล้วแยกให้ชัดว่า **มีข้อมูลจริงจากเอกสารแล้ว** หรือ
**ต้องออกแบบเชิงแนวคิดเพิ่ม** (ห้ามเดาแทนช่องที่ไม่มีข้อมูล) หัวข้อที่ต้อง
พิจารณาเสมอ (เลือกเฉพาะที่เกี่ยวกับสโคป/ประเภทเอกสารที่ทำรอบนี้):

**สำหรับ Database Schema:**
- กลยุทธ์ primary key เชิงแนวคิด (surrogate id / natural key / composite key)
- ขอบเขตของ audit trail: เฉพาะ `StatusHistory` ของ Screen ตาม §6 หรือ
  ขยายเป็น audit log ทั่วทั้งระบบตามหลัก "Everything is logged"
- รูปแบบเก็บผลลัพธ์จาก AI (§7.1): เก็บเป็นคอลัมน์ปกติที่ normalize ครบ หรือ
  เก็บแบบ field ยืดหยุ่น (JSON-flexible เชิงแนวคิด) พร้อม `source_clause`/
  `confidence`/label `AI Generated`/`Human Confirmed` ตามกติกา §7.2
- การแยก multi-tenancy/ขอบเขตข้อมูลต่อ `Project` (row-level scoping)
- นโยบายการลบข้อมูล: soft-delete (ตั้ง flag/สถานะ) หรือ hard-delete หรือ
  archive แยกตาราง — และผลต่อ referential integrity ของสาย traceability
- การจัดเก็บไฟล์แนบ (`Attachment`, TOR ต้นฉบับ, GeneratedDocument): เก็บ
  metadata+reference ในฐานข้อมูล กับตัวไฟล์จริงแยกไปอยู่ File Storage เสมอ
  (ตาม §3) — ต้องยืนยันว่า field ใดเป็น reference เท่านั้น
- การเก็บเวอร์ชันเอกสารที่สร้าง (`GeneratedDocument`): เก็บทุกเวอร์ชันแบบ
  immutable (append-only) หรือมีสถานะ draft/final ที่แก้ไขทับได้ก่อน export

**สำหรับ API Spec:**
- รูปแบบ endpoint เชิงแนวคิด: resource-oriented (CRUD ต่อ entity) หรือ
  action-oriented (endpoint ตามการกระทำในหน้าจอ) หรือผสมกัน
- รูปแบบงาน AI ที่ใช้เวลาประมวลผล (เช่น TOR Parser กับไฟล์ .docx/.pdf ขนาด
  ใหญ่): synchronous response ตรงๆ หรือ async job + polling/สถานะ
- รูปแบบ 2 ขั้นตอนของทุก endpoint ที่เกี่ยวกับ AI (เสนอผล → ให้คนยืนยัน) ตาม
  กติกา §7.2 ข้อ 5 — ต้องออกแบบให้ทุก AI endpoint มี endpoint แยก "ยืนยัน/
  บันทึกจริง" เสมอ ไม่ merge เป็น endpoint เดียว
- รูปแบบ pagination/filter/sort มาตรฐานที่ใช้ร่วมกันทุก resource
- รูปแบบ error response มาตรฐาน
- แนวทาง versioning ของ API (เช่น ผ่าน path prefix เชิงแนวคิด หรือยังไม่
  จำเป็นต้องกำหนดในระดับ conceptual)
- การแทนสิทธิ์ (§2): สิทธิ์อิงตาม Role ตรงๆ หรืออิงตาม `Assignment` (Screen
  × Role × User) ที่ต้องเช็คระดับ record ด้วย

ถ้าในเอกสารต้นทางมีคำตอบอยู่แล้ว (เช่น §7.2 บังคับ 2 ขั้นตอนเสนอ/ยืนยันอยู่
แล้ว) ให้ใช้ตรงนั้นได้เลยไม่ต้องถามซ้ำ — ถามเฉพาะจุดที่เอกสารต้นทางไม่ได้
ระบุไว้จริงๆ

### 6. สัมภาษณ์ผู้ใช้แบบเข้มข้น

สำหรับทุกหัวข้อในขั้นตอน 5 ที่ยังไม่มีคำตอบชัดเจนจากเอกสาร **ต้องถามด้วย
`AskUserQuestion`** แบ่งเป็นชุดละไม่เกิน 4 คำถามต่อการเรียก 1 ครั้ง (เรียกได้
หลายรอบจนครบ) **ทุกคำถามต้องมีตัวเลือกอย่างน้อย 3 แนวทางเสมอ พร้อมข้อดี-
ข้อเสียของแต่ละตัวเลือกในคำอธิบาย** (ไม่ใช่แค่ yes/no) ตัวอย่างรูปแบบ:

> "ผลลัพธ์จาก AI TOR Parser (FR/NFR ที่สกัดได้) ควรเก็บในฐานข้อมูลแบบไหน?"
> - ตัวเลือก 1: Normalize เป็นคอลัมน์ครบ (เช่น `type`, `text`, `source_clause`,
>   `confidence` แยกคอลัมน์) — ข้อดี: query/รายงานง่าย ตรวจสอบ constraint ได้
>   ข้อเสีย: ถ้าโครงสร้างผลลัพธ์ AI เปลี่ยนบ่อยต้องแก้ schema ตาม
> - ตัวเลือก 2: เก็บเป็น field ยืดหยุ่น (JSON-flexible) พร้อม field มาตรฐาน
>   เท่าที่ query บ่อย (`source_clause`, `confidence`, `status`) — ข้อดี:
>   ปรับโครงสร้างผลลัพธ์ AI ได้ง่ายโดยไม่ต้อง migrate ข้อเสีย: query เชิงลึก
>   ในฟิลด์ยืดหยุ่นทำยากกว่า ขึ้นกับความสามารถของ engine ที่เลือกภายหลัง
> - ตัวเลือก 3: เก็บทั้งสองแบบผสมกัน (คอลัมน์หลัก + field ยืดหยุ่นสำรอง
>   ส่วนเพิ่มเติม) — ข้อดี: สมดุลระหว่าง query ง่าย/ยืดหยุ่น ข้อเสีย: schema
>   ซับซ้อนขึ้นเล็กน้อย ต้องตกลงชัดว่าอะไรอยู่คอลัมน์หลัก อะไรอยู่ field ยืดหยุ่น

ถ้า user ตอบแบบเปิดกว้าง/มอบให้ AI ตัดสินใจแทน (เช่น "ช่วยคิดให้หน่อย", "ให้ AI
ประเมินเอง") ให้บันทึกไว้ว่าเป็น**มติที่ user มอบอำนาจให้ประเมินแทน** แล้วใช้
เป็นแนวทางในขั้นตอนถัดไปได้ แต่ต้องระบุป้าย `(ประเมินแทนโดย AI ตามที่ user
มอบอำนาจ)` กำกับไว้ในเอกสารเสมอ — ไม่ใช่การเดาแบบไม่มีที่มา

ถามได้หลายรอบจนกว่าจะเก็บข้อมูลครบพอจะออกแบบได้อย่างสมเหตุสมผล ไม่ต้องรีบสรุป
ถ้ายังมีความกำกวมสำคัญเหลืออยู่

### 7. ร่างเนื้อหา

สังเคราะห์จากขั้นตอน 4–6 เป็นร่างต่อไปนี้ (แสดงให้ user เห็นก่อนเขียนไฟล์จริง
ในขั้นตอน 8):

- **ถ้าทำ Database Schema:** รายการตาราง/entity ในสโคป แต่ละตารางระบุ
  คำอธิบาย, หน้าจอที่ใช้งาน (SCR-xxx), ฟิลด์ (ชื่อ, ชนิดข้อมูลเชิงแนวคิด,
  key, nullable, คำอธิบาย), ความสัมพันธ์กับตารางอื่น, constraint/business
  rule ที่กระทบ schema (ดึงจาก spec) — และ **ER Diagram แบบ mermaid
  `erDiagram`** ครอบคลุมทุกตารางในสโคปพร้อมความสัมพันธ์ (บังคับต้องมีเสมอ
  เป็นอย่างน้อย)
- **ถ้าทำ API Spec:** รายการ resource ในสโคป แต่ละ resource ระบุ entity/
  หน้าจอที่เกี่ยวข้อง, operation แต่ละตัว (ชื่อ/verb+path เชิงแนวคิด,
  คำอธิบาย, สิทธิ์ตาม Role, request/response เชิงแนวคิดแบบย่อ) รวม endpoint
  คู่ "เสนอผล AI"/"ยืนยันบันทึกจริง" ตามกติกา §7.2 และ endpoint ของกระบวนการ
  สร้างเอกสารตาม §8.1

### 8. แสดงผลให้ user รีวิวก่อนเขียนไฟล์เสมอ

**ห้ามเรียก sub agent ก่อนขั้นตอนนี้เด็ดขาด** แสดง ER Diagram + ตารางฟิลด์
ของทุก entity และ/หรือตาราง resource/endpoint ของทุก API ในสโคปให้ user เห็น
ในแชทก่อน แล้วขอให้ user ยืนยันเป็นรายตาราง/รายresource อย่างชัดเจน (เช่น
"ยืนยันตามที่ร่างไว้" หรือ "แก้ไขจุดนี้ก่อน" หรือ "ขอข้อมูลเพิ่มก่อนตัดสิน")
— ตาราง/resource ที่ user ยังไม่ยืนยัน ให้คงสถานะ `Draft (suggested)` ใน
เอกสาร ไม่ใช่ `Confirmed`

ถ้ามีตาราง/entity ใดในสโคปที่**ไม่ตรงกับ**รายการใน §4.1 หรือ resource ที่
สื่อถึง AI component ที่ **ไม่ตรงกับ** §7.1 ของ `Projexa-System-Design-R1.md`
(เช่น เพิ่ม entity ใหม่, เปลี่ยนความสัมพันธ์, เพิ่ม AI component ใหม่) ให้ถาม
ด้วย `AskUserQuestion` อย่างน้อย 3 ตัวเลือกว่าจะจัดการความต่างนี้อย่างไร เช่น:

- ตัวเลือก 1: แนะนำให้แก้ §4.1/§7.1 ของเอกสารหลักให้ตรงกับผลออกแบบรอบนี้ +
  ใส่ note อ้างอิงไปที่เอกสารนี้เป็น source of truth ระดับรายละเอียด — ข้อดี:
  ไม่มีข้อมูลขัดแย้งกันใน repo ข้อเสีย: ต้องแก้เอกสารหลักของระบบ
- ตัวเลือก 2: ไม่แก้เอกสารหลัก ให้เอกสารนี้เป็นฉบับละเอียดที่ขยายจาก §4.1/§7.1
  พร้อมลิงก์ไขว้ทั้งสองทาง — ข้อดี: ไม่กระทบเอกสารหลัก ข้อเสีย: ผู้อ่านต้อง
  เทียบสองเอกสารเองถ้าอยากรู้ภาพรวมล่าสุด
- ตัวเลือก 3: ยังไม่ตัดสินใจตอนนี้ รอ SA ยืนยันเป็นทางการก่อนค่อยแก้เอกสารหลัก

### 9. สรุปแผนให้ user ยืนยันครั้งสุดท้าย

สรุปสั้นๆ ว่าจะสร้าง/แก้ไฟล์อะไรบ้าง (สร้างใหม่/แก้ table หรือ resource ใด,
จะแนะนำแก้ §4.1/§7.1 ของเอกสารหลักหรือไม่) แล้วขอยืนยันหนึ่งครั้งก่อนเรียก
sub agent เพราะเป็นการสร้าง/แก้ไฟล์จริงในโปรเจกต์

### 10. มอบหมายให้ sub agent `data-api-writer`

เมื่อ user ยืนยันแล้ว เรียกผ่าน Agent tool (subagent_type: `data-api-writer`)
พร้อมข้อมูลทั้งหมดที่จำเป็นในพรอมป์ (ทุกอย่างต้อง finalize แล้ว ห้ามส่งให้
sub agent ไปออกแบบต่อเอง):

- วันที่ปัจจุบัน (`YYYYMMDD` และ `YYYY-MM-DD`) จาก context ของ session
- ประเภทเอกสารที่ต้องทำรอบนี้ (Database Schema / API Spec / ทั้งสอง)
- โหมดต่อไฟล์: "สร้างใหม่ทั้งไฟล์" หรือ "แก้/เพิ่ม section ของ: {รายชื่อ
  ตาราง/resource}"
- บริบท/การตัดสินใจเชิงแนวคิดที่สัมภาษณ์ได้ (พร้อมระบุอันไหนเป็นข้อมูลจริงจาก
  user อันไหนเป็น "ประเมินแทนโดย AI ตามที่ user มอบอำนาจ")
- ถ้าทำ Database Schema: ER Diagram (mermaid source ที่ finalize แล้ว) +
  รายละเอียดครบทุกตาราง (ฟิลด์, key, ความสัมพันธ์, สถานะ Confirmed/Draft)
- ถ้าทำ API Spec: แนวทางร่วม (global convention จากขั้นตอน 5–6) + รายละเอียด
  ครบทุก resource/operation (สิทธิ์, request/response เชิงแนวคิด, สถานะ
  Confirmed/Draft)
- มติเรื่องแก้ §4.1/§7.1 ของเอกสารหลักจากขั้นตอน 8 (แก้ / ไม่แก้ / รอ) — ถ้า
  แก้ต้องระบุให้ชัดว่าแก้แถว/ส่วนไหนเป็นค่าอะไร

sub agent จะจัดการให้ครบ: เขียน/แก้
`docs/02-design/02-technical/database-schema.md` และ/หรือ
`docs/02-design/02-technical/api-spec.md`, อัปเดต
`docs/02-design/02-technical/index.md`, แก้ §4.1/§7.1 ของ
`Projexa-System-Design-R1.md` เฉพาะกรณีมีมติให้แก้เท่านั้น, และบันทึก
`docs/05-log/`

### 11. รายงานผลกลับ user

สรุป path ไฟล์ที่ถูกสร้าง/แก้ไขทั้งหมด, ตาราง/resource ไหน `Confirmed` แล้ว
บ้าง, อันไหนยัง `Draft (suggested)` รอข้อมูล/การยืนยันเพิ่ม, และย้ำว่าเอกสาร
นี้ต้องรอ SA/Dev Lead ยืนยันเป็นทางการตามหลัก Human-in-the-loop ก่อนถือเป็น
พิมพ์เขียวที่ทีมพัฒนาใช้อ้างอิงจริง

## สิ่งที่ห้ามทำ

- ห้ามให้ sub agent ออกแบบตาราง/ฟิลด์/ความสัมพันธ์/endpoint เอง — ทุกอย่าง
  ต้องออกแบบและยืนยันโดย user ผ่าน main loop นี้ก่อน แล้วส่งเป็นค่าที่
  finalize แล้วเท่านั้น
- ห้ามเขียนชนิดข้อมูล/endpoint ผูกกับ DBMS, ORM, หรือ API framework ใดๆ
  โดยเฉพาะ (ต้องเป็น conceptual เท่านั้น) แม้ `tech-stack.md` จะเลือก
  เทคโนโลยีไว้แล้วก็ตาม
- ห้ามเดาคำตอบแทน user เมื่อการตัดสินใจเชิงแนวคิดไม่มีข้อมูลจริงจากเอกสาร —
  ต้องถามเสมอ ยกเว้น user มอบอำนาจให้ประเมินแทนอย่างชัดเจน (ต้องระบุป้ายกำกับ
  ในเอกสารตามขั้นตอน 6)
- ห้ามถามคำถามที่ไม่มีตัวเลือกอย่างน้อย 3 แนวทางพร้อมข้อดีข้อเสีย เมื่อสิ่งใด
  ไม่ชัดเจน (ยกเว้นคำถามยืนยัน yes/no ล้วนๆ ที่ไม่มีทางเลือกเชิงเทคนิคจริง)
- ห้ามส่งมอบ Database Schema โดยไม่มี ER Diagram แบบ mermaid อย่างน้อยหนึ่งอัน
  ครอบคลุมทุกตารางในสโคป
- ห้ามออกแบบ endpoint ที่เกี่ยวกับผลลัพธ์ AI (§7.1) แบบขั้นตอนเดียว (เสนอผล
  และบันทึกจริงพร้อมกัน) — ต้องแยก endpoint "เสนอผล"/"ยืนยันบันทึกจริง" เสมอ
  ตามกติกา §7.2 ข้อ 5
- ห้ามข้ามขั้นตอนแสดงผลให้ review ก่อนเขียนไฟล์ (ขั้นตอน 8) แม้ user จะรีบ
- ห้ามเขียนทับหรือลบตาราง/resource section ที่มีสถานะ `Confirmed` อยู่แล้ว
  โดยไม่ถาม user ก่อน (ถ้าล้าสมัยจริงให้แนะนำย้ายไป `docs/00-archived/` แทน)
- ห้ามแก้ §4.1/§7.1 ของ `Projexa-System-Design-R1.md` โดยไม่ผ่านขั้นตอน 8
  (ถามและได้รับมติชัดเจนก่อนเสมอ)