@educa-corp/sdd-framework 0.9.5 → 0.9.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (55) hide show
  1. package/bin/build.js +11 -1
  2. package/bin/lint-trace.js +397 -28
  3. package/bin/self-check.js +183 -12
  4. package/bin/trace-schema.json +2656 -1981
  5. package/core/FRAMEWORK_VERSION +1 -1
  6. package/core/commands/dev-gen-test.md +62 -0
  7. package/core/commands/generate-code.md +1 -1
  8. package/core/commands/generate-tech-docs.md +3 -3
  9. package/core/commands/map-testids.md +88 -11
  10. package/core/commands/qc-analyze.md +509 -425
  11. package/core/commands/qc-design-test.md +475 -247
  12. package/core/commands/qc-plan.md +134 -93
  13. package/core/commands/qc-review.md +216 -131
  14. package/core/commands/qc-run-test.md +346 -231
  15. package/core/commands/validate-traces.md +17 -2
  16. package/core/rules/workflow.md +40 -0
  17. package/core/skills/qc/qa-analyst/DOC_GAP.template.md +9 -1
  18. package/core/skills/qc/qa-designer/shared/duplicate-check-procedure.md +33 -5
  19. package/core/skills/qc/qa-designer/shared/tc-metadata-format.md +24 -0
  20. package/core/skills/qc/qa-planner/test-plan.md +7 -0
  21. package/core/skills/qc/qa-runner/functional/gui-feature.md +1 -1
  22. package/core/skills/qc/qa-runner/functional/gui-screen.md +1 -1
  23. package/core/steps/qc-scope.md +67 -11
  24. package/core/steps/qc-stamp.md +142 -0
  25. package/core/steps/report-footer.md +13 -5
  26. package/core/templates/tech-design.template.md +3 -3
  27. package/docs/01-getting-started/quickstart.md +4 -3
  28. package/docs/02-concepts/architecture.md +14 -0
  29. package/docs/02-concepts/glossary.md +8 -0
  30. package/docs/02-concepts/overview.md +3 -2
  31. package/docs/02-concepts/pipeline-steps/04-bdd.md +1 -1
  32. package/docs/02-concepts/pipeline-steps/05-tech-docs.md +21 -5
  33. package/docs/02-concepts/pipeline-steps/06-code.md +12 -2
  34. package/docs/02-concepts/pipeline-steps/08-qc-automation.md +60 -12
  35. package/docs/02-concepts/pipeline-steps/README.md +4 -3
  36. package/docs/02-concepts/traceability.md +2 -2
  37. package/docs/03-guides/architect.md +2 -2
  38. package/docs/03-guides/developer.md +5 -2
  39. package/docs/03-guides/tester-qa.md +17 -5
  40. package/docs/04-reference/commands.md +6 -3
  41. package/docs/04-reference/trace-schema.md +1 -1
  42. package/docs/explain/07-generate-tech-docs.md +5 -3
  43. package/docs/explain/08-review-tech-docs.md +15 -3
  44. package/docs/explain/09-generate-code.md +30 -4
  45. package/docs/explain/10-review-code.md +1 -1
  46. package/docs/explain/11-map-testids.md +72 -70
  47. package/docs/explain/12-dev-gen-test.md +1 -1
  48. package/docs/explain/15-qc-analyze.md +14 -2
  49. package/docs/explain/16-qc-plan.md +5 -1
  50. package/docs/explain/17-qc-design-test.md +26 -3
  51. package/docs/explain/18-qc-review.md +6 -2
  52. package/docs/explain/19-qc-run-test.md +29 -6
  53. package/docs/explain/20-qc-report.md +5 -2
  54. package/docs/explain/README.md +4 -1
  55. package/package.json +1 -1
@@ -1,17 +1,19 @@
1
- ---
2
- version: 1.0
3
- updated: 2026-09-04
4
- ported_from: ai-automation-qc-base
5
- ---
6
-
7
- # /qc-design-test — QC Test-Case Design
8
-
9
- > Stage 3 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-designer của team QC. Sinh test case Markdown (`.Test.md`) — Python đến sau ở /qc-run-test.
10
-
11
- ## Gate
12
-
13
- *Checkpoint: **chặn thường** — lệnh ghi file test-case. `--yes` bỏ qua được (gate Bước 3a).*
14
-
1
+ ---
2
+ version: 1.0
3
+ updated: 2026-09-04
4
+ ported_from: ai-automation-qc-base
5
+ ---
6
+
7
+ # /qc-design-test — QC Test-Case Design
8
+
9
+ > Stage 3 của QC automation pipeline native (qc-analyze → qc-plan → qc-design-test → qc-review → qc-run-test → qc-report). Port từ qa-designer của team QC. Sinh test case Markdown (`.Test.md`) — Python đến sau ở /qc-run-test.
10
+
11
+ ## Gate
12
+
13
+ *Checkpoint: **chặn CỨNG** — ghi đè `*.Test.md` đã qua cổng HITL `/qc-review` → mất `Status` đã duyệt, `Expected Result` đã sửa theo finding, dấu 🚫 Block vừa gỡ; và ĐÁNH SỐ LẠI `TC_<FEATURE>_NNN` mà `REVIEW_<FEATURE>.md` đang trỏ vào. `--yes` KHÔNG bỏ qua được (gate Bước 3a).*
14
+
15
+ *Mức cứng chỉ áp khi file `.Test.md` **đã tồn tại**. Lần thiết kế đầu không ghi đè gì, đi thẳng. Xem §Chạy lại.*
16
+
15
17
  # Gate — Quy trình vào chuẩn cho mọi lệnh
16
18
 
17
19
  Mọi lệnh PHẢI chạy gate này trước khi thực thi phần logic riêng của nó.
@@ -163,247 +165,473 @@ Mỗi dòng ⚠️/🔴 phải ứng với một trạng thái **context-loader
163
165
  - "N" → dừng, hỏi người dùng muốn thay đổi gì.
164
166
  - Có `--yes` và mức *chặn thường* → coi như "Y", **nhưng vẫn IN khối CHECKPOINT** nếu có cờ
165
167
  🔴/⚠️ (không chặn ≠ không báo — người đọc log sau này vẫn cần thấy).
166
-
167
-
168
- *Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID. Đọc output của qc-analyze + qc-plan (`REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`) từ `{qc_artifact_dir}` — **cả ba đều ở cấp PRD, lọc theo cột `UC`** để lấy phần của UC này — và file `.feature` của đúng platform đó (với `@trace.scenario` mỗi scenario). Với layer GUI, cũng đọc bảng **Test Selectors** §4.5.6 (block platform) của tech-doc gộp tại `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/{TICKET-ID}-tech-design.md` (nếu có — bảng gộp mọi UC của platform, **lọc theo cột "Phục vụ SC" khớp SC của UC này**) — các test-id ổn định mà QC sẽ định vị theo.*
169
-
170
- ## Context
168
+
169
+
170
+ *Lưu ý: Với lệnh này, target ở Bước 1 là một UC-ID. Đọc output của qc-analyze + qc-plan (`REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`) từ `{qc_artifact_dir}` — **cả ba đều ở cấp PRD, lọc theo cột `UC`** để lấy phần của UC này — và file `.feature` của đúng platform đó (với `@trace.scenario` mỗi scenario). Với layer GUI, cũng đọc bảng **Test Selectors** §4.5.6 (block platform) của tech-doc gộp tại `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/{TICKET-ID}-tech-design.md` (nếu có — bảng gộp mọi UC của platform, **lọc theo cột "Serves SC" khớp SC của UC này**) — các test-id ổn định mà QC sẽ định vị theo.*
171
+
172
+ ## Context
171
173
  **BẮT BUỘC — đọc `.agent/steps/context-loader.md` và thực thi TOÀN BỘ quy trình trong đó**,
172
174
  rồi mới tiếp tục phần bên dưới.
173
175
 
174
176
  Bỏ qua bước này thì `{paths.*}`, `{tech_stack.*}`, `{conventions.*}`, guardrail từ
175
177
  `project-lessons`, và routing service (chế độ umbrella) đều **chưa được phân giải** — mọi
176
- placeholder bên dưới sẽ rỗng và lệnh sẽ đọc/ghi sai chỗ.
177
-
178
- ## Phạm vi QC
179
-
178
+ placeholder bên dưới sẽ rỗng và lệnh sẽ đọc/ghi sai chỗ.
179
+
180
+ ## Phạm vi QC
181
+
180
182
  **BẮT BUỘC — đọc `.agent/steps/qc-scope.md` và thực thi TOÀN BỘ quy trình trong đó**,
181
183
  rồi mới tiếp tục phần bên dưới.
182
184
 
183
185
  Nó chốt bốn thứ mà mọi trạm QC đều cần: `TICKET-ID` · `active_platform` ·
184
- `qc_artifact_dir` · `uc_list` (kèm trạng thái BDD từng UC, và cờ `--include-draft`).
186
+ `qc_artifact_dir` · `uc_list` (kèm trạng thái BDD từng UC, và cờ `--force`).
185
187
  Bỏ qua thì artifact QC ghi vào **sai thư mục** và `qc_status` ghi vào **sai sổ trace** —
186
- cả hai đều xảy ra trong im lặng, không có bước nào phía sau bắt được.
187
-
188
- > **Trạm này vẫn gọi theo TỪNG UC** *(B11)* — thiết kế và chạy test **thật sự** làm tăng dần
189
- > theo UC, nên giữ khả năng làm UC1 khi UC3 chưa xong là đúng. Chỉ **chỗ đọc/ghi** đổi: mọi
190
- > artifact nằm chung ở `{qc_artifact_dir}` cấp PRD, không còn một thư mục mỗi UC.
191
- >
192
- > Nên `DOC_GAP.md` / `TEST_PLAN.md` đọc được đây phủ **cả PRD**: **lọc theo cột `UC`** để lấy
193
- > phần của UC đang làm. Đừng coi toàn bộ bảng gap là của UC này — sẽ chặn oan.
194
-
195
- ---
196
-
197
- ## Cờ chọn tầng nào, tách mịn đến đâu
198
-
199
- | Cờ | Ghi file | Nhóm |
200
- |---|---|---|
201
- | *(không cờ)* | `TC_<FEATURE>.Test.md` | 1 GUI · 2 Validation · 3 Functional · 4 Integration (qua UI) · 5 NFR · 6 E2E |
202
- | `--api` | `TC_<FEATURE>_API.Test.md` | 1 Endpoint · 2 Integration API/DB/Kafka |
203
- | `--all` | **cả hai file** | như trên, hai file riêng biệt |
204
- | `--atomic-max` | | bật chế độ tách tối đa (xem dưới) |
205
-
206
- **Câu hỏi phân file:** *"TC này verify được mà **không cần UI** không?"* → **có** = file API ·
207
- **không** = file giao diện. Đây đúng là Bước 2 của
208
- `{paths.qc_skills_dir}/qa-designer/shared/skill-decision-tree.md`.
209
-
210
- > **Vì sao hai file riêng chứ không một file rồi ghi từng nhóm** *(B12)*. `--api` chạy sau khi
211
- > file giao diện đã tồn tại chuyện thường. Nếu chung một file, lần chạy `--api` phải **giữ
212
- > nguyên** năm nhóm kia viết-lại-cả-file đúng thứ agent hay làm. Hai file thì hai chế
213
- > độ **không bao giờ chạm nhau**, và không cần tin vào việc agent nhớ giữ phần cũ.
214
-
215
- ### `--atomic-max` — tách tới mức nhỏ nhất
216
-
217
- Mặc định đã ATOMIC (mỗi TC đúng một kết cục), nhưng **cho phép** bullet compound khi cả hai
218
- vế nói về **cùng một** kết cục dụ *"form hiển thị đủ 3 trường"* vẫn 1 TC.
219
-
220
- `--atomic-max` **nổ danh sách completeness thành từng thành phần**: thẻ hiển thị đủ 5 thông tin
221
- → **5 TC**. Ở đội QC, một tính năng đi từ 82 lên 130 TC.
222
-
223
- **⛔ Thủ tục bắt buộc TRƯỚC khi ghi** *(theo `shared/precision-rules.md` §2.1)*:
224
-
225
- 1. **Chốt ranh giới completeness** — hai mức có quy mô rất khác nhau:
226
- | Giá trị | Nghĩa |
227
- |---|---|
228
- | `--atomic-max=keep-completeness` | giữ danh sách completeness là 1 TC (~95 TC ở ví dụ thật) |
229
- | `--atomic-max=explode` | nổ từng thành phần (~130 TC) |
230
-
231
- Không nêu giá trị **HỎI** trước khi ghi, đây quyết định quy của người chủ, không
232
- phải của agent. **Có `--yes`:** không hỏi — **DỪNG** với lỗi rõ ràng:
233
- ```
234
- --atomic-max cần nêu ranh giớichế độ headless (quy chênh ~35%).
235
- Chạy: /qc-design-test {UC-ID} --atomic-max=explode --yes
236
- hoặc --atomic-max=keep-completeness --yes
237
- ```
238
- *(Một cổng chỉ chặn được khi người ngồi đó thì chế độ headless không phải cổng, nó
239
- treo cùng bài học với `steps/qc-scope.md` §2.)*
240
-
241
- 2. **Dựng bản đồ tách trước khi ghi** mỗi TC cha tách ra mấy mảnh. Đừng để agent con tự suy
242
- trong lúc ghi; đó chỗ sinh ra TC cắt cụt.
243
- 3. **GIỮ 1 TC** cho bốn loại này kể cả ở chế độ tối đa: *predicate đa-điều-kiện định-nghĩa-một-
244
- khái-niệm* · *ngưỡng* (`≥44pt`, `WCAG AA ≥4.5:1`) · *exclusivity* chọn-một · *qualifier*.
245
- 4. **Verify bằng DIFF, không tin lời đếm của agent** — ID liên tục · mỗi Expected 1 bullet ·
246
- 0 ký tự `|` · Trace matrix không còn ID chết · P0/P1 khớp tag.
247
-
248
- ---
249
-
250
- ## Role
251
-
252
- Bạn **QC Designer** stage 3. Sinh/bảo trì các file test-case Markdown
253
- (`.Test.md`) từ requirement đã phân tích + plan. Output feed vào qc-run-test (Python) và
254
- qc-review. Bạn **không** viết Python.
255
-
256
- ## Skills (`{paths.qc_skills_dir}/qa-designer/`)
257
-
258
- **Luật dùng chung — nạp theo tầng, không nạp hết mỗi lần:**
259
-
260
- | Khi nào | Nạp |
261
- |---|---|
262
- | **Luôn** | `shared/tc-metadata-format.md` — khuôn TC · luật ATOMIC · phân nhóm · hai file `.Test.md` · Trace · `🚫 Block` · `Test-ID attribute` |
263
- | **Luôn** | `shared/precision-rules.md` cấm 9 cụm mơ hồ · đơn vị theo domain · toán tử · BVA 3-hay-4 giá trị · phủ đủ ô decision table · 3 mức teardown |
264
- | **Luôn** | `shared/action-keywords-glossary.md` — một hành động một từ (Click/Tap/Enter/Select…) |
265
- | **Luôn** | `shared/implicit-scenarios.md` 7 tình huống bắt buộc nghĩ tới, áp cho mọi nhóm |
266
- | Đầu phiên, một lần | `shared/read-doc-gap-inputs.md` đọc **đủ** mọi file trong bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md`, không chỉ đọc bản tóm tắt gap |
267
- | Không chắc chọn tầng nào | `shared/skill-decision-tree.md` cây quyết định UI / Integration-GUI / E2E / Integration |
268
- | Thêm TC vào file đã có | `shared/duplicate-check-procedure.md` grep trước khi viết; **trùng chéo UC** giờ mới thực sự xảy ra vì mọi UC dùng chung một thư mục |
269
- | `--api` / `--all` | `api/endpoint.md` · `api/auth-chain.md` · `api/http-status-codes.md` · `api/common-headers.md` · `api/crud-sequence.md` · `api/auth-sequence.md` |
270
-
271
- **Rồi chọn tầng, nạp MỘT file:**
272
-
273
- | Layer | File | Ghi vào |
274
- |---|---|---|
275
- | 1 màn hình | `functional/gui-screen.md` | file giao diện |
276
- | Feature đa-màn | `functional/gui-feature.md` | file giao diện |
277
- | API endpoint | `functional/api.md` | **file API** |
278
- | Integration qua UI | `integration/gui.md` | file giao diện |
279
- | Integration API/DB/Kafka | `integration/{api,db,kafka}.md` | **file API** |
280
- | End-to-end journey | `e2e/journey.md` | file giao diện |
281
- | Non-functional | `non-functional.md` | theo câu hỏi phân file |
282
- | Exploratory | `exploratory/{charter,explore-to-functional}.md` | file giao diện |
283
-
284
- ## Conventions
285
-
286
- *Khuôn TC, luật ATOMIC, phân nhóm, không-dùng-bảng, Trace, `🚫 Block`, `Test-ID attribute` —
287
- đều `shared/tc-metadata-format.md`. **Đừng lặp lại đây.** Dưới đây chỉ là thứ riêng của trạm:*
288
-
289
- - Markdown-first; đừng design khi requirement chưa đẩy ngược về qc-plan/qc-analyze.
290
- - **Tham chiếu test-id, không phải gợi ý hình ảnh.** Với mỗi step GUI tác động lên một element, trích test-id ổn định từ bảng §4.5.6 của tech-doc gộp (vd "click `ft001-login-submit-btn`") để qc-run-test dựng locator từ contract. Nếu một element có action không có test-id trong §4.5.6, ghi chú lại (qc-run-test sẽ fallback về locator role/text chậm hơn).
291
- - **Đọc `@trace.testid_attr` từ header tech-doc gộp** (do `/map-testids` ghi) và ghi lại một
292
- dòng `Test-ID attribute: {attr}` metadata đầu file `.Test.md`. §4.5.6 chỉ cho **giá trị**
293
- test-id; `@trace.testid_attr` **tên thuộc tính** chứa chúng `/qc-run-test` cần nó để cấu
294
- hình locator, `/qc-review` cần nó để biết selector trong script có đúng contract không.
295
- Không đọc được `@trace.testid_attr` → ghi
296
- `Test-ID attribute: (thiếu @trace.testid_attr, chạy /map-testids)`; **đừng bỏ trống, đừng
297
- tự đoán theo platform** — đoán sai thì mọi locator trượt 100%, vì một lý do không liên quan
298
- tới thứ đang được test. *(Dạng dòng metadata: `shared/tc-metadata-format.md`.)*
299
- - Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md) lý do`.
300
- Chặn theo **UC ở cột `UC` của hàng gap đó**, không chặn cả PRD.
301
-
302
- ## Trace mapping (bắt buộc)
303
-
304
- Ngoài trace `BR-xx`, mỗi TC ghi scenario framework mà nó verify — **dạng trường danh sách,
305
- không phải cột bảng** (file TC không tự `|`):
306
-
307
- ```
308
- - **@trace.verifies:** {UC-ID}-SC{N}
309
- ```
310
-
311
- Lấy từ `@trace.scenario` của `.feature`. Một SC map được nhiều TC. Đây là **join key** cho phép
312
- qc-run-test ghi `qc_status` theo từng scenario vào sổ trace — **thiếu nó thì test vẫn chạy,
313
- vẫn pass/fail, nhưng kết quả không vào được sổ và không ai biết nó phủ kịch bản nào.**
314
-
315
- Cuối file: **Trace matrix** (BR ↔ TC ↔ SC) + **danh sách TC bị block** — cả hai dạng danh sách.
316
-
317
- ## Guard SC coverage *(phép ĐẾM học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
318
-
319
- Dòng `Trace:` ở report cuối đã đòi con số `{K}/{total}` từ trước. Guard này là **phép tính sinh
320
- ra con số đó**, và là **hệ quả khi `K < total`** — trước đây có số mà không có phép tính nào
321
- đứng sau, nên nó là ước lượng, và `K < total` không dẫn tới việc gì.
322
-
323
- ### Ba bước
324
-
325
- 1. **Thu SC** — mọi `@trace.scenario` trong `.feature` của `uc_list` (đúng `active_platform`).
326
- **Loại** SC của UC mà `qc-scope` đã lọc ra (`⏸ chưa xét` BDD chưa approved): chúng nằm
327
- ngoài phạm vi lần chạy này, không phải bỏ sót.
328
- 2. **Thu V** mọi `@trace.verifies` trong các file `*.Test.md` **vừa ghi**.
329
- 3. **Đếm** mỗi SC tập bước 1 phải **≥ 1** TC trỏ tới.
330
-
331
- ### Xử
332
-
333
- | Kết quả | Làm |
334
- |---|---|
335
- | Mọi SC đều ≥1 TC | in `Guard SC coverage: khớp {K}/{K}` |
336
- | Có SC chưa phủ | **viết bù TC ngay**, rồi in `⚠️ Guard SC coverage: {K}/{total} — đã bù {m} SC: {danh sách}` |
337
-
338
- **Không có đường "bỏ trống có lý do".** Đây là chỗ dễ làm sai nhất, và quy ước ở §Conventions
339
- đã trả lời: *"Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md)`"*.
340
- Nghĩa **gap không phải cái cớ để không viết TC** — nó là thứ được **ghi vào TC**. SC bị chặn
341
- vẫn TC, vẫn được đếm đã phủ.
342
-
343
- Nên chỉ còn đúng hai trạng thái, cả hai đều không cho phép bỏ trống:
344
-
345
- - SC **trong** phạm vi phải TC (bị gap chặn thì TC mang dấu `🚫 Block`).
346
- - SC **ngoài** phạm vi → đã bị `qc-scope` lọc bước 1, không tính vào mẫu số.
347
-
348
- Nếu bạn thấy một SC "không thể viết TC" mà không thuộc hai loại trên, thì **đó là một gap** —
349
- mở gap trong `DOC_GAP.md`, viết TC kèm `🚫 Block` trỏ tới nó. Đừng viết một câu lý do rồi đi
350
- tiếp: guard viết lỏng thì lần sau sẽ có một câu lý do cho qua, phép đếm mất nghĩa.
351
-
352
- **In dòng `Guard SC coverage:` kể cả khi sạch** — guard im lặng khi sạch là guard không ai biết
353
- tồn tại, không ai phát hiện được khi chết.
354
-
355
- > **Vì sao đếm đây không đợi báo cáo cuối.** `/qc-report` (Đợt 3 của đợt mổ QC) sẽ tính
356
- > **design coverage** bằng **đúng phép đếm này**. Khác nhau thời điểm: guard đếm **lúc thiết
357
- > kế** còn kịp viết bù; báo cáo đếm **ở cuối** chỉ còn kịp báo. Phát hiện "design coverage
358
- > 68%" phút cuối lúc không còn thời gian viết 32%.
359
- >
360
- > **Vì sao "chưa TC" khác "có TC nhưng chưa chạy".** Hai trạng thái này dẫn tới hai việc khác
361
- > nhau hoàn toànviết test, so với chạy test. Nhưng nhìn vào sổ trace thì giống nhau: cả hai
362
- > đều `qc_status = not_run`. Guard này chỗ duy nhất phân biệt được.
363
-
364
- ## Output
365
-
366
- Ghi dưới `{qc_artifact_dir}test-cases/`
367
- (= `{paths.qc_dir}/{TICKET-ID}/{active_platform}/test-cases/`) — **một thư mục dùng chung cho cả
368
- PRD**. Tên file mang `<FEATURE>` nên các UC không đâm nhau; `@trace.verifies` chỗ phân biệt
369
- TC thuộc UC nào.
370
-
371
- **Đuôi bắt buộc là `.Test.md`.** `/qc-run-test` và `/qc-review` tìm `*.Test.md`; ghi ra
372
- `TC_<FEATURE>.md` ghi ra thứ **không trạm nào tìm thấy**, và **không có gì báo lỗi**.
373
-
374
- `🚫 Block` trỏ `../DOC_GAP.md` — lên một cấp, vì file gap ở thư mục cha của `test-cases/`.
375
-
376
- ## Self-Review *(trước khi in Report)*
377
-
378
- Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — **không chép lại ở đây**.
379
-
380
- - **Bịa:** mỗi TC kiểm một hành vi **spec có nêu** — không phải hành vi tôi cho là hợp lý? Mỗi
381
- `Expected` **giá trị cụ thể** (*"hiển thị text 'Tên lớp: Toán 6A'"*), không phải *"hiển thị
382
- đúng"* / *"hoạt động bình thường"*?
383
- - **Nhảy bước:** đã áp luật ATOMIC cho **mọi** TC (không chỉ vài TC đầu), đã chạy
384
- §duplicate-check trước khi thêm TC mới?
385
- - **Số liệu:** `{n}` TC mỗi file = `grep -cE "^#{2,4} *TC_"` thật? Các con số phân nhóm (GUI /
386
- Validation / Functional / …) cộng lại đúng bằng tổng TC?
387
-
388
- > Guard SC coverage ở trên là **phép đếm cơ học**, không phải self-review — nó đối chiếu với
389
- > `.feature`, một nguồn khác. Đừng coi self-review đã bao nó. Xem §Ranh giới trong file skill.
390
-
391
- ## Report
392
-
188
+ cả hai đều xảy ra trong im lặng, không có bước nào phía sau bắt được.
189
+
190
+ ---
191
+
192
+ ## Stamp phiên bản nguồn
193
+
194
+ **BẮT BUỘC đọc `.agent/steps/qc-stamp.md` thực thi phần áp cho lệnh này**,
195
+ rồi mới tiếp tục phần bên dưới.
196
+
197
+ Nó có **hai vế**: §1 **ghi** khối `Nguồn & phiên bản` vào artifact lệnh này sinh ra ·
198
+ §2 **so** stamp của artifact lệnh này ĐỌC với version hiện tại của spec.
199
+ Bỏ vế ghi thì trạm sau không để so; bỏ vế so thì stamp thành một con số không ai
200
+ đọc — và một bộ TC lỗi thời sẽ chạy xanh rồi ghi `pass` **hợp lệ theo mọi phép kiểm**.
201
+
202
+ > **Trạm này vẫn gọi theo TỪNG UC** *(B11)* — thiết kế và chạy test **thật sự** làm tăng dần
203
+ > theo UC, nên giữ khả năng làm UC1 khi UC3 chưa xong đúng. Chỉ **chỗ đọc/ghi** đổi: mọi
204
+ > artifact nằm chung ở `{qc_artifact_dir}` cấp PRD, không còn một thư mục mỗi UC.
205
+ >
206
+ > Nên `DOC_GAP.md` / `TEST_PLAN.md` đọc được đây phủ **cả PRD**: **lọc theo cột `UC`** để lấy
207
+ > phần của UC đang làm. Đừng coi toàn bộ bảng gap là của UC này — sẽ chặn oan.
208
+
209
+ ---
210
+
211
+ ## Guard — tiền đề *(chạy NGAY SAU §Phạm vi QC, TRƯỚC mọi việc khác của lệnh)*
212
+
213
+ Trạm này **trạm 3**. **tiêu thụ** output của trạm 1 trạm 2 không tự sinh lại được.
214
+ Kiểm sự tồn tại của cả ba file dưới `{qc_artifact_dir}`:
215
+
216
+ | File | Do lệnh nào sinh | Trạm này dùng để |
217
+ |---|---|---|
218
+ | `REQUIREMENT_ANALYSIS.md` | `/qc-analyze` | neo `BR-xx`/`AC-xx` cho trường `Trace:` của mỗi TC |
219
+ | `DOC_GAP.md` | `/qc-analyze` | gắn `🚫 Block` cho TC bị gap chặn |
220
+ | `TEST_PLAN.md` | `/qc-plan` | độ sâu theo rủi ro (P0/P1) · layer trong scope · entry criteria |
221
+
222
+ **Thiếu bất kỳ file nào DỪNG.** Không hỏi Y/N, không cảnh báo rồi đi tiếp:
223
+
224
+ ```
225
+ {TICKET-ID} ({active_platform}): thiếu đầu vào của trạm 3.
226
+ Không có: {danh sách file thiếu}
227
+ Chạy trước: /qc-analyze {TICKET-ID} {active_platform}
228
+ rồi: /qc-plan {TICKET-ID} {active_platform}
229
+ ```
230
+
231
+ **Đủ cả ba im lặng, đi tiếp.** Guard này là **điều kiện vào cửa**, không phải phép đo: "đủ file"
232
+ không phải một phát hiện, nên không in dòng nào. *(Khác `Guard BR-tag` và `Guard SC coverage` —
233
+ hai cái đó phép ĐẾM, con số của chúng giá trị ngay cả khi sạch, nên chúng luôn in.)*
234
+
235
+ > **Vì sao DỪNG chứ không cảnh báo rồi chạy.** Guard duy nhất còn lại của trạm này —
236
+ > `Guard SC coverage` đối chiếu TC với `.feature`, mà `.feature` spec repo thì **luôn mặt**,
237
+ > không mất theo khi trạm 1–2 chưa chạy. Nên nó vẫn in `khớp K/K` lần chạy thiếu đầu vào
238
+ > **không phân biệt được** với một lần chạy đúng.
239
+ >
240
+ > Thiếu `DOC_GAP.md` ca đắt nhất: TC bị gap chặn **trông y hệt** TC bình thường (không dấu
241
+ > `🚫 Block` nào), nên `/qc-run-test` chạy nó, thấy đỏ, và `/qc-report` phân loại thành *product-gap*
242
+ > rồi in một `/report-bug` sẵn-chạy. Lỗi đi **ra khỏi đội QC** thành bug gửi PO — cho một hành vi
243
+ > spec chưa bao giờ định nghĩa. Đây **báo cáo sai**, cùng loại với việc giữ một `pass` đã hết
244
+ > hiệu lực (`rules/workflow.md` §*"Làm mất hiệu lực ghi đè"*).
245
+ >
246
+ > **Vì sao DỪNG chứ không hỏi Y/N.** Một cổng chỉ chặn được khi có người ngồi đó thì ở chế độ
247
+ > headless không phải cổng, **treo**cùng bài học với `steps/qc-scope.md` §2.
248
+ >
249
+ > **Vì sao `--yes` KHÔNG bỏ qua được.** `--yes` nghĩa *"tôi không ngồi đây để trả lời"*, không phải
250
+ > *"tôi chấp nhận thiết kế test không có phân tích gap"*. Gộp hai nghĩa là để một lần chạy headless
251
+ > âm thầm sinh ra một bộ test case thiếu mọi dấu chặn.
252
+ >
253
+ > **Vì sao cả ba file đều bắt buộc, không miễn trừ `TEST_PLAN.md`.** Không có luồng hợp lệ nào có
254
+ > file 1–2 thiếu file 3: `Next` của `/qc-analyze` chính là `/qc-plan`. Miễn trừ nó là mở một
255
+ > đường tắt không ai xin.
256
+ >
257
+ > **Chỉ kiểm SỰ TỒN TẠI, không kiểm nội dung hay độ tươi.** Ba file này có còn khớp spec hiện tại
258
+ > không là một câu hỏi khác, và nó cần một cơ chế khác (đóng dấu version nguồn). Trộn hai việc vào
259
+ > một guard thì guard này không bao giờ landing được.
260
+
261
+ ---
262
+
263
+ ## Cờ — chọn tầng nào, tách mịn đến đâu
264
+
265
+ | Cờ | Ghi file | Nhóm |
266
+ |---|---|---|
267
+ | *(không cờ)* | `TC_<FEATURE>.Test.md` | 1 GUI · 2 Validation · 3 Functional · 4 Integration (qua UI) · 5 NFR · 6 E2E |
268
+ | `--api` | `TC_<FEATURE>_API.Test.md` | 1 Endpoint · 2 Integration API/DB/Kafka |
269
+ | `--all` | **cả hai file** | như trên, hai file riêng biệt |
270
+ | `--atomic-max` | — | bật chế độ tách tối đa (xem dưới) |
271
+
272
+ **Câu hỏi phân file:** *"TC này verify được mà **không cần UI** không?"* → **có** = file API ·
273
+ **không** = file giao diện. Đây đúng là Bước 2 của
274
+ `{paths.qc_skills_dir}/qa-designer/shared/skill-decision-tree.md`.
275
+
276
+ > **Vì sao hai file riêng chứ không một file rồi ghi từng nhóm** *(B12)*. `--api` chạy sau khi
277
+ > file giao diện đã tồn tại là chuyện thường. Nếu chung một file, lần chạy `--api` phải **giữ
278
+ > nguyên** năm nhóm kia — mà viết-lại-cả-file đúng thứ agent hay làm. Hai file thì hai chế
279
+ > độ **không bao giờ chạm nhau**, không cần tin vào việc agent nhớ giữ phần cũ.
280
+
281
+ ### `--atomic-max` tách tới mức nhỏ nhất
282
+
283
+ Mặc định đã ATOMIC (mỗi TC đúng một kết cục), nhưng **cho phép** bullet compound khi cả hai
284
+ vế nói về **cùng một** kết cục ví dụ *"form hiển thị đủ 3 trường"* vẫn là 1 TC.
285
+
286
+ `--atomic-max` **nổ danh sách completeness thành từng thành phần**: thẻ hiển thị đủ 5 thông tin
287
+ → **5 TC**. Ở đội QC, một tính năng đi từ 82 lên 130 TC.
288
+
289
+ **⛔ Thủ tục bắt buộc TRƯỚC khi ghi** *(theo `shared/precision-rules.md` §2.1)*:
290
+
291
+ 1. **Chốt ranh giới completeness** hai mức quy rất khác nhau:
292
+ | Giá trị | Nghĩa |
293
+ |---|---|
294
+ | `--atomic-max=keep-completeness` | giữ danh sách completeness 1 TC (~95 TC ví dụ thật) |
295
+ | `--atomic-max=explode` | nổ từng thành phần (~130 TC) |
296
+
297
+ Không nêu giá trị**HỎI** trước khi ghi, vì đây là quyết định quy mô của người chủ, không
298
+ phải của agent. **Có `--yes`:** không hỏi **DỪNG** với lỗi rõ ràng:
299
+ ```
300
+ --atomic-max cần nêu ranh giới ở chế độ headless (quy chênh ~35%).
301
+ Chạy: /qc-design-test {UC-ID} --atomic-max=explode --yes
302
+ hoặc --atomic-max=keep-completeness --yes
303
+ ```
304
+ *(Một cổng chỉ chặn được khi có người ngồi đó thì ở chế độ headless nó không phải cổng, nó
305
+ là treo — cùng bài học với `steps/qc-scope.md` §2.)*
306
+
307
+ 2. **Dựng bản đồ tách trước khi ghi** mỗi TC cha tách ra mấy mảnh. Đừng để agent con tự suy
308
+ trong lúc ghi; đó là chỗ sinh ra TC cắt cụt.
309
+ 3. **GIỮ 1 TC** cho bốn loại này kể cả ở chế độ tối đa: *predicate đa-điều-kiện định-nghĩa-một-
310
+ khái-niệm* · *ngưỡng* (`≥44pt`, `WCAG AA ≥4.5:1`) · *exclusivity* chọn-một · *qualifier*.
311
+ 4. **Verify bằng DIFF, không tin lời đếm của agent** — ID liên tục · mỗi Expected 1 bullet ·
312
+ 0 ký tự `|` · Trace matrix không còn ID chết · P0/P1 khớp tag.
313
+
314
+ ---
315
+
316
+ ## Role
317
+
318
+ Bạn là **QC Designer** — stage 3. Sinh/bảo trì các file test-case Markdown
319
+ (`.Test.md`) từ requirement đã phân tích + plan. Output feed vào qc-run-test (Python)
320
+ qc-review. Bạn **không** viết Python.
321
+
322
+ ## Skills (`{paths.qc_skills_dir}/qa-designer/`)
323
+
324
+ **Luật dùng chung — nạp theo tầng, không nạp hết mỗi lần:**
325
+
326
+ | Khi nào | Nạp |
327
+ |---|---|
328
+ | **Luôn** | `shared/tc-metadata-format.md` khuôn TC · luật ATOMIC · phân nhóm · hai file `.Test.md` · Trace · `🚫 Block` · `Test-ID attribute` |
329
+ | **Luôn** | `shared/precision-rules.md` cấm 9 cụm hồ · đơn vị theo domain · toán tử · BVA 3-hay-4 giá trị · phủ đủ ô decision table · 3 mức teardown |
330
+ | **Luôn** | `shared/action-keywords-glossary.md` một hành động một từ (Click/Tap/Enter/Select…) |
331
+ | **Luôn** | `shared/implicit-scenarios.md` 7 tình huống bắt buộc nghĩ tới, áp cho mọi nhóm |
332
+ | Đầu phiên, một lần | `shared/read-doc-gap-inputs.md` — đọc **đủ** mọi file trong bảng *Tài liệu đầu vào đã đọc* của `DOC_GAP.md`, không chỉ đọc bản tóm tắt gap |
333
+ | Không chắc chọn tầng nào | `shared/skill-decision-tree.md` — cây quyết định UI / Integration-GUI / E2E / Integration |
334
+ | Thêm TC vào file đã có | `shared/duplicate-check-procedure.md` — grep trước khi viết; và **trùng chéo UC** giờ mới thực sự xảy ra vì mọi UC dùng chung một thư mục |
335
+ | `--api` / `--all` | `api/endpoint.md` · `api/auth-chain.md` · `api/http-status-codes.md` · `api/common-headers.md` · `api/crud-sequence.md` · `api/auth-sequence.md` |
336
+
337
+ **Rồi chọn tầng, nạp MỘT file:**
338
+
339
+ | Layer | File | Ghi vào |
340
+ |---|---|---|
341
+ | 1 màn hình | `functional/gui-screen.md` | file giao diện |
342
+ | Feature đa-màn | `functional/gui-feature.md` | file giao diện |
343
+ | API endpoint | `functional/api.md` | **file API** |
344
+ | Integration qua UI | `integration/gui.md` | file giao diện |
345
+ | Integration API/DB/Kafka | `integration/{api,db,kafka}.md` | **file API** |
346
+ | End-to-end journey | `e2e/journey.md` | file giao diện |
347
+ | Non-functional | `non-functional.md` | theo câu hỏi phân file |
348
+ | Exploratory | `exploratory/{charter,explore-to-functional}.md` | file giao diện |
349
+
350
+ ## Conventions
351
+
352
+ *Khuôn TC, luật ATOMIC, phân nhóm, không-dùng-bảng, Trace, `🚫 Block`, `Test-ID attribute`
353
+ đều ở `shared/tc-metadata-format.md`. **Đừng lặp lại ở đây.** Dưới đây chỉ là thứ riêng của trạm:*
354
+
355
+ - Markdown-first; đừng design khi requirement chưa đẩy ngược về qc-plan/qc-analyze.
356
+ - **Tham chiếu test-id, không phải gợi ý hình ảnh.** Với mỗi step GUI tác động lên một element, trích test-id ổn định từ bảng §4.5.6 của tech-doc gộp (vd "click `ft001-login-submit-btn`") để qc-run-test dựng locator từ contract. Nếu một element có action không có test-id trong §4.5.6, ghi chú lại (qc-run-test sẽ fallback về locator role/text chậm hơn).
357
+ - **Đọc `@trace.testid_attr` từ header tech-doc gộp** (do `/map-testids` ghi) ghi lại một
358
+ dòng `Test-ID attribute: {attr}` metadata đầu file `.Test.md`. §4.5.6 chỉ cho **giá trị**
359
+ test-id; `@trace.testid_attr` **tên thuộc tính** chứa chúng`/qc-run-test` cần để cấu
360
+ hình locator, `/qc-review` cần để biết selector trong script đúng contract không.
361
+ Không đọc được `@trace.testid_attr` → ghi
362
+ `Test-ID attribute: (thiếu @trace.testid_attr, chạy /map-testids)`; **đừng bỏ trống, đừng
363
+ tự đoán theo platform**đoán sai thì mọi locator trượt 100%, một do không liên quan
364
+ tới thứ đang được test. *(Dạng dòng metadata: `shared/tc-metadata-format.md`.)*
365
+ - Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md) — lý do`.
366
+ Chặn theo **UC ở cột `UC` của hàng gap đó**, không chặn cả PRD.
367
+
368
+ ## Trace mapping (bắt buộc)
369
+
370
+ Ngoài trace `BR-xx`, mỗi TC ghi scenario framework verify **dạng trường danh sách,
371
+ không phải cột bảng** (file TC không ký tự `|`):
372
+
373
+ ```
374
+ - **@trace.verifies:** {UC-ID}-SC{N}
375
+ ```
376
+
377
+ Lấy từ `@trace.scenario` của `.feature`. Một SC map được nhiều TC. Đây là **join key** cho phép
378
+ qc-run-test ghi `qc_status` theo từng scenario vào sổ trace — **thiếu nó thì test vẫn chạy,
379
+ vẫn pass/fail, nhưng kết quả không vào được sổ và không ai biết nó phủ kịch bản nào.**
380
+
381
+ Cuối file: **Trace matrix** (BR ↔ TC ↔ SC) + **danh sách TC bị block** — cả hai dạng danh sách.
382
+
383
+ ## Guard SC coverage *(phép ĐẾM học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
384
+
385
+ Dòng `Trace:` report cuối đã đòi con số `{K}/{total}` từ trước. Guard này **phép tính sinh
386
+ ra con số đó**, và là **hệ quả khi `K < total`** — trước đây có số mà không có phép tính nào
387
+ đứng sau, nên ước lượng, `K < total` không dẫn tới việc gì.
388
+
389
+ ### Ba bước
390
+
391
+ 1. **Thu SC** mọi `@trace.scenario` trong `.feature` của **UC đang chạy** (`{UC-ID}`, đúng
392
+ `active_platform`) — **KHÔNG phải `uc_list`.**
393
+
394
+ `uc_list` là mọi UC approved của **cả PRD**; trạm này chạy **per-UC** (§Phạm vi QC), nên lấy
395
+ `uc_list` làm mẫu số là ép viết TC cho UC **không ai yêu cầu** — bằng dữ liệu đã lọc bỏ phần
396
+ của chúng ở Gate (*"lọc theo cột `UC` để lấy phần của UC này"*), tức là **viết mù**.
397
+
398
+ *Trạm 1 `/qc-analyze` dùng `uc_list` là **đúng** — nó cấp PRD, và mâu thuẫn chéo UC chỉ lộ ra
399
+ khi đọc cùng lúc. **Đừng copy mẫu số giữa hai trạm khác tầng.** Phép kiểm một câu: mẫu số của
400
+ một guard phải khớp **phạm vi mà lệnh đó được gọi**.*
401
+
402
+ **Không cần lọc `⏸ chưa xét` ở đây nữa:** `qc-scope` §4b đã chặn UC target chưa approved từ
403
+ trước khi tới bước này. Chạy được tới đây nghĩa là target hoặc đã `approved`, hoặc người dùng
404
+ đã nêu `--force` tường minh (và artifact đang mang dấu *"dựa trên BDD nháp"*).
405
+ 2. **Thu V** — mọi `@trace.verifies` trong **MỌI** `*.Test.md` dưới `{qc_artifact_dir}test-cases/`
406
+ — **không chỉ file vừa ghi** — rồi lọc lấy giá trị bắt đầu bằng `{UC-ID}-SC`.
407
+
408
+ *Thư mục `test-cases/` dùng chung cho **cả PRD** nên phải lọc theo UC. Và lệnh này có **ba chế
409
+ độ ghi** (§Cờ), hai trong ba chỉ ghi **một nửa**: `--api` chạy sau khi file giao diện đã tồn tại
410
+ là **chuyện thường** (§B12 ngay dưới bảng Cờ). Chỉ đếm file "vừa ghi" thì lần chạy `--api` thấy
411
+ độ phủ ≈ 0, rồi luật "viết bù TC ngay" **nhân bản toàn bộ TC giao diện vào file API** — phá đúng
412
+ ranh giới hai-file mà §B12 dựng lên.*
413
+
414
+ **Tiền tố lọc phải gồm cả `-SC`.** `{UC-ID}-SC` chứ **không** phải `{UC-ID}`:
415
+ `FT-001-UC1-SC` không khớp `FT-001-UC11-SC3`, còn `FT-001-UC1` thì có. Một PRD tới UC thứ 11
416
+ là đủ để phép lọc sai **trong im lặng**.
417
+
418
+ *Quét cả thư mục chứ không đoán theo tên file: tên file mang `<FEATURE>`, **không** mang UC —
419
+ `@trace.verifies` là chỗ duy nhất nói TC thuộc UC nào (§Output).*
420
+ 3. **Đếm** — mỗi SC ∈ tập ở bước 1 phải có **≥ 1** TC trỏ tới.
421
+
422
+ ### Xử lý
423
+
424
+ | Kết quả | Làm gì |
425
+ |---|---|
426
+ | Mọi SC đều có ≥1 TC | in `Guard SC coverage: khớp {K}/{K}` |
427
+ | Có SC chưa phủ | **viết bù TC ngay** — vào file đúng theo §Câu hỏi phân file, xem luật định tuyến dưới đây — rồi in `⚠️ Guard SC coverage: {K}/{total} — đã bù {m} SC: {danh sách}` |
428
+
429
+ **TC bù đi vào file nào — theo §Câu hỏi phân file, KHÔNG mặc định vào file của chế độ đang chạy.**
430
+
431
+ Hỏi từng SC chưa phủ: *"TC cho SC này verify được mà **không cần UI** không?"*
432
+
433
+ | Trả lời | Chế độ đang chạy | Làm gì |
434
+ |---|---|---|
435
+ | **Có** (không cần UI) | `--api` hoặc `--all` | bù vào **file API** — xong |
436
+ | **Không** (cần UI) | *(không cờ)* hoặc `--all` | bù vào **file giao diện** — xong |
437
+ | **Không** (cần UI) | **`--api`** | **KHÔNG bù vào file API.** SC vẫn tính là **chưa phủ**; in thêm dòng chỉ đường (dưới) |
438
+
439
+ ```
440
+ ⚠️ {n} SC cần UI, chưa có TC ở file giao diện — KHÔNG bù vào file API (§Câu hỏi phân file).
441
+ Chạy: /qc-design-test {UC-ID} ← không cờ, để bù đúng chỗ
442
+ SC: {danh sách}
443
+ ```
444
+
445
+ > **Đây KHÔNG phải "bỏ trống có lý do".** Phân biệt bằng một câu: đường thoát làm SC **được tính là
446
+ > đã phủ**; luật này để SC **vẫn nằm trong số chưa phủ** — `{K}/{total}` không đổi, dòng ⚠️ vẫn in,
447
+ > guard vẫn chưa sạch. Nó chỉ đổi **chỗ ghi TC**, không đổi **phép đếm**.
448
+ >
449
+ > Và nó **không** cho agent một câu-lý-do-cho-qua: điều kiện là một phép so cơ học (*"cần UI không?"*
450
+ > — đúng Bước 2 của `shared/skill-decision-tree.md`), không phải một nhận định tự do. Ghi *"SC này
451
+ > phức tạp"*, *"tương tự SC2"* thì **không** rơi vào ô nào của bảng trên.
452
+ >
453
+ > **Vì sao không cứ bù vào file đang mở cho gọn.** File API được `/qc-run-test` đọc bằng lane API.
454
+ > Một TC cần UI nằm ở đó **không chạy nổi** — và nó sẽ đỏ dưới dạng *script-bug* hoặc *product-gap*,
455
+ > không ai truy ngược về một quyết định ghi file ở phase thiết kế.
456
+
457
+ **Không có đường "bỏ trống có lý do".** Đây là chỗ dễ làm sai nhất, và quy ước ở §Conventions
458
+ đã trả lời: *"Một TC bị block bởi gap **vẫn viết đủ** + `🚫 Block: [GAP-UC{N}-{nnn}](../DOC_GAP.md)`"*.
459
+ Nghĩa là **gap không phải cái cớ để không viết TC** — nó là thứ được **ghi vào TC**. SC bị chặn
460
+ vẫn có TC, vẫn được đếm là đã phủ.
461
+
462
+ Nên chỉ còn đúng hai trạng thái, và cả hai đều không cho phép bỏ trống:
463
+
464
+ - SC **của UC đang chạy** → phải có TC (bị gap chặn thì TC mang dấu `🚫 Block`). Đây là **toàn bộ**
465
+ mẫu số — bước 1 không lấy SC của UC nào khác.
466
+ - SC **của UC khác** → không thuộc lần chạy này, không tính vào mẫu số. *(Muốn phủ chúng thì chạy
467
+ `/qc-design-test` cho UC đó — đừng viết TC của chúng ở đây.)*
468
+
469
+ Nếu bạn thấy một SC "không thể viết TC" mà không thuộc hai loại trên, thì **đó là một gap** —
470
+ mở gap trong `DOC_GAP.md`, viết TC kèm `🚫 Block` trỏ tới nó. Đừng viết một câu lý do rồi đi
471
+ tiếp: guard viết lỏng thì lần sau sẽ có một câu lý do cho qua, và phép đếm mất nghĩa.
472
+
473
+ *(Ca "SC cần UI mà đang chạy `--api`" **không** phải trạng thái thứ ba: SC đó vẫn ở nhóm thứ nhất,
474
+ vẫn tính vào mẫu số, vẫn chưa phủ. Chỉ **chỗ ghi TC** bị hoãn — xem luật định tuyến ở §Xử lý.)*
475
+
476
+ **In dòng `Guard SC coverage:` kể cả khi sạch** — guard im lặng khi sạch là guard không ai biết
477
+ nó tồn tại, và không ai phát hiện được khi nó chết.
478
+
479
+ > **Vì sao đếm ở đây mà không đợi báo cáo cuối.** `/qc-report` **sẽ** tính **design coverage** bằng
480
+ > **đúng phép đếm này** — **Đợt 3, CHƯA TRIỂN KHAI** (`docs/plans/qc-surgery/01-checklist.md`, phụ
481
+ > thuộc cứng vào `d2-b2`). Khác nhau ở thời điểm: guard đếm **lúc thiết kế** — còn kịp viết bù; báo
482
+ > cáo đếm **ở cuối** — chỉ còn kịp báo. Phát hiện "design coverage 68%" ở phút cuối là lúc không còn
483
+ > thời gian viết bù 32%.
484
+ >
485
+ > **Tới khi Đợt 3 có, guard này là lớp đếm DUY NHẤT — đừng dựa vào một lớp thứ hai chưa tồn tại.**
486
+ > *(Bản trước viết "sẽ tính" ở thì hiện tại, không nêu trạng thái. Một lời hứa không có trạng thái sẽ
487
+ > được đọc như một sự thật — và tệ nhất là khi nó được dùng để biện minh cho việc không đếm ở chỗ khác.)*
488
+ >
489
+ > **Vì sao "chưa có TC" khác "có TC nhưng chưa chạy".** Hai trạng thái này dẫn tới hai việc khác
490
+ > nhau hoàn toàn — viết test, so với chạy test. Nhưng nhìn vào sổ trace thì giống nhau: cả hai
491
+ > đều là `qc_status = not_run`. Guard này là chỗ duy nhất phân biệt được.
492
+
493
+ ## Chạy lại — `.Test.md` đã tồn tại *(GIỮ, không sinh lại từ trắng)*
494
+
495
+ File `.Test.md` đi qua **cổng HITL `/qc-review`**. Bốn thứ trong đó **không sinh lại được**:
496
+
497
+ | Mất gì | Vì sao |
498
+ |---|---|
499
+ | `Status` đổi sau review | **kết luận của người**, không suy từ spec |
500
+ | `Expected Result` sửa theo finding | finding nằm ở `REVIEW_<FEATURE>.md` — **lệnh này không đọc file đó** |
501
+ | Dấu `🚫 Block` vừa gỡ | phụ thuộc ô `Câu trả lời` của `DOC_GAP.md` (xem §Guard vòng đời 🚫 Block) |
502
+ | Đánh số `TC_<FEATURE>_NNN` | **`REVIEW_<FEATURE>.md` đang trỏ vào các số đó**, và nó nằm cùng thư mục |
503
+
504
+ **Đọc file cũ TRƯỚC khi ghi.** Với mỗi TC:
505
+
506
+ | Tình huống | Xử lý |
507
+ |---|---|
508
+ | TC cũ, spec **không đổi** | **Giữ nguyên** — số · `Status` · `Expected Result` đã sửa |
509
+ | TC cũ, spec **đổi** | Cập nhật **nội dung**; giữ **số** và `Status`, thêm ⚠️ để `/qc-review` soát lại |
510
+ | TC **mới** | Cấp số **tiếp theo** — không dồn, không tái dùng |
511
+ | TC không còn ứng với SC nào | **KHÔNG xoá** → `Status: Obsolete`, ghi lý do |
512
+
513
+ > **`Obsolete` chứ không xoá** — cùng luật `Stale` của `/qc-analyze` §Chạy lại: `REVIEW_<FEATURE>.md`
514
+ > đang trỏ vào số đó, xoá hàng là biến biên bản soát thành liên kết chết.
515
+ >
516
+ > **§duplicate-check KHÔNG phải lưới cho ca này.** Nó chống **viết trùng** (*"grep trước khi viết"*),
517
+ > không chống **ghi đè**. Hai chuyện khác nhau, và tên nghe giống nhau đủ để tưởng đã có người lo.
518
+
519
+ ### Lập lại từ trắng — phải nói ra
520
+
521
+ ```
522
+ ❌ {n} file .Test.md đã tồn tại ({k} TC có Status khác Draft — đã qua review).
523
+ Mặc định: GIỮ số + Status + Expected đã sửa, chỉ cập nhật nội dung theo spec mới.
524
+ Muốn bỏ hẳn và thiết kế lại từ trắng: thêm --force
525
+ ⚠️ --force sẽ XOÁ {k} kết quả review và làm REVIEW_<FEATURE>.md trỏ sai số TC.
526
+ ```
527
+
528
+ ---
529
+
530
+ ## Guard — vòng đời `🚫 Block` *(phép so cơ học, chạy SAU khi ghi file, TRƯỚC CHECKPOINT)*
531
+
532
+ `🚫 Block` có bước **mở** (§Conventions: TC chạm gap thì mang dấu) và một quy trình **đóng** viết
533
+ sẵn ở `{paths.qc_skills_dir}/qa-designer/shared/tc-metadata-format.md` §*Quy trình khi gap được giải
534
+ quyết (Answered)*. Bước đóng đó **chưa lệnh nào gọi** — nên dấu chặn chỉ dán vào, không bao giờ gỡ ra.
535
+
536
+ Một TC mang `🚫 Block` là một TC có **Expected Result dựa trên giả định chưa ai xác nhận**. Nó nằm
537
+ trong thư mục dùng chung, được `Guard SC coverage` đếm là **đã phủ**, và `/qc-run-test` sẽ nhặt lên.
538
+
539
+ > **Vì sao stamp phiên bản (§Stamp phiên bản nguồn) KHÔNG phủ ca này.** Gap chuyển `Open → Answered`
540
+ > là một **ô trong `DOC_GAP.md`** — nó **không bump version nào cả**. Mọi drift detector của framework
541
+ > so **nhãn version**; thay đổi trạng thái nằm *bên trong* một tài liệu đi vòng qua tất cả.
542
+
543
+ ### Bốn bước, thuần so chuỗi
544
+
545
+ 1. **Thu B** — mọi `GAP-ID` xuất hiện trong dòng `🚫 Block:` của các `*.Test.md` của UC này.
546
+ 2. **Thu A** — mọi `GAP-ID` có `Trạng thái = Answered` trong `DOC_GAP.md` (lọc theo cột `UC`).
547
+ 3. **So** — `A ∩ B` = gap đã trả lời mà TC vẫn mang dấu chặn.
548
+ 4. **Xử lý:**
549
+
550
+ | Kết quả | Làm gì |
551
+ |---|---|
552
+ | `A ∩ B` rỗng | in `Guard 🚫 Block: {n} dấu đang mở, 0 cần gỡ` |
553
+ | Có phần tử, **ô `Câu trả lời` ĐÃ điền** | **GỠ NGAY** theo 4 bước của skill: bỏ dấu `🚫 Block` · cập nhật `Expected Result` theo câu trả lời thật · nếu answer đổi scope thì tách/thêm TC. Rồi in:<br/>`🔓 Guard 🚫 Block: gỡ {k} dấu (gap đã Answered): {danh sách GAP-ID}` |
554
+ | Có phần tử, **ô `Câu trả lời` TRỐNG** | **KHÔNG gỡ.** In:<br/>`⚠️ Guard 🚫 Block: {GAP-ID} = Answered nhưng ô "Câu trả lời" trống — không gỡ được, hỏi lại PO.` |
555
+
556
+ **Guard TỰ SỬA, không chỉ tự báo** — cùng luật `Guard BR-tag` của `/qc-analyze` đã chốt: *"In cảnh
557
+ báo rồi để người đi lấp là thêm một dòng nữa để bỏ qua."*
558
+
559
+ **Nhưng ô `Câu trả lời` trống thì DỪNG, không đoán.** Gỡ dấu chặn mà không có câu trả lời thật là
560
+ **biến một giả định thành sự thật trong im lặng** — và `Expected Result` sai sẽ fail lúc chạy, rồi
561
+ `/qc-report` phân loại *product-gap* và in một `/report-bug`. Lúc đó một lỗ hổng **tài liệu** đã đi ra
562
+ ngoài đội QC thành **phiếu lỗi sản phẩm** gửi PO.
563
+
564
+ **In dòng `Guard 🚫 Block:` kể cả khi sạch** — cùng lý do với hai guard kia.
565
+
566
+ ---
567
+
568
+ ## UC đang Blocked — nói ra, KHÔNG chặn
569
+
570
+ `TEST_PLAN.md` §5 ghi `Ready`/`Blocked` cho mỗi UC (guard tiền đề đã ép file này phải có). Đọc trạng
571
+ thái của UC đang chạy. **`Blocked` là mức ƯU TIÊN, không phải lệnh cấm** — vẫn thiết kế bình thường,
572
+ chỉ in thêm một dòng ở report:
573
+
574
+ ```
575
+ ⚠️ {UC-ID} đang Blocked bởi {n} gap 🔴 — TC chạm chúng mang dấu 🚫 Block, chưa chạy được.
576
+ Gỡ chặn: trả lời {danh sách GAP-ID} với PO → chạy lại lệnh này để tự gỡ dấu.
577
+ ```
578
+
579
+ > **Vì sao không chặn** *(G66)*. `/qc-analyze` nói *"chưa sẵn sàng"* nghĩa là **chưa sẵn sàng để
580
+ > nghiệm thu**, không phải *"chưa được thiết kế"* — và §Conventions của chính lệnh này đã trả lời:
581
+ > *"TC bị block bởi gap **vẫn viết đủ**"*. Chặn ở đây là giết cơ chế `🚫 Block`, thứ được dựng kỹ tới
582
+ > mức có mã gap mang UC, liên kết ngược `../DOC_GAP.md`, và một dòng riêng trong report.
583
+ >
584
+ > Cái bị chặn là **chạy test**, không phải **viết test**.
585
+
586
+ ## Output
587
+
588
+ Ghi dưới `{qc_artifact_dir}test-cases/`
589
+ (= `{paths.qc_dir}/{TICKET-ID}/{active_platform}/test-cases/`) — **một thư mục dùng chung cho cả
590
+ PRD**. Tên file mang `<FEATURE>` nên các UC không đâm nhau; `@trace.verifies` là chỗ phân biệt
591
+ TC thuộc UC nào.
592
+
593
+ **Đuôi bắt buộc là `.Test.md`.** `/qc-run-test` và `/qc-review` tìm `*.Test.md`; ghi ra
594
+ `TC_<FEATURE>.md` là ghi ra thứ **không trạm nào tìm thấy**, và **không có gì báo lỗi**.
595
+
596
+ `🚫 Block` trỏ `../DOC_GAP.md` — lên một cấp, vì file gap ở thư mục cha của `test-cases/`.
597
+
598
+ ## Self-Review *(trước khi in Report)*
599
+
600
+ Theo 3 nhóm ở `{paths.qc_skills_dir}/_shared/self-review-principles.md` — **không chép lại ở đây**.
601
+
602
+ - **Bịa:** mỗi TC kiểm một hành vi **spec có nêu** — không phải hành vi tôi cho là hợp lý? Mỗi
603
+ `Expected` là **giá trị cụ thể** (*"hiển thị text 'Tên lớp: Toán 6A'"*), không phải *"hiển thị
604
+ đúng"* / *"hoạt động bình thường"*?
605
+ - **Nhảy bước:** đã áp luật ATOMIC cho **mọi** TC (không chỉ vài TC đầu), và đã chạy
606
+ §duplicate-check trước khi thêm TC mới?
607
+ - **Số liệu:** `{n}` TC mỗi file = `grep -cE "^#{2,4} *TC_"` thật? Các con số phân nhóm (GUI /
608
+ Validation / Functional / …) cộng lại đúng bằng tổng TC?
609
+
610
+ > Guard SC coverage ở trên là **phép đếm cơ học**, không phải self-review — nó đối chiếu với
611
+ > `.feature`, một nguồn khác. Đừng coi self-review đã bao nó. Xem §Ranh giới trong file skill.
612
+
613
+ ## Report
614
+
393
615
  **Đọc `.agent/steps/report-footer.md`** và áp đúng khuôn footer trong đó (Status Badge ·
394
- Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
395
-
396
- ```
397
- /qc-design-test Hoàn tất — {UC-ID} ({active_platform})
398
- Chế độ: {giao diện | API | cả hai}{nếu --atomic-max: " · tách tối đa ({explode|keep-completeness})"}
399
- Files: {qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md — {n} TC
400
- {nếu có: "…_API.Test.md — {m} TC"}
401
- Nhóm : GUI {a} · Validation {b} · Functional {c} · Integration {d} · NFR {e} · E2E {f}
402
- {nếu file API: "Endpoint {g} · Integration API/DB/Kafka {h}"}
403
- Trùng: {k} TC bỏ vì trùng ({j} trùng chéo UC — trỏ trace về UC nguồn thay vì viết lại)
404
- Block: {blocked} TC bị chặn bởi gap — theo UC: {UC1: n · UC2: n}
405
- Trace: {N} TC map tới {K}/{total} scenario của {UC-ID}
406
- Guard SC coverage: {khớp {K}/{K} | ⚠️ {K}/{total} — đã bù {m} SC: {danh sách SC}}
407
- Self-review: { sạch | ⚠️ {n} điểm cần chú ý liệt kê}
408
- Next : /qc-review {UC-ID} review test case trước khi sinh script
409
- ```
616
+ Output Artifacts · Next) cho report cuối, kèm khối bên dưới.
617
+
618
+ ```
619
+ /qc-design-test Hoàn tất — {UC-ID} ({active_platform})
620
+ Chế độ: {giao diện | API | cả hai}{nếu --atomic-max: " · tách tối đa ({explode|keep-completeness})"}
621
+ Files: {qc_artifact_dir}test-cases/TC_<FEATURE>.Test.md — {n} TC
622
+ {nếu có: "…_API.Test.md — {m} TC"}
623
+ Nhóm : GUI {a} · Validation {b} · Functional {c} · Integration {d} · NFR {e} · E2E {f}
624
+ {nếu file API: "Endpoint {g} · Integration API/DB/Kafka {h}"}
625
+ Trùng: {k} TC bỏ vì trùng ({j} trùng chéo UC — trỏ trace về UC nguồn thay vì viết lại)
626
+ Block: {blocked} TC bị chặn bởi gap — theo UC: {UC1: n · UC2: n}
627
+ {nếu UC đang Blocked: "⚠️ {UC-ID} đang Blocked bởi {n} gap 🔴 — trả lời {GAP-ID} với PO
628
+ rồi chạy lại lệnh này để tự gỡ dấu."}
629
+ Guard 🚫 Block: {{n} dấu đang mở, 0 cần gỡ | 🔓 gỡ {k} dấu (gap đã Answered): {danh sách}
630
+ | ⚠️ {GAP-ID} = Answered nhưng ô "Câu trả lời" trống — không gỡ được, hỏi lại PO}
631
+ Trace: {N} TC map tới {K}/{total} scenario của {UC-ID}
632
+ Guard SC coverage: {khớp {K}/{K} | ⚠️ {K}/{total} — đã bù {m} SC: {danh sách SC}}
633
+ {nếu có SC cần UI mà đang chạy --api: "⚠️ {n} SC cần UI chưa có TC ở file giao diện —
634
+ KHÔNG bù vào file API. Chạy: /qc-design-test {UC-ID} (không cờ). SC: {danh sách}"}
635
+ Self-review: {✅ sạch | ⚠️ {n} điểm cần chú ý — liệt kê}
636
+ Next : /qc-review {UC-ID} ← review test case trước khi sinh script
637
+ ```