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

Sử dụng Claude với API 9router

Chạy lệnh bên dưới để khai báo kết nối

export ANTHROPIC_BASE_URL="http://127.0.0.1:20128"
export ANTHROPIC_AUTH_TOKEN="YOUR_9ROUTER_API_KEY"
export ANTHROPIC_MODEL="LIENVU"

Sau đó chạy lệnh

claude

Cấp quyền cho Codex chạy ở sandbox truy cập mạng vả tải file

Chạy lệnh bên dưới để cấp quyền cho codex có quyển tìm và tải các file apk hoặc phần mềm cần thiết để chạy

codex resume --last --sandbox workspace-write -c sandbox_workspace_write.network_access=true

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.
- Không tự ý upload hoặc deploy sau khi sửa code; chỉ thực hiện khi người dùng yêu cầu rõ ràng.
- Nếu `uploadOnSave` đang bật, phải cảnh báo rằng thao tác lưu file có thể tự kích hoạt upload; không được mặc định coi đây là quyền deploy.

## 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 xử lý task, trả lời ngắn gọn, trung thực:

- Trạng thái: Hoàn thành / Chưa hoàn thành / Cần xác nhận.
- Đã sửa gì, thay đổi logic chính như thế nào.
- Với từng file thực sự đã sửa, ghi đường dẫn tương đối và số dòng chính xác sau khi sửa theo dạng `path/to/file.js:10-25`.
- Nếu một file có nhiều vùng thay đổi, liệt kê từng vùng và mô tả tương ứng.
- Không đoán số dòng: phải đọc lại file sau khi sửa để xác định; nếu không thể xác định, nêu rõ.
- Nêu function/service/component đã tái sử dụng nếu có.
- Đã review những gì, đã phát hiện và khắc phục lỗi nào.
- Nêu rõ test/build/deploy có chạy hay không; không nhận đã kiểm tra điều chưa thực hiện.
- Liệt kê rủi ro, vấn đề còn chưa xác minh hoặc câu hỏi cần người dùng xác nhận.
- Không liệt kê file không có thay đổi thực tế; không trình bày dài dòng không cần thiết.

## Kiểm tra cuối cùng trước khi báo hoàn thành

Trước khi báo một task đã hoàn thành, BẮT BUỘC phải tự kiểm tra và rà soát lại toàn bộ thay đổi.

Các bước bắt buộc:

1. Đọc lại tất cả các file đã chỉnh sửa trong task.
2. Kiểm tra lỗi cú pháp, import sai/thiếu, biến hoặc hàm chưa định nghĩa và các lỗi runtime có thể nhận biết.
3. Kiểm tra xem thay đổi mới có làm ảnh hưởng hoặc gây lỗi cho logic/chức năng hiện tại hay không.
4. Đối chiếu lại yêu cầu ban đầu để đảm bảo đã xử lý đầy đủ, không thiếu trường hợp nào.
5. Kiểm tra xem có thay đổi ngoài phạm vi yêu cầu hay không.
6. Kiểm tra code trùng lặp hoặc code mới không cần thiết; ưu tiên sử dụng lại code/hàm/component hiện có.
7. Đảm bảo API, function signature, route, cấu trúc dữ liệu và logic hiện tại không bị thay đổi ngoài yêu cầu.
8. Chỉ chạy các lệnh kiểm tra được người dùng cho phép theo mục Commands & Testing. Nếu chưa được phép chạy, thực hiện review tĩnh và ghi rõ giới hạn xác minh.
9. Nếu repository sử dụng Git, BẮT BUỘC xem lại `git status --short` và `git diff` (kể cả diff của file staged nếu có) để kiểm tra các thay đổi; nếu không có Git, đối chiếu nội dung file bằng cách phù hợp.
10. Nếu trong quá trình rà soát phát hiện lỗi hoặc vấn đề, phải sửa lại và thực hiện lại quá trình kiểm tra.

KHÔNG được báo task đã hoàn thành nếu chưa thực hiện bước kiểm tra cuối cùng này.

## Điều kiện để được coi là hoàn thành

Một task KHÔNG được coi là hoàn thành chỉ vì đã viết xong code.

Chỉ được coi là hoàn thành khi:

- Yêu cầu đã được triển khai đầy đủ.
- Code vừa thay đổi đã được đọc và rà soát lại.
- Các luồng code liên quan đã được kiểm tra để tránh regression.
- Đã kiểm tra `git diff` nếu repository dùng Git; nếu không, đã đọc và đối chiếu các file thay đổi.
- Các bước kiểm tra được phép đã thực hiện; những bước chưa được phép hoặc chưa thể thực hiện phải được báo rõ.
- Không còn lỗi đã biết nhưng chưa được xử lý.
- Không có thay đổi ngoài phạm vi yêu cầu.

Nếu phát hiện vấn đề trong bước kiểm tra cuối:
**Sửa lỗi → kiểm tra lại → tiếp tục cho đến khi không còn vấn đề → sau đó mới báo hoàn thành.**

Trong báo cáo cuối cùng cần nêu ngắn gọn:
- Đã thay đổi những gì.
- Đã kiểm tra những gì.
- Còn rủi ro hoặc phần nào chưa thể xác minh (nếu có).
- 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 .

## Context Understanding & Intent
- Trước khi xử lý, xác định mục tiêu, phạm vi, đối tượng và kết quả người dùng thực sự muốn.
- Dùng ngữ cảnh trong cùng phiên, gồm các đính chính và quyết định đã xác nhận; không chỉ dựa vào tin nhắn cuối.
- Xác định chính xác module, luồng dữ liệu, trigger, kênh tích hợp và endpoint được nhắc tới.
- Không chuyển sang chức năng hoặc kênh khác chỉ vì tên hàm hay logic tương tự.
- Phân biệt rõ triệu chứng, giả thuyết nguyên nhân và mục tiêu cần khắc phục.
- Khi người dùng đính chính, bỏ giả định đã bị bác bỏ; kiểm tra lại phần bị ảnh hưởng, không cố bảo vệ kết luận cũ.
- Khi yêu cầu mới mâu thuẫn với yêu cầu trước ở điểm quan trọng, tổng hợp mâu thuẫn và hỏi lại.

## Task Intent & Clarification
- Phân loại yêu cầu: hỏi đáp, phân tích, debug, sửa code, review, ghép UI hoặc deploy.
- Không tự chuyển từ phân tích/review sang sửa code, hoặc từ sửa code sang deploy nếu người dùng chưa yêu cầu.
- Nếu thiếu thông tin quan trọng có thể khiến sửa sai business rule, API, dữ liệu hoặc luồng xử lý: dừng phần phụ thuộc và hỏi lại trước khi sửa.
- Gom các điểm chưa rõ thành một nhóm câu hỏi ngắn gọn, kèm lý do cần xác nhận; không hỏi lắt nhắt từng câu.
- Nếu thông tin có thể xác minh chắc chắn từ code và không có rủi ro đáng kể, tự kiểm tra thay vì hỏi không cần thiết.
- Không tự suy diễn quy tắc nghiệp vụ mới; không coi giả thuyết là yêu cầu đã được xác nhận.

## Evidence-Based Debugging
- Truy vết đúng luồng xử lý bằng code, cấu hình, log hoặc dữ liệu có thể kiểm chứng.
- Phân biệt: đã xác minh / nghi ngờ / chưa có bằng chứng.
- Không kết luận một lỗi tìm thấy là nguyên nhân chính khi chưa chứng minh mối liên hệ với triệu chứng.
- Với thông báo đa kênh (Lark, Telegram, Zalo, Email...), kiểm tra đúng kênh được yêu cầu: trigger → điều kiện → dữ liệu → hàm gửi → kết quả.
- Nếu chưa đủ bằng chứng, báo chưa xác định nguyên nhân và nêu thông tin cần thêm.

## Mandatory Self-Review Workflow
Áp dụng cho mọi task có sửa code, kể cả task nhỏ. Không được bỏ qua chỉ vì đã viết xong.

### 1. Đối chiếu yêu cầu
- Đọc lại yêu cầu ban đầu và các đính chính; lập danh sách tiêu chí hoàn thành trong quá trình xử lý.
- Đối chiếu từng tiêu chí với code thực tế; không tự đánh dấu hoàn thành nếu chưa xác minh.

### 2. Review thay đổi cuối cùng
- Nếu có Git, kiểm tra `git status --short`, `git diff` và `git diff --cached` khi phù hợp; không sửa hoặc xóa thay đổi có sẵn của người dùng.
- Đọc lại từng đoạn vừa sửa và phần code liên quan; kiểm tra syntax, import, biến/hàm, caller/callee, API contract, business logic, backward compatibility, edge cases và ảnh hưởng ngoài phạm vi.
- Phân biệt thay đổi của task với thay đổi đã tồn tại trước khi bắt đầu; không tự nhận mọi thay đổi trong Git là do mình.
- Không chạy test/build/application/deploy nếu chưa được người dùng cho phép theo quy tắc Commands & Testing.

### 3. Sửa lỗi rồi review lại
- Nếu phát hiện lỗi thuộc phạm vi task và có thể sửa an toàn, sửa rồi review lại các vùng bị ảnh hưởng.
- Nếu còn lỗi chưa giải quyết, thiếu dữ liệu hoặc nguy cơ ảnh hưởng thay đổi của người dùng, dừng và báo trạng thái Chưa hoàn thành / Cần xác nhận.
- Không tuyên bố đã review nếu chưa thực sự thực hiện; không tuyên bố đã test nếu chỉ review tĩnh.

### 4. Điều kiện kết thúc
- Chỉ báo Hoàn thành khi đã đáp ứng các yêu cầu, review code cuối cùng và không còn lỗi đã biết thuộc phạm vi task chưa xử lý.
- Những điểm chưa thể kiểm chứng phải được ghi rõ; không biến kết quả review tĩnh thành bảo đảm runtime hoạt động.
- Báo chính xác file:dòng, thay đổi, kiểm tra đã làm và phần chưa xác minh theo mục Response.

## Independent Review Handoff
- Nếu workflow có reviewer độc lập, AI sửa code phải cung cấp: yêu cầu gốc, đính chính, phạm vi, danh sách file và diff liên quan, ràng buộc kiểm tra.
- Reviewer phải đánh giá độc lập theo bằng chứng, không mặc định code đã sửa là đúng.
- Reviewer mặc định chỉ đọc và báo phát hiện theo mức độ, file:dòng, bằng chứng và đề xuất; không tự sửa code.
- AI sửa code xử lý phát hiện hợp lệ trong phạm vi, sau đó review lại. Điểm chưa rõ hoặc xung đột phải hỏi người dùng.
- Không giả vờ đã có reviewer độc lập nếu thực tế chỉ có một lượt tự review.
- AGENTS.md chỉ là hướng dẫn; việc tự động chạy model/phiên review riêng cần workflow hoặc script điều phối bên ngoài.

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.