@educa-corp/fw 0.7.0 → 0.8.0

package/CHANGELOG.md

@@ -3,6 +3,16 @@
 > `fw install` in các mục của những version mới hơn bản đang cài trong dự án.
 > Mỗi lần sửa lệnh, khuôn, bộ câu hỏi hay công cụ đều phải tăng version và thêm một mục ở đây. Test sẽ báo lỗi nếu version chưa có mục.
 
+## 0.8.0 — 2026-10-01
+
+- PRD có mục mới **User flow**: các hành trình xuyên suốt nhiều UC, mỗi hành trình gồm một dòng trong bảng và một sơ đồ mermaid, có nhánh lỗi. **Mỗi UC phải có mặt trong ít nhất một hành trình**, `spec_edit flowcheck` kiểm và PRD thiếu User flow thì không duyệt được. PRD đã có: chạy `/prd <EPIC-ID> change thêm User flow`.
+- `/prd refine` rẻ hơn: các agent ghi kết quả ra file trong `.fw/tmp/`, không đổ báo cáo về phiên chính. Agent kiểm chứng **kiểm từng finding gốc trước, gộp sau**, rồi tự ghi vào `prd-refine.md`. Lăng kính Phạm vi chỉ đọc đúng phần cần của epic và `product.md`. Mọi lăng kính vẫn đọc **toàn bộ PRD**.
+- Finding được **sắp theo mức độ, rồi theo lăng kính** (QA → DEV → SA → Phạm vi). Mã F đánh theo thứ tự đó.
+- **Quyết theo nhóm** cho major và minor (*"nhận tất cả minor"*, *"nhận hết UC-003 trừ F12"*). Critical vẫn phải quyết từng mã.
+- Bảng Tóm tắt của refine ghi số nhận · sửa · bác · hoãn, để đo lớp kiểm chứng.
+- Lăng kính SA soi thêm User flow: ngõ cụt, thiếu nhánh lỗi, sơ đồ không khớp UC.
+- `fw install` thêm `.fw/tmp/` vào `.gitignore`.
+
 ## 0.7.0 — 2026-10-01
 
 - Chế độ mới **`/prd <EPIC-ID> refine`**: rà nội dung PRD qua 4 lăng kính (QA · DEV · SA · Phạm vi). Mỗi lăng kính là một sub-agent **Opus**, sau đó một agent **kiểm chứng** loại bỏ finding không đứng vững. Bạn quyết từng finding: nhận, sửa, bác hoặc hoãn.

package/bin/fw.js

@@ -32,7 +32,8 @@ const SOURCES = [
 const RUNTIME_FILES = ['package.json', 'CHANGELOG.md', 'bin/config.template.yaml', ...SOURCES.map((s) => s.from)];
 const CONFIG = '.fw/config.yaml';
 const SETTINGS = '.claude/settings.json';
-const GITIGNORE_LINE = '.fw/backup/';
+// Không commit: bản sao file đã sửa (khi nâng cấp) và file tạm của các agent.
+const GITIGNORE_LINES = ['.fw/backup/', '.fw/tmp/'];
 
 // Lệnh AI dùng để sửa file spec (xem tools/spec_edit.py). Cho phép sẵn để PO không bị hỏi quyền mỗi lần.
 const SPEC_EDIT = '.fw/core/tools/spec_edit.py';
@@ -100,16 +101,17 @@ function allowSpecEdit(target) {
   return { added };
 }
 
-// .fw/backup/ chứa bản sao file người dùng đã sửa, giữ lại khi nâng cấp — không nên vào git.
-function ignoreBackup(target) {
+// Thêm các dòng còn thiếu vào .gitignore, giữ nguyên nội dung cũ. Trả về các dòng đã thêm.
+function ignoreFwFiles(target) {
   const p = path.join(target, '.gitignore');
   const text = fs.existsSync(p) ? fs.readFileSync(p, 'utf8') : '';
   const lines = text.split(/\r?\n/).map((l) => l.trim());
-  if (lines.includes(GITIGNORE_LINE) || lines.includes('/' + GITIGNORE_LINE)) return false;
+  const add = GITIGNORE_LINES.filter((g) => !lines.includes(g) && !lines.includes('/' + g));
+  if (!add.length) return [];
   const sep = text && !text.endsWith('\n') ? '\n' : '';
-  const block = '\n# @educa-corp/fw — bản sao file đã sửa, tạo khi nâng cấp\n' + GITIGNORE_LINE + '\n';
+  const block = '\n# @educa-corp/fw — bản sao khi nâng cấp, file tạm của agent\n' + add.join('\n') + '\n';
   fs.writeFileSync(p, text + sep + block);
-  return true;
+  return add;
 }
 
 function install(target) {
@@ -177,7 +179,7 @@ function install(target) {
     changes: changesSince(old.version),
     python: findPython(),
     permissions: allowSpecEdit(target),
-    gitignore: ignoreBackup(target),
+    gitignore: ignoreFwFiles(target),
   };
 }
 
@@ -208,7 +210,7 @@ function printReport(r) {
   }
   console.log(`  thêm ${r.added.length} · cập nhật ${r.updated.length} · gỡ ${r.removed.length}`);
   if (r.configCreated) console.log(`  tạo ${CONFIG} — hãy mở file này và khai specs, tracker, units`);
-  if (r.gitignore) console.log(`  thêm ${GITIGNORE_LINE} vào .gitignore`);
+  if (r.gitignore.length) console.log(`  thêm ${r.gitignore.join(', ')} vào .gitignore`);
   if (r.permissions.error) console.log(`  ⚠ ${r.permissions.error}`);
   else if (r.permissions.added.length) console.log(`  thêm ${r.permissions.added.length} luật cho phép vào ${SETTINGS} (AI sửa spec không phải hỏi quyền)`);
   if (r.python) {

package/commands/prd.md

@@ -44,7 +44,7 @@ Nếu **trước lệnh này** phiên đã có hội thoại khác, dòng đầu
 6. **Sửa file: CHỈ dùng `spec_edit.py`** (gọi là `SE`). Không dùng Edit/Write, không tự viết script:
    - Tạo: `SE create <file> <<'EOF'` … `EOF` · Sửa: `SE edit <file> <<'EOF'` `[{"old": "…", "new": "…"}]` `EOF` (gom mọi chỗ sửa của một lượt vào một lần gọi)
    - Frontmatter: `SE set <file> version=1.1 status=draft updated=YYYY-MM-DD`
-   - `SE pending <file>` · `SE confirm <file> UC-003-BR02 UC-003-AC01` · `SE next-uc {specs}` · `SE coverage <epic> <prd>`
+   - `SE pending <file>` · `SE confirm <file> UC-003-BR02 UC-003-AC01` · `SE next-uc {specs}` · `SE coverage <epic> <prd>` · `SE flowcheck <prd>`
    - Đọc **một mục**: `SE section <file> <mã>`. Mã mục là `<!-- sec:… -->` ở tiêu đề (vd `constraints`, `usecases`, `open`). **Luôn tìm mục theo mã**, không theo số hay tên tiêu đề, không tự cắt file bằng `sed`/`grep`. Khi sửa, giữ nguyên `<!-- sec:… -->`.
    - `SE` báo lỗi thì **không có gì được ghi**. Đọc lại file, sửa lệnh rồi chạy lại. Không bỏ qua lỗi. Lỗi mà **không in dòng nào** là Python chưa kịp chạy: chạy lại đúng lệnh đó một lần.
 7. **Duyệt.** `status=approved` chỉ đặt được khi không còn `🤖`, `open_questions=0`, **đã refine đúng version này** (`refined` = `version`, không còn critical/major chưa quyết), và có người duyệt. Chưa refine thì báo *"Chạy `/prd EP-xx refine` trước khi duyệt."* Hỏi PO *"Ai duyệt PRD này?"* (mặc định là PO của epic), rồi đặt trong **một** lệnh: `SE set D status=approved approved_by=<tên> approved_at=YYYY-MM-DD`. `SE` tự chặn nếu chưa đủ. Không tìm cách lách.
@@ -57,7 +57,7 @@ In ra đúng khối sau:
 ---
 Trạng thái : {✅ Đã duyệt v{version} | 🟡 Nháp v{version} — còn {n} mục 🤖, {k} câu hỏi mở}
 Đã ghi     : {D} {· epic → handed-off · product.md nếu có}
-Kiểm       : coverage {đủ | thiếu …} · {số UC} UC · {số BR} BR · {số AC} AC
+Kiểm       : coverage {đủ | thiếu …} · user flow {đủ | thiếu …} · {số UC} UC · {số BR} BR · {số AC} AC
 Luồng      : Product → [PRD ◀ bạn ở đây] → BDD → TDD · Design-spec → Code → Test → QC
 Bước tiếp  : {`/clear` rồi `/prd {id} refine` | /bdd UC-xxx | trả lời / xác nhận các mục trên}
 ```

package/docs/guide/01-bat-dau.md

@@ -25,10 +25,10 @@ npx @educa-corp/fw install
 Kết quả mẫu:
 
 ```
-fw 0.6.2 — đã cài
-  thêm 20 · cập nhật 0 · gỡ 0
+fw 0.8.0 — đã cài
+  thêm 24 · cập nhật 0 · gỡ 0
   tạo .fw/config.yaml — hãy mở file này và khai specs, tracker, units
-  thêm .fw/backup/ vào .gitignore
+  thêm .fw/backup/, .fw/tmp/ vào .gitignore
   thêm 3 luật cho phép vào .claude/settings.json (AI sửa spec không phải hỏi quyền)
   Python: python
 ```
@@ -43,6 +43,7 @@ Lệnh tạo ra:
 | `.fw/config.yaml` | **Cấu hình của dự án. Bạn được sửa** | ✅ Có |
 | `.fw/guide/` | Bộ hướng dẫn này, đúng với version đang cài | ✅ Có |
 | `.fw/backup/` | Bản sao file bạn đã tự sửa, được giữ lại khi nâng cấp | ❌ Không. `fw install` đã tự thêm vào `.gitignore` |
+| `.fw/tmp/` | File tạm của các agent (ví dụ khi refine) | ❌ Không. Đã tự thêm vào `.gitignore` |
 
 Commit xong, đồng đội clone về là **có ngay**, không cần tự cài.
 

package/docs/guide/02-khai-niem.md

@@ -25,6 +25,7 @@ Chỉ những khái niệm bạn **gặp khi dùng** các lệnh hiện có.
 | **Business Logic** | Cách luật được thực hiện: rẽ nhánh, công thức, thông báo khi lỗi | Email trống hoặc đã có tài khoản → từ chối, báo lý do |
 | **AC** (Acceptance Criteria, điều kiện nghiệm thu) | Điều kiện kiểm được là đạt hay không đạt, dạng *"Khi … thì …"* | UC-002-AC01: Khi tài khoản mới quá 7 ngày chưa đăng nhập thì bị chuyển inactive, đăng nhập bị từ chối |
 | **Ràng buộc** | Điều kiện áp cho **mọi epic**, mã `CON-01`… | CON-01: Audit log không được xoá hay sửa |
+| **User flow** (hành trình) | Đường đi của một actor qua nhiều UC, có rẽ nhánh và nhánh lỗi, vẽ bằng sơ đồ trong PRD. Mã `J1`, `J2`… | J1 Nhân sự mới vào hệ thống: UC-001 → UC-003 → UC-005 |
 | **Checkpoint** | Một điểm dừng để bạn chốt. `/product` có 2 (sản phẩm) hoặc 3 (epic) checkpoint | — |
 
 ## Mã ổn định

package/docs/guide/README.md

@@ -1,7 +1,7 @@
 # Hướng dẫn sử dụng `@educa-corp/fw`
 
 > Framework làm việc với Claude Code: đưa một tính năng đi từ **ý tưởng → làm rõ yêu cầu → PRD → …**, AI hỏi và viết, con người xác nhận ở mỗi bước.
-> Hướng dẫn này viết cho **bản 0.7.0**. Chỉ mô tả những lệnh **đã có**. Lệnh mới có thì hướng dẫn mới được bổ sung.
+> Hướng dẫn này viết cho **bản 0.8.0**. Chỉ mô tả những lệnh **đã có**. Lệnh mới có thì hướng dẫn mới được bổ sung.
 > Trong dự án đã cài framework, bản hướng dẫn đúng với version đang dùng nằm ở **`.fw/guide/`**. Có thể hỏi Claude: *"Đọc .fw/guide và cho biết cách đổi PRD"*.
 
 ---

package/docs/guide/lenh/prd-refine.md

@@ -22,12 +22,14 @@
 |---|---|---|
 | **QA** | AC có kiểm được là đạt hay không? AC có lặp lại BR không? | *"UC-002-AC03 nói 'hiển thị thông báo phù hợp' — không kiểm được"* |
 | **DEV** | BR và Business Logic có đủ để làm mà không phải đoán? Nhánh thiếu, điều kiện biên, xử lý khi lỗi, BR mâu thuẫn | *"Gửi email đặt lại mật khẩu thất bại thì sao?"* |
-| **SA** | Các UC có thông suốt, nhất quán? Trạng thái, vòng đời của đối tượng; ai được làm gì | *"UC-002 cho Admin khoá tài khoản, nhưng UC-009 tự tạo tài khoản không nói trạng thái ban đầu"* |
+| **SA** | Các UC có thông suốt, nhất quán? **User flow** có ngõ cụt hay thiếu nhánh lỗi không? Trạng thái, vòng đời của đối tượng; ai được làm gì | *"UC-002 cho Admin khoá tài khoản, nhưng UC-009 tự tạo tài khoản không nói trạng thái ban đầu"* |
 | **Phạm vi** | PRD có vượt ngoài phạm vi epic, đi ngược ràng buộc `CON-xx`, hay giẫm lên epic khác không? | *"UC-009 xử lý đơn hàng CRM — thuộc EP-03"* |
 
 *(Các ví dụ trên là ví dụ minh hoạ.)*
 
-Mỗi lăng kính là một agent riêng, chạy song song, **bắt buộc dùng model Opus**. Sau đó có thêm **một agent kiểm chứng**, nhiệm vụ duy nhất là **cố chứng minh từng finding là sai** bằng cách tra lại PRD. Finding nào không đứng vững thì bị bỏ. Đây là lớp chặn chính đối với các finding do AI ảo giác.
+Mỗi lăng kính là một agent riêng, chạy song song, **bắt buộc dùng model Opus**, và đọc **toàn bộ PRD**. Sau đó có thêm **một agent kiểm chứng**: nó **cố chứng minh từng finding là sai** bằng cách tra lại PRD, rồi mới gộp trùng và sắp xếp. Finding nào không đứng vững thì bị bỏ, finding nào được trả lời một phần thì được thu hẹp. Đây là lớp chặn chính đối với các finding do AI ảo giác.
+
+Khi bạn quyết xong, bảng Tóm tắt trong `prd-refine.md` ghi số **nhận · sửa · bác · hoãn**. **Tỉ lệ bác cao** nghĩa là lớp kiểm chứng còn lỏng. Hãy báo người phụ trách framework nếu bạn thấy vậy.
 
 ## Mức độ
 
@@ -39,12 +41,22 @@ Mỗi lăng kính là một agent riêng, chạy song song, **bắt buộc dùng
 
 ## Bạn quyết thế nào
 
-AI trình bảng tóm tắt. Chi tiết từng finding nằm trong `review/prd-refine.md`. Bạn trả lời bằng mã:
+AI trình bảng tóm tắt, **sắp theo mức độ** (critical → major → minor), rồi **theo lăng kính** (QA → DEV → SA → Phạm vi). Mã F đánh theo đúng thứ tự đó, nên F01 luôn là finding nặng nhất. Chi tiết từng finding nằm trong `review/prd-refine.md`.
+
+Quyết theo mã:
 
 ```
 nhận F01, F03 · bác F02 vì đã có ở UC-002 · F04 sửa thành "khoá 30 phút" · hoãn F05
 ```
 
+Hoặc **quyết theo nhóm**, áp cho major và minor:
+
+```
+nhận tất cả minor · nhận hết UC-003 trừ F12 · bác F20–F24 vì đã có ở epic khác
+```
+
+Quyết theo nhóm thì AI **liệt kê lại đúng các mã** sẽ bị áp rồi hỏi bạn xác nhận. **Critical luôn phải quyết từng mã.**
+
 | Quyết định | Kết quả |
 |---|---|
 | `nhận` | AI sửa PRD theo đề xuất |

package/docs/guide/lenh/prd.md

@@ -51,7 +51,23 @@ Acceptance Criteria (điều kiện nghiệm thu)
 - UC-001-AC01. Khi Admin import file 10 dòng, trong đó 2 dòng trùng email thì 8 tài khoản được tạo, 2 dòng được báo lỗi kèm lý do. (nguồn: AC1)
 ```
 
-Gồm 5 mục: **Tổng quan** (mục tiêu, actor, phạm vi, ràng buộc áp dụng) · **Use case** · **Màn hình** · **Câu hỏi còn mở** · **Lịch sử thay đổi**. Cột `Nguồn` chỉ ghi mã (xem [Khái niệm](../02-khai-niem.md#nguồn-của-từng-mục-trong-prd)).
+Gồm 6 mục: **Tổng quan** (mục tiêu, actor, phạm vi, ràng buộc áp dụng) · **User flow** · **Use case** · **Màn hình** · **Câu hỏi còn mở** · **Lịch sử thay đổi**.
+
+**User flow** là các **hành trình** xuyên suốt nhiều UC: actor đi qua những UC nào, rẽ nhánh ở đâu, gặp lỗi thì đi đâu. Mỗi hành trình gồm một dòng trong bảng và một sơ đồ (GitLab hiển thị sẵn):
+
+````
+| J1 | Nhân sự mới vào hệ thống | ACT-03 | UC-001 → UC-003 → UC-005 | Admin tạo tài khoản | Đăng nhập được, đã đổi mật khẩu |
+
+```mermaid
+flowchart TD
+  A["UC-001 Admin tạo tài khoản"] --> B{"Đăng nhập lần đầu bằng?"}
+  B -->|Mật khẩu mặc định| C["UC-005 Bắt đổi mật khẩu"]
+  B -->|Google / Facebook| D["UC-004 Ghép theo email"]
+  C -->|Trùng mật khẩu mặc định| X["Từ chối, nhập lại"]
+```
+````
+
+*(ví dụ minh hoạ)* **Mỗi UC phải có mặt trong ít nhất một hành trình, và mỗi hành trình phải có ít nhất một nhánh lỗi.** Công cụ kiểm điều kiện đầu, và PRD thiếu User flow thì không duyệt được. PRD tạo bằng bản trước 0.8.0 chưa có mục này: chạy `/prd EP-01 change thêm User flow`. Cột `Nguồn` chỉ ghi mã (xem [Khái niệm](../02-khai-niem.md#nguồn-của-từng-mục-trong-prd)).
 
 ---
 

package/docs/guide/xu-ly-su-co.md

@@ -20,6 +20,8 @@
 | AI chạy lại cùng một lệnh `spec_edit` | Lần trước Python thoát mà không chạy (thường gặp với bản Store) | Bình thường, AI được dặn chạy lại một lần |
 | `không đặt được status=approved: còn 3 dòng 🤖` | Còn mục chưa được bạn xác nhận | Xác nhận các mục AI liệt kê |
 | `… chưa có approved_by` | Chưa ghi người duyệt | Trả lời câu *"Ai duyệt?"* |
+| `PRD chưa có mục User flow` | PRD tạo bằng bản trước 0.8.0 | Chạy `/prd EP-xx change thêm User flow` |
+| `UC chưa có mặt trong hành trình nào của User flow: UC-007` | Có UC chưa được vẽ vào sơ đồ nào | AI sẽ bổ sung. Hoặc chạy `/prd EP-xx change thêm UC-007 vào user flow` |
 | `… bản v1.2 chưa refine` | PRD chưa được rà nội dung ở version này | Chạy `/prd EP-xx refine` |
 | `… còn finding critical/major chưa có quyết định: F01, F04` | Bạn chưa quyết các finding đó | Trả lời: nhận, sửa, bác (kèm lý do) hay hoãn |
 | `Bản v1.1 đã refine xong` | Gọi refine lại khi PRD chưa đổi | Không cần làm gì. Thật sự muốn rà lại từ đầu thì thêm `--full` |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@educa-corp/fw",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "Framework làm việc với Claude Code cho phòng PTPM",
   "bin": {
     "fw": "bin/fw.js"

package/ref/prd/change.md

@@ -27,6 +27,7 @@ Khi PO đồng ý kế hoạch:
 1. **Một** lần `SE edit D` cho mọi chỗ sửa:
    - Mục sửa và mục thêm mang `✅`, vì PO vừa duyệt kế hoạch. Mục thêm ghi `(nguồn: PRD)`, trừ khi lấy từ một mã epic hay ràng buộc cụ thể.
    - Mục bỏ: giữ dòng, gạch ngang nội dung, ghi *"Đã bỏ (v{mới})"*.
-   - Thêm dòng vào **5. Lịch sử thay đổi**, dạng *"v1.1 — UC-003: khoá sau 3 lần sai (BR02 sửa, AC05 thêm, BR04 bỏ)"*.
-2. Tăng version phụ (1.0 → 1.1): `SE set D version=1.1 updated=…`. PRD đang `approved` thì đặt luôn `status=draft approved_by=— approved_at=—`.
+   - Thay đổi làm đổi luồng (thêm UC, đổi thứ tự, thêm nhánh lỗi) thì sửa luôn mục **User flow**. Yêu cầu là *"thêm User flow"* (PRD tạo bằng bản cũ) thì vẽ mục này từ checkpoint 2 của epic, theo luật trong `new.md`.
+   - Thêm dòng vào mục **Lịch sử thay đổi**, dạng *"v1.1 — UC-003: khoá sau 3 lần sai (BR02 sửa, AC05 thêm, BR04 bỏ)"*.
+2. Chạy `SE flowcheck D`. Còn UC chưa có trong hành trình nào thì sửa cho đủ. Sau đó tăng version phụ (1.0 → 1.1): `SE set D version=1.1 updated=…`. PRD đang `approved` thì đặt luôn `status=draft approved_by=— approved_at=—`.
 3. Báo lại cho PO. Không in lại cả PRD, chỉ tóm tắt những gì đã đổi. Nếu không còn `🤖` và không còn câu hỏi mở thì hỏi: *"Duyệt lại bản v1.1 không?"* PO đồng ý thì duyệt theo luật 7 của lệnh. Bản mới cần người duyệt mới, nên đặt lại `approved_by` và `approved_at`.

package/ref/prd/lenses.md

@@ -35,6 +35,7 @@ Cố ý hẹp. Chỉ hỏi:
 ## SA — thông suốt và nhất quán giữa các UC
 
 Đọc như một architect: toàn bộ luồng có **thông suốt và nhất quán** không? Soi:
+- **User flow** (mục `sec:userflow`): mỗi hành trình có đi tới được điểm ra không, có **ngõ cụt** không, có **nhánh lỗi hoặc ngoại lệ** không. Sơ đồ có khớp với các UC không: bước trong sơ đồ có UC nào thực hiện không, UC có làm điều sơ đồ nói không;
 - tương tác giữa các UC đã được định nghĩa chưa (UC này tạo ra thứ mà UC kia cần);
 - **trạng thái và vòng đời** của đối tượng nghiệp vụ có nhất quán không, ví dụ tài khoản: mới → active → inactive;
 - **ai được làm gì, ai sở hữu gì**;
@@ -44,16 +45,16 @@ Không phán về kiến trúc hay mô hình dữ liệu kỹ thuật.
 
 ## Phạm vi — PRD có đi đúng đường đã chốt không
 
-Đọc thêm file epic (mục checkpoint 1) và `product.md` (mục Ràng buộc, Danh sách epic). Soi:
+Đọc **toàn bộ PRD** (chuyện vượt phạm vi thường nằm trong thân UC, không nằm ở Tổng quan). Tài liệu phụ thì chỉ đọc đúng phần được giao: checkpoint 1 của epic, mục Ràng buộc và Danh sách epic của `product.md`. Soi:
 - PRD có **vượt ra ngoài** phạm vi epic, hoặc làm điều epic ghi là "ngoài phạm vi" không;
 - PRD có **đi ngược** một ràng buộc `CON-xx` không;
 - PRD có **giẫm lên** phạm vi của epic khác không.
 
 Không hỏi lại ưu tiên hay mục tiêu, vì đã chốt ở `/product`.
 
-## Định dạng trả về
+## Định dạng ghi file (agent lăng kính)
 
-Trả về **chỉ** danh sách sau, không viết gì thêm:
+Ghi vào file được giao bằng `SE create --replace <file>`, nội dung **chỉ** là danh sách sau:
 
 ```
 - lens: DEV
@@ -65,14 +66,24 @@ Trả về **chỉ** danh sách sau, không viết gì thêm:
   if_accepted: "…"        # chỉ critical / major: chốt đề xuất này thì phát sinh trường hợp gì
 ```
 
-Không tìm thấy gì thì trả về `[]`.
+Không tìm thấy gì thì ghi `[]`. Sau đó **chỉ trả về một dòng**: *"{lens}: {k} finding → {file}"*. Không chép lại finding vào câu trả lời.
 
-## Kiểm chứng — dành cho agent kiểm chứng
+## Kiểm chứng và ghi file — dành cho agent kiểm chứng
 
-Bạn nhận danh sách finding của 4 lăng kính. Với **từng** finding, **cố chứng minh nó sai**:
-1. Tra PRD: đoạn `quote` có đúng là nguyên văn không? Điều finding nói "thiếu" có thật là thiếu không, hay đã nằm ở mục khác (BR khác, Business Logic, UC khác, Tổng quan)?
-2. Finding có hỏi điều thuộc bước sau (giao diện, kịch bản test, kỹ thuật) không?
-3. Finding có đề xuất giải pháp kỹ thuật không?
-4. Mức độ có đúng định nghĩa không?
+Bạn nhận: PRD `D`, file refine `R` (có thể chưa có), thư mục `W` chứa 4 file kết quả của lượt `n`, và mã F kế tiếp. Làm **đúng thứ tự** sau. Phải **kiểm chứng trước, gộp sau**, để không tự kiểm phần mình vừa viết lại.
 
-Trả về cho mỗi finding một trong ba kết luận: `ĐÚNG` · `SAI: <lý do, kèm trích dẫn chứng minh>` · `HẠ MỨC: <mức mới, lý do>`.
+**1. Kiểm chứng từng finding gốc.** Đọc cả 4 file. Với **từng** finding, **cố chứng minh nó sai**:
+- Tra PRD: đoạn `quote` có đúng là nguyên văn không? Điều finding nói "thiếu" có thật là thiếu không, hay đã nằm ở mục khác (BR khác, Business Logic, UC khác, Tổng quan, User flow)? Đã được trả lời **một phần** thì thu hẹp finding lại, chỉ giữ phần chưa được trả lời.
+- Finding có hỏi điều thuộc bước sau (giao diện, kịch bản test, kỹ thuật) không? Có đề xuất giải pháp kỹ thuật không?
+- Finding có nêu lại một điểm **đã có quyết định** trong `R` không?
+- Mức độ có đúng định nghĩa không?
+
+Kết luận cho mỗi finding: `ĐÚNG` · `SAI` (bỏ) · `HẠ MỨC` (giữ, đổi mức).
+
+**2. Gộp** các finding ĐÚNG trùng nhau (cùng mục, cùng vấn đề), giữ bản rõ nhất. Hai đề xuất trái ngược nhau thì giữ cả hai trong **một** finding, và ghi rõ là cần PO chọn.
+
+**3. Sắp xếp** theo mức độ (critical → major → minor), sau đó theo lăng kính (QA → DEV → SA → Phạm vi). **Đánh mã F theo đúng thứ tự đó**, bắt đầu từ mã F kế tiếp.
+
+**4. Ghi vào `R`.** Chưa có `R` thì `SE create R` theo khuôn `.fw/core/templates/prd-refine.md`. Đã có thì `SE edit` thêm mục `## Lượt {n} — v{version} <!-- sec:round-{n} -->` ở **cuối**. **Không sửa các lượt cũ.** Thêm một dòng vào bảng Tóm tắt, rồi `SE set R prd_version={version} round={n} status=pending`. Mỗi finding theo đúng mẫu trong khuôn, `Quyết định: chờ`.
+
+**5. Trả về một dòng:** *"thô {a} · bỏ {b} · hạ mức {c} · còn {d} (critical {x} · major {y} · minor {z}) → {R}"*.

package/ref/prd/new.md

@@ -23,15 +23,16 @@ Chỉ **2 lượt** hỏi-đáp, vì epic đã được làm rõ kỹ. Không h
 Khi PO đồng ý cách chia UC:
 
 1. Tạo `D` bằng **một** lần `SE create`, theo khuôn `.fw/core/templates/prd.md`:
-   - **1. Tổng quan:** chuyển từ checkpoint 1 của epic. Ghi các ràng buộc `CON-xx` áp cho epic này.
-   - **2. Use case:** mỗi UC gồm điều kiện trước, kết quả sau, luồng chính (lấy các bước liên quan ở checkpoint 2 của epic), bảng BR, Acceptance Criteria (điều kiện nghiệm thu).
+   - **Tổng quan:** chuyển từ checkpoint 1 của epic. Ghi các ràng buộc `CON-xx` áp cho epic này.
+   - **User flow** (`sec:userflow`): vẽ các **hành trình** xuyên suốt nhiều UC, lấy từ luồng chính và edge case ở checkpoint 2 của epic. Mỗi hành trình gồm một dòng trong bảng và một sơ đồ `mermaid` (`flowchart TD`). Nút trong sơ đồ ghi mã UC, không chép lại BR. **Mỗi hành trình có ít nhất một nhánh lỗi hoặc ngoại lệ. Mỗi UC có mặt trong ít nhất một hành trình.** Nút nào AI tự suy ra (không có trong epic) thì ghi kèm `🤖` trong nhãn.
+   - **Use case:** mỗi UC gồm điều kiện trước, kết quả sau, luồng chính (lấy các bước liên quan ở checkpoint 2 của epic), bảng BR, Acceptance Criteria (điều kiện nghiệm thu).
      - **Cột Business Rule:** một BR mỗi dòng, dạng *"Hệ thống PHẢI / KHÔNG ĐƯỢC …"*.
      - **Cột Business Logic:** rẽ nhánh, công thức, thông báo khi lỗi. Lấy từ edge case và nhật ký làm rõ của epic.
      - **AC:** dạng *"Khi … thì …"*, mô tả **kết quả nhìn thấy được**, không mô tả cơ chế.
-   - **3. Màn hình:** chuyển từ "Màn hình chính" của epic, kèm cột UC.
-   - **4. Câu hỏi còn mở:** chỉ những gì phát sinh khi viết PRD.
-   - **5. Lịch sử thay đổi:** dòng `1.0`.
-2. Chạy `SE coverage <epic> D`. **Thiếu mục nào thì bổ sung vào UC phù hợp rồi chạy lại cho tới khi đủ.** Mục mà PO muốn bỏ thì hỏi PO. Không được tự bỏ.
+   - **Màn hình:** chuyển từ "Màn hình chính" của epic, kèm cột UC.
+   - **Câu hỏi còn mở:** chỉ những gì phát sinh khi viết PRD.
+   - **Lịch sử thay đổi:** dòng `1.0`.
+2. Chạy `SE coverage <epic> D` và `SE flowcheck D`. **Thiếu mục nào thì bổ sung vào UC phù hợp rồi chạy lại cho tới khi đủ.** Mục mà PO muốn bỏ thì hỏi PO. Không được tự bỏ.
 3. Epic giờ chỉ còn là lịch sử:
    - `SE set <epic> status=handed-off`
    - Trong `{specs}/product/product.md`, sửa cột Trạng thái của epic thành `đã có PRD`.

package/ref/prd/refine.md

@@ -2,11 +2,12 @@
 
 Mục đích: tìm chỗ **nghiệp vụ còn thiếu, mơ hồ, mâu thuẫn** đến mức sẽ làm sai hoặc phải đoán ở các bước sau. **Không** rà chính tả hay trình bày, vì đó là việc của `/review`.
 
-File refine: `R = {specs}/{domain}/{slug}/review/prd-refine.md` (khuôn `.fw/core/templates/prd-refine.md`).
+- File refine: `R = {specs}/{domain}/{slug}/review/prd-refine.md` (khuôn `.fw/core/templates/prd-refine.md`).
+- Thư mục làm việc của các agent: `W = .fw/tmp/refine/{slug}/`. Thư mục này không commit.
 
 ## Bước A — Xác định lượt
 
-Chạy `SE upgrade D` trước. Lệnh này bổ sung trường `refined` cho PRD tạo bằng bản cũ, và đổi mã nguồn `R…` thành `BR…`.
+Chạy `SE upgrade D` trước. Lệnh này bổ sung trường và mục còn thiếu cho PRD tạo bằng bản cũ (ví dụ `refined`, mục User flow), và đổi mã nguồn `R…` thành `BR…`. Nếu `SE` báo PRD **thiếu mục User flow**, thì dừng và báo: *"PRD chưa có User flow. Chạy `/prd {id} change thêm User flow` trước, rồi refine."*
 
 Đọc frontmatter của `D` (`version`, `refined`) và của `R` (nếu có: `prd_version`, `round`).
 
@@ -21,24 +22,28 @@ Chạy `SE upgrade D` trước. Lệnh này bổ sung trường `refined` cho PR
 
 ## Bước B — Rà (sub-agent, bắt buộc model Opus)
 
+Phiên chính **không đọc** kết quả chi tiết của các agent. Agent ghi ra file, phiên chính chỉ đọc bảng tóm tắt cuối cùng.
+
 1. Dùng công cụ **Agent**, `model: "opus"`, gọi **4 agent song song trong cùng một lượt**: QA · DEV · SA · Phạm vi. Mỗi agent nhận:
-   - đường dẫn `D`, `R` (nếu có), `.fw/core/ref/prd/lenses.md`, và tên lăng kính của nó;
-   - **phạm vi** của lượt (Bước A), và **ngưỡng báo**: lượt 1 báo mọi mức · lượt 2 chỉ báo critical hoặc lỗi do chính bản sửa gây ra;
-   - riêng lăng kính Phạm vi: thêm đường dẫn file epic và `{specs}/product/product.md`.
-2. Gom kết quả, rồi gọi **1 agent kiểm chứng** (`model: "opus"`) với danh sách finding, `D`, và phần "Kiểm chứng" trong `lenses.md`. Chỉ giữ finding nào được kết luận **ĐÚNG**.
-3. Gộp các finding trùng nhau (cùng mục, cùng vấn đề), giữ bản rõ nhất. Hai đề xuất trái ngược nhau thì giữ cả hai trong **một** finding, và nêu rõ là cần PO chọn.
+   - đường dẫn `D` (**đọc toàn bộ**), `R` (nếu có, để đọc sổ quyết định), `.fw/core/ref/prd/lenses.md`, tên lăng kính, **phạm vi** và **ngưỡng báo** của lượt (lượt 1: mọi mức · lượt 2: chỉ critical hoặc lỗi do chính bản sửa gây ra);
+   - riêng **Phạm vi**: thêm các lệnh để đọc tài liệu phụ, **chỉ đúng phần cần**: `SE section <epic> cp1`, `SE section {specs}/product/product.md constraints`, `SE section {specs}/product/product.md epics`;
+   - file kết quả: `W/round-{n}-{lens}.md`. Agent ghi bằng `SE create --replace` (chỉ dùng được trong `.fw/tmp/`) và **chỉ trả về một dòng**: *"{lens}: {k} finding → {file}"*.
+2. Khi đủ 4 dòng, gọi **1 agent kiểm chứng** (`model: "opus"`), giao: `D`, `R`, `W`, số lượt `n`, mã F kế tiếp (lớn nhất trong `R` cộng một, hoặc F01), và phần **"Kiểm chứng và ghi file"** trong `lenses.md`. Agent này kiểm chứng, gộp, sắp xếp, đánh mã, ghi vào `R`, rồi trả về **một dòng** số liệu.
 
-## Bước C — Ghi và trình
+## Bước C — Trình
 
-1. Chưa có `R`: `SE create R` theo khuôn. Đã có: `SE edit` thêm một mục `## Lượt {n} — v{version}` ở **cuối**. Không sửa các lượt cũ, vì chúng là sổ quyết định.
-2. Mã finding đánh **nối tiếp** qua mọi lượt (F01…), không đánh lại.
-3. `SE set R prd_version={version} round={n} status=pending`.
-4. Trình cho PO: **một bảng tóm tắt** (mã · mức · lăng kính · mục · một dòng vấn đề), sắp theo mức độ. Kèm số finding bị bỏ ở bước kiểm chứng, để PO thấy bước này có tác dụng. Nhắc PO: *"Chi tiết xem {R}. Quyết bằng mã: 'nhận F01, F03 · bác F02 vì … · F04 sửa thành … · hoãn F05'."*
-5. Không có finding nào: báo, rồi sang Bước D luôn.
+1. Đọc `SE section R summary` và danh sách tiêu đề finding của lượt này. Danh sách đã được agent kiểm chứng **sắp xếp sẵn** theo mức độ, rồi theo lăng kính (QA → DEV → SA → Phạm vi).
+2. Trình **một bảng tóm tắt** gồm mã · mức · lăng kính · mục · một dòng vấn đề, đúng theo thứ tự đó. Kèm số finding thô, số bị bỏ ở bước kiểm chứng, và số bị hạ mức.
+3. Nhắc PO cách quyết:
+   - *"Chi tiết xem {R}. Quyết theo mã: 'nhận F01, F03 · bác F02 vì … · F04 sửa thành … · hoãn F05'."*
+   - *"Quyết theo nhóm được, áp cho major và minor: 'nhận tất cả minor' · 'nhận hết UC-003 trừ F12' · 'bác F20–F24 vì …'. Critical phải quyết từng mã."*
+4. Lượt này không có finding nào thì báo, rồi sang Bước D luôn.
 
 ## Bước D — Áp quyết định
 
-1. Ghi quyết định của PO vào `R` (`- Quyết định: …`). **Mọi** finding critical / major đều phải có quyết định khác `chờ`. Còn thiếu thì hỏi lại, tối đa 4 mã mỗi lượt.
-2. Finding `nhận` hoặc `sửa`: áp vào `D` trong **một** lần `SE edit`, theo đúng luật của `.fw/core/ref/prd/change.md` (mã mới lấy số kế tiếp, mục bỏ thì gạch ngang, `(nguồn: PRD)`). Thêm một dòng Lịch sử thay đổi nêu mã finding, ví dụ *"v1.1 — refine lượt 1: F01, F03, F04"*.
-3. Có áp bản sửa: tăng version phụ (`SE set D version=… status=draft approved_by=— approved_at=—`), rồi `SE set R status=applied`. Nếu đây là **lượt 1**, báo *"`/clear` rồi `/prd {id} refine` để chạy lượt 2, chỉ soi phần vừa sửa."*
-4. Không áp gì (mọi finding đều bác / hoãn), **hoặc** vừa xong **lượt 2**: `SE set D refined={version hiện tại}` và `SE set R status=done`. Finding `hoãn` thì ghi thêm vào mục **Câu hỏi còn mở** của `D`, kèm chú thích *"(để bước QC)"*.
+1. **Quyết theo nhóm:** trước khi ghi, liệt kê lại **đúng các mã** sẽ nhận quyết định đó, rồi hỏi *"Đúng chưa?"*. Critical không được quyết theo nhóm.
+2. Ghi quyết định vào `R` (`- Quyết định: …`). **Mọi** finding critical / major phải có quyết định khác `chờ`. Còn thiếu thì hỏi lại, tối đa 4 mã mỗi lượt.
+3. Cập nhật dòng của lượt này trong bảng **Tóm tắt** của `R`: số `nhận` · `sửa` · `bác` · `hoãn`. Đây là số đo để đánh giá lớp kiểm chứng: **tỉ lệ bác cao nghĩa là kiểm chứng còn lỏng**.
+4. Finding `nhận` hoặc `sửa`: áp vào `D` trong **một** lần `SE edit`, theo đúng luật của `.fw/core/ref/prd/change.md` (mã mới lấy số kế tiếp, mục bỏ thì gạch ngang, `(nguồn: PRD)`, có đổi luồng thì sửa cả mục User flow). Thêm một dòng Lịch sử thay đổi nêu mã finding, ví dụ *"v1.3 — refine lượt 1: F01, F03, F04"*.
+5. Có áp bản sửa: tăng version phụ (`SE set D version=… status=draft approved_by=— approved_at=—`), rồi `SE set R status=applied`. Nếu đây là **lượt 1**, báo *"`/clear` rồi `/prd {id} refine` để chạy lượt 2, chỉ soi phần vừa sửa."*
+6. Không áp gì (mọi finding đều bác / hoãn), **hoặc** vừa xong **lượt 2**: `SE set D refined={version hiện tại}` và `SE set R status=done`. Finding `hoãn` thì ghi thêm vào mục **Câu hỏi còn mở** của `D`, kèm chú thích *"(để bước QC)"*.

package/templates/prd-refine.md

@@ -15,9 +15,12 @@ updated: {YYYY-MM-DD}
 
 ## Tóm tắt <!-- sec:summary -->
 
-| Lượt | Version | Tìm thấy | Bỏ sau kiểm chứng | critical | major | minor | Kết luận |
-|---|---|---|---|---|---|---|---|
-| 1 | {v} | {n} | {n} | {n} | {n} | {n} | {BLOCKED · NEEDS_REVISION · APPROVED_WITH_MINOR_CHANGES} |
+| Lượt | Version | Thô | Bỏ khi kiểm chứng | Hạ mức | Còn | critical | major | minor | Kết luận | Nhận | Sửa | Bác | Hoãn |
+|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+| 1 | {v} | {n} | {n} | {n} | {n} | {n} | {n} | {n} | {BLOCKED · NEEDS_REVISION · APPROVED_WITH_MINOR_CHANGES} | — | — | — | — |
+
+> Finding sắp theo mức độ (critical → major → minor), rồi theo lăng kính (QA → DEV → SA → Phạm vi). Mã F đánh theo đúng thứ tự đó, nối tiếp qua các lượt.
+> Bốn cột cuối điền khi PO quyết xong. **Tỉ lệ bác cao nghĩa là lớp kiểm chứng còn lỏng.**
 
 ## Lượt 1 — v{version} <!-- sec:round-1 -->
 

package/templates/prd.md

@@ -28,7 +28,25 @@ updated: {YYYY-MM-DD}
 - **Phụ thuộc:** {… hoặc "Không có"}
 - **Ràng buộc áp dụng** (từ `product.md`): {CON-01, CON-03 … hoặc "Không có"}
 
-## 2. Use case <!-- sec:usecases -->
+## 2. User flow <!-- sec:userflow -->
+
+> Các **hành trình** xuyên suốt nhiều UC: actor đi qua những UC nào, rẽ nhánh ở đâu, gặp lỗi thì đi đâu. Nút trong sơ đồ **ghi mã UC**, không chép lại BR.
+> Mỗi UC phải có mặt trong ít nhất một hành trình. Mỗi hành trình phải có ít nhất một nhánh lỗi hoặc ngoại lệ.
+
+| Mã | Hành trình | Actor | Đi qua UC | Điểm vào | Điểm ra |
+|---|---|---|---|---|---|
+| J1 | {Tên hành trình} | ACT-xx | UC-{NNN} → UC-{NNN} | {…} | {…} |
+
+### J1 — {Tên hành trình}
+
+```mermaid
+flowchart TD
+    A["UC-{NNN} {bước}"] --> B{"{điểm rẽ nhánh}"}
+    B -->|{nhánh chính}| C["UC-{NNN} {bước}"]
+    B -->|{nhánh lỗi}| X["{kết quả khi lỗi}"]
+```
+
+## 3. Use case <!-- sec:usecases -->
 
 ### UC-{NNN} — {Tên use case}
 
@@ -53,17 +71,17 @@ updated: {YYYY-MM-DD}
 
 - ✅ UC-{NNN}-AC01. Khi {…} thì {…}. (nguồn: AC1)
 
-## 3. Màn hình <!-- sec:screens -->
+## 4. Màn hình <!-- sec:screens -->
 
 | Màn hình | Thành phần chính | Hành động → kết quả | UC |
 |---|---|---|---|
 | {…} | {…} | {…} | UC-{NNN} |
 
-## 4. Câu hỏi còn mở <!-- sec:open -->
+## 5. Câu hỏi còn mở <!-- sec:open -->
 
 - {… hoặc "Không còn"}
 
-## 5. Lịch sử thay đổi <!-- sec:history -->
+## 6. Lịch sử thay đổi <!-- sec:history -->
 
 | Version | Ngày | Thay đổi |
 |---|---|---|

package/tools/spec_edit.py

@@ -17,6 +17,8 @@ Cách dùng (nội dung truyền qua stdin):
   spec_edit.py section <file> <mã>        in đúng một mục theo mã `<!-- sec:… -->` (vd constraints)
   spec_edit.py upgrade <file>             gắn mã mục cho file theo khuôn cũ (chạy một lần)
   spec_edit.py next-uc <thư mục specs>    in mã UC kế tiếp (quét mọi prd.md)
+  spec_edit.py flowcheck <prd>            kiểm User flow: có sơ đồ, mọi UC có mặt trong một hành trình
+  spec_edit.py create --replace <file>    chỉ cho file tạm trong .fw/tmp/ (kết quả của agent)
   spec_edit.py coverage <epic> <prd>      liệt kê BR / AC của epic chưa được PRD dùng tới
 
 Mã thoát: 0 = thành công · 1 = lỗi dữ liệu (không ghi gì) · 2 = sai cách dùng.
@@ -76,8 +78,15 @@ def stdin_text():
     return sys.stdin.read()
 
 
-def cmd_create(path):
-    if os.path.exists(path):
+def in_tmp(path):
+    parts = os.path.abspath(path).replace("\\", "/").split("/")
+    return any(parts[i] == ".fw" and parts[i + 1] == "tmp" for i in range(len(parts) - 1))
+
+
+def cmd_create(path, replace=False):
+    if replace and not in_tmp(path):
+        fail("--replace chỉ dùng cho file tạm trong .fw/tmp/. File spec thì không bao giờ ghi đè.")
+    if os.path.exists(path) and not replace:
         fail(path + " đã tồn tại — không ghi đè. Dùng `edit` hoặc `set`.")
     text = stdin_text()
     check_keys(file_type(text), [], sec_keys(text), creating=True)
@@ -162,6 +171,38 @@ def undecided_findings(text):
     return out
 
 
+def section_text(text, key):
+    lines = text.split("\n")
+    hs = headings(lines)
+    for n, (i, level, _, k) in enumerate(hs):
+        if k == key:
+            end = next((j for j, lv, _, _ in hs[n + 1:] if lv <= level), len(lines))
+            return "\n".join(lines[i:end])
+    return None
+
+
+def flow_problems(text):
+    """Danh sách vấn đề của mục User flow (rỗng = ổn)."""
+    flow = section_text(text, "userflow")
+    if flow is None:
+        return ["PRD chưa có mục User flow (sec:userflow). Chạy `/prd <EPIC-ID> change thêm User flow`."]
+    problems = []
+    if "```mermaid" not in flow:
+        problems.append("mục User flow chưa có sơ đồ mermaid nào")
+    ucs = sorted(set(UC_HEADING.findall(text)))
+    missing = ["UC-" + n for n in ucs if not re.search(r"UC-%s(?![\d-])" % n, flow)]
+    if missing:
+        problems.append("UC chưa có mặt trong hành trình nào của User flow: " + ", ".join(missing))
+    return problems
+
+
+def cmd_flowcheck(path):
+    problems = flow_problems(read(path))
+    if problems:
+        fail("\n  - ".join([""] + problems))
+    print("User flow đủ — mọi UC đều có mặt trong ít nhất một hành trình")
+
+
 def refine_path(prd_path):
     return os.path.join(os.path.dirname(os.path.abspath(prd_path)), "review", "prd-refine.md")
 
@@ -173,6 +214,9 @@ def guard_refined(path, block):
     if not ref or not ver or ref.group(1) != ver.group(1):
         fail("không đặt được status=approved: bản v%s chưa refine (refined=%s). Chạy `/prd <EPIC-ID> refine` trước."
              % (ver.group(1) if ver else "?", ref.group(1) if ref else "chưa có"))
+    flow = flow_problems(read(path))
+    if flow:
+        fail("không đặt được status=approved:\n  - " + "\n  - ".join(flow))
     rp = refine_path(path)
     pending = undecided_findings(read(rp)) if os.path.isfile(rp) else []
     if pending:
@@ -484,11 +528,16 @@ def main(argv):
     if argv[:1] == ["--check"]:
         print("ok — Python %s" % sys.version.split()[0])
         return
-    if len(argv) < 2 or argv[0] not in ("create", "edit", "set", "pending", "confirm", "next-uc", "coverage", "section", "upgrade"):
+    if len(argv) < 2 or argv[0] not in ("create", "edit", "set", "pending", "confirm", "next-uc", "coverage", "section", "upgrade", "flowcheck"):
         fail(__doc__.split("Cách dùng")[1], 2)
     cmd, path, rest = argv[0], argv[1], argv[2:]
     if cmd == "create":
-        cmd_create(path)
+        if path == "--replace":
+            if not rest:
+                fail("cách dùng: create --replace <file trong .fw/tmp/>", 2)
+            cmd_create(rest[0], replace=True)
+        else:
+            cmd_create(path)
     elif cmd == "edit":
         cmd_edit(path)
     elif cmd == "pending":
@@ -501,6 +550,8 @@ def main(argv):
         cmd_section(path, rest[0])
     elif cmd == "upgrade":
         cmd_upgrade(path)
+    elif cmd == "flowcheck":
+        cmd_flowcheck(path)
     elif cmd == "next-uc":
         cmd_next_uc(path)
     elif cmd == "coverage":