spec-lite 1.4.0 → 1.4.2

package/README.md

@@ -22,11 +22,14 @@ Chạy một lần để bootstrap main artifacts, sau đó vào Integration Pip
 /spec-prd → /spec-sad
                 │
                 ▼
+        /spec-frd [F-XXX]   (tùy chọn — BA author frd.md trước, spec-first)
+                │
+                ▼
         Integration Pipeline
 ```
 
 #### `/spec-prd`
-Tạo hoặc cập nhật `specs/main/prd.md` thông qua interview có cấu trúc. Đồng thời scaffold `specs/main/domain.md` skeleton.
+Tạo hoặc cập nhật `specs/main/prd.md` thông qua interview có cấu trúc. Đồng thời scaffold `specs/main/domain.md` skeleton. Nhận tùy chọn một nguồn baseline (path/@file/paste proposal/BRD) để pre-fill interview.
 
 Sections: Problem Statement · Target Users · Scope · Features · Components · Non-Functional Requirements · Business Constraints
 
@@ -35,6 +38,15 @@ Tạo hoặc cập nhật `specs/main/sad.md`. Yêu cầu `prd.md` và `domain.m
 
 Sections: Architectural Style · System Overview · Tech Stack · Cross-Cutting Concerns · Inter-Service Communication · Infrastructure Overview · Architectural Guardrails
 
+#### `/spec-frd [F-XXX]` *(tùy chọn)*
+BA author `specs/main/feature/{F-XXX}-*/frd.md` trực tiếp qua interview, **trước** khi DEV bắt đầu integration — spec-first ở feature level. Cặp greenfield đối xứng với `/spec-brownfield-feature`. Nhận F-XXX (hoặc chọn từ Feature Index) + tùy chọn nguồn baseline (path/@file/paste).
+
+**Hai gate input (làm chặt):** (1) **Single-feature** — nguồn liên quan đúng 1 feature; xác định >1 → dừng, mô tả rõ lý do tách, redirect `/spec-prd`. (2) **Create-only** — frd.md đã tồn tại → dừng, redirect `/spec-new` (thay đổi feature đã spec đi qua integration để delta cascade + tech/test). Feature mới đơn lẻ chưa có trong Index → skill offer **register một row vào prd Features** rồi author.
+
+Phạm vi hẹp: **chủ yếu frd.md** (+ tối đa một feature row vào prd nếu register). Reference component frd phụ thuộc (Components Used); component cần-nhưng-chưa-có ghi như *candidate* để `/spec-sad`/architect chốt boundary. **KHÔNG** tạo `crd.md`/`cdd.md` — component artifacts sinh ở integration time qua `/spec-new` cascade. Change History operation = `manual`. Nếu bỏ qua bước này, `/spec-new` vẫn tự tạo frd làm fallback.
+
+Sections: Overview · User Flows · Feature Acceptance Criteria · User Stories · Verification Rules · Scope · Dependencies
+
 ---
 
 ## Brownfield — project đã có code
@@ -152,6 +164,7 @@ Pre-flight yêu cầu git working tree clean — rollback dùng `git checkout --
 |---------|--------|
 | `/spec-prd` | `specs/main/prd.md`, `specs/main/domain.md` (skeleton) |
 | `/spec-sad` | `specs/main/sad.md` |
+| `/spec-frd` | `specs/main/feature/{F-XXX}-*/frd.md` *(+ register feature row vào `prd.md` nếu feature mới)* |
 | `/spec-brownfield-init` | `specs/main/prd.md`, `specs/main/domain.md`, `specs/main/sad.md` |
 | `/spec-brownfield-component` | `specs/main/component/{C-XXX}-*/crd.md + cdd.md` |
 | `/spec-brownfield-feature` | `specs/main/feature/{F-XXX}-*/frd.md + fdd.md` |
@@ -165,4 +178,4 @@ Pre-flight yêu cầu git working tree clean — rollback dùng `git checkout --
 | `/review-integration` | *(findings report — không tạo file)* |
 | `/review-everything` | `specs/integrations/{NNN}-{slug}/review-findings.md` *(qua /spec-new)* |
 
-Component và feature artifacts trong greenfield mọc dần qua **cascade proposals** từ integrations — không có skill chuyên biệt để tạo.
+Feature artifacts (`frd.md`) ở greenfield có thể author trước bằng `/spec-frd`, hoặc mọc dần qua **cascade proposals** từ integrations (`/spec-new` fallback). Component artifacts (`crd.md`/`cdd.md`) ở greenfield chỉ mọc qua cascade — không có skill author trực tiếp (`/spec-frd` chỉ reference component, không tạo crd/cdd).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spec-lite",
-  "version": "1.4.0",
+  "version": "1.4.2",
   "description": "Spec-driven development kit for Claude Code",
   "type": "module",
   "bin": {

package/skills/spec-frd/SKILL.md

@@ -0,0 +1,311 @@
+---
+name: spec-frd
+description: Author MỚI frd.md (Feature Requirements Document) trực tiếp ở feature level qua interview. Role BA, chạy trước integration. CREATE-only, đúng một feature/lần: frd đã tồn tại → redirect /spec-new (delta cascade); nguồn nhiều feature → redirect /spec-prd. Nhận F-XXX từ argument (hoặc chọn từ prd Feature Index) + tùy chọn nguồn baseline (path/@file/paste). Chỉ author frd.md (+ register feature row vào prd nếu feature mới) — reference component, KHÔNG tạo crd/cdd.
+---
+
+# spec-frd
+
+## Overview
+
+Author `specs/main/feature/{F-XXX}-{feature-slug}/frd.md` trực tiếp qua interview — **spec-first ở feature level**, do **BA** chạy trước khi bất kỳ integration nào bắt đầu.
+
+`frd.md` là **what to build** của một feature: Overview, User Flows, Feature AC, User Stories, Verification Rules, Scope, Dependencies. Đây là baseline ổn định, **author một lần** — mọi thay đổi sau đó đi qua `/spec-new` (delta cascade).
+
+Skill này là cặp greenfield đối xứng với `/spec-brownfield-feature` (vốn reverse-engineer frd từ code). Khác biệt: `/spec-frd` author *forward* từ interview, không scan code.
+
+**Hai ràng buộc input (làm chặt):**
+1. **Đúng một feature mỗi lần chạy** — xác định > 1 feature → DỪNG, mô tả rõ lý do, redirect `/spec-prd` (Bước 1a).
+2. **CREATE-only** — frd.md đã tồn tại → DỪNG, redirect `/spec-new` để phân tích delta + cascade + downstream (tech/test) (Bước 1c).
+
+**Phạm vi hẹp — chủ yếu frd.md:**
+- ✅ Author frd.md (7 sections) cho **một** feature **chưa có frd**.
+- ✅ *Reference* component frd phụ thuộc (Components Used) + ghi component cần-nhưng-chưa-có như **candidate**.
+- ✅ Nếu feature mục tiêu là feature mới chưa có trong Index → **register một row vào `prd.md > Features`** (side-effect hợp lệ duy nhất lên prd).
+- ❌ KHÔNG tạo/sửa `crd.md`/`cdd.md` — component artifacts ra đời ở integration time qua `/spec-new` cascade.
+- ❌ KHÔNG tạo `fdd.md` (inter-component design) hay `tsd.md` (test) — để skill/role khác lo.
+- ❌ KHÔNG đổi status feature đã có, không đụng sad/domain.
+
+## When to Use
+
+- Greenfield: BA muốn đặc tả **một feature chưa có frd** *trước* khi DEV bắt đầu integration.
+- `prd.md` đã tồn tại (feature có thể đã trong Index, hoặc là feature mới đơn lẻ → skill offer register vào Index).
+
+## When NOT to Use
+
+- `prd.md` chưa có → chạy `/spec-prd` trước.
+- **frd.md đã tồn tại** (thay đổi feature đã spec) → dùng `/spec-new` (delta cascade + tech/test). `/spec-frd` không update frd.
+- **Nguồn trải nhiều feature** → dùng `/spec-prd` để khai Feature Index trước.
+- Brownfield onboarding (reverse-engineer từ code) → dùng `/spec-brownfield-feature`.
+- Muốn thiết kế technical / inter-component → `/spec-tech` (integration) hoặc fdd qua cascade.
+
+---
+
+## Process
+
+### Bước 0: Nạp nguồn yêu cầu (tùy chọn)
+
+Giống `/spec-prd` Bước 0. Xác định có nguồn baseline cho feature không (proposal, mô tả feature, ghi chú họp, wireframe note):
+
+1. **ARGUMENT chứa path / `@file`** → đọc file đó (`.md`/`.txt`/PDF).
+2. **ARGUMENT chứa text dài (paste)** → dùng làm nguồn.
+3. **Không có** → hỏi một lần:
+   > Bạn có tài liệu/nguồn cho feature này không? Nhập **đường dẫn file**, **paste nội dung**, hoặc `không` để interview từ đầu.
+
+Lưu ý: ARGUMENT thường vừa chứa **F-XXX** (Bước 1) vừa có thể kèm path — tách hai phần. Nếu chỉ có F-XXX thì hỏi nguồn như trên.
+
+Có nguồn → trích baseline cho từng section frd (overview, flows, stories, AC, rules, scope, dependencies). Đánh dấu cái nào trích được, cái nào nguồn không đề cập. Áp **quy tắc baseline** giống `/spec-prd`: reuse những gì có; validate; phần thiếu mới hỏi.
+
+---
+
+### Bước 1: Xác định feature
+
+**Precondition:** đọc `specs/main/prd.md`. Nếu không tồn tại / template rỗng → dừng:
+> `prd.md` chưa có nội dung. Hãy chạy `/spec-prd` trước.
+
+`/spec-frd` là skill **CREATE-only, đúng một feature mỗi lần chạy**. Xác định feature mục tiêu qua ba gate — phải pass cả ba mới vào interview.
+
+#### 1a. Single-feature gate — chỉ liên quan đúng 1 feature
+
+Đánh giá ARGUMENT + nguồn baseline mô tả **bao nhiêu feature riêng biệt** — mỗi feature = một outcome/luồng nghiệp vụ độc lập (dùng litmus test trong `/spec-prd`).
+
+- **Xác định > 1 feature** → **DỪNG** và **mô tả rõ lý do** tại sao là nhiều feature, không chỉ báo chung chung:
+  > Mình xác định nguồn này trải **{N} feature** riêng biệt:
+  >   1. {tên feature A} — outcome: {…}; persona: {…}; luồng: {…}
+  >   2. {tên feature B} — outcome: {…}; persona: {…}; luồng: {…}
+  > Lý do tách: {mỗi cái có outcome/luồng độc lập, không phải biến thể của cùng một luồng — chiếu litmus test}.
+  >
+  > `/spec-frd` chỉ author một feature mỗi lần. Hãy chạy `/spec-prd` để khai {N} feature này vào Feature Index trước, rồi chạy `/spec-frd F-XXX` cho từng cái.
+
+  (Nếu có F-XXX chỉ định nhưng nguồn vẫn trải nhiều feature → vẫn dừng và mô tả lý do; không tự ý cắt phần thuộc F-XXX, vì BA cần thấy bức tranh đầy đủ để khai Index.)
+- **Đúng 1 feature** → tiếp 1b.
+
+#### 1b. Resolve feature mục tiêu
+
+- **F-XXX có trong Feature Index** → dùng.
+- **Feature mới — KHÔNG có trong Index** (đúng một) → **offer register**:
+  > Feature "{tên}" chưa có trong prd Feature Index. Mình sẽ thêm vào Index rồi author frd:
+  >   F-{auto next} | {tên} | {mô tả 1 câu} | {priority?} | TODO
+  > Đồng ý? [y / sửa / n]
+  - `y` → auto-pick `F-XXX` = max(seq)+1 trong Index; **giữ lại để Bước 7 ghi row `[NEW]` vào prd + Change History**.
+  - `n` → dừng, gợi ý `/spec-prd` để khai feature trước.
+- **Không có F-XXX và không có nguồn** → hiển thị Feature Index để chọn (chỉ feature **chưa có frd.md**):
+
+```
+Features chưa có frd.md:
+
+  [1] F-001 — Authentication        (High)    [TODO]
+  [3] F-003 — App Browsing & Opt-in (High)    [TODO]
+
+(F-002 đã có frd.md → thay đổi đi qua /spec-new)
+
+Chọn feature để author frd:
+```
+
+#### 1c. Create-only gate — frd.md CHƯA tồn tại
+
+Kiểm tra `specs/main/feature/{F-XXX}-*/frd.md`.
+
+- **Chưa tồn tại** → tiếp Bước 2 (author mới).
+- **Đã tồn tại** → **DỪNG**, redirect `/spec-new`:
+  > frd.md cho {F-XXX} đã tồn tại. Mọi thay đổi feature đã được spec phải đi qua `/spec-new` — skill đó phân tích delta, cascade lên frd/crd/prd/domain, và kéo theo việc kỹ thuật/test (`/spec-tech`, `/spec-test`).
+  > Chạy: `/spec-new {F-XXX}` (hoặc `/spec-new <mô tả thay đổi>`).
+
+  `/spec-frd` **không** update frd đã có — giữ một làn ghi delta duy nhất (`/spec-new`) để đảm bảo traceability và downstream không bị bỏ sót.
+
+---
+
+### Bước 2: Load context
+
+Load:
+- `specs/main/prd.md` — Problem Statement, Target Users (personas), Scope, **row của feature này** trong Feature Index (tên, mô tả, priority), Component Index, **cột ADO** (nếu feature có ticket → lưu lại để spec.md sau này không tạo duplicate).
+- `specs/main/domain.md` — Glossary + Shared Entities liên quan.
+- `specs/main/sad.md` — bảng Components (góc nhìn kiến trúc, để biết C-XXX nào đã có boundary).
+- `specs/main/component/{C-XXX}-*/crd.md` — Public Interface của các component khả năng feature sẽ dùng (nếu đã tồn tại).
+
+Tóm tắt context + surface assumptions:
+
+```
+TỪ PRD & DOMAIN TÔI HIỂU:
+- Feature: {F-XXX — tên — mô tả ngắn từ prd} (priority: {...})
+- Vấn đề tổng: {problem statement ngắn}
+- Personas liên quan: {từ Target Users}
+- Glossary/entities liên quan: {từ domain.md}
+- Components có sẵn có thể dùng: {C-XXX — tên}
+
+ASSUMPTIONS TÔI ĐANG ĐẶT RA:
+1. {scope của feature}
+2. {component feature có thể phụ thuộc}
+→ Sửa lại nếu sai trước khi tiếp tục.
+```
+
+---
+
+### Bước 3: Interview
+
+Hỏi tuần tự, từng phần — không hỏi tất cả cùng lúc. Nếu Bước 0 có nguồn → trình bày baseline đã trích rồi xin confirm/sửa; phần nguồn không đề cập mới hỏi từ đầu.
+
+**Phần 1 — Overview:**
+> Feature này giải quyết vấn đề gì, cho persona nào? (2-3 câu, góc nhìn user/business)
+
+**Phần 2 — User Flows:**
+> User thao tác qua những bước nào để đạt mục tiêu? Có những nhánh edge case / thất bại nào quan trọng?
+> (Mình sẽ vẽ mỗi luồng thành một Mermaid flowchart — happy case + edge cases.)
+
+**Phần 3 — User Stories:**
+> Liệt kê các stories ở cấp feature: "{Persona} muốn {hành động} để {mục tiêu}". Mỗi story có priority (Must/Should/Could) và acceptance criteria (Given/When/Then).
+
+**Phần 4 — Feature Acceptance Criteria:**
+> Có criteria nào áp cho *toàn* feature mà story lẻ không cover? (e2e liên story, cross-story consistency, NFR như performance/accessibility, data & migration)
+> Mỗi cái Given/When/Then, **Then phải đo được**.
+
+**Phần 5 — Verification Rules:**
+> Với mỗi input field trong các stories, mình sẽ suggest 2-4 phương án validation để BA chọn (xem "Verification Rules — quy ước sinh" bên dưới). BA là người quyết định.
+
+**Phần 6 — Scope:**
+> Feature này làm gì (In Scope)? Có gì liên quan nhưng KHÔNG làm (Out of Scope) + lý do?
+
+**Phần 7 — Dependencies:**
+> - **Feature dependencies:** feature này cần feature nào xong trước, hay chạy song song?
+> - **Components Used:** feature này dùng component nào? (Mình sẽ map sang C-XXX có sẵn; component cần-nhưng-chưa-có sẽ ghi như candidate — xem Bước 4.)
+
+Câu trả lời vague → hỏi lại để làm rõ (ngưỡng đo được, field cụ thể, nhánh xử lý).
+
+---
+
+### Bước 4: Xử lý component (mức reference + candidate)
+
+`/spec-frd` **không carve component**. Chỉ làm hai việc:
+
+1. **Component đã có C-XXX** (trong prd Component Index) → ghi vào `Dependencies > Components Used` với vai trò trong feature.
+
+2. **Component feature cần nhưng chưa có** → KHÔNG tạo crd/cdd, KHÔNG tự thêm vào prd Component Index. Thay vào đó:
+   - Ghi trong Components Used với **tên đề xuất** + flag `(candidate — chưa carve)`.
+   - Thêm một mục vào draft **Open Questions** (hoặc note cuối draft) để `/spec-sad`/architect chốt boundary, hoặc `/spec-new` formal-register + tạo crd/cdd ở integration time.
+
+Lý do: giữ **một authority duy nhất** cho việc carve component (architect qua `/spec-sad`, hoặc cascade qua `/spec-new`). BA chỉ khai báo *nhu cầu*, không quyết boundary. (Xem quy tắc Given/Derived trong `/spec-prd`.)
+
+---
+
+### Bước 5: Write — sinh draft
+
+Dùng `.claude/templates/main/feature/frd-template.md` làm skeleton, điền nội dung từ interview.
+
+**ID assignment** (luôn là create — frd mới): US `US-F{NNN}-001+`, Story AC `AC-F{NNN}-001+`, Feature AC `FAC-F{NNN}-001+` (counter độc lập với Story AC), VR `VR-F{NNN}-001+`. `NNN` = số của F-XXX. Flow đánh số từ 1.
+
+**Frontmatter** frd mới: theo template, `status: draft`, `owner: BA`, `feature_id: F-XXX`.
+
+Hiển thị **toàn bộ draft** cho user — chưa ghi file. Kèm danh sách component candidate (nếu có) và VR còn `TBD`.
+
+#### Verification Rules — quy ước sinh
+
+Áp dụng khi sinh section Verification Rules. **Tái dùng nguyên quy ước của `/spec-new`** (xem [spec-new SKILL.md](../spec-new/SKILL.md) → "Verification Rules — quy ước sinh"). Tóm tắt:
+
+- VR là **business decision — BA owns**. Agent đóng vai **option-suggester**, KHÔNG tự assert rule.
+- Mỗi input field → suggest 2-4 phương án validation + luôn có `Custom` và `TBD`.
+- BA chọn → auto-assign `VR-F{NNN}-{seq}`. `TBD` → vẫn assign ID, ghi `TBD` ở cột Rule, list ra cuối draft.
+- **Cấm:** tự điền rule chưa hỏi BA; đưa regex/validator/error message vào bảng (đó là HOW/UI copy); dùng tech type (`varchar(255)`) thay vì semantic type.
+- Heuristic suggest theo field name: xem bảng trong spec-new.
+
+---
+
+### Bước 6: Review — xác nhận với user
+
+> Draft frd trên đã đúng chưa?
+> - User Flows có cover đủ happy + edge case không?
+> - User Stories + AC đo được chưa?
+> - Verification Rules đã confirm với BA chưa (không còn TBD ngoài ý muốn)?
+> - Components Used đúng chưa? Component candidate (nếu có) có hợp lý để chuyển cho /spec-sad không?
+
+Chỉ ghi file sau khi user confirm. Yêu cầu chỉnh → cập nhật draft → hỏi lại.
+
+---
+
+### Bước 7: Save
+
+**7a. Ghi `specs/main/feature/{F-XXX}-{slug}/frd.md`** — tạo thư mục nếu chưa có. Status `draft` (lifecycle riêng của artifact).
+
+Slug feature lấy từ tên trong prd Feature Index, kebab-case (ví dụ F-001 "Authentication" → `F-001-authentication`).
+
+**7b. Append Change History entry** vào `## Change History` cuối frd.md — operation = `manual` (author trực tiếp, không qua integration; cùng quy ước với brownfield skills, theo `conventions.md` §5.5):
+
+```markdown
+### {YYYY-MM-DD} — manual — create
+
+- **All sections**: initial feature authoring qua /spec-frd
+```
+
+(Luôn là `create` — `/spec-frd` không update frd đã có; thay đổi đi qua `/spec-new`.)
+
+**7b'. (Chỉ khi Bước 1b register feature mới)** Ghi row `[NEW]` vào `prd.md > Features`:
+
+```
+F-{XXX} | {tên} | {mô tả 1 câu} | {priority} | TODO
+```
+
+Và append Change History entry vào prd.md (theo `conventions.md` §5.5):
+
+```markdown
+### {YYYY-MM-DD} — manual — update
+
+- **Features**:
+  - [NEW] F-XXX — {tên} (registered qua /spec-frd)
+```
+
+Đây là **side-effect hợp lệ duy nhất** của `/spec-frd` lên prd — thêm một feature row. Việc này atomic với 7a/7b: nếu fail thì rollback cả frd.
+
+**7c. KHÔNG đụng gì khác.** Không đổi status của các feature *đã có* (frd tồn tại ≠ integration bắt đầu; marker "→ frd.md tồn tại" derive từ file existence). Không thêm component vào Index (chỉ candidate). Không tạo crd/cdd/fdd/tsd. Không đụng sad/domain.
+
+**7d. Thông báo kết quả:**
+
+```
+✓ specs/main/feature/{F-XXX}-{slug}/frd.md đã được tạo (status: draft)
+
+{nếu có} Component candidate cần carve (chuyển cho architect / integration):
+  - {tên đề xuất} — {vai trò}
+
+{nếu có} Verification Rules còn TBD:
+  - VR-F{NNN}-{seq} — {field}
+
+Bước tiếp theo:
+  - /spec-tsd F-XXX  → QC bootstrap test spec từ frd này
+  - /spec-new F-XXX  → DEV bắt đầu integration (frd sẽ được consume, crd/cdd sinh qua cascade)
+  {nếu có candidate} - /spec-sad → architect chốt boundary cho component candidate
+```
+
+---
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| "Để /spec-new tự đẻ frd cho nhanh" | frd là *feature requirements* — việc của BA. Để integration đẻ ra = DEV phải đoán yêu cầu. |
+| "BA cứ tạo luôn crd cho component cần" | Carve component là quyết định kiến trúc. BA tạo crd sớm = boundary sai sớm. Chỉ reference. |
+| "Verification rule mình tự điền cho nhanh" | VR là business decision. Agent tự assert = rule sai mà không ai review. |
+| "User Flows vẽ sau cũng được" | Flow buộc phải nghĩ edge case. Không có flow = AC thiếu nhánh thất bại. |
+
+## Red Flags
+
+- frd dùng từ không đo được trong AC ("hoạt động đúng", "nhanh", "đẹp")
+- User Stories không có persona rõ hoặc không có AC
+- Verification Rules tự điền mà chưa hỏi BA
+- Tạo crd.md/cdd.md (vượt phạm vi — đó là integration time)
+- Component candidate không được surface cho architect
+- **Update frd đã tồn tại** thay vì redirect `/spec-new` (vi phạm CREATE-only)
+- Cắt phần thuộc một F-XXX từ nguồn nhiều feature thay vì dừng + mô tả lý do
+
+## Verification
+
+- [ ] `prd.md` tồn tại
+- [ ] **Single-feature gate**: nguồn liên quan đúng 1 feature; nếu >1 đã DỪNG và mô tả rõ lý do tách + redirect `/spec-prd`
+- [ ] **Create-only gate**: frd.md của feature mục tiêu CHƯA tồn tại; nếu đã có đã redirect `/spec-new`
+- [ ] Feature mục tiêu có trong Index, HOẶC feature mới đơn lẻ đã được user đồng ý register (Bước 1b)
+- [ ] frd.md có đủ 7 sections (luôn create mới)
+- [ ] Mỗi User Story có persona + priority + ít nhất 1 AC Given/When/Then
+- [ ] Feature AC dùng ID `FAC-F{NNN}-{seq}` (counter độc lập với `AC-F{NNN}`), Then đo được
+- [ ] Verification Rules đã confirm với BA (không tự assert); không chứa regex/code/error message; semantic type
+- [ ] ID bắt đầu từ 001 (create mới)
+- [ ] Components Used reference C-XXX có sẵn; component mới ghi candidate + surface cho /spec-sad
+- [ ] Nếu register feature mới: prd Features có row [NEW] + Change History entry; status feature đã có KHÔNG đổi
+- [ ] KHÔNG tạo crd/cdd/fdd/tsd; KHÔNG đụng sad/domain
+- [ ] Change History entry operation = `manual` (luôn `create`)
+- [ ] User đã confirm trước khi ghi file

package/skills/spec-prd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-prd
-description: Điền hoặc cập nhật prd.md — Product Requirements Document ở product level. Cũng scaffold domain.md skeleton (glossary placeholder + Shared Entities rỗng). Dùng khi prd.md còn là template rỗng hoặc cần review/cập nhật.
+description: Điền hoặc cập nhật prd.md — Product Requirements Document ở product level. Nhận tùy chọn một nguồn yêu cầu (đường dẫn file/@file hoặc paste proposal/BRD/ghi chú) làm baseline để pre-fill interview. Cũng scaffold domain.md skeleton (glossary placeholder + Shared Entities rỗng). Dùng khi prd.md còn là template rỗng hoặc cần review/cập nhật.
 ---
 
 # spec-prd
@@ -26,8 +26,96 @@ PRD không chứa: tech stack, implementation details, entity schema, glossary,
 
 ---
 
+## Khái niệm: Feature vs Component
+
+Section này là nền tảng để điền **Phần 4 (Features)** và **Phần 5 (Components)**. Đọc trước khi interview.
+
+### Nguyên tắc gốc
+
+**Component là đơn vị ownership; Feature là đơn vị delivery.** Component bền vững theo thời gian; Feature là một luồng nghiệp vụ consume một hoặc nhiều component. Quan hệ giữa hai khái niệm là **N–N** — không mechanical-derive cái này từ cái kia.
+
+### Litmus test — phân loại một mục là Feature hay Component
+
+Chạy qua các phép thử; đa số phiếu nghiêng đâu thì xếp vào đó:
+
+| Phép thử | → Component | → Feature |
+| --- | --- | --- |
+| **Ownership** (quan trọng nhất) | Sở hữu entity + rule + interface | Điều phối/tiêu thụ dữ liệu & rule của thứ khác |
+| **Lifetime** | Xóa hết luồng nghiệp vụ vẫn còn tồn tại | Bỏ đi, không component nào mất gì |
+| **Hướng cắt** | Ngang — một năng lực dùng lại bởi N luồng | Dọc — UI→logic→data cho một luồng |
+| **Đặt tên** | Danh từ hệ thống (`auth`, `payment`) | Luồng nghiệp vụ (`checkout-flow`, `password-reset`) |
+| **Trả lời** | "Phần nào của hệ thống chịu trách nhiệm X?" | "User làm được gì, nhận giá trị gì?" |
+
+### Quy tắc đặt tên (cho cả Feature và Component)
+
+**Goldilocks:** đặt tên ở mức trừu tượng **cao nhất mà vẫn truyền đạt đúng MỘT trách nhiệm/luồng rõ ràng**. Cao hơn → mất boundary; thấp hơn → rò rỉ chi tiết. Tên dùng kebab-case.
+
+**Component — theo năng lực bền vững, không theo công nghệ hiện tại:**
+- ✅ `notification`, `auth`, `file-storage`, `payment-gateway`
+- ❌ Quá cụ thể (rò rỉ impl): `email-sender` (mai thêm SMS/push?), `stripe-client`, `s3-uploader`
+- ❌ Quá mơ hồ (mất boundary): `core`, `utils`, `manager`, `engine`, `service`, `data`
+- Phép thử: *"Mai đổi nhà cung cấp / thêm kênh, tên còn đúng không?"* Không → quá cụ thể.
+
+**Feature — theo outcome của một luồng hoàn chỉnh:**
+- ✅ `user-registration`, `password-reset`, `checkout`
+- ❌ Quá rộng (thành feature area, ôm nhiều luồng): `user-management`, `account`, `admin`
+- ❌ Quá hẹp (chỉ một biến thể của luồng): `register-with-google`, `reset-password-via-sms-otp`
+- Phép thử: *"Đây là MỘT luồng, hay cái ô chứa nhiều luồng?"* Cái ô → quá rộng.
+
+### Định nghĩa một Component
+
+**Một component = một khối có (1) boundary rõ + interface tường minh, và (2) một lý do duy nhất để thay đổi.**
+
+- Tính chất (1) là điều kiện *cần*; (2) là guardrail chống "tầng kỹ thuật" lọt vào. "Tầng controller" có boundary rõ nhưng đổi vì N lý do (auth đổi, payment đổi...) → cohesion bằng 0 → **không** phải component.
+- Áp đúng tiêu chí "một lý do thay đổi" thì ranh giới theo capability/domain sẽ **tự hiện ra** — không cần áp luật "phải chia theo domain" từ ngoài vào.
+- Mỗi component đồng thời có **mặt domain** (`crd.md` — WHAT/contract) và **mặt kỹ thuật** (`cdd.md` — HOW/internal design). Đừng phân loại component thành "domain component" hay "kỹ thuật component" — đó chỉ là mô tả *nguồn* cohesion, không phải luật cấu trúc.
+
+### Component nào khai ở PRD? — Logic Given vs Derived
+
+Feature Index điền **đầy đủ** ở PRD. Component thì **không** — chỉ khai những component có boundary đã *chín*. Độ chín xác định bằng thủ tục quyết định, không cảm tính.
+
+**Litmus gốc:** *"Cùng bộ yêu cầu này, một architect giỏi khác có thể vẽ boundary này khác đi một cách hợp lý không?"* — KHÔNG (bị ép, một cách vẽ) → **Given, khai ở PRD**. CÓ (một lựa chọn đánh đổi) → **Derived, để `/spec-sad`**.
+
+**Thủ tục 3 câu** (YES đầu tiên thắng):
+
+| # | Câu hỏi | Nếu YES |
+| --- | --- | --- |
+| 1. External | Nó bọc/adapt một hệ thống hay bên thứ ba **ngoài codebase** mà ta buộc phải tích hợp? | **Given** → khai PRD (vd `payment-gateway` tích hợp Stripe, `email-service` tích hợp SendGrid) |
+| 2. Mandated-substrate | Nó là nền tảng kỹ thuật dùng chung mà yêu cầu nói rõ phải có, **độc lập với cách carve lõi nghiệp vụ**? | **Given** → khai PRD (vd `auth`, `file-storage`, `notification`) |
+| 3. Còn lại | Boundary phụ thuộc cách carve lõi nghiệp vụ, hoặc phụ thuộc đánh đổi NFR (scale, isolation, consistency, team topology)? | **Derived** → KHÔNG khai, để `/spec-sad` (vd `order`, `pricing`, `inventory`) |
+
+Ranh giới câu 2 vs câu 3 = **"boundary có độc lập với quyết định chia lõi nghiệp vụ không?"** Độc lập → Given; phụ thuộc → Derived.
+
+### Khi input context đã có sẵn feature/component
+
+Input là **baseline, không phải chân lý tuyệt đối**:
+
+- Reuse tên/ID/boundary nếu input đã có → không tự đẻ cấu trúc song song.
+- Vẫn chạy litmus test (phân loại) + Given/Derived để **validate**. Nếu input gọi X là "component" mà nó fail ownership test → flag, đề xuất reclassify thành feature (không im lặng bê nguyên).
+- Component **Derived** do input cung cấp → ghi nhận như *candidate*, chuyển sang `/spec-sad`, **không** nhồi vào Component Index của PRD.
+- Phần input thiếu → mới interview để bù.
+
+---
+
 ## Process
 
+### Bước 0: Nạp nguồn yêu cầu (tùy chọn)
+
+Trước khi interview, xác định có **nguồn yêu cầu** (proposal, BRD, ghi chú họp, draft cũ) để dùng làm baseline không. Thứ tự ưu tiên:
+
+1. **ARGUMENT là path / `@file`** → đọc file đó. Hỗ trợ `.md`, `.txt`, PDF.
+2. **ARGUMENT là text dài (paste trực tiếp)** → dùng luôn làm nguồn.
+3. **Không có ARGUMENT** → hỏi một lần:
+   > Bạn có tài liệu/nguồn yêu cầu nào để mình tham khảo không? Nhập **đường dẫn file**, **paste nội dung**, hoặc `không` để interview từ đầu.
+
+Nếu có nguồn → đọc và **trích baseline** cho từng section PRD (problem, users, scope, features, components, NFR, constraints). Đánh dấu cái nào trích được, cái nào nguồn không đề cập.
+
+Áp **quy tắc baseline** (xem section "Khi input context đã có sẵn feature/component"): reuse tên/ID/boundary; validate feature/component qua litmus + Given/Derived; flag mục phân loại sai; component Derived → candidate cho `/spec-sad`, không nhồi vào Component Index.
+
+Nếu không có nguồn → bỏ qua, interview từ đầu như bình thường.
+
+---
+
 ### Bước 1: Kiểm tra preconditions
 
 Đọc `specs/main/prd.md`:
@@ -79,6 +167,10 @@ PRD không chứa: tech stack, implementation details, entity schema, glossary,
 
 ### Bước 2: Gather — interview requirements
 
+**Nếu Bước 0 đã nạp được nguồn:** interview chuyển từ "hỏi trắng" thành **xác nhận + bù chỗ thiếu**. Với mỗi phần, trình bày baseline đã trích rồi hỏi user confirm/sửa; chỉ những phần nguồn không đề cập mới hỏi từ đầu. Bỏ qua phần nào nguồn đã đủ rõ và user xác nhận.
+
+**Nếu không có nguồn:** interview từ đầu như mô tả bên dưới.
+
 Trước khi hỏi, list ra các assumptions đang tạm thời:
 
 ```
@@ -105,9 +197,15 @@ Sau đó hỏi tuần tự, từng phần một — không hỏi tất cả cùn
 > Hệ thống cần implement những features gì? Mỗi feature gồm: tên ngắn, mô tả 1 câu (làm gì, cho ai), priority (Must/Should/Could).
 > (Đây sẽ là Feature Index mà các FRD sau này sẽ tham chiếu.)
 
-**Phần 5 — Components:**
-> Hệ thống có những thành phần kỹ thuật (component) nào? Mỗi component gồm: tên ngắn (kebab-case, ví dụ `auth`, `payment`), mô tả 1 câu — component chịu trách nhiệm gì.
-> (Đây là Component Index — agent có thể bỏ trống nếu user chưa rõ; component sẽ được thêm dần qua cascade từ integrations sau này.)
+**Phần 5 — Components (chỉ component có boundary Given):**
+> Hệ thống chắc chắn phải tích hợp hệ thống ngoài nào (vd `payment-gateway`, `email-service`), hoặc cần nền tảng kỹ thuật dùng chung nào độc lập với cách carve lõi nghiệp vụ (vd `auth`, `file-storage`, `notification`)?
+> Mỗi component gồm: tên kebab-case + 1 câu mô tả responsibility.
+>
+> Áp **thủ tục Given vs Derived** (xem section "Khái niệm: Feature vs Component" ở trên) cho mỗi ứng viên:
+> - **Given** (trúng câu 1 External hoặc câu 2 Mandated-substrate) → khai vào Component Index.
+> - **Derived** (câu 3 — boundary phụ thuộc cách carve lõi nghiệp vụ hoặc đánh đổi NFR, vd `order`, `pricing`) → **KHÔNG** khai. Để `/spec-sad` chốt, hoặc mọc qua `/spec-new F-XXX` cascade.
+>
+> **KHÔNG** mechanical-derive components từ feature areas (vd: thấy "Pricing" trong yêu cầu → tạo ngay `C-pricing`; đó là Derived). Section này có thể chỉ có 3-6 entries, hoặc thậm chí trống. Đừng cố fill cho đủ.
 
 **Phần 6 — Non-Functional Requirements:**
 > Có yêu cầu về performance, security, availability, scalability không?
@@ -200,8 +298,9 @@ Trước khi kết thúc, kiểm tra:
 - [ ] Problem Statement từ góc nhìn business, không mention tech stack
 - [ ] Mỗi persona có: tên vai trò, mục tiêu, pain point
 - [ ] Out of Scope có ít nhất 1 item với lý do
-- [ ] Features có ít nhất 1 item, mỗi item có ID (F-XXX), tên, mô tả, priority
-- [ ] Components: nếu có item, mỗi item có ID (C-XXX), tên, mô tả ngắn (có thể trống nếu chưa rõ)
+- [ ] Features có ít nhất 1 item, mỗi item có ID (F-XXX), tên, mô tả, priority. Mỗi item pass litmus test (đơn vị delivery, không phải ownership)
+- [ ] Components: mọi entry là **Given** (trúng câu 1 External hoặc câu 2 Mandated-substrate). Không có component **Derived** (boundary phụ thuộc carve lõi nghiệp vụ — thuộc `/spec-sad`). Có thể trống. Mỗi item có ID (C-XXX), tên kebab-case, mô tả 1 câu
+- [ ] Nếu input context có sẵn feature/component: đã reuse làm baseline, đã validate qua litmus + Given/Derived, đã flag mục phân loại sai (nếu có)
 - [ ] Mỗi NFR có target đo được (không phải "nhanh", "bảo mật chung chung")
 - [ ] domain.md tồn tại (đã scaffold skeleton hoặc có nội dung sẵn)
 - [ ] User đã confirm trước khi file được ghi

package/skills/spec-remove/SKILL.md

@@ -0,0 +1,588 @@
+---
+name: spec-remove
+description: Remove một feature toàn diện — tạo removal integration với Code Inventory, Reverse Dependency Audit, reverse-TDD test strategy, và Finalize Plan (move feature artifacts sang specs/removed/ + đóng ADO tickets) như task cuối trong todo.md. Nhận F-XXX làm argument.
+---
+
+# spec-remove
+
+## Overview
+
+Tạo removal integration cho 1 feature đã tồn tại. Output là `spec.md` với đầy đủ:
+
+- **Code Inventory** — code, route, DB, feature flag, config liên quan
+- **Reverse Dependency Audit** — ai còn reference, an toàn xoá hay không
+- **Test Strategy** — reverse-TDD (regression test "thing is gone")
+- **Finalize Plan** — move feature artifacts sang `specs/removed/` + đóng ADO tickets, được DEV chạy như task cuối trong `todo.md`
+- **Changes blocks** — `[REMOVE]` markers cho mọi artifact bị touched
+
+Skill **không** sinh `tech.md` / `plan.md` / `todo.md`. Sau khi `spec.md` được approve, chạy `/spec-tech` → `/plan` → `/build` như flow thường. `spec.md` đủ giàu để 3 skill đó hoạt động không cần modification.
+
+## When to Use
+
+- Một feature đã ship và cần decommission (deprecated, business pivot, replaced by feature khác)
+- Cần xoá toàn bộ code + spec + ADO state một cách an toàn, có audit trail
+- Có nhiều reverse-dep cần được liệt kê và quyết định rõ ràng trước khi xoá
+
+## When NOT to Use
+
+- Chỉ muốn xoá 1 US / 1 AC / 1 VR khỏi feature → dùng `/spec-new` với marker `[REMOVE]` cho item đó. Feature vẫn sống.
+- Feature chưa từng được implement (chỉ có frd.md, chưa có code) → dùng `/spec-new` với block `[REMOVE]` cho frd.md, không cần workflow này.
+- Muốn pause / disable tạm thời mà giữ code → đây không phải removal, dùng feature flag thay vì skill này.
+
+---
+
+## Prerequisites
+
+- `specs/main/feature/{F-XXX}-*/frd.md` tồn tại
+- `specs/main/prd.md` có row của feature trong Feature Index
+- (Optional) `.claude/ado.yaml` cấu hình nếu muốn đóng ADO tickets ở finalize step
+
+---
+
+## Process
+
+### Bước 1: Validate argument
+
+Argument BẮT BUỘC là Feature ID dạng `F-XXX` (3 chữ số). Nếu argument thiếu hoặc sai format → dừng:
+
+```
+spec-remove cần Feature ID. Ví dụ: /spec-remove F-001
+```
+
+Tìm thư mục `specs/main/feature/F-XXX-*/`:
+- 0 matches → báo lỗi feature không tồn tại, dừng.
+- ≥ 2 matches → báo lỗi data inconsistency (nhiều thư mục cùng prefix), dừng.
+- 1 match → tiếp.
+
+Đọc `frd.md` frontmatter:
+- Nếu `status: removed` → hỏi:
+
+```
+F-XXX đã có status `removed`. Bạn muốn:
+  [1] Re-finalize (move artifacts + close ADO lại, idempotent)
+  [2] Tạo removal integration mới (có thể bạn chưa cleanup code lần trước)
+  [3] Hủy
+```
+
+---
+
+### Bước 2: Load context
+
+Đọc các file sau:
+
+**Bắt buộc:**
+- `specs/main/feature/{F-XXX}-*/frd.md` — full content
+- `specs/main/feature/{F-XXX}-*/fdd.md` — nếu tồn tại
+- `specs/main/prd.md` — Feature Index (capture ADO ticket ID cho F-XXX), Component Index, NFR
+- `specs/main/domain.md` — Glossary + Shared Entities (xác định entity nào owned bởi component thuộc F-XXX)
+
+**Components used by F-XXX:**
+
+Trích từ `frd.md` section `Components Used` + `fdd.md` section `Components Touched`. Với mỗi C-YYY:
+- `specs/main/component/{C-YYY}-*/crd.md`
+- `specs/main/component/{C-YYY}-*/cdd.md` — nếu tồn tại
+
+**Reverse dependency scan:**
+
+Với mỗi C-YYY mà F-XXX sử dụng, grep `specs/main/feature/F-*/frd.md` (trừ F-XXX) tìm references tới C-YYY. Mọi feature khác có reference → load `frd.md` của feature đó để hiểu nó dùng C-YYY làm gì.
+
+Output context summary cho user:
+
+```
+F-XXX — {feature title}
+  Status: {Done/In Progress/...}
+  ADO: #{ticket_id} ({current state}) {nếu prd.md có cột ADO}
+
+  Components dùng bởi F-XXX:
+    - C-YYY-{slug} — {role} ({exclusive | shared with F-AAA, F-BBB})
+    - ...
+
+  Reverse-dep features (dùng chung component với F-XXX):
+    ⚠ F-AAA {title} — dùng C-YYY {interface_name}
+    ⚠ F-BBB {title} — dùng C-ZZZ {interface_name}
+    {hoặc} ✓ Không có reverse-dep — F-XXX hoàn toàn cô lập
+
+  Glossary terms từ domain.md tham chiếu trong F-XXX:
+    - {term} {(unique to F-XXX | shared)}
+    - ...
+
+  Shared entities owned bởi components của F-XXX:
+    - {Entity} (Owner: C-YYY) — {used by F-XXX only | also F-AAA}
+    - ...
+```
+
+---
+
+### Bước 3: Interview ngắn
+
+Hỏi 2 câu, tuần tự:
+
+**3.1 — Lý do remove:**
+
+```
+Lý do remove F-XXX? (sẽ ghi vào Change History + ADO closure comment)
+> ___
+```
+
+**3.2 — Removal strategy:**
+
+Dùng `AskUserQuestion`:
+
+```
+Removal strategy:
+  [1] Single-shot — xoá hết trong 1 deploy. Phù hợp khi feature off-traffic, internal-only, không có DB schema lớn.
+  [2] Phased — disable trước (feature flag off + deprecation banner), soak period, sau đó xoá code. Phù hợp khi có DB / external API / traffic gradual.
+  [3] Phased + drop schema riêng — như Phased nhưng tách thêm 1 integration cho DROP TABLE/COLUMN sau khi code đã xoá và observed.
+```
+
+Nếu chọn `[2]` hoặc `[3]` → hỏi soak period (1-2 tuần là baseline):
+
+```
+Soak period giữa các phase (ngày)?
+> ___
+```
+
+Phased và Phased+drop schema → ghi nhận để Bước 6 (sinh draft) có Removal Phases section.
+
+---
+
+### Bước 4: Code Discovery
+
+Mục tiêu: build **Code Inventory** — danh sách code cụ thể sẽ bị xoá.
+
+**Nguồn discovery (kết hợp):**
+
+1. **fdd.md / cdd.md** — nếu artifact có ghi file path / module path cụ thể trong section như "Implementation Notes" → dùng làm seed trực tiếp.
+2. **Component slug** — search filesystem cho directory matching `{C-YYY}-{slug}` (kebab) hoặc camelCase variant.
+3. **Public Interface signatures** — từ `crd.md` Public Interface, lấy function/class/endpoint name → grep codebase.
+4. **Route paths** — từ `frd.md` User Flows / `fdd.md` sequence diagrams, extract API path patterns (`/api/...`) → grep route registrations.
+5. **Owned Entities** — từ `domain.md` Shared Entities (owned bởi component của F-XXX), table name → grep migrations + queries.
+6. **Feature flag names** — nếu được nhắc trong artifact → grep config files.
+7. **Test files** — sau khi xác định module paths, grep `tests/` cho cùng prefix / cùng tên.
+
+**Tools:** `Grep`, `Glob`, `Bash` (`rg`, `find`). Khi không chắc filesystem layout, hỏi user 1 câu: "Codebase root ở `src/` hay project có monorepo structure khác?"
+
+**Output Code Inventory** dạng table, group theo category:
+
+```
+Code Inventory for F-XXX:
+
+  ROUTES / API ENDPOINTS:
+    [1] POST /api/auth/login        → src/routes/auth.ts:12-50
+    [2] POST /api/auth/logout       → src/routes/auth.ts:52-80
+    [3] POST /api/auth/refresh      → src/routes/auth.ts:82-115
+
+  SOURCE MODULES:
+    [4] src/services/auth/          → entire directory (8 files)
+    [5] src/middleware/auth-token.ts
+    [6] src/utils/jwt.ts            → ⚠ also used by F-007 (reverse-dep)
+
+  TESTS:
+    [7] tests/auth/                 → 12 files
+    [8] tests/integration/auth-flow.test.ts
+
+  DATABASE:
+    [9] table `sessions`            → migration drop_sessions.sql cần tạo
+    [10] table `refresh_tokens`     → migration cần tạo
+    [11] users.last_login_at column → ⚠ used by F-007 analytics
+
+  FEATURE FLAGS:
+    [12] ff_new_auth                → src/config/flags.ts:12
+
+  CONFIG / ENV:
+    [13] AUTH_SECRET, AUTH_TTL      → .env.example, src/config/index.ts
+
+  OTHER (best-effort, manual verify):
+    - Grafana dashboard "Auth metrics" — không scan được tự động, BA verify tay
+    - Docs site có section /docs/auth/ — verify tay
+```
+
+Mỗi item có thể là `safe` (xanh) hoặc `⚠ has external ref` (cần quyết định ở Bước 5).
+
+---
+
+### Bước 5: Reverse Dependency Audit
+
+Với mỗi item trong Code Inventory, grep external references (ngoài thư mục chính của F-XXX). Mọi reference `⚠` cần user quyết định.
+
+```
+Reverse-dep audit:
+
+  [6] src/utils/jwt.ts
+      External refs found:
+        - src/services/admin/sessions.ts:34 — imports `verifyJWT`
+        - src/services/api-gateway/auth-check.ts:12 — imports `signJWT`
+
+      Quyết định:
+        [a] Keep file — không xoá src/utils/jwt.ts (chỉ xoá phần exclusive của F-XXX bên trong nếu có)
+        [b] Migrate consumer first — abort removal, tạo integration migration F-007 + api-gateway sang alternative trước
+        [c] Remove anyway — xoá luôn, downstream tự fix (rủi ro cao, cần justify)
+      Chọn: ___
+
+  [11] users.last_login_at column
+      External refs found:
+        - src/analytics/login-tracking.ts:88 — SELECT this column
+      Quyết định: ___
+```
+
+Mọi item `⚠` đều phải có quyết định trước khi sang Bước 6. Nếu user chọn `[b]` cho bất kỳ item nào → dừng skill, instruct:
+
+```
+F-XXX chưa thể remove vì có reverse-dep chưa migrate:
+  - {item} blocked by {consumer}
+
+Tạo integration migration trước:
+  /spec-new "Migrate {consumer} away from {item}"
+
+Sau khi migration deploy xong, chạy lại /spec-remove F-XXX.
+```
+
+---
+
+### Bước 6: Sinh draft spec.md
+
+Xác định slug và NNN giống `/spec-new`:
+- Slug: `remove-{f-xxx-slug}` (ví dụ `remove-f001-authentication`)
+- NNN: max của thư mục hiện có trong `specs/integrations/` + 1, format 3 chữ số.
+
+Output path: `specs/integrations/{NNN}-remove-{f-xxx-slug}/spec.md`
+
+Cấu trúc spec.md:
+
+```markdown
+---
+id: "{NNN}"
+slug: "remove-{f-xxx-slug}"
+title: "Remove {F-XXX} {feature title}"
+features: [{F-XXX}]
+components: [{C-YYY list những component bị touched}]
+status: approved
+removal: true
+created: {YYYY-MM-DD}
+---
+
+## Context
+{tóm tắt frd/fdd/components/reverse-deps đã load ở Bước 2}
+
+## Problem Statement
+{lý do remove từ Bước 3.1 — ghi từ góc nhìn business/product, không phải tech}
+
+## Removal Strategy
+{Single-shot | Phased | Phased + schema drop} — chi tiết theo lựa chọn:
+
+### Phase 1: Disable (chỉ khi Phased)
+- Tắt feature flag `ff_xxx`
+- Deprecation banner trên UI (nếu user-facing)
+- Telemetry warning log mỗi lần feature được hit
+- Soak: {N} ngày, monitor traffic = 0
+
+### Phase 2: Remove code
+- Xoá code per Code Inventory dưới
+- Regression tests (xem Test Strategy)
+
+### Phase 3: Drop schema (chỉ khi Phased + schema drop)
+- Tạo integration riêng sau {N} ngày Phase 2 deployed
+- Migration DROP TABLE / DROP COLUMN
+
+## Code Inventory
+{copy table từ Bước 4, đã loại bỏ các item user quyết định `[a] Keep`}
+
+## Reverse Dependency Audit
+{liệt kê mỗi item ⚠ + quyết định user đã chọn, kèm lý do/justify}
+
+## Test Strategy (Reverse-TDD)
+
+Pattern cho mỗi target:
+
+1. **Baseline check (trước khi xoá):** ghi nhận test hiện có hoặc viết quick smoke test xác nhận thing exists và functional. Mục đích: confirm mental model trước khi xoá.
+
+2. **Delete trong 1 commit:**
+   - Xoá source code
+   - Xoá test files cũ tương ứng
+   - Update import statements
+
+3. **Regression assertion (sau khi xoá):** thêm test khẳng định thing is gone:
+   - Route → assert GET/POST trả 404 (hoặc proper error code)
+   - Exported function/class → assert import fails (compile-time check, không cần runtime test)
+   - DB table/column → migration test confirm DROP applied, query trả error
+   - Feature flag → assert flag key không tồn tại trong config
+
+4. **Full suite run:** mọi test khác phải pass. Nếu có test fail → reverse-dep chưa detect đủ, rollback commit, audit lại.
+
+Regression tests **được giữ lại** trong codebase như guardrail — future-self không vô tình re-add feature đã removed.
+
+## Finalize Plan
+
+Đây là **task cuối** trong todo.md (sẽ được /plan tự nhặt). DEV thực thi sau khi mọi removal task khác xong và đã deploy verify.
+
+### Actions:
+
+1. **Move feature artifacts:**
+   ```bash
+   mkdir -p specs/removed
+   mv specs/main/feature/{F-XXX}-{slug}/ specs/removed/{F-XXX}-{slug}/
+   ```
+
+2. **Append Change History** vào `specs/removed/{F-XXX}-{slug}/frd.md` (nếu file còn tồn tại sau move):
+   ```markdown
+   ### {YYYY-MM-DD} — [{NNN}-remove-{slug}](../../integrations/{NNN}-remove-{slug}/spec.md) — removed
+   - **Feature decommissioned**: moved from specs/main/feature/ to specs/removed/
+   - Reason: {lý do từ Problem Statement}
+   ```
+
+3. **Update prd.md Feature Index:**
+   - Row F-XXX: status → `Removed`
+   - Add note column hoặc inline: `(see specs/removed/{F-XXX}-{slug}/)`
+
+4. **Close ADO tickets** (nếu prd.md có ADO ticket ID cho F-XXX):
+   - Feature ticket → state `Removed`
+   - Tất cả User Story tickets thuộc F-XXX → state `Removed`
+   - Comment trên mỗi ticket: "Decommissioned per integration {NNN}-remove-{slug}. Reason: {lý do}"
+   - Dùng `mcp__azure-devops__wit_update_work_item` (state) + `mcp__azure-devops__wit_add_work_item_comment` (comment)
+   - Nếu ADO state name khác (vd "Closed") → xem `.claude/ado.yaml` hoặc fetch từ `wit_get_work_item_type`
+
+5. **Verify finalize:**
+   - `ls specs/main/feature/ | grep {F-XXX}` → không còn match
+   - `ls specs/removed/{F-XXX}-{slug}/` → tồn tại
+   - prd.md grep `F-XXX` → status `Removed`
+   - ADO ticket fetch → state khớp
+
+## Changes
+<!-- Changes blocks theo format chuẩn của spec-template.md, áp dụng cho mọi artifact bị touched. Xem markers [NEW]/[MODIFY {field}]/[REMOVE] theo conventions §5.5. -->
+
+### prd.md
+**Operation:** update
+**Format reference:** [prd-template.md](../../templates/main/prd-template.md)
+
+#### Features (Feature Index)
+- Row [MODIFY status]: `F-XXX` {current status} → `Removed`
+- {nếu có note column} Row [MODIFY note]: `F-XXX` add note "see specs/removed/"
+
+#### Components (Component Index) — chỉ component exclusive với F-XXX
+- Row [MODIFY status]: `C-YYY` {current status} → `Removed`
+- ... (component shared thì KHÔNG đổi status)
+
+### feature/{F-XXX}-{slug}/frd.md
+**Operation:** update
+**Format reference:** [frd-template.md](../../templates/main/feature/frd-template.md)
+
+<!--
+Đánh dấu mọi item bằng [REMOVE]. File sẽ bị move sang specs/removed/ ở Finalize step
+nhưng cascade content vẫn ghi vào file gốc trước (để Change History entry được apply).
+-->
+
+#### User Stories
+- US-FXXX-001 [REMOVE] — feature decommissioned
+- US-FXXX-002 [REMOVE] — feature decommissioned
+- ... (mọi US)
+
+#### Acceptance Criteria
+- AC-FXXX-* [REMOVE] — feature decommissioned
+
+#### Verification Rules
+- VR-FXXX-* [REMOVE] — feature decommissioned
+
+#### Frontmatter
+- [MODIFY status]: `draft|approved|...` → `removed`
+
+### feature/{F-XXX}-{slug}/fdd.md *(nếu tồn tại)*
+**Operation:** update
+**Format reference:** [fdd-template.md](../../templates/main/feature/fdd-template.md)
+
+#### Flow Sequences
+- [REMOVE] FS-FXXX-* — feature decommissioned
+
+#### Data Models
+- [REMOVE] {model} — feature decommissioned
+
+#### Frontmatter
+- [MODIFY status]: → `removed`
+
+### component/{C-YYY}-{slug}/crd.md *(lặp cho mỗi component bị touched)*
+**Operation:** update
+**Format reference:** [crd-template.md](../../templates/main/component/crd-template.md)
+
+<!--
+Component exclusive với F-XXX:
+- Toàn bộ sections [REMOVE]
+- Frontmatter status → removed
+
+Component shared (vẫn còn feature khác dùng):
+- Chỉ [REMOVE] những Public Interface / Responsibility / Owned Entity
+  chỉ phục vụ F-XXX (đã audit ở Bước 5)
+- Giữ nguyên phần còn lại
+- Frontmatter status KHÔNG đổi
+-->
+
+#### Public Interface
+- {interface} [REMOVE] — only used by F-XXX, no other consumer
+
+#### Owned Entities
+- {Entity} [REMOVE] — exclusive to F-XXX
+
+### domain.md
+**Operation:** update
+**Format reference:** [domain-template.md](../../templates/main/domain-template.md)
+
+#### Glossary
+- {term} [REMOVE] — unique to F-XXX, no other reference
+
+#### Shared Entities
+- {Entity} [REMOVE] — orphan after F-XXX removal, no other component owns
+
+## Out of Scope
+- {Migration của reverse-dep features tới alternative — separate integration nếu có}
+- {Documentation site cleanup — manual task ngoài integration}
+- {Grafana dashboard cleanup — manual task}
+
+## Cascade Summary
+
+| Artifact | Operation | Summary |
+| --- | --- | --- |
+| `prd.md` | update | F-XXX status → Removed; {N} components status → Removed |
+| `feature/F-XXX-*/frd.md` | update | All items [REMOVE]; status → removed; folder move tại Finalize |
+| `feature/F-XXX-*/fdd.md` | update | All items [REMOVE]; status → removed |
+| `component/C-YYY-*/crd.md` | update | All [REMOVE] (exclusive) / {N} items [REMOVE] (shared) |
+| `domain.md` | update | {N} glossary [REMOVE], {N} entity [REMOVE] |
+```
+
+---
+
+### Bước 7: Review — xác nhận với user
+
+Hiển thị toàn bộ draft. Hỏi:
+
+```
+Draft trên đã đúng chưa?
+  - Code Inventory đầy đủ và chính xác?
+  - Reverse-dep audit đã quyết định hết các ⚠?
+  - Removal Strategy phù hợp (single-shot vs phased)?
+  - Finalize Plan đủ steps?
+  - Changes blocks dùng [REMOVE] đúng chỗ (exclusive vs shared)?
+
+Sau khi confirm, agent sẽ auto-apply Changes blocks lên main artifacts.
+File feature artifacts (frd/fdd) KHÔNG bị move ngay — chỉ apply [REMOVE] markers
++ Change History entry. Move sang specs/removed/ là task cuối trong todo.md,
+do /build chạy sau khi mọi deletion task khác xong.
+```
+
+Chỉ tiến hành Bước 8 sau khi user confirm.
+
+---
+
+### Bước 8: Save + Auto-cascade
+
+Giống `/spec-new` Bước 7, nhưng với removal-specific extensions.
+
+**[8.1] Ghi spec.md** với status `approved`, `removal: true` trong frontmatter. Frontmatter `features` chứa F-XXX, `components` chứa list components touched.
+
+**[8.2] Auto-apply Changes blocks** vào main artifacts. Thứ tự: `prd.md` → `domain.md` → `sad.md` → `component/*/crd.md` → `component/*/cdd.md` → `feature/F-XXX-*/frd.md` → `feature/F-XXX-*/fdd.md`.
+
+Áp dụng marker [REMOVE] theo conventions §5.5:
+- Xoá item khỏi artifact, ID không tái sử dụng, không renumber.
+- Khi toàn bộ items trong frd/fdd của F-XXX bị [REMOVE] → đổi frontmatter `status: removed`.
+
+**[8.3] Append Change History entry** vào mọi artifact bị touched (conventions §5.5). Entry format chuẩn:
+
+```markdown
+### {YYYY-MM-DD} — [{NNN}-remove-{slug}](../../integrations/{NNN}-remove-{slug}/spec.md) — update
+
+- **{Section name}**:
+  - [REMOVE] {ID/item} — feature decommissioned ({lý do ngắn})
+```
+
+**[8.4] Side-effects:**
+
+- Trong prd.md: row F-XXX status đổi `Removed` ngay (không chờ finalize). Lý do: spec.md đã approved tức là quyết định removal đã được ký, status reflect quyết định ngay.
+- ADO tickets KHÔNG transition ngay. Chỉ transition khi DEV chạy task Finalize ở `/build`. Lý do: tránh case rollback removal sau khi spec approve nhưng chưa deploy.
+- File feature/F-XXX-*/ KHÔNG move ngay. Lý do giống ADO — chỉ move sau khi code thật đã xoá và verified.
+
+**[8.5] Thông báo kết quả:**
+
+```
+✓ specs/integrations/{NNN}-remove-{f-xxx-slug}/spec.md đã được tạo (status: approved, removal: true)
+
+Auto-cascade applied:
+  ✓ prd.md — F-XXX status → Removed; {N} components status → Removed
+  ✓ domain.md — {N} glossary/entity [REMOVE]
+  ✓ component/C-YYY-*/crd.md — {summary}
+  ✓ feature/F-XXX-*/frd.md — all items [REMOVE], status → removed
+  ✓ feature/F-XXX-*/fdd.md — all items [REMOVE], status → removed
+
+⚠ File feature/F-XXX-*/ vẫn ở specs/main/feature/. Sẽ được move sang specs/removed/ ở task cuối todo.md.
+⚠ ADO tickets giữ nguyên state. Sẽ được close ở task cuối todo.md (cần .claude/ado.yaml).
+
+Bước tiếp theo:
+  /spec-tech     → thiết kế delete order, migration SQL, regression test cases
+  /plan          → break down deletion tasks + finalize task cuối
+  /build         → execute deletion + finalize
+```
+
+**Nếu apply fail** (markers reference ID không tồn tại, reverse-dep audit chưa hoàn tất, file không ghi được) → dừng, báo lỗi cụ thể, **không** ghi spec.md. Yêu cầu user fix draft.
+
+---
+
+## Downstream Integration (informational)
+
+Skill này chỉ sinh `spec.md`. Để biết các skill sau xử lý removal flavor như nào:
+
+- **`/spec-tech`** đọc `spec.md`, thấy `removal: true` + Code Inventory + Test Strategy + Finalize Plan → sinh `tech.md` với:
+  - Section "Delete Order" liệt kê file paths theo Code Inventory
+  - Section "Migration SQL" nếu có DB target (DROP + rollback)
+  - Section "Regression Tests" theo Test Strategy pattern
+  - Section "Finalize Task" passthrough nguyên xi từ spec.md Finalize Plan
+
+- **`/plan`** đọc cả spec.md + tech.md → sinh `plan.md` + `todo.md`. Task cuối todo.md = Finalize task với 5 sub-actions như Finalize Plan của spec.md.
+
+- **`/build`** chạy tuần tự todo.md. Khi tới Finalize task:
+  - Move folder bằng shell mv
+  - Edit prd.md
+  - Append Change History
+  - Gọi ADO API để transition tickets (cần `.claude/ado.yaml` configured)
+  - Verify outputs
+
+Nếu `/spec-tech` hoặc `/plan` hiện tại chưa nhặt được removal flavor → có thể cần update sau (separate work). Trong v1, spec.md đủ rõ ràng để 2 skill đó produce reasonable output kể cả không có removal-awareness explicit.
+
+---
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+| --- | --- |
+| "Grep nhanh, không cần Code Inventory chi tiết" | Inventory sót item = code chết nằm trong repo vô thời hạn. Audit trail mất. |
+| "Reverse-dep nhỏ thôi, xoá luôn rồi fix sau" | Một import dangling phá CI cả team. Audit trước rẻ hơn rollback. |
+| "Feature flag off là xong, không cần xoá code" | Code dead vẫn phải maintain (security patch, dependency upgrade). Xoá hẳn mới sạch. |
+| "Single-shot cho nhanh, soak period làm gì" | Có DB / external traffic mà single-shot = rollback đắt khi phát hiện consumer chưa migrate. |
+| "Skip Finalize, để folder ở main feature là được" | Active dir bị noise. Sau 5 features removed, không phân biệt được active vs dead. |
+
+## Red Flags
+
+- Code Inventory empty hoặc chỉ có 1-2 file cho 1 feature đã ship → discovery chưa đủ rộng, xem lại sources
+- Reverse-dep audit không có ⚠ nào cho component shared → grep chưa đủ kỹ
+- Removal Strategy single-shot nhưng có DB schema lớn hoặc external traffic > 0 → cân nhắc Phased
+- Test Strategy chỉ có "delete code" mà không có regression test → future re-add risk
+- Finalize Plan thiếu ADO closure mà prd.md có ticket ID → audit trail không đầy đủ
+- Changes block frd.md mark [REMOVE] nhưng không đổi `status: removed` trong frontmatter → inconsistent state
+
+## Verification
+
+Trước khi user confirm (Bước 7):
+
+- [ ] Code Inventory liệt kê đủ 7 category (route / module / test / DB / flag / config / other)
+- [ ] Mỗi item ⚠ trong Reverse-dep audit đã có quyết định rõ ràng (a/b/c)
+- [ ] Nếu có item chọn `[b] Migrate first` → skill đã dừng, không tạo spec
+- [ ] Removal Strategy match scale: single-shot cho nhỏ, phased cho lớn
+- [ ] Test Strategy có 4 sub-step: baseline / delete / regression / full-suite
+- [ ] Finalize Plan có 5 actions: move folder / change history / prd update / ADO close / verify
+- [ ] Changes blocks: exclusive component → all [REMOVE]; shared component → chỉ items của F-XXX [REMOVE]
+- [ ] frd.md / fdd.md frontmatter có [MODIFY status] → removed
+
+Sau khi user confirm (Bước 8):
+
+- [ ] spec.md frontmatter `removal: true`
+- [ ] Auto-cascade chạy đúng thứ tự prd → domain → sad → crd → cdd → frd → fdd
+- [ ] Mọi artifact bị touched có Change History entry
+- [ ] prd.md row F-XXX status = Removed (đổi ngay sau approve)
+- [ ] File feature/F-XXX-*/ VẪN ở specs/main/feature/ (chưa move — chỉ move ở Finalize task)
+- [ ] ADO tickets KHÔNG bị transition (chưa close — chỉ close ở Finalize task)
+- [ ] Notification cuối ghi rõ 2 ⚠ về việc folder + ADO chưa được động vào

package/skills-overview.md

@@ -8,8 +8,9 @@ Dùng khi bắt đầu dự án mới chưa có code. Mục tiêu: bootstrap `pr
 
 | Command | Reads | Writes |
 | --- | --- | --- |
-| `/spec-prd` | — | `specs/main/prd.md`, `specs/main/domain.md` *(skeleton)* |
+| `/spec-prd` | — *(tùy chọn: nguồn baseline path/@file/paste)* | `specs/main/prd.md`, `specs/main/domain.md` *(skeleton)* |
 | `/spec-sad` | `prd.md`, `domain.md` | `specs/main/sad.md` |
+| `/spec-frd [F-XXX]` *(tùy chọn)* | `prd.md`, `domain.md`, `sad.md`, `crd(s)` *(+ nguồn baseline)* | `specs/main/feature/{F-XXX}-*/frd.md` *(+ register feature row vào `prd.md` nếu feature mới)* |
 
 ### `/spec-prd`
 
@@ -48,12 +49,36 @@ Nếu `prd.md` chưa có → dừng, yêu cầu chạy `/spec-prd` trước.
 
 ---
 
+### `/spec-frd [F-XXX]` *(tùy chọn)*
+
+BA author `specs/main/feature/{F-XXX}-*/frd.md` trực tiếp qua interview — **spec-first ở feature level**, chạy *trước* khi DEV bắt đầu integration. Cặp greenfield đối xứng với `/spec-brownfield-feature` (vốn reverse-engineer frd từ code).
+
+Nhận F-XXX từ argument (hoặc chọn từ prd Feature Index) + tùy chọn nguồn baseline (path/@file/paste như `/spec-prd`). Yêu cầu `prd.md` tồn tại.
+
+**Hai gate input (làm chặt) — phải pass cả hai mới author:**
+- **Single-feature**: nguồn liên quan **đúng 1 feature**. Xác định > 1 feature → **dừng + mô tả rõ lý do tách** (outcome/luồng/persona của từng cái) → redirect `/spec-prd` để khai Feature Index.
+- **Create-only**: frd.md của feature mục tiêu **chưa tồn tại**. Đã tồn tại → **dừng, redirect `/spec-new`** (thay đổi feature đã spec phải đi qua integration để delta cascade + kéo theo `/spec-tech`/`/spec-test`).
+- Feature mới **đơn lẻ** chưa có trong Index → offer **register một row vào `prd.md > Features`** rồi author.
+
+**Sections template** (7): Overview · User Flows · Feature Acceptance Criteria · User Stories · Verification Rules · Scope · Dependencies
+
+**Phạm vi hẹp — chủ yếu `frd.md`:**
+- Reference component frd phụ thuộc (Components Used → C-XXX có sẵn).
+- Component cần-nhưng-chưa-có → ghi *candidate* + Open Question cho `/spec-sad`/architect chốt boundary.
+- Có thể register **một** feature row vào prd (side-effect hợp lệ duy nhất lên prd). **KHÔNG** tạo `crd.md`/`cdd.md` (sinh ở integration time qua `/spec-new` cascade), không tạo `fdd.md`/`tsd.md`, không đổi status feature đã có, không đụng sad/domain.
+- Change History operation = `manual`. Verification Rules dùng quy ước option-suggester của `/spec-new` (BA owns).
+
+Bỏ qua bước này cũng được — `/spec-new` sẽ tự tạo frd làm fallback khi integration đầu tiên chạm tới feature.
+
+---
+
 ### Thứ tự thực hiện
 
 ```
 /spec-prd → /spec-sad
                 │
                 │ (có thể chạy /scaffold để khởi tạo project structure)
+                │ (tùy chọn /spec-frd [F-XXX] — BA author frd.md trước)
                 │
                 ▼
         → Integration Pipeline
@@ -595,7 +620,7 @@ Cập nhật state đồng loạt cho User Story (và tuỳ chọn Feature) tick
 ## Ghi chú
 
 - Cascade proposals trong `spec.md` và `tech.md` do human review và apply thủ công — không có skill riêng.
-- **Greenfield**: Component và Feature artifacts mọc dần qua cascade từ integrations — không có skill chuyên biệt để tạo.
+- **Greenfield**: Feature artifacts (`frd.md`) có thể author trước bằng `/spec-frd`, hoặc mọc dần qua cascade từ integrations (`/spec-new` fallback). Component artifacts (`crd.md`/`cdd.md`) chỉ mọc qua cascade — `/spec-frd` chỉ reference component, không tạo crd/cdd.
 - **Brownfield**: Component và Feature artifacts được bootstrap bởi `spec-brownfield-component` và `spec-brownfield-feature` — sau đó tiếp tục mọc qua cascade như bình thường.
 - Thứ tự trong một integration: `spec-new` → `spec-tech` → `plan` → `build`.
 - `frontend-design` và `frontend-ui-engineering` được `build` invoke tự động — không cần gọi thủ công.

package/templates/main/feature/frd-template.md

@@ -6,6 +6,7 @@ owner: "{BA}"
 feature_id: "{Feature ID từ PRD Feature Index}"
 referenced_by:
   - conventions.md > 3. Main Artifacts > 3.3 Feature level > frd.md > Cấu trúc
+  - skills/spec-frd/SKILL.md > Process > Bước 5: Write — sinh draft
   - skills/spec-new/SKILL.md > Process > Bước 5: Write — sinh draft > feature/{F-XXX}/frd.md
   - templates/integrations/spec-template.md > Changes > feature/{F-XXX}/frd.md
 ---

package/templates/main/prd-template.md

@@ -35,13 +35,28 @@ Tại sao cần giải quyết bây giờ.
 
 ## Features
 
+Đặt tên feature theo **outcome của một luồng hoàn chỉnh**, kebab-case, đủ khái quát mà vẫn là *một* luồng — không quá rộng (`user-management` là feature area), không quá hẹp (`register-with-google` chỉ là biến thể). ✅ `user-registration`, `password-reset`, `checkout`.
+
 | ID | Feature | Mô tả | Priority | Status |
 | --- | --- | --- | --- | --- |
 | F-001 | {tên feature} | {mô tả ngắn — feature làm gì, cho ai} | High/Medium/Low | TODO/DONE |
 
 ## Components
 
-Các thành phần kỹ thuật của hệ thống — chi tiết về vai trò và thiết kế nằm trong `specs/main/component/{C-XXX}-{component-name}/`.
+Một component = một khối có **boundary rõ + interface tường minh** và **một lý do duy nhất để thay đổi**. Không phân loại component thành "domain" hay "kỹ thuật" — mỗi component đều có mặt domain (`crd.md`) lẫn mặt kỹ thuật (`cdd.md`).
+
+Đặt tên component theo **năng lực bền vững**, không theo công nghệ hiện tại, kebab-case. ✅ `notification`, `auth`, `file-storage`. ❌ quá cụ thể (`email-sender`, `stripe-client`) hoặc quá mơ hồ (`core`, `utils`, `manager`).
+
+Section này **chỉ liệt kê component có boundary _Given_** — tức boundary bị ép từ ngoài, chỉ có một cách vẽ hợp lý. Áp thủ tục:
+- **Câu 1 (External):** bọc/adapt hệ thống ngoài ta buộc phải tích hợp? (vd `payment-gateway` tích hợp Stripe, `email-service` tích hợp SendGrid) → Given, khai ở đây.
+- **Câu 2 (Mandated-substrate):** nền tảng kỹ thuật dùng chung mà yêu cầu bắt buộc, độc lập với cách carve lõi nghiệp vụ? (vd `auth`, `file-storage`, `notification`) → Given, khai ở đây.
+- **Còn lại (Derived):** boundary phụ thuộc cách carve lõi nghiệp vụ hoặc đánh đổi NFR (vd `order`, `pricing`, `inventory`) → **KHÔNG** khai ở đây.
+
+**Component Derived mọc dần qua:**
+- `/spec-sad` — architect lock component boundaries dựa trên full feature index + NFRs
+- `/spec-new F-XXX` cascade — khi analyze 1 feature, discover component mới nếu cần và register vào đây qua Change History
+
+Chi tiết về vai trò và thiết kế nằm trong `specs/main/component/{C-XXX}-{component-name}/`.
 
 | ID | Component | Mô tả ngắn | Status |
 | --- | --- | --- | --- |