@torus-engineering/tas-kit 1.10.0 → 1.12.0

package/.claude/commands/tas-apitest.md

@@ -1,143 +0,0 @@
-# /tas-apitest $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Generate .NET xUnit automation test project cho REST API từ API Test Spec file (Markdown).
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Đọc toàn bộ API Test Spec file trước khi generate bất kỳ test nào |
-| **Always** | Tổ chức tests theo API version — mỗi version một folder riêng |
-| **Always** | Append-only: không sửa files trong version folder cũ đã tồn tại |
-| **Always** | URL và credentials ra `appsettings.json` — không hardcode trong code |
-| **Always** | XML doc comment trên mỗi test method |
-| **Ask** | Khi test spec không rõ expected response schema |
-| **Never** | Sửa hoặc xóa test files của version cũ hơn |
-| **Never** | Hardcode base URL, API key, credentials trong test code |
-| **Never** | Bỏ qua error path — mỗi endpoint cần ≥1 happy path + ≥1 error path |
-
-## Hành động
-
-### Bước 1 — Locate Input
-
-`$ARGUMENTS` là path đến API Test Spec file: `docs/tests/API-Test-Spec-{slug}.md`.
-
-Nếu không có → hỏi user:
-```
-Nhập path đến API Test Spec file (vd: docs/tests/API-Test-Spec-users.md)
-```
-
-### Bước 2 — Parse API Test Spec
-
-Đọc `.claude/rules/csharp/api-testing.md` để nắm convention trước khi generate.
-
-Từ API Test Spec file, thu thập:
-- API version
-- Endpoints với method, path, params
-- Test cases theo từng endpoint (TC-XXX)
-- Request/response schemas
-- Auth requirements
-- Test data requirements
-- Setup/teardown notes
-
-### Bước 3 — Detect Existing Test Project
-
-Glob tìm `**/ApiTests/*.csproj`, `**/Api.Tests/*.csproj`, `**/IntegrationTests/*.csproj`.
-
-- **Tìm thấy**: Đọc framework đang dùng (xUnit/NUnit/MSTest), glob `v*/` folders để biết versions đã có.
-- **Không tìm thấy**: Tạo mới tại `tests/ApiTests/` với xUnit + FluentAssertions (per `csharp/testing.md`).
-
-### Bước 4 — Get API Version from Spec
-
-Đọc version từ API Test Spec file (tìm frontmatter `api_version` hoặc section headers `## v{N}`).
-
-Version folder: lowercase, không có dot — `v1`, `v2` (không phải `v1.0`).
-
-### Bước 5 — Generate Infrastructure (chỉ khi tạo project mới)
-
-Đọc `.claude/rules/csharp/api-testing.md` section **Project Structure** và **Config Pattern** để generate:
-- `ApiTests.csproj` với packages chuẩn
-- `appsettings.json` (base) + `appsettings.Test.json` + `appsettings.Staging.json` với values từ spec
-- `Shared/TestBase.cs` — load config, HttpClient, helper methods
-- `Shared/ApiTestSettings.cs` — strongly typed settings
-- `.gitignore` cho `appsettings.*.local.json`
-
-### Bước 6 — Generate Test Classes từ Spec
-
-Nhóm endpoints theo resource. Mỗi nhóm → `tests/ApiTests/{version}/{Resource}ApiTests.cs`.
-
-Với mỗi test case (TC-XXX) trong spec:
-1. Đọc test case details
-2. Map sang test method với naming: `{HttpMethod}_{Resource}_Returns{Status}_When{Condition}`
-3. Generate XML doc từ test case title
-4. Generate assertions từ expected response
-5. Add AC reference comment nếu có
-
-Test class header comment:
-```csharp
-// ============================================================
-// {Resource} API Tests — v{N}
-// Spec: docs/tests/API-Test-Spec-{slug}.md
-// Generated: {YYYY-MM-DD}
-// Story: {ID} (if applicable)
-// APPEND-ONLY: không sửa methods đã tồn tại.
-// ============================================================
-```
-
-### Bước 7 — Append-Only Guard
-
-Trước khi ghi file: kiểm tra file đã tồn tại chưa.
-- **File chưa có** → tạo mới bình thường.
-- **File đã có** trong version folder → check từng test method:
-  - Method đã tồn tại (cùng tên) → **SKIP**, không ghi đè
-  - Method chưa có → append vào cuối class
-
-### Bước 8 — Generate Test Data Files (nếu spec yêu cầu)
-
-Nếu spec có `test-data.{env}.json` references:
-- Tạo `tests/ApiTests/data/test-data.Test.json` với sample data từ spec
-- Hướng dẫn user tạo `test-data.Staging.json` và `test-data.local.json`
-
-### Bước 9 — Post-Generate Review
-
-Launch `csharp-reviewer` agent:
-> Review `tests/ApiTests/{version}/`. Đọc `.claude/rules/csharp/testing.md` + `.claude/rules/csharp/api-testing.md`.
-> Tập trung: async/await, HttpClient disposal, assertion completeness, XML doc coverage.
-> Format: Critical / High / Medium / Low với file:line.
-
-Gate: Critical/High → fix ngay. Medium/Low → list gợi ý.
-
-### Bước 10 — Summary
-
-Hiển thị:
-1. Test project path
-2. Number of test classes generated
-3. Number of test methods generated
-4. Coverage matrix (so với spec)
-5. Next steps để chạy tests
-
-```
-## API Tests Generated
-
-**Project**: `tests/ApiTests/`
-**Version**: v{N}
-**Test Classes**: {N}
-**Test Methods**: {N}
-
-### Generated Files
-- tests/ApiTests/{version}/{Resource}ApiTests.cs
-- tests/ApiTests/Shared/TestBase.cs (if new project)
-
-### Coverage (vs Spec)
-[Print coverage table: spec test cases vs generated methods]
-
-### Next Steps
-1. Configure test environment: edit tests/ApiTests/appsettings.Test.json
-2. Add test data: tests/ApiTests/data/test-data.Test.json
-3. Run tests: `dotnet test tests/ApiTests/`
-```
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào API Test Spec file.

package/.claude/commands/tas-brainstorm.md

@@ -1,19 +0,0 @@
-# /tas-brainstorm $ARGUMENTS
-
-Vai trò: Bất kỳ
-Brainstorm có cấu trúc trước khi code hoặc thiết kế.
-
-## Hành động
-1. $ARGUMENTS là chủ đề brainstorm
-2. Dẫn dắt qua 4 bước:
-   a. **Clarify**: Hỏi 3-5 câu hỏi làm rõ vấn đề
-   b. **Explore**: Đưa ra 3+ hướng giải quyết, mỗi hướng có pros/cons
-   c. **Evaluate**: So sánh các hướng theo tiêu chí: complexity, maintainability, cost, time
-   d. **Decide**: Đề xuất hướng tốt nhất và lý do
-
-3. Nếu kết quả brainstorm dẫn đến quyết định kiến trúc, gợi ý user chạy /tas-adr
-
-## Nguyên tắc
-- KHÔNG nhảy thẳng vào giải pháp
-- Hỏi trước, suggest sau
-- Luôn xem xét ít nhất 2 alternatives

package/.claude/commands/tas-bug.md

@@ -1,113 +0,0 @@
-# /tas-bug $ARGUMENTS
-
-Quản lý toàn bộ lifecycle của bug: tạo, phân tích, fix, verify.
-Status của bug xác định bước tiếp theo — không cần khai báo role.
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Hiển thị status hiện tại và action tiếp theo trước khi làm gì |
-| **Always** | Viết regression test TRƯỚC khi fix |
-| **Always** | Launch review agent độc lập sau khi fix — không review trong cùng session |
-| **Ask** | Khi cần đọc thêm file ngoài Bug file (Status = Committed) |
-| **Never** | Patch symptom — phải fix root cause |
-| **Never** | Bỏ qua bước review sau khi fix |
-| **Never** | Tự commit hay push — đợi user test thủ công trước |
-
-## Stack Detection
-Đọc `.claude/rules/common/stack-detection.md`.
-
-## Hành động
-
-### Bước 1 — Xác định chế độ
-
-`$ARGUMENTS` là mô tả bug mới → **Chế độ CREATE**
-`$ARGUMENTS` là Bug ID (ví dụ: `Bug-001`) → **Chế độ UPDATE**
-
----
-
-### Chế độ CREATE
-
-Vai trò: PE hoặc SE (ai phát hiện bug)
-
-1. Đọc `project.code` từ root/`tas.yaml`
-2. Hỏi user:
-   - Bug thuộc Feature nào?
-   - Severity: `Critical` | `High` | `Medium` | `Low`
-   - Steps to reproduce
-   - Expected vs Actual behavior
-   - Môi trường phát hiện: Test | Staging | Production
-3. Tạo `docs/bugs/{code}-Bug-{NNN}-{slug}.md` từ template `.tas/templates/Bug.md`
-4. Bug status ban đầu: `New`
-
----
-
-### Chế độ UPDATE
-
-Tìm file Bug qua glob `docs/bugs/*-Bug-{ID}-*.md`, đọc status hiện tại.
-
-**Hiển thị trước khi làm gì:**
-> "Bug-{NNN} đang ở status: **{status}** — bước tiếp theo là {action}. Tiếp tục không?"
-
----
-
-#### Status = `New` — Phân tích (SE)
-
-1. Đọc error logs/stack trace từ Bug file
-2. Trace code flow, xác định file và dòng gây lỗi
-3. Ghi Root Cause Analysis vào Bug file
-4. Viết Regression Test Cases (test reproduce bug)
-5. Cập nhật status: `New` → `Committed`
-
----
-
-#### Status = `Committed` — Fix (SE)
-
-**Quy tắc đọc file:** CHỈ đọc Bug file. KHÔNG đọc PRD, SAD, ADR, Design-Spec, KHÔNG quét thư mục.
-Nếu cần thêm file → hỏi user xác nhận trước.
-
-Trước khi fix, đọc:
-- `.claude/rules/common/security.md` — fix không tạo security risk mới
-- `.claude/rules/common/testing.md` — pattern viết regression test
-- `.claude/rules/[lang_agent stack]/coding-style.md` — tuân thủ conventions
-
-**Fix workflow:**
-a. Chạy regression test case → xác nhận **FAIL** (reproduce bug)
-b. Fix code đúng root cause
-c. Chạy regression test → xác nhận **PASS**
-d. Chạy toàn bộ test suite → không có regression mới
-→ Nếu build fail hoặc test lỗi compile: launch `build-resolver` agent với error output trước khi tiếp tục.
-
-**Sau khi fix — Post-Fix Review (Isolated Agent):**
-
-Thực hiện theo `.claude/rules/common/post-review-agent.md`.
-Truyền vào: Bug file path, danh sách changed files, stack (từ CLAUDE.md), lang_agent.
-
-Sau khi review pass:
-- Cập nhật status: `Committed` → `Deploy Test`
-- Output commit message gợi ý: `fix: {mô tả ngắn} - resolves Bug-{NNN}`
-- Hỏi: "Bạn đã test thủ công chưa? Muốn commit và deploy lên Test không?"
-
----
-
-#### Status = `Verify Test` / `Verify Stag` — Verify (PE)
-
-1. PE verify trên môi trường tương ứng:
-   - Chạy lại Steps to Reproduce → xác nhận bug không còn
-   - Kiểm tra regression test case đã pass
-2. **Pass** → cập nhật status tiếp theo (`Deploy Stag` hoặc `Done`)
-3. **Fail** → ghi lý do, cập nhật status về `Committed`, SE fix lại
-
----
-
-## Nguyên tắc
-- KHÔNG patch symptom — phải fix root cause
-- PHẢI có regression test case TRƯỚC khi fix
-- Review phải chạy qua Agent độc lập — không inline trong session hiện tại
-- Bug `Critical`/`High` phải fix trước khi Feature được Verified
-- Flow: `New` → `Committed` → `Deploy Test` → `Verify Test` → `Deploy Stag` → `Verify Stag` → `Deploy Prod` → `Verify Prod` → `Done`
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Bug đang làm việc.

package/.claude/commands/tas-design.md

@@ -1,37 +0,0 @@
-# /tas-design $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Tạo hoặc cập nhật Design Specification document (UI/UX flows, wireframe descriptions).
-
-## Prerequisite
-- docs/prd.md phải tồn tại
-
-## Hành động
-1. Cần context từ root/tas.yaml và docs/prd.md
-2. Kiểm tra docs/design-spec.md đã tồn tại chưa:
-
-### Chế độ CREATE (file chưa tồn tại):
-3. Cần context từ .tas/templates/Design-Spec.md
-4. $ARGUMENTS là mô tả scope của design. Nếu không có, dựa vào PRD.
-5. Tạo file docs/design-spec.md chứa:
-   - User flows (Mermaid flowchart)
-   - Screen descriptions
-   - Navigation structure
-   - Interaction patterns
-   - Responsive behavior notes
-6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm `artifacts.design_spec`.
-
-### Chế độ UPDATE (file đã tồn tại):
-3. Cần context từ docs/design-spec.md hiện tại
-4. $ARGUMENTS là mô tả thay đổi. Nếu không có, hỏi user cần cập nhật section nào.
-5. Cập nhật file, thêm changelog
-6. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `artifacts.design_spec`.
-
-## Nguyên tắc
-- Focus vào flows và behavior, không vào pixel-perfect design
-- Mỗi screen cần mô tả: purpose, key elements, actions available
-- Mermaid tuân thủ: :::mermaid wrapper, không dùng ()
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào `docs/design-spec.md`.

package/.claude/commands/tas-dev.md

@@ -1,128 +0,0 @@
-# /tas-dev $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Implement một User Story theo Technical Plan đã được duyệt.
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Kiểm tra `plan_status` trước khi implement |
-| **Always** | Follow tasks trong `## Technical Plan` của Story |
-| **Always** | Launch review agent độc lập sau khi implement — không review trong cùng session |
-| **Ask** | Khi phát hiện plan cần thay đổi đáng kể trong lúc code |
-| **Ask** | Khi cần đọc thêm file ngoài scope của plan |
-| **Never** | Implement ngoài scope Story |
-| **Never** | Skip bước review sau khi implement |
-
-## QUAN TRỌNG - Quy tắc đọc file
-- CHỈ đọc Story file — Technical Plan đã có đủ context kỹ thuật.
-- Không tự đọc PRD, SAD, ADR, Design-Spec trừ khi user xác nhận.
-- Không list thư mục, không quét project structure.
-- Không đọc `.tas/checklists/story-done.md` ở bước đầu (chỉ đọc ở bước cuối).
-
-## Stack Detection
-Đọc `.claude/rules/common/stack-detection.md`.
-
-## Hành động
-
-### Bước 1 — Xác định Story
-
-`$ARGUMENTS` là Story ID hoặc file path.
-Nếu không có: đọc `project-status.yaml`, tìm stories có `status: Committed` hoặc `status: In Progress`. Nếu nhiều hơn một, liệt kê để user chọn.
-Đọc Story file.
-
-### Bước 1.5 — Gate: Kiểm tra plan_status
-
-Đọc `plan_status` từ frontmatter của Story.
-
-**Nếu `plan_status: pending`:**
-Đọc `require_plan` từ root/`tas.yaml`:
-- `require_plan: true` (hoặc field không tồn tại) → **DỪNG LẠI**:
-  > "Story này chưa có Technical Plan. Chạy `/tas-plan {Story-ID}` trước khi implement."
-- `require_plan: false` → tiếp tục, hiển thị warning và chờ xác nhận:
-  > "⚠️ Quick mode: Story chưa có Technical Plan. Tiếp tục implement không?"
-
-**Nếu `plan_status: completed`:** tiếp tục bình thường.
-
-### Bước 2 — Đọc Technical Plan
-
-Từ Story file, đọc section `## Technical Plan`:
-- Approach đã chọn
-- Files to Change / Files to Create
-- Database Changes, Config Changes
-- Tasks list (checklist thực hiện theo thứ tự)
-
-Nếu không có Technical Plan (quick mode) → phân tích AC và implement trực tiếp theo AC.
-
-### Bước 3 — Implement
-
-**Nếu stack là Node.js/Express/Next.js** → invoke skill `js-backend-patterns` để tham khảo
-repository pattern, service layer, N+1 prevention, caching, error handling trước khi code.
-
-#### Nếu `use_tdd = true` trong `tas.yaml`:
-a. **Red phase** — Viết test cases TRƯỚC theo AC trong Story. Chạy tests, xác nhận FAIL.
-
-   Platform-specific (từ stack detection):
-   - **Mobile (React Native)**: Jest + React Testing Library — Components (`render`, `fireEvent`, `screen`), Hooks (`renderHook`), Services/API (Jest mocks + MSW), Utils, Zustand stores. File: `src/**/*.test.ts(x)`
-   - **Web (React + Node)**: Vitest/Jest + React Testing Library — Components, Hooks, Services (MSW/Nock), Backend services (Jest). File: `src/**/*.test.ts(x)`
-   - **Backend (.NET)**: xUnit — Unit (services, repositories), Integration (TestServer), API (WebApplicationFactory). File: `tests/Unit/`, `tests/Integration/`, `tests/Api/`
-
-b. **Green phase** — Viết code tối thiểu để pass tests.
-c. **Refactor** — Clean up, đảm bảo tests vẫn pass.
-
-#### Nếu `use_tdd = false`:
-a. Implement code theo AC + Tasks trong Technical Plan
-b. Viết unit tests cover các cases trong `## Unit Test Cases`
-c. Chạy tests, fix nếu fail
-→ Nếu tests vẫn fail sau 1 lần tự fix: launch `build-resolver` agent với error output để diagnose.
-
-Trong quá trình implement, tick từng task hoàn thành trong Story file: `- [x] Task 1: ...`
-
-Nếu phát hiện plan cần thay đổi đáng kể → thông báo user trước khi thay đổi hướng.
-
-### Bước 4 — Post-Implementation Review (Isolated Agent)
-
-Thực hiện theo `.claude/rules/common/post-review-agent.md`.
-Truyền vào: Story file path, danh sách changed files, stack (từ CLAUDE.md), lang_agent.
-
-### Bước 5 — Definition of Done
-
-Đọc `.tas/checklists/story-done.md`, verify từng mục, tick vào Story:
-- `- [x] Technical plan completed` — nếu plan_status: completed (hoặc quick mode xác nhận)
-- `- [x] Code implemented` — nếu implement xong
-- `- [x] Unit tests pass` — nếu tests đã pass
-- `- [x] No regression` — nếu toàn bộ test suite pass
-- `- [x] Documentation updated (if needed)` — nếu đã cập nhật
-- `- [x] Code review passed` — nếu review gate pass (không có Critical/High)
-- `- [ ] Acceptance criteria verified` — KHÔNG tick, để PE verify
-
-**Optional — nếu Story thay đổi API public, database schema, hoặc setup:**
-Launch `doc-updater` agent: cập nhật docs liên quan (README, SAD section, API docs).
-> Scope: [danh sách changed files]. Story: [Story ID + title].
-> Chỉ cập nhật phần docs đã lỗi thời — không viết lại từ đầu.
-
-### Bước 6 — Wrap up
-
-Cập nhật Story status → `In Progress` (nếu chưa).
-Tạo commit message theo conventions trong `CLAUDE.md`.
-Hỏi: "Tests OK và review passed rồi — bạn đã test thủ công chưa? Muốn chuyển sang Deploy Test không?"
-
-Nếu Yes:
-- Cập nhật Story status → `Deploy Test`
-- Thêm Changelog entry
-- Cập nhật `project-status.yaml`
-- Gợi ý: `/ado-update story {ado-id} --status "Deploy Test"` nếu dùng ADO
-
-## Nguyên tắc
-- KHÔNG implement ngoài scope của Story
-- Mỗi public method PHẢI có XML doc comment (C#) hoặc JSDoc (TypeScript) hoặc docstring (Python)
-- Review phải chạy qua Agent độc lập — không inline trong session hiện tại
-- **Khi nào cần tạo ADR** (nếu Technical Plan chưa đề cập):
-  - Thay đổi kiến trúc ảnh hưởng nhiều components
-  - Thêm mới design pattern hoặc framework
-  - Quyết định trade-off kỹ thuật quan trọng
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Story đang làm việc.

package/.claude/commands/tas-e2e.md

@@ -1,102 +0,0 @@
-# /tas-e2e $ARGUMENTS
-
-Vai tro: QA / PE
-Generate E2E test scenario documents tu mot Epic hoac user flow description.
-
-## QUAN TRONG - Layer 3: E2E Testing
-- E2E tests kiem tra TOAN BO flow lien ket giua nhieu features/stories
-- E2E scenario PHAI reference FT IDs tu Layer 2 (Functional Tests)
-- E2E scripts (tao boi /tas-e2e-mobile hoac /tas-e2e-web) se REUSE helpers tu Layer 2
-- Output la markdown scenario file, KHONG phai test code
-
-## Hanh dong
-
-### Buoc 1: Xac dinh Input
-$ARGUMENTS co the la:
-- **Epic ID** (vd: "Epic-002", "AL-Epic-002-authentication") → generate scenarios tu tat ca features/stories trong epic
-- **Flow description** (vd: "user registration to first scan") → generate cross-epic scenario
-
-Neu khong co $ARGUMENTS: list cac Epics hien co va hoi user chon.
-
-### Buoc 2: Thu thap Context
-
-#### Neu la Epic ID:
-1. Doc Epic file va tat ca Feature files ben trong
-2. Doc tat ca Story files cua cac Features
-3. Tim tat ca `Func-Test-*.md` files de lay FT IDs
-
-#### Neu la Flow Description:
-1. Search across `docs/epics/` de tim Features/Stories lien quan
-2. Xac dinh cac Epics lien quan (cross-epic scenario)
-3. Thu thap FT IDs tu Func-Test-*.md files
-
-### Buoc 3: Doc template
-Doc `.tas/templates/E2E-Scenario.md`
-Doc `root/tas.yaml` de lay project code
-
-### Buoc 4: Generate Scenario
-
-#### Naming Convention:
-- **Single-epic**: `{PROJECT}_E{EPIC}_E2E_{NNN}_{MODIFIER}`
-  - Example: `AL_E002_E2E_001_H`
-- **Cross-epic**: `{PROJECT}_XEPIC_E2E_{NNN}_{MODIFIER}`
-  - Example: `AL_XEPIC_E2E_001_H`
-
-#### Scenario Steps Table:
-Moi step PHAI co cot "Builds on FT IDs" de reference Layer 2:
-
-```markdown
-| Step | Screen/Page | Action | Expected Result | Builds on FT IDs |
-|------|-------------|--------|-----------------|-------------------|
-| 1 | Login Screen | User logs in | Home screen shown | AL_E002_F002_S001_FT_001_H |
-| 2 | Home Screen | View allergen list | List displayed | AL_E003_F001_S001_FT_001_H |
-```
-
-Neu step KHONG co FT reference → ghi "-" (new logic, chua co func test)
-
-#### Noi dung generate:
-1. Flow Overview (narrative description)
-2. Scenario Steps table
-3. Step Details (chi tiet tung buoc)
-4. Alternate Flows (neu co)
-5. Error Flows (neu co)
-6. Test Data per environment
-7. Prerequisites checklist
-8. Success Criteria
-9. FT Reuse Map (map step → FT ID → helper function)
-
-### Buoc 5: Output File
-- **Single-epic**: `docs/epics/{epic-dir}/E2E-Scenario-{NNN}-{slug}.md`
-- **Cross-epic**: `docs/e2e-scenarios/E2E-Scenario-{NNN}-{slug}.md`
-
-Auto-create `docs/e2e-scenarios/` directory neu chua ton tai.
-
-### Buoc 6: Prompting
-Sau khi generate, hoi user:
-- "Co flow phu nao can cover khong?"
-- "Co error scenario nao can them khong?"
-- "Test data cho cac environment da day du chua?"
-- "Co can test tren ca mobile va web khong?"
-
-## FT Reuse Map
-Moi scenario file co section "FT Reuse Map" de:
-- Map scenario step → FT ID → source file → helper function
-- /tas-e2e-mobile va /tas-e2e-web doc section nay de import helpers tu Layer 2
-
-```markdown
-## FT Reuse Map
-| Step | FT ID | Source File | Helper Function |
-|------|-------|-------------|-----------------|
-| 1 | AL_E002_F002_S001_FT_001_H | features/auth/login/helpers.ts | fillLoginForm() |
-| 2 | AL_E003_F001_S001_FT_001_H | features/home/allergens/helpers.ts | viewAllergenList() |
-```
-
-## Status Flow
-Draft → Ready → Implemented → Verified
-
-## Nguyen tac
-- Output la MARKDOWN scenario, KHONG phai test code
-- Test code duoc tao boi /tas-e2e-mobile hoac /tas-e2e-web
-- Moi step NEN reference FT IDs khi co the (de reuse, khong viet lai)
-- Scenario phai testable: co preconditions, test data, success criteria ro rang
-- Cross-epic scenarios dung prefix XEPIC thay vi Epic number

package/.claude/commands/tas-epic.md

@@ -1,35 +0,0 @@
-# /tas-epic $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Tạo mới hoặc cập nhật Epic document.
-
-## Prerequisite
-- docs/prd.md phải tồn tại
-
-## Hành động
-1. Cần context từ root/tas.yaml và docs/prd.md
-2. Cần context từ .tas/templates/Epic.md
-3. Xác định chế độ dựa vào $ARGUMENTS:
-
-### Chế độ CREATE ($ARGUMENTS là mô tả Epic mới, hoặc không có $ARGUMENTS):
-4. Nếu không có $ARGUMENTS, hỏi user mô tả Epic.
-5. Đọc project.code từ root/tas.yaml. Quét docs/epics/ để xác định số thứ tự.
-6. Tạo thư mục docs/epics/{code}-Epic-{NNN}-{slug}/
-7. Tạo file docs/epics/{code}-Epic-{NNN}-{slug}/{code}-Epic-{NNN}-{slug}.md
-8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm entry vào `epics`.
-
-### Chế độ UPDATE ($ARGUMENTS là Epic ID, ví dụ: "Epic-001"):
-4. Tìm thư mục docs/epics/{code}-Epic-001-*/
-5. Cần context từ file Epic hiện tại
-6. Hỏi user cần thay đổi gì (cập nhật scope, thêm feature, đổi status...)
-7. Cập nhật file, thêm changelog
-8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `epics.{EPIC_ID}.status`.
-
-## Nguyên tắc
-- Mỗi Epic map với một business capability trong PRD
-- Epic KHÔNG chứa chi tiết kỹ thuật, chỉ chứa business value
-- Ước lượng effort ở mức T-shirt size: S/M/L/XL
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Epic đang làm việc.

package/.claude/commands/tas-feature.md

@@ -1,47 +0,0 @@
-# /tas-feature $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Tạo mới hoặc cập nhật Feature document, bao gồm thiết kế Integration Test và E2E/Acceptance Test.
-
-## Prerequisite
-- Ít nhất một Epic phải tồn tại trong docs/epics/
-
-## Hành động
-1. Cần context từ root/tas.yaml
-2. Cần context từ .tas/templates/Feature.md
-3. Xác định chế độ dựa vào $ARGUMENTS:
-
-### Chế độ CREATE ($ARGUMENTS là mô tả Feature mới, hoặc không có $ARGUMENTS):
-4. Đọc project.code từ root/tas.yaml. Liệt kê các Epic hiện có, hỏi user Feature này thuộc Epic nào.
-5. Quét thư mục Epic đã chọn để xác định số thứ tự Feature.
-6. Tạo thư mục docs/epics/{code}-Epic-{NNN}-{slug}/{code}-Feature-{NNN}-{slug}/
-7. Tạo file {code}-Feature-{NNN}-{slug}.md trong thư mục đó
-8. Sau khi PE điền mô tả và acceptance criteria, TỰ ĐỘNG chuyển sang thiết kế test:
-   a. **Integration Test Cases**: Hỏi PE:
-      - "Feature này tương tác với service/module nào khác?"
-      - "Các flow liên kết giữa stories cần test những gì?"
-      - "Có data flow nào cần verify end-to-end trong feature này?"
-      Ghi vào section Integration Test Cases.
-   b. **E2E / Acceptance Test Cases**: Hỏi PE:
-      - "User scenario chính để verify feature này trên Staging là gì?"
-      - "Có scenario nào cần test với data thật hoặc gần thật?"
-      - "Acceptance criteria nào cần PE verify thủ công?"
-      Ghi vào section E2E Test Cases. Đây là checklist PE dùng ở Phase 2 khi chạy /tas-verify.
-9. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm entry vào `epics.{EPIC_ID}.features`.
-
-### Chế độ UPDATE ($ARGUMENTS là Feature ID, ví dụ: "Feature-003"):
-4. Tìm file Feature trong cây docs/epics/ (dùng glob)
-5. Cần context từ file Feature hiện tại
-6. Hỏi user cần thay đổi gì (thêm story, cập nhật AC, thêm test cases, đổi status...)
-7. Cập nhật file, thêm changelog
-8. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `epics.{EPIC_ID}.features.{FEATURE_ID}.status`.
-
-## Nguyên tắc
-- Feature là một chức năng cụ thể, có thể demo được
-- Feature PHẢI có acceptance criteria rõ ràng, testable
-- Integration Test Cases PHẢI cover các flow liên kết giữa stories
-- E2E Test Cases PHẢI đủ để PE verify feature trên Staging ở Phase 2
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Feature đang làm việc.

package/.claude/commands/tas-fix.md

@@ -1,51 +0,0 @@
-# /tas-fix $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Quick fix cho bug nhỏ hoặc lỗi rõ ràng — không cần tạo ticket, không cần full lifecycle.
-Dùng khi: solo dev, hotfix nhanh, bug tìm thấy trong lúc dev.
-Khác với /tas-bug: không tạo Bug file, không track status, không deploy flow.
-
-## Stack Detection
-Đọc `.claude/rules/common/stack-detection.md`.
-
-## Hành động
-
-### 1. Hiểu bug
-$ARGUMENTS là mô tả lỗi, error message, hoặc file:line_number.
-- Nếu có error message/stack trace: parse ngay, xác định file và dòng lỗi
-- Nếu chỉ có mô tả: hỏi 1 câu duy nhất để làm rõ (reproduce steps hoặc expected vs actual)
-- KHÔNG hỏi nhiều hơn 1 câu
-
-### 2. Diagnose (tối đa 3 file đọc)
-- Đọc file lỗi và các file liên quan trực tiếp
-- Xác định root cause trong 1-2 câu ngắn
-- KHÔNG đọc toàn bộ project, KHÔNG quét cấu trúc folder
-- Nếu cần đọc thêm file ngoài 3 file đầu tiên: hỏi user xác nhận
-
-### 3. Fix với regression test
-
-Trước khi fix, đọc các rules liên quan:
-- `.claude/rules/common/security.md` — kiểm tra fix có tạo ra security risk không
-- `.claude/rules/common/testing.md` — pattern viết regression test
-- `.claude/rules/[lang_rules]/coding-style.md` — conventions của stack hiện tại (nếu xác định được)
-
-Sau đó:
-a. Viết 1 test case tối thiểu reproduce bug (nếu project có test framework)
-b. Xác nhận test FAIL
-c. Fix code đúng root cause
-d. Xác nhận test PASS
-e. Chạy nhanh test suite nếu có (để check regression)
-
-### 4. Wrap up
-- Output commit message: `fix: <mô tả ngắn gọn>`
-- Nhắc: "Nếu bug này có khả năng tái phát hoặc ảnh hưởng production, cân nhắc dùng /tas-bug để track đầy đủ."
-
-## Nguyên tắc
-- Tổng số file đọc ≤ 3 trừ khi được cho phép
-- Fix đúng root cause, KHÔNG patch symptom
-- Nếu fix kéo theo thay đổi architecture → dừng, gợi ý dùng /tas-bug + /tas-adr
-- Nếu bug thuộc production và severity cao → dừng, gợi ý dùng /tas-bug với severity Critical/High
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Story hoặc Bug liên quan (nếu có).