@torus-engineering/tas-kit 1.10.0 → 1.12.0

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

@@ -1,87 +0,0 @@
-# /tas-security $ARGUMENTS
-
-Kiểm tra bảo mật codebase, lưu báo cáo vào docs/security-report.md.
-
-## Stack Detection
-Đọc `.claude/rules/common/stack-detection.md`.
-
-## Hành động
-
-### Bước 1 — Xác định scope
-`$ARGUMENTS` có thể là:
-- File path hoặc directory → scan scope chỉ định
-- Để trống → scan toàn bộ codebase
-- `--staged` → chỉ scan các file đang staged (giống pre-commit hook), nhanh + dùng để self-test trước khi commit
-
-Với `--staged`: lấy danh sách từ `git diff --cached --name-only --diff-filter=ACM` và chỉ review các file đó. Dùng chung regex patterns với `.tas/hooks/security-scan.js` rồi bổ sung deep review bằng agents bên dưới.
-
-Đọc `.tas/checklists/security.md` để lấy checklist.
-
-### Bước 2 — Parallel Security Scan
-
-Launch các agents ĐỒNG THỜI dựa theo stack:
-
-**Agent 1 — `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`.
-> Kiểm tra OWASP Top 10: injection, broken auth, XSS, IDOR, security misconfiguration,
-> sensitive data exposure, insecure deserialization, vulnerable components, logging/monitoring.
-> Kiểm tra thêm: hardcoded secrets, CORS config, anti-forgery tokens, rate limiting.
-> Format: findings theo Critical / High / Medium / Low với file:line và remediation cụ thể.
-> Mỗi finding có: status = Open.
-
-**Agent 2 — `database-reviewer`** (chỉ khi `db_agent = database-reviewer`):
-> Database security review [scope].
-> Tập trung: parameterized queries vs string concatenation, ORM raw query usage,
-> sensitive data stored in plaintext, missing field-level encryption, excessive permissions.
-> Format: findings theo Critical / High / Medium / Low với file:line và remediation.
-
-**Agent 3 — `aws-reviewer`** (chỉ khi `infra_agent = aws-reviewer`):
-> AWS infrastructure security review [scope].
-> Tập trung: IAM overpermission, S3 public access, secrets trong env/config/code,
-> Lambda environment variables, API Gateway auth, VPC security groups.
-> Format: findings theo Critical / High / Medium / Low với file:line và remediation.
-
-Chờ TẤT CẢ agents hoàn thành.
-
-### Bước 3 — Tổng hợp và lưu báo cáo
-
-Gộp findings từ tất cả agents, deduplicate (cùng file:line → gộp), sort theo severity.
-
-Kiểm tra `docs/security-report.md`:
-- **Chưa có**: tạo mới theo template `.tas/templates/Security-Report.md`
-- **Đã có**: append report mới, cập nhật status findings cũ nếu đã được fix
-
-Nội dung report bao gồm:
-- Scan date, scope, stack
-- Findings theo Critical / High / Medium / Low
-- Mỗi finding: file:line, mô tả, remediation, status (Open / Fixed / Accepted Risk)
-- Summary: tổng số findings mỗi severity, số đã fix vs còn open
-
-### Bước 4 — Cập nhật project-status.yaml
-
-```yaml
-artifacts:
-  security_report:
-    file: docs/security-report.md
-    status: [Critical findings present | Clean]
-    last_updated: [ngày hôm nay]
-```
-
-### Bước 5 — Hành động tiếp theo
-
-Nếu có **Critical findings**:
-→ Liệt kê rõ, yêu cầu fix ngay trước khi deploy bất kỳ môi trường nào.
-
-Nếu có **High findings**:
-→ Liệt kê, khuyến nghị fix trước khi merge vào main.
-
-Nếu chỉ có **Medium/Low**:
-→ Tóm tắt, gợi ý fix theo thứ tự ưu tiên.
-
-## Nguyên tắc
-- Phân loại: Critical / High / Medium / Low
-- Mỗi finding phải có recommended fix cụ thể
-- Finding có status: Open | In Progress | Fixed | Accepted Risk
-- KHÔNG hardcode fix — đề xuất remediation pattern, không viết code thay thế

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

@@ -1,50 +0,0 @@
-# /tas-spec $ARGUMENTS
-
-Tạo lightweight spec trước khi code — cho solo dev, prototype, spike, internal tool.
-Khác với `/tas-fix`: có spec document, phù hợp task > 2 giờ hoặc cần track AC.
-
-## Steps
-
-### 1 — Thu thập thông tin
-`$ARGUMENTS` là mô tả task. Nếu chưa đủ rõ, hỏi tối đa 3 câu:
-- **Goal**: Build cái gì? Giải quyết vấn đề gì?
-- **AC**: Done trông như thế nào? (2-5 criteria cụ thể, testable)
-- **Constraints**: Tech constraints, out of scope?
-
-Không hỏi nếu $ARGUMENTS đã đủ rõ.
-
-### 2 — Tạo SPEC.md
-Tạo file `SPEC.md` ở project root:
-
-```markdown
-# {Title}
-> {one-line summary}
-
-**Status:** Draft | **Date:** {today}
-
-## Goal
-{Vấn đề cần giải quyết — không phải solution}
-
-## Acceptance Criteria
-- [ ] {Given/When/Then hoặc testable statement}
-- [ ] ...
-
-## Out of Scope
-- {Gì sẽ không làm}
-
-## Constraints
-{Tech constraints, patterns phải follow — bỏ qua nếu không có}
-
-## Open Questions
-{Câu hỏi chưa có câu trả lời — bỏ qua nếu không có}
-```
-
-### 3 — Next step
-> "SPEC.md đã tạo.
-> - Plan kỹ hơn: `/tas-plan SPEC.md`
-> - Code ngay: `/tas-dev` (cần `require_plan: false` trong tas.yaml)"
-
-## Principles
-- SPEC.md là single source of truth — không tạo thêm file khác
-- Giữ ngắn: mục tiêu < 1 trang
-- AC > 8 items hoặc task > 1 ngày → gợi ý dùng `/tas-story` thay thế

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

@@ -1,16 +0,0 @@
-# /tas-status
-
-Kiểm tra trạng thái hiện tại của dự án TAS.
-
-## Hành động
-1. Cần context từ root/project-status.yaml (CHỈ đọc file này, KHÔNG quét thư mục docs/)
-2. Cần context từ root/tas.yaml để biết workflow config
-3. Dựa vào project-status.yaml, tổng hợp:
-   - Số lượng artifacts đã tạo và status
-   - Số lượng epics/features/stories theo từng status
-   - Phase hiện tại dựa trên trạng thái tổng hợp
-4. Hiển thị bảng trạng thái phases và chi tiết stories theo status.
-
-## Lưu ý
-- Đây là command chỉ đọc, không thay đổi gì
-- Nếu nghi ngờ project-status.yaml lệch thực tế, user có thể chạy /tas-init để quét lại và đồng bộ

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

@@ -1,91 +0,0 @@
-# /tas-story $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Tạo mới hoặc cập nhật User Story document.
-
-**Phạm vi:** Nghiệp vụ, trải nghiệm người dùng, acceptance criteria, test cases.
-**Không thuộc phạm vi:** Kỹ thuật implement, files cần sửa, database schema — đó là việc của `/tas-plan`.
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Viết AC dạng Given/When/Then |
-| **Always** | Set `plan_status: pending` cho Story mới |
-| **Ask** | Khi Story > 8h — gợi ý tách nhỏ |
-| **Never** | Đọc SAD, ADR — kỹ thuật là việc của `/tas-plan` |
-
-## Prerequisite
-- Ít nhất một Feature phải tồn tại
-
-## Hành động
-
-### Chế độ CREATE ($ARGUMENTS là mô tả Story mới, hoặc không có $ARGUMENTS)
-
-**Bước 1 — Xác định Feature**
-- Đọc `project.code` từ root/`tas.yaml`
-- Ưu tiên theo thứ tự:
-  1. Nếu `$ARGUMENTS` chứa Feature ID → dùng luôn
-  2. Nếu context có `parent_id` → dùng luôn
-  3. Hỏi user: "Story này thuộc Feature nào?" — không quét thư mục
-
-**Bước 2 — Thu thập context nghiệp vụ**
-- Đọc file Feature đã xác định (lấy business context, scope, danh sách Stories hiện có)
-- Đọc PRD (nếu có) — chỉ lấy business requirements, user goals
-
-**Bước 3 — Xác định Story ID**
-- Đọc section Stories trong Feature file → xác định index tiếp theo từ danh sách đó
-- KHÔNG quét thư mục
-
-**Bước 4 — Soạn Story với user**
-
-Thảo luận để điền đầy đủ:
-
-a) **User Story**: "As a [role], I want [goal], so that [benefit]"
-
-b) **Business Requirements** (nếu có): business rules đặc thù, constraints từ stakeholders
-
-c) **Design Notes** (nếu có): UI/UX specs, mockup links, flow diagrams
-
-d) **Prerequisites** (nếu có): Stories khác phải done trước
-
-e) **Acceptance Criteria**: mỗi AC một kịch bản Given/When/Then rõ ràng
-
-**Bước 5 — Test Case Prompting**
-
-Sau khi AC được xác nhận, hỏi thêm:
-- "Ngoài happy path, có edge case nào cần test không?" (input rỗng, giá trị biên, concurrent)
-- "Có negative case nào cần cover?" (unauthorized, invalid data, timeout, not found)
-- "Có external dependency nào cần mock khi test?" (API bên ngoài, database state)
-
-Ghi tất cả vào section `## Unit Test Cases`.
-
-**Bước 6 — Tạo file**
-- Đọc `.tas/templates/Story.md` để lấy format
-- Tạo `docs/epics/{code}-Epic-{NNN}-{slug}/{code}-Feature-{NNN}-{slug}/{code}-Story-{NNN}-{slug}.md`
-- Frontmatter: `plan_status: pending`, `plan_date:` để trống
-
-**Bước 7 — Cập nhật project-status.yaml**
-Theo `.claude/rules/common/project-status.md` — thêm entry vào `epics.{EPIC_ID}.features.{FEATURE_ID}.stories`.
-
-**Bước 8 — Thông báo next step**
-> "Story đã tạo. Trước khi SE bắt đầu code, cần chạy `/tas-plan {Story-ID}` để lập kế hoạch kỹ thuật."
-
----
-
-### Chế độ UPDATE ($ARGUMENTS là Story ID, ví dụ: "Story-005")
-
-1. Tìm file qua glob `docs/epics/**/{code}-Story-{ID}-*.md`
-2. Đọc file Story hiện tại
-3. Hỏi user cần thay đổi gì (cập nhật AC, đổi status, thêm test cases, sửa business rule...)
-4. Cập nhật file, thêm entry vào Changelog
-5. Cập nhật `project-status.yaml` theo `.claude/rules/common/project-status.md`.
-
-## Nguyên tắc
-- Story phải đủ nhỏ để hoàn thành trong **4-8 giờ**; nếu lớn hơn → tách thành nhiều Stories
-- Story file = **product artifact**: mô tả *what* và *why*, không phải *how*
-- Story status: New → Committed → In Progress → 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 Story đang làm việc.

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

@@ -1,51 +0,0 @@
-# /tas-verify $ARGUMENTS
-
-Vai trò: PE - Product Engineer
-Verify Feature trên môi trường Staging (Phase 2).
-
-## Prerequisite
-- Feature phải có status "Ready To Verify"
-- Môi trường Staging phải sẵn sàng
-
-## Hành động
-1. Cần context từ root/tas.yaml
-2. $ARGUMENTS là Feature ID. Nếu không có, liệt kê features có status "Ready To Verify".
-3. Tìm file Feature trong cây docs/epics/ (dùng glob)
-4. Cần context từ file Feature hiện tại (đặc biệt section Integration Test Cases và E2E Test Cases)
-
-### Workflow verify:
-4.5. **Chạy Automated Tests** (nếu có):
-
-   **Functional Tests** (Layer 2):
-   - Kiểm tra `docs/epics/{epic-dir}/{feature-dir}/Func-Test-*.md` đã có chưa
-   - Nếu có, hỏi PE: "Chạy functional test suite? Command: `yarn functest:mobile:{feature-slug}` (hoặc `yarn functest:web:{feature-slug}`)"
-   - Ghi nhận pass/fail của func suite
-
-   **E2E Tests** (Layer 3 - nếu Feature có E2E / Acceptance Test Cases):
-   > Launch `e2e-runner`: E2E verification cho Feature {ID}.
-   > Đọc section `## E2E / Acceptance Test Cases` từ Feature file — list từng test case.
-   > Chạy các test cases đó, báo cáo kết quả: Pass/Fail per test case với lý do nếu Fail.
-   > Không tự động fix lỗi — chỉ báo cáo kết quả để PE xác nhận.
-
-5. **Tổng hợp kết quả và xác nhận với PE**:
-   - Hiển thị summary automated test results (Functional + E2E)
-   - Hỏi PE: "Automated tests đã pass. Trên Staging thực có vấn đề nào mà automated tests không catch được không? (UX, business logic, edge case thực tế...)"
-
-6. Với mỗi issue PE báo cáo hoặc test case FAIL:
-   - Hỏi PE mô tả lỗi
-   - Tự động tạo Bug trong thư mục Feature đó (dùng logic /tas-bug)
-   - Bug có reference đến test case gốc (FT ID hoặc E2E ID), hoặc ghi rõ "phát hiện qua manual verify Staging"
-7. Cập nhật file Feature:
-   - Ghi kết quả test (Pass/Fail + ngày) vào từng test case
-   - Nếu tất cả Pass: cập nhật Feature status thành "Verified"
-   - Nếu có Fail: giữ Feature status "Ready To Verify", liệt kê bugs
-8. Cập nhật root/project-status.yaml
-
-## Nguyên tắc
-- KHÔNG skip test case nào, phải verify hết
-- Bug phát hiện ở Phase 2 PHẢI được ghi thành Bug để track
-- Feature chỉ được chuyển sang Phase 3 (Deploy) khi status = "Verified"
-
-## Bước cuối — Token Log
-
-Invoke skill `token-logger`: ghi AI Usage Log vào file Feature đang verify.

package/.claude/rules/common/post-review-agent.md

@@ -1,49 +0,0 @@
-# Post-Implementation Review (Isolated Agent)
-
-Sau khi implement hoặc fix xong, chạy review qua **Agent độc lập** — không dùng session hiện tại để tránh reviewer bias từ quá trình implement.
-
-## Cách dùng
-
-Gọi `Agent` tool với prompt sau (thay thế các placeholder `{}`):
-
-```
-Bạn là code reviewer. Không có context từ session trước — hãy review hoàn toàn khách quan.
-
-Artifact: {path-to-artifact-file}
-Changed files: {danh sách files vừa thay đổi}
-Stack: {stack từ CLAUDE.md}
-
-Thực hiện:
-1. Hygiene scan: debug code còn sót (console.log, debugger, print), secrets hardcoded,
-   commented-out blocks lớn (>5 dòng).
-1b. Silent failure scan — tìm các pattern sau:
-   - Swallowed exceptions: empty catch {}, catch chỉ log nhưng tiếp tục chạy như không có lỗi
-   - Silent async failures: fire-and-forget (unawaited task/Promise), async void (.NET),
-     .catch(() => {}) không xử lý gì
-   - Null blindspots: .FirstOrDefault() dùng trực tiếp không null-check (.NET),
-     optional chaining thiếu trên deeply nested object access (TS/JS),
-     dict.get() result dùng như non-None (Python)
-   - Error propagation sai: HTTP calls không check status trước khi parse,
-     hàm return bool/null khi lỗi thay vì throw (caller bỏ qua kết quả)
-   - Config reads không check existence
-2. Chạy tests: detect test runner (package.json → npm test / *.csproj → dotnet test /
-   pytest.ini → python -m pytest), report kết quả.
-3. Parallel review — launch đồng thời:
-   - code-reviewer: đọc .tas/checklists/code-review.md + .claude/rules/common/code-review.md.
-     Tập trung: naming, architecture, error handling, DRY, function size, nesting depth.
-   - security-reviewer: đọc .claude/rules/common/security.md.
-     Tập trung: OWASP Top 10, injection, hardcoded secrets, auth/authz.
-   - {lang_agent}: đọc .claude/rules/[stack]/coding-style.md + .claude/rules/[stack]/patterns.md.
-     Tập trung: async/await, null handling, type safety, anti-patterns của stack.
-4. Tổng hợp findings: Critical / High / Medium / Low với file:line và fix cụ thể.
-
-Trả về Review Summary đầy đủ.
-```
-
-## Gate Rule
-
-| Kết quả | Hành động |
-|---|---|
-| Có **Critical** hoặc **High** | List findings, **DỪNG**, yêu cầu fix trước khi tiếp tục |
-| Chỉ có **Medium** / **Low** | List gợi ý, hỏi user có muốn fix không, sau đó tiếp tục |
-| Không có findings | Tiếp tục bình thường |

package/.claude/rules/common/stack-detection.md

@@ -1,29 +0,0 @@
-# Stack Detection
-
-Đọc `CLAUDE.md` tại root, tìm section `## Tech Stack`, xác định các biến sau để dùng trong agent prompts và rule file lookups.
-
-## lang_agent — Backend
-
-| Tech Stack chứa | lang_agent |
-|---|---|
-| `.NET` / `C#` | `csharp-reviewer` |
-| `Node.js` / `TypeScript` / `NestJS` / `Express` | `typescript-reviewer` |
-| `Python` / `FastAPI` / `Django` / `Flask` | `python-reviewer` |
-
-**Frontend bổ sung:** nếu Tech Stack chứa `React` → thêm `typescript-reviewer` vào lang_agent (nếu chưa có).
-
-## infra_agent và db_agent — Tùy chọn
-
-| Tech Stack chứa | Biến | Value |
-|---|---|---|
-| `AWS` (Infrastructure) | `infra_agent` | `aws-reviewer` |
-| `MySQL` / `PostgreSQL` / `MSSQL` / `SQL Server` / `SQLite` | `db_agent` | `database-reviewer` |
-
-## Rules directory theo stack
-
-| lang_agent | Rules directory |
-|---|---|
-| `csharp-reviewer` | `.claude/rules/csharp/` |
-| `typescript-reviewer` | `.claude/rules/typescript/` |
-| `python-reviewer` | `.claude/rules/python/` |
-| Frontend / React | `.claude/rules/web/` |

package/.claude/rules/common/token-logging.md

@@ -1,27 +0,0 @@
-# Token Usage Logging
-
-Ghi `## AI Usage Log` vào cuối artifact file khi TAS command hoàn thành.
-
-## Token Estimation
-
-Ước tính từ session awareness: số ký tự mỗi file đã `Read` ÷ 4 ≈ tokens (English/code), ÷ 2 (Vietnamese).
-Số ký tự output artifact ÷ 4. Luôn append `(est.)`. User verify bằng `/cost` (CLI) hoặc `/context` (Desktop app).
-
-## Format
-
-```markdown
----
-
-## AI Usage Log
-
-| # | Date | Command | Input (est.) | Output (est.) |
-|---|------|---------|-------------|---------------|
-| 1 | YYYY-MM-DD | /tas-{name} | ~{N}k | ~{N}k |
-| 2 | YYYY-MM-DD | /tas-{name} (revision) | ~{N}k | ~{N}k |
-| **Total** | | | **~{N}k** | **~{N}k** |
-```
-
-## Update Rules
-
-- **Lần đầu**: section chưa tồn tại → append toàn bộ section với row đầu tiên và row Total
-- **Lần sau**: append row mới trước row Total, cập nhật Total (cộng dồn)

package/.claude/rules/typescript/patterns.md

@@ -1,62 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
-  - "**/*.js"
-  - "**/*.jsx"
----
-# TypeScript/JavaScript Patterns
-
-> This file extends [common/patterns.md](../common/patterns.md) with TypeScript/JavaScript specific content.
-
-## API Response Format
-
-```typescript
-interface ApiResponse<T> {
-  success: boolean
-  data?: T
-  error?: string
-  meta?: {
-    total: number
-    page: number
-    limit: number
-  }
-}
-```
-
-## Custom Hooks Pattern
-
-```typescript
-export function useDebounce<T>(value: T, delay: number): T {
-  const [debouncedValue, setDebouncedValue] = useState<T>(value)
-
-  useEffect(() => {
-    const handler = setTimeout(() => setDebouncedValue(value), delay)
-    return () => clearTimeout(handler)
-  }, [value, delay])
-
-  return debouncedValue
-}
-```
-
-## Repository Pattern
-
-```typescript
-interface Repository<T> {
-  findAll(filters?: Filters): Promise<T[]>
-  findById(id: string): Promise<T | null>
-  create(data: CreateDto): Promise<T>
-  update(id: string, data: UpdateDto): Promise<T>
-  delete(id: string): Promise<void>
-}
-```
-
-## Performance Anti-Patterns
-
-Avoid these in Node.js backends:
-
-- **Sequential awaits that could be parallel**: use `Promise.all()` when calls are independent
-- **CPU-blocking on event loop**: offload heavy computation to worker threads
-- **Missing connection pooling**: never create a new DB connection per request — use pooled clients
-- **ORM N+1**: missing `include`/`select` in Prisma/Sequelize — use eager loading or DataLoader for GraphQL
-- **Large file reads without streaming**: avoid `fs.readFile` on large files — use streams instead

package/.claude/rules/typescript/security.md

@@ -1,28 +0,0 @@
----
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
-  - "**/*.js"
-  - "**/*.jsx"
----
-# TypeScript/JavaScript Security
-
-> This file extends [common/security.md](../common/security.md) with TypeScript/JavaScript specific content.
-
-## Secret Management
-
-```typescript
-// NEVER: Hardcoded secrets
-const apiKey = "sk-proj-xxxxx"
-
-// ALWAYS: Environment variables
-const apiKey = process.env.OPENAI_API_KEY
-
-if (!apiKey) {
-  throw new Error('OPENAI_API_KEY not configured')
-}
-```
-
-## Agent Support
-
-- Use **security-reviewer** skill for comprehensive security audits

package/.claude/settings.local.json

@@ -1,38 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Skill(*)",
-      "Bash(*)",
-      "Edit(*)",
-      "Write(*)",
-      "Read(*)",
-      "Glob(*)",
-      "Grep(*)",
-      "Agent(*)",
-      "ExitPlanMode",
-      "EnterWorktree",
-      "ExitWorktree",
-      "TodoWrite",
-      "NotebookEdit",
-      "CronCreate",
-      "CronDelete",
-      "CronList",
-      "RemoteTrigger(*)",
-      "TaskOutput",
-      "TaskStop",
-      "AskUserQuestion"
-    ],
-    "deny": [
-      "Read:env:*",
-      "Bash:sudo:*",
-      "WebSearch",
-      "WebFetch",
-      "Skill(mcp__web_reader__webReader)",
-      "Skill(mcp__4_5v_mcp__analyze_image)"
-    ]
-  },
-  "enabledMcpjsonServers": [
-    "figma"
-  ],
-  "enableAllProjectMcpServers": true
-}

package/.claude/skills/ado-integration/SKILL.md

@@ -1,75 +0,0 @@
----
-name: ado-integration
-description: |
-  Azure DevOps integration. Auto-invoke khi user nhắc đến:
-  sync ADO, push to board, pull work item, update status on ADO,
-  create work item on ADO, hoặc bất kỳ thao tác liên quan Azure DevOps.
-allowed-tools: Read, Write, Edit, Bash, Grep
----
-
-# ADO Integration Skill
-
-Cho phép đồng bộ hai chiều giữa file .md trong repo và work items trên Azure DevOps.
-ADO sync là **thao tác có chủ đích** — không tự động sau mỗi lần edit file.
-
-## When to Use
-
-- User yêu cầu sync, push, pull work item lên/từ ADO
-- User chạy `/ado-create`, `/ado-update`, `/ado-status`, `/ado-get`, `/ado-delete`
-- KHÔNG invoke khi: user chỉ edit file .md thông thường mà không nhắc đến ADO
-
-## Always / Ask / Never
-
-| | Hành động |
-|---|---|
-| **Always** | Đọc `tas.yaml` và kiểm tra `ado.enabled` trước bất kỳ thao tác nào |
-| **Always** | Hiển thị ADO ID và URL sau mỗi create/update thành công |
-| **Always** | Cập nhật frontmatter `ado_id`, `ado_state`, `last_ado_sync` trong file .md sau sync |
-| **Ask** | Khi sync bulk nhiều items cùng lúc — confirm list trước khi chạy |
-| **Ask** | Khi phát hiện conflict giữa file .md và ADO item (ai là source of truth?) |
-| **Ask** | Khi delete work item — đây là thao tác không thể undo |
-| **Never** | Auto-sync mỗi khi file .md được edit (quá aggressive, dễ gây noise) |
-| **Never** | Xóa ADO item mà không có xác nhận rõ ràng từ user |
-| **Never** | Tạo duplicate work item nếu đã có `ado_id` trong frontmatter |
-
-## Bước đầu tiên — Kiểm tra ADO enabled
-
-Trước khi thực hiện bất kỳ thao tác nào, đọc `tas.yaml` tại root và kiểm tra `ado.enabled`:
-- Nếu `ado.enabled: false` hoặc field không tồn tại: thông báo "ADO integration bị tắt trong tas.yaml (`ado.enabled: false`). Bật lên nếu project dùng ADO." rồi dừng lại.
-- Nếu `ado.enabled: true`: tiếp tục bình thường.
-
-## Prerequisites
-
-- Azure CLI + extension azure-devops: `az extension add --name azure-devops --upgrade`
-- Python 3.8+ với pyyaml: `pip install pyyaml`
-- PAT trong file .env: `AzureDevops_Personal_AccessToken=your-pat-here`
-
-## Commands
-
-Tất cả ADO commands chạy qua: `python .tas/tools/tas-ado.py <command> [args]`
-
-Hoặc dùng slash commands:
-- `/ado-create <type> <temp-id> [--parent-id <id>]`
-- `/ado-get <ado-id>`
-- `/ado-update <type> <ado-id> [--assign <name>] [--status <state>]`
-- `/ado-status <ado-id> --status <state>`
-- `/ado-delete <type> <ado-id>`
-
-## File Convention
-
-- Tên file: `{type}-{ado_id}-{slug-title}.md`
-- Mỗi file có frontmatter YAML: `ado_id`, `ado_type`, `ado_state`, `last_ado_sync`
-- File .md là single source of truth, sync lên ADO khi cần
-
-## Red Flags
-
-- File có `ado_id` nhưng state trong file khác ADO → confirm với user trước khi ghi đè
-- PAT hết hạn → hướng dẫn rotate, không log token ra stdout
-- `ado.enabled: true` nhưng project chưa setup Azure CLI → check prerequisites trước
-
-## Anti-Rationalization
-
-| Rationalization | Counter |
-|---|---|
-| "Auto-sync tiện hơn, không cần nhớ" | Hook auto-sync gây unintended pushes khi edit draft — sync phải có chủ đích |
-| "Delete chắc OK, mình biết mình đang làm gì" | ADO delete không có undo — luôn confirm, dù user trông có vẻ chắc chắn |