alla-tms/plans/tms-system-full-audit-prompts.md

# TMS Full System Audit Prompts

เอกสารคำสั่งสำหรับใช้สั่ง AI / Codex ตรวจสอบระบบ Training Management System (TMS) แบบครบวงจร แบ่งการตรวจสอบออกเป็นหลายเฟส เพื่อให้สามารถตรวจสอบอย่างเป็นระบบ ลดความเสี่ยงจากการตรวจสอบพร้อมกันทั้งหมด และสามารถนำผลลัพธ์ไปวางแผนแก้ไขใน Coding Phase ถัดไปได้อย่างชัดเจน

> **หลักการสำคัญ:** ทุกเฟสในเอกสารนี้เป็นการตรวจสอบ วิเคราะห์ และจัดทำรายงานเท่านั้น ห้ามแก้ไขโค้ด ห้ามเปลี่ยนโครงสร้างฐานข้อมูล ห้ามสร้าง Migration และห้าม Refactor เว้นแต่ได้รับคำสั่งให้เข้าสู่ Coding Phase อย่างชัดเจนภายหลัง

---

# 1. ภาพรวมการตรวจสอบ

ให้แบ่งการตรวจสอบระบบออกเป็น 7 เฟสหลัก ดังนี้

1. Phase 1 — Architecture Audit
2. Phase 2 — Functional Review
3. Phase 3 — Permission & Authorization Audit
4. Phase 4 — UI/UX & Design System Audit
5. Phase 5 — Code Quality & Performance Audit
6. Phase 6 — Security Audit
7. Phase 7 — Production Readiness Review

แต่ละเฟสต้องสร้างรายงานแยกกันภายใต้โฟลเดอร์:

```text
docs/reviews/
```

ไฟล์ผลลัพธ์ที่ต้องสร้าง:

```text
docs/reviews/phase-1-architecture-audit.md
docs/reviews/phase-2-functional-review.md
docs/reviews/phase-3-permission-authorization-audit.md
docs/reviews/phase-4-ui-ux-design-system-audit.md
docs/reviews/phase-5-code-quality-performance-audit.md
docs/reviews/phase-6-security-audit.md
docs/reviews/phase-7-production-readiness-review.md
docs/reviews/full-system-audit-summary.md
```

---

# 2. กติกากลางสำหรับทุกเฟส

ก่อนเริ่มตรวจสอบทุกเฟส ให้ปฏิบัติตามข้อกำหนดต่อไปนี้

## 2.1 ห้ามแก้ไขระบบ

ในช่วง Audit ให้ดำเนินการเฉพาะ:

- อ่านและตรวจสอบโค้ด
- ตรวจสอบโครงสร้างโปรเจกต์
- วิเคราะห์ Workflow
- วิเคราะห์ Business Rule
- วิเคราะห์ Permission
- วิเคราะห์ UI/UX
- วิเคราะห์ฐานข้อมูล
- ตรวจสอบ Configuration
- ตรวจสอบ Test ที่มีอยู่
- จัดทำรายงาน
- เสนอแนวทางแก้ไขในระดับคำแนะนำ

ห้ามดำเนินการดังต่อไปนี้:

- ห้ามแก้ไข Source Code
- ห้ามเพิ่มหรือลบไฟล์โค้ด
- ห้าม Refactor
- ห้ามแก้ Schema
- ห้ามสร้างหรือรัน Migration
- ห้ามแก้ Environment Variable
- ห้ามติดตั้ง Package เพิ่ม
- ห้ามลบ Package
- ห้ามแก้ Permission จริง
- ห้ามเปลี่ยนข้อมูลในฐานข้อมูล
- ห้ามแก้ UI
- ห้ามแก้ API

หากพบปัญหา ให้บันทึกลงรายงานเท่านั้น

## 2.2 ตรวจสอบจากระบบจริง

ห้ามสรุปจากชื่อไฟล์เพียงอย่างเดียว ต้องตรวจสอบอย่างน้อย:

- Route
- Page
- Layout
- Component
- Hook
- Service
- Repository
- API Route / Route Handler
- Server Action
- Schema Validation
- Type
- Database Schema
- Permission Guard
- Navigation Config
- Middleware
- Error Handling
- Loading State
- Empty State
- Test ที่เกี่ยวข้อง

## 2.3 ห้ามคาดเดา

หากไม่พบหลักฐานในโค้ด ให้ระบุว่า:

```text
ไม่พบหลักฐานยืนยันจากโค้ดที่ตรวจสอบ
```

ห้ามสรุปว่าระบบรองรับหรือไม่รองรับโดยไม่มีหลักฐาน

## 2.4 อ้างอิงตำแหน่งที่พบ

ทุก Finding ควรระบุ:

- ชื่อไฟล์
- Path
- Function / Component / Route ที่เกี่ยวข้อง
- บรรทัดโดยประมาณ หากตรวจสอบได้
- Module ที่ได้รับผลกระทบ

ตัวอย่าง:

```text
ไฟล์: src/app/api/training-records/route.ts
ส่วนที่เกี่ยวข้อง: POST handler
ประเด็น: ตรวจพบการตรวจสอบ Permission เฉพาะฝั่ง UI แต่ไม่พบ API Guard
```

## 2.5 Severity Standard

จัดระดับความรุนแรงโดยใช้มาตรฐานเดียวกันทุกเฟส

### Critical

ปัญหาที่อาจทำให้:

- ข้อมูลรั่วไหล
- ผู้ไม่มีสิทธิ์เข้าถึงข้อมูลสำคัญ
- ระบบหลักไม่สามารถใช้งานได้
- ข้อมูลเสียหายหรือสูญหาย
- Workflow อนุมัติผิดพลาดอย่างร้ายแรง
- Production ไม่สามารถ Deploy ได้

### High

ปัญหาที่:

- กระทบ Feature หลัก
- Permission ผิดบางกรณี
- Business Rule สำคัญทำงานไม่ครบ
- เกิด Error ใน Workflow หลัก
- มีความเสี่ยงด้าน Security สูง
- กระทบผู้ใช้จำนวนมาก

### Medium

ปัญหาที่:

- กระทบ UX หรือความสม่ำเสมอ
- Logic บางกรณีผิด
- Validation ไม่ครบ
- Code Maintainability ต่ำ
- Performance เริ่มมีความเสี่ยง
- กระทบ Feature รอง

### Low

ปัญหาที่:

- เป็นข้อเสนอแนะเพื่อปรับปรุง
- Naming ไม่สม่ำเสมอ
- UI Detail เล็กน้อย
- Documentation ไม่ครบ
- Code Style ไม่เป็นมาตรฐาน แต่ยังไม่กระทบการใช้งาน

## 2.6 รูปแบบ Finding

ทุก Finding ให้ใช้รูปแบบนี้:

```md
### [Severity] ชื่อปัญหา

**Module:**

**ตำแหน่งที่พบ:**

**รายละเอียด:**

**ผลกระทบ:**

**หลักฐานจากโค้ด:**

**สถานการณ์ตัวอย่าง:**

**คำแนะนำ:**

**ต้องแก้ก่อน Production หรือไม่:** ใช่ / ไม่ใช่ / ควรพิจารณา
```

## 2.7 ห้ามรายงานแบบกว้างเกินไป

หลีกเลี่ยงคำแนะนำ เช่น:

```text
ควรปรับปรุงโค้ดให้ดีขึ้น
ควรเพิ่ม Security
ควรทำ UI ให้สวยขึ้น
```

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

- ส่วนใดมีปัญหา
- ปัญหาเกิดจากอะไร
- กระทบใคร
- ควรแก้แบบใด
- ลำดับความสำคัญเท่าใด

---

# 3. Phase 1 — Architecture Audit

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior Software Architect และ Senior Full-Stack Engineer

หน้าที่ของคุณคือทำ Architecture Audit ระบบ Training Management System (TMS) ทั้งโปรเจกต์ โดยตรวจสอบโครงสร้างระบบจริงจาก Source Code ปัจจุบัน

## วัตถุประสงค์

ตรวจสอบว่าสถาปัตยกรรมของระบบมีความชัดเจน เป็นระบบ รองรับการดูแลระยะยาว และเหมาะสมกับระบบ Enterprise ภายในองค์กรหรือไม่

## ขอบเขตการตรวจสอบ

### 1. Project Structure

ตรวจสอบ:

- โครงสร้าง Folder หลัก
- การแบ่ง App Route
- การแบ่ง Feature Module
- การวาง Component
- การวาง Hook
- การวาง Service
- การวาง Repository
- การวาง Schema
- การวาง Type
- การวาง Constant
- การวาง Utility
- การวาง Permission
- การวาง Test
- การวาง Documentation

ตรวจสอบว่ามีปัญหาเหล่านี้หรือไม่:

- ไฟล์กระจายหลายตำแหน่ง
- Feature เดียวกันอยู่หลาย Folder
- Shared Component และ Feature Component ปะปนกัน
- Business Logic อยู่ใน UI มากเกินไป
- API เรียก Database โดยตรงโดยไม่มี Layer ที่ชัดเจน
- Naming Convention ไม่สม่ำเสมอ
- Dependency ข้าม Module มากเกินไป

### 2. Layer Separation

ตรวจสอบการแยก Layer:

- Presentation Layer
- Application Layer
- Domain / Business Logic
- Data Access Layer
- Infrastructure Layer

ตรวจสอบว่า:

- Component มี Business Logic มากเกินไปหรือไม่
- API Handler มี Logic มากเกินไปหรือไม่
- Repository รับผิดชอบเฉพาะ Data Access หรือไม่
- Validation อยู่ในตำแหน่งที่เหมาะสมหรือไม่
- Permission Logic กระจายหลายจุดหรือไม่
- Error Handling ถูกจัดการรวมศูนย์หรือไม่

### 3. Module Boundary

ตรวจสอบ Module หลัก เช่น:

- Authentication
- User / Employee
- Organization
- Training Records
- Training Approval
- Online Lessons
- Announcements
- Policies
- Reports
- Notifications
- Permission Template
- Audit Logs
- Settings

ตรวจสอบว่าแต่ละ Module:

- มีขอบเขตชัดเจนหรือไม่
- เรียกใช้งานข้าม Module อย่างเหมาะสมหรือไม่
- มี Circular Dependency หรือไม่
- มี Logic ซ้ำหรือไม่
- มี Shared Type หรือ Shared Constant ที่ผิดขอบเขตหรือไม่

### 4. Data Flow

ตรวจสอบ Flow ตั้งแต่:

```text
UI → Form Validation → Action/API → Permission → Service → Repository → Database
```

ตรวจสอบว่า:

- Flow สม่ำเสมอทั้งระบบหรือไม่
- บางหน้าข้าม Layer หรือไม่
- Error ถูกส่งกลับในรูปแบบเดียวกันหรือไม่
- Response Structure มีมาตรฐานหรือไม่
- Transaction Boundary ชัดเจนหรือไม่

### 5. State Management

ตรวจสอบ:

- Server State
- Client State
- Form State
- URL State
- Filter State
- Pagination State
- Dialog / Sheet State

ตรวจสอบว่ามี:

- State ซ้ำซ้อน
- State ที่ควรอยู่ใน URL แต่เก็บใน Component
- State ที่ควรอยู่ Server แต่เก็บ Client
- Re-fetch ที่ไม่จำเป็น
- Prop Drilling มากเกินไป

### 6. Authentication & Authorization Architecture

ตรวจสอบภาพรวมว่า:

- Authentication อยู่จุดใด
- Session ถูกอ่านอย่างไร
- Authorization ถูกเรียกใช้จากจุดใด
- Permission Template ถูกใช้จริงหรือไม่
- Compatibility Mode เดิมยังเหลืออยู่หรือไม่
- businessRole / isHRD / Role-based Logic ยังปะปนกับ Permission-first หรือไม่
- UI Guard, Route Guard และ API Guard ใช้มาตรฐานเดียวกันหรือไม่

### 7. Database Architecture

ตรวจสอบ:

- Schema Design
- Relation
- Foreign Key
- Unique Constraint
- Index
- Soft Delete
- Audit Field
- Status Field
- Versioning
- Approval History
- Notification Record
- File Metadata

### 8. Maintainability

ตรวจสอบว่า:

- เพิ่ม Feature ใหม่ได้ง่ายหรือไม่
- เปลี่ยน Permission ได้ง่ายหรือไม่
- เปลี่ยน Workflow ได้ง่ายหรือไม่
- เปลี่ยน Status ได้ง่ายหรือไม่
- มี Magic String มากหรือไม่
- มี Duplicate Logic หรือไม่
- มี God Component / God Service หรือไม่

## วิธีดำเนินการ

1. สำรวจโครงสร้างโปรเจกต์ทั้งหมด
2. ระบุ Module และ Layer ปัจจุบัน
3. ตรวจสอบ Dependency ระหว่าง Module
4. ตรวจสอบตัวอย่าง Flow อย่างน้อย 3 Flow ได้แก่:
   - Create Training Record
   - Approve / Reject Training Record
   - Create / Approve / Publish Announcement หรือ Online Lesson
5. ตรวจสอบ Permission Architecture
6. ตรวจสอบ Database Architecture
7. สรุป Finding ตาม Severity

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-1-architecture-audit.md
```

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

1. Executive Summary
2. Current Architecture Overview
3. Project Structure Assessment
4. Layer Separation Assessment
5. Module Boundary Assessment
6. Data Flow Assessment
7. Authentication & Authorization Architecture
8. Database Architecture Assessment
9. Maintainability Assessment
10. Findings by Severity
11. Architecture Risks
12. Recommended Target Architecture
13. Recommended Remediation Order
14. Files Reviewed
15. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามแก้ไขโค้ด
- ห้าม Refactor
- ห้ามสร้างไฟล์โค้ดใหม่
- ให้สร้างเฉพาะรายงาน Audit
- ทุกข้อสรุปต้องมีหลักฐานอ้างอิงจากโค้ด
```

---

# 4. Phase 2 — Functional Review

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior Business Analyst, QA Lead และ Senior Full-Stack Engineer

หน้าที่ของคุณคือทำ Functional Review ระบบ Training Management System (TMS) ทั้งระบบ โดยตรวจสอบว่า Feature, Workflow และ Business Rule ทำงานครบตามความต้องการหรือไม่

## วัตถุประสงค์

- ตรวจสอบความครบถ้วนของระบบ
- ตรวจสอบ Missing Feature
- ตรวจสอบ Business Logic
- ตรวจสอบ Workflow
- ตรวจสอบ Edge Case
- ตรวจสอบ Error Handling
- ตรวจสอบความสอดคล้องระหว่าง UI, API และ Database

## Module ที่ต้องตรวจสอบ

### 1. Authentication

ตรวจสอบ:

- Login
- Logout
- Session
- Unauthorized
- Forbidden
- Session Expired
- First-time Access
- Employee Lookup
- LDAP / AD Integration หากมี

### 2. Dashboard

ตรวจสอบ Dashboard ของ:

- Employee
- HRD Staff
- HRD Manager
- IT Admin
- Super Admin

ตรวจสอบ:

- KPI
- จำนวนรายการ
- Training Hour
- K/S/A
- Pending Approval
- Announcement
- Online Lesson
- Filter by Year / Company / Department
- Empty State
- Error State

### 3. Employee Management

ตรวจสอบ:

- Employee List
- Search by Employee Code
- Search by Employee Name
- Filter by Company
- Filter by Department
- Position
- Status
- Employee Detail
- Permission Assignment
- Sorting
- Pagination

มาตรฐานการแสดงข้อมูลพนักงานต้องตรวจสอบว่าใช้ลำดับ:

```text
รหัสพนักงาน → ชื่อพนักงาน → ตำแหน่ง → ฝ่าย
```

### 4. Training Records

ตรวจสอบ:

- Create
- Save Draft
- Submit for Review
- Edit Draft
- Delete Draft
- View Detail
- Upload Certificate / Evidence
- Download Attachment
- Duplicate Warning
- Validation
- Status Transition
- Employee Ownership
- HRD Edit
- HRD Approve
- HRD Reject
- HRD Return for Edit
- Import Training Records
- Excel Template Download
- Imported Records become Approved
- Export

ตรวจสอบ Workflow อย่างน้อย:

```text
Draft → Pending Review → Approved
Draft → Pending Review → Rejected
Draft → Pending Review → Returned for Edit → Pending Review
```

### 5. Online Lessons

ตรวจสอบ:

- Create Draft
- Submit for Review
- Edit Draft
- Delete Draft
- Category K/S/A
- Video URL
- Video File
- Thumbnail
- Required Field
- Preview
- Approve
- Reject
- Publish
- Schedule Publish
- Unpublish
- Versioning
- Employee View
- Lesson Completion หากมี

### 6. Announcements

ตรวจสอบ:

- Announcement List
- Table Layout
- Create Draft
- Submit for Review
- Edit
- Delete
- Approve
- Reject
- Publish
- Schedule Publish
- Pin / Unpin
- Preview
- Versioning
- Audience
- Expiration
- Employee View

ตรวจสอบว่าปุ่ม Pin / Unpin อยู่ในตำแหน่งที่เหมาะสมตาม Workflow ปัจจุบัน และไม่ปะปนกับการสร้างประกาศโดยไม่จำเป็น

### 7. Policy Management

ตรวจสอบ:

- Policy List
- Create
- Edit
- Delete
- Soft Delete
- View Detail
- Versioning
- Effective Date
- Status
- Publish
- Existing Data Compatibility
- Permission
- Audit History

### 8. Approval Workflow

ตรวจสอบ:

- HRD Staff Submit
- HRD Manager Review
- Super Admin Override
- Approve
- Reject
- Return for Edit
- Publish after Approval
- Approval History
- Comment / Reason
- Status Consistency
- Notification

### 9. Permission Template Management

ตรวจสอบ:

- Create Template
- Edit Template
- Clone Template
- Delete Template
- Soft Delete
- Assign to User
- Add Additional Permission
- Permission Description ภาษาไทย
- Permission Matrix
- Default Template
- Existing Role Compatibility

### 10. Reports

ตรวจสอบ:

- Employee Training Report
- Department Report
- Company Report
- K/S/A Report
- Required Hours Report
- Missing Training Report
- Approval Report
- Export CSV
- Export Excel
- Export PDF
- Filter
- Sort
- Pagination

### 11. Notifications

ตรวจสอบ:

- In-app Notification
- Email Notification
- Read / Unread
- Notification Link
- Approval Notification
- Rejection Notification
- Return for Edit Notification
- Publish Notification
- Error Handling

### 12. Audit Log

ตรวจสอบ:

- Create
- Update
- Delete
- Approve
- Reject
- Publish
- Permission Change
- Login / Security Event หากมี
- Actor
- Timestamp
- Old Value
- New Value
- Entity Reference

### 13. Global Behavior

ตรวจสอบทั้งระบบ:

- รายการที่สร้างใหม่แสดงก่อนเสมอ
- Sorting ใช้ created_at เป็นหลัก เว้นแต่มี Requirement เฉพาะ
- Search ทำงานตรงกันทุกหน้า
- Pagination ทำงานหลัง Search / Filter
- Loading State
- Empty State
- Error State
- Toast
- Form Validation
- Required Mark
- Back Navigation
- Unsaved Change Warning

## วิธีดำเนินการ

1. สร้าง Feature Inventory
2. ตรวจสอบ Route และหน้าจอทั้งหมด
3. ตรวจสอบ API / Server Action ที่รองรับแต่ละ Feature
4. ตรวจสอบ Status Transition
5. ตรวจสอบ Validation
6. ตรวจสอบ Negative Case
7. ตรวจสอบ Edge Case
8. เปรียบเทียบ UI, API และ Database
9. ระบุ Missing Feature และ Logic Gap

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-2-functional-review.md
```

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

1. Executive Summary
2. Feature Inventory
3. Module-by-Module Review
4. Workflow Review
5. Status Transition Review
6. Validation Review
7. Error Handling Review
8. Edge Cases
9. Missing Features
10. Inconsistent Behaviors
11. Findings by Severity
12. Regression Risk
13. Recommended Remediation Order
14. Functional Test Scenarios ที่ควรเพิ่ม
15. Files Reviewed
16. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามแก้ไขโค้ด
- ห้ามแก้ Workflow
- ห้ามเพิ่ม Feature
- ให้บันทึกผลการตรวจสอบเท่านั้น
- ทุก Finding ต้องระบุ Feature และสถานการณ์ที่ทำให้เกิดปัญหา
```

---

# 5. Phase 3 — Permission & Authorization Audit

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior Application Security Engineer และ Authorization Architect

หน้าที่ของคุณคือทำ Permission & Authorization Audit ระบบ TMS ทั้งระบบ โดยตรวจสอบสิทธิ์ตั้งแต่ Navigation, Page, Route, API, Server Action, Data Scope และ Action Level

## วัตถุประสงค์

ตรวจสอบว่า:

- ผู้ใช้เห็นเฉพาะเมนูที่มีสิทธิ์
- ผู้ใช้เข้าเฉพาะหน้าที่มีสิทธิ์
- ผู้ใช้เรียก API ได้เฉพาะสิทธิ์ที่อนุญาต
- ผู้ใช้จัดการข้อมูลได้เฉพาะ Scope ที่กำหนด
- Direct URL ไม่สามารถข้าม Permission
- API ไม่พึ่งพาเฉพาะการซ่อนปุ่มใน UI
- Permission-first Architecture ถูกใช้จริงทั้งระบบ

## กลุ่มผู้ใช้ที่ต้องตรวจสอบ

อย่างน้อย:

- Employee / User
- Staff / HRD Staff
- Manager / HRD Manager
- IT Admin
- Super Admin

หากระบบใช้ Permission Template เป็นหลัก ให้ยึด Effective Permission จริง ไม่ให้สรุปจาก Role Name เพียงอย่างเดียว

## ขอบเขตการตรวจสอบ

### 1. Navigation Permission

ตรวจสอบ:

- nav-config
- sidebar
- menu group
- submenu
- mobile navigation
- dashboard shortcut
- action button

ตรวจสอบว่าเมนูถูกซ่อนหรือแสดงตาม Permission จริงหรือไม่

### 2. Page / Route Guard

ตรวจสอบทุก Route เช่น:

```text
/dashboard
/dashboard/employees
/dashboard/training-records
/dashboard/training-records/create
/dashboard/training-records/pending
/dashboard/online-lessons
/dashboard/announcements
/dashboard/policies
/dashboard/reports
/dashboard/permission-templates
/dashboard/settings
```

สำหรับทุก Route ให้ระบุ:

- Permission ที่ต้องใช้
- ผู้ใช้ที่เข้าได้
- ผู้ใช้ที่เข้าไม่ได้
- Guard อยู่ที่ใด
- Direct URL ป้องกันหรือไม่
- Unauthorized Redirect ถูกต้องหรือไม่

### 3. API / Server Action Guard

ตรวจสอบทุก API และ Server Action:

- GET
- POST
- PUT
- PATCH
- DELETE
- Download
- Import
- Export
- Approve
- Reject
- Publish
- Pin
- Assign Permission

ตรวจสอบว่า:

- มี Authentication Guard
- มี Permission Guard
- มี Ownership Check
- มี Data Scope Check
- มี Validation ก่อนทำงาน
- ไม่เชื่อข้อมูล Role จาก Client

### 4. Action-Level Permission

ตรวจสอบสิทธิ์ระดับ Action:

- View
- Create
- Edit
- Delete
- Submit
- Approve
- Reject
- Return for Edit
- Publish
- Unpublish
- Pin
- Import
- Export
- Assign Permission
- Manage Settings

### 5. Data Scope

ตรวจสอบว่า:

- Employee เห็นเฉพาะข้อมูลของตนเอง
- HRD เห็นตาม Company / Department Scope ที่กำหนด
- HRD Manager เห็นข้อมูลที่ต้องอนุมัติ
- IT Admin เห็นข้อมูลตามสิทธิ์ที่ได้รับ
- Super Admin เห็นทุก Scope
- Search / Filter ไม่ทำให้เห็นข้อมูลข้าม Scope
- Export ไม่ข้าม Data Scope
- API Detail ไม่เปิดเผยข้อมูลเมื่อเดา ID

### 6. Permission Template

ตรวจสอบ:

- Effective Permission Calculation
- Template Assignment
- Additional Permission
- Permission Override
- Clone Template
- Soft Delete Template
- Deleted Template Effect
- Permission Cache
- Session Refresh

### 7. Compatibility Mode

ค้นหาและรายงานการใช้งาน Logic เดิม เช่น:

- role ===
- businessRole
- isHRD()
- isAdmin()
- hardcoded role name
- switch by role

ระบุว่าจุดใดยังไม่ย้ายไปใช้ Permission-first

### 8. Permission Description

ตรวจสอบว่า Permission แต่ละรายการมี:

- Key
- ชื่อแสดงผล
- Description ภาษาไทย
- Module
- Action
- Risk Level หากมี

### 9. Permission Matrix

สร้าง Matrix อย่างน้อยในระดับ:

| Module | Action | Required Permission | Employee | HRD Staff | HRD Manager | IT Admin | Super Admin |
|---|---|---|---|---|---|---|---|

หากสิทธิ์ขึ้นอยู่กับ Template ให้ใช้คำว่า:

```text
ขึ้นอยู่กับ Effective Permission
```

และต้องระบุ Default Template ปัจจุบันแยกต่างหาก

## วิธีดำเนินการ

1. Inventory Permission ทั้งระบบ
2. Inventory Route
3. Inventory API / Server Action
4. Mapping Route → Permission
5. Mapping API → Permission
6. ตรวจสอบ Ownership และ Data Scope
7. ตรวจสอบ Navigation
8. ตรวจสอบ Compatibility Mode
9. สร้าง Permission Matrix
10. ระบุช่องโหว่และ Inconsistency

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-3-permission-authorization-audit.md
```

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

1. Executive Summary
2. Authorization Architecture Overview
3. Permission Inventory
4. Route Permission Matrix
5. API Permission Matrix
6. Action-Level Permission Matrix
7. Role / Template Mapping
8. Data Scope Assessment
9. Direct URL Assessment
10. UI vs API Authorization Consistency
11. Compatibility Mode Findings
12. Missing Permission Descriptions
13. Findings by Severity
14. Privilege Escalation Risks
15. Recommended Remediation Order
16. Files Reviewed
17. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามแก้ Permission
- ห้ามเพิ่ม Guard
- ห้ามลบ Compatibility Code
- ห้ามแก้ Navigation
- ให้สร้างรายงานเท่านั้น
- Critical และ High Finding ต้องมี Scenario การโจมตีหรือการเข้าถึงที่ผิดสิทธิ์ประกอบ
```

---

# 6. Phase 4 — UI/UX & Design System Audit

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior Product Designer, UX Auditor และ Frontend Architect

หน้าที่ของคุณคือทำ UI/UX & Design System Audit ระบบ TMS ทั้งระบบ โดยตรวจสอบความสม่ำเสมอ ความเข้าใจง่าย การใช้งานจริง Responsive และ Accessibility

## วัตถุประสงค์

- ทำให้ UI ใช้มาตรฐานเดียวกันทั้งระบบ
- ลดความสับสนของผู้ใช้
- ตรวจสอบ Workflow ของหน้าจอ
- ตรวจสอบ Form, Table, Dialog, Empty State และ Feedback
- ตรวจสอบ Responsive และ Accessibility

## ขอบเขตการตรวจสอบ

### 1. Layout

ตรวจสอบ:

- Page Header
- Breadcrumb
- Content Width
- Card Layout
- Section Spacing
- Grid
- Responsive Breakpoint
- Sidebar Interaction
- Mobile Layout

### 2. Typography

ตรวจสอบ:

- Heading
- Subheading
- Label
- Description
- Helper Text
- Error Text
- Table Text
- Empty State Text

### 3. Color & Status

ตรวจสอบ:

- Primary
- Secondary
- Destructive
- Success
- Warning
- Info
- Muted
- Focus Ring
- Disabled

ตรวจสอบ Status Badge เช่น:

- Draft
- Pending Review
- Approved
- Rejected
- Returned for Edit
- Published
- Scheduled
- Inactive

ให้ตรวจสอบว่าชื่อ สี และความหมายตรงกันทุกหน้า

### 4. Button Standard

ตรวจสอบปุ่ม:

- สร้าง
- บันทึกฉบับร่าง
- บันทึกส่งตรวจสอบ
- อนุมัติ
- ไม่อนุมัติ
- ส่งกลับแก้ไข
- เผยแพร่
- แก้ไข
- ลบ
- ยกเลิก
- ย้อนกลับ
- Import
- Export
- Download Template

ตรวจสอบ:

- Variant
- Size
- Icon
- Order
- Alignment
- Loading State
- Disabled State
- Confirmation

### 5. Table Standard

ตรวจสอบทุก Data Table:

- Column Order
- Column Width
- Alignment
- Truncate
- Tooltip
- Header Height
- Row Height
- Action Column
- Search
- Filter
- Sort
- Pagination
- Empty State
- Loading
- Responsive Scroll

มาตรฐานตารางพนักงานต้องเป็น:

```text
รหัสพนักงาน → ชื่อพนักงาน → ตำแหน่ง → ฝ่าย → จัดการ
```

ตรวจสอบว่าคอลัมน์ Action มีขนาดคงที่และจัดชิดขวาอย่างสม่ำเสมอ

### 6. Form Standard

ตรวจสอบ:

- Label
- Required Mark
- Description
- Placeholder
- Validation
- Error Message
- Input Size
- Select
- Date Picker
- Time Picker
- File Upload
- Drag & Drop
- Existing Attachment
- Submit Button
- Unsaved Change

Required Mark ให้แสดงเฉพาะ Field ที่ Validation กำหนดว่าจำเป็น

### 7. File Attachment UX

ตรวจสอบว่า:

- ถ้ามีไฟล์ ให้แสดงชื่อไฟล์และ Action ที่เกี่ยวข้อง
- ถ้าไม่มีไฟล์ ให้แสดงข้อความ “ไม่มีไฟล์แนบ”
- ไม่แสดง Drag & Drop ในหน้า View หรือส่วนที่ไม่ใช่ Upload Mode
- Card ไม่ใหญ่เกินความจำเป็น
- Download / Remove / Replace ชัดเจน

### 8. Feedback State

ตรวจสอบ:

- Loading
- Skeleton
- Empty State
- Error State
- Success Toast
- Error Toast
- Confirmation Dialog
- Destructive Confirmation
- Optimistic Update

### 9. Dialog / Sheet / Drawer

ตรวจสอบ:

- ใช้ Component ถูกประเภท
- ขนาดเหมาะสม
- Scroll
- Header
- Footer
- Close
- Escape
- Focus Trap
- Mobile Behavior

### 10. Workflow UX

ตรวจสอบว่า:

- ผู้ใช้เข้าใจสถานะปัจจุบัน
- ผู้ใช้รู้ว่าต้องทำอะไรต่อ
- ปุ่มสำคัญเด่นชัด
- ปุ่มที่เสี่ยงไม่อยู่ใกล้ปุ่มบันทึกเกินไป
- Approval Action มี Reason
- Publish แยกจาก Approve
- Pin / Unpin อยู่ในหน้ารายการหรือเมนูจัดการอย่างเหมาะสม

### 11. Accessibility

ตรวจสอบ:

- Semantic HTML
- Label Association
- Keyboard Navigation
- Focus State
- Screen Reader Text
- aria-label
- Contrast
- Icon-only Button
- Table Header
- Dialog Accessibility

### 12. Responsive

ตรวจสอบอย่างน้อย:

- Mobile
- Tablet
- Laptop
- Desktop

ตรวจสอบ:

- Table Overflow
- Form Stack
- Button Wrap
- Dialog Height
- Sidebar
- Filter Toolbar

## วิธีดำเนินการ

1. Inventory หน้าจอทั้งหมด
2. จัดกลุ่ม Page Pattern
3. ตรวจ Component Pattern
4. ตรวจ Table Pattern
5. ตรวจ Form Pattern
6. ตรวจ Status Pattern
7. ตรวจ Responsive
8. ตรวจ Accessibility
9. ระบุ Inconsistency
10. เสนอ Design System Standard

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-4-ui-ux-design-system-audit.md
```

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

1. Executive Summary
2. Screen Inventory
3. Layout Assessment
4. Typography Assessment
5. Color & Status Assessment
6. Button Standard Assessment
7. Table Standard Assessment
8. Form Standard Assessment
9. File Attachment UX Assessment
10. Feedback State Assessment
11. Dialog / Sheet / Drawer Assessment
12. Workflow UX Assessment
13. Responsive Assessment
14. Accessibility Assessment
15. Design System Inconsistencies
16. Findings by Severity
17. Recommended UI Standard
18. Recommended Remediation Order
19. Files Reviewed
20. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามแก้ UI
- ห้ามเปลี่ยน Component
- ห้ามปรับ CSS
- ห้ามสร้าง Design Token ใหม่
- ให้รายงานพร้อมตัวอย่างแนวทางเท่านั้น
```

---

# 7. Phase 5 — Code Quality & Performance Audit

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior TypeScript Engineer, React / Next.js Architect และ Performance Engineer

หน้าที่ของคุณคือทำ Code Quality & Performance Audit ระบบ TMS ทั้งระบบ

## วัตถุประสงค์

ตรวจสอบ:

- คุณภาพโค้ด
- Type Safety
- Maintainability
- Reusability
- Error Handling
- Performance
- Database Query Efficiency
- Rendering Efficiency
- Bundle และ Client Boundary

## ขอบเขตการตรวจสอบ

### 1. TypeScript

ตรวจสอบ:

- any
- unknown
- type assertion
- nullable
- optional field
- duplicated type
- API response type
- database type
- form type
- enum consistency
- satisfies
- discriminated union

### 2. React

ตรวจสอบ:

- Component Responsibility
- God Component
- Prop Drilling
- Derived State
- useEffect
- Dependency Array
- Memoization
- Callback
- Controlled / Uncontrolled
- Key
- Conditional Rendering
- Client Component ที่ไม่จำเป็น

### 3. Next.js

ตรวจสอบ:

- Server Component
- Client Component
- Route Handler
- Server Action
- Caching
- Revalidation
- Dynamic Rendering
- Streaming
- Suspense
- Error Boundary
- Loading UI
- Metadata
- Image Optimization

### 4. Validation

ตรวจสอบ:

- Zod Schema
- Client Validation
- Server Validation
- Schema Reuse
- Error Message
- File Validation
- Enum Validation
- Date Validation
- URL Validation
- Status Validation

### 5. Error Handling

ตรวจสอบ:

- API Error Format
- Domain Error
- Validation Error
- Database Error
- Unauthorized
- Forbidden
- Not Found
- Conflict
- Logging
- User-friendly Message

### 6. Duplicate Code

ตรวจสอบ:

- Table Column
- Filter
- Pagination
- Status Badge
- Permission Check
- Error Handler
- Form Mapping
- Date Format
- API Response
- Repository Query

### 7. Naming & Conventions

ตรวจสอบ:

- File Name
- Component Name
- Hook Name
- Function Name
- Variable Name
- Constant
- Permission Key
- Route Name
- API Name
- Status Name

### 8. Database Query Performance

ตรวจสอบ:

- N+1 Query
- Missing Select
- Over-fetch
- Missing Index
- Count Query
- Pagination
- Search
- Filter
- Sort
- Transaction
- Include Relation
- Large Export

### 9. Frontend Performance

ตรวจสอบ:

- Re-render
- Large List
- Table Rendering
- Client Bundle
- Dynamic Import
- Heavy Library
- Image / Video
- File Preview
- Search Debounce
- Filter Update
- Pagination

### 10. API Performance

ตรวจสอบ:

- Payload Size
- Response Time Risk
- Repeated Query
- Sequential Request
- File Download
- Import
- Export
- Batch Operation
- Rate Limit

### 11. Dead Code

ตรวจสอบ:

- Unused File
- Unused Export
- Unused Hook
- Unused Component
- Legacy Role Logic
- Deprecated API
- Commented Code
- Old Migration Logic

### 12. Testability

ตรวจสอบ:

- Function Coupling
- Mockability
- Pure Function
- Service Isolation
- Repository Isolation
- Test Fixture
- Deterministic Behavior

## วิธีดำเนินการ

1. ตรวจสอบ Build Configuration
2. ตรวจสอบ TypeScript Configuration
3. ตรวจสอบ Lint Configuration
4. ตรวจ Source Code ตาม Module
5. ตรวจ Query ที่มีความเสี่ยง
6. ตรวจ Client Boundary
7. ตรวจ Duplicate Logic
8. ตรวจ Dead Code
9. ตรวจ Error Handling
10. สรุป Performance Risk

หากคำสั่งที่ปลอดภัยและเป็น Read-only มีอยู่ สามารถใช้เพื่อตรวจสอบได้ เช่น:

```text
typecheck
lint
build
unit test
```

แต่ห้ามแก้ไขโค้ดอัตโนมัติ และห้ามใช้คำสั่งที่เปลี่ยนไฟล์ เช่น lint --fix หรือ formatter write

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-5-code-quality-performance-audit.md
```

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

1. Executive Summary
2. TypeScript Assessment
3. React Assessment
4. Next.js Assessment
5. Validation Assessment
6. Error Handling Assessment
7. Duplicate Code Findings
8. Naming & Convention Findings
9. Database Performance Findings
10. Frontend Performance Findings
11. API Performance Findings
12. Dead Code Findings
13. Testability Assessment
14. Findings by Severity
15. Quick Wins
16. Structural Improvements
17. Recommended Remediation Order
18. Commands Executed and Results
19. Files Reviewed
20. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามแก้โค้ด
- ห้ามรัน auto-fix
- ห้ามเปลี่ยน package
- ห้าม Optimize จริงในเฟสนี้
- ให้รายงานผลเท่านั้น
```

---

# 8. Phase 6 — Security Audit

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior Application Security Engineer และ Secure Code Reviewer

หน้าที่ของคุณคือทำ Security Audit ระบบ TMS ทั้งระบบ โดยตรวจสอบ Source Code, API, Authentication, Authorization, File Upload, Data Protection และ Security Configuration

## วัตถุประสงค์

ค้นหาความเสี่ยงที่อาจนำไปสู่:

- Unauthorized Access
- Privilege Escalation
- Data Leakage
- Injection
- File Upload Abuse
- Sensitive Data Exposure
- Session Abuse
- Broken Access Control
- Audit Gap

## ขอบเขตการตรวจสอบ

### 1. Authentication

ตรวจสอบ:

- Login
- Session
- Cookie
- Token
- Expiration
- Logout
- Session Revocation
- LDAP / AD
- Password Handling หากมี
- Brute Force Protection
- Error Message Leakage

### 2. Authorization

ตรวจสอบ:

- Route Guard
- API Guard
- Server Action Guard
- Ownership
- Data Scope
- IDOR
- Direct URL
- Permission Escalation
- Template Assignment

### 3. Input Validation

ตรวจสอบ:

- Query Param
- Route Param
- JSON Body
- Form Data
- Search Input
- Sort Field
- Filter Field
- URL
- Date
- Enum
- File Metadata

### 4. Injection

ตรวจสอบความเสี่ยง:

- SQL Injection
- ORM Raw Query
- Command Injection
- Path Traversal
- Template Injection
- LDAP Injection
- CSV Injection

### 5. XSS

ตรวจสอบ:

- Rich Text
- Announcement Content
- Policy Content
- Online Lesson Description
- dangerouslySetInnerHTML
- Markdown Renderer
- URL
- User-generated Text

### 6. CSRF & Request Protection

ตรวจสอบ:

- Cookie-based Authentication
- CSRF Protection
- SameSite
- Origin Check
- State-changing GET
- Form Action Protection

### 7. File Upload

ตรวจสอบ:

- File Type
- MIME Type
- Extension
- File Size
- File Name
- Path
- Virus Scan หากมี
- Public URL
- Authorization ตอน Download
- Delete File
- Replace File
- Video / Thumbnail / Certificate / Evidence

### 8. Sensitive Data

ตรวจสอบ:

- Employee Data
- Email
- Employee Code
- Organization Data
- Permission Data
- Environment Variable
- Secret
- Log
- Error Response
- Debug Output

### 9. Security Headers

ตรวจสอบ:

- Content-Security-Policy
- X-Frame-Options
- X-Content-Type-Options
- Referrer-Policy
- Permissions-Policy
- HSTS
- Cache-Control

### 10. Rate Limiting

ตรวจสอบ Endpoint เสี่ยง:

- Login
- Search
- Export
- Import
- File Upload
- Download
- Notification
- Approval Action

### 11. Audit Log

ตรวจสอบว่า Action สำคัญถูกบันทึกหรือไม่:

- Permission Change
- Approval
- Rejection
- Publish
- Delete
- Import
- Export
- Login Failure
- Sensitive Data Access หากจำเป็น

### 12. Dependency & Configuration

ตรวจสอบ:

- Dependency ที่ล้าสมัยจากข้อมูลในโปรเจกต์
- Security Configuration
- Debug Mode
- Source Map
- Environment Separation
- Secret in Repository
- Default Credential

ห้ามอัปเดต Dependency ในเฟสนี้

### 13. Business Logic Security

ตรวจสอบ:

- Approval ข้ามลำดับ
- Publish โดยไม่ Approve
- Employee แก้ข้อมูลหลัง Submit
- Approver อนุมัติรายการของตนเอง หากไม่ควรอนุญาต
- Re-submit Status ที่ผิด
- Import ข้าม Validation
- Export ข้าม Scope
- Pin / Publish Action ข้าม Permission

## วิธีดำเนินการ

1. ทำ Threat Surface Inventory
2. ตรวจ Authentication
3. ตรวจ Authorization
4. ตรวจ Input และ Output
5. ตรวจ File Handling
6. ตรวจ Sensitive Data
7. ตรวจ Security Header และ Config
8. ตรวจ Business Logic Abuse
9. สรุป Finding ตาม Severity

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-6-security-audit.md
```

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

1. Executive Summary
2. Threat Surface Overview
3. Authentication Assessment
4. Authorization Assessment
5. Input Validation Assessment
6. Injection Assessment
7. XSS Assessment
8. CSRF Assessment
9. File Upload & Download Assessment
10. Sensitive Data Assessment
11. Security Header Assessment
12. Rate Limit Assessment
13. Audit Log Assessment
14. Dependency & Configuration Assessment
15. Business Logic Security Assessment
16. Findings by Severity
17. Exploit Scenario for Critical / High Findings
18. Production Blockers
19. Recommended Remediation Order
20. Files Reviewed
21. Areas Not Verified

## ข้อกำหนดสำคัญ

- ห้ามทดสอบโจมตีระบบ Production
- ห้ามลบหรือเปลี่ยนข้อมูล
- ห้ามอัปโหลดไฟล์อันตรายจริง
- ห้ามเปลี่ยน Security Configuration
- ให้ทำ Static Review และ Safe Verification เท่านั้น
```

---

# 9. Phase 7 — Production Readiness Review

## Prompt สำหรับใช้งาน

```md
คุณคือ Senior DevOps Engineer, SRE, Release Manager และ Production Readiness Reviewer

หน้าที่ของคุณคือทำ Production Readiness Review ระบบ TMS เพื่อประเมินว่าระบบพร้อม Deploy และใช้งานจริงภายในองค์กรหรือไม่

## วัตถุประสงค์

ตรวจสอบความพร้อมด้าน:

- Build
- Environment
- Deployment
- Database
- Monitoring
- Logging
- Backup
- Recovery
- Test
- Documentation
- Operational Support

## ขอบเขตการตรวจสอบ

### 1. Build Readiness

ตรวจสอบ:

- install
- typecheck
- lint
- build
- test
- production start
- environment validation
- build warning
- deprecated API

ใช้เฉพาะคำสั่ง Read-only หรือคำสั่งที่ไม่เปลี่ยน Source Code

### 2. Environment Configuration

ตรวจสอบ:

- Development
- Test
- UAT
- Production
- Environment Variable
- Secret Management
- Required Variable
- Default Value
- Missing Variable Handling
- Environment Documentation

ห้ามเปิดเผยค่า Secret ในรายงาน

### 3. Database Readiness

ตรวจสอบ:

- Migration Status
- Schema Drift
- Seed
- Backup
- Restore
- Index
- Constraint
- Transaction
- Data Retention
- Soft Delete
- Production Migration Plan
- Rollback Plan

ห้ามรัน Migration จริง

### 4. Deployment

ตรวจสอบ:

- Dockerfile
- Docker Compose
- Runtime
- Node Version
- Package Manager
- Build Artifact
- Health Check
- Reverse Proxy
- HTTPS
- Static File
- File Storage
- Persistent Volume

### 5. CI/CD

ตรวจสอบ:

- Pull Request Check
- Lint
- Typecheck
- Test
- Build
- Migration Check
- Security Scan
- Deployment Approval
- Rollback
- Environment Protection

### 6. Logging

ตรวจสอบ:

- Application Log
- Error Log
- Audit Log
- Request ID
- User ID
- Sensitive Data Redaction
- Log Level
- Log Retention
- Structured Logging

### 7. Monitoring & Alerting

ตรวจสอบ:

- Health Check
- Uptime
- Error Rate
- Response Time
- Database Connection
- Disk
- CPU
- Memory
- Queue / Job หากมี
- File Storage
- Alert Channel

### 8. Backup & Recovery

ตรวจสอบ:

- Database Backup
- File Backup
- Backup Frequency
- Retention
- Encryption
- Restore Test
- RPO
- RTO
- Disaster Recovery

### 9. Operational Workflow

ตรวจสอบ:

- User Provisioning
- Permission Change
- Employee Sync
- Failed Import
- Failed Notification
- File Storage Full
- Approval Issue
- Data Correction
- Incident Handling

### 10. Testing Readiness

ตรวจสอบ:

- Unit Test
- Integration Test
- API Test
- Permission Test
- Workflow Test
- Regression Test
- UAT
- Test Data
- Production Smoke Test

### 11. Documentation

ตรวจสอบว่ามีเอกสาร:

- README
- Setup
- Environment
- Architecture
- Permission Matrix
- Database
- Deployment
- Backup
- Restore
- Troubleshooting
- User Manual
- Admin Manual
- Release Note
- Rollback

### 12. Production Checklist

สร้าง Checklist แบบ:

- Ready
- Partially Ready
- Not Ready
- Not Verified

### 13. Go-live Risk

ระบุ:

- Production Blocker
- Must Fix Before Go-live
- Can Fix After Go-live
- Operational Risk
- Data Risk
- Security Risk

## วิธีดำเนินการ

1. ตรวจ Configuration
2. ตรวจ Build และ Test ที่มีอยู่
3. ตรวจ Deployment Artifact
4. ตรวจ Database Readiness
5. ตรวจ Monitoring / Logging
6. ตรวจ Backup / Restore
7. ตรวจ Documentation
8. สร้าง Production Readiness Checklist
9. สรุป Go / Conditional Go / No-Go

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/phase-7-production-readiness-review.md
```

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

1. Executive Summary
2. Build Readiness
3. Environment Readiness
4. Database Readiness
5. Deployment Readiness
6. CI/CD Readiness
7. Logging Readiness
8. Monitoring & Alerting Readiness
9. Backup & Recovery Readiness
10. Operational Readiness
11. Testing Readiness
12. Documentation Readiness
13. Production Checklist
14. Findings by Severity
15. Production Blockers
16. Go-live Recommendation
17. Recommended Remediation Order
18. Commands Executed and Results
19. Files Reviewed
20. Areas Not Verified

## Go-live Recommendation Standard

ใช้หนึ่งในผลลัพธ์ต่อไปนี้:

### GO

ระบบพร้อมใช้งานจริง และไม่พบ Critical หรือ High ที่เป็น Production Blocker

### CONDITIONAL GO

ระบบสามารถใช้งานจริงได้เมื่อแก้ไขเงื่อนไขที่ระบุครบก่อน Deploy

### NO-GO

ระบบยังไม่พร้อมใช้งานจริง เนื่องจากมี Critical / High Risk หรือขาด Operational Control ที่สำคัญ

## ข้อกำหนดสำคัญ

- ห้าม Deploy
- ห้ามแก้ Environment
- ห้ามรัน Migration
- ห้ามเปลี่ยน Infrastructure
- ห้ามเปิดเผย Secret
- ให้ประเมินและจัดทำรายงานเท่านั้น
```

---

# 10. Final Phase — Full System Audit Summary

หลังจากทำครบทั้ง 7 เฟส ให้ใช้ Prompt นี้เพื่อรวมผลทั้งหมด

```md
คุณคือ Principal Software Architect, QA Director, Security Lead และ Release Manager

หน้าที่ของคุณคืออ่านรายงาน Audit ทั้ง 7 เฟสต่อไปนี้:

```text
docs/reviews/phase-1-architecture-audit.md
docs/reviews/phase-2-functional-review.md
docs/reviews/phase-3-permission-authorization-audit.md
docs/reviews/phase-4-ui-ux-design-system-audit.md
docs/reviews/phase-5-code-quality-performance-audit.md
docs/reviews/phase-6-security-audit.md
docs/reviews/phase-7-production-readiness-review.md
```

จากนั้นจัดทำรายงานสรุประดับผู้บริหารและแผนแก้ไขรวมทั้งระบบ

## สิ่งที่ต้องดำเนินการ

### 1. รวม Finding

- รวม Finding จากทุกเฟส
- ตัด Finding ที่ซ้ำกัน
- เชื่อมโยง Finding ที่มีสาเหตุเดียวกัน
- คงหลักฐานอ้างอิงเดิม

### 2. จัดกลุ่ม

จัดกลุ่มเป็น:

- Architecture
- Functional
- Permission
- UI/UX
- Code Quality
- Performance
- Security
- Database
- Testing
- Production
- Documentation

### 3. จัดระดับ

แยกเป็น:

- Critical
- High
- Medium
- Low

### 4. ระบุ Production Blocker

ทุก Production Blocker ต้องระบุ:

- ปัญหา
- ผลกระทบ
- Module
- เจ้าของงานที่แนะนำ
- Dependency
- Acceptance Criteria

### 5. สร้าง Remediation Roadmap

แบ่งเป็น:

#### Wave 0 — Emergency Fix

สำหรับ Critical และ Security Blocker

#### Wave 1 — Pre-Production Fix

สำหรับ High และ Workflow หลัก

#### Wave 2 — Stabilization

สำหรับ Medium ที่กระทบ UX, Maintainability และ Performance

#### Wave 3 — Continuous Improvement

สำหรับ Low และ Technical Debt

### 6. กำหนดลำดับการแก้

คำนึงถึง:

- Dependency
- Risk
- Business Impact
- Regression Risk
- Effort
- Production Requirement

### 7. สร้าง Traceability Matrix

| Finding ID | Phase | Severity | Module | Production Blocker | Recommended Wave | Related Finding |
|---|---|---|---|---|---|---|

### 8. สร้าง Coding Phase Backlog

แต่ละ Backlog Item ต้องมี:

- ID
- Title
- Problem
- Scope
- Out of Scope
- Files / Modules
- Acceptance Criteria
- Test Required
- Dependency
- Severity
- Priority

## ผลลัพธ์ที่ต้องสร้าง

สร้างไฟล์:

```text
docs/reviews/full-system-audit-summary.md
```

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

1. Executive Summary
2. Overall System Health
3. Findings Summary by Severity
4. Findings Summary by Module
5. Production Blockers
6. Cross-Phase Root Causes
7. Risk Matrix
8. Traceability Matrix
9. Remediation Roadmap
10. Coding Phase Backlog
11. Testing Strategy After Fix
12. Recommended Release Gate
13. Final Go-live Recommendation
14. Appendix: Source Reports

## ข้อกำหนดสำคัญ

- ห้ามแก้ไขโค้ด
- ห้ามสร้าง Implementation
- ห้ามลด Severity โดยไม่มีเหตุผล
- ห้ามตัด Finding ที่ยังมีผลกระทบ
- หากข้อมูลจากแต่ละเฟสขัดแย้งกัน ให้ระบุ Conflict ชัดเจน
```

---

# 11. มาตรฐาน Release Gate หลังการแก้ไข

หลังจากนำผล Audit ไปแก้ไขแล้ว ระบบควรผ่าน Release Gate อย่างน้อยดังนี้

## Gate 1 — Build Quality

- Typecheck ผ่าน
- Lint ผ่าน
- Build ผ่าน
- ไม่มี Critical Runtime Error

## Gate 2 — Functional Quality

- Workflow หลักผ่าน
- Status Transition ถูกต้อง
- Validation สำคัญครบ
- Regression Test ผ่าน

## Gate 3 — Permission Quality

- Route Guard ครบ
- API Guard ครบ
- Data Scope ถูกต้อง
- Direct URL Test ผ่าน
- Permission Matrix ตรงกับระบบจริง

## Gate 4 — Security Quality

- ไม่มี Critical Security Finding
- High Security Finding ได้รับการแก้ไขหรือมี Risk Acceptance อย่างเป็นทางการ
- File Upload / Download ปลอดภัย
- Sensitive Data ไม่รั่วไหล

## Gate 5 — Production Quality

- Environment ครบ
- Database Migration Plan พร้อม
- Backup / Restore พร้อม
- Monitoring พร้อม
- Rollback Plan พร้อม
- Production Smoke Test พร้อม

---

# 12. แนวทางการใช้งานเอกสารนี้

แนะนำให้ทำตามลำดับ:

```text
Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5 → Phase 6 → Phase 7 → Full Summary
```

ไม่ควรเริ่มแก้ไขโค้ดระหว่างที่ยังตรวจไม่ครบ เพราะอาจทำให้:

- ผล Audit แต่ละเฟสอ้างอิงคนละสถานะของโค้ด
- Finding หายหรือเปลี่ยนตำแหน่ง
- เกิด Regression ระหว่างการตรวจ
- เปรียบเทียบผลยาก

หลังจากได้ `full-system-audit-summary.md` แล้ว จึงเริ่ม Coding Phase โดยแบ่งตาม Remediation Wave และสร้าง Prompt สำหรับการแก้ไขทีละกลุ่มปัญหา

---

# 13. Definition of Done สำหรับ Audit ทั้งระบบ

ถือว่าการ Audit เสร็จสมบูรณ์เมื่อ:

- มีรายงานครบทั้ง 7 เฟส
- มีรายการไฟล์ที่ตรวจสอบ
- มี Areas Not Verified
- ทุก Finding มี Severity
- Critical / High มีหลักฐานและสถานการณ์ประกอบ
- มี Permission Matrix
- มี Feature Inventory
- มี Production Checklist
- มี Production Blocker List
- มี Full System Audit Summary
- มี Remediation Roadmap
- มี Coding Phase Backlog
- ยังไม่มีการแก้ไข Source Code ระหว่าง Audit