690514:2019 204-rfa-approval-refactor #01
This commit is contained in:
@@ -0,0 +1,34 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/api-design.md
|
||||
# API Design Prompt (DMS Standard)
|
||||
|
||||
## ⭐ Role: Backend Architect
|
||||
|
||||
## 🎯 Objective
|
||||
ออกแบบ REST API ที่ปลอดภัย, มีประสิทธิภาพ และรองรับ Idempotency สำหรับระบบ DMS
|
||||
|
||||
## 📝 Instructions
|
||||
1. **Naming**: ใช้ kebab-case สำหรับ URL และ camelCase สำหรับ JSON field
|
||||
2. **Security**: ทุก Endpoint ต้องระบุ Decorator `@UseGuards(CaslGuard)` และ `@CheckPolicies(...)`
|
||||
3. **Idempotency**: สำหรับ POST/PATCH ต้องตรวจสอบ `Idempotency-Key` ใน Header
|
||||
4. **Validation**: ใช้ `Zod` สำหรับ Frontend และ `class-validator` ใน Backend DTOs
|
||||
5. **Standard Response**:
|
||||
- Success: `200 OK` หรือ `201 Created` พร้อมข้อมูล
|
||||
- Error: ปฏิบัติตาม ADR-007 (Error Handling Strategy)
|
||||
|
||||
## 📤 Output Format
|
||||
```typescript
|
||||
// Example Controller / DTO Definition
|
||||
@Controller('v1/documents')
|
||||
export class DocumentController {
|
||||
@Post()
|
||||
@UseGuards(CaslGuard)
|
||||
@CheckPolicies((ability) => ability.can(Action.Create, Document))
|
||||
async create(@Body() createDto: CreateDocumentDto, @Headers('idempotency-key') key: string) {
|
||||
// ... logic
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial API design standard
|
||||
@@ -0,0 +1,30 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/bug-fix.md
|
||||
# Bug Fix Prompt (DMS Module)
|
||||
|
||||
## ⭐ Role: Debugging Specialist (DMS Expert)
|
||||
|
||||
## 🎯 Context
|
||||
ระบบ DMS มีความซับซ้อนเรื่องสถานะ (State) และสิทธิ์ (Permissions) การแก้ไข Bug ต้องระวังไม่ให้กระทบต่อ Workflow Logic
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[DEBUG DMS]
|
||||
Module: <e.g. RFA, Correspondence>
|
||||
Issue: <อธิบายปัญหา>
|
||||
Affected PublicId: <UUIDv7 ที่เกิดปัญหา>
|
||||
Error Message: <Paste log หรือ error จาก browser>
|
||||
Reference Docs:
|
||||
- specs/01-Requirements/01-06-edge-cases-and-rules.md
|
||||
- specs/06-Decision-Records/ADR-007-error-handling-strategy.md
|
||||
Request: วิเคราะห์หาสาเหตุ โดยตรวจสอบทั้ง Database State และ CASL Ability
|
||||
```
|
||||
|
||||
## 🔍 Investigation Checklist
|
||||
1. **Database Check**: ตรวจสอบสถานะจริงใน DB เทียบกับสถานะที่ควรจะเป็น
|
||||
2. **Permission Check**: ผู้ใช้ที่เกิดปัญหามีสิทธิ์ทำ Action นั้นหรือไม่?
|
||||
3. **Concurrency**: เกิด Race Condition หรือไม่? (เช็ค Redis locks)
|
||||
4. **Validation**: ติด Zod หรือ class-validator หรือไม่?
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial bug fix prompt for DMS
|
||||
@@ -0,0 +1,31 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/db-schema.md
|
||||
# Database Schema Design Prompt
|
||||
|
||||
## ⭐ Role: Senior Database Administrator (MariaDB Specialist)
|
||||
|
||||
## 🎯 Context
|
||||
ออกแบบหรือแก้ไขตารางฐานข้อมูลสำหรับระบบ NAP-DMS โดยยึดตาม ADR-009 และ ADR-019
|
||||
|
||||
## 📝 Key Rules
|
||||
1. **No Migrations**: ห้ามสร้างไฟล์ Migration ให้เขียน SQL Script โดยตรง
|
||||
2. **Hybrid ID**:
|
||||
- `id INT AUTO_INCREMENT PRIMARY KEY` (Internal)
|
||||
- `publicId BINARY(16) UNIQUE` (External - UUIDv7)
|
||||
3. **Audit Fields**:
|
||||
- `createdBy INT` (FK to user internal id)
|
||||
- `updatedBy INT`
|
||||
- `createdAt TIMESTAMP`
|
||||
- `updatedAt TIMESTAMP`
|
||||
- `version INT DEFAULT 1` (For optimistic locking)
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[DB SCHEMA DESIGN]
|
||||
Feature: <ชื่อฟีเจอร์>
|
||||
Requirements: <รายละเอียดข้อมูลที่ต้องเก็บ>
|
||||
Request: ออกแบบตารางพร้อมความสัมพันธ์ (FK) และดัชนี (Index) ที่เหมาะสม โดยใช้มาตรฐาน Hybrid UUID
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial DB schema prompt standard
|
||||
@@ -0,0 +1,32 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/feature-design.md
|
||||
# Feature Design Prompt (DMS Edition)
|
||||
|
||||
## ⭐ Role: Senior Full Stack Developer / Solution Architect
|
||||
|
||||
## 🎯 Context
|
||||
คุณกำลังออกแบบฟีเจอร์ใหม่สำหรับระบบ NAP-DMS โดยอ้างอิงจาก Business Rules ใน `specs/01-requirements/01-02-business-rules/`
|
||||
|
||||
## 📝 Input Template
|
||||
```
|
||||
[NEW FEATURE]
|
||||
Module: <module-name>
|
||||
Requirement: <อธิบาย User Story หรืออ้างอิงไฟล์ spec>
|
||||
Constraints: <ข้อจำกัดเพิ่มเติม เช่น สิทธิ์การเข้าถึง, ความเกี่ยวข้องกับ Module อื่น>
|
||||
```
|
||||
|
||||
## 🚀 Instructions
|
||||
1. ตรวจสอบ **Glossary** (`specs/00-overview/00-02-glossary.md`) เพื่อใช้คำศัพท์ให้ถูกต้อง
|
||||
2. วิเคราะห์ **Edge Cases** (`specs/01-Requirements/01-06-edge-cases-and-rules.md`)
|
||||
3. ออกแบบ **Data Model & Schema** ตามมาตรฐาน ADR-019 (Hybrid UUID)
|
||||
4. กำหนด **RBAC Matrix** สำหรับฟีเจอร์นี้
|
||||
5. ร่างลำดับการทำงาน (Workflow) และการแจ้งเตือน (Notifications)
|
||||
|
||||
## 📤 Output Format
|
||||
1. **Summary**: สรุปแนวทางการแก้ปัญหา
|
||||
2. **Database Schema**: คำสั่ง SQL สำหรับสร้าง/แก้ไขตาราง
|
||||
3. **API Contracts**: นิยาม DTO และ Endpoint
|
||||
4. **Implementation Plan**: ขั้นตอนการพัฒนาทีละ Step
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial template
|
||||
@@ -0,0 +1,27 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/rbac-enforcement.md
|
||||
# RBAC Enforcement Prompt (DMS Security)
|
||||
|
||||
## ⭐ Role: Security Engineer / IAM Specialist
|
||||
|
||||
## 🎯 Context
|
||||
การบังคับใช้สิทธิ์การเข้าถึงข้อมูล (Access Control) ตามบทบาทหน้าที่ (Role-Based Access Control) โดยใช้ CASL ใน NestJS และ RBAC Matrix
|
||||
|
||||
## 🛡️ Enforcement Rules
|
||||
1. **CASL Guard**: ทุก API Controller ต้องประดับด้วย `@UseGuards(CaslGuard)`
|
||||
2. **Policy Definition**: ตรวจสอบสิทธิ์ในระดับ Action (Create, Read, Update, Delete, Manage) และ Subject (Entity)
|
||||
3. **Field Level Security**: บางฟิลด์อาจต้องซ่อนตามระดับสิทธิ์ (e.g. ข้อมูลราคา)
|
||||
4. **Project Isolation**: ตรวจสอบว่าผู้ใช้มีสิทธิ์เข้าถึงโครงการนั้นๆ จริงหรือไม่ (Project ID Check)
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[RBAC CHECK]
|
||||
Endpoint: <e.g. PATCH /v1/rfa/:publicId>
|
||||
User Role: <e.g. Consultant>
|
||||
Desired Action: <e.g. Approve RFA>
|
||||
Reference: specs/01-requirements/01-02-business-rules/01-02-01-rbac-matrix.md
|
||||
Request: วิเคราะห์และเขียนโค้ด CASL Policy สำหรับกรณีนี้
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial RBAC enforcement prompt
|
||||
@@ -0,0 +1,25 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/refactor.md
|
||||
# Code Refactoring Prompt (DMS Standard)
|
||||
|
||||
## ⭐ Role: Senior Software Engineer (Refactoring Specialist)
|
||||
|
||||
## 🎯 Objective
|
||||
ปรับปรุงโครงสร้างโค้ดให้สะอาด (Clean Code), บำรุงรักษาง่าย (Maintainability) และสอดคล้องกับมาตรฐาน LCBP3
|
||||
|
||||
## 🏗️ Refactoring Principles
|
||||
1. **DRY (Don't Repeat Yourself)**: ย้าย Logic ที่ซ้ำกันไปไว้ใน Common Service หรือ Utility
|
||||
2. **SOLID**: แยกความรับผิดชอบของ Class และ Method ให้ชัดเจน
|
||||
3. **Type Safety**: กำจัด `any` และ `unknown` โดยใช้ Interface/Type ที่ถูกต้อง
|
||||
4. **Performance**: ลดการ Query ซ้ำซ้อน และใช้ Transaction เมื่อจำเป็น
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[REFACTOR]
|
||||
Target File: <path/to/file>
|
||||
Goal: <e.g. แยก logic ออกจาก controller, ปรับปรุง type safety>
|
||||
Request: ช่วยวิเคราะห์โค้ดเดิมและเสนอเวอร์ชัน Refactor ที่ยังคงรักษา functionality เดิมไว้ 100% พร้อมอธิบายเหตุผลของการเปลี่ยนแปลง
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial refactor prompt
|
||||
@@ -0,0 +1,27 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/report-generation.md
|
||||
# Report Generation Prompt (DMS)
|
||||
|
||||
## ⭐ Role: Data Analyst / Backend Developer
|
||||
|
||||
## 🎯 Context
|
||||
การสร้างรายงาน (Reports) จากข้อมูลในระบบ DMS เช่น สรุปสถานะ RFA ประจำสัปดาห์ หรือรายงานความคืบหน้าของ Drawing
|
||||
|
||||
## 📊 Reporting Requirements
|
||||
1. **Data Source**: ดึงข้อมูลจากตารางหลัก (Correspondence, RFA, etc.) และตาราง History
|
||||
2. **Filters**: ต้องรองรับการกรองตาม Project, Discipline, Date Range และ Status
|
||||
3. **Export Formats**: รองรับ PDF (สำหรับเซ็นชื่อ) และ Excel (สำหรับวิเคราะห์ข้อมูล)
|
||||
4. **Performance**: ใช้ Aggregate Queries ที่มีประสิทธิภาพ และทำ Caching หากจำเป็น
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[REPORT DESIGN]
|
||||
Report Name: <ชื่อรายงาน>
|
||||
Columns: <รายการฟิลด์ที่ต้องการแสดง>
|
||||
Group By: <e.g. Discipline, Sub-contractor>
|
||||
Export Format: <Excel/PDF>
|
||||
Request: ออกแบบ Query และโครงสร้างข้อมูลสำหรับสร้างรายงานนี้
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial report generation prompt
|
||||
@@ -0,0 +1,26 @@
|
||||
// File: docs/ai-knowledge-base/prompts/dms/ui-flow.md
|
||||
# UI/UX Flow Design Prompt (DMS)
|
||||
|
||||
## ⭐ Role: UX/UI Designer (Enterprise Application)
|
||||
|
||||
## 🎯 Context
|
||||
ออกแบบหน้าจอและการไหลเวียนของงาน (User Journey) ในระบบ DMS ที่มีข้อมูลจำนวนมากและ Workflow ที่ซับซ้อน
|
||||
|
||||
## 🎨 Design Guidelines
|
||||
1. **Consistency**: ใช้ Component จาก `shadcn/ui` และ Palette สีตามมาตรฐานโครงการ
|
||||
2. **Efficiency**: ลดจำนวนการคลิกเพื่อเข้าถึงข้อมูลสำคัญ (e.g. Document Preview)
|
||||
3. **Feedback**: ต้องมี Loading states, Success/Error toasts และ Skeleton screens
|
||||
4. **Responsive**: รองรับทั้ง Desktop (หลัก) และ Tablet สำหรับงานหน้าไซต์
|
||||
|
||||
## 🚀 Prompt Template
|
||||
```
|
||||
[UI FLOW DESIGN]
|
||||
Feature: <ชื่อฟีเจอร์>
|
||||
User Role: <e.g. Document Control, Sub-contractor>
|
||||
Objective: <สิ่งที่ผู้ใช้ต้องการทำ>
|
||||
Request: ออกแบบ User Flow ตั้งแต่เริ่มต้นจนจบ พร้อมระบุ UI Components ที่ต้องใช้ในแต่ละหน้า
|
||||
```
|
||||
|
||||
---
|
||||
// Change Log:
|
||||
// - 2026-05-14: Initial UI flow prompt
|
||||
Reference in New Issue
Block a user