@educa-corp/sdd-framework 0.9.6 → 0.9.8

package/core/skills/qc/qa-reviewer/script/exploratory.md

@@ -13,7 +13,7 @@ Review session note sau khi test, coaching QC cải thiện kỹ năng.
 - Khi lead/senior muốn đánh giá chất lượng session của junior
  
 ## Khi KHÔNG trigger
-- Review Python script → dùng qa-reviewer/script/functional
+- Soát script tự động → dùng `web/functional.md` · `mobile/functional.md` · `api/endpoint.md` theo nền
 - Review charter → dùng qa-reviewer/test-case/exploratory
  
 ---
@@ -41,13 +41,13 @@ Review session note sau khi test, coaching QC cải thiện kỹ năng.
  
 **Điểm `XX/100`** — ánh xạ mức độ sang điểm trừ: 🔴 = `FAIL` (−5đ) · 🟠 = `WARN` (−2đ) ·
 🟡 = ghi nhận, không trừ. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
-**Verdict:** `≥80` VÀ không còn 🔴 → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+**Verdict:** suy từ **số đếm lỗi** theo `../shared/review-file-template.md` §Verdict — `≥1 BLOCKER` → `REJECTED` · `≥1 MAJOR` → `REVISION_REQUIRED` · chỉ MINOR/SUGGESTION → `APPROVED_WITH_SUGGESTIONS` · sạch → `APPROVED`.
 
 **Ghi vào `{qc_artifact_dir}test-cases/REVIEW_<FEATURE>.md`** — thêm một hàng vào bảng Tổng quan
 (cột `Tầng` phân biệt vai soát-code với vai soát-kịch-bản; **không ghi đè** hàng của vai kia).
 Khuôn + quy tắc ghi: `../shared/review-file-template.md`.
 
-**KHÔNG tự sửa code** — chỉ nêu `file:line` + cách sửa. Người sửa là `/qc-run-test`.
+**KHÔNG tự sửa code** — chỉ nêu `file:line` + cách sửa. Người sửa là `/qc-design-script`.
 Mỗi tiêu chí: ✅/⚠️/❌ + feedback cụ thể
 Top 3 improvement suggestions (coaching tone)
 Đề xuất charter tiếp theo nếu chưa đủ coverage

package/core/skills/qc/qa-reviewer/script/mobile/e2e.md

@@ -0,0 +1,41 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Mobile-Automation-Standards.md §5 §9 §11 (Approved)
+---
+
+# Soát script — Mobile E2E *(hành trình xuyên nhiều màn app)*
+
+**Nạp `../_shared/review-rules.md` rồi `functional.md` cùng nền.**
+
+## Khi nào trigger
+- Soát script đi trọn một hành trình trong app, qua nhiều màn.
+
+---
+
+## Thêm gì so với functional
+
+### A · Một hành trình = một test
+
+- Chia thành nhiều `it()` phụ thuộc nhau ⇒ **BLOCKER** — chạy riêng lẻ là fail
+- Chia chặng bằng `describe`/step để report Allure đọc được; >5 thao tác mà không chia ⇒ **MINOR**
+
+### B · Điều hướng và trạng thái app
+
+- Quay lại bằng `driver.back()` mà không assert đã về đúng màn ⇒ **MAJOR**
+- Không reset app giữa các hành trình *(`driver.reset()` hoặc fixture)* ⇒ **MAJOR** — trạng thái rò
+
+### C · Gesture trong hành trình dài
+
+- Cuộn tìm phần tử phải có **giới hạn số lần**; cuộn vô hạn ⇒ **MAJOR** *(treo cho tới timeout)*
+
+### D · Flaky *(§11)*
+
+- E2E mobile là nơi flaky sống nhất *(mạng + emulator + animation)*. Test đỏ-xanh thất thường mà
+  không tag `@flaky` ⇒ **MAJOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/script/mobile/functional.md

@@ -0,0 +1,90 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Mobile-Automation-Standards.md §4 §6 §7 §8 §9 §10 §11 §12 (Approved)
+---
+
+# Soát script — Mobile Functional *(WebdriverIO + Appium + TypeScript)*
+
+**Nạp `../_shared/review-rules.md` trước.** File này chỉ có phần riêng của nền app.
+
+> ⚠️ **Đây KHÔNG phải bản web đổi tên.** Chuẩn mobile khác web ở bốn chỗ có thật: thứ tự locator,
+> gesture, đối chiếu dữ liệu server, và kiểm môi trường. Soát mobile bằng checklist web là bỏ sót cả bốn.
+
+## Khi nào trigger
+- Soát script functional cho nền `app` (`app-ios` · `app-android`), sau `/qc-design-script`.
+
+## Khi KHÔNG trigger
+- Nền `web` → `../web/functional.md` · nền `system` → `../api/endpoint.md`
+
+---
+
+## Phase 1 — Đọc đủ *(R01)*
+
+1. `mobile-automation/tests/{TICKET-ID}/<feature>-*.spec.ts`
+2. `mobile-automation/screens/<feature>.screen.ts` + `base.screen.ts`
+3. `helpers/{api,device,gesture}.helper.ts` nếu spec dùng
+4. `wdio.config.ts` · `.env.example` — biết thiết bị và endpoint
+5. `.Test.md` + `AUTOMATION_ASSESSMENT.md`
+
+**R07 chặn cửa** như mọi lane.
+
+---
+
+## Phase 2 — Sáu nhóm soát của nền app
+
+### A · Screen Object *(§4)* — KHÔNG gọi là Page
+
+- `extends BaseScreen`; class `<Feature>Screen`; file `<feature>.screen.ts`
+- Đặt tên `Page`/`page.ts` ở nền app ⇒ **MINOR** nhưng phải sửa — làm người sau tra nhầm chuẩn
+- Không `expect()` trong Screen Object ⇒ **MAJOR**
+
+### B · Locator *(§7.1)* — thứ tự KHÁC HẲN web
+
+```
+~accessibilityId  →  id (resource-id)  →  xpath (cuối cùng, phải ghi lý do)
+```
+
+- Dùng `getByRole` / `getByLabel` *(của web)* ⇒ **BLOCKER** — không tồn tại ở Appium
+- `xpath` không kèm comment lý do ⇒ **MAJOR**
+- `~accessibilityId` yêu cầu dev gán `content-desc`; locator trỏ id chưa có trong bảng §4.5.6
+  ⇒ **MAJOR** kèm đề nghị bổ sung vào tech-doc
+
+### C · Gesture *(§9)*
+
+- Vuốt/cuộn viết tay bằng toạ độ **rải trong spec** ⇒ **MAJOR** — phải qua `helpers/gesture.helper.ts`
+- Toạ độ hard-code không kèm ghi chú độ phân giải ⇒ **MINOR**: đúng trên một máy, sai trên máy khác
+
+### D · Đối chiếu dữ liệu server *(§6)*
+
+- Spec `*-api-sync.spec.ts` phải dùng `helpers/api.helper.ts` *(Playwright `request`)*
+- Chỉ assert trên màn hình, không đối chiếu server ⇒ **MAJOR**: một màn hiển thị đúng **dữ liệu cũ**
+  vẫn là bug, và UI assertion không bắt được
+
+### E · Wait *(§8)* và độ ổn định
+
+- `browser.pause(...)` cứng ⇒ **MAJOR**; dùng `waitForDisplayed({ timeout })`
+- Luồng có dialog quyền mà spec không xử lý ⇒ **MAJOR** — nó nuốt thao tác đầu tiên
+
+### F · Môi trường *(§12 — Gate 6B)*
+
+- Đọc `API_BASE_URL` từ `.env`, hard-code ⇒ **MAJOR**
+- Spec giả định emulator/APK sẵn sàng: **không** phải lỗi của spec, nhưng biên bản phải nhắc
+  checklist §12 chạy **trước** lượt execute
+
+---
+
+## Phase 3 — Kiểm cơ học
+
+```
+npx tsc --noEmit
+npx wdio ./wdio.config.ts --dry-run
+```
+
+Số test phải bằng số TC `Automatable: Y`. Lệch ⇒ **BLOCKER**.
+
+---
+
+## Output
+
+Theo `_shared/review-rules.md` §3, kèm ≥2–3 điểm tốt *(R05)*.

package/core/skills/qc/qa-reviewer/script/mobile/integration.md

@@ -0,0 +1,41 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Mobile-Automation-Standards.md §5.3 §6 §8 (Approved)
+---
+
+# Soát script — Mobile Integration *(app ↔ backend)*
+
+**Nạp `../_shared/review-rules.md` rồi `functional.md` cùng nền.** Đây là phần thêm.
+
+## Khi nào trigger
+- Soát script kiểm app **giao tiếp với server thật**: gửi lên, nhận về, đồng bộ sau thao tác.
+
+---
+
+## Thêm gì so với functional
+
+### A · `*-api-sync.spec.ts` là tầng này, không phải functional
+
+- Chuẩn tách hẳn một loại spec cho việc này *(§5.3)*. Trộn kiểm đồng bộ vào spec functional
+  ⇒ **MINOR** — nhưng phải tách, vì hai loại có điều kiện môi trường khác nhau
+
+### B · Hai phía phải cùng được assert
+
+- Thao tác trên app → assert UI **và** gọi `api.helper.ts` kiểm bản ghi trên server
+- Chỉ một phía ⇒ **MAJOR**
+
+### C · Trạng thái mạng
+
+- Không kiểm nhánh mất mạng / timeout khi `.Test.md` có ⇒ **MAJOR**
+- Dùng `browser.setNetworkConditions` hoặc cơ chế tương đương, không mock ở tầng UI
+
+### D · Dọn dữ liệu
+
+- Bản ghi tạo qua app phải được xoá qua API trong `after`, kể cả khi test fail ⇒ thiếu là **MAJOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/script/mobile/non-functional.md

@@ -0,0 +1,43 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Mobile-Automation-Standards.md §8 §11 §12 (Approved)
+---
+
+# Soát script — Mobile Non-Functional
+
+**Nạp `../_shared/review-rules.md` rồi `functional.md` cùng nền.**
+
+## Khi nào trigger
+- Soát script kiểm thuộc tính phi chức năng của app: thời gian mở màn, bộ nhớ, quyền, đa thiết bị.
+
+---
+
+## Thêm gì so với functional
+
+### A · Ngưỡng là con số
+
+- Assert hiệu năng không có ngưỡng cụ thể ⇒ **BLOCKER**
+- Đo thời gian mở màn bằng mốc **sự kiện** *(`waitForDisplayed` trả về)*, không bằng `pause` rồi trừ
+
+### B · Quyền và bảo mật
+
+- Kiểm từ chối quyền: phải assert app **xử lý được**, không crash ⇒ assert yếu ⇒ **MAJOR**
+- Credential/token thật trong code ⇒ **BLOCKER**; đọc từ `.env`
+
+### C · Đa thiết bị
+
+- Chạy đa cấu hình bằng **capabilities trong `wdio.config.ts`**, không lặp tay trong spec
+  ⇒ lặp tay ⇒ **MAJOR**
+- Chỉ một emulator rồi gọi là kiểm tương thích ⇒ **MAJOR**
+
+### D · Môi trường *(§12)*
+
+- Kết quả phi chức năng **không có nghĩa** nếu checklist Gate 6B chưa chạy. Biên bản phải nêu
+  đã chạy hay chưa; không nêu ⇒ **MINOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/script/web/e2e.md

@@ -0,0 +1,46 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Automation-Standards.md §5 §11 (Approved)
+---
+
+# Soát script — Web E2E *(hành trình xuyên nhiều màn)*
+
+**Nạp `../_shared/review-rules.md` trước**, rồi `functional.md` cùng nền.
+
+## Khi nào trigger
+- Soát script đi **trọn một hành trình người dùng** qua nhiều màn, nhiều vai.
+
+## Khi KHÔNG trigger
+- Một màn → `functional.md` · hai thành phần → `integration.md`
+
+---
+
+## Thêm gì so với functional
+
+### A · Hành trình phải là một test
+
+- Chia hành trình thành nhiều `test()` phụ thuộc nhau ⇒ **BLOCKER** — chạy riêng lẻ là fail,
+  và Playwright **không bảo đảm thứ tự** khi chạy song song
+- Một hành trình = một `test()`, các chặng chia bằng `test.step()` để report đọc được
+- Thiếu `test.step()` cho hành trình >5 thao tác ⇒ **MINOR** — fail ở đâu không ai biết
+
+### B · Vai và phiên
+
+- Đổi vai giữa chừng phải qua `storageState` riêng hoặc `browser.newContext()`, **không**
+  logout/login trong cùng context ⇒ làm sai ⇒ **MAJOR** *(rò trạng thái giữa hai vai)*
+
+### C · Độ dài và chi phí
+
+- Hành trình >15 chặng mà không tách được ⇒ **MINOR** kèm đề nghị tách; E2E dài là E2E flaky
+- E2E **không** kiểm lại thứ functional đã kiểm — trùng lặp ⇒ **SUGGESTION**
+
+### D · Flaky
+
+- E2E là nơi flaky sống *(§11)*. Không có tag `@flaky` cho test đã đỏ-xanh thất thường ⇒ **MAJOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/script/web/functional.md

@@ -0,0 +1,111 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Automation-Standards.md §4 §6 §7 §8 §9 §10 §11 (Approved)
+---
+
+# Soát script — Web Functional *(Playwright Test + TypeScript)*
+
+**Nạp `../_shared/review-rules.md` trước.** File này chỉ có phần riêng của nền web, tầng
+functional.
+
+## Khi nào trigger
+- Soát script cho TC functional (1 màn hoặc đa màn) của một PRD, nền `web`, sau `/qc-design-script`.
+
+## Khi KHÔNG trigger
+- Nền `app` → `../mobile/functional.md` · nền `system` → `../api/endpoint.md`
+- Soát **test case** *(không phải code)* → `/qc-review-testcase`
+- Soát biên bản exploratory → `../exploratory.md`
+
+---
+
+## Phase 1 — Đọc đủ trước khi soát *(R01)*
+
+1. `automation/tests/{TICKET-ID}/<feature>-*.spec.ts` — **mọi** spec của feature
+2. `automation/pages/<feature>.page.ts` + `base.page.ts`
+3. `automation/data/<feature>.data.ts` · `fixtures/*.fixture.ts` nếu spec có dùng
+4. `.Test.md` gốc + `AUTOMATION_ASSESSMENT.md` — để đếm TC `Automatable: Y`
+
+**R07 chặn cửa:** spec thiếu header artifact ID / `@trace.verifies` ⇒ **BLOCKER, dừng soát.**
+
+---
+
+## Phase 2 — Bảy nhóm soát của nền web
+
+### A · Page Object *(§4)*
+
+- Có `extends BasePage`? Không kế thừa là chép lại method dùng chung → **MAJOR**
+- **Không `expect()` trong Page Object** — assertion thuộc spec. Có ⇒ **MAJOR**
+- Method 1 việc, đặt tên **camelCase động từ trước**: `login()` · `fillEmail()` ⇒ sai tên là MINOR
+- Class `PascalCase` + hậu tố `Page`: `LoginPage` · file `kebab-case`: `login.page.ts`
+- Locator khai **trong** Page Object, **không** hard-code trong spec ⇒ trong spec là **BLOCKER**
+
+### B · Locator *(§6.1 · §6.2)*
+
+Thứ tự ưu tiên bắt buộc:
+
+```
+getByRole → getByLabel → getByPlaceholder → getByTestId → getByText → locator('[css]')
+```
+
+- `locator('[css]')` mà **không có comment nêu lý do** ⇒ **MAJOR**
+- Locator bám **class CSS tự sinh** (`.css-1x2y3z`, `.MuiBox-root-42`) ⇒ **MAJOR**
+- XPath ⇒ **MAJOR** *(web có đủ 5 cách tốt hơn)*
+- `.first()` / `.nth(n)` không kèm lý do ⇒ **MINOR** — vị trí đổi là test đổi
+- **test-id lấy từ bảng §4.5.6 của tech-doc**, không dò DOM lúc chạy. Dò DOM ⇒ **MAJOR**
+- Thuộc tính test-id ≠ `data-testid` mà **thiếu** `use: { testIdAttribute: '…' }` trong
+  `playwright.config.ts` ⇒ **BLOCKER** — `getByTestId()` sẽ trượt **100 %**, và nó trượt trông
+  **y hệt một bug sản phẩm**
+
+### C · Assertion *(§7)*
+
+- Dùng **web-first assertion** `await expect(locator).toBeVisible()` — tự retry
+- `expect(await locator.isVisible()).toBe(true)` ⇒ **MAJOR**: chụp giá trị một lần, mất auto-retry
+- Chỉ assert URL mà không assert nội dung ⇒ **MINOR** — điều hướng đúng không có nghĩa hiển thị đúng
+- `expect(true).toBe(true)` hoặc assert không thể sai ⇒ **BLOCKER** *(test xanh giả)*
+- Thiếu assertion âm cho nhánh lỗi mà `.Test.md` có ⇒ **MAJOR**
+
+### D · Wait *(§8)*
+
+- `waitForTimeout(…)` ⇒ **MAJOR** — chờ cứng, hỏng theo tốc độ máy
+- Chờ theo **điều kiện**: `expect(...).toBeVisible()` · `waitForResponse` · `waitForURL`
+- Timeout tự đặt < 3 s hoặc > 30 s mà không nêu lý do ⇒ **MINOR**
+
+### E · Test structure *(§5)*
+
+- Mỗi test **độc lập**: chạy riêng lẻ vẫn pass. Phụ thuộc thứ tự ⇒ **BLOCKER**
+- `test.describe` gom theo màn/nhóm chức năng; tên test mang **TC-ID**
+- Auth dùng `storageState` / fixture, **không** đăng nhập lại trong từng test ⇒ lặp login là **MINOR**
+- Data từ `data/<feature>.data.ts`, **không** hard-code trong spec ⇒ hard-code là **MAJOR**
+- Tạo data thì phải dọn *(teardown)*; trừ khi chỉ mock/intercept ⇒ thiếu dọn là **MAJOR**
+
+### F · Code quality *(§9)*
+
+- TypeScript **strict**: không `any`, không `as any` ⇒ có là **MINOR**
+- Kiểu trả về khai tường minh cho method public
+- Thứ tự import: Playwright → Page Object → data → helper
+- Logic lặp ≥3 lần chưa tách ⇒ **MINOR**
+
+### G · Anti-pattern *(§10)* và flaky *(§11)*
+
+- Test flaky **không mang tag `@flaky`** mà vẫn nằm trong suite chính ⇒ **MAJOR**
+- Tag `@flaky` có, nhưng **không có ghi chú điều tra** ⇒ **MINOR**
+- `test.skip` không nêu lý do ⇒ **MINOR**; `test.only` sót lại ⇒ **BLOCKER** *(CI chạy 1 test rồi báo xanh)*
+
+---
+
+## Phase 3 — Kiểm cơ học *(bắt buộc — `_shared` §5)*
+
+```
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/<feature>-*.spec.ts --list
+```
+
+Số test collect được **phải bằng** số TC `Automatable: Y` của feature này. Lệch ⇒ **BLOCKER**.
+
+---
+
+## Output
+
+Theo `_shared/review-rules.md` §3 — verdict suy từ số đếm, kèm **≥2–3 điểm tốt** *(R05)*.
+Ghi vào `{qc_artifact_dir}test-cases/REVIEW_SCRIPT_<FEATURE>.md`.

package/core/skills/qc/qa-reviewer/script/web/integration.md

@@ -0,0 +1,46 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Automation-Standards.md §5 §7 §8 (Approved)
+---
+
+# Soát script — Web Integration *(GUI ↔ Backend · API · DB)*
+
+**Nạp `../_shared/review-rules.md` trước**, rồi `functional.md` cùng nền — file này chỉ thêm
+phần riêng của tầng tích hợp.
+
+## Khi nào trigger
+- Soát script kiểm **giao tiếp giữa hai thành phần**: UI gọi API, API ghi DB, sự kiện qua queue.
+
+## Khi KHÔNG trigger
+- Chỉ kiểm UI một màn → `functional.md` · chỉ kiểm endpoint → `../api/endpoint.md`
+
+---
+
+## Thêm gì so với functional
+
+### A · Ranh giới thật, không mock
+
+- Tầng này tồn tại để kiểm **đường dây thật**. Mock hết hai đầu ⇒ **BLOCKER** — test không kiểm gì
+- Mock **một** đầu để cô lập lỗi thì được, nhưng phải ghi rõ đầu nào thật
+
+### B · Đối chiếu hai phía
+
+- Assert trên UI **và** đối chiếu dữ liệu phía server *(qua `request` của Playwright)*
+- Chỉ assert UI ⇒ **MAJOR**: màn hình hiển thị đúng **dữ liệu cũ** vẫn là bug, UI assertion không bắt được
+
+### C · Trạng thái và thứ tự
+
+- Data tạo ở bước trước phải được **dọn** kể cả khi test fail giữa chừng *(dùng `finally`/fixture)*
+- Chờ theo **điều kiện của hệ**: `waitForResponse(...)` thay vì chờ cứng ⇒ chờ cứng là **MAJOR**
+- Test phụ thuộc bản ghi có sẵn trên môi trường ⇒ **MAJOR** — môi trường sạch là fail oan
+
+### D · Mã lỗi
+
+- Nhánh lỗi tích hợp *(timeout, 5xx, kết nối đứt)* có được kiểm không? Thiếu hẳn ⇒ **MAJOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/script/web/non-functional.md

@@ -0,0 +1,49 @@
+---
+version: 1.0
+updated: 2026-09-17
+source: upstream/qc-base-new/Automation-Standards.md §7 §8 §10 (Approved)
+---
+
+# Soát script — Web Non-Functional *(hiệu năng · bảo mật · a11y · tương thích)*
+
+**Nạp `../_shared/review-rules.md` trước**, rồi `functional.md` cùng nền.
+
+## Khi nào trigger
+- Soát script kiểm thuộc tính **phi chức năng**: thời gian đáp ứng, kiểm soát truy cập, khả năng
+  tiếp cận, chạy đa trình duyệt.
+
+---
+
+## Thêm gì so với functional
+
+### A · Ngưỡng phải là con số, không phải cảm tưởng
+
+- Assert hiệu năng **không có ngưỡng cụ thể** ⇒ **BLOCKER** — không có ngưỡng thì không có kết quả
+- Ngưỡng hard-code trong spec thay vì đọc từ config/data ⇒ **MINOR**
+- Đo bằng `Date.now()` quanh một `await` ⇒ **MINOR**; ưu tiên `page.evaluate(performance…)` hoặc
+  `waitForResponse` + timing của response
+
+### B · Bảo mật
+
+- Payload thử injection **hard-code trong spec** ⇒ **MAJOR** — để ở `data/`
+- Kiểm quyền: phải assert **bị chặn** *(403/redirect/không thấy phần tử)*, không chỉ assert
+  "không lỗi" ⇒ assert yếu ⇒ **MAJOR**
+- Credential thật trong code ⇒ **BLOCKER**
+
+### C · Khả năng tiếp cận
+
+- Dùng thư viện a11y qua Playwright *(vd `@axe-core/playwright`)*, assert trên **số vi phạm theo
+  mức**, không assert "có chạy"
+- Không nêu tiêu chuẩn áp dụng (WCAG mức nào) ⇒ **MINOR**
+
+### D · Tương thích
+
+- Chạy đa trình duyệt bằng **`projects` trong `playwright.config.ts`**, không tự lặp trong spec
+  ⇒ tự lặp ⇒ **MAJOR** *(mất song song, mất report tách theo project)*
+- Chỉ khai một browser rồi gọi là "kiểm tương thích" ⇒ **MAJOR**
+
+---
+
+## Kiểm cơ học + Output
+
+Như `functional.md` Phase 3 và §Output.

package/core/skills/qc/qa-reviewer/shared/read-doc-gap-inputs.md

@@ -16,7 +16,7 @@ upstream_sha: 3caa1562399ef1167ac2dc620add2c6c729e55df
 2. **`Read` toàn bộ DOC_GAP.** Định vị mục **`## Tài liệu đầu vào đã đọc để phân tích`** — bảng liệt kê **đầy đủ** file nguồn (cột "Đường dẫn", tính từ `{paths.specs_dir}/`), kèm vai trò & phiên bản.
 3. **`Read` TỪNG file trong bảng đó** — ghép prefix `{paths.specs_dir}/` vào đường dẫn ở cột. Đọc HẾT, không bỏ sót dòng nào (spec chính + ref bắt buộc + transitive 1-hop). Nếu bảng liệt kê phiên bản, kiểm tra file hiện tại khớp; lệch phiên bản → ghi chú vào REVIEW.
 4. **Đối chiếu chéo:** file nào có mặt ở header DOC_GAP ("Tài liệu nguồn (spec chính)"/"Coverage Attestation") mà thiếu trong bảng → vẫn đọc.
-5. Chỉ sau khi đã nạp xong toàn bộ input + file domain (`business-dictionary.md`, `product-definition/`) mới bắt đầu review — dùng chúng làm chuẩn đối chiếu để phán quyết `APPROVED` / `NEEDS_FIX`.
+5. Chỉ sau khi đã nạp xong toàn bộ input + file domain (`business-dictionary.md`, `product-definition/`) mới bắt đầu review — dùng chúng làm chuẩn đối chiếu để phán quyết `APPROVED` / `REVISION_REQUIRED` / `REJECTED`.
 
 ## Nguyên tắc
 

package/core/skills/qc/qa-reviewer/shared/review-file-template.md

@@ -12,7 +12,7 @@ upstream_sha: bd596393ecc016cbea106835681a4979c0a9ca0e
 >
 > | | Upstream | Ở đây | Vì sao |
 > |---|---|---|---|
-> | Verdict | `APPROVE` / `REJECT` | **`APPROVED` / `NEEDS_FIX`** | Đây là từ vựng chung của framework — `/review-code` dùng đúng cặp này. Đổi theo upstream là làm ba lệnh review nói ba kiểu |
+> | Verdict | `APPROVE` / `REJECT` | **4 mức của `AGT-006`** *(xem §Verdict)* | **Đổi 2026-09-17, Bước S · S3.** Trước đó là `APPROVED`/`NEEDS_FIX` cho khớp `/review-code`. Nay lane QC có `AGT-006` §3.2 định nghĩa **severity thành bốn ô đếm được**, nên bốn verdict chỉ là **tên của bốn ô đó** — không thêm phán quyết nào, và ngưỡng qua cửa đã khai sẵn ở `AGT-005:132`. Lane DEV *(`/review-code` · `/review-context` · `/review-tech-docs`)* **giữ 2 mức** vì chưa có bảng severity tương ứng; ở đó 4 tên sẽ là bốn nhãn phải tự đoán. **Bất đối xứng có lý do, không phải chỗ quên đồng bộ** |
 > | Bảng Tổng quan | mỗi vòng **ghi đè** hàng của tầng đó | mỗi vòng **thêm một hàng** | Ghi đè thì mất điểm vòng trước, và **không ai thấy được điểm có tăng không**. Các bảng chi tiết vẫn ghi đè (chúng là trạng thái hiện tại, tích luỹ chỉ thành nhiễu) |
 
 # Khuôn file Review (dùng chung)
@@ -31,7 +31,7 @@ upstream_sha: bd596393ecc016cbea106835681a4979c0a9ca0e
   giữa tài-liệu-nền-cũ và PRD đã duyệt là **lệch đồng bộ, KHÔNG chặn** — không phải mâu thuẫn
   chặn. *(Khung "gap thật = QA KHÔNG tự quyết được" — xem `steps/gap-verify.md`.)*
 - **KHÔNG tự sửa** kịch bản hay code. Chỉ nhận xét, chấm điểm, và nêu cụ thể sửa gì. Người sửa là
-  trạm 3 (`/qc-design-test`) hoặc trạm 5 (`/qc-run-test`).
+  trạm 3 (`/qc-design-test`) hoặc trạm 5 (`/qc-run-script`).
 
 ## Kiểm tra cấu trúc TC (bắt buộc mỗi vòng)
 
@@ -41,7 +41,7 @@ upstream_sha: bd596393ecc016cbea106835681a4979c0a9ca0e
 - **1 bullet Expected / TC (ATOMIC — đội QC chốt 2026-07-09):** mỗi TC có đúng **1**
   `#### Expected Result` với **ĐÚNG 1 bullet**; Test Steps chỉ `[Action]`/`[Verify]`, **không**
   còn `→ [Expected]` ở bước. Đếm nhanh: số header `### TC_` = số `#### Expected Result` = số
-  bullet Expected. **TC có ≥2 bullet → `NEEDS_FIX` `[MULTI_BULLET_EXPECTED]`**, yêu cầu tách
+  bullet Expected. **TC có ≥2 bullet → `MAJOR` `[MULTI_BULLET_EXPECTED]`**, yêu cầu tách
   thành nhiều TC độc lập (mỗi TC 1 bullet, giữ full steps, đánh số lại tuần tự).
 - **Soi bullet 2-kết-cục ẩn (ATOMIC = 1 KẾT CỤC, không chỉ đếm bullet):** bullet nối bằng `;`
   kiểu "khẳng-định + phủ-định" (grep bullet chứa `;` **và** `không/KHÔNG`, vd
@@ -87,26 +87,45 @@ upstream_sha: bd596393ecc016cbea106835681a4979c0a9ca0e
 - **Oracle tự chứa và đúng nguồn:** chuỗi sao-nguyên-văn (tiêu đề · nhãn · chữ trên nút · thông
   báo lỗi) mà TC assert phải ghi nguyên văn trong Expected Result **và** khớp design-spec/PRD của
   **chính feature này**. Soi kỹ chuỗi **mượn nhầm từ feature anh em** (vd *"tạo tài khoản"* vs
-  *"tạo câu hỏi"*). Chuỗi chưa có nguồn chốt mà bị bịa oracle → `NEEDS_FIX`; đúng ra phải để
+  *"tạo câu hỏi"*). Chuỗi chưa có nguồn chốt mà bị bịa oracle → `MAJOR`; đúng ra phải để
   `Status: PENDING` hoặc gắn `🚫 Block: [GAP-UC{N}-{nnn}]`.
 
 ## Thang điểm
 
 **Điểm chất lượng `XX/100`:** trừ **5đ** mỗi lỗi `FAIL`, trừ **2đ** mỗi `WARN`.
 
+> **Hai bộ nhãn, một phép ánh xạ.** Nhãn cũ `FAIL`/`WARN` dùng để **trừ điểm**; nhãn
+> `BLOCKER`/`MAJOR`/`MINOR`/`SUGGESTION` *(`AGT-006` §3.2)* dùng để **suy verdict**. Ánh xạ:
+> `FAIL` ≡ `BLOCKER` ∪ `MAJOR` · `WARN` ≡ `MINOR` ∪ `SUGGESTION`. Ghi finding thì dùng nhãn
+> **bốn mức** — nó phân biệt được *"không chạy được"* với *"chạy được nhưng khó bảo trì"*,
+> thứ mà `FAIL` gộp làm một.
+
 | Điểm | Nghĩa |
 |---|---|
 | **≥ 80** | đạt |
 | 60–79 | cần cải thiện |
 | < 60 | không đạt |
 
-**Verdict suy ra được, không chấm cảm tính:**
+**Verdict suy ra được, không chấm cảm tính — và suy từ SỐ ĐẾM LỖI, không từ điểm:**
 
 ```
-điểm ≥ 80  VÀ  không còn lỗi FAIL chặn   →  APPROVED
-ngược lại                                 →  NEEDS_FIX
+≥1 BLOCKER                                  →  REJECTED
+0 BLOCKER, ≥1 MAJOR                         →  REVISION_REQUIRED
+0 BLOCKER, 0 MAJOR, ≥1 MINOR/SUGGESTION     →  APPROVED_WITH_SUGGESTIONS
+0 BLOCKER, 0 MAJOR, 0 MINOR/SUGGESTION      →  APPROVED
+
+đi tiếp được:  APPROVED · APPROVED_WITH_SUGGESTIONS      (ngưỡng ≥ APPROVED_WITH_SUGGESTIONS)
+phải sửa lại:  REVISION_REQUIRED · REJECTED
 ```
 
+> **Điểm `XX/100` vẫn giữ, nhưng nó KHÔNG quyết verdict.** Điểm là con số để **so hai vòng soát
+> với nhau**; verdict là kết luận **đi tiếp hay không**. Khi hai thứ mâu thuẫn — điểm 75 mà
+> 0 BLOCKER + 0 MAJOR — thì **số đếm thắng** *(`AGT-006` R06: verdict phải phản ánh đúng finding
+> counts, không được override)*, và chỗ phải sửa là **trọng số trừ điểm**, không phải verdict.
+>
+> **Vì sao không để điểm quyết:** một lỗi BLOCKER duy nhất vẫn có thể ra 85 điểm nếu mọi mục khác
+> tốt — và 85 điểm mà script không dịch được là một con số nói dối.
+
 > **Vì sao là số, không phải chữ cái.** Framework trước đây ghi `Score: A / B / C / D` mà **không
 > có luật chấm** — nên hai người soát ra hai kết quả, và vòng 2 không so được với vòng 1. Một con
 > số có luật trừ điểm làm được cả ba: **so được các vòng** · **verdict suy ra được** · **hai
@@ -126,7 +145,7 @@ soát:
 ```
 
 ⚠️ **Tên file review KHÔNG có đuôi `.Test.md`.** Đuôi đó là của file test case; gắn vào file
-review sẽ làm `/qc-run-test` nhặt nó lên như một file test case rồi cố sinh script từ một bảng
+review sẽ làm `/qc-design-script` nhặt nó lên như một file test case rồi cố sinh script từ một bảng
 điểm.
 
 - **Chưa tồn tại** → `Write` toàn bộ khuôn bên dưới, điền hàng của tầng vừa soát, các tầng khác
@@ -147,7 +166,7 @@ review sẽ làm `/qc-run-test` nhặt nó lên như một file test case rồi
 ```markdown
 # Review Report — <FEATURE>
 
-> Sinh bởi /qc-review. Cập nhật sau mỗi vòng soát. Bảng Tổng quan tích luỹ theo vòng.
+> Sinh bởi /qc-review-testcase hoặc /qc-review-script (mỗi vai một file). Cập nhật sau mỗi vòng soát. Bảng Tổng quan tích luỹ theo vòng.
 
 ## Tổng quan
 
@@ -177,7 +196,7 @@ review sẽ làm `/qc-run-test` nhặt nó lên như một file test case rồi
 | Tầng | Kịch bản còn thiếu |
 |---|---|
 
-## Điều kiện để APPROVED (khi đang NEEDS_FIX)
+## Điều kiện để lên `APPROVED` (khi đang `REVISION_REQUIRED` / `REJECTED`)
 
 | Tầng | Điều kiện cần sửa |
 |---|---|

package/core/skills/qc/qa-reviewer/test-case/e2e.md

@@ -12,7 +12,7 @@ Review bộ TC end-to-end và đánh giá chất lượng.
 
 ## Khi nào trigger
 - "review TC E2E cho [Feature]" / "check coverage E2E"
-- Sau khi qa-designer/e2e/journey xong, trước khi /qc-run-test
+- Sau khi qa-designer/e2e/journey xong, trước khi /qc-design-script
 
 ## Khi KHÔNG trigger
 - Review TC functional 1 màn → `test-case/functional`
@@ -123,7 +123,7 @@ hàng của tầng mình, KHÔNG ghi đè tầng khác).
 Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể (TC ID / journey)
 
 **Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
-**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+**Verdict:** suy từ **số đếm lỗi** theo `shared/review-file-template.md` §Verdict — `≥1 BLOCKER` → `REJECTED` · `≥1 MAJOR` → `REVISION_REQUIRED` · chỉ MINOR/SUGGESTION → `APPROVED_WITH_SUGGESTIONS` · sạch → `APPROVED`. Điểm `XX/100` vẫn ghi, nhưng **không quyết verdict**.
 
 Danh sách journey thiếu TC; TC cần sửa Expected; TC vi phạm isolation.
 Điền thêm bảng **Coverage journey/path (E2E)** ở cuối file review.

package/core/skills/qc/qa-reviewer/test-case/exploratory.md

@@ -84,7 +84,7 @@ hàng của tầng mình, KHÔNG ghi đè tầng khác).
 Mỗi tiêu chí: ✅ PASS | ⚠️ WARN | ❌ FAIL + evidence cụ thể (charter ID)
 
 **Điểm `XX/100`** — trừ 5đ mỗi `FAIL`, 2đ mỗi `WARN`. ≥80 đạt · 60–79 cần cải thiện · <60 không đạt.
-**Verdict:** `điểm ≥ 80` VÀ không còn `FAIL` chặn → **`APPROVED`**; ngược lại **`NEEDS_FIX`**.
+**Verdict:** suy từ **số đếm lỗi** theo `shared/review-file-template.md` §Verdict — `≥1 BLOCKER` → `REJECTED` · `≥1 MAJOR` → `REVISION_REQUIRED` · chỉ MINOR/SUGGESTION → `APPROVED_WITH_SUGGESTIONS` · sạch → `APPROVED`. Điểm `XX/100` vẫn ghi, nhưng **không quyết verdict**.
 
 Mỗi charter: ✅ PASS | 🔧 REWORK | ✂️ SPLIT | 🔗 MERGE + feedback cụ thể.
 Charter bổ sung nếu còn gap.