@educa-corp/sdd-framework 0.8.1 → 0.9.1

package/core/skills/qc/qa-designer/integration/kafka.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Integration Kafka (Message/Event)
@@ -18,7 +18,7 @@ Skill **tự chứa** để viết TC tích hợp qua Kafka: producer phát even
 ---
 
 ## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
+- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAPS.md)`.
 - **Test Data** dạng list (payload) · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet nêu **topic + field payload / hành vi consumer**.
 - Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
 

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Test Case — Non-Functional
@@ -18,7 +18,7 @@ Trọng tâm "hệ thống hoạt động TỐT thế nào". Chỉ cần load fi
 ---
 
 ## Format file TC (bắt buộc)
-- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAP.md)`.
+- Metadata **list**: Title · Feature · Priority · Status(Draft) · Author(AI) · Tags · **Trace** `[BR-xx](REQUIREMENT_ANALYSIS.md#3-business-rules)` (không có → `⚠️ Chưa có Business Rule`) · **🚫 Block** `[GAP-xx](DOC_GAPS.md)`.
 - **Test Data** dạng list · **Steps** `[Action]`/`[Verify]` · **Expected** 1 bullet có **ngưỡng đo cụ thể** (không "nhanh/ổn định").
 - Cuối file: Trace matrix + bảng TC block · bỏ nội dung gạch ngang.
 

package/core/skills/qc/qa-planner/test-plan.md

@@ -1,9 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
-upstream_path: skills/qa-tc-analyst/test-plan.md
-upstream_sha: f259b4d123c565a42ba6c6ec96980a8e4c66284f
+ported_from: ai-automation-qc-base
 ---
 
 # Lập Test Plan
@@ -12,15 +10,15 @@ Tổng hợp **output của qa-analyst** thành **Test Plan** cho một feature.
 
 **Đầu vào (bắt buộc, chỉ 2 nguồn — đúng 2 file qa-analyst trả ra):**
 1. `{paths.qc_dir}/{UC-ID}/REQUIREMENT_ANALYSIS.md` — chức năng, BR-xx, AC-xx, data flow (qa-analyst).
-2. `{paths.qc_dir}/{UC-ID}/DOC_GAP.md` — bảng gap GAP-xx, mức độ, gap Blocker (qa-analyst).
+2. `{paths.qc_dir}/{UC-ID}/DOC_GAPS.md` — bảng gap GAP-xx, mức độ, gap Blocker (qa-analyst).
 
 ## Khi nào trigger
 - "lập test plan cho [Feature]" / "viết test plan"
-- Sau khi qa-analyst xong (đã có REQUIREMENT_ANALYSIS + DOC_GAP)
+- Sau khi qa-analyst xong (đã có REQUIREMENT_ANALYSIS + DOC_GAPS)
 - Trước khi qa-designer thiết kế chi tiết TC — test plan là khung định hướng
 
 ## Khi KHÔNG trigger
-- Chưa có REQUIREMENT_ANALYSIS / DOC_GAP → chạy qa-analyst trước
+- Chưa có REQUIREMENT_ANALYSIS / DOC_GAPS → chạy qa-analyst trước
 - Thiết kế test case chi tiết (.Test.md) → dùng qa-designer
 - Bóc tách yêu cầu/spec, lập danh sách gap → dùng qa-analyst
 
@@ -30,7 +28,7 @@ Tổng hợp **output của qa-analyst** thành **Test Plan** cho một feature.
 
 1. Đọc `REQUIREMENT_ANALYSIS.md`: nắm chức năng, các BR-xx và AC-xx, data flow,
    integration/failure point.
-2. Đọc `DOC_GAP.md`: lấy danh sách gap, đặc biệt **gap Blocker còn Open** → đây là
+2. Đọc `DOC_GAPS.md`: lấy danh sách gap, đặc biệt **gap Blocker còn Open** → đây là
    nguồn cho cột "Phụ thuộc" và cho Entry criteria.
 3. Map mỗi nhóm BR sang **layer test** của qa-designer: functional/gui-screen,
    gui-feature, api, integration, e2e/journey, non-functional.
@@ -49,8 +47,7 @@ Tổng hợp **output của qa-analyst** thành **Test Plan** cho một feature.
   criteria yêu cầu đóng các gap đó trước khi thiết kế TC.
 - Liệt kê **E2E journey** đầy đủ (mỗi journey: tiền điều kiện, kết quả/định tuyến kỳ
   vọng, BR, phụ thuộc, priority) + bộ **verify point chung** sau submit.
-- Mục Rủi ro: **nạp `risk-model.md`** — quét đủ 7 nguồn, chấm khả năng × thiệt hại → P0–P3,
-  rồi dùng mức đó chia độ sâu test. Đừng chấm thẳng ra P0/P1 theo cảm tính.
+- Mục Rủi ro: rút trực tiếp từ gap Blocker + các BR logic phức tạp.
 
 ---
 
@@ -66,7 +63,7 @@ Tổng hợp **output của qa-analyst** thành **Test Plan** cho một feature.
 | Feature / Project / Module | … |
 | Người lập | qa-planner |
 | Ngày / Phiên bản | … |
-| Nguồn | REQUIREMENT_ANALYSIS · DOC_GAP |
+| Nguồn | REQUIREMENT_ANALYSIS · DOC_GAPS |
 
 ## 1. Mục tiêu
 Mục tiêu test của feature (1–3 câu).
@@ -98,12 +95,12 @@ Kỹ thuật áp dụng: EP+BVA, Decision Table (cho logic điều kiện), stat
 integration, negative/exploratory; tự động hoá theo `CLAUDE.md` (Playwright + pytest-playwright + Trace + pytest-html).
 
 ## 5. Tiêu chí Vào / Ra
-- **Entry:** gap Blocker (trong DOC_GAP) đã Answered; doc phụ thuộc sẵn sàng; môi trường + tài khoản role.
+- **Entry:** gap Blocker (trong DOC_GAPS) đã Answered; doc phụ thuộc sẵn sàng; môi trường + tài khoản role.
 - **Exit:** pass P0=100%, P1≥95%; không còn defect Blocker/Critical; mọi BR/AC được trace; báo cáo pytest-html + Playwright Trace.
 
 ## 6. Rủi ro (risk-based)
-| Rủi ro | Nguồn | Khả năng | Thiệt hại | Mức | Giảm thiểu |
-(cách chấm mức + 7 nguồn rủi ro + cách dùng mức để chia độ sâu test: xem `risk-model.md`)
+| Rủi ro | Ảnh hưởng | Mức | Giảm thiểu |
+(rút từ gap Blocker + BR logic phức tạp)
 
 ## 7. Dữ liệu & Môi trường
 Tài khoản các role, dữ liệu mẫu (biên/edge), môi trường staging.

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Script — E2E Journey

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Session Note — Exploratory

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Script — Functional

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Script — Integration

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Script — Non-Functional

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Case — E2E Journey

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Charter — Exploratory

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Case — Functional

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Case — Integration
@@ -21,7 +21,7 @@ Review bộ TC tích hợp (GUI↔Backend, API, DB) và đánh giá chất lư
 ## Phase 1 — Clarify
 
 1. Đọc tất cả TC integration trong folder chỉ định; xác định loại: GUI↔Backend / API / DB
-2. Đọc REQUIREMENT_ANALYSIS + DOC_GAP nếu có
+2. Đọc REQUIREMENT_ANALYSIS + DOC_GAPS nếu có
 3. Xác định chuỗi tích hợp (caller → component → downstream)
 
 ---

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

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Review Test Case — Non-Functional

package/core/skills/qc/qa-runner/e2e.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — E2E Journey

package/core/skills/qc/qa-runner/exploratory/session.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Session Template & Convert Findings — Exploratory

package/core/skills/qc/qa-runner/functional/api.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — Functional API

package/core/skills/qc/qa-runner/functional/gui-feature.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — Functional GUI Feature (đa màn hình)

package/core/skills/qc/qa-runner/functional/gui-screen.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — Functional GUI Screen (1 màn hình)

package/core/skills/qc/qa-runner/integration.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — Integration

package/core/skills/qc/qa-runner/non-functional.md

@@ -1,7 +1,7 @@
 ---
 version: 1.0
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Gen Script — Non-Functional

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

@@ -1,7 +1,7 @@
 ---
 version: 1.1
 updated: 2026-06-11
-ported_from: ui-automation-testing
+ported_from: ai-automation-qc-base
 ---
 
 # Report — Playwright Trace + pytest-html (stack chuẩn)

package/core/steps/review-fanout.md

@@ -8,11 +8,10 @@ vòng không sinh thêm gì mới, *trước khi* ghi file findings.
 
 Lệnh gọi cung cấp hai thứ bắt buộc + hai tuỳ chọn:
 - **DIMENSIONS** — danh sách các chiều review để fan out
-  (`/refine-prd` → 4 lăng kính; `/review-context` → các P-check hoặc B-check; `/qc-analyze` → 3 lăng kính quét gap).
+  (`/refine-prd` → 3 lăng kính; `/review-context` → các P-check hoặc B-check).
 - **FINDINGS SCHEMA** — dạng YAML mà mỗi finding phải theo (định nghĩa trong lệnh).
 - **GRANULARITY** *(tuỳ chọn, mặc định `auto`)* — `auto`: chọn độ mịn fan-out theo bảng ngưỡng kích thước ở Phase 1 (hành vi cũ). `per-uc`: **LUÔN** fan-out theo từng UC, **bỏ qua ngưỡng** — dùng cho review cần độ đầy đủ cao (`/refine-prd` truyền cái này để lần đầu đã quét sâu). Lệnh không truyền → `auto` → hành vi không đổi.
 - **CHANGED_SCOPE** *(tuỳ chọn)* — danh sách UC/section đã thay đổi (review **delta**). Nếu được truyền, Phase 1 chỉ fan-out trên các phạm vi này + PRD-global; Phase 2 critic vẫn quét **toàn doc** làm lưới an toàn. Không truyền → quét toàn bộ như thường.
-- **VERIFY** *(tuỳ chọn, mặc định `off`)* — `on` chèn **Phase 2.5** (`steps/gap-verify.md`) giữa critic và dedup: mỗi finding phải mở lại tài liệu nguồn tự chứng minh trước khi được giữ. Không truyền → hành vi không đổi.
 
 > **Bỏ qua ở chế độ sub-agent:** Nếu Gate Bước 0 đã set `_agent_mode: true`, toàn bộ
 > quy trình này bị **bỏ qua** — orchestrator đã chạy sẵn một dimension/UC cho mỗi
@@ -131,31 +130,6 @@ Ghi lại `convergence_rounds` (số vòng critic đã chạy) cho report.
 
 ---
 
-## Phase 2.5 — Thẩm định *(chỉ chạy khi `VERIFY = on`)*
-
-**Vì sao có bước này.** Phase 1 và Phase 2 chỉ có **một chiều lực**: fan-out mở rộng bề
-ngang, critic lặp cho tới khi không còn gì mới — cả hai đều hỏi *"còn thiếu gì nữa?"*.
-Không có gì hỏi ngược lại *"cái vừa tìm ra có thật không?"*. Nên quy trình này đẩy **recall**
-lên mà **không có gì kéo precision lại**, và càng lặp critic thì tỉ lệ finding bịa càng cao —
-đúng thứ nó tự sinh ra: khẳng định hành vi tài liệu không nêu, trích evidence sai, hoặc gắn
-nhãn vấn đề cho thứ thực ra là chuyện làm-kỹ-hơn.
-
-Chạy `steps/gap-verify.md` trên `ALL_FINDINGS` với:
-- `FINDINGS` = `ALL_FINDINGS` (sau Phase 2)
-- `EVIDENCE_ROOT` = `{paths.specs_dir}` — hoặc giá trị lệnh gọi chỉ định
-- `VERDICT_FIELD` = trường trạng thái của FINDINGS SCHEMA mà lệnh định nghĩa
-- `RERATE` = `on`
-
-Finding bị `❌ INVALID` / `⚠️ RECLASSIFY` / `🔁 MERGE` **không đi tiếp sang Phase 3** — nhưng
-**KHÔNG bị xoá**: chúng vào file findings với trạng thái đóng + lý do, để người đọc kiểm chứng
-được vì sao chúng bị loại. Ghi lại số liệu verdict cho report.
-
-> **Chạy TRƯỚC Phase 3, không phải sau.** Dedup và giải quyết xung đột là việc tốn suy luận;
-> làm nó trên một tập còn lẫn finding bịa là vừa phí, vừa nguy hiểm — một finding ảo có thể
-> "thắng" một finding thật ở bước giữ-cái-severity-cao-hơn.
-
----
-
 ## Phase 3 — Dedup, giải quyết xung đột, merge
 
 Các sub-agent chạy **mù với nhau** (độc lập = độ phủ đa dạng). Chúng không bao giờ

package/core/templates/project-context.yaml

@@ -63,14 +63,14 @@ paths:
   refinement_dir: ".agent/review"
 
   # QC's OWN analysis/design working docs (qc-analyze/plan/design-test outputs:
-  # REQUIREMENT_ANALYSIS.md, DOC_GAP.md, TEST_PLAN.md, test-cases/*.Test.md).
+  # REQUIREMENT_ANALYSIS.md, DOC_GAPS.md, TEST_PLAN.md, test-cases/*.Test.md).
   # One subfolder per UC: {qc_dir}/{UC-ID}/. Default "docs" (the QC team's own
   # convention), VISIBLE — not hidden under .agent/. NOTE: specs (PRD / .feature /
   # design-spec) are NOT here — they come from the PO spec submodule (spec_source).
   qc_dir: "docs"
 
   # WHERE the qc-* commands LOAD their skills from (qa-analyst / qa-designer / qa-planner
-  # / qa-reviewer / qa-runner + DOC_GAP.template.md). Default = the framework-bundled
+  # / qa-reviewer / qa-runner + DOC_GAPS.template.md). Default = the framework-bundled
   # copy at .agent/skills/qc (works standalone). The QC team OWNS these skills in their
   # canonical repo (ai-automation-qc-base) — point this at that repo/submodule (e.g.
   # "qc-base/.claude/skills") so the skills evolve INDEPENDENTLY and are NOT overwritten

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

@@ -38,7 +38,7 @@
 
 | Artifact | Nội dung |
 |----------|----------|
-| `docs/{UC-ID}/…` | `REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md`, `TEST_PLAN.md`, `test-cases/*.Test.md` |
+| `docs/{UC-ID}/…` | `REQUIREMENT_ANALYSIS.md`, `DOC_GAPS.md`, `TEST_PLAN.md`, `test-cases/*.Test.md` |
 | Script Python pytest-playwright | 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 |
@@ -70,7 +70,7 @@ Dây chuyền **6 trạm**, output trạm trước là input trạm sau:
 
 | # | Trạm | Việc |
 |---|------|------|
-| 1 | `/qc-analyze` | Phân rã yêu cầu + phát hiện **gap tài liệu** (`DOC_GAP.md`) |
+| 1 | `/qc-analyze` | Phân rã yêu cầu + phát hiện **gap tài liệu** (`DOC_GAPS.md`) |
 | 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`) |
 | 4 | `/qc-review` | 🛑 **Cổng review** hai chiều: test case & script trước khi chạy |

package/docs/04-reference/commands.md

@@ -89,7 +89,7 @@ Mọi lệnh chạy chung một **Gate** (model check → target → context-loa
 
 | Lệnh | Input | Output | Owner |
 |------|-------|--------|-------|
-| `/qc-analyze` | UC + spec | `REQUIREMENT_ANALYSIS.md`, `DOC_GAP.md` | QA |
+| `/qc-analyze` | UC + spec | `REQUIREMENT_ANALYSIS.md`, `DOC_GAPS.md` | QA |
 | `/qc-plan` | Analysis | `TEST_PLAN.md` (rủi ro) | QA |
 | `/qc-design-test` | Plan | `test-cases/*.Test.md` | QA |
 | `/qc-review` | Test case/script | 🛑 Cổng review | QA |

package/docs/explain/03-refine-prd.md

@@ -1,8 +1,8 @@
 [← /extend-prd](02b-extend-prd.md) · [Explain Home](README.md) · [Next: /review-context →](04-review-context.md)
 
-# 03 · `/refine-prd` — Tinh chỉnh PRD qua 4 lăng kính
+# 03 · `/refine-prd` — Tinh chỉnh PRD qua 3 lăng kính
 
-> **Một câu.** Fan-out review PRD qua **4 lăng kính QA / DEV / SA / PO**, chạy **vòng lặp completeness-critic** để hội tụ đầy đủ trong một lần, rồi sinh file findings cho PO accept/reject ở Review Board.
+> **Một câu.** Fan-out review PRD qua **3 lăng kính DEV / SA / PO**, chạy **vòng lặp completeness-critic** để hội tụ đầy đủ trong một lần, rồi sinh file findings cho PO accept/reject ở Review Board.
 
 ---
 
@@ -33,10 +33,9 @@ Một lượt review đơn không bao giờ liệt kê hết vấn đề — mod
 Chạy qua step **review-fanout** với tham số `GRANULARITY = per-uc`:
 
 ### Phase 1 — Fan-out song song theo dimension
-- **DIMENSIONS = 4 lăng kính** (mỗi lăng kính một sub-agent, context window mới, quét toàn PRD chỉ qua lăng kính đó):
+- **DIMENSIONS = 3 lăng kính** (mỗi lăng kính một sub-agent, context window mới, quét toàn PRD chỉ qua lăng kính đó):
   | Lăng kính | Soi gì |
   |-----------|--------|
-  | **QA** (tầng nghiệm thu) *(bật 2026-08-25)* | AC có nêu **outcome quan sát/kiểm được** chưa? AC có lặp nội dung BR (trùng tầng) không? — hỏi về **HÌNH THỨC**, KHÔNG về nội dung thiếu |
   | **DEV** (cơ chế nghiệp vụ) | BR + Business Logic đã đủ & không mơ hồ để build không phải đoán chưa? Nhánh nghiệp vụ thiếu, điều kiện biên, đường lỗi bỏ ngỏ |
   | **SA** (thông suốt & nhất quán) | Luồng nghiệp vụ thông suốt trên cả feature/domain? Tương tác UC, quan hệ entity, vòng đời trạng thái, ai-làm-gì |
   | **PO** | Scope khoanh vùng? Priority? Success metric? Rủi ro scope creep? |
@@ -67,8 +66,7 @@ Chạy qua step **review-fanout** với tham số `GRANULARITY = per-uc`:
 
 ## Cơ chế đặc biệt
 
-- **Lăng kính QA hẹp có chủ ý** — nó hỏi *"phát biểu này kiểm chứng được không?"*, KHÔNG hỏi *"còn thiếu gì?"*. Ở thời điểm PRD chỉ có PRD (design-spec/BDD/tech-doc chưa tồn tại), nên không phân biệt được *"PRD thiếu X"* với *"PRD để X cho design-spec"*. Câu hỏi nội dung thuộc `/qc-analyze`. Số liệu: review chỉ-PRD ra ~14 gap, review đủ 4 nguồn ra ~9,4 — chênh lệch là câu tài liệu sau trả lời hộ.
-- **Không có `--fix` mode** (khác `/review-context`) — finding 4 lăng kính là phán đoán QA/DEV/SA/PO, **bắt buộc qua người** ở Board; `auto_fixable` chỉ là gợi ý quick-accept.
+- **Không có `--fix` mode** (khác `/review-context`) — finding 3 lăng kính là phán đoán DEV/SA/PO, **bắt buộc qua người** ở Board; `auto_fixable` chỉ là gợi ý quick-accept.
 - **`resolution_edge_cases`** — phân tích bậc-hai (chỉ critical/major): "nếu chốt phương án này thì đẻ ra edge case gì?" → PO thấy trước khi accept (advisory, không chặn).
 - **QA lens đang DISABLED** (comment trong file) — có hướng dẫn bật lại nếu cần.
 
@@ -76,10 +74,10 @@ Chạy qua step **review-fanout** với tham số `GRANULARITY = per-uc`:
 
 ## 👓 Góc nhìn tối ưu
 
-- **Đây là command tốn agent/token nhất phía thượng nguồn** — `per-uc` × 4 lăng kính × (UC+1) + tới 3 vòng critic. `AGENT_CAP=12` là núm chỉnh chính. Với PRD lớn, đây là điểm cần cân đối chi phí ↔ độ đầy đủ.
+- **Đây là command tốn agent/token nhất phía thượng nguồn** — `per-uc` × 3 lăng kính × (UC+1) + tới 3 vòng critic. `AGENT_CAP=12` là núm chỉnh chính. Với PRD lớn, đây là điểm cần cân đối chi phí ↔ độ đầy đủ.
 - **Completeness-critic tới 3 vòng** — điểm đáng đo: thực tế hội tụ ở vòng mấy? Nếu thường 1–2 vòng thì cap 3 hợp lý.
 - **Full/delta logic phức tạp** (`applied_to_version` tracking) — mạnh nhưng nhiều nhánh; dễ rơi về FULL khi có actor khác sửa PRD (vd `/review-context` xen giữa).
-- **Ranh giới với `/review-context`** — cả hai đều review PRD, dùng chung review-fanout. `/refine-prd` = phán đoán chất lượng nghiệp vụ (4 lăng kính); `/review-context` = check có mã P0–P5 + auto-fix. Chồng lấn có chủ đích hay có thể gộp?
+- **Ranh giới với `/review-context`** — cả hai đều review PRD, dùng chung review-fanout. `/refine-prd` = phán đoán chất lượng nghiệp vụ (3 lăng kính); `/review-context` = check có mã P0–P5 + auto-fix. Chồng lấn có chủ đích hay có thể gộp?
 
 ---
 

package/docs/explain/15-qc-analyze.md

@@ -2,7 +2,7 @@
 
 # 15 · `/qc-analyze` — Trạm 1: Phân rã yêu cầu + gap tài liệu
 
-> **Một câu.** Trạm đầu của dây chuyền QC: phân rã yêu cầu từ spec, map trace, và ghi **DOC_GAP** (chỗ tài liệu thiếu để test được). Markdown-first, chưa có script.
+> **Một câu.** Trạm đầu của dây chuyền QC: phân rã yêu cầu từ spec, map trace, và ghi **DOC_GAPS** (chỗ tài liệu thiếu để test được). Markdown-first, chưa có script.
 
 > 🏭 **Dây chuyền QC 6 trạm** dùng module `qc-playwright` và **QC skill** nạp từ `paths.qc_skills_dir` — mặc định bundled `.agent/skills/qc`, **override sang repo riêng của team QC** để nâng cấp framework không ghi đè (QC skill tiến hoá độc lập).
 
@@ -26,7 +26,7 @@ QC chính thức cần hiểu yêu cầu **testable** trước khi viết test.
 
 **Input:** UC-ID + spec (PRD/BDD từ spec repo) + skill `qa-analyst`.
 
-**Output (per UC):** `{qc_dir}/{UC-ID}/{platform}/REQUIREMENT_ANALYSIS.md` + `DOC_GAP.md`.
+**Output (per UC):** `{qc_dir}/{UC-ID}/{platform}/REQUIREMENT_ANALYSIS.md` + `DOC_GAPS.md`.
 
 ---
 
@@ -36,17 +36,14 @@ QC chính thức cần hiểu yêu cầu **testable** trước khi viết test.
 2. **Platform Resolution** — chốt 1 platform cho toàn QC pass (sổ trace ghi `qc_status` sẽ là `{UC-ID}-{platform}.tsv`).
 3. **Role qa-analyst** — nạp skill `{qc_skills_dir}/qa-analyst/`.
 4. **Trace mapping (bắt buộc)** — map yêu cầu ↔ scenario ↔ SC.
-5. **DOC_GAP (bắt buộc)** — ghi chỗ tài liệu thiếu/mơ hồ chặn test (blocker 🔴 xử trước ở `/qc-plan`).
-6. **Output** REQUIREMENT_ANALYSIS.md + DOC_GAP.md.
+5. **DOC_GAPS (bắt buộc)** — ghi chỗ tài liệu thiếu/mơ hồ chặn test (blocker 🔴 xử trước ở `/qc-plan`).
+6. **Output** REQUIREMENT_ANALYSIS.md + DOC_GAPS.md.
 
 ---
 
 ## Checkpoint & Gate
 
-- **CHECKPOINT: chặn thường** — lệnh ghi 2 file artifact. `--yes` bỏ qua được.
-- Guard mềm (BDD approved) — cảnh báo, không chặn cứng; `--yes` coi như Y nhưng **vẫn in cảnh báo**.
-- **Platform Resolution chạy TRƯỚC Guard** (sửa 2026-08-25): UC đa nền có nhiều `.feature`, mỗi bản
-  mang `@trace.status` riêng — kiểm duyệt trước khi biết platform là kiểm nhầm bản.
+- Guard mềm (BDD approved). Không gate chặn.
 
 ---
 
@@ -54,13 +51,13 @@ QC chính thức cần hiểu yêu cầu **testable** trước khi viết test.
 
 - **QC skill từ repo riêng** (`qc_skills_dir`) — QC team sở hữu, không bị framework upgrade ghi đè.
 - **Platform khoá một lần** cho cả pass → nhất quán sổ trace.
-- **DOC_GAP** — kênh QC phản hồi ngược chất lượng tài liệu (song song `/report-bug`).
+- **DOC_GAPS** — kênh QC phản hồi ngược chất lượng tài liệu (song song `/report-bug`).
 
 ---
 
 ## 👓 Góc nhìn tối ưu
 
-- **DOC_GAP trùng vai với review-context B-check?** — cả hai bắt gap tài liệu, nhưng QC nhìn từ góc "test được không". Đáng xem có nối được feedback này về spec.
+- **DOC_GAPS trùng vai với review-context B-check?** — cả hai bắt gap tài liệu, nhưng QC nhìn từ góc "test được không". Đáng xem có nối được feedback này về spec.
 - **Platform một pass** — feature multi-platform phải chạy QC pass nhiều lần. Chi phí lặp phân tích.
 - **Phụ thuộc QC skill ngoài** — nếu `qc_skills_dir` trỏ sai/thiếu, trạm hụt logic.
 

package/docs/explain/16-qc-plan.md

@@ -15,7 +15,7 @@ Không phải mọi scenario rủi ro ngang nhau. Trạm này xếp ưu tiên te
 ## Vị trí & tiền đề
 
 - **Vị trí:** Phase QC (trạm 2), sau `/qc-analyze`.
-- **Tiền đề:** REQUIREMENT_ANALYSIS.md + DOC_GAP.md; nên xử blocker 🔴 trước.
+- **Tiền đề:** REQUIREMENT_ANALYSIS.md + DOC_GAPS.md; nên xử blocker 🔴 trước.
 
 ---
 
@@ -52,7 +52,7 @@ Không phải mọi scenario rủi ro ngang nhau. Trạm này xếp ưu tiên te
 ## 👓 Góc nhìn tối ưu
 
 - **Trạm mỏng nhất** (~thin orchestrator + skill). Giá trị phụ thuộc chất lượng skill qa-planner.
-- **Câu hỏi cho dev** không có cơ chế theo dõi trả lời — dễ rơi. Cân nhắc gắn vào DOC_GAP/feedback.
+- **Câu hỏi cho dev** không có cơ chế theo dõi trả lời — dễ rơi. Cân nhắc gắn vào DOC_GAPS/feedback.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@educa-corp/sdd-framework",
-  "version": "0.8.1",
+  "version": "0.9.1",
   "description": "Spec Driven Development workflow framework for Claude Code",
   "bin": {
     "sdd-framework": "./bin/index.js"
@@ -21,7 +21,8 @@
     "bin/",
     "core/",
     "scripts/",
-    "docs/"
+    "docs/",
+    "!docs/update-framework-daily-logs.md"
   ],
   "keywords": [
     "claude-code",