# Prompt: เพิ่มปุ่มบันทึกฉบับร่างใน Training Record Form

## Objective

ปรับปรุงหน้า `training-records/new` และหน้าที่เกี่ยวข้องกับการแก้ไขประวัติการอบรม ให้รองรับการ **บันทึกฉบับร่าง** เพื่อให้พนักงานสามารถบันทึกข้อมูลการอบรมไว้ก่อนได้ แม้ข้อมูลหรือเอกสารแนบยังไม่ครบ และสามารถกลับมาแก้ไข/ส่งตรวจสอบภายหลังได้

## Scope

ให้ตรวจสอบและปรับปรุงทุกส่วนที่เกี่ยวข้อง เช่น

- หน้า `training-records/new`
- หน้า Edit Training Record
- Training Record Form Component
- Validation Schema
- API / Server Action / Mutation
- Status ของ Training Record
- ตารางรายการประวัติการอบรม
- สิทธิ์การแก้ไขตามสถานะ
- เอกสารรายงานผลใน `docs/`

## Requirement

### 1. เพิ่มสถานะฉบับร่าง

เพิ่มหรือรองรับสถานะรายการเป็น

```text
ฉบับร่าง
```

หากระบบใช้ enum/status code ให้ตรวจสอบ Pattern เดิมก่อน เช่น

```ts
DRAFT;
```

ห้ามเดาค่าเอง ให้ตรวจสอบ status เดิมของระบบก่อนแก้ไข

### 2. เพิ่มปุ่มในหน้า Create

ในหน้า `training-records/new` ให้เพิ่มปุ่ม

```text
บันทึกฉบับร่าง
```

โดยตำแหน่งปุ่มแนะนำเป็น

```text
[ยกเลิก] [บันทึกฉบับร่าง] [ส่งตรวจสอบ]
```

หรือปรับตาม Layout เดิมของระบบ โดยต้องไม่ทำให้ UI เดิมเสีย

### 3. เพิ่มปุ่มในหน้า Edit

กรณีเปิดรายการที่มีสถานะ **ฉบับร่าง** หรือ **ตีกลับ** ให้มีปุ่ม

```text
[บันทึกฉบับร่าง] [ส่งตรวจสอบ]
```

เพื่อให้ผู้ใช้เลือกได้ว่าจะบันทึกไว้ก่อน หรือส่งให้ HRD ตรวจสอบ

### 4. พฤติกรรมของปุ่มบันทึกฉบับร่าง

เมื่อกด **บันทึกฉบับร่าง**

ระบบต้องบันทึกรายการด้วยสถานะ

```text
ฉบับร่าง
```

และหลังบันทึกสำเร็จให้ Redirect กลับไปหน้า

```text
training-records
```

### 5. Validation สำหรับ Draft

กรณีกด **บันทึกฉบับร่าง** ให้ผ่อนปรน Validation บางส่วนได้ เช่น

- ยังไม่แนบไฟล์ได้
- ยังไม่กรอก URL ได้
- ยังไม่กรอกหมายเหตุได้
- ยังไม่กรอก Provider ได้
- ยังไม่กรอก Location ได้

แต่ยังควรบังคับข้อมูลหลัก เช่น

- ชื่อหลักสูตร
- วันที่อบรม
- ประเภทการอบรม
- จำนวนชั่วโมง

ให้ตรวจสอบ Validation เดิมก่อน และปรับให้เหมาะสมตาม Pattern เดิมของโปรเจกต์

### 6. Validation สำหรับส่งตรวจสอบ

กรณีกด **ส่งตรวจสอบ**

ให้ใช้ Validation เต็มตามเงื่อนไขเดิมของระบบ

เพิ่มเติมจาก Requirement ก่อนหน้า:

หากประเภทการอบรมเป็น **อบรมภายนอก (Public Training)** ต้องบังคับแนบ Attachment ก่อนส่งตรวจสอบ

แต่หากกด **บันทึกฉบับร่าง** ไม่ต้องบังคับแนบ Attachment แม้จะเป็น Public Training

### 7. สิทธิ์การมองเห็น Draft

รายการสถานะ **ฉบับร่าง**

- Employee เห็นเฉพาะ Draft ของตัวเอง
- HRD/Admin ไม่ต้องนำ Draft ไปเข้าคิวตรวจสอบ
- HRD/Admin จะเห็นหรือไม่เห็น Draft ให้ตรวจสอบ Pattern เดิมของระบบก่อน หากไม่มี Requirement ชัดเจน ให้แนะนำแนวทางใน `plan.md` ก่อนแก้ไข

### 8. Workflow สถานะ

ให้รองรับ Flow ดังนี้

```text
ฉบับร่าง → รอตรวจสอบ → อนุมัติ / ตีกลับ
```

รายละเอียด:

- Draft ยังไม่ส่งให้ HRD ตรวจ
- Draft ยังแก้ไขได้โดยเจ้าของรายการ
- เมื่อกดส่งตรวจสอบ ให้เปลี่ยนสถานะเป็น `รอตรวจสอบ`
- เมื่อส่งตรวจสอบแล้ว Employee แก้ไขไม่ได้
- หาก HRD ตีกลับ รายการกลับมาให้ Employee แก้ไขและส่งใหม่ได้

### 9. ตารางรายการ Training Records

ให้ตรวจสอบหน้า List ของ `training-records`

ต้องแสดงรายการ Draft ของ Employee เจ้าของรายการด้วย

ควรแสดงสถานะเป็น Badge เช่น

```text
ฉบับร่าง
```

และควรมี Action สำหรับแก้ไข Draft ได้ เช่น

```text
แก้ไข
```

โดยใช้ UI Pattern เดิมของระบบ

### 10. Technical Requirement

ก่อนแก้ไขต้องตรวจสอบก่อนว่าโปรเจกต์ใช้ Pattern ใด เช่น

- React Hook Form
- TanStack Form
- Zod Validation
- Server Action
- API Route
- TanStack Query Mutation
- Prisma / SQL Server
- Status enum / constant / master data

ให้แก้ไขตาม Pattern เดิมเท่านั้น

ห้ามสร้าง Logic ซ้ำ หากมี Shared Component หรือ Shared Schema อยู่แล้ว

## Implementation Steps

1. ตรวจสอบโครงสร้างหน้า `training-records/new`
2. ตรวจสอบหน้า Edit Training Record
3. ตรวจสอบ Training Record Form Component
4. ตรวจสอบ Validation Schema เดิม
5. ตรวจสอบ API / Mutation / Server Action สำหรับ Create/Update
6. ตรวจสอบ Status เดิมของ Training Record
7. เพิ่มหรือรองรับสถานะ `ฉบับร่าง`
8. เพิ่มปุ่ม `บันทึกฉบับร่าง`
9. แยก Logic ระหว่าง Draft Submit กับ Final Submit
10. ปรับ Validation ให้ Draft ผ่อนปรนได้
11. ปรับ Public Training Attachment Rule ให้บังคับเฉพาะตอน `ส่งตรวจสอบ`
12. ปรับหน้า List ให้แสดง Draft ของ Employee เจ้าของรายการ
13. ทดสอบ Create Draft, Edit Draft, Submit Draft
14. ตรวจสอบ TypeScript, ESLint และ Build
15. สร้างเอกสารรายงานผลใน `docs/`

## Expected Behavior

### Case 1: สร้างรายการแล้วกดบันทึกฉบับร่าง

- ระบบบันทึกสถานะเป็น `ฉบับร่าง`
- ไม่บังคับแนบ Attachment
- Redirect กลับไปหน้า `training-records`
- รายการแสดงใน List ของ Employee เจ้าของรายการ

### Case 2: Public Training แล้วกดบันทึกฉบับร่างโดยไม่แนบไฟล์

- บันทึกได้
- สถานะเป็น `ฉบับร่าง`
- ไม่ส่งให้ HRD ตรวจ

### Case 3: Public Training แล้วกดส่งตรวจสอบโดยไม่แนบไฟล์

- Submit ไม่ได้
- แสดง Validation Error
- แจ้งว่าต้องแนบเอกสารก่อนส่งตรวจสอบ

### Case 4: เปิด Draft มาแก้ไข

- แก้ไขข้อมูลได้
- มีปุ่ม `บันทึกฉบับร่าง`
- มีปุ่ม `ส่งตรวจสอบ`

### Case 5: Draft ถูกส่งตรวจสอบ

- สถานะเปลี่ยนเป็น `รอตรวจสอบ`
- Employee ไม่สามารถแก้ไขได้
- รายการเข้าสู่ Flow HRD Review

### Case 6: HRD ตีกลับ

- Employee สามารถแก้ไขรายการได้
- สามารถกด `บันทึกฉบับร่าง` หรือ `ส่งตรวจสอบ` ใหม่ได้

## Testing Checklist

- [ ] หน้า `training-records/new` มีปุ่ม `บันทึกฉบับร่าง`
- [ ] กด Draft แล้วบันทึกสำเร็จ
- [ ] Draft Redirect กลับไปหน้า `training-records`
- [ ] Draft แสดงใน List ของ Employee เจ้าของรายการ
- [ ] Draft ไม่เข้าคิว HRD Review
- [ ] Draft ไม่บังคับแนบ Attachment
- [ ] Public Training Draft ไม่บังคับแนบ Attachment
- [ ] Public Training ส่งตรวจสอบโดยไม่แนบ Attachment ต้อง Submit ไม่ได้
- [ ] Public Training ส่งตรวจสอบพร้อม Attachment ต้อง Submit ได้
- [ ] Edit Draft ได้
- [ ] Edit Draft มีปุ่ม `บันทึกฉบับร่าง` และ `ส่งตรวจสอบ`
- [ ] ส่ง Draft ไปตรวจสอบแล้วสถานะเปลี่ยนเป็น `รอตรวจสอบ`
- [ ] รายการที่ส่งตรวจสอบแล้ว Employee แก้ไขไม่ได้
- [ ] รายการที่ HRD ตีกลับ Employee แก้ไขและส่งใหม่ได้
- [ ] Badge สถานะ `ฉบับร่าง` แสดงถูกต้อง
- [ ] Layout ไม่เสียบน Desktop
- [ ] Layout ไม่เสียบน Mobile
- [ ] ไม่มี TypeScript Error
- [ ] ไม่มี ESLint Error
- [ ] Build ผ่าน

## Report Requirement

หลังดำเนินการเสร็จ ให้สร้างเอกสารรายงานผลไว้ในโฟลเดอร์

```text
docs/
```

ตั้งชื่อไฟล์ประมาณนี้

```text
docs/training-record-draft-feature-report.md
```

ในรายงานต้องมีหัวข้อดังนี้

```md
# Training Record Draft Feature Report

## Summary

สรุปสิ่งที่ดำเนินการ

## Files Changed

รายการไฟล์ที่แก้ไข

## Requirement Mapping

Mapping ระหว่าง Requirement กับสิ่งที่แก้ไข

## Implementation Details

รายละเอียดการเพิ่มปุ่ม Draft, Workflow, Validation และ Permission

## Status Workflow

อธิบาย Flow สถานะ ฉบับร่าง → รอตรวจสอบ → อนุมัติ/ตีกลับ

## Validation Rules

สรุป Validation ของ Draft และ Submit

## Testing Result

ผลการทดสอบตาม Checklist

## Impact Analysis

ผลกระทบต่อระบบเดิม

## Notes / Limitations

ข้อจำกัดหรือสิ่งที่ควรตรวจสอบเพิ่มเติม
```

## Important Rules

- ห้ามแก้ไขส่วนที่ไม่เกี่ยวข้อง
- ห้ามเปลี่ยน Role Permission เดิมโดยไม่จำเป็น
- ห้ามเปลี่ยน Database Schema หากไม่จำเป็น
- หากจำเป็นต้องเพิ่ม Status/Enum/Database Field ต้องอธิบายเหตุผลใน `plan.md` ก่อน
- ต้องใช้ Pattern เดิมของโปรเจกต์
- ต้องรองรับ Requirement Public Training Attachment เดิม
- ต้องสร้างรายงานผลไว้ใน `docs/` หลังดำเนินการเสร็จ
- หากพบความเสี่ยงหรือจุดที่กระทบหลายหน้า ให้สรุปใน `plan.md` ก่อนแก้ไข
## Implementation Notes

- This feature requires a real DB enum extension because the current `approval_status` only supports `pending`, `approved`, `rejected`, and `needs_revision`; there is no existing persisted draft value to reuse safely.
- Implementation decision: add `draft` to `approval_status` and use the existing `needs_revision` status as the employee-editable returned-for-revision state.
- Implementation decision: drafts will be excluded from the HRD `pending-review` queue, but remain visible in the main `training-records` listing for HRD/Admin to preserve the current organization-wide visibility pattern unless a later requirement says otherwise.
