@trungtamcongnghedigital/vsaf 1.0.0

package/skills/NTAPP/.agent/skills/NTAPP-product-research/workflow.md

@@ -0,0 +1,58 @@
+# Product Research Workflow (Problem-Solution Fit)
+
+**Goal:** Thực hiện nghiên cứu Problem-Solution Fit qua chuỗi Agent (User Researcher → Product Manager
+→ Chief Editor) để tạo Customer Pain Points Report (Personas, Customer Journey, Pain Matrix,
+Prioritization P0/P1/P2).
+
+---
+
+## WORKFLOW ARCHITECTURE — Progressive disclosure
+
+- File này giữ KHUNG điều phối (bản đồ + cổng + rule). Chi tiết thực thi nằm TRONG từng step file.
+- ⛔ Đọc ĐÚNG MỘT step mỗi lần. Hoàn tất step hiện tại (gồm mọi PAUSE) RỒI mới đọc step kế.
+  KHÔNG đọc trước nhiều step. State chuyển tiếp qua temp file, không qua việc giữ instruction trong context.
+
+---
+
+## INITIALIZATION
+Load config từ `{project-root}/_bmad/config.yaml`.
+
+### Paths
+- `market_data_input` = `{planning_artifacts}/master-market-research.md`
+- `raw_personas` = `{planning_artifacts}/temp/pr-personas.md`
+- `raw_journey` = `{planning_artifacts}/temp/pr-journey.md`
+- `raw_pain_matrix` = `{planning_artifacts}/temp/pr-pain-matrix.md`
+- `raw_prioritization` = `{planning_artifacts}/temp/pr-prioritization.md`
+- `final_report` = `{planning_artifacts}/{project_name}-customer-pain-points-report.md`
+- `archive_report` = `{planning_artifacts}/archive/{project_name}-pr-report-{date}.md`
+
+---
+
+## PIPELINE MAP (neo thường trực — 1 dòng/step, KHÔNG chi tiết)
+
+| # | Step file | Role | Output |
+|---|---|---|---|
+| 1 | steps/step-01-init.md           | pr_chief_editor | (đọc market_data_input + chọn focus) |
+| 2 | steps/step-02-segmentation.md   | user_researcher | raw_personas |
+| 3 | steps/step-03-journey.md        | user_researcher | raw_journey |
+| 4 | steps/step-04-pain-matrix.md    | user_researcher | raw_pain_matrix |
+| 5 | steps/step-05-prioritization.md | product_manager | raw_prioritization |
+| 6 | steps/step-06-synthesis.md      | pr_chief_editor | final_report + archive_report |
+
+Chuỗi: **1 → [GATE chọn focus] → 2 → [GATE chờ lệnh] → 3 → [GATE chờ lệnh] → 4 → 5 → 6**.
+
+---
+
+## GLOBAL RULES (bất biến — áp dụng mọi step)
+
+- ⛔ Đọc đúng một step file mỗi lần; chỉ đọc step kế khi step hiện tại xong + qua cổng user (nếu có).
+- ✅ **NO HALLUCINATION:** KHÔNG BAO GIỜ tự bịa dữ liệu — mọi nhận định về tệp khách hàng / hành vi /
+  nỗi đau phải Verify bằng Web Search (trừ step tổng hợp chỉ gộp nguyên văn từ file raw).
+- ✅ Ghi ngay kết quả vào file đích sau khi hoàn tất phân tích của mỗi step.
+
+---
+
+## LAUNCH
+
+Khởi động luồng Product Research từ bước Context Ingestion (pr_chief_editor đọc Market Research làm bối cảnh).
+**Next:** Read fully and follow `./steps/step-01-init.md`

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: ntapp-qa-audit
+description: 'Rà soát Shift-Left tài liệu Specs L2 + file thiết kế chi tiết `_detailed_design` (bỏ phần Đảm bảo chất lượng / Kiểm thử), tìm các điểm nhập nhằng (ambiguity), Logic/Parameter/Integration Gaps và UI-Logic inconsistency, rồi tạo danh sách câu hỏi Q&A có sẵn phương án gợi ý để QA Lead/PO làm rõ TRƯỚC khi thiết kế testcase. Input: Specs + `{id}_detailed_design.md` của `{id}` → Output: `{id}_qa_report.md` (Gap Analysis + Checklist Q&A). Workflow DỪNG chờ user trả lời (gate). Alias lệnh cũ: `/audit_advanced_qa`. Dùng khi người dùng nói "audit specs", "rà soát ambiguity", "shift-left testing", "gap analysis", "Q&A trước khi viết testcase".'
+---
+
+# NTAPP QA — Ambiguity & Quality Audit (Shift-Left)
+
+Rà soát chéo đa tầng đặc tả + file thiết kế chi tiết để phát hiện sớm lỗ hổng logic, tham số biên mập mờ và bất đồng bộ FE-BE, kết tinh thành Checklist Q&A cho PO/Lead làm rõ trước khi viết bất kỳ testcase nào.
+
+Đọc đầy đủ và tuân theo: `./workflow.md`

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/agents/agent_qa_auditor.md

@@ -0,0 +1,33 @@
+# SYSTEM INSTRUCTION: SENIOR QA ENGINEER (MODE 1: AUDIT)
+
+## [B] - BACKGROUND (Bối Cảnh)
+Bạn là một Senior QA Engineer chuyên nghiệp. Nhiệm vụ của bạn là bảo vệ chất lượng dự án ngay từ pha thiết kế bằng cách phát hiện sớm tất cả các điểm nhập nhèm (ambiguity), các lỗ hổng logic, và các điểm không đồng bộ giữa đặc tả hệ thống và giao diện trước khi tiến hành viết kịch bản kiểm thử chi tiết.
+
+## [M] - MISSION (Sứ Mệnh)
+Từ tài liệu đặc tả **L2 TechSpec / UX Spec** và **file thiết kế chi tiết `{id}_detailed_design.md`** (bỏ phần Đảm bảo chất lượng / Kiểm thử) của một đơn vị công việc `{id}` để thực hiện rà soát chéo nghiêm ngặt. Chỉ ra các lỗi thiết kế, lỗ hổng tham số, và các kịch bản ngoại lệ chưa được xử lý. Xuất ra tài liệu báo cáo câu hỏi làm rõ **`{qa_artifacts}/{id}/{id}_qa_report.md`**.
+
+## [A] - ACTIONS & RULES (Hành Động & Quy Tắc)
+
+### 1. Kiểm tra sự sẵn sàng và Tuân thủ Missing Input Handling:
+- Đọc L2 TechSpec, UX Spec và file `{detailed_design_root}/{id}_detailed_design.md` — **bỏ phần Đảm bảo chất lượng / Kiểm thử** (heading — không phân biệt hoa/thường — chứa "chất lượng", "kiểm thử", "quality assurance" hoặc "testing"/"test"; bỏ từ heading đó đến ngay trước mục kế tiếp).
+- Nếu phát hiện bất kỳ file đầu vào nào thiếu hoặc không thể đọc được, hãy **DỪNG pipeline lập tức** và thông báo lỗi rõ ràng cho người dùng (Không tự động sinh dữ liệu giả định/mock).
+
+### 2. Thực hiện Rà Soát Chi Tiết (Audit Checkpoints):
+Quét chéo toàn bộ dữ liệu để phát hiện và phân loại các loại lỗ hổng sau:
+- **Logic Gaps (Lỗ hổng Logic)**: Các trường hợp xử lý lỗi BE chưa định nghĩa (ví dụ: Downstream timeout, HTTP 5xx, Token expired); các luồng đồng bộ DB hoặc ghi Log thiếu mã trace; các luồng xử lý không đồng bộ (CompletableFuture) thiếu trạng thái xử lý lỗi ở FE UI.
+- **Parameter Gaps (Lỗ hổng Tham Số)**: Các trường dữ liệu (phần Dữ liệu) thiếu đặc tả độ dài giới hạn (`maxLength`), thiếu format validation (Regex), thiếu quy định cho các giá trị đặc biệt (Null, Empty, Space).
+- **Integration Gaps (Lỗ hổng Tích Hợp)**: Ranh giới giao tiếp giữa các hệ thống (API downstream, auth chain, Bearer token mask, JWKS downtime).
+- **UI-Logic Inconsistency (Bất đồng bộ FE-BE)**: Tên trường/control ở UI (phần Giao diện) khác với tên field trong phần Logic hoặc phần Dữ liệu.
+
+### 3. Tuân thủ Zero-Fabrication & Missing Input Handling:
+- Tuyệt đối không tự ý giả định, bịa đặt giải pháp cho các lỗ hổng phát hiện được. 
+- Mọi điểm thiếu sót phải được định dạng dưới dạng câu hỏi làm rõ **[TBD]** để trình bày lên người dùng/PO trong báo cáo.
+
+## [D] - DELIVERABLES (Kết Quả Đầu Ra)
+Tạo file Markdown tại: `{qa_artifacts}/{id}/{id}_qa_report.md` tuân thủ mẫu `../templates/qa_report_template.md` bao gồm:
+1. **Phần 1: Scope & Pre-flight Checklist**: Danh sách các file inputs được đọc và trạng thái sẵn sàng.
+2. **Phần 2: Ambiguity & Gap Analysis Table**: Bảng thống kê các lỗi/lỗ hổng phát hiện được phân loại rõ rệt kèm mức độ nghiêm trọng (High, Medium, Low).
+3. **Phần 3: Checklist Q&A (Câu hỏi làm rõ)**: Danh sách câu hỏi rõ ràng, trực diện kèm các phương án gợi ý giải quyết (Ví dụ: A/B/C) để người dùng chỉ cần chọn hoặc ghi phản hồi ngắn.
+
+## [🚫] - ANTI-PATTERNS (Quy Tắc Chống Mẫu Nghiêm Cấm)
+> Tuân thủ đầy đủ danh sách chống mẫu tại: [ntapp-core-compliance.md](../references/ntapp-core-compliance.md)

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/references/behavior-completeness-rules.md

@@ -0,0 +1,45 @@
+# Behavior & Completeness Gap Rules
+
+Nhóm "hành vi / độ phủ" — chạy ĐỦ; im lặng / không tất định → GAP + `[TBD]`.
+
+---
+
+## 1. Cross-System State-Sync Gap
+
+**Cross-System State-Sync Gaps (BẮT BUỘC khi trạng thái tài nguyên đọc ở một thời điểm rồi bị hành động ở thời điểm khác, hoặc đồng bộ bất đồng bộ giữa nhiều hệ thống):** Rà soát và cờ MỌI điểm sau, đối chiếu xuyên nguồn (phần Logic/sequence ↔ techspec ↔ Module 0 state registry/cache/event contract):
+
+1. **Revalidate tại thời điểm ghi (TOCTOU):** giữa lúc đọc list/cache và lúc submit/bind/duyệt, trạng thái tài nguyên có thể đã đổi ở hệ nguồn — spec có bắt buộc **đọc lại trạng thái hiện tại trước khi ghi** không? Nếu tài nguyên không còn ở trạng thái hợp lệ mà vẫn cho tạo/bind = gap.
+2. **Cửa sổ stale (cache TTL / list read-only):** dữ liệu trạng thái phục vụ hành động có đến từ cache có TTL / list không refresh không? Bao lâu? Trong cửa sổ đó hành động dựa trên trạng thái cũ được xử lý ra sao.
+3. **Event-before-entity + đồng bộ lỡ:** event/callback đồng bộ trạng thái có thể đến **trước khi bản ghi đích tồn tại** (hoặc bị nuốt/ACK) → spec có backfill/reload/đối soát (reconciliation) để không mất trạng thái vĩnh viễn không? Thiếu đường phục hồi = gap.
+4. **Snapshot vs source-of-truth:** trạng thái có bị copy/denormalize/seed cứng vào bản ghi local lúc tạo thay vì đọc live không? Sau khi nguồn đổi, giá trị local có được đồng bộ về khớp nguồn không.
+5. **Terminal/ineligible state + state machine:** tài nguyên ở trạng thái kết thúc/không hợp lệ (đã duyệt/từ chối/hủy/hết hạn) có bị đưa vào luồng giả định trạng thái trước đó (double-process) không.
+
+Mức mặc định **≥🟡**; lên **🔴** nếu làm "Kết quả mong muốn" mơ hồ, khiến trạng thái local lệch nguồn mà không tự sửa, hoặc gây double-process. KHÔNG gộp các điểm khác bản chất (TOCTOU / stale-cache / event-before-entity / snapshot-drift) thành một gap.
+
+---
+
+## 2. List/Collection Display Completeness
+
+**List/collection display completeness (BẮT BUỘC cho MỖI màn danh sách / bảng / collection):** Chốt và đối chiếu xuyên nguồn (phần Giao diện ↔ techspec/API ↔ Module 0), cờ MỌI mâu thuẫn:
+
+1. **Bao nhiêu bản ghi hiển thị** trên màn — page size cụ thể / giới hạn cứng / "hiển thị tất cả"; nguồn nào ghi số mấy (vd phần Giao diện nói 20/trang vs techspec nói 50).
+2. **Điều kiện hiển thị / lọc mặc định** — status nào được liệt, cửa sổ thời gian mặc định, data-scope (partner/role), record nào bị ẩn. **Record thoả điều kiện nhưng không hiện = gap** (và ngược lại).
+3. **Cơ chế tải thêm** — **phân trang** (page size, sort key/hướng, tổng số) **vs infinite/virtual scroll vs "scroll đến hết"**; và hành vi ở biên: **vượt trang cuối**, **danh sách rỗng** (empty-state vs 404), **đang tải**. Nguồn khác nhau chọn cơ chế khác nhau = gap.
+4. **Count-consistency** — số ở badge/tổng ("(N)", "totalElements", tab count) phải **khớp số dòng thực tế + khớp tiêu chí lọc đang áp**. Lệch = gap (dễ lọt bug thật).
+5. **Volume boundary** — phải phủ ca **0 / 1 / đúng 1 trang / tràn trang / rất lớn** khi viết testcase; nếu spec không nói giới hạn trên → `[TBD]`.
+
+Mức mặc định **≥🟡**; lên **🔴** nếu làm "Kết quả mong muốn" của tiêu chí "thấy đủ/đúng danh sách" mơ hồ hoặc chặn demo.
+
+---
+
+## 3. Field-Level Expectation Gate
+
+Với **mỗi trường nhập / tham số** và **mỗi cột hiển thị**, soi các câu dưới. Mức `≥🟡`; lên `🔴` nếu làm expected mơ hồ, hoặc là lỗ hổng bảo mật / sai tiền.
+
+1. **Validation input (gọn):** hoa/thường, khoảng trắng, trống–rỗng–không nhập, ký tự đặc biệt → xử lý ra sao? *(chi tiết ở Contradiction & Core Gaps — Parameter Gaps.)*
+2. **So khớp hoa/thường khi lọc:** gõ HOA mà dữ liệu lưu thường → lọc còn ra kết quả không?
+3. **Tie-break:** cùng khóa sắp xếp thì dòng nào lên trước?
+4. **Chuẩn hóa nhiều nguồn:** định dạng / múi giờ / đơn vị khác nhau có quy về một chuẩn không?
+5. **Phân quyền theo vai trò:** vai trò nào được thao tác / xem?
+6. **Phân quyền theo phạm vi dữ liệu (IDOR):** cùng vai trò, user có chỉ thấy dữ liệu của mình không?
+7. **Đồng thời (lost update):** 2 người sửa cùng 1 bản ghi → có khóa version / atomic không?

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/references/contract-consistency-rules.md

@@ -0,0 +1,38 @@
+# Contract & Consistency Gap Rules
+
+Nhóm "so khớp / mâu thuẫn" — chạy ĐỦ; im lặng / lệch → GAP + `[TBD]`.
+
+---
+
+## 1. Contradiction & Core Gaps
+
+Bốn loại gap cơ bản — soi trong từng unit và giữa DD ↔ nguồn.
+
+- **Logic Gaps**: luồng lỗi downstream (PMT/PCM/Policy) chưa định nghĩa, thiếu xử lý lỗi mạng, token Keycloak hết hạn, thiếu logic lưu DB.
+- **Parameter Gaps**: trường dữ liệu (phần Dữ liệu) thiếu `maxLength` / format-Regex.
+- **UI-Logic Inconsistency**: controls (Giao diện) ↔ biến logic (Logic/Dữ liệu) lệch naming — vd `userId` vs `user_id`.
+- **Contradiction Gaps**: cùng ràng buộc (maxLength, enum, tồn-tại param, error-code) lệch giữa nguồn (`_detailed_design` ↔ L2 TechSpec / DD cũ) — vd `maxLength 64` (Giao diện) vs `100` (nơi khác); param còn ở techspec nhưng đã bỏ ở DD → Gap, không tự chọn giá trị.
+  - **maxLength** hoà giải 3 điểm: spec ↔ FE `maxlength` attr ↔ BE `@Size(max=)`/cột DB. Lệch cặp nào = GAP (vd FE=100, BE=64, spec=20). FE-attr > BE-limit → testcase drive biên `BE+1` (≥🟡).
+- **Navigation / Post-action Routing** (MỖI create/submit/save/cancel/delete): đối chiếu đích điều hướng sau khi thành công giữa mọi mục (Post-condition, bảng control, Navigation-map, luồng UX). Đích khác nhau (vd `redirect /detail/{id}` vs "về List + highlight row") → GAP (≥🟡, 🔴 nếu luồng chính). Khác theo mode (modal A vs page B) mà DD không tách → GAP (thiếu điều kiện).
+  - **Side-effect completeness**: liệt kê đủ side-effect mỗi action thành công (thêm/xoá/reorder row; counter/badge; toast; clear draft/localStorage) + kiểm mỗi cái có trong bảng logic tất định, không chỉ Post-condition / ghi chú "inherit". Chỉ ở prose mà vắng bảng logic = GAP (≥🟡, 🔴 nếu là tiêu chí demo — vd badge/count).
+- **Cụm "A HOẶC B" chưa-chốt**: quét Post-condition/Expected/bảng tương tác tìm "X HOẶC Y" (/, hay) cho một hành vi tất định (điều hướng, status khởi tạo, thông báo, đích lưu) → GAP + `[TBD]`, PO chốt 1 nhánh hoặc nêu điều kiện.
+
+---
+
+## 2. Cross-Unit Contract Gap
+
+Dựng ma trận contract cross-unit theo khoá dùng chung (field/regex/maxLength, enum + hoa/thường, query param FE↔BE, response field FE↔BE, error-code, cache key); diff mọi unit chạm khoá, lệch = Gap. Bắt cả >1 spec cho 1 surface, và mẫu wireframe ≠ dữ liệu staging thật.
+
+---
+
+## 3. Cross-Document Gap
+
+Đối chiếu nguồn: Module 0 (state registry/ERD, cache key, contract) ↔ techspec ↔ ux_design ↔ PRD (FR/BR). Bắt mâu thuẫn nội bộ 1 tài liệu (vd ux_design 2 mục lệch) + citation "ma" (DD cite mục không tồn tại).
+
+---
+
+## 4. FE↔BE Business-Rule & Guard/Validate Parity
+
+So luật nghiệp vụ 2 nhánh: ai enforce phân quyền/data-scope (FE-only vs BE), enum canonical, luồng hợp lệ (state tạo từ màn nào), partial/ordering, list "count + status". Lệch hành vi (không chỉ tên field) = Gap.
+
+- **FE-guard ↔ BE-validate** (MỖI create/submit/action): FE chặn (nút disabled, min-selection, field required, confirm dialog, empty-state) ↔ BE validate (`@NotNull`/`@Size(min/max)`/required-when/regex/cardinality). Cờ ca FE chặn-BE cho qua & ngược lại. Vét: empty/zero-selection (vd tạo composite khi chưa chọn sub-link), min-cardinality (≥1), nút-disabled, kết quả input rỗng (BE tạo record gì? 400? status nào?). ≥🟡, 🔴 nếu luồng chính / expected mơ hồ. Mỗi mâu thuẫn = 1 GAP riêng.

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/references/no-hallucination-rule.md

@@ -0,0 +1,44 @@
+# No Hallucination Rule
+
+## Mục đích
+
+Chặn việc agent tự suy diễn field, button, message lỗi, API, trạng thái hoặc business rule không có trong tài liệu đầu vào.
+
+## Nguyên tắc bắt buộc
+
+Agent chỉ được sinh testcase dựa trên một trong các nguồn sau:
+
+1. DD/PRD/SRS/KBNV được cung cấp.
+2. KBKT cũ được cung cấp.
+3. API spec/database spec/UI mockup được cung cấp.
+4. Rule đã tồn tại trong repo `.agent/rules`.
+5. Q&A đã được xác nhận.
+
+## Khi thiếu thông tin
+
+Nếu thiếu thông tin quan trọng, agent không được tự đoán.
+
+Thay vào đó phải tạo Q&A với format:
+
+| ID | Vùng thiếu thông tin | Câu hỏi cần làm rõ | Ảnh hưởng nếu không rõ | Người cần trả lời |
+| --- | --- | --- | --- | --- |
+| QA-001 | Message lỗi | Khi lưu thiếu Mã nhóm thuộc tính thì message chính xác là gì? | Không thể viết expected result chính xác | BA/PO/Dev |
+
+## Ví dụ tình huống phải tạo Q&A
+
+- File mẫu có expected `Báo lỗi: ???`.
+- DD nói field bắt buộc nhưng không nêu message lỗi.
+- DD nói maxlength nhưng không nêu giới hạn cụ thể.
+- DD có button nhưng không mô tả onclick.
+- Có conflict giữa UI mockup và API spec.
+- Có rule cũ và rule mới mâu thuẫn.
+
+## Điều kiện reject
+
+Reject output nếu agent:
+
+- Tự tạo message lỗi không có căn cứ.
+- Tự thêm SQL/API/DB check khi tài liệu không có.
+- Tự thêm field ngoài màn hình.
+- Tự đổi trạng thái enable/disable khác với spec.
+- Tự suy diễn flow thành công khi spec chưa mô tả.

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/references/ntapp-core-compliance.md

@@ -0,0 +1,45 @@
+# NTAPP Core Compliance & Anti-Patterns
+
+## Mục đích
+Tài liệu này quy định các quy tắc cốt lõi (Iron Rules) và chống mẫu (Anti-Patterns) đặc thù của dự án NTAPP khi sinh kịch bản kiểm thử (KBKT).
+
+---
+
+## 1. Quy tắc Bất Biến (Iron Rules)
+
+### 1.1. Zero-Summarization & Zero-Fabrication
+- **Không tóm tắt**: Giữ nguyên 100% chi tiết kỹ thuật, cấu trúc JSON sample, schema dữ liệu.
+- **Không tự chế**: Cấm tự chế dữ liệu hoặc mock giả định. Sinh test data phải dùng dữ liệu kiểm thử cụ thể, tường minh, có cấu trúc thực tế. (Xem thêm: [no-hallucination-rule.md](./no-hallucination-rule.md))
+
+### 1.2. Traceability (Truy vết)
+- Từng dòng kịch bản kiểm thử phải chỉ rõ link liên kết tới dòng logic của BE (phần Logic trong `_detailed_design`) hoặc UI Control của FE (phần Giao diện trong `_detailed_design`).
+- Đảm bảo 100% các dòng logic matrix và mã lỗi trong specs được bao phủ trọn vẹn trong test cases.
+- **Tag bắt buộc**: Mỗi testcase cần gắn tag phân loại rõ ràng:
+  - `[HappyPath]`
+  - `[Negative]`
+  - `[Boundary]`
+  - `[Validation]`
+  - `[Permission]`
+  - `[Integration]`
+  - `[Regression]`
+  - `[ImpactArea]`
+  - `[BugRecheck]`
+
+### 1.3. Bảo mật
+- Tuyệt đối không đọc trực tiếp file `.env` hoặc ghi lộ lọt credentials.
+
+---
+
+## 2. Quy Tắc Chống Mẫu (Anti-Patterns)
+
+Nghiêm cấm các hành vi sau khi sinh KBKT:
+- ❌ **Gộp nhiều bước chạy 1 lần**: Phải tuân thủ quy trình chạy tuần tự từng Mode/Step.
+- ❌ **Rút gọn hoặc bỏ sót test case khi mapping sang bảng**: Phải map đầy đủ 100% kịch bản kiểm thử đã thiết kế sang bảng 10 cột, không gộp hay cắt bớt.
+- ❌ **Sinh tất cả test cases 1 lần cho hệ thống lớn**: Phải chia tách thành từng module/id nhỏ để xử lý cuốn chiếu chất lượng cao.
+- ❌ **Test Steps mơ hồ, không ghi rõ dữ liệu nhập**: Từng bước kiểm thử phải mô tả rõ thao tác nhập liệu gì, chọn gì, với dữ liệu cụ thể nào.
+- ❌ **Sinh kịch bản hời hợt, gom nhóm (Superficial Generation)**: NGHIÊM CẤM việc gom chung các trường hợp kiểm thử khác biệt vào một kịch bản duy nhất hoặc chỉ sinh ra số lượng ít ỏi các kịch bản bề mặt. Phải vét cạn toàn bộ luồng rẽ, tổ hợp biến, ranh giới biên (BVA) và kiểm thử chéo để đảm bảo khối lượng testcase cực kỳ chi tiết, cụ thể cho từng trường hợp nhỏ nhất.
+- ❌ **Gộp validation nhiều trường vào 1 test case**: Mỗi trường dữ liệu (input field) phải có các Test Case validation riêng biệt.
+- ❌ **Dùng chung 1 bộ validation cho tất cả fields**: Phải thiết kế validation riêng dựa trên đặc tính của từng trường dữ liệu (Email ≠ Phone ≠ Date ≠ Text).
+- ❌ **Bỏ qua security validation cho text/textarea fields**: Phải bao phủ kiểm thử bảo mật cơ bản như SQL Injection, XSS trên các trường nhập liệu tự do.
+- ❌ **Không liệt kê danh sách fields trước khi sinh validation TCs**: Bắt buộc phải liệt kê đầy đủ danh sách trường thông tin từ UI spec trước rồi mới tiến hành sinh các ca kiểm thử validation tương ứng.
+- ❌ **Sao chép KBKT nhúng sẵn ở phần Đảm bảo chất lượng / Kiểm thử của `_detailed_design`**: Được đọc `_detailed_design` để phân tích, nhưng TUYỆT ĐỐI KHÔNG lấy/sao chép/trích xuất các kịch bản kiểm thử (KBKT) đã nhúng sẵn ở phần Đảm bảo chất lượng / Kiểm thử (phần này phải bỏ qua khi đọc). Hệ thống BẮT BUỘC phải thiết kế testcase mới từ đầu dựa trên việc phân tích phần Logic và phần Dữ liệu.

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/steps/step-01-ambiguity-audit.md

@@ -0,0 +1,44 @@
+# STEP 01: AMBIGUITY & QUALITY AUDIT (MODE 1: AUDIT)
+
+> **Acting as:** [Senior QA Engineer](../agents/agent_qa_auditor.md)
+> **Tuân thủ:** [ntapp-core-compliance.md](../references/ntapp-core-compliance.md) (Zero-Fabrication, Zero-Summarization, Traceability) + [no-hallucination-rule.md](../references/no-hallucination-rule.md) — Đặc biệt Zero-Fabrication (cấm bịa giải pháp cho gap) và Missing Input Handling (thiếu input → DỪNG, hỏi user, không mock).
+
+---
+
+## 1. Mục tiêu
+Rà soát toàn diện các tài liệu đặc tả và **file thiết kế chi tiết `{id}_detailed_design.md`** để tìm ra các rủi ro, lỗ hổng logic nghiệp vụ, các tham số biên mập mờ và các vấn đề tích hợp trước khi tiến hành viết kịch bản kiểm thử.
+
+## 2. Nguyên liệu đầu vào (Input)
+- **Tài liệu nguồn (BẮT BUỘC đối chiếu — xem §3 mục 2: Cross-Unit & Cross-Document Gaps):** BE = `{module}_techspec.md` + Module 0 (`00_system_connectivity_integration.md`) + `project_wbs.md`; FE = `ux_design.md` + `{fe}_techspec.md`; chung = `prd.md`.
+- **Thiết kế chi tiết** — đọc file `{detailed_design_root}/{id}_detailed_design.md` của **mỗi** unit; **bỏ phần Đảm bảo chất lượng / Kiểm thử** (heading — **không phân biệt hoa/thường** — chứa "chất lượng", "kiểm thử", "quality assurance" hoặc "testing"/"test"; thường là Mục 5 — bỏ từ heading đó đến ngay trước mục kế tiếp), vì phần này chứa KBKT nhúng sẵn, không dùng để audit.
+
+> **SLICE mode:** `{id}` là SLICE ⇒ đọc file `{unit}_detailed_design.md` của **MỌI** unit trong `units:` (vẫn bỏ phần Đảm bảo chất lượng / Kiểm thử).
+
+---
+
+## 3. Chỉ thị thực thi chi tiết
+1. **Kiểm tra đầu vào (Missing Input Handling)**: Đảm bảo các file input tồn tại và đọc được. Nếu thiếu, dừng ngay lập tức và báo cáo lỗi cho người dùng.
+   - **Gate độ phủ (bắt buộc):** Liệt kê **mỗi unit** vào bảng pre-flight; **đọc file `_detailed_design` của MỌI unit** rồi mới kết luận. Bỏ sót unit = audit chưa xong.
+   - **Cảnh báo:** phần Ma trận đồng bộ (Sync Matrix) trong DD mỗi unit chỉ chứng minh nhất quán **TRONG** unit đó — KHÔNG suy ra nhất quán cross-unit. Audit phải tự dựng lớp cross-unit (xem §3 mục 2 — Cross-Unit Contract Gaps).
+2. **Quét chéo đa tầng để phát hiện Gaps** — chạy **ĐỦ** cả 2 bộ rule dưới; im lặng / lệch ở điểm nào → GAP + `[TBD]`:
+
+   | Bộ rule | Gồm |
+   |---|---|
+   | [contract-consistency-rules.md](../references/contract-consistency-rules.md) | Contradiction & Core (Logic/Parameter/UI-Logic) · **Navigation/Post-action routing** · **cụm "A HOẶC B" tất định** · Cross-Unit Contract · Cross-Document · FE↔BE parity |
+   | [behavior-completeness-rules.md](../references/behavior-completeness-rules.md) | Cross-System State-Sync · List/collection completeness · Field-Level Expectation Gate |
+
+3. **Tuân thủ Zero-Fabrication (Cấm tự bịa)**: Không tự giả lập phương án giải quyết cho các lỗ hổng phát hiện được. 
+4. **Tạo báo cáo Q&A**: Sử dụng template `../templates/qa_report_template.md` để ghi nhận các điểm mập mờ thành danh sách câu hỏi [TBD] cho người dùng/PO trả lời.
+
+---
+
+## 4. Đầu ra yêu cầu
+- File báo cáo chất lượng: **`{qa_artifacts}/{id}/{id}_qa_report.md`** — đặt trong **thư mục con riêng theo chức năng** `{id}` (vd `test/HUB-01/HUB-01_qa_report.md`, `test/SLICE-03/SLICE-03_qa_report.md`), KHÔNG gom chung vào `reviews/` (template `../templates/qa_report_template.md` — theo đúng bố cục template).
+- **Bố cục dễ đọc (bắt buộc):** (1) header + **bảng "📚 Tài liệu tham chiếu" đặt NGAY ĐẦU** (cột đầu = **tên file ĐẦY ĐỦ** bọc link tương đối từ root workspace + phiên bản; KHÔNG để bảng này xuống cuối) + "Cách dùng" → (2) mục 1 Pre-flight → (3) **3 bảng theo mức 🔴 Cao / 🟡 Trung bình / ⚪ Thấp**, mỗi mức 1 bảng, **cùng 5 cột đúng thứ tự: `Mã · Trạng thái · Vấn đề là gì & vì sao quan trọng · Phương án (✓=nên) · Trả lời`** → (4) GHI CHÚ.
+- **Cột "Trạng thái" (cột 2, ngay sau Mã):** tick 1 trong 3 — **Todo** (mới, mặc định) · **Resolved** (đã có Trả lời) · **Pending** (đã trả lời nhưng cần làm rõ thêm). Render checkbox stack `☑&nbsp;Todo<br>☐&nbsp;Resolved<br>☐&nbsp;Pending`.
+- **Cột "Vấn đề" (quan trọng nhất — để ai đọc cũng hiểu):** mỗi ô gồm **1 tiêu đề đậm** + các dòng có **NHÃN CỐ ĐỊNH**, mỗi nguồn 1 dòng, **trích dẫn clickable ĐẶT Ở ĐẦU DÒNG** dạng `**[<tên file ĐẦY ĐỦ> §<mục> · dòng <N>](<link>#L<N>):** <file này nói gì>`, kết thúc bằng dòng `**⇒ Hậu quả:** <chặn demo / expected mơ hồ / lọc sai…>`. TUYỆT ĐỐI KHÔNG viết tắt tên file (không `DD`/`L2`/`M0` trong link), KHÔNG telegraphic, KHÔNG để trích dẫn trôi về cuối câu, KHÔNG nhồi nhiều nguồn vào 1 câu dài. Link = đường dẫn tương đối từ root workspace + anchor `#L<N>` (range → dùng dòng đầu).
+- **Mâu thuẫn cấp tài liệu** (Module 0 / techspec / ux / prd lệch nhau, hoặc 1 file tự mâu thuẫn): KHÔNG tách bảng riêng — đưa thành GAP trong 3 bảng theo mức (nếu ảnh hưởng testcase), hoặc gộp vào mục "Vệ sinh tài liệu" trong GHI CHÚ (nếu chỉ là drift version/số dòng, không chặn test). Luôn trích file/§/dòng.
+- Đánh số `GAP-NN` **liên tục xuyên suốt 3 bảng** (không reset theo mức). Mỗi phương án A/B/C ngắn gọn, ô "Trả lời" để trống cho PO điền.
+- **GATE:** chỉ chuyển sang Mode 2 GENERATE khi **mọi điểm 🔴 Cao = Resolved** (cột Trạng thái, do PO/Lead chốt). Điểm 🟡/⚪ chưa Resolved → có thể ghi nhận rủi ro và tiếp tục.
+
+---

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/templates/qa_report_template.md

@@ -0,0 +1,90 @@
+# RÀ SOÁT ĐIỂM CHƯA RÕ (AMBIGUITY AUDIT) — {id}
+
+**Đối tượng:** {id} · **Ngày:** {timestamp}
+**Mục tiêu / phạm vi demo (nếu là slice):** {mô tả 1 dòng điều cần build/demo}
+
+### 📚 Tài liệu tham chiếu (đọc trước)
+
+> Bảng này đặt **NGAY ĐẦU** báo cáo (không để cuối). Cột đầu là **tên file ĐẦY ĐỦ** (KHÔNG viết tắt `DD`/`L2`/`M0`), bọc link tương đối từ root workspace để bấm mở được.
+
+| Tên file (bấm để mở) | Vai trò | Phiên bản |
+|:---|:---|:---|
+| [{ĐV}_detailed_design.md]({detailed_design_root}/{ĐV}_detailed_design.md) | Thiết kế chi tiết (DD) của {ĐV} | {vN} |
+| [{module}_techspec.md]({techspec_root}/{module}_techspec.md) | TechSpec Layer 2 — source-of-truth hiện hành | {vN} |
+| [00_system_connectivity_integration.md]({architecture_root}/00_system_connectivity_integration.md) | Module 0 — contract kết nối | {vN} |
+| [prd.md / ux_design.md / project_wbs.md]({...}) | Nguồn đối chiếu bổ sung (khi có) | {vN} |
+
+**Cách dùng báo cáo:** mỗi dòng là 1 điểm đang **mâu thuẫn** hoặc **chưa rõ**. Trong cột *Vấn đề*, **mỗi trích dẫn đặt ở ĐẦU dòng làm nhãn in đậm** — ghi **tên file ĐẦY ĐỦ · §mục · (dòng N)** và **bấm được** (click nhảy thẳng tới đúng dòng). PO/Lead điền **A/B/C** vào cột *Trả lời*, rồi tick cột *Trạng thái*. Chỉ bắt đầu viết testcase khi **mọi dòng 🔴 Cao** = Resolved.
+**Cột Trạng thái:** **Todo** (mới, chưa ai phản hồi — mặc định) · **Resolved** (đã có câu trả lời ở cột Trả lời) · **Pending** (đã trả lời nhưng cần làm rõ thêm).
+
+> [!IMPORTANT]
+> **Quy ước viết cột "Vấn đề" (bắt buộc — để ai đọc cũng hiểu):** KHÔNG viết cụt kiểu điện tín, KHÔNG nhồi nhiều nguồn vào 1 câu dài. Mỗi ô gồm 1 **tiêu đề đậm** + các dòng có **NHÃN CỐ ĐỊNH**, mỗi nguồn 1 dòng, **trích dẫn clickable đặt ở ĐẦU dòng**:
+> - `**{tiêu đề ngắn}.**`
+> - `**[{tên file đầy đủ} §{mục} · dòng {N}]({link}#L{N}):** {file này nói gì}` — lặp 1 dòng cho MỖI nguồn mâu thuẫn (DD, techspec, Module 0…).
+> - `**⇒ Hậu quả:** {chặn demo / expected mơ hồ / lọc sai…}`.
+>
+> Link = đường dẫn tương đối từ root workspace + anchor `#L{N}` (dùng dòng đầu nếu là range). Cột "Phương án" liệt kê sẵn A/B/C, dấu **✓** = khuyến nghị; PO điền lựa chọn vào cột "Trả lời" rồi tick "Trạng thái".
+
+---
+
+## 1. ĐÃ ĐỌC GÌ (Pre-flight — kiểm tra độ phủ đầu vào)
+
+| Unit | Loại | DD đọc? | Ghi chú |
+|:---|:---|:---:|:---|
+| {unit} | BE/FE | {OK/MISSING/N/A} | |
+
+> **Coverage verdict:** {đã đọc file DD của mọi unit? PASS / ghi ngoại lệ}. **Phần Đảm bảo chất lượng / Kiểm thử KHÔNG đọc** (chứa KBKT nhúng sẵn — không dùng để audit).
+> **Tài liệu nguồn đã đối chiếu:** Module 0, {module}_techspec, ux_design, prd, project_wbs.
+
+---
+
+## 🔴 MỨC CAO — bắt buộc chốt trước khi viết testcase
+
+> Blocker luồng chính / khiến fixture fail / khiến cột "Kết quả mong muốn" mơ hồ. Gate GENERATE chỉ mở khi **mọi dòng 🔴 = Resolved**.
+
+| Mã | Trạng thái | Vấn đề là gì & vì sao quan trọng | Phương án (✓ = nên chọn) | Trả lời |
+|:---|:---|:---|:---|:---:|
+| GAP-01 | ☑&nbsp;Todo<br>☐&nbsp;Resolved<br>☐&nbsp;Pending | **{tiêu đề ngắn}.**<br>**[{FileA_đầy_đủ} §{mục} · dòng {X}]({linkA}#L{X}):** {FileA nói gì}.<br>**[{FileB_đầy_đủ} §{mục} · dòng {Y}]({linkB}#L{Y}):** {FileB nói gì}.<br>**⇒ Hậu quả:** {hậu quả cụ thể lên demo/test}. | **A✓** {hướng nên chọn}<br>**B** {hướng khác}<br>**C** {hướng khác} | |
+| GAP-02 | ☑&nbsp;Todo<br>☐&nbsp;Resolved<br>☐&nbsp;Pending | **{tiêu đề}.**<br>**[{File} §{mục} · dòng {N}]({link}#L{N}):** {…}.<br>**⇒ Hậu quả:** {…}. | **A✓** …<br>**B** … | |
+
+## 🟡 MỨC TRUNG BÌNH
+
+> Sai logic nhánh / ranh giới (boundary) / mã lỗi.
+
+| Mã | Trạng thái | Vấn đề là gì & vì sao quan trọng | Phương án (✓ = nên chọn) | Trả lời |
+|:---|:---|:---|:---|:---:|
+| GAP-… | ☑&nbsp;Todo<br>☐&nbsp;Resolved<br>☐&nbsp;Pending | **{tiêu đề}.**<br>**[{File} §{mục} · dòng {N}]({link}#L{N}):** {…}.<br>**⇒ Hậu quả:** {…}. | **A✓** …<br>**B** … | |
+
+## ⚪ MỨC THẤP
+
+> Hiển thị / định dạng / làm rõ nhỏ — không chặn viết testcase.
+
+| Mã | Trạng thái | Vấn đề là gì & vì sao quan trọng | Phương án (✓ = nên chọn) | Trả lời |
+|:---|:---|:---|:---|:---:|
+| GAP-… | ☑&nbsp;Todo<br>☐&nbsp;Resolved<br>☐&nbsp;Pending | **{tiêu đề}.**<br>**[{File} §{mục} · dòng {N}]({link}#L{N}):** {…}.<br>**⇒ Hậu quả:** {…}. | **A✓** … | |
+
+---
+
+## GHI CHÚ
+
+**Vệ sinh tài liệu (không chặn viết testcase — nên gửi người chủ tài liệu sửa để tránh lệch tiếp):**
+- {vd: số phiên bản / số dòng techspec lệch giữa các unit — trích **tên file đầy đủ + link dòng**}.
+- {vd: version Module 0 mỗi nơi ghi một kiểu — trích file}.
+
+**Viết testcase được ngay (không phải đợi mức Cao):** {liệt kê phần contract đã rõ, an toàn viết ngay — vd validation input, mã lỗi 4xx đã tường minh, happy path đã đủ}.
+
+**Tổng: {N} điểm — 🔴 Cao: {a} · 🟡 Trung bình: {b} · ⚪ Thấp: {c}.**
+
+---
+*Đây là bước bắt buộc trước khi viết testcase — DỪNG chờ PO/Lead điền cột "Trả lời". Chỉ chuyển sang Mode 2 GENERATE khi **mọi dòng 🔴 Cao** = Resolved.*
+
+<!--
+GHI CHÚ CHO AI (không render — hướng dẫn sinh báo cáo):
+1. Bố cục cố định: (1) header + **bảng "📚 Tài liệu tham chiếu" đặt NGAY ĐẦU** (cột đầu = tên file ĐẦY ĐỦ bọc link tương đối từ root workspace, kèm phiên bản) + "Cách dùng" + Cột Trạng thái → (2) mục 1 pre-flight → (3) 3 bảng theo mức 🔴/🟡/⚪, mỗi mức 1 bảng, CÙNG 5 cột THEO THỨ TỰ (Mã · Trạng thái · Vấn đề · Phương án · Trả lời) → (4) GHI CHÚ. KHÔNG để bảng tài liệu tham chiếu xuống cuối.
+2. KHÔNG tách bảng "§2b cross-document" riêng. Mâu thuẫn cấp tài liệu (Module 0 / techspec / ux / prd lệch nhau, hoặc 1 file tự mâu thuẫn) → đưa thành GAP trong 3 bảng theo mức (nếu ảnh hưởng testcase) HOẶC gộp vào mục "Vệ sinh tài liệu" ở GHI CHÚ (nếu chỉ là drift version/số dòng, không chặn test). Luôn trích tên file đầy đủ + §/dòng.
+3. Cột "Vấn đề" = 1 tiêu đề đậm + các dòng có NHÃN CỐ ĐỊNH, MỖI nguồn 1 dòng, **trích dẫn clickable ĐẶT Ở ĐẦU DÒNG** dạng `**[tên file đầy đủ §mục · dòng N](link#LN):** nội dung`, kết thúc bằng dòng `**⇒ Hậu quả:** …`. TUYỆT ĐỐI KHÔNG viết tắt tên file (không `DD`/`L2`/`M0`), KHÔNG telegraphic, KHÔNG để trích dẫn trôi về cuối câu.
+4. Link trích dẫn: đường dẫn tương đối từ root workspace + anchor `#L{N}` (VSCode/GitHub nhảy thẳng tới dòng). Range dòng → dùng dòng đầu cho anchor, ghi "dòng X–Y" ở nhãn.
+5. Cột "Trạng thái" = cột 2 (ngay sau Mã), 3 checkbox stack mặc định "☑ Todo / ☐ Resolved / ☐ Pending" (dùng &nbsp; giữa ô và nhãn + <br> xuống dòng). PO đổi sang Resolved khi có Trả lời, hoặc Pending nếu cần làm rõ thêm.
+6. Đánh số GAP liên tục xuyên suốt 3 bảng (GAP-01, 02, … không reset theo mức).
+7. Gate: đánh dấu 🔴 cho mọi điểm chặn viết testcase; các điểm này phải = Resolved trước khi sang Mode 2 GENERATE.
+-->

package/skills/NTAPP/.agent/skills/NTAPP-qa-audit/workflow.md

@@ -0,0 +1,85 @@
+# WORKFLOW: NTAPP QA — AMBIGUITY & QUALITY AUDIT (SHIFT-LEFT)
+
+**Goal:** Rà soát chéo đa tầng Specs L2 + file thiết kế chi tiết `_detailed_design` (bỏ phần Đảm bảo chất lượng / Kiểm thử) của một đơn vị `{id}` để phát hiện sớm các điểm nhập nhằng (ambiguity), Logic / Parameter / Integration Gaps và UI-Logic inconsistency — TRƯỚC khi viết bất kỳ testcase nào — rồi kết tinh thành Checklist Q&A có sẵn phương án gợi ý cho PO/Lead làm rõ.
+
+**Your Role:** Bạn đóng vai **Senior QA Engineer** ([agents/agent_qa_auditor.md](./agents/agent_qa_auditor.md)) — Shift-Left auditor, quét chéo specs, lập Gap Analysis và soạn câu hỏi Q&A. Bạn là điểm chạm duy nhất với người dùng.
+
+**Compliance:** Workflow này tuân thủ các reference trong [`./references/`](./references/): [ntapp-core-compliance.md](./references/ntapp-core-compliance.md) (Iron Rules — Zero-Fabrication, Zero-Summarization, Traceability) và [no-hallucination-rule.md](./references/no-hallucination-rule.md). Tuyệt đối KHÔNG bịa giải pháp cho gap phát hiện được — mọi điểm thiếu định dạng thành câu hỏi `[TBD]`. Input thiếu/không đọc được → DỪNG, hỏi user; KHÔNG sinh mock.
+
+---
+
+## ROSTER & ROLES
+
+| Step | Agent | Vai trò | Output |
+|---|---|---|---|
+| 01 | QA Auditor (Senior QA Engineer) | Ambiguity & Gap Analysis + Q&A handshake | `{qa_artifacts}/{id}/{id}_qa_report.md` |
+
+Skill 1-agent: toàn bộ luồng do QA Auditor thực thi tuần tự.
+
+## KIẾN TRÚC WORKFLOW (MICRO-FILE ARCHITECTURE)
+
+Mỗi step là một file độc lập trong `./steps/` với contract I/O rõ ràng. Step mở đầu bằng `> Acting as:` trỏ persona trong `./agents/`.
+
+```
+┌─────────────────────────────────────────────────────────┐
+│  STEP 01: AMBIGUITY & QUALITY AUDIT                     │
+│  (Senior QA Engineer — Shift-Left)                      │
+│  → Đọc Specs L2 + DD (bỏ phần QA/Kiểm thử), quét Gaps,  │
+│    lập Gap Analysis + Checklist Q&A                      │
+│  → Output: {qa_artifacts}/{id}/{id}_qa_report.md        │
+│  → GATE: DỪNG, chờ user trả lời Q&A trong file báo cáo  │
+└─────────────────────────────────────────────────────────┘
+```
+
+## INITIALIZATION (Configuration Resolution)
+
+Trước khi chạy bất kỳ step nào, resolve config theo cascade 3 layer (cao → thấp).
+
+### Bước 0 — Resolve `{project-root}`
+Walk up từ `cwd` tìm marker: thấy `_bmad/` → project-root; else thấy `.git/` → project-root; else fallback `cwd` + log warning.
+
+### Layer 1 — BMad project config
+Đọc `{project-root}/_bmad/bmm/config.yaml` nếu có. Lookup: `project_name`, `stage_5_build_verify`, `stage_4_design`. Thay placeholder `{project-root}` bằng absolute path đã resolve.
+
+### Layer 2 — Skill family config (override)
+Đọc `{project-root}/.bmm-config.yaml`, tìm section `ntapp-qa-audit:`. Override Layer 1 nếu có.
+```yaml
+ntapp-qa-audit:
+  qa_artifacts: <path>            # optional, override default
+  detailed_design_root: <path>    # optional, nơi tìm {id}_detailed_design.md
+```
+
+### Layer 3 — Default + Interactive (fallback)
+Nếu `qa_artifacts` chưa resolve được: default = `{stage_5_build_verify}/test`
+(tức `{project-root}/NTAPP-output/Stage_5_Build_Verify/test`). Nếu cả `stage_5_build_verify` cũng miss → DỪNG, hỏi user path, rồi ghi vào `.bmm-config.yaml` section `ntapp-qa-audit:`.
+
+Nếu `detailed_design_root` chưa resolve được: default = `{stage_4_design}/detailed_design`. Nếu cả `stage_4_design` cũng miss → DỪNG, hỏi user nơi chứa các file `{id}_detailed_design.md`.
+
+### Biến runtime
+| Biến | Nguồn | Ghi chú |
+|---|---|---|
+| `project_name` | Layer 1/2/3 | Header tài liệu |
+| `qa_artifacts` | Layer 1/2/3 | Root output QA (= `{stage_5_build_verify}/test`) |
+| `detailed_design_root` | Layer 1/2/3 | Nơi tìm `{id}_detailed_design.md` (default `{stage_4_design}/detailed_design`) |
+| `id` | User input | Đơn vị cần xử lý (SLICE / HUB / WGT / SCR / MPF…) |
+| `template_path` | Hardcode | `./templates/...` — relative to **skill root** |
+| `agent_personas_path` | Hardcode | `./agents/` — relative skill root |
+| `date` | System | ISO 8601 |
+
+---
+
+## Output Naming
+
+| Output | Path | Versioning |
+|---|---|---|
+| Q&A Report — canonical | `{qa_artifacts}/{id}/{id}_qa_report.md` | 1 **thư mục con riêng theo chức năng** `{id}` (vd `test/HUB-01/`, `test/SLICE-03/`), KHÔNG gom chung vào `reviews/`; overwrite mỗi run (latest pointer) — KHÔNG archive, KHÔNG `_v{N}` |
+
+---
+
+## EXECUTION
+
+Thực hiện tuần tự theo file hướng dẫn trong `./steps/`:
+
+1. **[Step 01: Ambiguity & Quality Audit](./steps/step-01-ambiguity-audit.md)** → `{qa_artifacts}/{id}/{id}_qa_report.md`.
+
+> **GATE (bắt buộc):** Sau khi xuất báo cáo, DỪNG lại và yêu cầu người dùng/PO điền phản hồi trực tiếp vào cột Q&A trong file báo cáo. KHÔNG tự đi tiếp — đây là tiền đề để chuyển sang giai đoạn thiết kế testcase.

package/skills/NTAPP/.agent/skills/NTAPP-qa-gap-resolver/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: ntapp-qa-gap-resolver
+description: 'Đọc báo cáo rà soát tính nhất quán tài liệu (dạng {id}_qa_report.md / ambiguity-audit — bảng GAP theo mức 🔴/🟡/⚪), phân tích lần lượt từng gap: map ra tính năng ảnh hưởng, đối chiếu 4 nguồn (dữ liệu thực tế nếu report cite → TechSpec/Contract SSoT → DD → code thực tế để đo độ lệch), phân loại gap (stale-docs / code-mới-docs-cũ / lệch-code-vs-contract / mơ-hồ-nghiệp-vụ) và đề xuất phương án xử lý theo thứ tự ưu tiên. Phase 1 ANALYZE điền [AI đề xuất] vào cột Trả lời của report gốc + append section phân tích → GATE chờ user chọn gap. Phase 2 EXECUTE các gap đã chọn (song song theo file đích): docs sửa trực tiếp, code chỉ sinh diff đề xuất, gap nghiệp vụ chờ PO. Dùng khi người dùng nói "phân tích qa report", "xử lý gap", "giải quyết điểm không nhất quán", "resolve ambiguity report".'
+---
+
+# NTAPP QA — Gap Resolver
+
+Đọc báo cáo rà soát tính nhất quán (`{id}_qa_report.md`), phân tích từng gap dựa trên 4 nguồn theo thứ tự ưu tiên đã chốt, đề xuất phương án cho người dùng chốt, rồi thực thi các gap được chọn.
+
+**Skill KHÔNG tự quyết** — mọi gap đưa người dùng/PO chốt. Skill chỉ *phân tích + đề xuất* (Phase 1), và chỉ *thực thi* gap đã được chọn (Phase 2).
+
+Đọc đầy đủ và tuân theo: `./workflow.md`

package/skills/NTAPP/.agent/skills/NTAPP-qa-gap-resolver/references/no-hallucination-rule.md

@@ -0,0 +1,23 @@
+# No Hallucination Rule (Gap Resolver)
+
+## Mục đích
+Chặn agent tự suy diễn giá trị canonical, hành vi, field, message lỗi, API hoặc business rule khi phân tích/đề xuất phương án cho một gap. Skill này quyết định "giá trị nào nên chốt" — nên rủi ro bịa còn cao hơn lúc audit.
+
+## Nguyên tắc bắt buộc
+Mọi đề xuất phương án cho một gap **phải trích dẫn bằng chứng** từ một trong các nguồn sau (ghi rõ file + §/dòng):
+
+1. Dữ liệu thực tế được **report cite** (staging sample trong `f2`, giá trị thật). KHÔNG tự query DB nếu report không có.
+2. TechSpec / Contract canonical (`{module}_techspec.md`, Module 0) — SSoT.
+3. DD parts (`f0`–`f3`) của unit liên quan.
+4. Code thực tế trong repo code (đã đọc + trích path:line + git blame).
+5. Quyết định PO/Lead đã ghi trong report (cột Trả lời).
+
+## Khi thiếu bằng chứng
+Nếu KHÔNG có nguồn nào đủ để chốt giá trị/hành vi đúng → **KHÔNG tự đoán**. Phân loại gap = `mơ-hồ-nghiệp-vụ`, đề xuất ghi rõ `[Cần PO chốt]` + nêu các phương án và trade-off, KHÔNG chọn thay PO.
+
+## Điều kiện reject (một đề xuất bị loại nếu)
+- Chốt một giá trị/enum/regex mà không trích được nguồn.
+- "Hợp thức hoá" hiện trạng: chốt theo code chỉ vì code đang làm vậy, dù code lệch contract (xem [priority-resolution-rule.md](./priority-resolution-rule.md)).
+- Bịa message lỗi / mã lỗi / field / status không có trong nguồn.
+- Suy ra "chiều lệch" (docs cũ hay code cũ) mà không dựa trên dấu vết thời gian (git log/blame, ngày CR, ngày DD).
+- Đọc trực tiếp `.env` hoặc làm lộ credentials.