@educa-corp/sdd-framework 0.2.7 → 0.2.9

package/bin/build.js

@@ -215,6 +215,23 @@ for (const { src, dest, filter } of coreMappings) {
 fs.writeFileSync(path.join(CORE_DIR, 'FRAMEWORK_VERSION'), VERSION + '\n', 'utf8');
 console.log(`  ✅ core/FRAMEWORK_VERSION  (v${VERSION})`);
 
+// ── 4. Sync local dogfood .agent/ (dev repo only) ────────────────────────────
+//
+// In THIS framework repo, .agent/ is a pure mirror of core/ used to dogfood the
+// framework on itself. Consumers never run build.js (they get core/ from the npm
+// package and run `--init`), so this block only affects the dev checkout.
+// Guard on existence: only refresh if .agent/ is already present — do NOT create
+// it here (that's --init's job, which also generates .claude/ shortcuts). This is
+// an overlay merge (adds new files like a newly-added module, overwrites changed
+// ones); to prune files removed from core, run `npm run dev` (build + --init).
+const AGENT_DIR = path.join(ROOT, '.agent');
+if (fs.existsSync(AGENT_DIR)) {
+  console.log('');
+  console.log('Syncing local dogfood .agent/ from core/ ...');
+  copyDirToCore(CORE_DIR, AGENT_DIR, null);
+  console.log('  ✅ .agent/ (mirrored from core/)');
+}
+
 // ── Summary ───────────────────────────────────────────────────────────────────
 
 const total = allSucceeded + allFailed;

package/bin/index.js

@@ -46,6 +46,7 @@ const AVAILABLE_MODULES = [
   'java-spring', 'angular', 'react', 'nextjs',
   'dotnet', 'golang', 'php-laravel', 'context-engineering',
   'flutter', 'react-native', 'ios-swiftui', 'android-compose',
+  'phaser-game',
 ];
 
 // Language/framework labels per module (for generated project-context.yaml)
@@ -64,6 +65,7 @@ const MODULE_STACK = {
   'react-native':     { language: 'TypeScript',    framework: 'React Native / Expo' },
   'ios-swiftui':      { language: 'Swift',         framework: 'SwiftUI' },
   'android-compose':  { language: 'Kotlin',        framework: 'Jetpack Compose' },
+  'phaser-game':      { language: 'TypeScript',    framework: 'Phaser 3' },
 };
 
 if (showHelp) {

package/commands/define-product.md

@@ -484,6 +484,27 @@ Các từ như `cờ / flag`, `biến / trường / field`, `giá trị / value`
 **Checklist (dùng ở Quality Checklist của lệnh):** 0 thuật ngữ kỹ thuật/UI (re-render, UI, timeout, spinner, API/endpoint/token…) trong prose nghiệp vụ — đã diễn đạt lại (Nhóm 1) / chuyển Design Spec (Nhóm 2) / bỏ về Tech Docs (Nhóm 3); 0 ẩn dụ dữ liệu cho trạng thái đã có tên nghiệp vụ (cờ/giá trị/đọc-ghi khi là artifact — Nhóm 4) và 0 backtick bọc giá trị nghiệp vụ.
 
 
+---
+
+## Discovery Contract *(đọc trước — quyết định cách xử lý input của PO)*
+
+Lệnh này là **khai vấn (discovery)**, KHÔNG phải thu thập dữ liệu. Giá trị nằm ở **quá trình hỏi** — nó ép PO nói ra những gì chưa viết (edge case, out-of-scope, phụ thuộc, rule mâu thuẫn). Vì vậy:
+
+> **Input của PO là NGUYÊN LIỆU THÔ, KHÔNG phải câu trả lời thay thế phỏng vấn.**
+> Dù PO dán tài liệu dày cỡ nào — **vẫn đi hết Phase 1→7, mọi CHECKPOINT vẫn phải nổ.** TUYỆT ĐỐI KHÔNG coi input là "đã trả lời" rồi nhảy phase. Đây là điểm khác biệt cốt lõi so với các lệnh thu thập dữ kiện (generate-code/architecture "vét nguồn rồi mới hỏi") — ở discovery, **không có luật skip-if-answered.**
+
+**Cơ chế Confirm-vs-Ask** *(áp cho mọi câu hỏi ở Phase 1–6)*:
+- **Item input ĐÃ phủ** → KHÔNG skip. Trình bản nháp đã trích, đánh dấu `🤖 trích từ input` và hỏi PO **xác nhận / sửa / bổ sung**:
+  ```
+  🤖 Trích từ input: "{nội dung AI hiểu được}"
+  → Đúng chưa? Cần sửa/bổ sung gì không?
+  ```
+  Chỉ khi PO chốt mới nâng dấu thành `✅ PO xác nhận` và đi tiếp.
+- **Item input CHƯA phủ** → hỏi mới bình thường.
+- **Nghịch lý độ dày:** input càng dày → GAP tiềm ẩn càng nhiều (đó là thứ PO *chưa nghĩ tới*), nên phần soi hở ở **Phase 3 càng phải sâu**, KHÔNG được rút ngắn. Input dày tạo *ảo giác đủ* — đừng mắc bẫy.
+
+**Phân biệt dấu (bắt buộc, để chống blitz):** trong file output, mỗi dữ kiện mang một trong hai dấu — `✅ PO xác nhận` (PO đã chốt trực tiếp) hoặc `🤖 AI trích — chờ PO chốt`. Một phase CHỈ được đóng khi mọi item của nó mang dấu `✅`. Không tự nâng `🤖`→`✅` thay PO.
+
 ---
 
 ## Phase 0 — Knowledge Sync *(AI tự điền — bối cảnh hệ thống, KHÔNG phải yêu cầu nghiệp vụ; không cần input PO)*
@@ -514,6 +535,8 @@ Lưu bản đồ thuật ngữ này vào file product-definition output dưới
 
 Hỏi **lần lượt từng câu một**, đợi PO trả lời rồi mới hỏi câu kế. Giữ giọng nghiệp vụ, thân thiện; nếu PO lúng túng, đưa một ví dụ ngắn để gợi ý. Tránh hỏi về giải pháp kỹ thuật ở phase này.
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** với câu mà input PO đã phủ, ĐỪNG bỏ qua — trình bản nháp `🤖 trích từ input` rồi hỏi PO xác nhận/sửa/bổ sung; câu chưa phủ thì hỏi mới. Mọi câu 1–8 đều phải có một cú chạm xác nhận của PO trước khi tóm tắt.
+
 1. **Context**: Bối cảnh / lý do vì sao cần feature này?
 2. **Problem**: Vấn đề cụ thể cần giải quyết?
 3. **Goal**: Khi feature chạy ổn, kết quả nghiệp vụ bạn muốn thấy là gì? Mô tả *thành quả*, chưa cần cách làm.
@@ -532,6 +555,8 @@ Sau câu 8 → **tóm tắt lại toàn bộ** cho PO → chờ xác nhận →
 
 ## Phase 2 — User Flow Definition *(CHECKPOINT 2)*
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** input phủ bước nào → trình bản nháp `🤖 trích từ input` để PO xác nhận/sửa; bước nào input im lặng (đặc biệt Edge Cases) → hỏi mới, KHÔNG tự bịa cho đủ bảng.
+
 Hỏi:
 1. **Entry Point**: Người dùng bắt đầu tương tác với feature này ở đâu?
 2. **Flow Steps**: Mô tả từng bước (dùng bảng):
@@ -553,6 +578,14 @@ Xác nhận → ghi `✅ PO xác nhận: Có` → tiếp tục.
 
 Dựa trên Phase 1-2, AI xác định gap và hỏi các câu follow-up. Tiếp tục các vòng cho tới khi không còn Mục chưa giải quyết.
 
+> **BẮT BUỘC chạy ≥1 vòng — KHÔNG được bỏ qua kể cả khi input rất dày.** Đây là nơi bắt GAP mà PO *chưa nghĩ tới*, nên độ dày input KHÔNG làm giảm nhu cầu hỏi — mà **làm tăng**. AI phải chủ động thách thức các **vùng input im lặng**, tối thiểu soi 4 nhóm:
+> 1. **Edge case / luồng lỗi** chưa được nêu (input thiếu, điều kiện không thoả, thao tác đồng thời).
+> 2. **Out-of-scope mơ hồ** — ranh giới ticket chưa rõ, dễ phình phạm vi.
+> 3. **Phụ thuộc liên service** input ngầm giả định nhưng chưa xác nhận (dữ liệu/năng lực từ team khác).
+> 4. **Rule mâu thuẫn / chồng chéo** giữa các phát biểu trong input.
+>
+> Với mỗi item `🤖 AI trích — chờ PO chốt` còn sót từ Phase 1–2 → gom vào đây để PO chốt dứt điểm. **Không được nâng dấu `🤖`→`✅` thay PO.**
+
 ```
 ### Vòng {N}
 | # | Nhóm           | Câu hỏi    | PO trả lời |
@@ -645,6 +678,7 @@ Ghi `{paths.product_definitions_dir}/{TICKET-ID}-{slug}.md` theo `templates/prod
 
 **Cập nhật Metadata theo tiến độ (cho phép resume):**
 - Sau mỗi CHECKPOINT phase được chốt (`✅ PO xác nhận: Có`, hoặc với Phase 3 là `✅ CHECKPOINT 3: Không còn mục tồn đọng`) → cập nhật `Completed Phase` = số phase vừa xong và giữ `Status: in-progress`.
+- **Chống blitz:** một phase CHỈ được tính là chốt khi mọi item của nó mang dấu `✅ PO xác nhận` — nếu còn bất kỳ item `🤖 AI trích — chờ PO chốt` nào, phase đó CHƯA xong, KHÔNG được tăng `Completed Phase`.
 - Khi Phase 7 pass mà không còn GAP → đặt `Completed Phase: 7` và `Status: completed`.
 - Nếu discovery bị ngắt giữa chừng, file vẫn được ghi với `Completed Phase` phản ánh phase cao nhất đã xác nhận — buổi sau resume tiếp từ phase kế tiếp.
 

package/commands/define-product.tmpl

@@ -15,6 +15,27 @@
 
 ---
 
+## Discovery Contract *(đọc trước — quyết định cách xử lý input của PO)*
+
+Lệnh này là **khai vấn (discovery)**, KHÔNG phải thu thập dữ liệu. Giá trị nằm ở **quá trình hỏi** — nó ép PO nói ra những gì chưa viết (edge case, out-of-scope, phụ thuộc, rule mâu thuẫn). Vì vậy:
+
+> **Input của PO là NGUYÊN LIỆU THÔ, KHÔNG phải câu trả lời thay thế phỏng vấn.**
+> Dù PO dán tài liệu dày cỡ nào — **vẫn đi hết Phase 1→7, mọi CHECKPOINT vẫn phải nổ.** TUYỆT ĐỐI KHÔNG coi input là "đã trả lời" rồi nhảy phase. Đây là điểm khác biệt cốt lõi so với các lệnh thu thập dữ kiện (generate-code/architecture "vét nguồn rồi mới hỏi") — ở discovery, **không có luật skip-if-answered.**
+
+**Cơ chế Confirm-vs-Ask** *(áp cho mọi câu hỏi ở Phase 1–6)*:
+- **Item input ĐÃ phủ** → KHÔNG skip. Trình bản nháp đã trích, đánh dấu `🤖 trích từ input` và hỏi PO **xác nhận / sửa / bổ sung**:
+  ```
+  🤖 Trích từ input: "{nội dung AI hiểu được}"
+  → Đúng chưa? Cần sửa/bổ sung gì không?
+  ```
+  Chỉ khi PO chốt mới nâng dấu thành `✅ PO xác nhận` và đi tiếp.
+- **Item input CHƯA phủ** → hỏi mới bình thường.
+- **Nghịch lý độ dày:** input càng dày → GAP tiềm ẩn càng nhiều (đó là thứ PO *chưa nghĩ tới*), nên phần soi hở ở **Phase 3 càng phải sâu**, KHÔNG được rút ngắn. Input dày tạo *ảo giác đủ* — đừng mắc bẫy.
+
+**Phân biệt dấu (bắt buộc, để chống blitz):** trong file output, mỗi dữ kiện mang một trong hai dấu — `✅ PO xác nhận` (PO đã chốt trực tiếp) hoặc `🤖 AI trích — chờ PO chốt`. Một phase CHỈ được đóng khi mọi item của nó mang dấu `✅`. Không tự nâng `🤖`→`✅` thay PO.
+
+---
+
 ## Phase 0 — Knowledge Sync *(AI tự điền — bối cảnh hệ thống, KHÔNG phải yêu cầu nghiệp vụ; không cần input PO)*
 
 AI quét dự án và ghi:
@@ -43,6 +64,8 @@ Lưu bản đồ thuật ngữ này vào file product-definition output dưới
 
 Hỏi **lần lượt từng câu một**, đợi PO trả lời rồi mới hỏi câu kế. Giữ giọng nghiệp vụ, thân thiện; nếu PO lúng túng, đưa một ví dụ ngắn để gợi ý. Tránh hỏi về giải pháp kỹ thuật ở phase này.
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** với câu mà input PO đã phủ, ĐỪNG bỏ qua — trình bản nháp `🤖 trích từ input` rồi hỏi PO xác nhận/sửa/bổ sung; câu chưa phủ thì hỏi mới. Mọi câu 1–8 đều phải có một cú chạm xác nhận của PO trước khi tóm tắt.
+
 1. **Context**: Bối cảnh / lý do vì sao cần feature này?
 2. **Problem**: Vấn đề cụ thể cần giải quyết?
 3. **Goal**: Khi feature chạy ổn, kết quả nghiệp vụ bạn muốn thấy là gì? Mô tả *thành quả*, chưa cần cách làm.
@@ -61,6 +84,8 @@ Sau câu 8 → **tóm tắt lại toàn bộ** cho PO → chờ xác nhận →
 
 ## Phase 2 — User Flow Definition *(CHECKPOINT 2)*
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** input phủ bước nào → trình bản nháp `🤖 trích từ input` để PO xác nhận/sửa; bước nào input im lặng (đặc biệt Edge Cases) → hỏi mới, KHÔNG tự bịa cho đủ bảng.
+
 Hỏi:
 1. **Entry Point**: Người dùng bắt đầu tương tác với feature này ở đâu?
 2. **Flow Steps**: Mô tả từng bước (dùng bảng):
@@ -82,6 +107,14 @@ Xác nhận → ghi `✅ PO xác nhận: Có` → tiếp tục.
 
 Dựa trên Phase 1-2, AI xác định gap và hỏi các câu follow-up. Tiếp tục các vòng cho tới khi không còn Mục chưa giải quyết.
 
+> **BẮT BUỘC chạy ≥1 vòng — KHÔNG được bỏ qua kể cả khi input rất dày.** Đây là nơi bắt GAP mà PO *chưa nghĩ tới*, nên độ dày input KHÔNG làm giảm nhu cầu hỏi — mà **làm tăng**. AI phải chủ động thách thức các **vùng input im lặng**, tối thiểu soi 4 nhóm:
+> 1. **Edge case / luồng lỗi** chưa được nêu (input thiếu, điều kiện không thoả, thao tác đồng thời).
+> 2. **Out-of-scope mơ hồ** — ranh giới ticket chưa rõ, dễ phình phạm vi.
+> 3. **Phụ thuộc liên service** input ngầm giả định nhưng chưa xác nhận (dữ liệu/năng lực từ team khác).
+> 4. **Rule mâu thuẫn / chồng chéo** giữa các phát biểu trong input.
+>
+> Với mỗi item `🤖 AI trích — chờ PO chốt` còn sót từ Phase 1–2 → gom vào đây để PO chốt dứt điểm. **Không được nâng dấu `🤖`→`✅` thay PO.**
+
 ```
 ### Vòng {N}
 | # | Nhóm           | Câu hỏi    | PO trả lời |
@@ -174,6 +207,7 @@ Ghi `{paths.product_definitions_dir}/{TICKET-ID}-{slug}.md` theo `templates/prod
 
 **Cập nhật Metadata theo tiến độ (cho phép resume):**
 - Sau mỗi CHECKPOINT phase được chốt (`✅ PO xác nhận: Có`, hoặc với Phase 3 là `✅ CHECKPOINT 3: Không còn mục tồn đọng`) → cập nhật `Completed Phase` = số phase vừa xong và giữ `Status: in-progress`.
+- **Chống blitz:** một phase CHỈ được tính là chốt khi mọi item của nó mang dấu `✅ PO xác nhận` — nếu còn bất kỳ item `🤖 AI trích — chờ PO chốt` nào, phase đó CHƯA xong, KHÔNG được tăng `Completed Phase`.
 - Khi Phase 7 pass mà không còn GAP → đặt `Completed Phase: 7` và `Status: completed`.
 - Nếu discovery bị ngắt giữa chừng, file vẫn được ghi với `Completed Phase` phản ánh phase cao nhất đã xác nhận — buổi sau resume tiếp từ phase kế tiếp.
 

package/core/FRAMEWORK_VERSION

@@ -1 +1 @@
-0.2.7
+0.2.9

package/core/commands/define-product.md

@@ -484,6 +484,27 @@ Các từ như `cờ / flag`, `biến / trường / field`, `giá trị / value`
 **Checklist (dùng ở Quality Checklist của lệnh):** 0 thuật ngữ kỹ thuật/UI (re-render, UI, timeout, spinner, API/endpoint/token…) trong prose nghiệp vụ — đã diễn đạt lại (Nhóm 1) / chuyển Design Spec (Nhóm 2) / bỏ về Tech Docs (Nhóm 3); 0 ẩn dụ dữ liệu cho trạng thái đã có tên nghiệp vụ (cờ/giá trị/đọc-ghi khi là artifact — Nhóm 4) và 0 backtick bọc giá trị nghiệp vụ.
 
 
+---
+
+## Discovery Contract *(đọc trước — quyết định cách xử lý input của PO)*
+
+Lệnh này là **khai vấn (discovery)**, KHÔNG phải thu thập dữ liệu. Giá trị nằm ở **quá trình hỏi** — nó ép PO nói ra những gì chưa viết (edge case, out-of-scope, phụ thuộc, rule mâu thuẫn). Vì vậy:
+
+> **Input của PO là NGUYÊN LIỆU THÔ, KHÔNG phải câu trả lời thay thế phỏng vấn.**
+> Dù PO dán tài liệu dày cỡ nào — **vẫn đi hết Phase 1→7, mọi CHECKPOINT vẫn phải nổ.** TUYỆT ĐỐI KHÔNG coi input là "đã trả lời" rồi nhảy phase. Đây là điểm khác biệt cốt lõi so với các lệnh thu thập dữ kiện (generate-code/architecture "vét nguồn rồi mới hỏi") — ở discovery, **không có luật skip-if-answered.**
+
+**Cơ chế Confirm-vs-Ask** *(áp cho mọi câu hỏi ở Phase 1–6)*:
+- **Item input ĐÃ phủ** → KHÔNG skip. Trình bản nháp đã trích, đánh dấu `🤖 trích từ input` và hỏi PO **xác nhận / sửa / bổ sung**:
+  ```
+  🤖 Trích từ input: "{nội dung AI hiểu được}"
+  → Đúng chưa? Cần sửa/bổ sung gì không?
+  ```
+  Chỉ khi PO chốt mới nâng dấu thành `✅ PO xác nhận` và đi tiếp.
+- **Item input CHƯA phủ** → hỏi mới bình thường.
+- **Nghịch lý độ dày:** input càng dày → GAP tiềm ẩn càng nhiều (đó là thứ PO *chưa nghĩ tới*), nên phần soi hở ở **Phase 3 càng phải sâu**, KHÔNG được rút ngắn. Input dày tạo *ảo giác đủ* — đừng mắc bẫy.
+
+**Phân biệt dấu (bắt buộc, để chống blitz):** trong file output, mỗi dữ kiện mang một trong hai dấu — `✅ PO xác nhận` (PO đã chốt trực tiếp) hoặc `🤖 AI trích — chờ PO chốt`. Một phase CHỈ được đóng khi mọi item của nó mang dấu `✅`. Không tự nâng `🤖`→`✅` thay PO.
+
 ---
 
 ## Phase 0 — Knowledge Sync *(AI tự điền — bối cảnh hệ thống, KHÔNG phải yêu cầu nghiệp vụ; không cần input PO)*
@@ -514,6 +535,8 @@ Lưu bản đồ thuật ngữ này vào file product-definition output dưới
 
 Hỏi **lần lượt từng câu một**, đợi PO trả lời rồi mới hỏi câu kế. Giữ giọng nghiệp vụ, thân thiện; nếu PO lúng túng, đưa một ví dụ ngắn để gợi ý. Tránh hỏi về giải pháp kỹ thuật ở phase này.
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** với câu mà input PO đã phủ, ĐỪNG bỏ qua — trình bản nháp `🤖 trích từ input` rồi hỏi PO xác nhận/sửa/bổ sung; câu chưa phủ thì hỏi mới. Mọi câu 1–8 đều phải có một cú chạm xác nhận của PO trước khi tóm tắt.
+
 1. **Context**: Bối cảnh / lý do vì sao cần feature này?
 2. **Problem**: Vấn đề cụ thể cần giải quyết?
 3. **Goal**: Khi feature chạy ổn, kết quả nghiệp vụ bạn muốn thấy là gì? Mô tả *thành quả*, chưa cần cách làm.
@@ -532,6 +555,8 @@ Sau câu 8 → **tóm tắt lại toàn bộ** cho PO → chờ xác nhận →
 
 ## Phase 2 — User Flow Definition *(CHECKPOINT 2)*
 
+> **Áp Confirm-vs-Ask (Discovery Contract):** input phủ bước nào → trình bản nháp `🤖 trích từ input` để PO xác nhận/sửa; bước nào input im lặng (đặc biệt Edge Cases) → hỏi mới, KHÔNG tự bịa cho đủ bảng.
+
 Hỏi:
 1. **Entry Point**: Người dùng bắt đầu tương tác với feature này ở đâu?
 2. **Flow Steps**: Mô tả từng bước (dùng bảng):
@@ -553,6 +578,14 @@ Xác nhận → ghi `✅ PO xác nhận: Có` → tiếp tục.
 
 Dựa trên Phase 1-2, AI xác định gap và hỏi các câu follow-up. Tiếp tục các vòng cho tới khi không còn Mục chưa giải quyết.
 
+> **BẮT BUỘC chạy ≥1 vòng — KHÔNG được bỏ qua kể cả khi input rất dày.** Đây là nơi bắt GAP mà PO *chưa nghĩ tới*, nên độ dày input KHÔNG làm giảm nhu cầu hỏi — mà **làm tăng**. AI phải chủ động thách thức các **vùng input im lặng**, tối thiểu soi 4 nhóm:
+> 1. **Edge case / luồng lỗi** chưa được nêu (input thiếu, điều kiện không thoả, thao tác đồng thời).
+> 2. **Out-of-scope mơ hồ** — ranh giới ticket chưa rõ, dễ phình phạm vi.
+> 3. **Phụ thuộc liên service** input ngầm giả định nhưng chưa xác nhận (dữ liệu/năng lực từ team khác).
+> 4. **Rule mâu thuẫn / chồng chéo** giữa các phát biểu trong input.
+>
+> Với mỗi item `🤖 AI trích — chờ PO chốt` còn sót từ Phase 1–2 → gom vào đây để PO chốt dứt điểm. **Không được nâng dấu `🤖`→`✅` thay PO.**
+
 ```
 ### Vòng {N}
 | # | Nhóm           | Câu hỏi    | PO trả lời |
@@ -645,6 +678,7 @@ Ghi `{paths.product_definitions_dir}/{TICKET-ID}-{slug}.md` theo `templates/prod
 
 **Cập nhật Metadata theo tiến độ (cho phép resume):**
 - Sau mỗi CHECKPOINT phase được chốt (`✅ PO xác nhận: Có`, hoặc với Phase 3 là `✅ CHECKPOINT 3: Không còn mục tồn đọng`) → cập nhật `Completed Phase` = số phase vừa xong và giữ `Status: in-progress`.
+- **Chống blitz:** một phase CHỈ được tính là chốt khi mọi item của nó mang dấu `✅ PO xác nhận` — nếu còn bất kỳ item `🤖 AI trích — chờ PO chốt` nào, phase đó CHƯA xong, KHÔNG được tăng `Completed Phase`.
 - Khi Phase 7 pass mà không còn GAP → đặt `Completed Phase: 7` và `Status: completed`.
 - Nếu discovery bị ngắt giữa chừng, file vẫn được ghi với `Completed Phase` phản ánh phase cao nhất đã xác nhận — buổi sau resume tiếp từ phase kế tiếp.