# Prompt: Standardize Online Lesson Category (K/S/A) & Required Field Indicators

## Objective

ดำเนินการตรวจสอบ วิเคราะห์ และปรับปรุง Module **Online Lessons** ให้เป็นมาตรฐานเดียวกันทั้งระบบ โดยมีวัตถุประสงค์หลักดังนี้

1. เปลี่ยนฟิลด์ **หมวดหมู่ (Category)** ให้เป็น Select ที่ใช้ค่าคงที่ของระบบ (Knowledge / Skill / Attitude)
2. ตรวจสอบ Required Fields ทั้งหมดให้สอดคล้องกับ Validation
3. แสดงเครื่องหมาย **(\*) สีแดง** เฉพาะฟิลด์ที่ Required เท่านั้น
4. ลบเครื่องหมาย (\*) ออกจากฟิลด์ที่ไม่ Required
5. ปรับ UI, Validation, API และ Database Mapping ให้สอดคล้องกัน
6. ตรวจสอบทุกหน้าที่เกี่ยวข้องกับ Online Lessons

---

# Background

ปัจจุบันหน้า Online Lesson มีความไม่สอดคล้องระหว่าง

- UI
- Validation
- Business Rules

เช่น

- บาง Field ถูกบังคับกรอก แต่ไม่มีเครื่องหมาย \*
- บาง Field มี \* แต่จริง ๆ ไม่ได้ Required
- Category ยังไม่ใช้มาตรฐาน K/S/A ของระบบ Training

ต้องปรับให้ทั้งระบบมีมาตรฐานเดียวกัน

---

# IMPORTANT

ก่อนแก้ไข

AI ต้องตรวจสอบ Architecture ของ Project ก่อน

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

ต้อง Reuse

- Shared Form Components
- Shared Select Components
- Shared Validation
- Shared Zod Schema
- Shared API Pattern
- Shared Constants
- Shared Badge
- Shared Label Components

---

# Scope

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

- Create Online Lesson
- Edit Online Lesson
- View Online Lesson
- Detail Page
- List Page
- Filters
- Search
- API
- Validation
- DTO
- Type Definitions

รวมถึงทุก Component ที่ใช้ร่วมกัน

---

# Phase 0 — Architecture Audit

ก่อนแก้ไข

ตรวจสอบ

## Frontend

- Create Form
- Edit Form
- Shared Form
- Shared Label
- Shared Select
- Validation Display

---

## Backend

ตรวจสอบ

- Route Handler
- Server Action
- Service
- Repository
- DTO

---

## Database

ตรวจสอบว่า Category ปัจจุบันเก็บเป็นอะไร

เช่น

```
string

enum

lookup table
```

ห้ามเดา

อ้างอิงจาก Prisma Schema จริง

---

# Phase 1 — Category Redesign

## Business Rule

Category ของ Online Lesson

ให้เป็นค่าคงที่ของระบบ

ประกอบด้วย

```
Knowledge

Skill

Attitude
```

Database

เก็บเป็น Enum หรือ Constant

```
KNOWLEDGE

SKILL

ATTITUDE
```

UI

แสดง

```
K - Knowledge

S - Skill

A - Attitude
```

หรือ Label ตาม Design System ของระบบ

ห้ามใช้ Text Input

---

## Select

เปลี่ยน Category

เป็น

Select

Placeholder

```
เลือกหมวดหมู่
```

Options

```
K - Knowledge

S - Skill

A - Attitude
```

ห้ามให้ผู้ใช้กรอกเอง

---

## Validation

Category

Required

ต้องเลือก 1 ค่า

ข้อความ Error

```
กรุณาเลือกหมวดหมู่
```

---

# Phase 2 — Required Field Audit

ตรวจสอบทุก Field

ใน

Create

Edit

และ Shared Form

---

Rule

ตรวจสอบ

Validation Schema

เป็นหลัก

---

หาก

Validation

กำหนดว่า

Required

UI

ต้องมี

```
*
```

สีแดง

---

หาก

Validation

ไม่ได้ Required

UI

ต้องไม่มี

```
*
```

---

ห้ามมีความไม่ตรงกัน

---

# Phase 3 — Required Label Standard

ใช้ Pattern เดิมของ shadcn/ui

ตัวอย่าง

```
ชื่อบทเรียน *
```

โดย

```
*
```

ใช้สีแดง

เหมือนฟอร์มอื่นในระบบ

ห้ามสร้าง Component ใหม่ หากมี Shared Label อยู่แล้ว

---

# Phase 4 — Validation Review

ตรวจสอบ Validation ทุก Field

เช่น

- Title
- Description
- Category
- Cover
- Video
- Duration
- Visibility
- Provider
- Tags

หรือ Field ที่มีอยู่จริง

ห้ามเดา

ใช้ Schema จริง

---

หากพบว่า

UI

กับ

Validation

ไม่ตรงกัน

ให้ปรับ

UI

ตาม Validation

---

# Phase 5 — Database Mapping

ตรวจสอบ Mapping

UI

↓

DTO

↓

API

↓

Service

↓

Repository

↓

Database

Category

ต้อง Mapping

```
K

↓

KNOWLEDGE
```

```
S

↓

SKILL
```

```
A

↓

ATTITUDE
```

หรือใช้ Enum จริงของระบบ

ห้าม Hardcode

หากระบบมี Shared Enum

ต้อง Reuse

---

# Phase 6 — API Review

ตรวจสอบ

Create API

Edit API

Validation

ต้องรองรับ Category ใหม่

ห้ามรับค่าอื่น

เช่น

```
TEST

AAA

OTHER
```

หากไม่อยู่ใน Enum

ต้อง Reject

---

# Phase 7 — Edit Page

หน้า Edit

ต้องใช้

Category Select

แบบเดียวกับ

Create

และ

แสดงค่าเดิมได้ถูกต้อง

---

# Phase 8 — Filters

หากหน้า List

มี Filter

Category

ให้เปลี่ยนเป็น

Select

K/S/A

ด้วย

ห้ามใช้ Text Search

สำหรับ Category

---

# Phase 9 — Type Safety

ตรวจสอบ

TypeScript

ให้ใช้

Enum

หรือ

Literal Type

ของระบบ

ห้ามใช้

```
string
```

แบบกว้าง

ตัวอย่าง

```
type Category

=

"KNOWLEDGE"

|

"SKILL"

|

"ATTITUDE"
```

หรือ Enum เดิมของระบบ

---

# Phase 10 — Regression Testing

ตรวจสอบ

## Create

- Category เป็น Select
- Placeholder ถูกต้อง
- Required แสดง \*
- Validation ทำงาน

---

## Edit

- Category แสดงค่าเดิม
- เปลี่ยนค่าได้
- Save สำเร็จ

---

## View

- แสดง Category ถูกต้อง

---

## List

- Filter ใช้งานได้

---

## Validation

ทุก Field

ที่ Required

มี \*

ทุก Field

ที่ Optional

ไม่มี \*

---

## API

Reject

Invalid Category

---

## Database

Category

ถูกบันทึกถูกต้อง

---

## TypeScript

ไม่มี

Type Error

---

## ESLint

ไม่มี Error

---

# Code Quality

ตรวจสอบ

- ไม่มี Duplicate Logic
- ไม่มี Hardcode Category
- ไม่มี any ใหม่
- ไม่มี Dead Code
- ไม่มี console.log
- Reuse Existing Components
- Reuse Existing Enum
- Reuse Existing Validation

---

# Documentation

สร้างรายงาน

```
docs/online-lessons-category-standardization-report.md
```

---

รายงานต้องมี

```md
# Online Lessons Category Standardization Report

## Executive Summary

## Current Architecture

## Current Issues

## Category Design

## Required Field Audit

## Validation Audit

## Database Mapping

## API Changes

## UI Changes

## Files Modified

## Testing Result

## Regression Result

## Risks

## Recommendations
```

---

# Future Improvements

เสนอแนวทางเพิ่มเติม เช่น

- Category Color Badge
- Category Statistics Dashboard
- Category Permission
- Dynamic Category (หาก Business เปลี่ยนในอนาคต)
- Category Report

---

# Constraints

ห้าม

- เปลี่ยน Business Logic อื่น
- Hardcode Category
- Hardcode Enum
- เพิ่ม Library ใหม่
- ใช้ any
- เปลี่ยน Design System
- สร้าง Component ซ้ำ

ต้อง

- ใช้ Shared Enum
- ใช้ Shared Validation
- ใช้ Shared Label
- ใช้ Shared Select
- รักษา Type Safety
- รักษา Coding Standard
- รองรับการขยายไปยัง Module อื่น

---

# Deliverables

ดำเนินการดังนี้

1. Audit ระบบก่อนแก้ไข
2. แก้ไข Source Code
3. ตรวจสอบ Regression
4. สร้างรายงาน

```
docs/online-lessons-category-standardization-report.md
```

---

# Final Response

เมื่อดำเนินการเสร็จ ให้ตอบกลับเป็นภาษาไทย พร้อมสรุป

1. Architecture ที่ตรวจพบ
2. Category Design ที่ใช้
3. รายการ Required Fields ที่ตรวจพบ
4. การปรับ Required Indicator (\*)
5. Validation ที่แก้ไข
6. Database Mapping
7. API ที่แก้ไข
8. รายชื่อไฟล์ที่แก้ไข
9. ผลการทดสอบ
10. Regression Result
11. ความเสี่ยงที่เหลือ (ถ้ามี)
12. Path ของรายงาน

```
docs/online-lessons-category-standardization-report.md
```
