# Training Record Draft Submit Workflow Review & Fix

## Objective

ตรวจสอบ วิเคราะห์ และแก้ไขปัญหา Workflow ของการส่งประวัติการอบรม (Training Record) จากสถานะ "ฉบับร่าง (Draft)" ไปเป็น "รอตรวจสอบ (Pending Review)"

ปัจจุบันพบ Runtime Error

```
พนักงานสามารถอัปโหลดเอกสารได้เฉพาะรายการที่อยู่ในสถานะฉบับร่างหรือขอแก้ไขเท่านั้น
```

**ห้ามแก้ไขจากการคาดเดา**

ต้องตรวจสอบ Source Code และลำดับการทำงานจริงก่อนทุกครั้ง

---

# Project Rules

ก่อนแก้ไขให้ปฏิบัติตาม

- AGENTS.md
- docs/AI_DEVELOPMENT_GUIDE.md
- docs/PROJECT_ARCHITECTURE.md

ห้ามสร้าง Pattern ใหม่ หากระบบเดิมมี Pattern รองรับอยู่แล้ว

Reuse

- Shared Components
- Shared Services
- Shared Mutations
- Shared Queries
- Shared Hooks
- Shared Upload Components

---

# Scope (Mandatory)

การตรวจสอบและแก้ไข **ต้องครอบคลุมทั้งระบบ**

ห้ามตรวจสอบหรือแก้ไขเฉพาะ

```
Training Record ID = 277
```

Record 277 เป็นเพียงตัวอย่างที่พบปัญหาเท่านั้น

ต้องตรวจสอบทุก Workflow ที่เกี่ยวข้องกับ

- Create Training Record
- Save Draft
- Edit Draft
- Submit Draft
- Revision Requested
- Re-submit
- Upload Certificate
- Upload Supporting Files
- Remove Files
- HRD Review
- Employee View

ต้องยืนยันว่า Logic ทำงานถูกต้องกับทุก Record

ห้าม

- Hardcode Record ID
- Hardcode Status
- แก้ไขเฉพาะหน้าเดียว
- แก้เฉพาะเคสตัวอย่าง

การแก้ไขต้องอยู่ในระดับ

- Shared Workflow
- Shared Mutation
- Shared Upload Logic
- Shared Status Guard

---

# Current User Flow

ผู้ใช้งานทำงานดังนี้

```
Create Training Record

↓

Save Draft

↓

Open Draft

↓

Edit

↓

Click "บันทึกประวัติการอบรม"

↓

Runtime Error
```

Backend ส่งข้อความ

```
พนักงานสามารถอัปโหลดเอกสารได้เฉพาะรายการที่อยู่ในสถานะฉบับร่างหรือขอแก้ไขเท่านั้น
```

---

# Expected Workflow

Workflow ที่ถูกต้องต้องเป็น

```
Create

↓

Save Draft

↓

Edit Draft

↓

Validate

↓

Save Form

↓

Upload Certificate

↓

Upload Supporting Files

↓

Verify Upload Success

↓

Update Status

Draft

↓

Pending Review

↓

Refresh Query

↓

Redirect
```

ห้ามเปลี่ยน Status ก่อน Upload ทุกชนิดเสร็จ

---

# Mandatory Investigation

## 1. Workflow Analysis

ค้นหา

- handleSubmit
- onSubmit
- submitTrainingRecord
- updateTrainingRecord
- saveTrainingRecord
- uploadCertificate
- uploadAttachment
- saveDraft
- submitDraft

สร้าง Flow Diagram ปัจจุบัน

เช่น

```
Save

↓

Update Status

↓

Upload
```

หรือ

```
Save

↓

Upload

↓

Update Status
```

---

## 2. Execution Timeline

ห้ามเดาจาก Error

ต้องสร้าง Timeline จริง

```
User Click

↓

Validation

↓

Mutation A

↓

Mutation B

↓

Mutation C

↓

Upload

↓

Status Changed

↓

Redirect
```

ระบุ

- API ไหนเรียกก่อน
- API ไหนเรียกหลัง
- API ไหน await
- API ไหนทำงานพร้อมกัน

---

## 3. API Call Order

ตรวจสอบทุก API

เช่น

```
PATCH Training Record

POST Certificate

POST Attachment

PATCH Status
```

สร้างลำดับจริง

---

## 4. React Query Analysis

ตรวจสอบ

- useMutation
- mutate
- mutateAsync
- invalidateQueries
- refetch
- router.refresh
- router.push
- router.replace

สร้าง Flow ของ Mutation

---

## 5. Async Analysis

ตรวจสอบ

- async
- await
- Promise.all
- Promise.allSettled
- Promise.any
- queueMicrotask
- setTimeout
- background upload

หากพบ

ให้วิเคราะห์ผลกระทบต่อ Workflow

---

## 6. Race Condition Analysis

ตรวจสอบว่ามี Race Condition หรือไม่

ตัวอย่าง

```
PATCH Status

────────────┐

            ▼

Pending Review

            │

            ▼

POST Upload
```

หากพบ

อธิบาย

- สาเหตุ
- หลักฐาน
- วิธีแก้ไข

---

## 7. Upload Component Analysis

ตรวจสอบ

- CertificateUploader
- AttachmentUploader
- Dropzone
- Upload Hook

ว่ามี

- Auto Upload
- Upload On Mount
- Upload After Save
- Upload After State Change

หรือไม่

---

## 8. Component Lifecycle

ตรวจสอบ

- useEffect
- useMemo
- useCallback

ว่าทำให้ Upload หลัง Status เปลี่ยนหรือไม่

---

## 9. Backend Rule

ตรวจสอบ Business Rule

Backend อนุญาต Upload เฉพาะ

- Draft
- Revision Requested

ห้ามแก้ไข Rule นี้

ถือว่าเป็น Business Rule ที่ถูกต้อง

Frontend ต้องทำงานให้สอดคล้องกับ Backend

---

# UI Review

ตรวจสอบทุกหน้าที่เกี่ยวข้อง

เมื่อ Status ไม่ใช่

- Draft
- Revision Requested

ต้อง

- Disable Upload
- Disable Remove File
- Disable Save Draft
- Disable Submit

หรือแสดงเป็น Readonly

ห้ามเปิดให้ Upload แล้วปล่อยให้ Backend Reject

---

# Error Handling

Runtime Error ต้องไม่เกิด

ทุก Mutation

ทุก Upload

ทุก API

ต้องมี

```
try/catch
```

หรือ

```
mutation.onError
```

แสดง

- Toast
- Inline Error

แทน Runtime Error

---

# Validation

ก่อน Submit

ต้องผ่าน Validation ทั้งหมด

หาก Validation ไม่ผ่าน

- ไม่ Upload
- ไม่ Submit
- ไม่เปลี่ยน Status

---

# Required Fix

หากพบ

```
Update Status

↓

Upload
```

ให้แก้เป็น

```
Validate

↓

Save Form

↓

Upload Certificate

↓

Upload Attachment

↓

Verify Upload Success

↓

Update Status

↓

Invalidate Query

↓

Redirect
```

---

# Regression Test

ทดสอบทุก Record

ไม่ใช่เฉพาะ Record 277

อย่างน้อย

## Case 1

Draft

Create

↓

Save Draft

↓

Edit

↓

Submit

Expected

Success

---

## Case 2

Draft

Upload Certificate

↓

Submit

Expected

Success

---

## Case 3

Draft

Upload Multiple Attachments

↓

Submit

Expected

Success

---

## Case 4

Revision Requested

↓

Edit

↓

Upload

↓

Submit

Expected

Success

---

## Case 5

Pending Review

↓

Open

Expected

Readonly

Upload Disabled

---

## Case 6

Approved

↓

Open

Expected

Readonly

---

## Case 7

Rejected

↓

Open

Expected

เป็นไปตาม Business Rule

---

## Case 8

Existing Draft with Existing Files

↓

Edit

↓

Replace Files

↓

Submit

Expected

Success

---

## Case 9

Existing Draft without Files

↓

Submit

Expected

ทำงานตาม Validation

---

## Case 10

หลาย Record พร้อมกัน

Draft A

Draft B

Draft C

ต้องทำงานถูกต้องทุก Record

---

# Deliverables

สร้างเอกสาร

```
docs/reports/training-record-submit-workflow-review.md
```

ประกอบด้วย

## Executive Summary

สรุปปัญหา

---

## Current Workflow

Flow เดิม

---

## Expected Workflow

Flow ใหม่

---

## Execution Timeline

Timeline จริง

---

## API Call Sequence

ลำดับ API

---

## React Query Flow

Mutation ทั้งหมด

---

## Async Analysis

await / Promise

---

## Race Condition Analysis

พบหรือไม่

หลักฐาน

---

## Upload Component Review

ผลการตรวจสอบ

---

## Root Cause

อธิบายสาเหตุที่แท้จริง

พร้อมหลักฐาน

ห้ามสรุปจากการคาดเดา

---

## Files Modified

รายชื่อไฟล์ทั้งหมด

พร้อมเหตุผล

---

## Risk Assessment

ผลกระทบ

- Employee
- HRD
- Admin

---

## Regression Test Result

ผลการทดสอบทุก Case

---

## Remaining Issues

สิ่งที่ควรปรับปรุงต่อ

---

# Constraints

ห้าม

- เปลี่ยน Business Rule ของ Backend
- Hardcode Status
- Hardcode Record ID
- Hardcode Permission
- สร้าง API ใหม่ หาก API เดิมรองรับ
- เปลี่ยน Database Schema โดยไม่จำเป็น
- เปลี่ยน Public Interface ของ Shared Component หากไม่มีเหตุผล

ต้อง

- Reuse Shared Components
- Reuse Shared Services
- Reuse Existing Pattern
- รักษา Coding Style ของโปรเจค
- แก้ไขที่ Root Cause ไม่ใช่แก้ปลายเหตุ
- ตรวจสอบให้ครอบคลุมทั้งระบบ ไม่ใช่เฉพาะเคสตัวอย่าง
