@torus-engineering/tas-kit 1.5.1 → 1.7.0

package/.tas/templates/SAD.md

@@ -7,58 +7,268 @@
 ---
 
 ## 1. Executive Summary
+
+<!-- MANDATORY. Viết cho người đọc không có technical background.
+  Bắt buộc:
+  - 1.1 Purpose: Tại sao SAD này tồn tại, vấn đề gì cần giải quyết
+  - 1.2 Scope: Hệ thống nào, ranh giới nào được/không được cover
+  - 1.3 Key Objectives: 3-5 mục tiêu kiến trúc cụ thể, đo lường được
+  Format: Prose ngắn, tối đa 1 trang tổng cộng -->
+
 ### 1.1 Purpose
 ### 1.2 Scope
 ### 1.3 Key Objectives
 
+---
+
 ## 2. Architecture Vision
+
+<!-- MANDATORY.
+  Bắt buộc:
+  - 2.1 Vision Statement: 1-2 câu mô tả "kiến trúc này hướng tới điều gì"
+  - 2.2 Architecture Principles: 4-8 nguyên tắc dẫn dắt quyết định thiết kế
+    (vd: Stateless services, API-first, Defense in depth, Fail fast)
+  - 2.3 Constraints & Assumptions: Ràng buộc kỹ thuật/tổ chức, giả định đang được chấp nhận
+  Format: Bullet list cho principles và constraints -->
+
 ### 2.1 Vision Statement
 ### 2.2 Architecture Principles
 ### 2.3 Constraints & Assumptions
 
+---
+
 ## 3. Business Requirements
+
+<!-- MANDATORY.
+  Bắt buộc:
+  - 3.1 Business Problem: Mô tả bài toán kinh doanh cần giải quyết
+  - 3.2 Stakeholders: Bảng stakeholder (role, concerns, influence)
+  - 3.3 Functional Requirements: Danh sách FR-xxx, mỗi item có ID để trace
+  - 3.4 Non-Functional Requirements: Danh sách NFR với metric cụ thể
+    (vd: Latency P99 < 300ms, Availability 99.9%, RPS 5000)
+  Nên có: Priority (Must/Should/Could) cho mỗi requirement
+  Format: Table hoặc numbered list với ID (FR-001, NFR-001) -->
+
 ### 3.1 Business Problem
 ### 3.2 Stakeholders
 ### 3.3 Functional Requirements
 ### 3.4 Non-Functional Requirements
 
+---
+
 ## 4. Technology Baseline
+
+<!-- MANDATORY.
+  Bắt buộc:
+  - 4.1 Current State: Hệ thống hiện tại (nếu là greenfield thì ghi rõ)
+  - 4.2 Technology Stack: Bảng layer → technology → version → rationale
+    (Frontend / Backend / Database / Infrastructure / Messaging / Monitoring)
+  - 4.3 Dependencies: External services, third-party APIs, shared platforms
+  Nên có: Diagram current-state nếu là migration/modernization
+  Format: Table cho Technology Stack -->
+
 ### 4.1 Current State
 ### 4.2 Technology Stack
 ### 4.3 Dependencies
 
+---
+
 ## 5. System Context (C4 Level 1)
-<!-- Dùng Mermaid flow diagram, :::mermaid wrapper, không dùng () -->
 
-## 6. Logical View (C4 Level 2 - Container)
-<!-- Dùng Mermaid flow diagram -->
+<!-- MANDATORY. Trả lời: "Hệ thống này nằm ở đâu trong hệ sinh thái?"
+  Bắt buộc:
+  - Mermaid flowchart: hệ thống ở giữa, xung quanh là users và external systems
+  - Chú thích mỗi external system: tên, vai trò, protocol giao tiếp
+  Không cần: chi tiết nội bộ của hệ thống (để C4 Level 2)
+  Format: Mermaid flowchart (dùng :::mermaid wrapper, không dùng () trong node label)
+
+  Ví dụ:
+  :::mermaid
+  flowchart TD
+    U[fa:fa-user End User] -- |HTTPS| SYS[Your System]
+    SYS -- |REST| EXT1[Payment Gateway]
+    SYS -- |SMTP| EXT2[Email Service]
+    ADMIN[fa:fa-user Admin] -- |HTTPS| SYS
+  ::: -->
+
+---
+
+## 6. Logical View (C4 Level 2 — Container)
+
+<!-- MANDATORY. Trả lời: "Hệ thống gồm những container nào?"
+  Bắt buộc:
+  - Mermaid flowchart: tất cả containers (web app, API, DB, cache, queue, ...)
+  - Mỗi container: tên, technology, vai trò chính
+  - Luồng tương tác giữa containers với protocol/label
+  Nên có: Phân nhóm theo bounded context nếu hệ thống lớn
+  Format: Mermaid flowchart với subgraph để nhóm theo domain
+
+  Ví dụ node: WebApp["Web App\n(Next.js / Vercel)"] -->
+
+---
 
 ## 7. Component View (C4 Level 3)
-<!-- Dùng Mermaid flow diagram -->
+
+<!-- CONDITIONAL — Bắt buộc nếu hệ thống có độ phức tạp cao hoặc team mới.
+  Trả lời: "Bên trong mỗi container có components nào?"
+  Hướng dẫn:
+  - Mỗi container phức tạp → một subsection riêng (7.1, 7.2, ...)
+  - Container đơn giản (chỉ proxy, static file, thin wrapper) → bỏ qua
+  - Không cần drill vào mọi container — chỉ những container có internal logic đáng kể
+  Mỗi subsection bắt buộc:
+  - Mermaid flowchart liệt kê components bên trong container đó
+  - Mỗi component: tên, trách nhiệm chính, interface exposed
+  - Dependency direction giữa components (tránh circular)
+  Format: Mermaid flowchart với subgraph bao ngoài (tên container), nodes là components
+
+  Ví dụ:
+  :::mermaid
+  flowchart TD
+    subgraph API["API Service (NestJS)"]
+      Router[Route Handler] -- AuthMW[Auth Middleware]
+      AuthMW -- Controller[Order Controller]
+      Controller -- Service[Order Service]
+      Service -- Repo[Order Repository]
+      Service -- Queue[Queue Publisher]
+    end
+  ::: -->
+
+### 7.1 [Container Name]
+
+<!-- Bắt buộc: Mermaid component diagram như hướng dẫn trên.
+  Nên có: Mô tả ngắn vai trò của container này trước diagram. -->
+
+### 7.2 [Container Name]
+
+<!-- Thêm subsection cho mỗi container phức tạp. Xóa subsection này nếu không cần. -->
+
+---
 
 ## 8. Data Architecture & ERD
-<!-- Dùng Mermaid erDiagram -->
+
+<!-- MANDATORY nếu hệ thống có persistence layer.
+  Bắt buộc:
+  - ERD: entities, attributes (chỉ key fields), relationships với cardinality
+  - Data flow overview: data đi từ đâu đến đâu, transform ở đâu
+  Nên có:
+  - Data classification: PII / Sensitive / Internal / Public cho mỗi entity
+  - Retention policy nếu có compliance requirement
+  - Sharding/partitioning strategy nếu data scale lớn
+  Format: Mermaid erDiagram cho ERD -->
+
+---
 
 ## 9. Integration & Data Flow
-<!-- Dùng Mermaid sequenceDiagram -->
+
+<!-- MANDATORY nếu hệ thống tích hợp với external services hoặc có async flows.
+  Bắt buộc:
+  - Sequence diagram cho mỗi critical flow (auth, payment, order, ...)
+  - Async flows: queue/event-driven patterns phải được diagram rõ
+  Nên có: Error/retry flows cho critical paths
+  Format: Mermaid sequenceDiagram, một diagram per flow -->
+
+### 9.1 API Design Principles
+
+<!-- MANDATORY nếu hệ thống expose API (internal hoặc external).
+  Bắt buộc:
+  - API Style: REST / GraphQL / gRPC / Event-driven — và lý do chọn
+  - Versioning strategy: URL path (/v1/) vs header vs query param
+  - Authentication scheme: Bearer JWT / API Key / OAuth2 / mTLS
+  - Standard error format: HTTP status codes, error body structure
+  Nên có:
+  - Rate limiting approach (per-user, per-IP, tiered)
+  - Pagination convention (cursor vs offset)
+  - Idempotency handling cho mutating operations
+  Không đưa vào đây: endpoint list, request/response schema chi tiết
+    → Những thứ đó thuộc API Contract document riêng (viết khi implement)
+  Format: Bullet list hoặc table ngắn gọn -->
+
+---
 
 ## 10. Security Architecture
 
-## 11. Deployment View
-<!-- Dùng Mermaid flow diagram -->
+<!-- MANDATORY. Đây là architectural concern, không phải implementation detail.
+  Bắt buộc:
+  - Threat Model: attack surfaces, trust boundaries, top threats (dùng STRIDE nếu cần)
+  - Identity & Auth Flow: AuthN/AuthZ mechanism, token lifecycle, privilege escalation path
+  - Data Classification: PII / Sensitive / Internal / Public — handling rules per class
+  - Network Security Zones: public / DMZ / private / data tier và rules giữa các zones
+  - Encryption: at-rest (algorithm, key management) và in-transit (TLS version, cert strategy)
+  Nên có:
+  - Secrets management approach (Vault, AWS SSM, env vars strategy)
+  - Audit logging scope: what events must be logged, retention
+  - Compliance requirements: GDPR, PCI-DSS, SOC2, ... nếu applicable
+  Format:
+  - Threat model: table (Threat | Vector | Mitigation)
+  - Auth flow: Mermaid sequenceDiagram
+  - Network zones: Mermaid flowchart với subgraph per zone -->
+
+---
+
+## 11. NFR Strategies
+
+<!-- MANDATORY. Mỗi NFR-xxx trong Section 3.4 phải có strategy tương ứng ở đây (reference bằng ID).
+  Bắt buộc — cover các categories sau nếu có NFR liên quan:
+  - Performance: caching strategy (L1/L2/CDN), DB indexing, query optimization approach
+  - Scalability: horizontal vs vertical, stateless design, queue-based decoupling
+  - Availability: redundancy model (Active-Active/Active-Passive), failover mechanism, SLA target
+  - Resilience: circuit breaker, retry with backoff, bulkhead, timeout policy
+  - Observability: structured logging, distributed tracing, metrics & alerting thresholds
+  Nên có:
+  - Capacity planning baseline: expected load, growth projection, scale trigger points
+  - DR strategy: RPO/RTO targets, backup frequency, restore procedure overview
+  Format: Table với cột NFR ID để trace ngược về Section 3.4
+  | NFR ID | Category | Target | Strategy | Notes |
+  |--------|----------|--------|----------|-------|
+  | NFR-001 | Latency | P99 < 300ms | Redis cache L2, read replicas | Cache TTL 5m |
+  | NFR-002 | Availability | 99.9% | Active-Active, 2 AZs | Health check interval 10s | -->
+
+---
 
-## 12. Non-Functional Requirements
+## 12. Deployment Topology
+
+<!-- MANDATORY. Trả lời: "Các components chạy ở đâu trong infrastructure?"
+  Bắt buộc:
+  - Infrastructure diagram: regions, AZs, VPC/subnets, load balancers, entry points
+  - Component-to-infrastructure mapping: service X → ECS Fargate, DB → RDS Multi-AZ, ...
+  - Traffic entry points: CDN → ALB → API Gateway → Service flow
+  - Environment matrix: dev / staging / prod — sự khác nhau về scale, config, isolation
+  Nên có:
+  - Network topology: public subnet / private subnet / data subnet và routing rules
+  - CI/CD pipeline overview: build → test → deploy flow và approval gates
+  - Container orchestration config nếu dùng K8s/ECS (namespace, resource limits)
+  Format:
+  - Mermaid flowchart với subgraph per environment tier hoặc per network zone
+  - Environment matrix: table (Component | Dev | Staging | Prod) -->
+
+---
 
 ## 13. Architectural Decisions
+
+<!-- MANDATORY. Ghi lại mọi quyết định kiến trúc quan trọng và lý do.
+  Bắt buộc: Mỗi ADR entry gồm Decision, Status, Date, Rationale
+  Nên có: Alternatives considered và tại sao không chọn
+  Format: Table — thêm row mỗi khi có quyết định mới
+  Status values: Proposed | Accepted | Deprecated | Superseded -->
+
 | ID | Decision | Status | Date | Rationale |
 |----|----------|--------|------|-----------|
 
+---
+
 ## 14. Risks & Mitigation
-| Risk | Impact | Probability | Mitigation |
-|------|--------|-------------|------------|
+
+<!-- MANDATORY.
+  Bắt buộc: Risk, Impact (H/M/L), Probability (H/M/L), Mitigation action
+  Nên có: Owner và review date cho mỗi risk
+  Format: Table, sắp xếp theo Impact × Probability giảm dần -->
+
+| Risk | Impact | Probability | Mitigation | Owner |
+|------|--------|-------------|------------|-------|
 
 ---
 
 ## Changelog
+
 | Date | Version | Changes | Author |
 |------|---------|---------|--------|

package/.tas/templates/Story.md

@@ -7,6 +7,8 @@ ado_assigned_to:
 ado_created:
 last_ado_sync:
 parent_ado_id:
+plan_status: pending
+plan_date:
 ---
 # Story-{NNN}: {Title}
 
@@ -20,25 +22,20 @@ parent_ado_id:
 As a {role}, I want {goal}, so that {benefit}.
 
 ---
-## Context from PRD (nếu có)
-*(Chỉ thêm section này khi Story có business requirements đặc biệt cần lưu ý)*
+## Business Requirements (nếu có)
+*(Yêu cầu nghiệp vụ đặc biệt, business rules, constraints từ stakeholders — chỉ thêm khi cần)*
 
 ---
-## Context from SAD/ADR (nếu có)
-*(Chỉ thêm section này khi Story có architecture decisions, patterns, hoặc constraints cần tuân thủ)*
-
-- **Relevant Components:** {components liên quan}
-- **Patterns to follow:** {patterns từ SAD/ADR}
-- **Constraints:** {nếu có}
+## Design Notes (nếu có)
+*(UI/UX specs, mockup links, design decisions, flow diagrams — chỉ thêm khi cần)*
 
 ---
-## Prerequisites from Feature (nếu có)
-*(Chỉ thêm section này khi Story có dependency từ Stories khác hoặc prerequisites)*
+## Prerequisites (nếu có)
+*(Dependencies từ Stories khác hoặc điều kiện phải có trước — chỉ thêm khi cần)*
 
 ---
-## Implementation Context
-
 ## Acceptance Criteria
+
 ### AC-1: {title}
 - **Given** {precondition}
 - **When** {action}
@@ -49,13 +46,9 @@ As a {role}, I want {goal}, so that {benefit}.
 - **When** {action}
 - **Then** {expected result}
 
-## Technical Notes
-- **Files to modify:** {list}
-- **Patterns:** {reference to SAD/ADR}
-- **Database changes:** {if any}
-
+---
 ## Unit Test Cases
-SE implement trong code. PE thiết kế happy path + edge cases + negative cases khi tạo Story.
+*(PE thiết kế happy path + edge cases + negative cases. SE implement trong code.)*
 
 ### Happy Path
 | ID | Description | Input | Expected Output |
@@ -75,7 +68,14 @@ SE implement trong code. PE thiết kế happy path + edge cases + negative case
 ### Dependencies to Mock
 - {external API, database state, third-party service...}
 
+---
+<!-- ═══════════════════════════════════════════════════════════════════
+     TECHNICAL PLAN — generated by /tas-plan, do not edit manually
+     ═══════════════════════════════════════════════════════════════════ -->
+
+---
 ## Definition of Done
+- [ ] Technical plan completed (`/tas-plan`)
 - [ ] Code implemented
 - [ ] Unit tests pass
 - [ ] Code review passed

package/CLAUDE-Example.md

@@ -41,7 +41,7 @@ This project uses Torus-Agentic-SDLC (TAS) kit.
 ## Commands
 Type /tas-status to see current project state.
 Type /tas-[artifact] to create or update artifacts (prd, sad, adr, epic, feature, story, design).
-Type /tas-dev-story to implement a story.
+Type /tas-dev to implement a story.
 Type /tas-verify to verify a Feature on Staging (Phase 2).
 Type /tas-review-code, /tas-brainstorm, /tas-bug, /tas-security-check for dev workflows.
 

package/README.md

@@ -19,9 +19,9 @@ npx @torus-engineering/tas-kit install --yes    # skip confirmation prompts
 
 ```
 .claude/
-  commands/   20 slash commands (/tas-*, /ado-*)
+  commands/   22 slash commands (/tas-*, /ado-*)
   skills/     3 auto-invoked skills
-  agents/     2 specialized subagents
+  agents/     29 specialized subagents
 .tas/
   templates/  Markdown templates (PRD, SAD, ADR, Epic, Feature, Story...)
   checklists/ Code review, story done, security checklists
@@ -49,11 +49,14 @@ tas.yaml      Flow configuration template (edit this for your project)
 | `/tas-epic` | Create/update Epic |
 | `/tas-feature` | Create/update Feature |
 | `/tas-story` | Create/update Story |
-| `/tas-dev-story` | Implement a story (agentic) |
-| `/tas-review-code` | Code review with checklist |
+| `/tas-spec` | Lightweight spec (solo / prototype) |
+| `/tas-plan` | Plan technical implementation |
+| `/tas-dev` | Implement a story (agentic) |
+| `/tas-fix` | Quick fix without full story flow |
+| `/tas-review` | Code review with checklist |
 | `/tas-brainstorm` | Brainstorm solutions |
 | `/tas-bug` | Create bug report |
-| `/tas-security-check` | Security review |
+| `/tas-security` | Security review |
 | `/tas-verify` | Verify feature on staging |
 | `/ado-*` | Azure DevOps integration |
 
@@ -62,6 +65,18 @@ tas.yaml      Flow configuration template (edit this for your project)
 - Node.js 18+
 - [Claude Code](https://claude.ai/code)
 
+## Publishing to npm
+
+```bash
+# Bump version (patch / minor / major)
+npm version patch
+
+# Publish to npm registry
+npm publish --access=public --auth-type=web
+```
+
+`--auth-type=web` mở trình duyệt để xác thực nếu chưa login. Chạy `npm whoami` để kiểm tra đang đăng nhập với account nào trước khi publish.
+
 ## Documentation
 
 See `.tas/README.md` after install for full kit documentation.

package/bin/cli.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { install } from '../lib/install.js';
+import { install, update } from '../lib/install.js';
 
 const args = process.argv.slice(2);
 const command = args[0];
@@ -9,7 +9,12 @@ function printHelp() {
 tas-kit — Torus Agentic SDLC Kit installer
 
 Usage:
-  npx @torus-engineering/tas-kit install [options]
+  npx @torus-engineering/tas-kit <command> [options]
+
+Commands:
+  install   Copy TAS Kit files into a project (first-time setup)
+  update    Overwrite .claude/ and .tas/ with the latest kit version
+            (preserves CLAUDE.md, tas.yaml, .env.example)
 
 Options:
   --directory <path>   Target directory (default: current working directory)
@@ -19,7 +24,8 @@ Options:
 Examples:
   npx @torus-engineering/tas-kit install
   npx @torus-engineering/tas-kit install --directory /path/to/my-project
-  npx @torus-engineering/tas-kit install --yes
+  npx @torus-engineering/tas-kit update
+  npx @torus-engineering/tas-kit update --yes
   `.trim());
 }
 
@@ -28,7 +34,7 @@ if (!command || command === '--help' || command === '-h') {
   process.exit(0);
 }
 
-if (command !== 'install') {
+if (command !== 'install' && command !== 'update') {
   console.error(`Unknown command: "${command}"\n`);
   printHelp();
   process.exit(1);
@@ -43,7 +49,8 @@ for (let i = 1; i < args.length; i++) {
   }
 }
 
-install(opts).catch((err) => {
-  console.error('\nInstall failed:', err.message);
+const runner = command === 'update' ? update : install;
+runner(opts).catch((err) => {
+  console.error(`\n${command === 'update' ? 'Update' : 'Install'} failed:`, err.message);
   process.exit(1);
 });

package/lib/install.js

@@ -23,6 +23,63 @@ async function copyDir(src, dest) {
   await fs.cp(src, dest, { recursive: true });
 }
 
+export async function update({ directory, yes }) {
+  const target = path.resolve(directory);
+
+  // Must already have .claude/ or .tas/ — otherwise suggest install
+  const claudeExists = await exists(path.join(target, '.claude'));
+  const tasExists = await exists(path.join(target, '.tas'));
+  if (!claudeExists && !tasExists) {
+    console.error(`  ERROR: No TAS Kit found in: ${target}`);
+    console.error(`  Run "install" first to set up TAS Kit.`);
+    process.exit(1);
+  }
+
+  console.log(`\nUpdating TAS Kit in: ${target}\n`);
+
+  if (!yes) {
+    console.warn(`  This will overwrite .claude/ and .tas/ with the latest kit files.`);
+    console.warn(`  Your CLAUDE.md, tas.yaml, and .env.example will NOT be touched.\n`);
+    const ok = await confirm('Continue?');
+    if (!ok) {
+      console.log('Update cancelled.');
+      process.exit(0);
+    }
+    console.log();
+  }
+
+  // Overwrite .claude/
+  await copyDir(
+    path.join(PACKAGE_DIR, '.claude'),
+    path.join(target, '.claude')
+  );
+  console.log('  [ok] .claude/ (updated)');
+
+  // Overwrite .tas/
+  await copyDir(
+    path.join(PACKAGE_DIR, '.tas'),
+    path.join(target, '.tas')
+  );
+  console.log('  [ok] .tas/ (updated)');
+
+  // Set executable bit on tas-ado.py (Unix/macOS)
+  if (process.platform !== 'win32') {
+    const adoPy = path.join(target, '.tas', 'tools', 'tas-ado.py');
+    if (await exists(adoPy)) {
+      await fs.chmod(adoPy, 0o755);
+    }
+  }
+
+  console.log(`  [--] CLAUDE.md, tas.yaml, .env.example — not touched`);
+
+  console.log(`
+TAS Kit updated successfully!
+
+If this version added new settings or templates, check the changelog
+and manually merge changes into your CLAUDE.md and tas.yaml if needed.
+  `);
+}
+
 export async function install({ directory, yes }) {
   const target = path.resolve(directory);
 
@@ -73,12 +130,17 @@ export async function install({ directory, yes }) {
     console.log('  [--] CLAUDE.md already exists, skipped');
   }
 
-  // Copy .env.example
-  await fs.copyFile(
-    path.join(PACKAGE_DIR, '.env.example'),
-    path.join(target, '.env.example')
-  );
-  console.log('  [ok] .env.example');
+  // Copy .env.example (only if absent)
+  const envExampleTarget = path.join(target, '.env.example');
+  if (!(await exists(envExampleTarget))) {
+    await fs.copyFile(
+      path.join(PACKAGE_DIR, '.env.example'),
+      envExampleTarget
+    );
+    console.log('  [ok] .env.example');
+  } else {
+    console.log('  [--] .env.example already exists, skipped');
+  }
 
   // Copy tas-example.yaml as tas.yaml (only if absent)
   const tasYamlTarget = path.join(target, 'tas.yaml');

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@torus-engineering/tas-kit",
-  "version": "1.5.1",
-  "description": "Torus Agentic SDLC Kit — Claude Code commands, skills and workflows for modern AI-assisted SDLC",
+  "version": "1.7.0",
+  "description": "Torus Agentic SDLC Kit — Collection of commands, skills, rules, hooks, agents and workflows for modern AI-First SDLC",
   "type": "module",
   "bin": {
     "tas-kit": "bin/cli.js"

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

@@ -1,61 +0,0 @@
-# /tas-dev-story $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Implement một User Story.
-
-## QUAN TRỌNG - Quy tắc đọc file
-- CHỈ đọc DUY NHẤT Story file. Không đọc thêm bất kỳ file nào khác.
-- KHÔNG đọc PRD, SAD, ADR, Design-Spec.
-- 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).
-- Nếu cần tra cứu thêm, PHẢI hỏi user xác nhận trước khi đọc bất kỳ file nào.
-
-## Hành động
-1. $ARGUMENTS là Story ID hoặc file path. Nếu không có, quét docs/epics/**/Story-*.md tìm stories có status Committed.
-2. Đọc Story file.
-3. **Phân tích kiến trúc:**
-   - Kiểm tra vấn đề kỹ thuật đã được mô tả trong SAD/ADR chưa (qua section Context from SAD/ADR trong Story)
-   - Nếu có và không thay đổi kiến trúc → Chuyển sang implement, mô tả giải pháp thi công (API, DB, FE component, config...)
-   - Nếu chưa có hoặc là thay đổi kiến trúc lớn → **TẠO ADR mới**:
-     - Command: `/tas-adr "{Tiêu đề quyết định kiến trúc}"`
-     - Template: `.tas/templates/ADR.md`
-     - Điền đầy đủ: Context, Decision, Rationale, Alternatives, Consequences
-     - Trong section Consequences, thêm subsection **SAD Updates** liệt kê các thay đổi cần cập nhật vào SAD
-4. Bắt đầu implement dựa trên nội dung Story và ADR (nếu đã tạo).
-
-## Workflow
-### Nếu use_tdd = true trong root/tas.yaml:
-a. Viết test cases TRƯỚC (Red phase)
-   - Unit tests theo acceptance criteria trong Story
-   - Chạy tests, xác nhận FAIL
-b. Implement code (Green phase)
-   - Viết code tối thiểu để pass tests
-c. Refactor
-   - Clean up code
-   - Đảm bảo tests vẫn pass
-
-### Nếu use_tdd = false:
-a. Implement code theo acceptance criteria trong Story
-b. Viết unit tests cover các cases
-c. Chạy tests, fix nếu fail
-
-## Sau khi code xong
-3. Đọc .tas/checklists/story-done.md, verify từng mục, sau đó tick vào section ## Definition of Done trong file Story:
-   - `- [x] Code implemented` nếu đã implement xong
-   - `- [x] Unit tests pass` nếu tests đã chạy pass
-   - `- [x] No regression` nếu toàn bộ test suite pass
-   - `- [x] Documentation updated (if needed)` nếu đã cập nhật
-   - `- [ ] Code review passed` — KHÔNG tick, để sau khi chạy /tas-review-code
-   - `- [ ] Acceptance criteria verified` — KHÔNG tick, để PE verify
-4. Tạo commit message theo conventions trong CLAUDE.md
-5. Nhắc user: chạy /tas-review-code để review và tự test lại ở local trước khi chuyển status
-
-## Nguyên tắc
-- KHÔNG implement ngoài scope của Story
-- Mỗi public method PHẢI có XML doc comment
-- **Khi nào cần tạo ADR:**
-  - Thay đổi kiến trúc ảnh hưởng nhiều components
-  - Thêm mới design pattern hoặc framework
-  - Đổi data flow hoặc integration pattern
-  - Quyết định trade-off kỹ thuật quan trọng
-  - Thay đổi đã ảnh hưởng đến SAD

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

@@ -1,42 +0,0 @@
-# /tas-review-code $ARGUMENTS
-
-Vai trò: SE - Software Engineer
-Review code thay đổi gần nhất hoặc một file/PR cụ thể.
-
-## Hành động
-1. Cần context từ root/tas.yaml và .tas/checklists/code-review.md
-2. $ARGUMENTS có thể là: file path, hoặc để trống (review git diff)
-3. Nếu $ARGUMENTS trống: lấy git diff của staged changes hoặc last commit
-4. Review theo checklist:
-   - Naming conventions
-   - Architecture alignment (so với SAD)
-   - Error handling
-   - Security concerns
-   - Test coverage
-   - Performance implications
-5. Output: danh sách findings phân loại theo severity (Critical/Major/Minor/Info)
-
-## Sau khi review
-6. Nếu có findings Critical/Major: liệt kê rõ, yêu cầu human fix trước khi tiếp tục.
-7. Khi human xác nhận đã fix hết tất cả issues:
-   - Tick `- [x] Code review passed` trong section ## Definition of Done của file Story
-8. 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?"
-9. Nếu human xác nhận Yes, cập nhật file Story:
-   a. Dòng **Status:** trong header → Deploy Test
-   b. Cập nhật Technical notes nếu có thay đổi phát sinh trong quá trình review
-   c. Thêm dòng vào section Changelog trong Story: ngày, "Code review passed, moved to Deploy Test"
-10. Cập nhật Story trên ADO:
-   - Chạy /ado-update story <ado-id> --status "Deploy Test" để push nội dung mới nhất và đổi state
-11. Cập nhật file Feature cha:
-   a. Dòng **Status:** trong header → In Progress
-   b. Cột Status của Story trong bảng ## User Stories → Deploy Test
-   c. Thêm dòng Changelog trong Feature: ngày, "Story <id> moved to Deploy Test"
-12. Cập nhật Feature trên ADO:
-   - Chạy /ado-update feature <feature-ado-id> --status "In Progress" để push nội dung mới nhất và đổi state
-13. Cập nhật root/project-status.yaml: Story → Deploy Test, Feature → In Progress
-
-## Nguyên tắc
-- Review khách quan, chỉ ra cụ thể dòng code 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
-- KHÔNG tự động chuyển status mà không có xác nhận của human