@torus-engineering/tas-kit 1.10.0 → 1.12.0

package/.claude/commands/tas-functest-mobile.md

@@ -1,144 +0,0 @@
-# /tas-functest-mobile $ARGUMENTS
-
-Vai tro: SE / QA
-Generate tat ca Detox automation test scripts cho mot mobile Feature.
-
-## QUAN TRONG - Layer 2: Mobile Functional Test Scripts
-- Tao Detox test scripts tu Func-Test-Spec (markdown)
-- Scripts nam trong `apps/mobile/e2e/features/`
-- Reusable helpers duoc export de Layer 3 (E2E) tai su dung
-- Data hardcoded trong test, credentials tu .env
-
-## Hanh dong
-
-### Buoc 1: Xac dinh Feature
-1. $ARGUMENTS la Feature ID hoac file path
-2. Neu khong co: scan `docs/epics/**/Feature-*.md` tim features co status In Progress
-3. Doc Feature file de lay Epic/Feature numbers va danh sach Stories
-
-### Buoc 2: Kiem tra Prerequisites
-1. Kiem tra `apps/mobile/` ton tai. Neu khong → bao loi:
-   > "Mobile app chua ton tai trong project nay. Vui long tao apps/mobile/ truoc."
-2. Tim tat ca `Func-Test-*.md` files trong Feature directory:
-   ```
-   docs/epics/{epic-dir}/{feature-dir}/Func-Test-*.md
-   ```
-3. Neu khong co Func-Test-Spec nao → bao loi:
-   > "Chua co Func-Test-Spec nao cho Feature nay. Chay /tas-functest {story-ID} truoc."
-4. Doc `apps/mobile/e2e/test-ids.ts` de biet testID hien co
-5. Doc `apps/mobile/e2e/helpers/data-loader.ts` va `test-utils.ts` de hieu patterns
-
-### Buoc 3: Aggregate FT Test Cases
-- Tu tat ca Func-Test-Spec files, tong hop danh sach FT test cases
-- Nhom theo Story
-- Lay test data requirements tu moi spec
-
-### Buoc 4: Generate Test Scripts
-Voi MOI Story co Func-Test-Spec:
-
-**File output**: `apps/mobile/e2e/features/{epic-slug}/{feature-slug}/{story-slug}.func.e2e.ts`
-
-**Structure**:
-```typescript
-/**
- * Functional Tests: {Story Name}
- * Story: {Story_ID}
- * Feature: {Feature_ID}  
- * Epic: {Epic_ID}
- * 
- * Generated by /tas-functest-mobile
- * Spec: docs/epics/{epic-dir}/{feature-dir}/Func-Test-{story-slug}.md
- */
-
-import { device, element, expect, by, waitFor } from 'detox';
-import { TEST_IDS } from '../../../test-ids';
-import { loadTestData, getCredentials } from '../../../helpers/data-loader';
-import { login, navigateTo } from '../../../helpers/test-utils';
-
-const testData = loadTestData();
-
-describe('{Feature Name} - {Story Name}', () => {
-  beforeAll(async () => {
-    await device.launchApp({ newInstance: true });
-  });
-
-  beforeEach(async () => {
-    await device.reloadReactNative();
-  });
-
-  // AC Reference: AC-1
-  describe('{PROJECT}_E{EPIC}_F{FEATURE}_S{STORY}_FT_001_H', () => {
-    it('should {description from spec}', async () => {
-      // Given: {precondition}
-      // When: {action}
-      // Then: {expected}
-    });
-  });
-});
-```
-
-### Buoc 5: Update test-ids.ts (neu can)
-- Neu test cases can testID chua co trong test-ids.ts
-- Them testID moi theo naming convention hien tai
-- Giu nguyen structure: nested object voi dot notation
-
-### Buoc 6: Generate Feature Helpers
-Tao file `apps/mobile/e2e/features/{epic-slug}/{feature-slug}/helpers.ts`:
-```typescript
-/**
- * Reusable helpers cho {Feature Name}
- * Duoc tai su dung boi Layer 3 E2E scripts
- */
-
-export async function {featureSpecificHelper}() {
-  // Helper logic extracted from functional tests
-}
-```
-
-### Buoc 7: Update package.json Script
-Them hoac update script trong `apps/mobile/package.json`:
-```json
-"functest:mobile:{feature-slug}": "detox test --configuration ios.sim.debug --testPathPattern='e2e/features/{epic-slug}/{feature-slug}'"
-```
-
-### Buoc 8: Generate Index
-Tao `apps/mobile/e2e/features/{epic-slug}/{feature-slug}/index.ts`:
-```typescript
-export * from './helpers';
-```
-
-## File Structure Output
-```
-apps/mobile/e2e/features/
-└── {epic-slug}/
-    └── {feature-slug}/
-        ├── {story-1-slug}.func.e2e.ts
-        ├── {story-2-slug}.func.e2e.ts
-        ├── helpers.ts
-        └── index.ts
-```
-
-## Test Data Convention
-- **Hardcoded values**: Truc tiep trong test (vd: "invalid@email", "short")
-- **Credentials**: `const creds = getCredentials();` → password tu process.env
-- **Environment data**: `const testData = loadTestData();` → doc tu test-data.{env}.json
-- **KHONG BAO GIO** hardcode passwords/tokens trong test files
-
-## Chay Tests
-```bash
-# Chay tat ca func tests cho feature
-yarn functest:mobile:{feature-slug}
-
-# Chay chi mot story
-npx detox test --configuration ios.sim.debug --testPathPattern='e2e/features/{epic}/{feature}/{story}'
-
-# Chay voi Android
-npx detox test --configuration android.emu.debug --testPathPattern='e2e/features/{epic}/{feature}'
-```
-
-## Nguyen tac
-- Script PHAI chay duoc ngay tu CLI, KHONG can cua so Claude
-- Moi describe block dung full FT ID de grep duoc
-- Helpers PHAI export de Layer 3 reuse
-- KHONG import tu Layer 3 (flows/), chi export LEN Layer 3
-- Neu apps/mobile/ khong ton tai → bao loi graceful, KHONG tao

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

@@ -1,76 +0,0 @@
-# /tas-functest $ARGUMENTS
-
-Vai tro: SE / QA
-Generate Functional Test Specification tu mot User Story, lien ket test cases voi Acceptance Criteria (AC).
-
-## QUAN TRONG - Layer 2: Functional Testing
-- Functional tests (FT) nam giua Unit tests (Layer 1) va E2E tests (Layer 3)
-- FT test tung chuc nang/story rieng le, KHONG test flow lien ket giua nhieu features
-- Moi FT case PHAI reference AC-ID de traceability
-
-## Hanh dong
-
-### Buoc 1: Xac dinh Story
-1. $ARGUMENTS la Story ID hoac file path
-2. Neu khong co $ARGUMENTS: scan `docs/epics/**/Story-*.md` tim stories co status In Progress hoac Committed
-3. Doc Story file de lay:
-   - Tat ca Acceptance Criteria (AC-1, AC-2, ...)
-   - Epic/Feature/Story numbers (tu frontmatter hoac file path)
-   - Platform context (mobile/web/backend)
-4. Doc `root/tas.yaml` de lay project code (vd: "AL")
-
-### Buoc 2: Auto-detect Platform
-Tu Story context, xac dinh platform:
-- **Mobile**: Keywords "screen", "navigation", "React Native", "Detox"; paths `apps/mobile/src/features/*`
-- **Web**: Keywords "browser", "page", "Playwright", "React"; paths `apps/web/*`
-- **Backend**: Keywords "API endpoint", "service", "controller"; paths `src/Torus.*`, `tests/`
-- Neu khong xac dinh duoc: hoi user
-
-### Buoc 3: Generate FT Test Cases
-Doc template tu `.tas/templates/Func-Test-Spec.md`
-
-Naming format:
-```
-{PROJECT}_E{EPIC}_F{FEATURE}_S{STORY}_FT_{NNN}_{MODIFIER}
-```
-
-Voi moi AC, generate:
-- **BAT BUOC**: 1 Happy path test (H)
-- **NEN CO**: 1 Negative test (N) neu co error scenarios
-- **TUY CHON**: 1 Edge case test (E) neu co boundary conditions
-
-Moi test case PHAI co cot AC-ID trong bang mapping.
-
-### Buoc 4: Generate Test Data Requirements
-- Xac dinh data can thiet cho moi test case
-- Data hardcoded: ghi truc tiep trong scenario
-- Credentials: chi reference `process.env.TEST_USER_PASSWORD`, KHONG hardcode
-- Data per environment: reference `test-data.{env}.json`
-
-### Buoc 5: Output File
-Luu file tai:
-```
-docs/epics/{epic-dir}/{feature-dir}/Func-Test-{story-slug}.md
-```
-
-### Buoc 6: Prompting
-Sau khi generate, hoi user:
-- "Co edge case nao can them khong?"
-- "Co negative test scenario nao bi bo sot khong?"
-- "Co test case nao can danh dau P0 Critical khong?"
-- "Test data va fixtures can chuan bi gi them?"
-
-## Traceability Feature
-- Moi FT case gan AC-ID trong cot mapping
-- Khi AC thay doi: grep AC-ID trong Func-Test-*.md de biet FT nao can update
-- Trong test script, moi describe block co comment `// AC Reference: AC-{N}`
-
-## Status Flow
-Draft → Ready → Implemented → Verified
-
-## Nguyen tac
-- KHONG tao test code, chi tao specification (markdown)
-- Test code duoc tao boi `/tas-functest-mobile` hoac `/tas-functest-web`
-- Func-Test-Spec la input cho Layer 2 script generation
-- Moi AC phai co it nhat 1 FT case
-- FT dung type code `FT`, KHONG dung `E2E` hay `UT`

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

@@ -1,17 +0,0 @@
-# /tas-init
-
-Khởi tạo bộ TAS cho dự án hiện tại.
-
-## Hành động
-1. Cần context từ root/tas.yaml. Nếu chưa có, copy từ .tas/tas-example.yaml ra root và hỏi user điền thông tin cần thiết.
-2. Tạo cấu trúc thư mục: .tas/templates/, .tas/checklists/, docs/, docs/adr/, docs/epics/, docs/bugs/
-3. Tạo file root/project-status.yaml với trạng thái ban đầu (artifacts, epics, adrs đều rỗng).
-4. Copy các template mặc định vào .tas/templates/ nếu chưa có.
-5. Nếu project type là brownfield và codebase_scan_on_init = true:
-   - Quét codebase hiện tại
-   - Tạo file docs/codebase-overview.md tóm tắt kiến trúc hiện có
-6. Hiển thị trạng thái: project type, team roles, workflow phases đang bật.
-
-## Lưu ý
-- KHÔNG tạo lại file nếu đã tồn tại
-- Hỏi xác nhận trước khi thực hiện

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

@@ -1,200 +0,0 @@
-# /tas-plan $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Cầu nối giữa nghiệp vụ (Story) và kỹ thuật (code).
-Phân tích Story, lập kế hoạch kỹ thuật, break tasks — trước khi bắt đầu implement.
-
-**Output bắt buộc:** Technical Plan được ghi vào Story file + `plan_status: completed`.
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Đọc Story file trước khi làm bất cứ điều gì |
-| **Always** | Chờ user approve plan trước khi ghi vào Story |
-| **Always** | Ghi Technical Plan vào Story file sau khi approved |
-| **Ask** | Khi cần tham khảo SAD/ADR — xác nhận với user trước khi đọc |
-| **Ask** | Khi Story scope > 8 giờ — gợi ý tách Story |
-| **Never** | Bắt đầu implement ở command này |
-| **Never** | Tự đọc SAD/ADR mà không hỏi user trước |
-| **Never** | Ghi plan vào Story mà chưa có approval |
-
-## Hành động
-
-### Bước 1 — Xác định Story
-
-`$ARGUMENTS` có thể là: Story ID (`Story-005`), file path, hoặc mô tả Story.
-
-- Nếu là Story ID: tìm file qua glob `docs/epics/**/*-Story-{ID}-*.md`
-- Nếu là file path: đọc trực tiếp
-- Nếu là mô tả: hỏi user Story ID/file cụ thể
-- Đọc Story file
-
-**Check re-plan:** Nếu `plan_status: completed` → hỏi user:
-> "Story này đã có Technical Plan rồi. Bạn muốn lập lại kế hoạch không?"
-Nếu user xác nhận → tiếp tục. Nếu không → dừng.
-
-### Bước 2 — Parallel Context Gathering
-
-Launch 2 agents ĐỒNG THỜI:
-
-**Agent 1 — `code-explorer`** (luôn chạy):
-> Khảo sát codebase liên quan đến Story: "{Story title + tóm tắt AC}".
-> Tìm: entry points, files có khả năng thay đổi, existing patterns, dependencies.
-> Đọc tối đa 10 files liên quan nhất.
-> Trả về: map ngắn gọn — what exists, what needs to change, potential conflicts.
-
-**Agent 2 — `architect`** (chỉ chạy khi Story có dấu hiệu thay đổi kiến trúc:
-thêm service/module mới, thay đổi data flow, tích hợp external system,
-thay đổi database schema, thêm mới design pattern):
-> Đánh giá architectural implications của Story: "{Story title}".
-> Đọc `docs/sad.md` (nếu tồn tại) và files trong `docs/adr/`.
-> Đọc `.claude/rules/common/patterns.md`.
-> Trả về: ADR nào liên quan, patterns cần follow, rủi ro kiến trúc, constraints.
-
-Chờ TẤT CẢ agents xong, tổng hợp findings.
-
-### Bước 3 — Hỏi về SAD/ADR (nếu chưa rõ)
-
-Sau khi xem findings từ agents, nếu cần tham khảo thêm SAD hoặc ADR cụ thể:
-> "Tôi cần đọc thêm [SAD / ADR-XXX] để làm rõ [lý do]. Được không?"
-
-Chỉ đọc sau khi user xác nhận.
-
-### Bước 4 — API Design (nếu Story liên quan đến backend API)
-
-**Nếu Story có dấu hiệu thiết kế API** (thêm endpoint mới, thay đổi API contract, expose service ra ngoài):
-Invoke skill `api-design` để thiết kế API Spec trước khi lập plan:
-- URL structure, HTTP methods, status codes
-- Request/response payload shape
-- Pagination, filtering nếu cần
-- Error response format
-
-Gắn API Spec vào section **Technical Plan → API Contract** trong Story.
-Nếu Story không liên quan API → bỏ qua bước này.
-
-### Bước 5 — Phân tích kỹ thuật
-
-Dựa trên Story + agent findings, liệt kê rõ:
-
-**Files sẽ thay đổi:**
-| File | Thay đổi gì | Lý do |
-|------|-------------|-------|
-
-**Files mới cần tạo** (nếu có):
-| File | Mục đích |
-|------|----------|
-
-**Database changes** (nếu có): migration, schema changes, seed data
-
-**Config/Infrastructure changes** (nếu có): env vars, feature flags, dependencies mới
-
-**Cần cập nhật SAD?** Yes/No + lý do ngắn gọn
-
-**Cần tạo ADR mới?** Yes/No + lý do ngắn gọn
-
-### Bước 6 — Đề xuất approach
-
-Nếu có nhiều cách làm khả thi, liệt kê 2-3 options:
-```
-Option A: [mô tả ngắn]
-  + [ưu điểm]
-  - [nhược điểm]
-
-Option B: [mô tả ngắn]
-  + [ưu điểm]
-  - [nhược điểm]
-```
-Đề xuất option tốt nhất và lý do. Nếu chỉ có 1 cách → trình bày trực tiếp.
-
-### Bước 7 — Break Tasks
-
-Breakdown thành tasks theo thứ tự implement. Mỗi task ~1-2 giờ:
-```
-- [ ] Task 1: [hành động cụ thể — file nào, thay đổi gì]
-- [ ] Task 2: [hành động cụ thể]
-- [ ] Task 3: Viết unit tests cho [AC-1, AC-2...]
-- [ ] Task 4: [nếu cần] Tạo ADR / cập nhật SAD
-```
-
-Nếu tổng estimate > 8 giờ → gợi ý tách Story trước khi tiếp tục.
-
-### Bước 8 — Chờ approval
-
-**DỪNG LẠI.** Hiển thị toàn bộ plan và hỏi:
-> "Technical Plan trên có OK không? Muốn điều chỉnh gì không?"
-
-- Nếu user approve → Bước 9
-- Nếu user có feedback → cập nhật plan, hỏi lại
-- KHÔNG ghi gì vào Story trước khi có approval
-
-### Bước 9 — Ghi Technical Plan vào Story
-
-Sau khi approved, cập nhật Story file:
-
-**1. Thêm section `## Technical Plan`** vào Story (thay thế comment placeholder):
-
-```markdown
-## Technical Plan
-> **Plan by:** {SE name} | **Date:** {ngày hiện tại}
-
-### Approach
-{Mô tả ngắn về approach đã chọn và lý do}
-
-### Files to Change
-| File | Change | Reason |
-|------|--------|--------|
-
-### Files to Create
-| File | Purpose |
-|------|---------|
-
-### Database Changes
-{Nếu không có: "None"}
-
-### Config Changes
-{Nếu không có: "None"}
-
-### Architecture Notes
-- SAD update needed: Yes/No
-- New ADR needed: Yes/No — {tiêu đề nếu Yes}
-
-### Tasks
-- [ ] Task 1: ...
-- [ ] Task 2: ...
-- [ ] Task 3: Viết unit tests
-```
-
-**2. Cập nhật frontmatter:**
-- `plan_status: completed`
-- `plan_date: {ngày giờ hiện tại}`
-
-**3. Cập nhật `project-status.yaml`:**
-- `last_updated: {ngày hiện tại}`
-- `epics.{EPIC_ID}.features.{FEATURE_ID}.stories.{STORY_ID}.plan_status: completed`
-
-**4. Nếu cần ADR:** chạy `/tas-adr "{Tiêu đề quyết định}"` ngay sau khi ghi plan xong.
-
-### Bước 10 — Thông báo next step
-> "Technical Plan đã ghi vào Story. SE có thể bắt đầu implement với `/tas-dev {Story-ID}`."
-
----
-
-## Quick Mode (require_plan: false trong tas.yaml)
-
-Dành cho: solo dev, prototype, spike, hotfix khẩn.
-
-- `/tas-dev` sẽ KHÔNG bắt buộc chạy `/tas-plan` trước
-- `/tas-plan` vẫn có thể chạy tự nguyện khi Story phức tạp
-- Trade-off: tốc độ cao hơn, traceability thấp hơn
-
-## Nguyên tắc
-- Technical Plan sống trong Story file — không tạo file plan riêng
-- Mỗi task ~1-2 giờ; cả Story ~4-8 giờ
-- Nếu estimate > 8 giờ → tách Story
-- Nếu task ảnh hưởng architecture → suggest ADR
-- Giữ plan ngắn gọn, actionable — không viết essay
-
-## 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-prd.md

@@ -1,37 +0,0 @@
-# /tas-prd $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Tạo hoặc cập nhật Product Requirements Document.
-
-## Hành động
-1. Cần context từ root/tas.yaml để lấy project context
-2. Kiểm tra docs/prd.md đã tồn tại chưa:
-
-### Chế độ CREATE (file chưa tồn tại):
-3. Cần context từ .tas/templates/PRD.md
-4. Nếu $ARGUMENTS có nội dung, dùng làm input mô tả sản phẩm
-5. Nếu không có $ARGUMENTS, hỏi user:
-   - Sản phẩm giải quyết vấn đề gì?
-   - Đối tượng người dùng chính?
-   - Các tính năng cốt lõi?
-   - Ràng buộc kỹ thuật/kinh doanh?
-6. Tạo file docs/prd.md theo template
-7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm `artifacts.prd`.
-
-### Chế độ UPDATE (file đã tồn tại):
-3. Cần context từ docs/prd.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, giữ nguyên các section không thay đổi
-6. Thêm dòng vào section Changelog cuối file: ngày, mô tả thay đổi
-7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `artifacts.prd`.
-
-## Nguyên tắc
-- Viết ở mức đủ chi tiết để SE có thể hiểu và thiết kế kiến trúc
-- Phân loại requirements theo MoSCoW: Must/Should/Could/Won't
-- Mỗi requirement có ID duy nhất: FR-001, NFR-001
-- Luôn có section Non-Goals để giới hạn scope
-- Sơ đồ Mermaid phải dùng :::mermaid wrapper, KHÔNG dùng ký tự ()
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào `docs/prd.md`.

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

@@ -1,111 +0,0 @@
-# /tas-review $ARGUMENTS
-
-Review code thay đổi gần nhất hoặc một file/PR cụ thể.
-Bao gồm hygiene scan, test run, và parallel multi-agent review.
-
-## Stack Detection
-Đọc `.claude/rules/common/stack-detection.md`.
-
-## Hành động
-
-### Bước 1 — Xác định scope review
-`$ARGUMENTS` có thể là: file path, Story ID, hoặc để trống (review git diff).
-- Nếu trống: lấy `git diff HEAD` (staged + unstaged) hoặc last commit
-- Nếu Story ID: tìm file Story tương ứng để lấy danh sách files đã thay đổi
-- Nếu file path: review trực tiếp file đó
-
-### Bước 2 — Pre-checks (PHẢI pass mới tiếp tục)
-
-**Hygiene scan** — scan nhanh các files trong scope:
-- Debug code còn sót: `console.log`, `print(`, `Debug.WriteLine`, `debugger`
-- Secrets hardcoded: password/key/token/secret gán bằng string literal
-- Commented-out code block lớn (>5 dòng) không có comment lý do
-
-→ Nếu có blocker: liệt kê ngay, yêu cầu fix trước khi tiếp tục.
-
-**Run tests** — detect từ project structure:
-- `package.json` → `yarn test --ci` hoặc `npm test`
-- `*.csproj` / `*.sln` → `dotnet test`
-- `pytest.ini` / `pyproject.toml` → `python -m pytest`
-
-→ Nếu **FAIL**: thêm finding **"Unit Test Failure"** severity **Critical**, dừng lại, KHÔNG tiếp tục review.
-→ Nếu **PASS**: ghi chú "Unit Tests: ✓ PASS" vào Review Summary.
-→ Nếu không detect được: ghi chú "No test runner detected" và tiếp tục.
-
-### Bước 3 — Parallel Multi-Agent Review
-
-Launch các agents ĐỒNG THỜI (không chờ nhau):
-
-**Agent 1 — `code-reviewer`** (luôn chạy):
-> Review [scope]. Đọc `.tas/checklists/code-review.md` và `.claude/rules/common/code-review.md`.
-> Tập trung: naming, architecture alignment, error handling, DRY, function size, nesting depth.
-> Format: findings nhóm theo Critical / High / Medium / Low, mỗi finding có file:line và fix cụ thể.
-
-**Agent 2 — `security-reviewer`** (luôn chạy):
-> Security audit [scope]. Đọc `.claude/rules/common/security.md`.
-> Nếu stack đã xác định, đọc thêm `.claude/rules/[stack]/security.md`.
-> Tập trung: OWASP Top 10, injection, hardcoded secrets, auth/authz, data exposure.
-> Format: findings nhóm theo Critical / High / Medium / Low, mỗi finding có file:line và remediation.
-
-**Agent 3 — Language reviewer** (dựa theo `lang_agent` từ stack detection):
-> Language-specific review [scope].
-> Đọc `.claude/rules/[stack]/coding-style.md`, `.claude/rules/[stack]/patterns.md`, `.claude/rules/[stack]/testing.md`.
-> Nếu stack có React: đọc thêm `.claude/rules/web/design-quality.md`, `.claude/rules/web/testing.md`, `.claude/rules/web/performance.md`.
-> Tập trung: async/await patterns, null handling, type safety, anti-patterns đặc thù của stack.
-> Format: findings theo Critical / High / Medium / Low với file:line.
-
-**Agent 4 — `aws-reviewer`** (chỉ khi `infra_agent = aws-reviewer`):
-> AWS infrastructure review [scope].
-> Tập trung: IAM policies, secrets trong env/config, S3 permissions, Lambda security.
-> Format: findings theo Critical / High / Medium / Low.
-
-Chờ TẤT CẢ agents hoàn thành, sau đó tổng hợp.
-
-### Bước 4 — Tổng hợp kết quả
-
-Gộp findings từ tất cả agents, deduplicate (cùng file:line từ nhiều agent → gộp lại), sort theo severity:
-
-```
-## Review Summary
-
-### Critical (phải fix trước khi merge)
-- [file:line] Issue — Fix: ...
-
-### High (nên fix trước khi merge)
-- [file:line] Issue — Fix: ...
-
-### Medium (cân nhắc fix)
-- [file:line] Issue — Fix: ...
-
-### Low / Info (optional)
-- [file:line] Issue — Fix: ...
-```
-
-## Sau khi review
-
-**Nếu có Critical/High:**
-→ Liệt kê rõ, yêu cầu human fix. KHÔNG tiếp tục flow.
-
-**Nếu chỉ có Medium/Low:**
-→ List gợi ý, hỏi human có muốn fix không, sau đó tiếp tục.
-
-**Khi human xác nhận đã fix:**
-1. Tick `- [x] Code review passed` trong section `## Definition of Done` của Story
-2. Hỏi: "Bạn đã tự test lại ở local chưa? Nếu OK, có muốn chuyển ticket sang Deploy Test không?"
-3. Nếu Yes:
-   a. Cập nhật `Status:` trong Story → `Deploy Test`
-   b. Thêm dòng Changelog trong Story: ngày, "Code review passed, moved to Deploy Test"
-   c. Cập nhật `Status:` trong Feature cha → `In Progress`, update bảng Stories
-   d. Thêm Changelog trong Feature
-   e. Cập nhật `project-status.yaml`
-   f. Gợi ý: chạy `/ado-update story <ado-id> --status "Deploy Test"` nếu dùng ADO
-
-## Nguyên tắc
-- Review khách quan — chỉ ra file:line cụ thể và lý do
-- Đề xuất fix cụ thể, không chỉ nói "code xấu"
-- Check xem code có vi phạm ADR nào không (đọc từ Technical Notes trong Story)
-- KHÔNG tự động chuyển status mà không có xác nhận của human
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Story đang review (nếu có).

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

@@ -1,43 +0,0 @@
-# /tas-sad $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Tạo hoặc cập nhật Solution Architecture Document.
-
-## Prerequisite
-- docs/prd.md phải tồn tại. Nếu chưa có, thông báo user chạy /tas-prd trước.
-
-## Hành động
-1. Cần context từ root/tas.yaml để lấy project info, workflow config
-2. Cần context từ docs/prd.md để hiểu requirements
-3. Nếu brownfield: cần context từ docs/codebase-overview.md nếu có
-4. Kiểm tra docs/sad.md đã tồn tại chưa:
-
-### Chế độ CREATE (file chưa tồn tại):
-5. Cần context từ .tas/templates/SAD.md
-6. Tạo file docs/sad.md theo template SAD của Torus
-7. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — thêm `artifacts.sad`.
-
-### Chế độ UPDATE (file đã tồn tại):
-5. Cần context từ docs/sad.md hiện tại
-6. $ARGUMENTS là mô tả thay đổi. Nếu không có, hỏi user cần cập nhật section nào.
-7. Cập nhật file, giữ nguyên các section không thay đổi
-8. Thêm dòng vào section Changelog cuối file
-9. Nếu thay đổi là quyết định kiến trúc quan trọng, gợi ý user chạy /tas-adr
-10. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md` — cập nhật `artifacts.sad`.
-
-## Quy tắc Mermaid
-- Các sơ đồ C4 PHẢI dùng Mermaid flow diagram
-- Bắt đầu bằng :::mermaid, kết thúc bằng :::
-- KHÔNG dùng ký tự () trong node labels, thay bằng []
-- Ví dụ: A["Web App"] --> B["API Gateway"]
-- Bao gồm các view: System Context, Container, Component, Data, Deployment
-
-## Nguyên tắc
-- SAD phải align với tech stack trong CLAUDE.md
-- Mỗi architectural decision quan trọng cần reference sang ADR
-- ERD phải dùng Mermaid erDiagram
-- Sequence diagram dùng Mermaid sequenceDiagram
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào `docs/sad.md`.