---
name: ba-3-specification
description: Giai đoạn 3 của quy trình BA — viết đặc tả chi tiết tới mức dev code được và QA test được. Viết SRS/FRD cho một hoặc nhiều User Story, với PART 2 thay đổi theo loại sản phẩm - màn hình và bảng field (screen), endpoint và hợp đồng dữ liệu (api-service), luồng dữ liệu và data contract (data-pipeline), metric và ngưỡng chấp nhận (ml-model), lịch và idempotency (batch-job) - cộng acceptance criteria Given/When/Then đủ cả luồng lỗi, bảng mã lỗi, yêu cầu phi chức năng, API contract; với sản phẩm có giao diện còn sinh quy ước giao diện cấp project (UICONV) và wireframe low-fi (WF markdown + HTML) đối chiếu với prototype nếu có. Kích hoạt khi người dùng nói "viết SRS", "đặc tả US này", "viết acceptance criteria", "field spec", "bảng mã lỗi", "NFR", "API contract", "data contract", "spec cho dev", "ngưỡng chấp nhận cho mô hình", "wireframe", "bố cục màn hình", "đối chiếu prototype", "quy ước UI". Input là BACKLOG đã qua G2 (+ prototype/design system nếu có); output vào ba-output/<PROJECT>/03-specification/ và phải qua Gate G3 (Ready for Dev) trước khi dev bắt đầu.
---

# GĐ3 · SPECIFICATION — Đặc tả chi tiết

Mục tiêu: **viết tới mức dev code được mà không phải đoán, QA test được mà không phải hỏi.**

Đây là sản phẩm chính của nghề BA và là gate nghiêm nhất. Một chỗ mơ hồ lọt qua G3 sẽ
thành một bug hoặc một CR — với chi phí gấp nhiều lần chi phí làm rõ ở đây.

Output: `SRS` · `AC` · `NFR` · `API` trong `ba-output/<PROJECT>/03-specification/`.
Khi `PRODUCT = screen` thêm: `UICONV` (một lần cho cả project, ở `00-index/`) và `WF` (mỗi US,
gồm `.md` + `.html` low-fi) — hai artifact này là phần **thay vai trò design ở mức bố cục và
trạng thái** khi dự án có prototype tham chiếu, và là **đề xuất chờ Designer duyệt** khi không có.

## Bốn nguyên tắc bất di bất dịch

1. **Không bịa yêu cầu** — thiếu ⇒ `OQ-nnn`. Ở giai đoạn này bịa một giá trị "hợp lý"
   (độ dài 255, timeout 30s) là cách phổ biến nhất tạo ra bug.
2. **Không quyết định thay PO.**
3. **Mọi phát biểu truy vết được** — mỗi AC chỉ về `US`, mỗi field chỉ về `BR`.
4. **Không ghi đè tài liệu đã qua gate.**

Nạp bắt buộc trước khi viết: `../ba-lifecycle/references/domain-profiles.md` (quyết định
PART 2 viết cái gì và gate chặt tới đâu) · `../ba-lifecycle/references/writing-rules.md`
(W1–W13 — giai đoạn này áp dụng chặt nhất) · `../ba-lifecycle/references/artifact-map.md` §2 ·
`../ba-lifecycle/references/diagram-rules.md` (sơ đồ điều hướng, sequence, lineage).

🔴 **Mọi sơ đồ theo chuẩn Archify** (`W13`, `../ba-lifecycle/references/diagram-rules.md`): spec JSON
`diagrams/<ARTIFACT>_<slug>.<type>.json` (`quality_profile: showcase`, validate 0 lỗi) **+** mermaid có
marker `<!-- archify: <type> · <spec> -->` (hoặc `mermaid-only` cho ERD/use case/2×2) **+** bảng đi kèm.
Một đường chính, ≤ 12 node, nhãn cạnh là điều kiện/giao thức, không màu. Không có Bash ⇒ ghi
`humanInputNeeded` "chạy archify validate/deliver + diagram-check", không tự nhận đã validate.
Điều hướng, phụ thuộc job → `workflow` · luồng nhiều bên → `sequence` · lineage → `dataflow`. Riêng ở GĐ3:
mọi `sequenceDiagram` **bắt buộc vẽ cả nhánh lỗi** (`alt`/`else`, spec dùng `segments` "Nhánh lỗi") —
sequence chỉ có luồng thành công vi phạm W4, và đó chính là nhánh dev hay tự bịa. Spec mẫu đã pass:
`templates/diagrams/SRS_lineage.dataflow.json`, `../sa-2-architecture/templates/diagrams/SAD_luong-chinh.sequence.json`.

Ví dụ minh hoạ cho từng bước, ở nhiều domain khác nhau: `examples.md`.

## Bước 0 — Chốt input rồi dừng lại

**Chưa được ghi file.** Làm bảy việc rồi **dừng chờ trả lời**:

1. **Profile** — đọc `00-index/PROFILE_<PROJECT>.md`. Chưa có ⇒ suy ra từ tài liệu, **nêu rõ
   là suy đoán** và hỏi xác nhận. Nêu đích danh `PRODUCT · LIFECYCLE · RIGOR`.
2. **Input dùng được** — bảng `File | Vai trò | Version | Status`. Bắt buộc tìm: `BACKLOG`
   (US cần đặc tả), `BR`, `RBAC`, `IMPACT`, `PROCESS` từ GĐ2.
3. **Gate G2 đã qua chưa** — đọc `Approved by`. Chưa qua ⇒ nêu rủi ro (SRS sẽ phải viết lại
   nếu backlog đổi) rồi hỏi có làm tiếp không.
4. **Phạm vi lần chạy** — liệt kê đích danh `US` sẽ đặc tả. **Quá 3 US một lần chạy thì
   chất lượng giảm rõ rệt** — đề xuất chia.
5. **Biến thể PART 2 sẽ nạp** — theo `PRODUCT` (Bước 2). US có nhiều loại ⇒ nêu đủ.
6. **Guideline dự án cần tuân thủ** — tìm và nêu: `00-index/UICONV_<PROJECT>.md`, quy ước UI
   sẵn có của dự án (vd `GLOBAL_UI_CONVENTION.md`), bộ NFR chuẩn, glossary, danh sách mã lỗi
   đã dùng. **Chưa có `UICONV` mà `PRODUCT = screen` ⇒ lần chạy này phải sinh nó trước (Bước 8)**
   và nêu ai duyệt (Designer + PO).
7. **Ngôn ngữ hiển thị** — chỉ hỏi khi `PRODUCT` có giao diện cho người. Không có ⇒ ghi N/A.
8. **Prototype / design system tham chiếu** — chỉ khi `PRODUCT = screen`. Tìm theo thứ tự:
   tham số `--proto`, thư mục `design/` hoặc `prototype/` trong repo, mục *Thiết kế giao diện*
   của SAD (`docs/sections/07-*.md`, `docs/SAD.md` §7), file Figma/HTML/ảnh người dùng đưa.
   Trình bảng `Nguồn | Định dạng | Phiên bản | Phủ màn hình nào`. Không có ⇒ nói rõ **WF sẽ là
   đề xuất của BA và cần Designer duyệt trước G3**; có ⇒ prototype là nguồn sự thật về bố cục.

Rồi **hỏi xác nhận** tám điểm trên.

Bỏ qua khi lệnh có `go`.

## Thực hiện — 9 bước

Bước 1–7 cho mọi `PRODUCT`. Bước 8–9 chỉ khi `PRODUCT = screen`; loại khác ghi "N/A" trong
báo cáo cuối, không bỏ im lặng.

### Bước 1 — Khung SRS và tóm tắt nghiệp vụ

Dùng `templates/srs.md`. **Không bỏ mục nào** — mục không áp dụng thì ghi "N/A" kèm lý do,
đừng xoá; xoá mục làm người đọc không biết là đã cân nhắc hay đã quên.

Với `PRODUCT = screen`: §2.3.6 (trạng thái), §4.3 (định dạng) và mọi quy ước phân trang, toast,
vị trí nút **tham chiếu `UICONV`** thay vì định nghĩa lại. Muốn khác ⇒ ghi vào `UICONV` §12.

Viết mục **Tóm tắt nghiệp vụ** cho PO đọc: US này giải quyết `RQ` nào, người dùng được gì,
khác hiện tại chỗ nào. Ngôn ngữ nghiệp vụ, không có tên bảng dữ liệu, không có tên component.
Đây là hiện thực hoá quy tắc W10 — một tài liệu, ba người đọc.

### Bước 2 — Chọn và nạp biến thể PART 2

🔴 **PART 2 thay đổi theo `PRODUCT`.** Không viết PART 2 từ đầu — nạp biến thể:

| `PRODUCT` | Nạp | PART 2 mô tả |
|---|---|---|
| `screen` | `templates/srs-part2/screen.md` | Màn hình, bảng thành phần, bảng field |
| `api-service` | `templates/srs-part2/api-service.md` | Người tiêu thụ, khả năng, hợp đồng dữ liệu |
| `data-pipeline` | `templates/srs-part2/data-pipeline.md` | Luồng, data contract, chất lượng, đối soát |
| `ml-model` | `templates/srs-part2/ml-model.md` | Bài toán, nhãn, metric + ngưỡng, fallback |
| `batch-job` | `templates/srs-part2/batch-job.md` | Job, lịch, idempotency, cảnh báo |
| `process-only` | — | Không có PART 2; nội dung ở `PROCESS` của GĐ2 |

**Một US thường có nhiều loại** (màn hình + API, hoặc màn hình + job đêm) ⇒ nạp nhiều biến
thể, mỗi cái một mục con `2.A`, `2.B`, `2.C`. Ghi vào dòng **Biến thể PART 2** ở header.

**Loại chưa có biến thể** (nhúng/IoT/firmware) ⇒ nói thẳng với người dùng là PART 2 phải tự
viết, và đề xuất khung dựa trên biến thể gần nhất — **không im lặng nhét vào biến thể sai**.

`Read` file biến thể trước khi làm tiếp. Mỗi biến thể có **tiêu chí G3 riêng** ghi ở đầu
file — đó là thứ thay cho dòng "bảng field" / "wireframe" trong checklist G3 chung.

### Bước 3 — Điền biến thể

**Đây là phần dev đọc nhiều nhất.** Ba quy tắc áp cho **mọi** biến thể, bất kể loại sản phẩm:

**① Bảng ràng buộc phải cụ thể tới mức không cần hỏi lại.** Mỗi biến thể có một bảng đóng
vai trò "bảng field": `screen` → bảng field 10 cột · `api-service` → bảng tham số/schema ·
`data-pipeline` → bảng ánh xạ trường · `batch-job` → bảng quy tắc xử lý bản ghi ·
`ml-model` → bảng metric + ngưỡng. Bốn thứ không được để trống ở bất kỳ bảng nào:

| Thiếu | Hậu quả thực tế |
|---|---|
| **Giới hạn** (độ dài, khoảng, ngưỡng) | Chặn ở một tầng, không chặn ở tầng kia ⇒ lỗi 500 hoặc dữ liệu bẩn |
| **Giá trị mặc định** | Mỗi chỗ một kiểu; báo cáo lệch vì bản ghi cũ null |
| **Nguồn giá trị** | Lấy từ đâu, lọc theo gì, sắp xếp thế nào — dev tự quyết mỗi chỗ một kiểu |
| **Hành vi khi sai** | Dev tự quyết ⇒ mỗi chỗ một kiểu, không nhất quán, không dịch được |

Mọi con số phải có **đơn vị và nguồn** (quy tắc W3): `40 ký tự (code point UTF-8)` chứ không
phải `40`. Tiếng Hàn/Việt có dấu làm số byte khác số ký tự.

**② Ba trạng thái, không được gộp** (quy tắc W7). Với `screen`: không hiển thị · disable ·
read-only. Với `api-service`: 404 · 403 · 200 kèm cờ. Với `batch-job`: bỏ qua · quarantine ·
dừng job. Ghi "tuỳ trường hợp" là chưa đặc tả xong.

**③ Phân biệt "không có gì" với "không lấy được".** Mọi biến thể đều có mục này và mọi biến
thể đều hay bỏ nó: hai tình huống trông giống nhau (danh sách rỗng, 0 bản ghi, mảng rỗng)
nhưng ý nghĩa ngược nhau. Gộp chúng khiến sự cố bị bỏ qua nhiều ngày.

### Bước 4 — Acceptance Criteria

Dùng `templates/acceptance-criteria.md`. Viết theo Given/When/Then.

🔴 **Với `PRODUCT = ml-model`, chia đôi trước khi viết AC.** Given/When/Then không mô tả
được yêu cầu xác suất. Phần **hệ thống bao quanh** (API, lưu kết quả, hiển thị, xử lý lỗi)
viết AC bình thường đủ 4 nhóm; phần **chất lượng dự đoán** dùng **metric + ngưỡng chấp nhận**
ở PART 2 §2.4. Nhầm hai phần này là lỗi kinh điển — QA sẽ viết test đòi mô hình đúng 100%
trên vài mẫu tự chọn rồi kết luận fail.

**Mỗi US phải có đủ bốn nhóm AC** (quy tắc W4). Chỉ có nhóm 1 là spec chưa viết xong:

| Nhóm | Nội dung | Tối thiểu |
|---|---|---|
| 1. Luồng thành công | Đường đi đúng | 1 AC/hành động |
| 2. Validation | Từng rule kiểm tra dữ liệu | 1 AC/rule |
| 3. Lỗi hệ thống | Timeout, 5xx, mất mạng giữa chừng | ≥1 AC |
| 4. Phân quyền | Không đủ quyền, sai trạng thái | ≥1 AC/vai trò bị chặn |

Kèm **bảng dữ liệu biên** cho mỗi field có ràng buộc — đây là thứ QA dùng trực tiếp:

| Field | Dưới ngưỡng | Ngưỡng dưới | Trong khoảng | Ngưỡng trên | Trên ngưỡng | Rỗng | Ký tự đặc biệt |
|---|---|---|---|---|---|---|---|

**Kiểm tra tính test được** — đọc từng AC và tự hỏi: *"tôi ngồi trước màn hình, tôi làm gì
để kiểm chứng câu này?"* Không trả lời được ⇒ AC chưa viết xong. AC kiểu "hệ thống hoạt
động ổn định" không phải AC.

### Bước 5 — Bảng mã lỗi và text hiển thị

**① Bảng mã lỗi — bắt buộc với mọi `PRODUCT`:**

| Mã | Khi nào xảy ra | Thông điệp | Đi tới đâu | Người/hệ thống nhận nên làm gì | BR/AC |
|---|---|---|---|---|---|

Cột **"Đi tới đâu"** và **"nên làm gì"** đổi theo loại sản phẩm — đây là chỗ hay bị bỏ nhất
ở loại không có giao diện:

| `PRODUCT` | Đi tới đâu | Nên làm gì |
|---|---|---|
| `screen` | Toast / dưới field / trang lỗi | Người dùng sửa gì |
| `api-service` | Mã HTTP + `code` trong body | 🔴 Người gọi có được retry không |
| `data-pipeline` | Log / bảng quarantine / cảnh báo | Ai điều tra, bản ghi đi đâu |
| `batch-job` | Log + kênh cảnh báo | Người trực làm gì, có chạy lại được không |
| `ml-model` | Log + fallback | Hệ thống dùng giá trị gì thay thế |

Đặt mã theo `E-<DOMAIN>-<4 số>`, **không tái sử dụng**. Dự án đã có dãy mã ⇒ dùng tiếp số.

**② Text hiển thị — chỉ khi `PRODUCT` có giao diện cho người.** Không có ⇒ ghi "N/A", đừng
xoá mục. **BA sở hữu mọi chuỗi hiển thị** (quy tắc W5), viết nguyên văn từng ký tự:

| Khoá | Ngữ cảnh | Text (VI) | Text (EN) | Text (KO) | Giới hạn ký tự |
|---|---|---|---|---|---|

**③ "Không có gì" ≠ "không lấy được" — bắt buộc với mọi `PRODUCT`:**

| `PRODUCT` | Hai tình huống phải phân biệt |
|---|---|
| `screen` | Chưa có bản ghi nào *(nút Tạo mới)* ↔ bộ lọc không khớp *(nút Xoá lọc)* |
| `api-service` | Mảng rỗng + `total: 0` *(200)* ↔ tài nguyên không tồn tại *(404)* |
| `data-pipeline` | Ngày không phát sinh giao dịch ↔ nguồn không phản hồi |
| `batch-job` | Không có bản ghi thoả điều kiện ↔ đầu vào chưa sẵn sàng |

Gộp hai tình huống này là lỗi kinh điển: với `screen` người dùng tưởng mất dữ liệu; với ba
loại còn lại, sự cố im lặng nhiều ngày không ai biết.

### Bước 6 — Yêu cầu phi chức năng

Dùng `templates/nfr-checklist.md`. Chỉ viết **NFR áp dụng cho US này**, không copy cả bộ
tiêu chuẩn công ty vào.

Mỗi NFR bắt buộc ba thứ: **con số đo được** · **điều kiện đo** · **cách verify**.

❌ "Hệ thống phải nhanh."
✅ "Danh sách chênh lệch trả về ≤ 2 giây ở p95, với 100.000 bản ghi và 20 người dùng đồng
   thời. Verify: chạy k6 kịch bản S1 trên môi trường staging."

Bảy nhóm cần rà, ghi "N/A + lý do" cho nhóm không áp dụng: hiệu năng · dung lượng/tăng
trưởng · bảo mật & quyền riêng tư · lưu vết · khả dụng & xử lý sự cố · đa ngữ & định dạng ·
khả năng truy cập.

🔴 **Nhóm đa ngữ & định dạng hay bị bỏ:** múi giờ hiển thị, định dạng ngày, dấu phân cách
số, đơn vị tiền, sắp xếp chuỗi có dấu. Đây toàn là thứ gây bug ở môi trường thật.

### Bước 7 — API contract (nếu cần)

Dùng `templates/api-contract.md`.

🔴 **Với `PRODUCT = api-service`, đây là artifact chính, không phải bước cuối.** Làm nó song
song với Bước 3, và PART 2 chỉ mô tả hợp đồng nhìn từ phía người tiêu thụ — đừng chép trùng.

🔴 **Ghi rõ ngay đầu tài liệu API là contract này do BA đề xuất hay do BE cung cấp.** Hai
thứ có độ tin cậy khác hẳn nhau. BA đề xuất ⇒ đánh dấu `⚠️ Đề xuất — chờ BE xác nhận` và
liệt kê điểm cần BE chốt.

Với mỗi endpoint: method · path · quyền · request (kèm ràng buộc) · response thành công ·
response lỗi (map về bảng mã lỗi ở Bước 5) · phân trang · sắp xếp.

Ba điểm phải chốt, hay bị bỏ:
- **Số lớn** (id, số tiền) truyền dạng string hay number? Vượt `2^53` thì JS làm tròn sai.
- **Thời gian** dạng gì, múi giờ nào — UTC hay giờ địa phương?
- **Phân trang** offset hay cursor, có `hasNext`/`total` không?

### Bước 8 — Quy ước giao diện cấp project (`UICONV`) — chỉ `screen`

Dùng `templates/ui-convention.md`, ghi vào `00-index/UICONV_<PROJECT>.md`. **Sinh một lần** ở
lần chạy ba-3 đầu tiên của project; các lần sau chỉ đọc và bổ sung §10 (dãy mã lỗi), §11 (từ
vựng thành phần), §12 (ngoại lệ).

Nguồn điền, theo thứ tự ưu tiên: design system của dự án > prototype tham chiếu > guideline
sẵn có > **hỏi** (ghi `OQ`, không tự chọn). Mọi ô "chọn một" phải chọn xong — còn dấu `/`
giữa các phương án là chưa làm.

🔴 `UICONV` là **hợp đồng giữa BA và Design**: BA sở hữu text và trạng thái, Design sở hữu
layout và từ vựng thành phần. Cả hai ký. Dự án không có Designer ⇒ PO ký thay và ghi `DEC-nn`.

### Bước 9 — Wireframe & bố cục (`WF`) — chỉ `screen`

Dùng `templates/wireframe.md` (bảng) + `templates/wireframe.html` (render low-fi). Ghi
`WF_<US>_v1.0.md` và `WF_<US>_v1.0.html` vào `03-specification/`. Làm **sau** Bước 3 và 5, vì
WF chỉ sắp xếp những thành phần và text đã có trong SRS.

**Hai chế độ, phải khai rõ ở dòng `Nguồn bố cục` của header:**

| Chế độ | Khi nào | WF là gì | Ai duyệt |
|---|---|---|---|
| 🎨 **Prototype tham chiếu** | Có Figma / HTML / ảnh / mô tả UI đã duyệt | **Bản ghi lại** bố cục của prototype bằng bảng + đối chiếu với SRS | PO (Designer đã duyệt prototype) |
| ✏️ **BA tự dựng** | Không có prototype | **Đề xuất** bố cục theo `UICONV` | **Designer bắt buộc** ở `standard`+ |

Bốn việc, theo thứ tự:

1. **Bản đồ prototype ↔ SCR** (§1): mỗi màn hình trong `SRS` §2.1 có trong prototype không,
   ở frame/trang nào. Màn hình prototype không có ⇒ BA tự dựng phần đó và đánh dấu.
2. **Bảng vùng + vị trí thành phần** (§3.x.1–2) cho **mọi** `SCR`, kể cả modal và trang lỗi.
   🔴 Tập `C-id` phải **khớp hai chiều** với bảng thành phần `SRS` §2.3.1 — chạy
   `grep -o "C[0-9][0-9]"` trên cả hai file và so tập. Thành phần có trong prototype mà SRS
   không có ⇒ **không tự thêm vào SRS**, ghi lệch ở §5 cho PO quyết.
3. **Trạng thái, responsive, tương tác trình bày** (§3.x.3–6): hai trạng thái rỗng phải **trông**
   khác nhau; mọi con số (ms, s, px) có nguồn `UICONV`/prototype, không có ⇒ `OQ`.
4. **Sinh HTML** từ bảng: mỗi `SCR` một `<section id>`, mỗi vùng `data-zone`, mỗi thành phần
   `data-c` đúng C-id, mỗi trạng thái một khối `data-state`. Thành phần **chỉ có ở prototype**
   (lệch loại Tồn tại ở §5) vẽ đúng chỗ prototype đặt nó bằng `<span class="proto-only"
   data-ref="WF §5 #n">`, **không gán `data-c`** — khung đỏ đứt để PO nhìn thấy ngay quyết định
   còn thiếu. Giữ nguyên `<style>`/`<script>` của template để mọi WF trong project trông giống
   nhau. Không màu thương hiệu, không font.

**§5 Lệch prototype ↔ SRS là mục quan trọng nhất của WF.** Phân loại: Tồn tại · Hành vi · Bố
cục · Text · Trạng thái thiếu. Bên thắng theo W11: SRS thắng Tồn tại/Hành vi/Text; prototype
thắng Bố cục. Lệch Tồn tại/Hành vi chưa có người quyết ⇒ 🔴 chặn G3. Bảng rỗng vẫn phải ghi
"đã đối chiếu n màn hình, không lệch".

Điều **không** làm ở bước này: chọn màu, font, icon, khoảng cách chính xác, motion — ghi vào
§6 "Designer còn phải làm". Có prototype phủ hết ⇒ ghi "Không".

🔴 Việc ở §6 là **input của skill `../ba-design`** (activity `ds` → `hifi` → `figma` → `dspec`): chạy nó ngay sau
khi WF xong để ra `DS` (design system, một lần/project), `HIFI` (mockup hi-fi), `FIGMA` (gói nhập Figma) và
`DSPEC` (redline bàn giao). Dự án không có Designer ⇒ `ba-design` đóng vai đề xuất, PO ký thay theo `DEC-nn` —
**không** chuyển §6 cho Dev FE nữa.

## Trước khi kết thúc

In năm thứ (sáu khi `PRODUCT = screen`):

**① Bảng truy vết** `US` → `AC` → `BR` → `field` → `mã lỗi`. Ô trống là chỗ chưa đặc tả xong.

**② Bảng tự chấm Gate G3** (`../ba-lifecycle/references/workflow.md` §2) dạng ☐/✅.

**③ Checklist W1–W13** dạng ☐/✅. Chạy thật lệnh quét từ mơ hồ:
```bash
grep -niE "nhanh|mượt|thân thiện|v\.v|phù hợp|tương ứng|nên |có thể " <file SRS>
```
Kết quả khác rỗng ⇒ chưa đạt W2, in ra từng dòng.

**④ Danh sách `TBD` còn lại** — quét `grep -n "TBD\|TODO\|\?\?\?" <file>`. **Còn `TBD` trong
bảng ràng buộc của PART 2 hoặc trong bảng mã lỗi ⇒ G3 không thể pass**, nói thẳng điều đó.

**⑤ `OQ` mở** — cái nào ảnh hưởng tới hành vi hệ thống thì đánh dấu 🔴 chặn G3.

**⑥ Đối chiếu WF ↔ SRS ↔ UICONV** *(chỉ `screen`)* — in: tập `C-id` lệch hai chiều (phải rỗng) ·
số dòng §5 của WF theo loại và số dòng chưa có người quyết · mục nào của SRS định nghĩa lại
thứ đã có trong `UICONV` mà không có dòng ở `UICONV` §12 · WF đang ở chế độ 🎨 hay ✏️ và
Designer đã ký chưa.

Với `PRODUCT = screen`, nhắc thêm: G3 còn ba dòng *(screen · design)* do `/ba-design` đảm nhiệm — chưa có
`DS`/`HIFI`/`DSPEC` thì G3 chưa đủ điều kiện ở `standard`+.

Nhắc chữ ký theo `RIGOR` (`../ba-lifecycle/references/workflow.md` §2 — G3):
`light` không cần chữ ký QA · `standard` cần **PO + Tech Lead + QA** · `strict` thêm
**Bảo mật/Pháp chế**, và API **phải do BE xác nhận**, không chấp nhận contract BA tự đề xuất.
Ở mức `standard` trở lên, QA phải xác nhận *mọi AC đều test được*.
`PRODUCT = screen` ở `standard`+ thêm **Designer** ký `UICONV` và `WF` (WF ở chế độ 🎨 thì
Designer đã duyệt prototype, chỉ cần PO xác nhận bản đồ §1 và §5 không còn lệch mở).

## Bẫy thường gặp

**Viết AC chỉ cho luồng thành công.** Chiếm khoảng một nửa số spec kém. Luồng lỗi mới là
chỗ dev tự bịa và mỗi người bịa một kiểu.

**Copy field spec từ US khác mà không rà lại.** Độ dài, default, message hay bị mang theo
sai. Mỗi field phải truy về một `BR` hoặc một câu trả lời của stakeholder.

**Mô tả hành vi bằng ảnh.** Wireframe minh hoạ bố cục; hành vi nằm ở bảng thành phần và AC
(quy tắc W11). Viết "xem hình" ở cột hành vi là chưa đặc tả.

**Chép prototype vào SRS.** Prototype có nút mà backlog không có ⇒ đó là scope creep bằng hình
ảnh. Ghi vào WF §5, để PO quyết, không tự thêm thành phần vào bảng SRS.

**Mỗi SRS tự đặt quy ước.** Phân trang, vị trí toast, định dạng ngày phải tham chiếu `UICONV`.
Ba SRS với ba kiểu phân trang là ba màn hình người dùng phải học lại.

**WF không có bảng lệch.** WF chỉ có hình mà không có §5 là chưa đối chiếu — và đúng chỗ
prototype khác SRS là chỗ dev sẽ tự chọn một bên.

**Trộn "ẩn" với "disable".** Ba trạng thái khác nhau (W7), và người dùng phản ứng rất khác:
nút biến mất làm họ tưởng mất quyền, nút mờ có tooltip làm họ hiểu vì sao chưa bấm được.

**Đặc tả quá nhiều US một lượt.** Quá 3 US thì các bảng bắt đầu sơ sài và mâu thuẫn chéo
không ai phát hiện. Chia nhỏ.

**Bịa giá trị cho chỗ chưa hỏi được.** 255 ký tự, timeout 30 giây, giữ log 90 ngày — những
con số này nghe hợp lý nên không ai chất vấn, và sai thì phát hiện rất muộn. Ghi `OQ`.

**Quên rằng SRS phải nói cả cái nó KHÔNG làm.** Mục "Ngoài phạm vi" (W12) chặn dev làm thừa
và chặn PO tưởng đã có.