@edupia-tutor/spec-driven-docs 0.14.6 → 0.14.7

package/commands/review-context.md

@@ -641,7 +641,9 @@ Convergence: {convergence_rounds} vòng critic — file findings đã đầy đ
    - **Tồn tại** + có `--full` → **FULL**: bỏ qua findings cũ.
    - **Tồn tại** + KHÔNG `--full` → so `source_version` trong findings cũ với version target hiện tại (PRD: Metadata `Version`; BDD: `@trace.bdd_version`):
      - **Bằng nhau** (target chưa đổi từ lần review trước) → DỪNG, báo: `"Target chưa đổi từ v{X} (lần review gần nhất). Không có gì để review lại — dùng --full nếu vẫn muốn quét toàn bộ."`
-     - **Khác** → **DELTA**: `CHANGED_SCOPE` = { `uc_id`/`section` của finding đã xử lý (status `accepted`/`modified`/`applied_automatically`) trong findings cũ } ∪ { UC có trong target hiện tại nhưng chưa từng xuất hiện ở findings cũ }.
+     - **Khác** → kiểm tra `applied_to_version` trong findings cũ (version mà lần `--fix`/`--resume` gần nhất của CHÍNH lệnh này đã bump target tới) để biết ai gây ra thay đổi:
+       - **`applied_to_version` có mặt VÀ `==` version target hiện tại** → target đổi đúng bằng phần lệnh này tự áp, không actor khác động vào → **DELTA**: `CHANGED_SCOPE` = { `uc_id`/`section` của finding đã xử lý (status `accepted`/`modified`/`applied`) trong findings cũ } ∪ { UC có trong target hiện tại nhưng chưa từng xuất hiện ở findings cũ }.
+       - **`applied_to_version` vắng mặt HOẶC `≠` version hiện tại** → target đã bị sửa bởi **actor khác** (lệnh `/refine-prd`, `/generate-bdd` regen, sửa tay…) sau lần áp này → KHÔNG tin được phạm vi hẹp → **FULL** (KHÔNG truyền `CHANGED_SCOPE`), kèm cảnh báo: `"Target đổi ngoài tầm theo dõi của findings (applied_to_version={A} ≠ hiện tại={C}); quét lại toàn bộ để khỏi sót UC do người/lệnh khác sửa."`
 
 ---
 
@@ -653,7 +655,7 @@ Convergence: {convergence_rounds} vòng critic — file findings đã đầy đ
 
 Khi `setup.mode = umbrella`, PRD phải có metadata routing đúng để context-loader Bước 1.5 có thể đưa output sinh ra tới đúng service submodule. Chạy các check này **trước P1–P5**:
 
-> **Nguồn đọc:** PRD mang Domain/Status ở **bảng Metadata** (`| **Domain** | … |`, `| **Status** | … |`) — **KHÔNG** phải frontmatter `@trace.*` (cái đó dành cho file `.feature`/tech-docs do máy đọc). Routing umbrella dựa trên Domain (bảng) + path, đúng như context-loader Bước 1.5 và `generate-bdd` (đọc `| **Status** |`).
+> **Nguồn đọc:** PRD mang **Domain** ở **bảng Metadata** (`| **Domain** | … |`) — **KHÔNG** phải frontmatter `@trace.*` (cái đó dành cho file `.feature`/tech-docs do máy đọc). Routing umbrella dựa trên Domain (bảng) + path, đúng như context-loader Bước 1.5.
 
 **P0.1 — Row `Domain` có mặt trong Metadata**
 - Đọc bảng Metadata của PRD, lấy row `| **Domain** |`.
@@ -673,11 +675,7 @@ Khi `setup.mode = umbrella`, PRD phải có metadata routing đúng để contex
   - `suggestion`: "Cập nhật section services trong `.agent/project-context.yaml` với mapping domain-to-submodule trước khi sinh BDD."
   - `auto_fixable: false`
 
-**P0.3 — Check row `Status` trong Metadata**
-- Nếu row `| **Status** |` **vắng mặt** → **minor**, `auto_fixable: true` (thêm `| **Status** | draft |`)
-- Nếu `Status: draft` → **major**, `auto_fixable: false`:
-  - `finding`: "PRD status là `draft`. Team dev không nên sinh BDD từ một PRD chưa được duyệt."
-  - `suggestion`: "PO/SA nên review và cập nhật Status thành `approved` trước khi team dev tiếp tục."
+> **Status KHÔNG còn là check của P0.** PRD chưa duyệt (`Status: draft`) là trạng thái **bình thường** lúc review — việc duyệt diễn ra *sau khi* review-context sạch, nên báo draft là "lỗi" ở đây chỉ gây nhiễu. Gác duyệt do `/generate-bdd` lo (cảnh báo mềm, áp **mọi mode**); lời nhắc đặt `approved` nằm ở Report (mọi mode). P4 chỉ lo trường hợp row Status **vắng mặt** (auto-fix mặc định `draft`).
 
 > **P0 là một gate check:** Nếu P0.1 hoặc P0.2 cho finding critical, hiển thị cảnh báo trước khi tiếp tục:
 > ```
@@ -741,7 +739,7 @@ hoặc định nghĩa lại field/status transition của một entity khác đi
 - [ ] Có section `# Change Log`
 - [ ] Không còn giá trị `{{PLACEHOLDER}}` chưa điền
 
-→ Section/field thiếu hoặc lệch cấu trúc: **major**. AI có thể thêm skeleton khi `--resume` nếu được chấp nhận. Riêng **"Nhất quán 2 chiều"** lệch → **major**, `auto_fixable: false` (người xác nhận AC↔UC, AI không tự đoán). **API Source: existing thiếu contract** → **major**, `auto_fixable: false` (cần nguồn contract); **greenfield còn sót section "Existing API Contract" rỗng** → **minor**, `auto_fixable: true` (xoá section).
+→ Section/field thiếu hoặc lệch cấu trúc: **major**. AI có thể thêm skeleton khi `--resume` nếu được chấp nhận. Riêng **"Nhất quán 2 chiều"** lệch → **major**, `auto_fixable: false` (người xác nhận AC↔UC, AI không tự đoán). **API Source: existing thiếu contract** → **major**, `auto_fixable: false` (cần nguồn contract); **greenfield còn sót section "Existing API Contract" rỗng** → **minor**, `auto_fixable: true` (xoá section). Riêng **row `Status` vắng mặt** → **minor**, `auto_fixable: true` (thêm `| **Status** | draft |`) — KHÔNG flag *giá trị* draft (đó là trạng thái bình thường lúc review; gác duyệt do `/generate-bdd` lo).
 
 ### P5 — Custom Criteria (tuỳ chọn)
 
@@ -826,6 +824,7 @@ Sau khi chạy hết các check, ghi `{paths.refinement_dir}/{slug}-review-*-fin
 ```yaml
 source_file: "{absolute path to reviewed file}"
 source_version: "{version target lúc sinh findings — PRD: Metadata Version; BDD: @trace.bdd_version — dùng chọn full/delta lần chạy sau}"
+applied_to_version: ""   # để trống lúc phân tích; --fix/--resume sẽ ghi version target vừa bump tới. Lần delta sau: nếu version target hiện tại ≠ giá trị này → target bị actor khác sửa → fallback FULL (xem "Chọn full vs delta")
 generated_at: "{ISO datetime}"
 review_type: "{prd | bdd}"
 status: "pending_review"
@@ -840,7 +839,8 @@ findings:
     finding: "{mô tả rõ ràng vấn đề}"
     suggestion: "{bản fix cụ thể, hành động được — AI sẽ áp dụng khi --resume nếu được chấp nhận}"
     auto_fixable: true       # true = AI áp dụng được; false = người phải viết note trong Review Board
-    status: "pending"        # pending | accepted | modified | rejected | deferred
+    status: "pending"        # pending | accepted | modified | rejected | needs_discussion | deferred | applied (vòng đời chung — xem chú thích dưới)
+    applied_via: ""          # set khi status='applied': "fix" (auto qua --fix) | "resume" (người duyệt qua --resume)
 
 summary:
   total_findings: {N}
@@ -850,6 +850,15 @@ summary:
   recommendation: "APPROVED | NEEDS_REVISION | BLOCKED"
 ```
 
+> **Vòng đời finding-level (CHUNG với `/refine-prd` — một Review Board đọc cả hai loại file nên enum phải khớp):**
+> - `pending` → mới, chưa review
+> - `accepted` → nhận suggestion gốc → `--resume` sẽ áp
+> - `modified` → người đã sửa suggestion trong Review Board → `--resume` dùng bản đã sửa
+> - `rejected` → bác bỏ, không áp
+> - `needs_discussion` → xung đột/chưa ngã ngũ → **chặn** `--resume` (bỏ qua + cảnh báo) tới khi người quyết
+> - `deferred` → cố ý hoãn (không chặn), bỏ qua lượt này, xem lại sau
+> - `applied` → đã áp vào target; `applied_via` ghi cách áp: `"fix"` (auto qua `--fix`) hoặc `"resume"` (người duyệt qua `--resume`)
+
 > **Field định vị (`quote` + `uc_id`) — bắt buộc cho source-jump của Review Board.**
 > Với mỗi finding, copy một đoạn `quote` **nguyên văn** thẳng từ file đang review tại đúng
 > chỗ lỗi xảy ra — KHÔNG diễn giải lại; nó được so khớp với tài liệu để định vị dòng.
@@ -928,7 +937,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |
@@ -983,6 +992,10 @@ Lựa chọn tiếp theo:
                   → áp dụng ngay mọi finding auto-fixable
   B) Review Board: mở file findings → accept/modify/reject
                   → /review-context --resume {target-file}
+
+  {CHỈ in khối này khi 0 finding critical còn lại — còn critical thì nhắc duyệt là vô nghĩa}:
+  ✅ PRD đã sạch critical. Khi PO hài lòng → đặt `| **Status** | approved |` trong
+     Metadata PRD (dấu duyệt nghiệp vụ, do người quyết) → rồi /generate-bdd.
 ```
 
 ---
@@ -1012,10 +1025,9 @@ Với mỗi finding có `auto_fixable: true`, theo thứ tự (critical → majo
 
 | check_id | Áp dụng gì |
 |----------|--------------|
-| P0.3 (Thiếu status) | Thêm row `| **Status** | draft |` vào bảng Metadata |
 | P1 (Banned term) | Thay mọi lần xuất hiện banned term bằng canonical term |
 | P1 (Thuật ngữ kỹ thuật/UI) | Diễn đạt lại theo Business Language Guard (Nhóm 1) / chuyển Design Spec (2) / bỏ về Tech Docs (3) |
-| P4 (Structure) | Thêm skeleton section/metadata còn thiếu; greenfield → xoá section "Existing API Contract" rỗng |
+| P4 (Structure) | Thêm skeleton section/metadata còn thiếu (row Status vắng → thêm mặc định `draft`); greenfield → xoá section "Existing API Contract" rỗng |
 
 > **Chạy Business Language Guard trên text vừa sửa TRƯỚC khi ghi** (xem section "Ngôn ngữ nghiệp vụ") — không để bản auto-fix tự kéo thuật ngữ kỹ thuật vào.
 
@@ -1033,13 +1045,14 @@ Với mỗi finding có `auto_fixable: true`, theo thứ tự (critical → majo
 | B5 | Thêm @trace header còn thiếu, sinh lại Coverage Matrix / Pre-merge Checklist |
 | B6 | Thêm `And <side-effect>` còn thiếu vào block Then |
 
-Sau khi áp dụng mỗi finding, đánh dấu nó `status: "applied_automatically"` trong file findings.
+Sau khi áp dụng mỗi finding, đánh dấu nó `status: "applied"` + `applied_via: "fix"` trong file findings.
 
 ### Phase 3 — Version bump
 
-- **PRD**: nếu ≥1 finding được áp dụng → bump version **minor** (auto-fix chỉ áp dụng thay banned-term P1 và thêm skeleton P4 — không bao giờ thay đổi cấu trúc UC hay nội dung BR, nên minor bump luôn đúng), thêm entry Changelog:
+- **PRD**: nếu ≥1 finding được áp dụng → bump version **minor** (auto-fix chỉ áp dụng thay banned-term P1 và thêm skeleton P4 — không bao giờ thay đổi cấu trúc UC hay nội dung BR, nên minor bump luôn đúng), **reset `| **Status** | draft |` trong Metadata** (PRD vừa đổi sau khi duyệt → con dấu duyệt cũ hết hiệu lực, phải duyệt lại — đồng bộ với /refine-prd), thêm entry Changelog:
   `Auto-fix: applied {N} auto-fixable review-context findings`
 - **BDD**: nếu ≥1 finding được áp dụng → tăng `@trace.bdd_version` lên 0.1
+- **Cả hai**: ghi `applied_to_version: "{version vừa bump tới}"` ở root level của findings — đóng dấu "target đổi tới version này là do lệnh này áp", để lần review delta sau phân biệt thay đổi của chính mình với thay đổi do actor khác (xem "Chọn full vs delta").
 
 ### Phase 4 — Report
 
@@ -1054,13 +1067,14 @@ Auto-fixed : {N} findings ({critical} critical, {major} major, {minor} minor)
 Còn pending (cần quyết định của con người): {N}
   - F00X [{severity}] {tóm tắt finding}  ← mở file findings trong Review Board
 
-{If PRD}: Version bumped: {old} → {new}
+{If PRD}: Version bumped: {old} → {new}  |  Status: reset về draft (cần duyệt lại)
 {If BDD}: bdd_version: {old} → {new}
 
 File findings:
   {If PRD}: {paths.refinement_dir}/{prd-slug}-review-context-findings.yaml
   {If BDD}: {paths.refinement_dir}/{uc-id}-review-bdd-findings.yaml
 Chạy lại /review-context {file} để xác nhận 0 finding critical còn lại.
+Khi sạch critical + PO duyệt → đặt | **Status** | approved | trong Metadata rồi /generate-bdd.
 ```
 
 Nếu 0 finding nào auto-fixable → in:
@@ -1082,26 +1096,28 @@ Mở file findings trong Review Board → rồi chạy: /review-context --resume
    - PRD: `{paths.refinement_dir}/{prd-slug}-review-context-findings.yaml`
    - BDD: `{paths.refinement_dir}/{uc-id}-review-bdd-findings.yaml`
 2. Đọc file findings.
-3. Gom các finding có `status: "accepted"` hoặc `status: "modified"`.
+3. Gom các finding có `status: "accepted"` hoặc `status: "modified"`. Bỏ qua `rejected`/`deferred`.
 4. Nếu không có → báo "No accepted findings. File unchanged." và dừng.
+5. Nếu còn finding `status: "needs_discussion"` → cảnh báo (không dừng): `"⚠️  {N} finding chưa ngã ngũ (needs_discussion) — bỏ qua lần áp này; giải quyết trong Review Board rồi --resume lại."`
 
 ### Phase 2 — Áp dụng fix
 
 Áp dụng theo thứ tự: critical → major → minor.
 
+Với mỗi finding `accepted`/`modified` sau khi áp xong → đặt `status: "applied"` + `applied_via: "resume"` trong findings (hoàn tất vòng đời, cùng quy ước với `--fix` và `/refine-prd`).
+
 > **Chạy Business Language Guard trên text vừa sửa TRƯỚC khi ghi** (xem section "Ngôn ngữ nghiệp vụ") — đặc biệt với P2 (sửa câu mơ hồ) / P4 skeleton: không để bản fix tự kéo thuật ngữ kỹ thuật-UI vào PRD.
 
 **Với finding PRD:**
 | check_id | Làm gì |
 |----------|-----------|
-| P0.3 (Thiếu status) | Thêm row `| **Status** | draft |` vào bảng Metadata |
 | P1 (Banned term) | Thay banned term bằng canonical; thuật ngữ kỹ thuật/UI → diễn đạt lại theo Business Language Guard |
 | P2 (Ambiguity) | Áp dụng fix nêu trong `suggestion` hoặc note `modified` |
 | P3 (Conflict) | Áp dụng cách giải quyết nêu trong note modified |
-| P4 (Structure) | Thêm section/metadata field còn thiếu |
+| P4 (Structure) | Thêm section/metadata field còn thiếu (row Status vắng → thêm mặc định `draft`) |
 | P5 (Custom) | Áp dụng như nêu trong suggestion/note |
 
-→ Sau khi áp dụng, bump version PRD (minor) và thêm entry Changelog.
+→ Sau khi áp dụng, bump version PRD (minor), **reset `| **Status** | draft |` trong Metadata** (PRD vừa đổi sau khi duyệt → phải duyệt lại — đồng bộ với /refine-prd), thêm entry Changelog, và ghi `applied_to_version: "{new_version}"` ở root level của findings (xem "Chọn full vs delta").
 
 **Với finding BDD:**
 | check_id | Làm gì |
@@ -1115,20 +1131,22 @@ Mở file findings trong Review Board → rồi chạy: /review-context --resume
 
 → Sau khi áp dụng, tăng `@trace.bdd_version` trong header file lên 0.1.
 → Đồng thời cập nhật `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv`: đặt cột `bdd_version` thành giá trị `@trace.bdd_version` mới cho mọi row, và đặt `last_updated` thành ngày hôm nay.
+→ Ghi `applied_to_version: "{@trace.bdd_version mới}"` ở root level của findings (xem "Chọn full vs delta").
 
 ### Phase 3 — Report
 
 ```
 /review-context --resume Đã áp dụng — {target file}
 Applied  : {N} findings ({critical} critical, {major} major, {minor} minor)
-Skipped  : {N} rejected/deferred
+Skipped  : {N} rejected/deferred/needs_discussion
 
 Changes:
   - {tóm tắt change 1}
   - {tóm tắt change 2}
 
-{If PRD}: Version bumped: {old} → {new}
+{If PRD}: Version bumped: {old} → {new}  |  Status: reset về draft (cần duyệt lại)
 {If BDD}: bdd_version: {old} → {new}
 
 Chạy lại /review-context {file} để xác nhận 0 finding critical còn lại.
+Khi sạch critical + PO duyệt → đặt | **Status** | approved | trong Metadata rồi /generate-bdd.
 ```

package/commands/review-context.tmpl

@@ -58,7 +58,9 @@ Suy ra tên file findings output:
    - **Tồn tại** + có `--full` → **FULL**: bỏ qua findings cũ.
    - **Tồn tại** + KHÔNG `--full` → so `source_version` trong findings cũ với version target hiện tại (PRD: Metadata `Version`; BDD: `@trace.bdd_version`):
      - **Bằng nhau** (target chưa đổi từ lần review trước) → DỪNG, báo: `"Target chưa đổi từ v{X} (lần review gần nhất). Không có gì để review lại — dùng --full nếu vẫn muốn quét toàn bộ."`
-     - **Khác** → **DELTA**: `CHANGED_SCOPE` = { `uc_id`/`section` của finding đã xử lý (status `accepted`/`modified`/`applied_automatically`) trong findings cũ } ∪ { UC có trong target hiện tại nhưng chưa từng xuất hiện ở findings cũ }.
+     - **Khác** → kiểm tra `applied_to_version` trong findings cũ (version mà lần `--fix`/`--resume` gần nhất của CHÍNH lệnh này đã bump target tới) để biết ai gây ra thay đổi:
+       - **`applied_to_version` có mặt VÀ `==` version target hiện tại** → target đổi đúng bằng phần lệnh này tự áp, không actor khác động vào → **DELTA**: `CHANGED_SCOPE` = { `uc_id`/`section` của finding đã xử lý (status `accepted`/`modified`/`applied`) trong findings cũ } ∪ { UC có trong target hiện tại nhưng chưa từng xuất hiện ở findings cũ }.
+       - **`applied_to_version` vắng mặt HOẶC `≠` version hiện tại** → target đã bị sửa bởi **actor khác** (lệnh `/refine-prd`, `/generate-bdd` regen, sửa tay…) sau lần áp này → KHÔNG tin được phạm vi hẹp → **FULL** (KHÔNG truyền `CHANGED_SCOPE`), kèm cảnh báo: `"Target đổi ngoài tầm theo dõi của findings (applied_to_version={A} ≠ hiện tại={C}); quét lại toàn bộ để khỏi sót UC do người/lệnh khác sửa."`
 
 ---
 
@@ -70,7 +72,7 @@ Suy ra tên file findings output:
 
 Khi `setup.mode = umbrella`, PRD phải có metadata routing đúng để context-loader Bước 1.5 có thể đưa output sinh ra tới đúng service submodule. Chạy các check này **trước P1–P5**:
 
-> **Nguồn đọc:** PRD mang Domain/Status ở **bảng Metadata** (`| **Domain** | … |`, `| **Status** | … |`) — **KHÔNG** phải frontmatter `@trace.*` (cái đó dành cho file `.feature`/tech-docs do máy đọc). Routing umbrella dựa trên Domain (bảng) + path, đúng như context-loader Bước 1.5 và `generate-bdd` (đọc `| **Status** |`).
+> **Nguồn đọc:** PRD mang **Domain** ở **bảng Metadata** (`| **Domain** | … |`) — **KHÔNG** phải frontmatter `@trace.*` (cái đó dành cho file `.feature`/tech-docs do máy đọc). Routing umbrella dựa trên Domain (bảng) + path, đúng như context-loader Bước 1.5.
 
 **P0.1 — Row `Domain` có mặt trong Metadata**
 - Đọc bảng Metadata của PRD, lấy row `| **Domain** |`.
@@ -90,11 +92,7 @@ Khi `setup.mode = umbrella`, PRD phải có metadata routing đúng để contex
   - `suggestion`: "Cập nhật section services trong `.agent/project-context.yaml` với mapping domain-to-submodule trước khi sinh BDD."
   - `auto_fixable: false`
 
-**P0.3 — Check row `Status` trong Metadata**
-- Nếu row `| **Status** |` **vắng mặt** → **minor**, `auto_fixable: true` (thêm `| **Status** | draft |`)
-- Nếu `Status: draft` → **major**, `auto_fixable: false`:
-  - `finding`: "PRD status là `draft`. Team dev không nên sinh BDD từ một PRD chưa được duyệt."
-  - `suggestion`: "PO/SA nên review và cập nhật Status thành `approved` trước khi team dev tiếp tục."
+> **Status KHÔNG còn là check của P0.** PRD chưa duyệt (`Status: draft`) là trạng thái **bình thường** lúc review — việc duyệt diễn ra *sau khi* review-context sạch, nên báo draft là "lỗi" ở đây chỉ gây nhiễu. Gác duyệt do `/generate-bdd` lo (cảnh báo mềm, áp **mọi mode**); lời nhắc đặt `approved` nằm ở Report (mọi mode). P4 chỉ lo trường hợp row Status **vắng mặt** (auto-fix mặc định `draft`).
 
 > **P0 là một gate check:** Nếu P0.1 hoặc P0.2 cho finding critical, hiển thị cảnh báo trước khi tiếp tục:
 > ```
@@ -158,7 +156,7 @@ hoặc định nghĩa lại field/status transition của một entity khác đi
 - [ ] Có section `# Change Log`
 - [ ] Không còn giá trị `{{PLACEHOLDER}}` chưa điền
 
-→ Section/field thiếu hoặc lệch cấu trúc: **major**. AI có thể thêm skeleton khi `--resume` nếu được chấp nhận. Riêng **"Nhất quán 2 chiều"** lệch → **major**, `auto_fixable: false` (người xác nhận AC↔UC, AI không tự đoán). **API Source: existing thiếu contract** → **major**, `auto_fixable: false` (cần nguồn contract); **greenfield còn sót section "Existing API Contract" rỗng** → **minor**, `auto_fixable: true` (xoá section).
+→ Section/field thiếu hoặc lệch cấu trúc: **major**. AI có thể thêm skeleton khi `--resume` nếu được chấp nhận. Riêng **"Nhất quán 2 chiều"** lệch → **major**, `auto_fixable: false` (người xác nhận AC↔UC, AI không tự đoán). **API Source: existing thiếu contract** → **major**, `auto_fixable: false` (cần nguồn contract); **greenfield còn sót section "Existing API Contract" rỗng** → **minor**, `auto_fixable: true` (xoá section). Riêng **row `Status` vắng mặt** → **minor**, `auto_fixable: true` (thêm `| **Status** | draft |`) — KHÔNG flag *giá trị* draft (đó là trạng thái bình thường lúc review; gác duyệt do `/generate-bdd` lo).
 
 ### P5 — Custom Criteria (tuỳ chọn)
 
@@ -243,6 +241,7 @@ Sau khi chạy hết các check, ghi `{paths.refinement_dir}/{slug}-review-*-fin
 ```yaml
 source_file: "{absolute path to reviewed file}"
 source_version: "{version target lúc sinh findings — PRD: Metadata Version; BDD: @trace.bdd_version — dùng chọn full/delta lần chạy sau}"
+applied_to_version: ""   # để trống lúc phân tích; --fix/--resume sẽ ghi version target vừa bump tới. Lần delta sau: nếu version target hiện tại ≠ giá trị này → target bị actor khác sửa → fallback FULL (xem "Chọn full vs delta")
 generated_at: "{ISO datetime}"
 review_type: "{prd | bdd}"
 status: "pending_review"
@@ -257,7 +256,8 @@ findings:
     finding: "{mô tả rõ ràng vấn đề}"
     suggestion: "{bản fix cụ thể, hành động được — AI sẽ áp dụng khi --resume nếu được chấp nhận}"
     auto_fixable: true       # true = AI áp dụng được; false = người phải viết note trong Review Board
-    status: "pending"        # pending | accepted | modified | rejected | deferred
+    status: "pending"        # pending | accepted | modified | rejected | needs_discussion | deferred | applied (vòng đời chung — xem chú thích dưới)
+    applied_via: ""          # set khi status='applied': "fix" (auto qua --fix) | "resume" (người duyệt qua --resume)
 
 summary:
   total_findings: {N}
@@ -267,6 +267,15 @@ summary:
   recommendation: "APPROVED | NEEDS_REVISION | BLOCKED"
 ```
 
+> **Vòng đời finding-level (CHUNG với `/refine-prd` — một Review Board đọc cả hai loại file nên enum phải khớp):**
+> - `pending` → mới, chưa review
+> - `accepted` → nhận suggestion gốc → `--resume` sẽ áp
+> - `modified` → người đã sửa suggestion trong Review Board → `--resume` dùng bản đã sửa
+> - `rejected` → bác bỏ, không áp
+> - `needs_discussion` → xung đột/chưa ngã ngũ → **chặn** `--resume` (bỏ qua + cảnh báo) tới khi người quyết
+> - `deferred` → cố ý hoãn (không chặn), bỏ qua lượt này, xem lại sau
+> - `applied` → đã áp vào target; `applied_via` ghi cách áp: `"fix"` (auto qua `--fix`) hoặc `"resume"` (người duyệt qua `--resume`)
+
 > **Field định vị (`quote` + `uc_id`) — bắt buộc cho source-jump của Review Board.**
 > Với mỗi finding, copy một đoạn `quote` **nguyên văn** thẳng từ file đang review tại đúng
 > chỗ lỗi xảy ra — KHÔNG diễn giải lại; nó được so khớp với tài liệu để định vị dòng.
@@ -300,6 +309,10 @@ Lựa chọn tiếp theo:
                   → áp dụng ngay mọi finding auto-fixable
   B) Review Board: mở file findings → accept/modify/reject
                   → /review-context --resume {target-file}
+
+  {CHỈ in khối này khi 0 finding critical còn lại — còn critical thì nhắc duyệt là vô nghĩa}:
+  ✅ PRD đã sạch critical. Khi PO hài lòng → đặt `| **Status** | approved |` trong
+     Metadata PRD (dấu duyệt nghiệp vụ, do người quyết) → rồi /generate-bdd.
 ```
 
 ---
@@ -329,10 +342,9 @@ Với mỗi finding có `auto_fixable: true`, theo thứ tự (critical → majo
 
 | check_id | Áp dụng gì |
 |----------|--------------|
-| P0.3 (Thiếu status) | Thêm row `| **Status** | draft |` vào bảng Metadata |
 | P1 (Banned term) | Thay mọi lần xuất hiện banned term bằng canonical term |
 | P1 (Thuật ngữ kỹ thuật/UI) | Diễn đạt lại theo Business Language Guard (Nhóm 1) / chuyển Design Spec (2) / bỏ về Tech Docs (3) |
-| P4 (Structure) | Thêm skeleton section/metadata còn thiếu; greenfield → xoá section "Existing API Contract" rỗng |
+| P4 (Structure) | Thêm skeleton section/metadata còn thiếu (row Status vắng → thêm mặc định `draft`); greenfield → xoá section "Existing API Contract" rỗng |
 
 > **Chạy Business Language Guard trên text vừa sửa TRƯỚC khi ghi** (xem section "Ngôn ngữ nghiệp vụ") — không để bản auto-fix tự kéo thuật ngữ kỹ thuật vào.
 
@@ -350,13 +362,14 @@ Với mỗi finding có `auto_fixable: true`, theo thứ tự (critical → majo
 | B5 | Thêm @trace header còn thiếu, sinh lại Coverage Matrix / Pre-merge Checklist |
 | B6 | Thêm `And <side-effect>` còn thiếu vào block Then |
 
-Sau khi áp dụng mỗi finding, đánh dấu nó `status: "applied_automatically"` trong file findings.
+Sau khi áp dụng mỗi finding, đánh dấu nó `status: "applied"` + `applied_via: "fix"` trong file findings.
 
 ### Phase 3 — Version bump
 
-- **PRD**: nếu ≥1 finding được áp dụng → bump version **minor** (auto-fix chỉ áp dụng thay banned-term P1 và thêm skeleton P4 — không bao giờ thay đổi cấu trúc UC hay nội dung BR, nên minor bump luôn đúng), thêm entry Changelog:
+- **PRD**: nếu ≥1 finding được áp dụng → bump version **minor** (auto-fix chỉ áp dụng thay banned-term P1 và thêm skeleton P4 — không bao giờ thay đổi cấu trúc UC hay nội dung BR, nên minor bump luôn đúng), **reset `| **Status** | draft |` trong Metadata** (PRD vừa đổi sau khi duyệt → con dấu duyệt cũ hết hiệu lực, phải duyệt lại — đồng bộ với /refine-prd), thêm entry Changelog:
   `Auto-fix: applied {N} auto-fixable review-context findings`
 - **BDD**: nếu ≥1 finding được áp dụng → tăng `@trace.bdd_version` lên 0.1
+- **Cả hai**: ghi `applied_to_version: "{version vừa bump tới}"` ở root level của findings — đóng dấu "target đổi tới version này là do lệnh này áp", để lần review delta sau phân biệt thay đổi của chính mình với thay đổi do actor khác (xem "Chọn full vs delta").
 
 ### Phase 4 — Report
 
@@ -371,13 +384,14 @@ Auto-fixed : {N} findings ({critical} critical, {major} major, {minor} minor)
 Còn pending (cần quyết định của con người): {N}
   - F00X [{severity}] {tóm tắt finding}  ← mở file findings trong Review Board
 
-{If PRD}: Version bumped: {old} → {new}
+{If PRD}: Version bumped: {old} → {new}  |  Status: reset về draft (cần duyệt lại)
 {If BDD}: bdd_version: {old} → {new}
 
 File findings:
   {If PRD}: {paths.refinement_dir}/{prd-slug}-review-context-findings.yaml
   {If BDD}: {paths.refinement_dir}/{uc-id}-review-bdd-findings.yaml
 Chạy lại /review-context {file} để xác nhận 0 finding critical còn lại.
+Khi sạch critical + PO duyệt → đặt | **Status** | approved | trong Metadata rồi /generate-bdd.
 ```
 
 Nếu 0 finding nào auto-fixable → in:
@@ -399,26 +413,28 @@ Mở file findings trong Review Board → rồi chạy: /review-context --resume
    - PRD: `{paths.refinement_dir}/{prd-slug}-review-context-findings.yaml`
    - BDD: `{paths.refinement_dir}/{uc-id}-review-bdd-findings.yaml`
 2. Đọc file findings.
-3. Gom các finding có `status: "accepted"` hoặc `status: "modified"`.
+3. Gom các finding có `status: "accepted"` hoặc `status: "modified"`. Bỏ qua `rejected`/`deferred`.
 4. Nếu không có → báo "No accepted findings. File unchanged." và dừng.
+5. Nếu còn finding `status: "needs_discussion"` → cảnh báo (không dừng): `"⚠️  {N} finding chưa ngã ngũ (needs_discussion) — bỏ qua lần áp này; giải quyết trong Review Board rồi --resume lại."`
 
 ### Phase 2 — Áp dụng fix
 
 Áp dụng theo thứ tự: critical → major → minor.
 
+Với mỗi finding `accepted`/`modified` sau khi áp xong → đặt `status: "applied"` + `applied_via: "resume"` trong findings (hoàn tất vòng đời, cùng quy ước với `--fix` và `/refine-prd`).
+
 > **Chạy Business Language Guard trên text vừa sửa TRƯỚC khi ghi** (xem section "Ngôn ngữ nghiệp vụ") — đặc biệt với P2 (sửa câu mơ hồ) / P4 skeleton: không để bản fix tự kéo thuật ngữ kỹ thuật-UI vào PRD.
 
 **Với finding PRD:**
 | check_id | Làm gì |
 |----------|-----------|
-| P0.3 (Thiếu status) | Thêm row `| **Status** | draft |` vào bảng Metadata |
 | P1 (Banned term) | Thay banned term bằng canonical; thuật ngữ kỹ thuật/UI → diễn đạt lại theo Business Language Guard |
 | P2 (Ambiguity) | Áp dụng fix nêu trong `suggestion` hoặc note `modified` |
 | P3 (Conflict) | Áp dụng cách giải quyết nêu trong note modified |
-| P4 (Structure) | Thêm section/metadata field còn thiếu |
+| P4 (Structure) | Thêm section/metadata field còn thiếu (row Status vắng → thêm mặc định `draft`) |
 | P5 (Custom) | Áp dụng như nêu trong suggestion/note |
 
-→ Sau khi áp dụng, bump version PRD (minor) và thêm entry Changelog.
+→ Sau khi áp dụng, bump version PRD (minor), **reset `| **Status** | draft |` trong Metadata** (PRD vừa đổi sau khi duyệt → phải duyệt lại — đồng bộ với /refine-prd), thêm entry Changelog, và ghi `applied_to_version: "{new_version}"` ở root level của findings (xem "Chọn full vs delta").
 
 **Với finding BDD:**
 | check_id | Làm gì |
@@ -432,20 +448,22 @@ Mở file findings trong Review Board → rồi chạy: /review-context --resume
 
 → Sau khi áp dụng, tăng `@trace.bdd_version` trong header file lên 0.1.
 → Đồng thời cập nhật `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv`: đặt cột `bdd_version` thành giá trị `@trace.bdd_version` mới cho mọi row, và đặt `last_updated` thành ngày hôm nay.
+→ Ghi `applied_to_version: "{@trace.bdd_version mới}"` ở root level của findings (xem "Chọn full vs delta").
 
 ### Phase 3 — Report
 
 ```
 /review-context --resume Đã áp dụng — {target file}
 Applied  : {N} findings ({critical} critical, {major} major, {minor} minor)
-Skipped  : {N} rejected/deferred
+Skipped  : {N} rejected/deferred/needs_discussion
 
 Changes:
   - {tóm tắt change 1}
   - {tóm tắt change 2}
 
-{If PRD}: Version bumped: {old} → {new}
+{If PRD}: Version bumped: {old} → {new}  |  Status: reset về draft (cần duyệt lại)
 {If BDD}: bdd_version: {old} → {new}
 
 Chạy lại /review-context {file} để xác nhận 0 finding critical còn lại.
+Khi sạch critical + PO duyệt → đặt | **Status** | approved | trong Metadata rồi /generate-bdd.
 ```

package/commands/review-tech-docs.md

@@ -682,7 +682,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/commands/setup-ai-first.md

@@ -140,15 +140,15 @@ Rồi:
 - Artifact theo từng feature (`specs/{domain}/{prd-slug}/{ {TICKET-ID}-{prd-slug}.md, bdd/, tech-docs/, design-spec/}`) được tạo on demand bởi các lệnh generate — ĐỪNG tạo trước
 - Skip: `.trace/` (theo service, sống cạnh code trong mỗi service submodule)
 - Sinh `CLAUDE.md` tối thiểu chỉ với §1 (project overview) và §7 (git conventions)
-- Hỏi người dùng: **"Liệt kê các business domain của bạn (vd auth, payment, loyalty):"** — lưu thành domain list cho `project-context.yaml` và nhắc PO các tên này phải được dùng nhất quán làm `@trace.domain` trong mọi PRD
+- Hỏi người dùng: **"Liệt kê các business domain của bạn (vd auth, payment, loyalty):"** — lưu thành domain list cho `project-context.yaml` và nhắc PO các tên này phải được dùng nhất quán ở row `| **Domain** |` của bảng Metadata trong mọi PRD
 - Thông báo:
   - Lệnh cho PO repo: `/define-product`, `/generate-prd`, `/review-context`, `/generate-design-spec`
-  - **Quan trọng cho handoff team dev:** Mọi PRD phải có `@trace.domain: {domain}` trong frontmatter. Team dev dùng nó để route BDD/code sinh ra tới đúng service submodule. Tên domain không nhất quán sẽ phá routing.
-  - Frontmatter PRD khuyến nghị:
+  - **Quan trọng cho handoff team dev:** Mọi PRD phải có row `| **Domain** | {domain} |` trong **bảng Metadata**. Team dev dùng nó để route BDD/code sinh ra tới đúng service submodule. Tên domain không nhất quán sẽ phá routing.
+  - Bảng Metadata PRD (do `/generate-prd` điền sẵn theo template):
     ```
-    @trace.domain: {domain}    ← phải khớp một key trong services config của team dev
-    @trace.id: {TICKET-ID}
-    @trace.status: draft | approved
+    | **Domain** | {domain} |       ← phải khớp một key trong services config của team dev
+    | **Ticket** | {TICKET-ID} |
+    | **Status** | draft | approved |
     ```
 
 ## Step 1 — Tạo cấu trúc thư mục
@@ -446,7 +446,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |
@@ -510,7 +510,7 @@ Next:
 Next:
   1. Review .agent/project-context.yaml:
      - Cập nhật services[].path khớp tên thư mục submodule thực tế
-     - Cập nhật domain key của services khớp @trace.domain trong các file PRD
+     - Cập nhật domain key của services khớp row `Domain` (bảng Metadata) trong các file PRD
      - Xác nhận path spec_source đúng
 
   2. Chạy /sync — một lệnh lo mọi thứ còn lại:
@@ -529,7 +529,7 @@ Next:
 ```
 Next:
   1. Điền .agent/project-context.yaml:
-     - domains: [liệt kê mọi business domain — chúng thành giá trị @trace.domain trong PRD]
+     - domains: [liệt kê mọi business domain — chúng thành row `Domain` (bảng Metadata) trong PRD]
      - project.name, project.description
   2. Điền specs/domain-knowledge/business-dictionary.md  ← canonical terms
   3. Điền specs/domain-knowledge/core-entities.md        ← entity glossary
@@ -539,7 +539,7 @@ Next:
   6. /define-product để bắt đầu feature đầu tiên
 
 ⚠️  Nhắc handoff team dev:
-  - Mỗi PRD phải có @trace.domain khớp một trong domains list của bạn
+  - Mỗi PRD phải có row `Domain` (bảng Metadata) khớp một trong domains list của bạn
   - Khi team dev setup umbrella repo của họ, họ map các tên domain này
     tới path service submodule trong section services của project-context.yaml
   - Chia sẻ tên domain với team dev trước khi họ cấu hình umbrella

package/commands/setup-ai-first.tmpl

@@ -52,15 +52,15 @@ Rồi:
 - Artifact theo từng feature (`specs/{domain}/{prd-slug}/{ {TICKET-ID}-{prd-slug}.md, bdd/, tech-docs/, design-spec/}`) được tạo on demand bởi các lệnh generate — ĐỪNG tạo trước
 - Skip: `.trace/` (theo service, sống cạnh code trong mỗi service submodule)
 - Sinh `CLAUDE.md` tối thiểu chỉ với §1 (project overview) và §7 (git conventions)
-- Hỏi người dùng: **"Liệt kê các business domain của bạn (vd auth, payment, loyalty):"** — lưu thành domain list cho `project-context.yaml` và nhắc PO các tên này phải được dùng nhất quán làm `@trace.domain` trong mọi PRD
+- Hỏi người dùng: **"Liệt kê các business domain của bạn (vd auth, payment, loyalty):"** — lưu thành domain list cho `project-context.yaml` và nhắc PO các tên này phải được dùng nhất quán ở row `| **Domain** |` của bảng Metadata trong mọi PRD
 - Thông báo:
   - Lệnh cho PO repo: `/define-product`, `/generate-prd`, `/review-context`, `/generate-design-spec`
-  - **Quan trọng cho handoff team dev:** Mọi PRD phải có `@trace.domain: {domain}` trong frontmatter. Team dev dùng nó để route BDD/code sinh ra tới đúng service submodule. Tên domain không nhất quán sẽ phá routing.
-  - Frontmatter PRD khuyến nghị:
+  - **Quan trọng cho handoff team dev:** Mọi PRD phải có row `| **Domain** | {domain} |` trong **bảng Metadata**. Team dev dùng nó để route BDD/code sinh ra tới đúng service submodule. Tên domain không nhất quán sẽ phá routing.
+  - Bảng Metadata PRD (do `/generate-prd` điền sẵn theo template):
     ```
-    @trace.domain: {domain}    ← phải khớp một key trong services config của team dev
-    @trace.id: {TICKET-ID}
-    @trace.status: draft | approved
+    | **Domain** | {domain} |       ← phải khớp một key trong services config của team dev
+    | **Ticket** | {TICKET-ID} |
+    | **Status** | draft | approved |
     ```
 
 ## Step 1 — Tạo cấu trúc thư mục
@@ -322,7 +322,7 @@ Next:
 Next:
   1. Review .agent/project-context.yaml:
      - Cập nhật services[].path khớp tên thư mục submodule thực tế
-     - Cập nhật domain key của services khớp @trace.domain trong các file PRD
+     - Cập nhật domain key của services khớp row `Domain` (bảng Metadata) trong các file PRD
      - Xác nhận path spec_source đúng
 
   2. Chạy /sync — một lệnh lo mọi thứ còn lại:
@@ -341,7 +341,7 @@ Next:
 ```
 Next:
   1. Điền .agent/project-context.yaml:
-     - domains: [liệt kê mọi business domain — chúng thành giá trị @trace.domain trong PRD]
+     - domains: [liệt kê mọi business domain — chúng thành row `Domain` (bảng Metadata) trong PRD]
      - project.name, project.description
   2. Điền specs/domain-knowledge/business-dictionary.md  ← canonical terms
   3. Điền specs/domain-knowledge/core-entities.md        ← entity glossary
@@ -351,7 +351,7 @@ Next:
   6. /define-product để bắt đầu feature đầu tiên
 
 ⚠️  Nhắc handoff team dev:
-  - Mỗi PRD phải có @trace.domain khớp một trong domains list của bạn
+  - Mỗi PRD phải có row `Domain` (bảng Metadata) khớp một trong domains list của bạn
   - Khi team dev setup umbrella repo của họ, họ map các tên domain này
     tới path service submodule trong section services của project-context.yaml
   - Chia sẻ tên domain với team dev trước khi họ cấu hình umbrella

package/commands/sync.md

@@ -364,7 +364,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/commands/update-framework.md

@@ -187,7 +187,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/commands/validate-traces.md

@@ -757,7 +757,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/core/FRAMEWORK_VERSION

@@ -1 +1 @@
-0.14.6
+0.14.7

package/core/commands/debug.md

@@ -672,7 +672,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/core/commands/define-product.md

@@ -670,7 +670,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/core/commands/dev-gen-test.md

@@ -960,7 +960,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/core/commands/dev-run-test.md

@@ -684,7 +684,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |

package/core/commands/dev-smoke-test.md

@@ -658,7 +658,7 @@ Gợi ý lệnh kế tiếp hợp lý theo phase của workflow:
 | /define-product         | `/generate-prd {product-definition-file}`     |
 | /generate-prd           | `/refine-prd {prd-file}` rồi `/review-context {prd-file}` |
 | /refine-prd             | Mở Review Board → cập nhật PRD → `/review-context {prd-file}` |
-| /review-context (PRD)   | FE/App: `/generate-design-spec {prd-file}` (rồi BDD sau khi sign-off); BE: `/generate-bdd {prd-file}` trực tiếp; sửa PRD nếu NEEDS_FIX |
+| /review-context (PRD)   | Khi 0 critical → PO đặt `Status: approved`, rồi FE/App: `/generate-design-spec {prd-file}` (→ design sign-off → BDD); BE: `/generate-bdd {prd-file}`. Còn critical/NEEDS_FIX → sửa PRD (giữ draft) |
 | /generate-design-spec   | Designer review → xác nhận link Figma → PO + Designer sign-off → `/generate-bdd {prd-file}` |
 | /generate-bdd           | `/review-context {feature-file}` để kiểm tra độ phủ |
 | /review-context (BDD)   | `/generate-tech-docs {UC-ID}` nếu APPROVED; sinh lại nếu NEEDS_FIX |