@edupia-tutor/spec-driven-docs 0.14.0 → 0.14.2

package/commands/review-tech-docs.tmpl

@@ -1,185 +1,185 @@
 # /review-tech-docs — Review Technical Design Document
 
-**READ-ONLY analysis mode — writes a findings file, does NOT modify the target.**
-**Use `--resume` to apply accepted findings.**
+**Chế độ phân tích READ-ONLY — ghi file findings, KHÔNG sửa target.**
+**Dùng `--resume` để áp dụng các finding được chấp nhận.**
 
 ## Gate
 {{include:steps/gate.md}}
 
-*Note: For this command, the target in Step 1 is a tech-design `.md` file in `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/`.
-If `$ARGUMENTS` contains `--resume` → skip to Resume Mode below.*
+*Lưu ý: Với lệnh này, target ở Bước 1 là một file tech-design `.md` trong `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/`.
+Nếu `$ARGUMENTS` chứa `--resume` → bỏ qua sang Resume Mode bên dưới.*
 
 ## Context
 {{include:steps/context-loader.md}}
 
 ---
 
-## Load Review Materials
+## Nạp tài liệu Review
 
-After loading base context, read the following in order:
+Sau khi nạp context nền, đọc các thứ sau theo thứ tự:
 
-1. **Target tech-doc** — read fully. Extract from header:
+1. **Tech-doc target** — đọc đầy đủ. Trích từ header:
    - `@trace.id` → UC-ID
    - `@trace.domain` → domain
-   - `@trace.prd` → source PRD ticket ID
-   - `@trace.status` → current status (draft / in-review / approved)
+   - `@trace.prd` → ticket ID của PRD nguồn
+   - `@trace.status` → status hiện tại (draft / in-review / approved)
 
-2. **Source feature file** — load `{paths.specs_dir}/{domain}/{prd-slug}/bdd/{UC-ID}*.feature` if exists.
+2. **File feature nguồn** — nạp `{paths.specs_dir}/{domain}/{prd-slug}/bdd/{UC-ID}*.feature` nếu tồn tại.
 
-3. **Other tech-docs in same domain** — list and load all `.md` files in
-   `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/` excluding the target. Used for conflict checking (T4).
+3. **Các tech-doc khác cùng domain** — liệt kê và nạp mọi file `.md` trong
+   `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/` trừ target. Dùng để check conflict (T4).
 
-4. **Architecture reference** — re-confirm CLAUDE.md §2: layer order, architectural rules.
+4. **Tham chiếu kiến trúc** — xác nhận lại CLAUDE.md §2: thứ tự layer, quy tắc kiến trúc.
 
-5. **Core entities** — already loaded in context (Step 6 of context-loader).
+5. **Core entities** — đã nạp trong context (Bước 6 của context-loader).
 
-Derive findings filename:
+Suy ra tên file findings:
 `{paths.refinement_dir}/{uc-id}-tech-review-findings.yaml`
 
 ---
 
 ## Review Dimensions
 
-### T1 — Architecture Alignment *(always CRITICAL if violated)*
+### T1 — Architecture Alignment *(luôn CRITICAL nếu vi phạm)*
 
-Cross-reference the proposed design against CLAUDE.md §2 rules:
+Đối chiếu design đề xuất với quy tắc CLAUDE.md §2:
 
-| Violation type | Severity |
+| Loại vi phạm | Severity |
 |----------------|----------|
-| Controller calls Repository directly (layer skip) | Critical |
-| Business logic in Controller or DTO | Critical |
-| Forbidden pattern from §3 | Critical |
-| Dependency going upstream (Service → Controller DTO) | Critical |
-| Transaction annotation on wrong layer | Major |
-| Missing separation (no Facade when arch requires it) | Major |
-
-For each finding:
+| Controller gọi Repository trực tiếp (skip layer) | Critical |
+| Business logic trong Controller hoặc DTO | Critical |
+| Pattern bị cấm từ §3 | Critical |
+| Phụ thuộc đi ngược upstream (Service → Controller DTO) | Critical |
+| Annotation transaction sai layer | Major |
+| Thiếu tách lớp (không có Facade khi kiến trúc yêu cầu) | Major |
+
+Với mỗi finding:
 ```
-Component: {class or method name}
+Component: {tên class hoặc method}
 Violates:  "{rule text}" (CLAUDE.md §2)
-Fix:       {which layer/component should own this instead}
+Fix:       {layer/component nào nên sở hữu cái này}
 ```
-→ **Not auto-fixable.** Human must decide structural fix. Note required in Review Board.
+→ **Không auto-fix.** Người phải quyết định fix cấu trúc. Bắt buộc note trong Review Board.
 
 ### T2 — Entity Consistency
 
-Using the loaded core-entities catalog:
+Dùng catalog core-entities đã nạp:
 
-| Issue | Severity | Auto-fixable? |
+| Vấn đề | Severity | Auto-fixable? |
 |-------|----------|---------------|
-| Entity mentioned not in core-entities.md | Major | No — human confirms if DTO or domain entity |
-| Field name differs from core-entities.md | Major | Yes — rename to canonical |
-| Relationship described differently | Major | No — human decides |
-| New entity introduced but not in core-entities.md | Minor | No — add to core-entities first |
+| Entity được nhắc nhưng không có trong core-entities.md | Major | No — người confirm là DTO hay domain entity |
+| Tên field khác core-entities.md | Major | Yes — đổi về canonical |
+| Quan hệ được mô tả khác đi | Major | No — người quyết định |
+| Entity mới được đưa ra nhưng chưa có trong core-entities.md | Minor | No — thêm vào core-entities trước |
 
 ### T3 — BDD Traceability
 
-Cross-reference against the source `.feature` file:
+Đối chiếu với file `.feature` nguồn:
 
-| Issue | Severity | Auto-fixable? |
+| Vấn đề | Severity | Auto-fixable? |
 |-------|----------|---------------|
-| Tech-doc proposes behavior not in any BDD scenario | Major | No — create scenario first |
-| Tech-doc contradicts a BDD scenario | Critical | No — resolve conflict first |
-| UC scenario has no corresponding design decision | Minor | Yes — add missing design note |
+| Tech-doc đề xuất behavior không có trong scenario BDD nào | Major | No — tạo scenario trước |
+| Tech-doc mâu thuẫn một scenario BDD | Critical | No — giải quyết conflict trước |
+| Scenario UC không có design decision tương ứng | Minor | Yes — thêm design note còn thiếu |
 
 ### T4 — Domain Conflict Check
 
-Compare against other tech-docs in `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/`:
+So với các tech-doc khác trong `{paths.tech_docs_dir}/{domain}/{prd-slug}/tech-docs/`:
 
-| Issue | Severity | Auto-fixable? |
+| Vấn đề | Severity | Auto-fixable? |
 |-------|----------|---------------|
-| Same endpoint defined with different request/response | Critical | No — human resolves |
-| Same service method with different behavior | Critical | No — human resolves |
-| Entity status transitions differ between docs | Critical | No — human resolves |
-| Overlapping responsibility (both docs claim ownership of same logic) | Major | No — human resolves |
+| Cùng endpoint định nghĩa với request/response khác | Critical | No — người giải quyết |
+| Cùng service method với behavior khác | Critical | No — người giải quyết |
+| Status transition của entity khác nhau giữa các doc | Critical | No — người giải quyết |
+| Trách nhiệm chồng lấn (cả hai doc nhận sở hữu cùng logic) | Major | No — người giải quyết |
 
 ### T5 — Internal Consistency
 
-Within the tech-doc itself:
+Trong nội bộ tech-doc:
 
 | Check | Severity | Auto-fixable? |
 |-------|----------|---------------|
-| Sequence diagram shows different flow than written description | Major | No |
-| API spec return type differs from code sketch | Major | Yes — align one to the other |
-| Section references a component/concept never defined later | Minor | Yes — add definition |
-| Assumption stated but no design addresses it | Minor | Yes — add note or remove assumption |
+| Sequence diagram thể hiện flow khác phần mô tả viết | Major | No |
+| API spec return type khác code sketch | Major | Yes — căn chỉnh cái này theo cái kia |
+| Section tham chiếu một component/concept không bao giờ được định nghĩa sau đó | Minor | Yes — thêm định nghĩa |
+| Assumption được nêu nhưng không design nào xử lý nó | Minor | Yes — thêm note hoặc bỏ assumption |
 
 ### T6 — Structural Completeness
 
-Check all standard sections are present and non-empty:
+Kiểm tra tất cả section chuẩn có mặt và không rỗng:
 
 | Section | Missing severity |
 |---------|-----------------|
 | Header (`@trace.id`, `@trace.prd`, `@trace.domain`, `@trace.status`) | Major |
 | Overview / Context | Major |
-| Architecture Decision with rationale | Major |
-| Component Diagram or Layer Description | Major |
-| Sequence Diagram or Flow Steps | Major |
-| API Contract (if HTTP-facing) | Major |
-| Data Model Changes (if entity changes) | Major |
+| Architecture Decision kèm lý do | Major |
+| Component Diagram hoặc Layer Description | Major |
+| Sequence Diagram hoặc Flow Steps | Major |
+| API Contract (nếu hướng HTTP) | Major |
+| Data Model Changes (nếu entity đổi) | Major |
 | Error Handling Strategy | Major |
 | Open Questions / Assumptions | Minor |
 
-→ All T6 missing-section findings are **auto-fixable**: AI adds skeleton section with prompts.
+→ Mọi finding section-thiếu T6 đều **auto-fixable**: AI thêm skeleton section kèm prompt.
 
 ### T7 — Cross-Team API Contract Review
 
-*Only applies when ALL of the following are true:*
-*1. Source BDD has `@trace.platform: system`.*
-*2. Tech-doc header does NOT have `@trace.api_source: existing`.*
+*Chỉ áp dụng khi TẤT CẢ điều sau đúng:*
+*1. BDD nguồn có `@trace.platform: system`.*
+*2. Header tech-doc KHÔNG có `@trace.api_source: existing`.*
 
-*If `@trace.api_source: existing` → **skip T7 entirely**. Contract đã được PO xác định trong PRD — không có API design mới để đồng thuận.*
+*Nếu `@trace.api_source: existing` → **skip T7 hoàn toàn**. Contract đã được PO xác định trong PRD — không có API design mới để đồng thuận.*
 
-This dimension ensures FE, App, and BE teams all agree on the API contract before implementation starts.
+Dimension này đảm bảo team FE, App, và BE đều đồng thuận API contract trước khi bắt đầu implement.
 
-**Step 1 — Check sign-off status in tech-doc header:**
+**Step 1 — Check status sign-off trong header tech-doc:**
 
-Read the `@trace.sign_off` block in the tech doc header. If absent → add it as a finding (auto-fixable: add skeleton).
+Đọc block `@trace.sign_off` trong header tech doc. Nếu vắng → thêm như một finding (auto-fixable: thêm skeleton).
 
 ```yaml
 # @trace.sign_off:
-#   be_team:  pending    # author — set to "done" when BE satisfied with design
-#   fe_team:  pending    # FE/Web — must confirm contract matches web BDD expectations
-#   app_team: pending    # App — must confirm contract matches app BDD expectations (if applicable)
-#   sa:       pending    # SA/Tech Lead — final approval
+#   be_team:  pending    # author — set "done" khi BE hài lòng với design
+#   fe_team:  pending    # FE/Web — phải confirm contract khớp expectation của web BDD
+#   app_team: pending    # App — phải confirm contract khớp expectation của app BDD (nếu áp dụng)
+#   sa:       pending    # SA/Tech Lead — approval cuối
 ```
 
 **Step 2 — Contract vs BDD cross-check:**
 
-Load the web and app BDDs for this TICKET-ID (from `{paths.specs_dir}/{domain}/{prd-slug}/bdd/web/` and `{paths.specs_dir}/{domain}/{prd-slug}/bdd/app/` in the spec submodule or spec repo).
+Nạp web và app BDD cho TICKET-ID này (từ `{paths.specs_dir}/{domain}/{prd-slug}/bdd/web/` và `{paths.specs_dir}/{domain}/{prd-slug}/bdd/app/` trong spec submodule hoặc spec repo).
 
-For each platform BDD, verify the tech doc's API contract satisfies the BDD's `Then` clauses:
+Với mỗi platform BDD, kiểm tra API contract của tech doc có thoả các mệnh đề `Then` của BDD không:
 
 | Check | Severity |
 |---|---|
-| Response fields in API contract don't cover what web BDD `Then` expects | Critical |
-| Response fields in API contract don't cover what app BDD `Then` expects | Critical |
-| Error response shape doesn't match what platform BDDs expect | Major |
-| System BDD `@system.resolution` annotation contradicts the API contract design | Critical |
+| Field response trong API contract không phủ những gì web BDD `Then` mong | Critical |
+| Field response trong API contract không phủ những gì app BDD `Then` mong | Critical |
+| Shape error response không khớp những gì các platform BDD mong | Major |
+| Annotation `@system.resolution` của System BDD mâu thuẫn với design API contract | Critical |
 
-**Step 3 — Pending sign-off report:**
+**Step 3 — Report sign-off pending:**
 
-After the review, list which sign-offs are still `pending`:
+Sau review, liệt kê các sign-off còn `pending`:
 
 ```
-⏳ Pending sign-offs before tech docs can be approved:
-  fe_team  — FE/Web team must confirm API contract matches web BDD expectations
-  app_team — App team must confirm API contract matches app BDD expectations
-  sa       — SA/Tech Lead final approval
+⏳ Sign-off pending trước khi tech docs được approve:
+  fe_team  — team FE/Web phải confirm API contract khớp expectation web BDD
+  app_team — team App phải confirm API contract khớp expectation app BDD
+  sa       — SA/Tech Lead approval cuối
 
-Once sign-offs are collected → update @trace.sign_off in tech doc header, then re-run /review-tech-docs.
-Tech docs cannot be set to "approved" while any required sign-off is pending.
+Khi thu đủ sign-off → cập nhật @trace.sign_off trong header tech doc, rồi chạy lại /review-tech-docs.
+Tech docs không thể set "approved" khi còn bất kỳ sign-off bắt buộc nào pending.
 ```
 
 **Approval gate:**
-- If `be_team: done` AND `fe_team: done` AND `app_team: done` (or N/A) AND `sa: done` → tech docs may be set to `approved`
-- Otherwise → `@trace.status` stays `in-review` — `generate-code` is blocked
+- Nếu `be_team: done` VÀ `fe_team: done` VÀ `app_team: done` (hoặc N/A) VÀ `sa: done` → tech docs có thể set `approved`
+- Ngược lại → `@trace.status` giữ `in-review` — `generate-code` bị chặn
 
 ---
 
-## Write Findings File
+## Ghi File Findings
 
-After running all checks, write findings to `{paths.refinement_dir}/{uc-id}-tech-review-findings.yaml`:
+Sau khi chạy hết các check, ghi findings vào `{paths.refinement_dir}/{uc-id}-tech-review-findings.yaml`:
 
 ```yaml
 source_file: "{absolute path to tech-doc}"
@@ -188,25 +188,25 @@ domain: "{domain}"
 generated_at: "{ISO datetime}"
 review_type: "tech-design"
 status: "pending_review"
-is_system_bdd: {true | false}  # true if source BDD has @trace.platform: system
+is_system_bdd: {true | false}  # true nếu BDD nguồn có @trace.platform: system
 
-sign_off:                       # only present when is_system_bdd: true
-  be_team:  pending             # read from @trace.sign_off in tech-doc header
+sign_off:                       # chỉ có khi is_system_bdd: true
+  be_team:  pending             # đọc từ @trace.sign_off trong header tech-doc
   fe_team:  pending
-  app_team: pending             # "n/a" if project has no app platform
+  app_team: pending             # "n/a" nếu dự án không có platform app
   sa:       pending
-sign_off_gate: blocked          # blocked | ready — "ready" only when all required are "done"
+sign_off_gate: blocked          # blocked | ready — "ready" chỉ khi tất cả bắt buộc là "done"
 
 findings:
   - id: "F001"
     check_id: "T1"           # T1–T7
     severity: "critical"     # critical | major | minor
-    section: "{section heading or component name where issue was found}"
-    uc_id: "{UC-ID}"         # same as top-level uc_id (the UC this tech-doc designs)
-    quote: "{verbatim snippet copied EXACTLY from the tech-doc at the issue location, ≤120 chars}"
-    finding: "{clear description of the violation or gap}"
-    suggestion: "{specific fix — AI applies this in --resume if accepted}"
-    auto_fixable: false      # true = AI can apply; false = human must write decision in note
+    section: "{section heading hoặc tên component nơi tìm thấy lỗi}"
+    uc_id: "{UC-ID}"         # giống uc_id top-level (UC mà tech-doc này thiết kế)
+    quote: "{trích đoạn nguyên văn copy CHÍNH XÁC từ tech-doc tại vị trí lỗi, ≤120 ký tự}"
+    finding: "{mô tả rõ ràng vi phạm hoặc gap}"
+    suggestion: "{bản fix cụ thể — AI áp dụng khi --resume nếu được chấp nhận}"
+    auto_fixable: false      # true = AI áp dụng được; false = người phải ghi quyết định trong note
     status: "pending"        # pending | accepted | modified | rejected | deferred
 
 summary:
@@ -218,82 +218,82 @@ summary:
   sign_off_gate: "{blocked — pending: fe_team, app_team, sa | ready}"
 ```
 
-> **Locator fields (`quote` + `uc_id`) — required for Review Board source-jump.**
-> For every finding, copy a short **verbatim** `quote` straight from the tech-doc at the exact spot
-> the issue occurs — do NOT paraphrase; it is matched against the document to locate the line.
-> These let a reviewer click a finding in the Review Board and jump to the precise source location.
+> **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ừ tech-doc 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.
+> Field này cho phép reviewer click một finding trong Review Board và nhảy tới đúng vị trí nguồn.
 
 ## Report
 
 {{include:steps/report-footer.md}}
 
 ```
-/review-tech-docs Complete — {target file}
+/review-tech-docs Hoàn tất — {target file}
 UC: {UC-ID} | Domain: {domain}
 Findings: {total} | 🔴 Critical: {N} | 🟡 Major: {N} | 🟢 Minor: {N}
 Auto-fixable: {N} | Needs human decision: {N}
 
-Sign-off gate (system BDD only):
+Sign-off gate (chỉ system BDD):
   be_team  : {done | pending}
   fe_team  : {done | pending}   ← {name / "needs sign-off" }
   app_team : {done | pending | n/a}
   sa       : {done | pending}
   Gate     : {🔒 BLOCKED — pending: fe_team, sa | ✅ READY}
 
-Findings file: {paths.refinement_dir}/{uc-id}-tech-review-findings.yaml
-Next: Open in Review Board → Accept/Modify/Reject each finding
-      Then run: /review-tech-docs --resume {tech-design-file}
-      After all sign-offs collected → update @trace.sign_off in tech doc, re-run review
+File findings: {paths.refinement_dir}/{uc-id}-tech-review-findings.yaml
+Next: Mở trong Review Board → Accept/Modify/Reject từng finding
+      Rồi chạy: /review-tech-docs --resume {tech-design-file}
+      Sau khi thu đủ sign-off → cập nhật @trace.sign_off trong tech doc, chạy lại review
 ```
 
 ---
 
-## Resume Mode — Apply Accepted Findings
+## Resume Mode — Áp dụng các Finding được chấp nhận
 
-*Triggered when `$ARGUMENTS` contains `--resume`.*
-*Example: `/review-tech-docs --resume {paths.tech_docs_dir}/payment/{prd-slug}/tech-docs/PAY-UC1-tech-design.md`*
+*Kích hoạt khi `$ARGUMENTS` chứa `--resume`.*
+*Ví dụ: `/review-tech-docs --resume {paths.tech_docs_dir}/payment/{prd-slug}/tech-docs/PAY-UC1-tech-design.md`*
 
-### Phase 1 — Read accepted findings
+### Phase 1 — Đọc các finding được chấp nhận
 
-1. Derive findings file from target: `{paths.refinement_dir}/{uc-id}-tech-review-findings.yaml`
-2. Read the file. Collect findings where `status: "accepted"` or `status: "modified"`.
-3. If none → report "No accepted findings. File unchanged." and stop.
+1. Suy ra file findings từ target: `{paths.refinement_dir}/{uc-id}-tech-review-findings.yaml`
+2. Đọc file. Gom các finding có `status: "accepted"` hoặc `status: "modified"`.
+3. Nếu không có → báo "No accepted findings. File unchanged." và dừng.
 
-### Phase 2 — Apply fixes
+### Phase 2 — Áp dụng fix
 
-Apply in order: critical → major → minor.
+Áp dụng theo thứ tự: critical → major → minor.
 
-| check_id | What to do |
+| check_id | Làm gì |
 |----------|-----------|
-| T1 (Architecture) | Apply the structural fix from finding note — move logic to correct layer, update component description |
-| T2 (Field name) | Rename field to canonical name from core-entities.md throughout the document |
-| T3 (Missing design note) | Add design decision note for the uncovered scenario |
-| T5 (Internal inconsistency) | Align the conflicting sections to the decision stated in the note |
-| T6 (Missing section) | Add skeleton section with placeholder prompts for the tech lead to fill |
+| T1 (Architecture) | Áp dụng fix cấu trúc từ note finding — chuyển logic về đúng layer, cập nhật mô tả component |
+| T2 (Tên field) | Đổi field về tên canonical từ core-entities.md xuyên suốt tài liệu |
+| T3 (Thiếu design note) | Thêm design decision note cho scenario chưa phủ |
+| T5 (Internal inconsistency) | Căn chỉnh các section mâu thuẫn theo quyết định nêu trong note |
+| T6 (Thiếu section) | Thêm skeleton section với prompt placeholder cho tech lead điền |
 
-**T1, T2, T4 findings with `auto_fixable: false`:** require a human-written resolution in the
-Review Board "Modify" note. Apply exactly what the note says. Do not invent the fix.
+**Finding T1, T2, T4 có `auto_fixable: false`:** cần một resolution do người viết trong
+note "Modify" của Review Board. Áp dụng đúng những gì note nói. Đừng bịa fix.
 
-### Phase 3 — Update header + TSV + Report
+### Phase 3 — Cập nhật header + TSV + Report
 
-Edit the tech-doc file directly:
-1. Find `@trace.revision:` in the header — increment its integer value by 1.
-2. Find `@trace.status:` in the header:
-   - If sign_off_gate = `ready` (all sign-offs done) → set to `approved`
-   - Otherwise → set to `in-review` (blocks `/generate-code`)
-3. If `@trace.sign_off` block is absent and this is a system BDD tech doc → add it with all values `pending`.
+Sửa file tech-doc trực tiếp:
+1. Tìm `@trace.revision:` trong header — tăng giá trị integer lên 1.
+2. Tìm `@trace.status:` trong header:
+   - Nếu sign_off_gate = `ready` (tất cả sign-off done) → set `approved`
+   - Ngược lại → set `in-review` (chặn `/generate-code`)
+3. Nếu block `@trace.sign_off` vắng và đây là tech doc system BDD → thêm nó với tất cả giá trị `pending`.
 
-Write both changes to the file.
+Ghi cả hai thay đổi vào file.
 
-Then update `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv` — pick the column by which tech-doc was reviewed (read the filename):
-- **BE contract** (`{UC-ID}-tech-design.md`) → set `tech_doc_revision` to the new `@trace.revision` integer for all rows of this UC.
-- **FE tech-design** (`{UC-ID}-tech-design-{platform}.md`) → set `fe_tech_doc_revision` instead, for the rows of this UC on that platform (leave `tech_doc_revision` untouched).
-- Set `last_updated` to today's date (`YYYY-MM-DD`) for all rows of this UC.
+Rồi cập nhật `{paths.trace_dir}/{domain}/{prd-slug}/{UC-ID}.tsv` — chọn cột theo tech-doc nào được review (đọc tên file):
+- **BE contract** (`{UC-ID}-tech-design.md`) → set `tech_doc_revision` thành integer `@trace.revision` mới cho mọi row của UC này.
+- **FE tech-design** (`{UC-ID}-tech-design-{platform}.md`) → set `fe_tech_doc_revision` thay vì cái kia, cho các row của UC này trên platform đó (giữ nguyên `tech_doc_revision`).
+- Set `last_updated` thành ngày hôm nay (`YYYY-MM-DD`) cho mọi row của UC này.
 
-Print the report after all file writes are complete.
+In report sau khi hoàn tất mọi lần ghi file.
 
 ```
-/review-tech-docs --resume Applied — {target file}
+/review-tech-docs --resume Đã áp dụng — {target file}
 UC: {UC-ID}
 
 Applied  : {N} findings ({critical} critical, {major} major, {minor} minor)
@@ -306,12 +306,12 @@ Changes:
 Revision : {old} → {new}
 Status   : {approved | in-review}
 
-Sign-off : {✅ All done — status set to approved
-           | 🔒 Pending: fe_team, sa — status set to in-review
-              Update @trace.sign_off in tech doc when each team confirms, then re-run /review-tech-docs}
+Sign-off : {✅ Tất cả done — status set approved
+           | 🔒 Pending: fe_team, sa — status set in-review
+              Cập nhật @trace.sign_off trong tech doc khi mỗi team confirm, rồi chạy lại /review-tech-docs}
 
-Re-run /review-tech-docs {file} to confirm 0 remaining critical findings.
-Next: {/generate-code {feature-file}  ← only if status = approved
-      | Collect pending sign-offs → update @trace.sign_off → re-run /review-tech-docs}
-      → if the tech-doc lives in the shared spec repo: commit + push it to the spec submodule so FE/App `/sync` the updated contract
+Chạy lại /review-tech-docs {file} để xác nhận 0 finding critical còn lại.
+Next: {/generate-code {feature-file}  ← chỉ khi status = approved
+      | Thu các sign-off pending → cập nhật @trace.sign_off → chạy lại /review-tech-docs}
+      → nếu tech-doc sống trong spec repo dùng chung: commit + push lên spec submodule để FE/App `/sync` contract đã cập nhật
 ```