update skill ba

.claude/skills/ba-lifecycle/SKILL.md

@@ -72,7 +72,10 @@ file tồn tại nhưng các mục còn `TBD` ⇒ **chưa đạt**, không đư
 tồn tại và có chữ ký Designer · `WF` phủ mọi SCR, `C-id` khớp hai chiều · `WF` §5 không còn lệch
 Tồn tại/Hành vi chưa quyết · WF ✏️ có Designer ký) chỉ áp cho `PRODUCT = screen`. Loại khác
 dùng tiêu chí ghi ở đầu file `ba-3-specification/templates/srs-part2/<loại>.md`.
-Khi chấm G3 cho `screen`, mở cả `00-index/UICONV_*.md` và `03-specification/WF_*.md`.
+Khi chấm G3 cho `screen`, mở cả `00-index/UICONV_*.md` và `03-specification/WF_*.md`; ba dòng *(screen · design)*
+đọc `00-index/DS_*.md`, `03-specification/design/DSPEC_*.md` (§6 có kết quả `design-check`) và kiểm `HIFI_*.html`,
+`FIGMA_*/` tồn tại. Chạy được `node .claude/skills/ba-design/scripts/design-check.mjs …` thì chép kết quả thật;
+không chạy được ⇒ ghi "chưa kiểm bằng máy", không đoán ✅.
 
 Ba trạng thái, không có trạng thái thứ tư:
 
@@ -135,6 +138,7 @@ G3 vì thiếu bảng mã lỗi và 3 OQ chưa trả lời."*
 1. Trả lời OQ-012, OQ-013 (chờ PO)          → /ba-4-delivery-support US059
 2. Bổ sung bảng mã lỗi vào SRS §1.A.4       → /ba-3-specification US059
 3. Chạy kiểm tra coverage trước khi trình G3 → /ba-traceability US059
+4. (screen) Sinh DS/HIFI/FIGMA sau khi WF xong      → /ba-design US059 hifi
 ```
 
 **④ Cảnh báo** — OQ quá hạn, artifact lệch version, US có trong backlog nhưng chưa có SRS,

.claude/skills/ba-lifecycle/references/artifact-map.md

@@ -19,6 +19,10 @@
 | `NFR` | Yêu cầu phi chức năng | `03-specification/` | ba-3 | Dev, Ops, QA |
 | `WF` | Wireframe & bố cục (`.md` bảng vùng/thành phần/lệch + `.html` low-fi) — chỉ `PRODUCT = screen` | `03-specification/` | ba-3 (activity `wf`) | Dev FE, Designer, PO |
 | `UICONV` | Quy ước giao diện cấp project — chỉ `PRODUCT = screen`, sinh một lần | `00-index/` | ba-3 (activity `uiconv`) | Dev FE, Designer, mọi SRS/WF |
+| `DS` | Design system cấp project (`.md` + `ds/tokens.json` chuẩn W3C DTCG, `ds/tokens.css`, `ds/components.html`) — chỉ `PRODUCT = screen`, sinh một lần | `00-index/` | ba-design (activity `ds`) | Dev FE, Designer, mọi HIFI/FIGMA |
+| `HIFI` | Mockup hi-fi tự chứa (`.html`: mọi `SCR` × trạng thái × breakpoint, chế độ prototype bấm được) — chỉ `screen` | `03-specification/design/` | ba-design (`hifi`, `proto`) | Dev FE, Designer, PO |
+| `FIGMA` | Gói nhập Figma (thư mục: SVG mỗi `SCR` × khung nhìn, `tokens.dtcg.json`, `png/`, `README-import.md`) — chỉ `screen`; **không có `.fig`** | `03-specification/design/` | ba-design (`figma`) | Designer |
+| `DSPEC` | Đặc tả thiết kế & bàn giao (redline, ánh xạ component, truy cập, bảng lệch HIFI ↔ WF/SRS/DS) — chỉ `screen` | `03-specification/design/` | ba-design (`dspec`) | Dev FE, QA (review giao diện) |
 | `QLOG` | Clarification log | `04-delivery/` | ba-4 | Dev, QA |
 | `CR` | Change Request | `04-delivery/` | ba-4 | PO, PM, Dev |
 | `TCREVIEW` | Biên bản review test case | `04-delivery/` | ba-4 | QA |
@@ -56,6 +60,10 @@ Mọi file `.md` sinh ra phải mở đầu bằng khối này. Thiếu một d
 | 1.0 | 2026-08-30 | … | Bản đầu | — |
 ```
 
+Artifact **không phải `.md`** (`WF_*.html`, `HIFI_*.html`, thư mục `FIGMA_*/`, `ds/*`) không có header riêng:
+trạng thái duyệt của chúng nằm ở artifact `.md` đi kèm (`WF.md` cho `WF.html`; `DSPEC` cho `HIFI` và `FIGMA`;
+`DS.md` cho `ds/*`). Gate chấm file `.md` đó, và kiểm file kèm có tồn tại + qua `design-check`.
+
 **Ý nghĩa `Status`** — đây là thứ gate đọc, không phải tên file:
 
 | Status | Nghĩa | Ai được sửa file |
@@ -134,17 +142,31 @@ flowchart LR
     SRS --> WF
     PROTO[["Prototype / design system (ngoài bộ BA)"]] -.-> UICONV
     PROTO -.-> WF
+    UICONV --> DS["DS"]
+    BRAND[["Brand guideline (ngoài bộ BA)"]] -.-> DS
+    PROTO -.-> DS
+    DS --> HIFI["HIFI"]
+    WF --> HIFI
+    SRS --> HIFI
+    HIFI --> FIGMA["FIGMA"]
+    HIFI --> DSPEC["DSPEC"]
+    DS --> FIGMA
     AC --> UAT["UAT"]
     UAT --> BENEFIT["BENEFIT"]
     UAT --> RELNOTE["RELNOTE"]
     UAT --> MANUAL["MANUAL"]
 ```
 
-**RTM đọc:** `BRIEF`(RQ) · `BACKLOG`(US) · `SRS`+`AC`(AC, field, mã lỗi) · `WF`(C-id, SCR) · `UAT`(test case) · `CR`
+**RTM đọc:** `BRIEF`(RQ) · `BACKLOG`(US) · `SRS`+`AC`(AC, field, mã lỗi) · `WF`(C-id, SCR) · `HIFI`(`data-c`, `data-key`, `SCR`) · `DS`(token) · `UAT`(test case) · `CR`
 
 `WF` và `UICONV` chỉ tồn tại khi `PRODUCT = screen`. `WF` **không** là nguồn sự thật về hành
 vi — nó tham chiếu ngược về `SRS`; đổi prototype ⇒ đổi `WF`, `SRS` chỉ đổi khi lệch loại
 Tồn tại/Hành vi được PO chấp nhận (qua `CR` nếu SRS đã Baselined).
 
+`DS`, `HIFI`, `FIGMA`, `DSPEC` cũng chỉ tồn tại khi `PRODUCT = screen` và do `ba-design` sinh **sau** `WF`.
+`HIFI` **không** là nguồn sự thật về hành vi hay text — nó *chép* từ `SRS` (`design-check` H3/H4 kiểm); `DS` là
+nguồn sự thật về visual (token). Đổi brand ⇒ đổi `DS` ⇒ chạy lại mọi `HIFI`/`FIGMA`; đổi `SRS`/`WF` ⇒ chạy lại
+`HIFI` → `FIGMA` → `DSPEC` của US đó.
+
 Đọc xuôi mũi tên để biết **sửa cái này thì phải sửa tiếp cái nào**. Ví dụ sửa một `BR` ⇒
 phải rà lại `SRS`, `AC`, test case, và cập nhật `RTM`.

.claude/skills/ba-lifecycle/references/domain-profiles.md

@@ -66,6 +66,7 @@ Trục quan trọng nhất. Nó quyết định **GĐ3 viết cái gì**.
 | **GĐ3** PART 2 | Màn hình, field | Endpoint, schema | Luồng dữ liệu, data contract | Bài toán, metric, ngưỡng | Job, lịch, chạy lại | ❌ N/A |
 | **GĐ3** `AC` | 4 nhóm đầy đủ | 4 nhóm đầy đủ | 4 nhóm + **đối soát nguồn–đích** | 🔴 Chỉ áp cho hệ thống bao quanh; phần dự đoán dùng **ngưỡng metric** | 4 nhóm + **chạy lại** | Tiêu chí quy trình |
 | **GĐ3** text hiển thị | Bắt buộc | N/A | N/A | Chỉ phần hiển thị cho người | N/A | N/A |
+| **GĐ3** design (`ba-design`: `DS`, `HIFI`, `FIGMA`, `DSPEC`) | Bắt buộc ở `standard`+ | ❌ N/A | ❌ N/A | Chỉ phần màn hình cho người (nếu có) | ❌ N/A | ❌ N/A |
 | **GĐ4** UAT | Người dùng thao tác | Team tiêu thụ tích hợp thử | Đối soát số liệu song song | 🔴 Đánh giá trên tập giữ lại + shadow mode | Chạy song song với cách cũ | Chạy thử quy trình |
 | **GĐ5** `MANUAL` | Cho người dùng cuối | **Tài liệu tích hợp** cho dev | Từ điển dữ liệu + hướng dẫn đọc số | Hướng dẫn diễn giải kết quả | Sổ tay vận hành | Quy trình mới |
 
@@ -116,7 +117,7 @@ Quyết định **gate chặt tới đâu và ai phải ký**. `standard` là ba
 | Giá trị | Dùng khi | Ký gate |
 |---|---|---|
 | `light` | POC, thử nghiệm, công cụ nội bộ ≤ 2 tuần, không đụng tiền/dữ liệu cá nhân | Chỉ PO |
-| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate); `PRODUCT = screen` thêm **Designer ở G3** (`UICONV`, `WF`) |
+| `standard` | Mặc định — sản phẩm thật, có người dùng thật | PO + Tech Lead + QA (theo từng gate); `PRODUCT = screen` thêm **Designer ở G3** (`UICONV`, `WF`, và `DS`/`HIFI`/`DSPEC` do `ba-design` sinh) |
 | `strict` | Có tiền, dữ liệu cá nhân, yêu cầu pháp lý, chịu kiểm toán (tài chính, y tế, bảo hiểm) | Như standard **+ Bảo mật/Pháp chế ở G2 và G3** |
 
 Chi tiết tiêu chí bớt/thêm theo từng gate: [workflow.md §2.0](workflow.md).

.claude/skills/ba-lifecycle/references/workflow.md

@@ -28,6 +28,9 @@ flowchart TD
 
 `ba-traceability` chạy song song, cập nhật RTM sau mỗi giai đoạn và **có quyền chặn G2, G3, G4**.
 
+`ba-design` (vai Design của bộ skill) chạy **song song GĐ3** khi `PRODUCT = screen`, sau activity `wf` của ba-3:
+sinh `DS` (một lần/project), `HIFI`, `FIGMA`, `DSPEC` cho từng US. Artifact của nó **ký cùng G3**, không có gate riêng.
+
 ## 2.0 Mức nghiêm ngặt — đọc trước §2
 
 Checklist ở §2 là **baseline của mức `standard`**. Hai mức còn lại là delta so với nó:
@@ -103,16 +106,20 @@ giải quyết được pain point đã ghi ở G1.
 - [ ] *(screen)* `WF_<US>` (md + html) phủ **mọi** `SCR` của SRS; tập `C-id` khớp **hai chiều** với bảng thành phần
 - [ ] *(screen)* `WF` §5 (lệch prototype ↔ SRS) đã điền; không còn lệch **Tồn tại/Hành vi** chưa có người quyết
 - [ ] *(screen)* `WF` chế độ ✏️ (BA tự dựng) có chữ ký Designer; chế độ 🎨 (prototype tham chiếu) có PO xác nhận §1 và §5
+- [ ] *(screen · design)* `DS_<PROJECT>` tồn tại; `design-check` T1/T2 đạt (token ↔ `tokens.css` khớp, mọi cặp chữ/nền ≥ 4.5); §0 ghi độ tin cậy visual; có chữ ký Designer (hoặc PO + `DEC-nn`)
+- [ ] *(screen · design)* `HIFI_<US>` phủ **mọi** `SCR` × trạng thái SRS §2.3.6 × (desktop + mobile); `design-check` H1–H5 đạt: `data-c`/`data-f` khớp **hai chiều** SRS, text `data-key` **nguyên văn** SRS §4.2, không mã màu thô
+- [ ] *(screen · design)* `FIGMA_<US>/` có SVG desktop + mobile cho mọi `SCR`, màu ⊆ token (`design-check` S1); `DSPEC_<US>` §6 đã điền, không còn lệch Tồn tại/Hành vi/Text với SRS
 - [ ] QA xác nhận **mọi AC đều test được** — AC không test được là AC chưa viết xong
 - [ ] Không còn `OQ` mở nào ảnh hưởng tới hành vi hệ thống
 - [ ] `ba-traceability` báo coverage US→AC và AC→test case ≥ 100%, và *(screen)* SRS↔WF `C-id` lệch = 0
 
 **Chặn:** còn bất kỳ `TBD` nào trong bảng field hoặc bảng mã lỗi. Còn `OQ` mở về hành vi.
-*(screen)* Còn lệch Tồn tại/Hành vi giữa prototype và SRS chưa quyết.
+*(screen)* Còn lệch Tồn tại/Hành vi giữa prototype và SRS chưa quyết. *(screen · design)* `HIFI` có thành phần
+không có trong SRS mà không bọc `hf-proto-only`, hoặc text `data-key` khác SRS §4.2.
 **Đây 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.
 
-> Checklist trên viết theo `PRODUCT = screen`. Loại khác thì dòng "bảng field" và bốn dòng
-> *(screen)* được thay bằng tiêu chí tương ứng của biến thể PART 2 — xem đầu file
+> Checklist trên viết theo `PRODUCT = screen`. Loại khác thì dòng "bảng field", bốn dòng *(screen)*
+> và ba dòng *(screen · design)* được thay bằng tiêu chí tương ứng của biến thể PART 2 — xem đầu file
 > `ba-3-specification/templates/srs-part2/<loại>.md`.
 
 | Bớt ở `light` | Thêm ở `strict` |
@@ -121,6 +128,7 @@ giải quyết được pain point đã ghi ở G1.
 | `NFR` chỉ bắt buộc nhóm áp dụng rõ ràng; các nhóm khác ghi "N/A — POC" | Mọi mã lỗi phải có bản dịch đủ mọi ngôn ngữ hỗ trợ, không được để sau |
 | `API` được phép là phác thảo, không cần bảng đối chiếu mã lỗi | `API` phải do BE xác nhận, **không chấp nhận contract BA tự đề xuất** |
 | *(screen)* `WF` chỉ cần bảng vùng + bảng lệch, không cần HTML; `UICONV` chỉ cần §3–§6, §8 | *(screen)* `WF` phải có responsive đủ mọi breakpoint của `UICONV` §1 và thứ tự focus cho mọi form |
+| *(screen · design)* `HIFI`/`FIGMA` không bắt buộc; `DS` chỉ cần §1 token + §3 ánh xạ; `DSPEC` bỏ | *(screen · design)* `HIFI` đủ cả tablet; tương phản AA cho **mọi** cặp kể cả badge/trạng thái; `DSPEC` §5 mọi dòng có bằng chứng; `FIGMA` có PNG mọi trạng thái |
 | Không cần chữ ký QA; Designer không bắt buộc (PO ký `WF`) | Ký: PO + Tech Lead + QA + Designer + Bảo mật/Pháp chế |
 
 ### G4 — UAT pass · duyệt bởi **PO**
@@ -167,17 +175,19 @@ cách một POC mang theo mọi thiếu sót của nó vào sản phẩm thật.
 | **PO / Khách hàng** | Quyết ưu tiên và scope. Ký G1, G4, G5. Trả lời `OQ` nghiệp vụ |
 | **Tech Lead** | Ký G2, G3 về mặt khả thi. Quyết kiến trúc. Trả lời `OQ` kỹ thuật |
 | **QA** | Ký G3 về tính test được. Viết test case từ AC. Chủ trì thực thi UAT |
-| **Designer** *(khi `PRODUCT = screen`)* | Sở hữu prototype, design system, visual. Ký `UICONV` và `WF` ở G3. Trả lời lệch loại *Bố cục* ở `WF` §5. Nhận từ BA: kho thành phần, text nguyên văn, trạng thái, phân quyền hiển thị — **không phải đi hỏi lại nghiệp vụ** |
+| **Designer** *(khi `PRODUCT = screen`)* | Sở hữu prototype, design system, visual. Ký `UICONV`, `WF`, `DS`, `HIFI`, `DSPEC` ở G3. Trả lời lệch loại *Bố cục* ở `WF` §5 và `DSPEC` §6. Nhận từ BA: kho thành phần, text nguyên văn, trạng thái, phân quyền hiển thị — **không phải đi hỏi lại nghiệp vụ**. Nhận từ `ba-design`: `DS`/`HIFI`/`FIGMA` làm **đề xuất** để sửa trong Figma, không dựng lại từ đầu |
+| **`ba-design`** *(vai Design của bộ skill, `screen`)* | Sinh `DS`, `HIFI`, `FIGMA`, `DSPEC` từ `SRS`+`WF`+`UICONV` (+ brand). **Đề xuất**, không duyệt: mọi artifact 🟡 Draft chờ Designer ký. Không quyết hành vi/text (chép từ SRS), không bịa brand (thiếu ⇒ token trung tính + `OQ`, độ tin cậy 🔴) |
 | **Dev** | Tiêu thụ SRS + WF + UICONV. Đặt `OQ` qua `QLOG` |
 | **PM** | Tiến độ, nguồn lực. Không ký gate nội dung |
 
 BA **không** thay PO quyết ưu tiên, **không** thay Tech Lead chọn kiến trúc, **không** thay
 PM quản tiến độ, **không** thay Designer quyết visual — nhưng phải cung cấp đủ thông tin để
-cả bốn ra quyết định. Riêng phần **bố cục và trạng thái**, BA làm được khi có prototype tham
+cả bốn ra quyết định. Riêng visual: `ba-design` **đề xuất** (token, HIFI), Designer **quyết**. Riêng phần **bố cục và trạng thái**, BA làm được khi có prototype tham
 chiếu (chế độ 🎨 của `WF`); không có thì BA đề xuất, Designer quyết (chế độ ✏️).
 
-**Dự án không có Designer:** ghi `DEC-nn`, PO ký thay `UICONV`/`WF`, và mục §6 của `WF`
-("Designer còn phải làm") chuyển thành việc của dev FE — nêu đích danh.
+**Dự án không có Designer:** ghi `DEC-nn`, PO ký thay `UICONV`/`WF`/`DS`/`HIFI`/`DSPEC`, và mục §6 của `WF`
+("Designer còn phải làm") là **việc của `ba-design`** (sinh `DS` + `HIFI` + `FIGMA` + `DSPEC`) — không đẩy sang
+dev FE. Dev FE chỉ nhận phần `DSPEC` §7 "Bàn giao".
 
 ## 4. Khi nào được bỏ giai đoạn