# Prompt: Permission Template Type Validation Audit & Fix

## Objective

ดำเนินการตรวจสอบ วิเคราะห์ และแก้ไขปัญหาในฟอร์มที่เกี่ยวข้องกับ **Permission Template** ซึ่งปัจจุบันพบ Validation Error ดังนี้

```text
Invalid input: expected number, received string
```

เป้าหมายคือให้ระบบสามารถเลือก Permission Template ได้อย่างถูกต้อง โดยไม่มี Type Mismatch ระหว่าง Frontend, Validation Schema และ Backend พร้อมทั้งสร้างเอกสารสรุปผลการดำเนินงานไว้ในโฟลเดอร์ `docs/`

---

# Background

ระบบกำลังพัฒนาโดยใช้แนวคิด **Permission Template First Architecture**

Permission Template เป็นตัวกำหนดสิทธิ์หลักของผู้ใช้งาน

เมื่อผู้ใช้เลือก Permission Template จาก Dropdown ไม่ควรเกิด Validation Error และข้อมูลต้องสามารถบันทึกได้ทั้ง Create และ Edit

---

# Scope

ตรวจสอบทุกส่วนที่เกี่ยวข้องกับ Permission Template ได้แก่

- Form Component
- Select Component
- TanStack Form
- React Hook Form (ถ้ามี)
- Zod Schema
- DTO
- API Request
- API Route
- Service Layer
- Repository
- Prisma
- Database Mapping
- TypeScript Types
- Default Values
- Edit Form
- Create Form

รวมถึงไฟล์ Shared ที่เกี่ยวข้อง

---

# Phase 1 — Architecture Audit

ก่อนแก้ไข ต้องตรวจสอบระบบทั้งหมดก่อน

## ตรวจสอบ

### Frontend

- Permission Template Select
- Form State
- Default Values
- Initial Values
- Edit Values
- Submit Handler

### Validation

ตรวจสอบ

- zod schema
- validator
- preprocess
- transform

### Backend

ตรวจสอบ

- Route Handler
- Server Action
- Service
- Repository
- Prisma

### Database

ตรวจสอบว่า

Permission Template ใช้

```
INT
```

หรือ

```
UUID
```

หรือ

```
String
```

ห้ามเดา

ต้องอ้างอิงจากโค้ดจริง

---

# Phase 2 — Root Cause Analysis

ค้นหาสาเหตุที่แท้จริง

เช่น

## Case A

Select ส่ง

```ts
"1";
```

แต่ schema

```ts
z.number();
```

---

## Case B

Select ส่ง

```ts
"employee";
```

แต่ database ต้องการ

```ts
1;
```

---

## Case C

Default Value

```ts
permissionTemplateId: "";
```

แต่ schema

```ts
z.number();
```

---

## Case D

Edit Form

โหลดข้อมูลมาเป็น

```ts
number;
```

แต่ Select ต้องการ

```ts
string;
```

---

## Case E

API รับ

```ts
string;
```

แต่ backend schema

```ts
number;
```

---

ต้องระบุให้ชัดเจนว่า

Root Cause ที่แท้จริงคืออะไร

พร้อมอธิบายเหตุผล

---

# Phase 3 — Fix Frontend

## ตรวจสอบ Select

ตัวอย่าง

```tsx
<Select
    value={...}
    onValueChange={...}
>
```

ต้องตรวจสอบว่า

value

และ

onValueChange

มี Type ที่ถูกต้อง

หาก Database ใช้ numeric id

ให้แปลงค่าอย่างเหมาะสม

เช่น

```tsx
value={
    field.state.value != null
        ? String(field.state.value)
        : undefined
}
```

และ

```tsx
onValueChange={(value) => {
    if (!value) {
        field.handleChange(undefined)
        return
    }

    field.handleChange(Number(value))
}}
```

ห้ามใช้

```ts
Number("");
```

จนกลายเป็น

```
0
```

โดยไม่ได้ตั้งใจ

---

# Phase 4 — Fix Default Values

ตรวจสอบ

Default Values

ทุกจุด

เช่น

ผิด

```ts
permissionTemplateId: "";
```

หรือ

```ts
permissionTemplateId: "1";
```

ให้ปรับให้สอดคล้องกับ schema

เช่น

```ts
undefined;
```

หรือ

```ts
null;
```

หรือ

```ts
number;
```

ตามมาตรฐานของระบบ

---

# Phase 5 — Fix Validation

ตรวจสอบ Zod Schema

หากต้องการ Number

ให้รองรับค่าจาก Select อย่างถูกต้อง

ตัวอย่าง

```ts
z.preprocess(...)
```

หรือ

ให้ Form State เป็น Number ตั้งแต่ต้น

เลือกวิธีที่สอดคล้องกับ Architecture ของโปรเจกต์

ห้ามเพิ่ม Logic ซ้ำซ้อน

---

# Phase 6 — Fix API

ตรวจสอบ Request Payload

ก่อนส่ง API

ต้องเป็น

```ts
number;
```

ไม่ใช่

```ts
string;
```

ตรวจสอบ

- mutation
- fetch
- api client

ทุกจุด

---

# Phase 7 — Fix Backend

ตรวจสอบ

- Route Handler
- Service
- DTO
- Validation

ต้องรับ Type ตรงกับ Frontend

ห้ามเกิด

```
string -> number
```

Mismatch

---

# Phase 8 — UX Improvement

ปัจจุบัน

ผู้ใช้เห็น

```text
Invalid input: expected number, received string
```

ซึ่งเป็น Technical Error

ให้ปรับเป็นข้อความที่ผู้ใช้เข้าใจได้

เช่น

```
กรุณาเลือก Permission Template
```

หรือ

```
กรุณาเลือกเทมเพลตสิทธิ์การใช้งาน
```

โดยยังคงเก็บ Technical Error ไว้สำหรับ Developer

---

# Phase 9 — Regression Testing

ตรวจสอบ

## Create

- เปิดหน้า
- ไม่มี Error
- เลือก Permission Template
- Submit ได้

---

## Edit

- โหลดค่าเดิมได้
- แสดงค่าใน Select ถูกต้อง
- เปลี่ยนค่าได้
- Save ได้

---

## Validation

- ไม่เลือก Template
- แสดงข้อความภาษาไทย

---

## API

ตรวจสอบ Payload

ต้องเป็น

```ts
permissionTemplateId: number;
```

---

## Database

ตรวจสอบข้อมูลที่บันทึก

ต้องตรงกับ Template ที่เลือก

---

## TypeScript

ต้องไม่มี

- type error
- eslint error
- any ใหม่

---

# Code Quality

หลังแก้ไขแล้ว

ตรวจสอบ

- ไม่มี duplicated logic
- ไม่มี dead code
- ไม่มี unused imports
- ไม่มี console.log
- ไม่มี TODO ค้าง
- ไม่มี workaround ชั่วคราว
- ใช้ Shared Component เดิม
- ใช้ Shared Utility เดิม
- ไม่สร้าง Helper ใหม่โดยไม่จำเป็น

---

# Deliverables

## 1. แก้ไข Source Code

แก้ไขเฉพาะส่วนที่จำเป็น

ห้าม Refactor ส่วนอื่น

---

## 2. สร้างรายงาน

สร้างไฟล์

```
docs/permission-template-validation-fix-report.md
```

---

รายงานต้องประกอบด้วย

# Permission Template Validation Fix Report

## Executive Summary

สรุปปัญหา

---

## Root Cause Analysis

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

---

## Architecture Review

อธิบาย Flow

Frontend

↓

Validation

↓

API

↓

Backend

↓

Database

---

## Files Modified

ระบุทุกไฟล์

พร้อมเหตุผลที่แก้ไข

---

## Implementation Details

อธิบาย

- Form
- Select
- Schema
- API
- Backend

ที่ถูกแก้ไข

---

## Before

อธิบายพฤติกรรมเดิม

---

## After

อธิบายพฤติกรรมใหม่

---

## Validation Result

ผลการทดสอบ

- Create
- Edit
- Validation
- API
- Database

---

## Regression Check

รายการที่ตรวจสอบแล้ว

---

## Risks

ผลกระทบที่อาจเกิดขึ้น

---

## Recommendation

ข้อเสนอแนะเพิ่มเติม

---

# Constraints

ต้องปฏิบัติตามข้อกำหนดดังต่อไปนี้

- ห้ามแก้ Database Schema โดยไม่จำเป็น
- ห้าม Hardcode Permission Template ID
- ห้ามเปลี่ยน Business Logic
- ห้ามเปลี่ยน Permission Logic
- ห้ามเปลี่ยน API Contract หากไม่จำเป็น
- ห้ามใช้ any
- ห้ามเพิ่ม Library ใหม่
- ต้องรักษา Type Safety
- ต้องใช้ Shared Component ของระบบ
- ต้องทำตาม Coding Standard ของโปรเจกต์
- ต้องรักษา Backward Compatibility หากมี

---

# Final Response

เมื่อดำเนินการเสร็จ ให้สรุปผลเป็นภาษาไทย โดยประกอบด้วย

1. Root Cause ที่พบ
2. แนวทางการแก้ไข
3. รายชื่อไฟล์ที่แก้ไข
4. ผลการทดสอบ
5. ความเสี่ยงที่เหลือ (ถ้ามี)
6. Path ของรายงานที่สร้างใน `docs/permission-template-validation-fix-report.md`
7. ข้อเสนอแนะเพิ่มเติม (ถ้ามี)
