Một số prompt và câu lệnh hay dùng trong AI

Một số prompt mẫu thường dùng để AI xử lý công việc 

Thay đổi biến ngôn ngữ

# NHIỆM VỤ

Chuyển toàn bộ **hardcoded UI text** trong file React/TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) sang đa ngôn ngữ bằng `t('code')`, đối chiếu với file ngôn ngữ được cung cấp.

Mục tiêu bắt buộc:

1. Không bỏ sót UI text.

2. Không tạo language trùng với text đã tồn tại.

3. Không thay đổi logic/code ngoài phạm vi i18n.

4. Text chưa tồn tại mới được đưa vào SQL.

---

# NGUYÊN TẮC ƯU TIÊN SỐ 1 — SO KHỚP THEO `vi_value`

File language hiện tại là **nguồn dữ liệu chuẩn duy nhất**.

Khi kiểm tra một UI text, PHẢI tìm theo **nội dung tiếng Việt trong `vi_value`**, KHÔNG tìm hoặc suy đoán theo `code`.

Ví dụ source có:

```tsx

<Button>Xin chào</Button>

```

Language đã có:

```js

{

    code: 'hello',

    vi_value: 'Xin chào'

}

```

BẮT BUỘC sử dụng:

```tsx

<Button>{t('hello')}</Button>

```

TUYỆT ĐỐI KHÔNG:

* tạo `xin_chao`

* tạo `greeting`

* tạo `welcome`

* sinh SQL mới cho `Xin chào`

nếu `vi_value = "Xin chào"` đã tồn tại.

---

# QUY TẮC CHỐNG TẠO TRÙNG

Trước khi kết luận một text là "chưa có", bắt buộc:

1. Search toàn bộ file language.

2. So sánh với tất cả `vi_value`.

3. Xác nhận không có `vi_value` tương ứng.

4. Chỉ sau đó mới đưa text vào `MISSING_LANGUAGE`.

Không được kết luận text chưa tồn tại chỉ vì:

* Không tìm thấy `code` mong muốn.

* Tên `code` khác dự đoán.

* `code` có tên không liên quan.

* Không thấy ngay ở khu vực đang đọc.

Ví dụ:

```js

{

    code: 'customer_remove_confirm',

    vi_value: 'Bạn có chắc chắn muốn xóa?'

}

```

Source:

```tsx

title="Bạn có chắc chắn muốn xóa?"

```

Dù tên `code` khó đoán, vẫn PHẢI dùng:

```tsx

title={t('customer_remove_confirm')}

```

Không được tạo thêm language mới.

---

# BƯỚC 1 — ĐỌC TOÀN BỘ LANGUAGE TRƯỚC

Trước khi sửa source:

* Đọc toàn bộ file language.

* Xác định cấu trúc dữ liệu.

* Thu thập mapping:

```text

vi_value → code

```

Ví dụ:

```text

Lưu → save

Hủy → cancel

Xin chào → hello

Tên khách hàng → customer_name

```

Mapping này phải được dùng trong TOÀN BỘ quá trình xử lý.

Không bắt đầu sửa source khi chưa đọc xong file language.

---

# BƯỚC 2 — QUÉT TOÀN BỘ SOURCE

Duyệt source từ đầu đến cuối.

Không chỉ tìm một số component hoặc từ khóa phổ biến.

Phải kiểm tra MỌI:

```text

JSXText

'string'

"string"

`template literal`

```

Với từng string, xác định:

```text

String này có thể hiển thị cho người dùng không?

```

Nếu KHÔNG → bỏ qua.

Nếu CÓ → bắt buộc kiểm tra mapping `vi_value → code`.

---

# BƯỚC 3 — XỬ LÝ UI TEXT

## Trường hợp A: `vi_value` đã tồn tại

Ví dụ:

```tsx

<Button>Lưu</Button>

```

Language:

```text

vi_value = "Lưu"

code = "save"

```

Thay thành:

```tsx

<Button>{t('save')}</Button>

```

Props:

```tsx

placeholder="Tên khách hàng"

```

→

```tsx

placeholder={t('customer_name')}

```

---

## Trường hợp B: `vi_value` chưa tồn tại

Nếu đã search toàn bộ language và chắc chắn không có:

```tsx

<Button>Xóa vĩnh viễn</Button>

```

thì:

1. GIỮ NGUYÊN source.

2. Không tự tạo language.

3. Thêm `Xóa vĩnh viễn` vào `MISSING_LANGUAGE`.

4. Cuối task mới sinh SQL.

---

# UI TEXT PHẢI KIỂM TRA

Bất kỳ string nào cuối cùng có thể hiển thị cho người dùng đều phải kiểm tra.

Bao gồm nhưng không giới hạn:

* JSX text

* Button

* Label

* placeholder

* title

* tooltip

* description

* helper/hint

* aria-label

* alt

* Modal

* Drawer

* Dialog

* Popconfirm

* Alert

* message

* notification

* toast

* validation message

* Form.Item

* rules

* Empty state

* emptyText

* Table column title

* render()

* renderCell

* renderItem

* renderContent

* Tabs

* Menu

* Dropdown

* Breadcrumb

* Card

* Collapse

* Checkbox

* Radio

* Select

* Switch

* Upload

* Badge

* Tag

* Timeline

* Steps

* Statistic

* pagination

* locale

* columns

* items

* options

* tabs

* object cấu hình UI

* array cấu hình UI

* `.map()`

* `useMemo`

* `useCallback`

* conditional render `&&`

* ternary `?:`

* props truyền vào custom component

Danh sách trên KHÔNG phải giới hạn.

Quy tắc cuối cùng:

> Bất kỳ string nào có khả năng được render ra giao diện đều phải kiểm tra với `vi_value`.

---

# KHÔNG ĐƯỢC THAY

Không thay string phục vụ kỹ thuật/logic:

* variable name

* function name

* object key

* API

* URL

* route

* className

* id

* enum

* status code

* field name

* query param

* storage key

* event name

* permission

* constant phục vụ logic

* comment

* dữ liệu không hiển thị

Nếu chưa chắc → trace nơi string được sử dụng trước khi quyết định.

---

# QUY TẮC SỬA CODE

Tuyệt đối không:

* Refactor.

* Sửa logic.

* Đổi format.

* Đổi indent.

* Đổi thứ tự code.

* Đổi nội dung UI text.

* Rename biến/function.

* Tạo helper không cần thiết.

* Tạo language trực tiếp.

* Sửa code ngoài phạm vi i18n.

Nếu file đã có `t` hoặc `useTranslation` → sử dụng lại.

Không tạo `t` hoặc hook trùng.

Chỉ thêm import/hook i18n nếu file thực sự chưa có và cần thiết.

---

# RÀ SOÁT BẮT BUỘC SAU KHI SỬA

Không được trả kết quả ngay sau lần sửa đầu tiên.

Phải thực hiện các vòng kiểm tra sau bằng công cụ search/grep của môi trường coding nếu có.

---

## PASS 1 — QUÉT SOURCE VÀ THAY THẾ

Đọc toàn bộ source từ đầu → cuối.

Phân loại từng UI string.

UI text có `vi_value` tương ứng → thay bằng `t('code')`.

UI text chưa có → giữ nguyên + đưa vào `MISSING_LANGUAGE`.

---

## PASS 2 — SEARCH TOÀN BỘ TEXT TIẾNG VIỆT CÒN LẠI

Sau khi sửa, search/grep lại toàn bộ file để tìm string còn chứa ký tự tiếng Việt.

Ví dụ cần tìm các ký tự:

```text

ă â đ ê ô ơ ư

á à ả ã ạ

ắ ằ ẳ ẵ ặ

ấ ầ ẩ ẫ ậ

é è ẻ ẽ ẹ

ế ề ể ễ ệ

í ì ỉ ĩ ị

ó ò ỏ õ ọ

ố ồ ổ ỗ ộ

ớ ờ ở ỡ ợ

ú ù ủ ũ ụ

ứ ừ ử ữ ự

ý ỳ ỷ ỹ ỵ

```

Bao gồm cả chữ hoa tương ứng.

Với TỪNG kết quả search:

```text

Có phải UI text?

    ↓

CÓ

    ↓

Search vi_value trong language

    ↓

Có → thay t('code')

Không → MISSING_LANGUAGE

```

Không được bỏ qua bất kỳ kết quả search nào mà chưa phân loại.

---

## PASS 3 — KIỂM TRA STRING KHÔNG CÓ DẤU TIẾNG VIỆT

Không được chỉ dựa vào ký tự tiếng Việt.

Phải kiểm tra các UI text không dấu hoặc tiếng Anh đang hardcode như:

```text

OK

Email

Phone

Facebook

Cancel

Submit

Loading

Search

Next

Back

Yes

No

```

Nếu chúng là UI text thì cũng phải đối chiếu với language.

Vẫn áp dụng:

```text

UI text

→ tìm theo vi_value

→ có thì dùng code hiện tại

→ không có thì MISSING_LANGUAGE

```

Không tự tạo language chỉ vì text không phải tiếng Việt.

---

## PASS 4 — KIỂM TRA CÁC VỊ TRÍ DỄ BỎ SÓT

Quét lại:

```text

columns

items

options

tabs

menu

rules

locale

pagination

useMemo

useCallback

.map()

render()

renderCell()

renderItem()

renderContent()

conditional render

ternary

custom component props

object UI config

array UI config

```

Kiểm tra cả JSX lồng nhiều cấp.

---

# PASS 5 — KIỂM TRA CHỐNG TRÙNG TRƯỚC KHI SINH SQL

Đây là bước BẮT BUỘC.

Với TỪNG phần tử trong `MISSING_LANGUAGE`:

### Bước 1

Lấy nguyên văn text.

### Bước 2

Search lại TOÀN BỘ file language theo `vi_value`.

### Bước 3

Nếu tìm thấy:

```text

vi_value == text

```

→ XÓA khỏi `MISSING_LANGUAGE`.

→ Quay lại source và thay text bằng:

```tsx

t('code')

```

### Bước 4

Chỉ khi chắc chắn KHÔNG tồn tại `vi_value` tương ứng mới được giữ trong `MISSING_LANGUAGE`.

### Bước 5

Loại bỏ duplicate trong chính `MISSING_LANGUAGE`.

Hai vị trí source cùng text:

```text

Xóa vĩnh viễn

Xóa vĩnh viễn

```

chỉ được sinh **1 language variable**.

---

# QUY TẮC QUAN TRỌNG KHI SO KHỚP

Ưu tiên exact match:

```text

source text === vi_value

```

Không được coi các text gần giống nhau là cùng một text.

Ví dụ:

```text

Xóa

Xóa khách hàng

Xóa khách hàng?

Bạn có chắc chắn muốn xóa khách hàng?

```

là các text khác nhau.

Không tự ý thay đổi nội dung để ép khớp language.

---

# OUTPUT

Trả về đúng các phần sau.

## 1. File source đã sửa

Toàn bộ file sau khi xử lý.

---

## 2. Các text chưa có

Ví dụ:

```text

Các text chưa có:

- Xóa vĩnh viễn

- Khôi phục khách hàng

```

Nếu không thiếu:

```text

Các text chưa có: Không có

```

---

## 3. SQL

Chỉ sinh SQL cho text đã vượt qua PASS 5 và chắc chắn chưa tồn tại trong language.

```sql

INSERT IGNORE INTO language (code, vi_value, en_value)

VALUES

('permanently_delete', 'Xóa vĩnh viễn', 'Permanently delete'),

('restore_customer', 'Khôi phục khách hàng', 'Restore customer');

```

Quy tắc `code`:

* tiếng Anh

* lowercase

* snake_case

* ngắn gọn

* đúng ngữ nghĩa

* dễ tái sử dụng

`en_value` phải là tiếng Anh tự nhiên, phù hợp UI.

---

# KIỂM TRA CUỐI CÙNG

Trước khi kết thúc, tự xác nhận:

```text

[ ] Đã đọc TOÀN BỘ language.

[ ] Đã tạo/hiểu mapping vi_value → code.

[ ] Đã đọc TOÀN BỘ source.

[ ] Đã kiểm tra mọi JSXText/string có khả năng hiển thị.

[ ] Đã search lại text tiếng Việt còn hardcode.

[ ] Đã kiểm tra text không dấu/tiếng Anh hiển thị trên UI.

[ ] Đã kiểm tra columns/items/options/render/callback/hooks.

[ ] Mọi text có vi_value tương ứng đều đã dùng code CÓ SẴN.

[ ] Không tạo code mới cho vi_value đã tồn tại.

[ ] Đã search lại từng MISSING_LANGUAGE trong language lần thứ hai.

[ ] Đã loại duplicate khỏi MISSING_LANGUAGE.

[ ] SQL chỉ chứa text thực sự chưa tồn tại.

[ ] Không sửa logic.

[ ] Không refactor ngoài phạm vi task.

```

Nếu bất kỳ mục nào chưa hoàn thành → tiếp tục kiểm tra, KHÔNG trả kết quả.

---

# QUY TẮC CUỐI CÙNG

**`vi_value` là căn cứ xác định language đã tồn tại hay chưa.**

Luồng bắt buộc cho MỌI UI text:

```text

UI TEXT

   ↓

SEARCH TOÀN BỘ LANGUAGE THEO vi_value

   ↓

┌────────────────────┬─────────────────────┐

│ TÌM THẤY           │ KHÔNG TÌM THẤY      │

│                    │                     │

│ dùng code hiện có  │ giữ nguyên source   │

│ t('existing_code') │ MISSING_LANGUAGE    │

└────────────────────┴─────────────────────┘

                              ↓

                     SEARCH LẠI LẦN CUỐI

                              ↓

                     vẫn không tồn tại

                              ↓

                         SINH SQL

```

**Không được sinh SQL hoặc tạo code mới trước khi search `vi_value` trong toàn bộ language.**

**Không được tạo language trùng chỉ vì không đoán được tên `code` hiện tại.**

**Không được kết thúc task khi vẫn còn UI text có `vi_value` tương ứng nhưng chưa được chuyển thành `t('code')`.**

Viết tài liệu hướng dẫn từ CURL

Trong quá trình phát triển phần mềm, việc viết tài liệu API thường mất khá nhiều thời gian. Thay vì viết thủ công, bạn có thể cung cấp cURL (và nếu có thì kèm Response JSON) cho AI để tự động sinh tài liệu API theo một cấu trúc thống nhất.

Tài liệu được tạo nên bao gồm:

• Thông tin chung của API.
• Mục đích sử dụng.
• URL (Endpoint).
• Header.
• Body Request.
• Query Parameters.
• Path Parameters.
• Trạng thái trả về từ API.
• Response.
• Response lỗi.
• Luồng xử lý.
• Ví dụ cURL.

Bạn là Technical Writer. Tôi sẽ cung cấp cho bạn cURL của một API (và có thể kèm Response JSON). Hãy phân tích và viết tài liệu API bằng tiếng Việt theo định dạng Markdown chuyên nghiệp để có thể đưa trực tiếp vào Google Docs hoặc tài liệu kỹ thuật.

Yêu cầu:

- Không tự suy diễn dữ liệu, nếu thiếu thì ghi "Chưa xác định".

- Chỉ ghi Endpoint, không ghi Base URL.

- Phân tích đầy đủ Method, Header, Query Parameters, Path Parameters, Body và Response.

- Nếu dùng Bearer Token thì tự thêm Authorization Header.

- Nếu là upload file thì tự nhận biết multipart/form-data, chỉ hiển thị các field upload và bổ sung mục Quy định Upload.

- Nếu Response theo chuẩn {status, msg, data} thì tạo thêm bảng Trạng thái trả về từ API.

- Response, Request Body và các Parameters phải trình bày dưới dạng bảng.

- Có ví dụ Response JSON.

- Có các Response lỗi nếu xác định được.

- Có Luồng xử lý.

- Cuối tài liệu đặt lại đầy đủ cURL.

Cấu trúc tài liệu:

# <Tên API>

## Mục đích

## URL

## Header

## Body

## Query Parameters

## Path Parameters

## Trạng thái trả về từ API

## Response

## Response lỗi

## Luồng xử lý

## Ví dụ cURL

Cách sử dụng

Chỉ cần gửi cho AI:

Viết tài liệu API theo mẫu dưới đây.

cURL:

<dán cURL>

Response:

<dán JSON Response>

Kiểm tra và check lỗi

Hãy rà soát cnăng này để phát hiện các phần đã code nhưng đang hoạt động không đúng, đặc biệt tập trung vào API, dữ liệu và hiển thị giao diện.

Yêu cầu kiểm tra:

Rà soát toàn bộ API đang được gọi

Tìm tất cả các request: fetch, axios, service API, Redux action/thunk, React Query hoặc các hàm request khác.

Kiểm tra URL, endpoint, HTTP method, params, query params và body truyền lên.

Kiểm tra API nào gọi lỗi, sai endpoint, sai method hoặc thiếu params.

Kiểm tra API nào đã viết nhưng thực tế không được gọi.

Kiểm tra API bị gọi lặp không cần thiết.

Kiểm tra API gọi sai thời điểm do useEffect, dependency hoặc lifecycle.

Kiểm tra dữ liệu API trả về

Đối chiếu cấu trúc response với cách frontend đang đọc dữ liệu.

Tìm các trường hợp sai path, ví dụ API trả data.items nhưng code lại đọc data.data.

Kiểm tra field bị sai tên, undefined, null hoặc sai kiểu dữ liệu.

Kiểm tra pagination, total, page, limit nếu có.

Kiểm tra dữ liệu có trả về nhưng không được set vào state/Redux đúng cách.

Kiểm tra dữ liệu không hiển thị trên giao diện

API thành công và có dữ liệu nhưng component không render.

State đã có dữ liệu nhưng UI không cập nhật.

Điều kiện render sai.

Mapping dữ liệu sai field.

Component nhận sai hoặc thiếu props.

Redux selector lấy sai dữ liệu.

useMemo, useEffect, useCallback dependency sai làm dữ liệu không cập nhật.

Loading state không được tắt.

Error state che mất dữ liệu.

Filter/search làm mất dữ liệu ngoài ý muốn.

Kiểm tra các thao tác CRUD

Danh sách.

Chi tiết.

Thêm mới.

Cập nhật.

Xóa.

Bật/tắt trạng thái.

Search/filter.

Pagination.

Upload nếu có.

Đảm bảo sau khi thao tác thành công thì dữ liệu trên giao diện được cập nhật đúng, không cần reload trang nếu thiết kế hiện tại không yêu cầu.

Kiểm tra lỗi runtime

Console error/warning.

Promise rejection.

Access property of undefined/null.

React key warning.

Infinite render / infinite API request.

Memory leak.

State update sau khi component unmount.

Import/component/function bị thiếu hoặc sai.

Kiểm tra các màn hình đã làm

Không chỉ kiểm tra file đang mở.

Tìm từ router/menu để xác định toàn bộ page/module liên quan.

Lần theo luồng:

Page -> Component -> Hook/Redux -> Service/API -> Response -> State -> Render

Phát hiện những chức năng đã có UI nhưng chưa nối API hoặc nối API chưa hoàn chỉnh.

Không tự ý thay đổi business logic

Trước tiên hãy xác định lỗi dựa trên code hiện tại.

Không tự tạo endpoint hoặc field API khi chưa có căn cứ.

Nếu không xác định được response thực tế của backend thì ghi rõ phần cần xác minh, không đoán cấu trúc dữ liệu.

Sau khi rà soát, hãy sửa trực tiếp các lỗi có thể xác định chắc chắn

Ưu tiên lỗi khiến API không chạy.

API chạy nhưng dữ liệu không hiển thị.

Sai mapping response.

Sai state/Redux.

Sai dependency.

Sai params/body.

Loading/error handling bị kẹt.

Các lỗi runtime liên quan.

Sau khi sửa xong

Chạy lint/build/typecheck/test nếu project có hỗ trợ.

Sửa các lỗi phát sinh liên quan đến phần vừa thay đổi.

Không sửa lan sang các phần không liên quan nếu không cần thiết.

Cuối cùng báo cáo ngắn gọn theo format:

Đã kiểm tra

Các page/module đã rà soát

Các API đã kiểm tra

Lỗi phát hiện

Filenày

Tạo rule cho AI khi sửa dự án

Tạo file AGENTS.md

# AGENTS.md

## Language & UI Text

- Luôn giao tiếp với người dùng bằng tiếng Việt.

- Code, tên biến, tên hàm, tên class, file và module phải theo convention hiện tại của project.

- Comment trong code theo convention hiện tại của project; không tự ý thêm comment dài hoặc không cần thiết.

- Khi thêm mới hoặc ghép giao diện có text hiển thị cho người dùng, mặc định sử dụng tiếng Việt có dấu.

- Không tự ý chuyển text tiếng Việt hiện có sang tiếng Anh.

- Không sử dụng tiếng Việt không dấu cho label, button, placeholder, message, validation message, notification hoặc các nội dung UI khác.

- Nếu giao diện mẫu sử dụng tiếng Anh nhưng project hiện tại sử dụng tiếng Việt, ưu tiên chuyển nội dung hiển thị sang tiếng Việt có dấu, trừ khi người dùng yêu cầu giữ nguyên tiếng Anh.

- Giữ nguyên terminology đang được project sử dụng để đảm bảo nhất quán.

## Core Principles

- Luôn đọc và hiểu code liên quan trước khi chỉnh sửa.

- Không đoán implementation khi chưa đọc code.

- Tìm tất cả nơi function/module/component đang được sử dụng trước khi thay đổi.

- Chỉ thay đổi những gì cần thiết để hoàn thành task.

- Ưu tiên giải pháp đơn giản, ít thay đổi và tương thích với code hiện tại.

- Ưu tiên tái sử dụng function, service, component, helper, hook, utility và pattern đang có.

- Không tự ý refactor code ngoài phạm vi task.

- Không tự ý thay đổi architecture hoặc structure của project.

- Không tự ý cài, nâng cấp hoặc xóa package/dependency.

- Không tạo file mới nếu có thể xử lý hợp lý bằng cấu trúc hiện tại.

- Không tự ý sửa các lỗi khác không liên quan đến task.

- Không tự ý thay đổi behavior hiện tại nếu task không yêu cầu.

## Code Reuse

- Luôn tìm kiếm function, helper, service, component, hook, utility hoặc module có chức năng tương tự trước khi tạo mới.

- Nếu đã có function/module thực hiện cùng chức năng hoặc có thể tái sử dụng hợp lý thì bắt buộc ưu tiên sử dụng lại.

- Không tạo function/helper/component/service mới có logic hoặc chức năng trùng lặp với code hiện tại.

- Trước khi tạo function mới, phải kiểm tra trong project xem đã có implementation tương tự chưa.

- Không copy/paste logic hiện tại sang nơi khác nếu có thể tái sử dụng thông qua function/module đã có.

- Nếu code hiện tại chỉ cần thay đổi nhỏ để có thể tái sử dụng thì ưu tiên mở rộng code hiện tại.

- Khi mở rộng code hiện tại phải đảm bảo không làm thay đổi behavior cũ ngoài phạm vi task.

- Không tạo abstraction/helper mới chỉ để sử dụng một lần nếu code trực tiếp đơn giản và phù hợp với convention hiện tại.

## Before Coding

Trước khi sửa code phải:

1. Phân tích yêu cầu.

2. Xác định chính xác phạm vi thay đổi.

3. Tìm các file liên quan.

4. Đọc implementation hiện tại.

5. Tìm nơi function/module/component đang được sử dụng.

6. Tìm code/function/component có thể tái sử dụng.

7. Kiểm tra dependency và ảnh hưởng tới code hiện tại.

8. Xác định giải pháp ít thay đổi nhất.

9. Sau đó mới sửa code.

## Backend

- Luôn kiểm tra đầy đủ luồng liên quan:

  route → middleware → controller → service → model/database.

- Kiểm tra validation, authentication và authorization liên quan nếu có.

- Trước khi tạo API/function/service mới, kiểm tra xem project đã có chức năng tương tự chưa.

- Không tự ý thay đổi API endpoint.

- Không tự ý thay đổi HTTP method.

- Không tự ý thay đổi request parameters/body.

- Không tự ý thay đổi API response structure.

- Không tự ý đổi tên field đang được frontend hoặc hệ thống khác sử dụng.

- Không tự ý thay đổi status code nếu task không yêu cầu.

- Đảm bảo backward compatibility với code hiện tại.

- Khi sửa một API phải kiểm tra nơi API đó đang được gọi.

- Ưu tiên sử dụng service/helper/model hiện tại thay vì viết lại logic tương tự.

## Frontend

- Kiểm tra page, component, API/service, state/store, hook, utility và các component liên quan.

- Không thay đổi UI nếu task không yêu cầu.

- Không tự ý thay đổi business logic khi task chỉ yêu cầu sửa UI.

- Ưu tiên sử dụng component, style, hook, utility và pattern có sẵn.

- Trước khi tạo component mới phải tìm component tương tự trong project.

- Không tạo component mới nếu component hiện tại có thể tái sử dụng hợp lý.

- Không tự ý thay đổi responsive behavior ngoài phạm vi task.

- Không tự ý thay đổi API integration khi task chỉ liên quan tới giao diện.

## Ghép giao diện

Khi người dùng yêu cầu "ghép giao diện":

- Ưu tiên giữ nguyên toàn bộ business logic hiện tại.

- Giữ nguyên API endpoint hiện tại.

- Giữ nguyên request và response hiện tại.

- Giữ nguyên service/API integration hiện tại.

- Giữ nguyên state management và data flow nếu không có yêu cầu thay đổi.

- Không tự ý tạo API mới khi API hiện tại đã đáp ứng chức năng.

- Không tự ý sửa backend khi task chỉ yêu cầu ghép frontend.

- Chỉ thay đổi phần UI cần thiết để khớp giao diện được cung cấp.

- Ưu tiên tái sử dụng component hiện tại.

- Không dùng mock data thay cho API đang hoạt động.

- Không hardcode dữ liệu nếu dữ liệu hiện tại đã lấy từ API/state.

- Không xóa logic hiện tại chỉ vì giao diện mới chưa sử dụng đến.

- Text hiển thị trên giao diện phải sử dụng tiếng Việt có dấu.

- Nếu giao diện mẫu có text tiếng Anh nhưng hệ thống hiện tại sử dụng tiếng Việt, chuyển text đó sang tiếng Việt có dấu phù hợp với ngữ cảnh.

- Giữ terminology nhất quán với các màn hình hiện tại của project.

## Database

- Không tự ý DROP database/table/collection.

- Không tự ý DELETE dữ liệu.

- Không tự ý ALTER schema.

- Không tự ý tạo migration.

- Không tự ý đổi tên column/field.

- Không tự ý thay đổi index.

- Query thay đổi phải đảm bảo tương thích dữ liệu cũ.

- Không giả định cấu trúc database nếu chưa kiểm tra model/schema/query hiện tại.

- Ưu tiên query và pattern database đang được project sử dụng.

- Với thao tác có khả năng làm mất dữ liệu, phải dừng lại và báo cho người dùng trước khi thực hiện.

## Security

- Không hardcode password, token, API key, secret hoặc credential vào source code.

- Không hiển thị hoặc đưa secret/credential vào log.

- Không tự ý sửa file `.env` hoặc credential.

- Không commit secret hoặc dữ liệu nhạy cảm.

- Không đưa token/password/API key thật vào code mẫu.

- Nếu phát hiện credential đang tồn tại trong code, chỉ cảnh báo; không tự ý thay đổi ngoài phạm vi task.

## Git

- Không tự ý commit.

- Không tự ý push.

- Không tự ý pull.

- Không tự ý merge.

- Không tự ý rebase.

- Không tự ý checkout hoặc đổi branch.

- Không dùng `git reset --hard`.

- Không dùng `git clean` hoặc các lệnh có thể xóa file chưa commit.

- Không tự ý revert thay đổi của người dùng.

- Có thể sử dụng `git diff` và `git status` để kiểm tra thay đổi khi cần.

## Upload / Deploy

- Dự án sử dụng `.vscode/sftp.json` làm cấu hình SFTP; trước khi upload hoặc deploy, kiểm tra và dùng cấu hình hiện có trong file này.

- Dùng `host`, `port`, `username` và `remotePath` trong `.vscode/sftp.json` để kết nối và xác định thư mục đích; upload các file có thay đổi liên quan đến task theo đúng cấu trúc đường dẫn của dự án.

- Cấu hình hiện bật `uploadOnSave`; không dựa riêng vào hành vi tự upload khi lưu để kết luận các file liên quan đã được upload đầy đủ. Đối chiếu danh sách file thay đổi với đích upload.

- Không tự suy đoán host, thư mục đích hoặc danh sách file cần upload; đối chiếu thay đổi thực tế và cấu hình trước khi thực hiện.

- Không in, ghi vào log, đưa vào nội dung trả lời hoặc commit thông tin nhạy cảm trong cấu hình như mật khẩu, token hay khóa riêng.

- Không sửa nội dung `.vscode/sftp.json` trừ khi người dùng yêu cầu rõ ràng.

- Nếu không tìm thấy file cấu hình thì bỏ qua upload

## Commands & Testing

- Không tự ý chạy application.

- Không tự ý chạy test.

- Không tự ý chạy build.

- Không tự ý chạy migration.

- Không tự ý chạy seed.

- Không tự ý restart service/process/container.

- Không tự ý chạy command có khả năng thay đổi dữ liệu.

- Không tự ý chạy npm/yarn/pnpm install.

- Không tự ý chạy Docker/PM2 command làm thay đổi trạng thái service.

- Không hỏi người dùng có muốn chạy test/build hay không nếu người dùng chưa yêu cầu.

- Chỉ thực hiện các thao tác trên khi người dùng yêu cầu rõ ràng.

## Scope Control

- Chỉ xử lý đúng phạm vi task người dùng yêu cầu.

- Không mở rộng phạm vi task.

- Không tự ý sửa code không liên quan.

- Không refactor code chỉ vì thấy có thể viết đẹp hơn.

- Không đổi tên biến/function/file ngoài phạm vi cần thiết.

- Không format lại toàn bộ file nếu chỉ sửa một phần nhỏ.

- Không thay đổi coding style hiện tại nếu task không yêu cầu.

Nếu trong quá trình xử lý phát hiện vấn đề khác:

- Không tự ý sửa.

- Không mở rộng phạm vi task.

- Có thể thông báo ngắn gọn cho người dùng sau khi hoàn thành task hiện tại.

Nếu yêu cầu không rõ nhưng có thể suy ra an toàn từ code hiện tại:

- Ưu tiên implementation nhất quán với pattern hiện tại.

- Không tự sáng tạo business rule mới.

Nếu có nhiều cách implementation:

- Ưu tiên cách ít thay đổi code nhất.

- Ưu tiên cách tái sử dụng code hiện tại nhiều nhất.

- Ưu tiên cách tương thích với architecture hiện tại.

- Ưu tiên backward compatibility.

- Không refactor lớn chỉ để làm code "đẹp hơn".

## Existing Behavior

- Mặc định coi behavior hiện tại là có chủ đích nếu chưa có bằng chứng ngược lại.

- Không xóa hoặc thay đổi logic cũ chỉ vì thấy không cần thiết.

- Không thay đổi business rule nếu người dùng không yêu cầu.

- Khi sửa bug, ưu tiên sửa nguyên nhân trực tiếp của bug thay vì viết lại toàn bộ flow.

- Đảm bảo chức năng cũ không bị ảnh hưởng bởi thay đổi mới.

## After Coding

Sau khi sửa:

1. Đọc lại toàn bộ phần code vừa thay đổi.

2. Kiểm tra syntax và logic bằng việc review code.

3. Kiểm tra các caller/callee liên quan.

4. Kiểm tra có tạo logic/function trùng lặp không.

5. Kiểm tra API contract có bị thay đổi ngoài ý muốn không.

6. Kiểm tra business logic cũ có bị ảnh hưởng không.

7. Kiểm tra có thay đổi file ngoài phạm vi task không.

8. Kiểm tra text UI mới có đúng tiếng Việt có dấu không.

9. Kiểm tra `git diff` nếu repository sử dụng Git.

10. Không chạy test/build/application nếu người dùng chưa yêu cầu.

## Response

Sau khi hoàn thành, trả lời ngắn gọn:

- Đã sửa gì.

- File nào đã thay đổi.

- Logic chính đã thay đổi như thế nào.

- Đã tái sử dụng code/function/component nào nếu có.

- Có vấn đề hoặc rủi ro nào người dùng cần biết hay không.

Không viết giải thích dài nếu không cần thiết.

Không đề xuất refactor hoặc công việc ngoài phạm vi task nếu không thực sự cần thiết .

Viết tài liệu Docs API

Hãy phân tích source code của project hiện tại và tạo tài liệu API dành cho developer đối tác tại:

`docs/partner-api.md`

## Yêu cầu

* Tự tìm và phân tích routes, middleware/auth, validation, controller, service và response/error handler để xác định API contract thực tế.

* Chỉ document thông tin có thể xác minh từ source code.

* KHÔNG suy đoán hoặc tự tạo thêm request, response, error, validation.

* KHÔNG thay đổi source code hoặc business logic.

* KHÔNG đưa implementation nội bộ như controller/service/function/file/database vào tài liệu.

* KHÔNG đưa password, token, secret, internal IP hoặc credentials thật vào tài liệu. Dùng placeholder như `YOUR_API_TOKEN`, `YOUR_PASSWORD`.

* Kiểm tra đầy đủ router prefix để lấy đúng full endpoint.

## Format

Nhóm API theo chức năng:

# Authentication

## Đăng nhập

Mô tả ngắn API.

**Endpoint**

```http

POST /api/v1/auth/login

```

**Authentication:** Public / Bearer Token / API Key

Chỉ hiển thị các section bên dưới nếu API thực sự có dữ liệu tương ứng.

### Headers

| Header | Required | Description |

| ------ | -------- | ----------- |

### Path Parameters

| Parameter | Type | Required | Description | Example |

| --------- | ---- | -------- | ----------- | ------- |

### Query Parameters

| Parameter | Type | Required | Description | Example |

| --------- | ---- | -------- | ----------- | ------- |

### Request Body

| Field | Type | Required | Description | Example |

| ----- | ---- | -------- | ----------- | ------- |

### Request Example

```json

{

  "email": "user@example.com",

  "password": "YOUR_PASSWORD"

}

```

### Response

**HTTP 200**

```json

{

  "success": true,

  "data": {}

}

```

Nếu xác định được response fields thì thêm:

| Field | Type | Description |

| ----- | ---- | ----------- |

### Errors

| HTTP Status | Error Code | Description |

| ----------- | ---------- | ----------- |

Nếu API không có Error Code thì bỏ cột này.

### cURL

```bash

curl -X POST "$BASE_URL/api/v1/auth/login" \

  -H "Content-Type: application/json" \

  -d '{

    "email": "user@example.com",

    "password": "YOUR_PASSWORD"

  }'

```

## Quy tắc bắt buộc

1. Một endpoint = một section riêng.

2. Không gom nhiều API thành một đoạn văn.

3. Không hiển thị section không có dữ liệu.

4. Dùng bảng cho parameters/request/response/errors.

5. Dùng code block riêng cho endpoint, JSON và cURL.

6. cURL phải đúng contract và có thể copy để test.

7. Không ghi `Unknown`, `TODO`, `chưa xác định` vào tài liệu partner.

8. Nếu thông tin không xác minh được từ source thì bỏ qua, KHÔNG tự đoán.

9. Tài liệu phải sạch, dễ scan và chỉ chứa thông tin developer đối tác cần để tích hợp API.

10. Sau khi tạo xong, tự review lại Markdown để đảm bảo không lỗi bảng, heading hoặc code block.

Mục tiêu: developer đối tác nhìn vào mỗi API trong 5–10 giây phải tìm được Method, Endpoint, Authentication, Parameters, Request, Response, Errors và cURL.

Hãy tự scan toàn bộ project và tạo/cập nhật `docs/partner-api.md`. Không cần hỏi tôi xác nhận từng endpoint.