@educa-corp/sdd-framework 0.9.6 → 0.9.8

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

@@ -0,0 +1,39 @@
+---
+version: 1.0
+updated: 2026-09-09
+---
+
+# Gen Script — API (dùng chung mọi platform)
+
+Skill sinh script test API thuần (không qua UI), dùng `@playwright/test` `APIRequestContext`.
+Test API **không phân biệt platform gọi nó là web hay mobile** — backend là một, nên file này
+dùng chung cho cả pipeline web và mobile (không có bản mobile riêng).
+
+## Khi nào trigger
+- Convert TC API (output `qa-designer/functional/api.md`), TC Automatable=Y, `TC_<FEATURE>.md` đã approve.
+
+## Khi KHÔNG trigger
+- Test qua UI → `functional/gui-screen.md`/mobile tương ứng · tích hợp đa thành phần → `integration.md`
+
+## Quy ước riêng (ngoài Locator/Wait/Assertion chung — API không có locator)
+- Client API gói trong fixture Playwright (`test.extend`) — base URL + auth header từ
+  `process.env.*`, KHÔNG rải request rời rạc trong test.
+- Assertion: status code **và** field response (JSON path) — không chỉ status code.
+- Test độc lập: tạo data qua API → dùng → cleanup qua API (`test.afterEach`), không phụ thuộc
+  thứ tự chạy.
+
+## Phase 1 — Clarify
+Base URL/auth/role theo `TEST_DATA_PLAN.md`; client fixture đã có chưa.
+
+## Phase 2 — Generate
+Mỗi TC Automatable=Y → 1 test gọi endpoint với request từ `TEST_DATA_PLAN.md`; assert status +
+field. Nhóm `test.describe`: happy → validation → auth → not-found → edge.
+
+## Phase 3 — Self-Verify
+```bash
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/functional/api/<feature>-<scenario>.spec.ts --list
+```
+
+## Output
+`automation/tests/{TICKET-ID}/functional/api/<feature>-<scenario>.spec.ts` + client fixture (`fixtures/api-client.ts`) nếu mới.

package/core/skills/qc/qa-script-designer/web/functional/gui-feature.md

@@ -0,0 +1,34 @@
+---
+version: 1.0
+updated: 2026-09-09
+---
+
+# Gen Script — Web Functional GUI Feature (đa màn hình)
+
+Skill sinh script cho feature span ≥2 màn. **Đọc `_shared/web-conventions.md` trước.**
+
+## Khi nào trigger
+- Convert TC feature đa-màn (output `qa-designer/functional/gui-feature.md`), TC Automatable=Y,
+  `TC_<FEATURE>.md` đã approve.
+
+## Khi KHÔNG trigger
+- Gọn 1 màn → `functional/gui-screen.md` · đầu-cuối xuyên hệ thống ngoài → `e2e.md`
+
+## Phase 1 — Clarify
+Liệt kê các màn/Page Object cần; state truyền giữa màn (giá trị nhập màn A hiển thị đúng ở
+màn B); data từ `TEST_DATA_PLAN.md`.
+
+## Phase 2 — Generate
+Mỗi Page Object action điều hướng **trả về PO màn kế tiếp** (`return new NextPage(this.page)`)
+— test chuỗi `const p2 = await p1.doAction()`. Phủ đúng TC Automatable=Y (đếm khớp
+`AUTOMATION_ASSESSMENT.md`). Assert **sau mỗi chặng có side-effect**, không chỉ ở bước cuối
+(xem Common Pitfall #4 trong `_shared/web-conventions.md`).
+
+## Phase 3 — Self-Verify
+```bash
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/<feature>-<scenario>.spec.ts --list
+```
+
+## Output
+Script + nhiều Page Object (mỗi màn) trong `automation/pages/{TICKET-ID}/...`.

package/core/skills/qc/qa-script-designer/web/functional/gui-screen.md

@@ -0,0 +1,42 @@
+---
+version: 1.0
+updated: 2026-09-09
+---
+
+# Gen Script — Web Functional GUI Screen (1 màn hình)
+
+Skill sinh script cho 1 màn hình đơn. **Đọc `_shared/web-conventions.md` trước** (Locator
+Strategy, Page Object, Wait/Assertion, Common Pitfalls) — file này chỉ có phần sinh-script
+riêng của layer.
+
+## Khi nào trigger
+- Convert TC functional 1 màn (output `qa-designer/functional/gui-screen.md`), TC đã
+  `Automatable: Y` (từ `AUTOMATION_ASSESSMENT.md`) và `TC_<FEATURE>.md` đã approve.
+
+## Khi KHÔNG trigger
+- Feature đa-màn → `functional/gui-feature.md` · API thuần → `functional/api.md`
+
+## Phase 1 — Clarify
+Đọc `TC_<FEATURE>.md` (chỉ TC Automatable=Y) + `TEST_DATA_PLAN.md`. Page Object cho màn này đã có
+chưa → tạo mới nếu chưa. Đọc bảng test-id §4.5.6 tech-doc gộp cho màn này.
+
+## Phase 2 — Generate
+**Phủ đúng các TC Automatable=Y** — đếm TC trong `AUTOMATION_ASSESSMENT.md` có `Y` cho màn
+này = số `test(...)` phải sinh (không hơn, không kém). TC Automatable=Y nhưng phát hiện rào
+cản kỹ thuật lúc viết → `test.fixme('TC_xxx — {lý do}')` + ghi `IMPROVE-xxx` (xem command
+`/qc-design-script` §Testability Improvement List), không âm thầm bỏ qua.
+
+Nhóm theo `test.describe`: GUI (hiển thị/enable-disable) → Functional (input/validation/action).
+Data lấy từ `TEST_DATA_PLAN.md` (theo `TD-xxx` map ở cột "Dùng bởi").
+
+## Phase 3 — Self-Verify (trước khi báo Human approve)
+```bash
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/<screen>.spec.ts --list
+```
+Số test liệt kê = số TC Automatable=Y của màn này. Thiếu → quay lại Phase 2.
+
+## Output
+`automation/tests/{TICKET-ID}/<screen-slug>.spec.ts` +
+`automation/pages/{TICKET-ID}/<screen-slug>.page.ts` (mới nếu cần —
+xem quy tắc slug/kiểm tra tồn tại trước khi tạo ở `_shared/file-naming-and-folders.md`).

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

@@ -0,0 +1,43 @@
+---
+version: 1.0
+updated: 2026-09-09
+---
+
+# Gen Script — Web Integration (API↔DB↔service↔queue↔UI)
+
+**Đọc `_shared/web-conventions.md` trước.**
+
+## Khi nào trigger
+- Convert TC integration (output `qa-designer/integration/*`), TC Automatable=Y.
+
+## Khi KHÔNG trigger
+- Chỉ 1 endpoint/UI đơn → `functional/*` · hành trình đầu-cuối → `e2e.md`
+
+## Quy ước riêng — không mock (nguyên tắc quan trọng nhất của integration test)
+Mock API/DB trong integration test biến nó thành **unit test trá hình** — không còn verify
+được tích hợp thật. Luôn gọi network/DB thật trên môi trường test:
+- **GUI↔Backend**: `page.waitForResponse(url)` để capture request/response thật khi thao tác UI.
+- **DB**: client DB thật (qua fixture, connection string từ `process.env.*`), verify trực tiếp
+  bảng/cột — không chỉ verify qua UI hiển thị đúng (UI có thể cache sai mà DB đã đúng, hoặc
+  ngược lại).
+- **Kafka/queue**: producer/consumer thật trong fixture, verify payload nhận được, không
+  giả lập message.
+
+## Phase 1 — Clarify
+Chuỗi tích hợp & chặng cần verify; client/fixture (API/DB/Kafka) đã có chưa; data từ
+`TEST_DATA_PLAN.md`.
+
+## Phase 2 — Generate
+Mỗi TC → 1 test theo data flow: action → verify từng chặng (response → DB → event → UI).
+Nhóm: happy → contract-negative (4xx/5xx + UI hiển thị đúng message) → concurrency (mô tả rõ
+số request đồng thời, assert không race condition — vd unique constraint giữ nguyên).
+
+## Phase 3 — Self-Verify
+```bash
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/integration/<feature>-<scenario>.spec.ts --list
+```
+(Cần môi trường staging/DB/Kafka test khả dụng để chạy thật sau khi generate.)
+
+## Output
+Script + client/fixture (DB/Kafka/API) trong `automation/tests/{TICKET-ID}/integration/` + `fixtures/`.

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

@@ -0,0 +1,42 @@
+---
+version: 1.0
+updated: 2026-09-09
+---
+
+# Gen Script — Web Non-Functional (Performance/Security/Accessibility/Compatibility)
+
+**Đọc `_shared/web-conventions.md` trước** (locator/wait/assertion nền tảng vẫn áp dụng).
+
+## Khi nào trigger
+- Convert TC non-functional (output `qa-designer/non-functional.md`), TC Automatable=Y, có
+  **ngưỡng đo cụ thể** trong `TC_<FEATURE>.md`.
+
+## Công cụ theo loại
+
+| Loại | Công cụ | Assert |
+|---|---|---|
+| **Performance** | `performance.timing`/`page.evaluate` đo, hoặc tích hợp k6/Artillery cho load thật | Ngưỡng cụ thể (`expect(elapsed).toBeLessThan(2000)`), không assert mơ hồ |
+| **Security** | Payload injection trong constant/fixture; test trên môi trường test, KHÔNG production | Status 4xx + không tạo được record + response không lộ PII |
+| **Accessibility** | `@axe-core/playwright` (`AxeBuilder`) | `expect(results.violations).toHaveLength(0)` hoặc filter đúng WCAG level (`wcag2a`/`wcag2aa`) |
+| **Compatibility** | Playwright `projects` trong config (chromium/firefox/webkit), hoặc device emulation | Mỗi project = 1 target trong TC; không hardcode 1 browser |
+
+## Quy ước riêng
+- Assertion **luôn có ngưỡng cụ thể khớp TC gốc** — không tự đặt ngưỡng khác, không
+  `expect(response).toBeTruthy()` mơ hồ.
+- Đo elapsed time: bắt đầu/kết thúc rõ ràng, **không** bao gồm thời gian fixture setup.
+- Test cần môi trường đặc biệt (load server, scanner) → `test.skip(!envReady, 'lý do')`.
+
+## Phase 1 — Clarify
+Loại + ngưỡng + công cụ; môi trường/tải mẫu; data đặc biệt từ `TEST_DATA_PLAN.md`.
+
+## Phase 2 — Generate
+Mỗi TC → 1 test đo + assert ngưỡng; đánh dấu test cần môi trường riêng bằng tag `@slow`.
+
+## Phase 3 — Self-Verify
+```bash
+npx tsc --noEmit
+npx playwright test automation/tests/{TICKET-ID}/non-functional/<feature>-<scenario>.spec.ts --list
+```
+
+## Output
+`automation/tests/{TICKET-ID}/non-functional/<feature>-<scenario>.spec.ts` + helper đo/scan (`utils/measure.ts`).

package/core/skills/qc/qa-script-runner/mobile/run.md

@@ -0,0 +1,38 @@
+---
+version: 1.0
+updated: 2026-09-09
+new_in: QC-Workflow-Proposal (8-phase)
+---
+
+# Run — Mobile (WebdriverIO + Appium)
+
+Skill **tự chứa** cho `/qc-run-script` khi `active_platform = app`.
+
+## Lệnh chạy
+
+```bash
+npx wdio run wdio.conf.ts --spec mobile-automation/test/specs/{TICKET-ID}/...
+```
+
+Video/screenshot on-fail cấu hình qua `afterTest` hook trong `wdio.conf.ts` (chụp screenshot
+khi `passed === false`; ghi video nếu dùng service `wdio-video-reporter` hoặc quay màn hình
+qua `driver.saveRecordingScreen`/tương đương simulator/emulator).
+
+## Đọc kết quả trước khi đề xuất phân loại Fail
+
+Với mỗi FAIL, xem screenshot/video tại thời điểm fail + log Appium server (`appium.log`)
+trước khi đoán:
+
+| Dấu hiệu | Khả năng cao là |
+|---|---|
+| Element "not found" nhưng screenshot cho thấy nó **hiển thị rõ trên màn hình** | **script-bug** — sai `ValueKey`/locator, hoặc app chưa bật `Semantics` đúng cho driver `FlutterIntegration` đọc |
+| Log Appium báo `automationName` không khớp app (vd dùng `UiAutomator2` cho app Flutter không bật accessibility) | **script-bug** — sai cấu hình driver, xem `_shared/mobile-conventions.md` §0 |
+| Hành động đúng (tap đúng nút, đúng data) nhưng app **không phản hồi đúng spec** (không điều hướng, không lưu data) | **product-gap** |
+| Permission dialog native chặn action, test không xử lý | **script-bug** — thiếu xử lý dialog, không phải bug sản phẩm |
+| Fail chỉ xảy ra trên 1 device/OS version cụ thể | Có thể **product-gap** riêng cho compatibility đó — không quy chung là flaky |
+
+## Retry trước khi kết luận (bắt buộc — bước 0 của gate phân loại Fail)
+Mobile vốn có độ trễ/nhiễu cao hơn web (cold start, animation, tốc độ máy) — trước khi đề xuất
+phân loại bất kỳ Fail nào, chạy lại riêng test đó tối đa 2 lần trên cùng device/emulator. Kết
+quả không nhất quán → đề xuất `flaky` (xem `/qc-run-script` §Phân loại mỗi Fail), không phải
+script-bug/product-gap ngay.

package/core/skills/qc/qa-script-runner/report.md

@@ -0,0 +1,41 @@
+---
+version: 1.0
+updated: 2026-09-09
+source: upstream/qc-base-new/Automation-Standards.md §1 + OQ-01 · Mobile-Automation-Standards.md §1 (Approved)
+---
+
+# Report skill — TypeScript stack (Playwright HTML Report / WDIO Allure Report)
+
+Skill **tự chứa** cho `/qc-report`. Báo cáo do **công cụ sinh** — Playwright HTML Report (web·system) hoặc Allure v2.x (app) — **không** dashboard tự viết.
+
+## Web — Playwright HTML Report + Trace Viewer
+
+```bash
+npx playwright test automation/tests/{TICKET-ID}/... --reporter=html
+npx playwright show-report                      # mở report HTML tương tác
+npx playwright show-trace test-results/<nodeid>/trace.zip   # debug 1 test cụ thể
+```
+
+- Report HTML mặc định ở `playwright-report/` (self-contained, mở trực tiếp trong browser).
+- Mỗi test fail có sẵn trace + screenshot đính kèm (cấu hình qua
+  `use: { trace: 'on-first-retry', screenshot: 'only-on-failure' }` trong `playwright.config.ts`).
+
+## Mobile — WebdriverIO Allure Report
+
+```bash
+npx wdio run wdio.conf.ts --spec ...
+npx allure generate ./allure-results --clean -o ./allure-report
+npx allure open ./allure-report
+```
+
+- Cần reporter `@wdio/allure-reporter` khai trong `wdio.conf.ts` (`reporters: ['allure']`).
+- Screenshot/video on-fail đính kèm tự động vào report qua `afterTest` hook (xem
+  `qa-script-runner/mobile/run.md`).
+
+## Nguyên tắc chung (cả hai platform)
+- Evidence trung thực: report phản ánh đúng lần chạy gần nhất, không chỉnh sửa số liệu.
+- FAIL giữ nguyên trạng thái thật cho tới khi fix + chạy lại — **không fake-pass**.
+- `playwright-report/`, `test-results/`, `allure-results/`, `allure-report/` đã gitignore
+  (artifact nặng) — không commit vào repo.
+- Tóm tắt bắt buộc: **TOTAL / PASS / FAIL / SKIP / FLAKY** + duration, và với mỗi FAIL: phân
+  loại đã xác nhận (script-bug/product-gap/flaky) từ `/qc-run-script`, kèm `BUG-{id}` nếu đã file.

package/core/skills/qc/qa-script-runner/web/run.md

@@ -0,0 +1,48 @@
+---
+version: 1.0
+updated: 2026-09-09
+new_in: QC-Workflow-Proposal (8-phase)
+---
+
+# Run — Web (Playwright Test)
+
+Skill **tự chứa** cho `/qc-run-script` khi `active_platform = web`.
+
+## Lệnh chạy
+
+```bash
+npx playwright test automation/tests/{TICKET-ID}/... --reporter=html,list
+```
+
+Trace tự động bật qua `playwright.config.ts` (`use: { trace: 'on-first-retry' }` hoặc `'on'`
+nếu muốn trace mọi lần) → mỗi test có `test-results/<nodeid>/trace.zip` khi fail.
+
+## Đọc kết quả trước khi đề xuất phân loại Fail
+
+Với mỗi FAIL, **mở trace trước khi đoán**:
+
+```bash
+npx playwright show-trace test-results/<nodeid>/trace.zip
+```
+
+Trace viewer cho: timeline hành động, DOM snapshot tại từng bước, network request/response,
+console log. Dấu hiệu phân biệt:
+
+| Dấu hiệu trong trace | Khả năng cao là |
+|---|---|
+| Locator "not found" nhưng DOM snapshot cho thấy element **có tồn tại** với selector khác | **script-bug** — selector sai/lỗi thời do UI đổi cấu trúc, không phải bug sản phẩm |
+| Element thực sự **không xuất hiện** sau hành động đúng spec (nút bấm không có phản hồi, API trả lỗi mà spec nói phải thành công) | **product-gap** — hành vi thực tế ≠ spec |
+| Timeout chờ network response, response **không bao giờ tới** | **product-gap** nếu spec yêu cầu response — hoặc **script-bug** nếu URL/endpoint chờ sai |
+| Assertion so giá trị: actual đúng theo spec nhưng expected trong test viết sai | **script-bug** |
+| Flaky ngẫu nhiên (pass khi chạy lẻ, fail khi chạy song song) | **script-bug** — thiếu cách ly data/test independence, xem `_shared/web-conventions.md` §Common Pitfalls #5-6 |
+
+Không kết luận nếu bằng chứng không đủ rõ — báo "không chắc, cần điều tra thêm" thay vì đoán.
+
+## Retry trước khi kết luận (bắt buộc — bước 0 của gate phân loại Fail)
+Trước khi đề xuất phân loại bất kỳ Fail nào, chạy lại riêng test đó tối đa 2 lần:
+```bash
+npx playwright test <file> -g "<title>" --repeat-each=1
+```
+Kết quả không nhất quán (fail→pass hoặc ngược lại) → đề xuất `flaky`, không phải
+script-bug/product-gap (xem `/qc-run-script` §Phân loại mỗi Fail). Chỉ khi fail **nhất quán**
+qua các lần retry mới tiếp tục điều tra để phân biệt script-bug/product-gap.

package/core/steps/context-loader.md

@@ -190,7 +190,7 @@ services:
 - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
 - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
 - Override `paths.prd_change_requests_dir` → `{spec_source}/feedback/prd-change-requests`
-- Override `paths.trace_dir` → `{spec_source}/.trace` — **luôn khi `spec_source` được đặt.** Trace TSV được gộp vào spec repo (một nơi authoritative duy nhất, không tách theo service) để PM/PO có một chỗ duy nhất quản lý trạng thái. Cấu trúc bên trong: `.trace/{domain}/{prd-slug}/{UC-ID}-{platform}.tsv`. Các lệnh phía code (`/generate-code`, `/dev-run-test`, `/qc-run-test`) chạy từ `service_root` nhưng **ghi trace row của chúng vào `{spec_source}/.trace/{domain}/{prd-slug}/`** — giống như chúng đã push `feedback/` vào đó. *(`.trace` theo service chỉ khi không có `spec_source`.)*
+- Override `paths.trace_dir` → `{spec_source}/.trace` — **luôn khi `spec_source` được đặt.** Trace TSV được gộp vào spec repo (một nơi authoritative duy nhất, không tách theo service) để PM/PO có một chỗ duy nhất quản lý trạng thái. Cấu trúc bên trong: `.trace/{domain}/{prd-slug}/{UC-ID}-{platform}.tsv`. Các lệnh phía code (`/generate-code`, `/dev-run-test`, `/qc-run-script`) chạy từ `service_root` nhưng **ghi trace row của chúng vào `{spec_source}/.trace/{domain}/{prd-slug}/`** — giống như chúng đã push `feedback/` vào đó. *(`.trace` theo service chỉ khi không có `spec_source`.)*
 - Override `paths.refinement_dir` → `{spec_source}/.agent/review` — **luôn khi `spec_source` được đặt.** Findings review (`/refine-prd`, `/review-context`, `/review-tech-docs`) là artifact liên-team *về* tài liệu trong spec repo (PRD/BDD/tech-design) — thuộc cùng khu vực ghi với `.trace/` và `feedback/`. Các lệnh review chạy từ working dir của service (BE repo) nhưng **ghi findings vào `{spec_source}/.agent/review/`**, KHÔNG phải `.agent/review` của service repo. Bên trong flat, phân biệt bằng tên file đã prefix `{prd-slug}`/`{UC-ID}`/`{TICKET-ID}`. *(`.agent/review` theo service chỉ khi không có `spec_source`.)*
 
 > **Vì sao đặt dưới `spec_source`:** PRD, BDD, tech-docs, design-spec, domain knowledge, feedback của tester, **trạng thái coverage `.trace/`**, **và findings review `.agent/review/`** đều là **artifact liên team** — chúng nằm trong **spec repo dùng chung** theo bố cục feature-package để mọi umbrella (FE/App/BE) và PM đọc từ một nguồn qua `/sync`. Trong bố cục feature-package, một folder `specs/{domain}/{prd-slug}/` gom tất cả loại artifact của một PRD, giúp spec repo tự đủ và dễ điều hướng theo feature. Service submodule chỉ chứa **code** (+ tooling build/test). `.trace/`, `.agent/review/` và `feedback/` là khu vực **ghi** của dev/QC/reviewer trong spec repo. Ở chế độ single-service (không có `spec_source`), mọi thứ mặc định dưới gốc repo — vẫn là một repo.

package/core/steps/gate.md

@@ -77,7 +77,7 @@ Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phi
 
 | Mức | Lệnh nào | `--yes` bỏ qua được? |
 |---|---|:---:|
-| **Không chặn** | Lệnh read-only: `/review-code` · `/validate-traces` · `/debug` · `/review-context` · `/review-tech-docs` | — (vốn không có) |
+| **Không chặn** | `/review-code` · `/validate-traces` · `/debug` — **KHÔNG phải vì read-only**: cả ba đều CÓ ghi file. Chúng không chặn vì thao tác ghi của chúng hoặc nằm sau một câu hỏi `(Y/N)`, hoặc nằm sau một cờ, hoặc là `append`/dựng-lại-được | — (vốn không có) |
 | **Chặn thường** | Mọi lệnh sinh/sửa artifact | ✅ |
 | **Chặn CỨNG** | Ghi đè file đã tồn tại · `--resume` áp findings · migrate · prune | ❌ **không bao giờ** |
 
@@ -85,6 +85,12 @@ Lưu toàn bộ context đã nạp vào bộ nhớ để dùng xuyên suốt phi
 `--` khỏi phần resolve target, nên cờ này không ảnh hưởng việc tìm file.) Mở đường chạy
 headless: `claude -p "/generate-code UC1 --yes"`.
 
+> **Tên lệnh trong bảng trên có máy canh — `R19`.** Mỗi hàng bảng vừa nêu một mức vừa nêu
+> tên lệnh sẽ bị đối chiếu với `gate.checkpoint_levels`; lệch là build đỏ. Lý do có rule này:
+> ngày 2026-09-16 hai lệnh đổi mức, schema và `commands/*.tmpl` đều sửa, **build vẫn xanh**,
+> mà bảng này lẫn `rules/workflow.md` đều còn liệt chúng ở mức cũ. `R11` chỉ canh
+> `commands/*.tmpl` ↔ schema — *biết có máy canh không bằng biết máy canh **đến đâu***.
+
 > **KHÔNG tự suy mức từ bảng này.** Mỗi lệnh **tự khai** mức của nó ở một dòng `*Checkpoint: …*`
 > ngay dưới `## Gate` của chính nó — đọc dòng đó, đừng suy diễn. Bảng trên chỉ giải thích ba mức
 > **nghĩa là gì**.

package/core/steps/qc-scope.md

@@ -58,6 +58,49 @@ Theo thứ tự, dừng ở cái đầu tiên khớp:
 Lưu `active_platform`. Từ đây, **mọi** phép đọc `.feature` chỉ đọc thư mục
 `bdd/{active_platform}/` — không trộn SC chéo nền.
 
+> **Nền `system` còn MỘT câu hỏi nữa, và nó ở trạm 3.** `system` không đồng nghĩa với API — nó
+> còn chứa **job tự chạy** và **consumer hàng đợi**, hai thứ không có endpoint nào. Khi không suy
+> được, `/qc-design-test` hỏi QC rồi ghi câu trả lời vào `Tags` của TC. Xem
+> `/qc-design-test` §Nền `system`. Ghi ở đây để người đọc luật nền biết **còn một câu chưa xong**,
+> chứ không phải phân giải xong nền là hết.
+
+### 2b — Nền → module QC → lane skill *(bảng DUY NHẤT, đừng chép lại ở lệnh)*
+
+| `active_platform` | module QC | `layout` | lane skill |
+|---|---|---|---|
+| `web` · `webview` | `qc-playwright-ts` | `layout.web` — `automation/` | `qa-script-designer/web/*` |
+| `app` · `app-ios` · `app-android` | `qc-wdio-appium` | `layout.mobile` — `mobile-automation/` | `qa-script-designer/mobile/*` |
+| `system` + lane `api` | `qc-playwright-ts` | `layout.api` — `api-automation/` | `qa-script-designer/api/*` |
+| `system` + lane `job` · `queue` | `qc-playwright-ts` | `layout.api` — `api-automation/` | ⚠️ **chưa có lane script** — xem dưới |
+
+> **Vì sao bảng này ở đây chứ không ở lệnh.** Cùng lý do mục §2 tồn tại: luật phân giải nền
+> từng được copy-paste ở 5 lệnh rồi câu chữ lệch nhau. Ba lệnh script trỏ vào đây, **không
+> chép lại**.
+>
+> **Vì sao KHÔNG có key cấu hình riêng.** Từng có một lời hứa `tech_stack.qc_module` trong
+> comment của module cũ, nhưng nó **chưa bao giờ được cài** — và không nên cài: `active_platform`
+> đã trả lời xong câu này ở §2 và đã **khoá cho cả pass QC**. Một field thứ hai là hai đáp án
+> cho một câu hỏi, và khi chúng lệch nhau thì artifact ghi vào thư mục của nền này trong khi
+> script sinh theo layout của nền kia — hỏng **im lặng**.
+>
+> 🔴 **`system` KHÔNG đồng nghĩa với API — sửa 2026-09-17 sau ca thật LESS-22.** Quyết định
+> `S-API` ánh xạ `system → lane api` vô điều kiện, và nó **sai**: `system` còn chứa **job tự
+> chạy** *(không ai gọi)* và **consumer hàng đợi** *(nằm chờ message)*. Cả ba tài liệu chuẩn dùng
+> để chốt `S-API` đều **chỉ nói về API**, nên không ai thấy hai hình dạng kia.
+>
+> **Tầng thiết kế TC đã có đủ ba** *(trạm 3 hỏi QC rồi ghi lane — xem `/qc-design-test` §Nền
+> `system`)*: `functional/api` · `functional/job` · `integration/queue`.
+>
+> **Tầng sinh script mới có một** — `qa-script-designer/api/*`. Lane `job` và `queue` chạy tới
+> trạm 6 thì **chưa có skill**. Đây là **lỗ đã biết, ghi ra thay vì để trạm 6 lặng lẽ dùng lane
+> `api`**: gặp TC lane `job`/`queue`, trạm 6 phải **DỪNG** và nói rõ chưa hỗ trợ, không được
+> sinh API Object cho một thứ không có endpoint.
+
+> **`web` và `system` dùng chung module, khác `layout`.** Đó là chủ ý: cùng Playwright + TS
+> *(AD-API-001 — "tái dùng infrastructure với Web testing")*, nên tách làm hai module là khai
+> dãy phiên bản hai lần. Nhưng **API Object ≠ Page Object** và `api-automation/` là thư mục
+> gốc riêng, nên `layout` và lane skill phải tách.
+
 ---
 
 ## 3 — `qc_artifact_dir`
@@ -114,7 +157,7 @@ và đánh dấu trong artifact là dựa trên BDD nháp. *(Tên cờ chung cho
 
 ### 4b — Cổng cấp UC: **cái UC vừa được gọi tên** có làm được không?
 
-Bốn lệnh nhận target là **UC-ID** — `/qc-design-test` · `/qc-review` · `/qc-run-test` · `/qc-report`
+Bảy lệnh nhận target là **UC-ID** — `/qc-design-test` · `/qc-review-testcase` · `/qc-review-script` · `/qc-design-script` · `/qc-run-script` · `/qc-run-manualtest` · `/qc-report`
 — phải đối chiếu target với **bảng vừa in ở trên**. Hai lệnh cấp PRD (`/qc-analyze` · `/qc-plan`)
 **bỏ qua mục này**: target của chúng là `TICKET-ID`, và cổng 4a đã trả lời đúng câu hỏi của chúng.
 
@@ -141,7 +184,7 @@ Bốn lệnh nhận target là **UC-ID** — `/qc-design-test` · `/qc-review`
 > đi thẳng vào một spec chưa ai duyệt.
 >
 > Cái giá không dừng ở "thiết kế trên bản nháp". `Guard SC coverage` của trạm 3 sẽ **khẳng định**
-> `khớp K/K` trên spec chưa duyệt, và `/qc-run-test` sẽ ghi `qc_status = pass` **chính thức** vào sổ
+> `khớp K/K` trên spec chưa duyệt, và `/qc-run-script` sẽ ghi `qc_status = pass` **chính thức** vào sổ
 > trace cho nó. Đó là **báo cáo sai** — `rules/workflow.md` §*"ai KHẲNG ĐỊNH một giá trị dương phải
 > được phép khẳng định"*.
 >

package/core/steps/qc-stamp.md

@@ -17,7 +17,7 @@ Câu chưa ai trả lời là *"**tài liệu thiết kế test** còn khớp kh
 
 | Tín hiệu | Nghĩa | Việc phải làm |
 |---|---|---|
-| `qc_status = not_run` | kết quả cũ hết hiệu lực | **chạy lại** `/qc-run-test` |
+| `qc_status = not_run` | kết quả cũ hết hiệu lực | **chạy lại** `/qc-run-script` |
 | **stamp lệch** | TC/gap/plan mô tả spec cũ | **viết lại** — `/qc-analyze` hoặc `/qc-design-test` |
 
 Thiếu vế sau thì người ta thấy `not_run` và **chạy lại** — đúng phản xạ, sai việc. Một bộ TC lỗi thời
@@ -111,8 +111,8 @@ Với mỗi artifact mà lệnh này đọc:
 
 | Trạm | Lệch thì | Vì sao |
 |---|---|---|
-| `/qc-plan` · `/qc-design-test` · `/qc-review` | **⚠️ cảnh báo, đi tiếp** | Cùng họ `TECHDOC_DRIFT`/`BDD_DRIFT` — 13/17 cờ audit không chặn. Thiết kế TC trên bản hơi cũ vẫn ra sản phẩm dùng được; chặn ở đây là **ồn** |
-| `/qc-run-test` | **chặn `pass`, KHÔNG chặn chạy** | Lớp **báo cáo sai** |
+| `/qc-plan` · `/qc-design-test` · `/qc-review-testcase` | **⚠️ cảnh báo, đi tiếp** | Cùng họ `TECHDOC_DRIFT`/`BDD_DRIFT` — 13/17 cờ audit không chặn. Thiết kế TC trên bản hơi cũ vẫn ra sản phẩm dùng được; chặn ở đây là **ồn** |
+| `/qc-run-script` | **chặn `pass`, KHÔNG chặn chạy** | Lớp **báo cáo sai** |
 
 ```
 ⚠️ Stamp lệch — {file} dựng trên {nguồn} {ver_cũ}, hiện tại {ver_mới}.
@@ -120,7 +120,7 @@ Với mỗi artifact mà lệnh này đọc:
    Nên chạy lại: {lệnh}   (đi tiếp vẫn được, nhưng {hệ quả cụ thể})
 ```
 
-**`/qc-run-test` — nhập vào cơ chế đã có, không phát minh cơ chế mới.** Stamp lệch xử lý **y hệt**
+**`/qc-run-script` — nhập vào cơ chế đã có, không phát minh cơ chế mới.** Stamp lệch xử lý **y hệt**
 row `DRIFT`/`ORPHANED` của `positive_assertion_guards` + lint **T12** (G55): test vẫn chạy, nhưng
 xanh → ghi `not_run` chứ **không** ghi `pass`, và **không đóng bug nào** ở lần chạy đó.
 

package/core/steps/report-footer.md

@@ -54,9 +54,9 @@ Discovery → PRD → [Design Spec] → BDD → Tech Design ─┬─ Code → D
 ```
 
 **Sơ đồ rẽ đôi, không phải một dòng thẳng.** `/map-testids` chốt hợp đồng test-id §4.5.6 ở Tech
-Design, nên **Code** và **QC Design** (`/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review`)
+Design, nên **Code** và **QC Design** (`/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review-testcase`)
 đọc cùng một bản đã đóng băng và **chạy song song, không chờ nhau**. Hai nhánh gặp lại ở **QC Run**
-(`/qc-run-test` → `/qc-report`) — trạm duy nhất cần code chạy được.
+(`/qc-run-script` → `/qc-report`) — trạm duy nhất cần code chạy được.
 
 Tìm lệnh hiện tại trong bảng phase dưới đây và đánh dấu **phase của nó** trong sơ đồ trên:
 
@@ -69,8 +69,8 @@ Tìm lệnh hiện tại trong bảng phase dưới đây và đánh dấu **pha
 | Tech Design | `/generate-tech-docs` · `/map-testids` · `/review-tech-docs` |
 | Code | `/generate-code` · `/review-code` |
 | Dev Self-Check | `/dev-gen-test` · `/dev-run-test` · `/dev-smoke-test` |
-| QC Design | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review` |
-| QC Run | `/qc-run-test` · `/qc-report` |
+| QC Design | `/qc-analyze` · `/qc-plan` · `/qc-design-test` · `/qc-review-testcase` · `/qc-automation-assess` |
+| QC Run | `/qc-design-script` · `/qc-review-script` · `/qc-run-script` · `/qc-run-manualtest` · `/qc-report` |
 | Trace Audit | `/validate-traces` |
 
 Với **lệnh review**, thêm vòng review 3 bước và đánh dấu bước hiện tại, vd:
@@ -97,10 +97,11 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |
 | /qc-analyze             | `/qc-plan {TICKET-ID} {platform}` — **cấp PRD**, không phải `{UC-ID}` (xử lý các gap blocker 🔴 trước) |
 | /qc-plan                | `/qc-design-test {UC-ID}`                     |
-| /qc-design-test         | `/qc-review {UC-ID}` (review test-case)       |
-| /qc-review (test-case)  | `/qc-run-test {UC-ID}` nếu APPROVED; sửa TC nếu NEEDS_FIX |
-| /qc-run-test            | `/qc-report {UC-ID}` rồi `/qc-review {UC-ID}` (review script) |
-| /qc-review (script)     | `/qc-report {UC-ID}` rồi tạo PR nếu APPROVED |
+| /qc-design-test         | `/qc-review-testcase {UC-ID}`                 |
+| /qc-automation-assess   | `/qc-design-script {TICKET-ID}` (Automatable: Y) · `/qc-run-manualtest {UC-ID}` (N) |
+| /qc-review-testcase     | `/qc-automation-assess {TICKET-ID}` nếu `APPROVED` hoặc `APPROVED_WITH_SUGGESTIONS`; sửa TC bằng `/qc-design-test` nếu `REVISION_REQUIRED` · `REJECTED` |
+| /qc-run-script          | `/qc-run-manualtest {UC-ID}` (TC Automatable: N) rồi `/qc-report {UC-ID}` |
+| /qc-review-script       | `/qc-report {UC-ID}` rồi tạo PR nếu `APPROVED` hoặc `APPROVED_WITH_SUGGESTIONS`; sửa script nếu `REVISION_REQUIRED` · `REJECTED` |
 | /qc-report              | `/validate-traces {UC-ID}` để làm mới Living Docs (qc_status) |
 | /generate-tech-docs     | `/map-testids {UC-ID}` — chốt hợp đồng test-id §4.5.6 **trước** khi review |
 | /map-testids            | `/review-tech-docs {tech-design-file}` (review CẢ hợp đồng vừa ghi) |
@@ -112,7 +113,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /review-code            | `/dev-smoke-test {UC-ID}` hoặc tạo PR            |
 | /dev-smoke-test             | Tạo PR và link tới ticket                  |
 | /validate-traces        | **Cờ 🔴 trước (chặn PR):** SEAM_UNWIRED → nối binding sang class thật, xoá/thay stub · STUB_UNRESOLVED → `/generate-code {owner_uc}` (lấp logic tại chỗ + xoá hàm song song) · ORPHANED/TRACE_ORPHAN → quyết định thủ công (xoá code+test, đưa scenario trở lại `.feature`, hoặc sửa `sc_id` của tag). **Rồi:** DRIFT/UNTRACKED → `/generate-code {UC-ID}` · BDD_DRIFT → `/generate-code {feature-file}` · tech-doc lỗi thời vs BDD → `/generate-tech-docs` → `/review-tech-docs` · PRD drift → `/generate-bdd {prd-file}` · GAP → `/dev-gen-test {UC-ID}`. **Chỉ tạo PR khi mọi cờ 🔴 = 0** |
-| /fix-bug                | `/dev-run-test {UC-ID}` (dev_selftest vừa reset về not_run) → tạo PR; nếu fix một `{BUG-ID}` → QC chạy `/qc-run-test {UC-ID}` để verify + đóng bug |
+| /fix-bug                | `/dev-run-test {UC-ID}` (dev_selftest vừa reset về not_run) → tạo PR; nếu fix một `{BUG-ID}` → QC chạy `/qc-run-script {UC-ID}` để verify + đóng bug |
 | /debug                  | `/fix-bug {ticket-id}` nếu cần sửa          |
 | /report-bug             | Gửi cho dev (`/fix-bug {BUG-ID}`); nếu thiếu coverage → `/propose-scenario {UC-ID}` |
 | /propose-scenario       | **Case A** (thiếu scenario cho AC có sẵn) → báo PO/Dev review trong `feedback/bdd-proposals/`; `/generate-bdd` tự chèn khi `Status: accepted`. **Case B** (requirement mới) → `feedback/prd-change-requests/` — PO phải đưa vào PRD trước, KHÔNG tự vào BDD được; `/validate-traces` nhắc lại kèm số ngày chờ chừng nào `Status: Open` |

package/docs/02-concepts/pipeline-steps/07-dev-selftest.md

@@ -25,7 +25,7 @@ Trước khi đẩy sang QC chính thức, Dev cần một vòng **kiểm nhanh
 
 > **`dev_selftest` ≠ `qc_status`.** Hai trục **độc lập**: dev smoke (nhanh, tự kiểm) vs QC chính thức (Playwright, evidence). Không lấn quyền nhau.
 >
-> ⚠️ **Nhưng "độc lập" chỉ đúng với `status` về KẾT QUẢ CHẠY, không đúng về QUYỀN KHẲNG ĐỊNH** *(GAPS-v4 G55)*. `pass` mang nghĩa *"scenario này đã được nghiệm thu theo spec **hiện tại**"* — nên trên row `DRIFT`/`ORPHANED`, `/dev-run-test` và `/qc-run-test` **không được** ghi `pass`; chúng hạ về `not_run`. `fail`/`skip` thì ghi bình thường. `lint-trace` **T12** bắt trạng thái `DRIFT + pass` ở sổ thật, bất kể ai ghi ra.
+> ⚠️ **Nhưng "độc lập" chỉ đúng với `status` về KẾT QUẢ CHẠY, không đúng về QUYỀN KHẲNG ĐỊNH** *(GAPS-v4 G55)*. `pass` mang nghĩa *"scenario này đã được nghiệm thu theo spec **hiện tại**"* — nên trên row `DRIFT`/`ORPHANED`, `/dev-run-test` và `/qc-run-script` và `/qc-run-manualtest` **không được** ghi `pass`; chúng hạ về `not_run`. `fail`/`skip` thì ghi bình thường. `lint-trace` **T12** bắt trạng thái `DRIFT + pass` ở sổ thật, bất kể ai ghi ra.
 
 ---
 

package/docs/02-concepts/pipeline-steps/08-qc-automation.md

@@ -3,13 +3,13 @@
 # Bước 8 · QC Automation — Dây chuyền kiểm thử 6 trạm (QC Pipeline)
 
 > **Tóm tắt.** Dây chuyền QC tự động 6 trạm: phân rã yêu cầu → lập kế hoạch → thiết kế test case → review → chạy Playwright → report. Ghi `qc_status` **chính thức** + evidence.
-> **Commands:** `/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review` → `/qc-run-test` → `/qc-report`
+> **Commands:** `/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review-testcase` → `/qc-automation-assess` → `/qc-design-script` → `/qc-review-script` → `/qc-run-script` → `/qc-report`
 
 | | |
 |---|---|
 | **Giai đoạn** | QC Automation |
 | **Owner** | 👤 QA / Tester |
-| **Đầu vào** | **Trạm 1–4:** spec (PRD/BDD `approved`) + **hợp đồng test-id §4.5.6** (đóng băng ở bước 5) — **chưa cần code**.<br/>**Trạm 5 `/qc-run-test` thêm:** code đã chạy được — **trạm duy nhất** cần |
+| **Đầu vào** | **Trạm 1–4:** spec (PRD/BDD `approved`) + **hợp đồng test-id §4.5.6** (đóng băng ở bước 5) — **chưa cần code**.<br/>**Trạm 6–8 `/qc-design-script` · `/qc-run-script` thêm:** code đã chạy được — **hai trạm duy nhất** cần |
 | **Đầu ra** | Test case, script Playwright, `qc_status`, evidence, product-gap |
 | **HITL** | 🟠 Vừa — cổng review case & script trước khi chạy |
 
@@ -17,11 +17,11 @@
 
 ## Mục đích (Purpose)
 
-Đây là **kiểm thử chính thức** (khác với dev smoke). Dùng module **`qc-playwright`** (Python + pytest-playwright + Page Object) — độc lập với module implementation của dev. Bước này:
+Đây là **kiểm thử chính thức** (khác với dev smoke). Dùng module QC theo nền — **`qc-playwright-ts`** (web·system) hoặc **`qc-wdio-appium`** (app), phân giải ở `steps/qc-scope.md` §2b — độc lập với module implementation của dev. Bước này:
 
 - Phân rã yêu cầu thành test case bám scenario, phát hiện **gap tài liệu**.
 - Chạy test thật, ghi **`qc_status` chính thức** + **evidence**.
-  ⚠️ Nhưng `/qc-run-test` **đọc cột `status` trước khi ghi `pass`** *(GAPS-v4 G55)*: row `DRIFT`/`ORPHANED` + test xanh → hạ về `not_run`, và **không** đóng bug nào ở lần chạy đó. `fail`/`skip` ghi bình thường.
+  ⚠️ Nhưng `/qc-run-script` và `/qc-run-manualtest` **đọc cột `status` trước khi ghi `pass`** *(GAPS-v4 G55)*: row `DRIFT`/`ORPHANED` + test xanh → hạ về `not_run`, và **không** đóng bug nào ở lần chạy đó. `fail`/`skip` ghi bình thường.
 - Phân loại FAIL thành **ba** nhãn — `script-bug` · `product-gap` · `flaky` — **sau khi đã chạy lại tối đa 2 lần**. Một test đỏ **một lần** chưa nói được nó đỏ vì cái gì.
 - Đẩy **product-gap** ngược về PO/Dev.
 
@@ -32,15 +32,15 @@
 - **UC-ID** + platform (QC pass khoá 1 platform).
 - Spec: PRD / `.feature` (từ spec repo, qua `spec_source`).
 - **Hợp đồng test-id**: `@trace.testid_attr` (header tech-doc, **tên** thuộc tính) + §4.5.6 Test Selectors (**giá trị** test-id, cột *Serves SC* là chỉ mục ngược). Đã chốt ở [bước 5](05-tech-docs.md) **trước khi có code**.
-- Code đã sinh & chạy được — **chỉ `/qc-run-test` cần**. Bốn trạm đầu (`/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review`) chạy **song song với FE** vì chỉ cần spec + hợp đồng test-id. Đó là chỗ hai nhánh của [bước 5](05-tech-docs.md) gặp lại.
-- `qc_dir` (working docs của QC) + module `qc-playwright`.
+- Code đã sinh & chạy được — **chỉ `/qc-design-script` và `/qc-run-script` cần**. Bốn trạm đầu (`/qc-analyze` → `/qc-plan` → `/qc-design-test` → `/qc-review-testcase`) chạy **song song với FE** vì chỉ cần spec + hợp đồng test-id. Đó là chỗ hai nhánh của [bước 5](05-tech-docs.md) gặp lại.
+- `qc_dir` (working docs của QC) + module QC theo nền (`qc-playwright-ts` · `qc-wdio-appium`).
 
 ## Output (Đầu ra)
 
 | Artifact | Nội dung |
 |----------|----------|
 | `docs/{TICKET-ID}/{platform}/…` | `REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`, `test-cases/*.Test.md` — **mỗi loại đúng một file cho cả (PRD × nền)**, các UC là hàng/mục bên trong (cột `UC`) |
-| Script Python pytest-playwright | Sinh từ `.Test.md` đã review |
+| Script TypeScript (`*.spec.ts`) | Sinh từ `.Test.md` đã review |
 | Cột `qc_status` trong `.trace/…/{UC-ID}-{platform}.tsv` | Trạng thái QC **chính thức** |
 | Evidence + report | `/qc-report` — kèm product-gap đẩy về PO/Dev |
 
@@ -75,8 +75,9 @@ Dây chuyền **6 trạm**, output trạm trước là input trạm sau:
 | 1 | `/qc-analyze` | Phân rã yêu cầu + phát hiện **gap tài liệu** (`DOC_GAP.md`) | **Guard BR-tag** |
 | 2 | `/qc-plan` | Đánh giá **rủi ro** + câu hỏi cho dev (`TEST_PLAN.md`) | — |
 | 3 | `/qc-design-test` | Thiết kế **test case** dạng Markdown (`*.Test.md`) | **Guard SC coverage** |
-| 4 | `/qc-review` | 🛑 **Cổng review** hai chiều: test case & script trước khi chạy | — |
-| 5 | `/qc-run-test` | Sinh & chạy **pytest-playwright**, ghi **`qc_status`** chính thức | **chạy lại ×2 + 3 nhãn FAIL** |
+| 4 | `/qc-review-testcase` | 🛑 **Cổng review test case** — verdict `APPROVED`/`NEEDS_FIX` là điều kiện tiên quyết của trạm sau | — |
+| 6 | `/qc-review-script` | 🛑 **Cổng review script** — biên bản riêng `REVIEW_SCRIPT_<FEATURE>.md` | — |
+| 5–8 | `/qc-design-script` · `/qc-run-script` | Sinh rồi chạy **script TypeScript**, ghi **`qc_status`** chính thức | **chạy lại ×2 + 3 nhãn FAIL** |
 | 6 | `/qc-report` | Report + **evidence**, đẩy **product-gap** về PO/Dev | — |
 
 ### Hai Guard cơ học — chống bỏ sót **im lặng**
@@ -120,14 +121,14 @@ Cả sáu trạm nạp chung `skills/qc/_shared/self-review-principles.md` và c
 
 > ⚠️ **Self-review KHÔNG thay Guard.** Guard là phép **đếm cơ học**, có hệ quả bắt buộc. Self-review là lượt đọc lại **rộng hơn nhưng mềm hơn**. Một bộ nguyên tắc tự soát **không bao giờ** được dùng làm lý do gỡ một guard — file đó ghi rõ ranh giới này ngay ở đầu.
 
-- Stack QC bắt buộc theo `modules/qc-playwright/stack-profile.yaml`: Python + pytest-playwright + Page Object; mỗi test độc lập; gom theo (role, account) để auth không xen kẽ.
+- Stack QC bắt buộc theo `stack-profile.yaml` của module đã phân giải (§2b): TypeScript + Playwright Test (web·system) / WebdriverIO + Appium (app); mỗi test độc lập; gom theo (role, account) để auth không xen kẽ.
 - **Locator lấy từ hợp đồng, không dò DOM**: thứ tự ưu tiên là §4.5.6 → `@trace.testid_attr` → mới tới các cách khác. Skill `qa-runner` đã bỏ hết chỉ dẫn "dò DOM trước".
 
 ---
 
 ## HITL / Gate
 
-- 🛑 `/qc-review` — **cổng review** case & script: không chạy test kém.
+- 🛑 `/qc-review-testcase` · `/qc-review-script` — **hai cổng review riêng**: không chạy test kém, và trạm sau đọc được verdict của ĐÚNG vai nó cần.
 - 🛑 **Xác nhận phân loại FAIL** — mỗi FAIL phải được người chốt nhãn trước khi ghi `qc_status`. Đây là cổng chặn hiếm hoi được **thêm vào** (framework vốn đang giảm số cổng), vì **cả hai hướng sai đều không đảo ngược rẻ**.
 - **Không fake-pass**: FAIL là product-gap → giữ nguyên FAIL + evidence, đẩy về PO/Dev.
 
@@ -137,7 +138,7 @@ Cả sáu trạm nạp chung `skills/qc/_shared/self-review-principles.md` và c
 
 - ❌ Lẫn `qc_status` với `dev_selftest` — hai trục độc lập.
 - ❌ Sửa script cho "xanh" khi thực chất là product-gap → giấu lỗi sản phẩm.
-- ❌ Chạy `/qc-run-test` khi chưa qua cổng `/qc-review`.
+- ❌ Chạy `/qc-design-script` khi chưa qua cổng `/qc-review-testcase`.
 - ❌ **Kết luận từ một lần chạy đỏ** — chưa loại nhiễu thì chưa phân biệt được `flaky` với lỗi thật.
 - ❌ **Tự dò selector từ DOM** thay vì đọc §4.5.6 — script giòn, dev đổi một class là vỡ mà không ai báo.
 - ❌ Dùng self-review làm lý do **bỏ qua** một Guard.