# TSHIRTORDER-XXXX — Tiêu đề ngắn gọn mô tả tính năng

> File này là **template**. Khi tạo issue doc mới:
> - Nếu issue có **mockup/ảnh đính kèm** → tạo **folder** `docs/issues/TSHIRTORDER-XXXX/`, đặt file markdown tên mô tả ngắn gọn (không lặp lại số ticket) bên trong, ví dụ `docs/issues/TSHIRTORDER-1600/add-color-field.md`, và copy ảnh vào `docs/issues/TSHIRTORDER-XXXX/files/`.
> - Nếu issue **không có ảnh** → tạo file phẳng `docs/issues/TSHIRTORDER-XXXX-mo-ta-ngan.md` ngay trong `docs/issues/`.
> - Xoá dòng blockquote hướng dẫn này khi bắt đầu viết doc thật.

## Yêu cầu gốc

> Quote lại nguyên văn yêu cầu của user/sếp (copy paste, không diễn giải).
> Nếu có ảnh mockup, ghi chú: "Kèm ảnh mockup (xem `files/ten-anh.png`)."

---

## Tổng quan

2-4 câu tóm tắt: tính năng làm gì, thuộc phần nào của hệ thống (API/Webshop/Cronjob/...), phạm vi (backend/frontend/cả hai).

**Luôn kiểm tra code hiện tại trước khi viết TODO** — nhiều field/logic có thể đã tồn tại sẵn (entity, migration, service method) từ trước. Nếu phát hiện phần nào đã có sẵn, ghi rõ trong 1 mục riêng kiểu:

> ⚠️ **Phát hiện quan trọng: X đã có sẵn từ trước** — liệt kê bằng bảng file/dòng code + trạng thái ✅, để tránh làm lại việc đã có.

---

## Luồng hoạt động / Chi tiết theo mockup *(chọn 1 trong 2 tuỳ loại issue)*

Với **flow nghiệp vụ** (button → action → email → status change,...): mô tả luồng từng bước, quote lại phần yêu cầu gốc tương ứng bằng `>` cho từng bước nếu hữu ích.

Với **UI/mockup**: mô tả rõ mockup đang chỉ vào đâu, field/cột nào cần thêm, vị trí trong layout hiện tại.

---

## Questions / Đã xác nhận *(optional — chỉ thêm nếu có trao đổi qua lại với sếp/PO)*

| # | Câu hỏi | Trả lời | Ghi chú kỹ thuật |
|---|---------|---------|-------------------|
| 1 | ... | ... | ... |

Nếu còn điểm chưa rõ, tạo thêm mục **Pending Clarification** liệt kê các phương án đang cân nhắc — đừng tự quyết định thay sếp khi mơ hồ.

---

## API contract / Thiết kế kỹ thuật

Với thay đổi có API: liệt kê rõ route, method, field request/response — đủ để FE team làm việc độc lập không cần đọc code BE.

Với thay đổi entity: bảng field mới (tên, type, ý nghĩa) + tên migration nếu đã chạy.

Nếu phát hiện **bẫy/side-effect** dễ gây bug (VD: field bị ghi đè nếu FE không gửi đủ), tách riêng thành mục `#### ⚠️ Lưu ý bẫy quan trọng`.

---

## TODO List

Chia theo layer, dùng checkbox `- [ ]` (tick `- [x]` khi đã làm xong):

```
### Backend — Entity & Migration
- [ ] ...

### Backend — Service
- [ ] ...

### Backend — Controller & Routing
- [ ] ...

### Frontend — React *(nếu có, ghi rõ đây là repo khác nếu FE không nằm trong repo này)*
- [ ] ...

### Test / kiểm tra
- [ ] ...
```

Mỗi TODO nên nêu rõ **file** + **method/logic cụ thể**, không viết chung chung.

---

## Các file/files liên quan

| File | Mục đích |
|------|----------|
| `src/...` | ... |

---

## Estimate *(optional — chỉ thêm nếu được yêu cầu ước lượng giờ)*

| # | Task | Giờ |
|---|------|-----|
| 1 | ... | ... |