@torus-engineering/tas-kit 1.9.0 → 1.11.1

package/.tas/templates/ADR.md

@@ -3,29 +3,29 @@
 > **Status:** Proposed | Accepted | Deprecated | Superseded
 > **Date:** [Date]
 > **Author:** [SE name]
-> **Supersedes:** [ADR-NNN nếu có]
-> **Related:** [ADR-NNN nếu có]
+> **Supersedes:** [ADR-NNN if any]
+> **Related:** [ADR-NNN if any]
 
 ## Context
-[Mô tả bối cảnh dẫn đến quyết định này. Vấn đề cần giải quyết là gì?]
+[Describe context leading to this decision. What problem needs solving?]
 
 ## Decision
-[Mô tả quyết định kiến trúc đã chọn.]
+[Describe the chosen architectural decision.]
 
 ## Rationale
-[Tại sao chọn hướng này? Lý do kỹ thuật và kinh doanh.]
+[Why choose this approach? Technical and business reasons.]
 
 ## Alternatives Considered
 
-### Alternative 1: [Tên]
-- **Pros:** [ưu điểm]
-- **Cons:** [nhược điểm]
-- **Lý do không chọn:** [giải thích]
+### Alternative 1: [Name]
+- **Pros:** [advantages]
+- **Cons:** [disadvantages]
+- **Why not chosen:** [explanation]
 
-### Alternative 2: [Tên]
-- **Pros:** [ưu điểm]
-- **Cons:** [nhược điểm]
-- **Lý do không chọn:** [giải thích]
+### Alternative 2: [Name]
+- **Pros:** [advantages]
+- **Cons:** [disadvantages]
+- **Why not chosen:** [explanation]
 
 ## Consequences
 
@@ -38,9 +38,9 @@
 - [consequence 2]
 
 ### SAD Updates
-*(Liệt kê các thay đổi cần cập nhật vào docs/sad.md - chỉ thêm khi ADR ảnh hưởng đến kiến trúc chung)*
-- [ ] [thay đổi 1]
-- [ ] [thay đổi 2]
+*(List changes needed to update docs/sad.md - only add when ADR affects overall architecture)*
+- [ ] [change 1]
+- [ ] [change 2]
 
 ## Changelog
 | Date | Changes | Author |

package/.tas/templates/API-Test-Spec.md

@@ -28,7 +28,7 @@ framework: xUnit
 
 ## Version History
 
-> Mỗi API version có section riêng biệt. APPEND-ONLY: không sửa version cũ.
+> Each API version has separate section. APPEND-ONLY: don't modify old versions.
 
 | Version | Status | Created | Description |
 |---------|--------|---------|-------------|
@@ -354,7 +354,7 @@ framework: xUnit
 
 ## Story-Specific Test Cases (Optional)
 
-> Nếu spec được generate từ Story, thêm AC mapping ở đây.
+> If spec generated from Story, add AC mapping here.
 
 | AC ID | AC Description | Test Case IDs |
 |-------|----------------|---------------|
@@ -365,7 +365,7 @@ framework: xUnit
 
 ## Regression Tests (Optional)
 
-> Test cases cho bugs đã được tìm thấy và fix.
+> Test cases for bugs that were found and fixed.
 
 | Bug ID | Description | Test Case ID | Date Added |
 |--------|-------------|--------------|------------|

package/.tas/templates/Bug.md

@@ -19,7 +19,7 @@ parent_ado_id:
 > **Created:** {Date}
 
 ## Description
-{Mô tả bug ngắn gọn}
+{Brief bug description}
 
 ## Steps to Reproduce
 1. {Step 1}
@@ -27,22 +27,22 @@ parent_ado_id:
 3. {Step 3}
 
 ## Expected Behavior
-{Kết quả mong đợi}
+{Expected result}
 
 ## Actual Behavior
-{Kết quả thực tế}
+{Actual result}
 
 ## Evidence
 {Screenshots, logs, error messages}
 
 ## Root Cause Analysis
-*SE điền khi phân tích*
-- **Root Cause:** {Mô tả nguyên nhân gốc}
-- **Affected Files:** {Danh sách file liên quan}
-- **Impact Scope:** {Ảnh hưởng đến những chức năng nào khác}
+*SE fills when analyzing*
+- **Root Cause:** {Root cause description}
+- **Affected Files:** {List of related files}
+- **Impact Scope:** {Affected functionality}
 
 ## Regression Test Cases
-*SE thiết kế trước khi fix*
+*SE designs before fixing*
 
 | ID | Description | Input | Expected | Status |
 |----|-------------|-------|----------|--------|
@@ -50,13 +50,13 @@ parent_ado_id:
 | RT-2 | Related regression | {input} | {expected} | - |
 
 ## Fix Notes
-*SE ghi sau khi fix*
-- **Fix Description:** {Mô tả cách fix}
-- **Files Changed:** {Danh sách file đã sửa}
+*SE fills after fixing*
+- **Fix Description:** {Fix description}
+- **Files Changed:** {List of changed files}
 - **Commit:** {commit hash}
 
 ## Verify Notes
-*PE ghi khi verify*
+*PE fills when verifying*
 
 | Date | Environment | Result | Verified by | Notes |
 |------|-------------|--------|-------------|-------|

package/.tas/templates/Design-Spec.md

@@ -8,26 +8,26 @@
 ---
 
 ## 1. Overview
-{Tổng quan design}
+{Design overview}
 
 ## 2. User Flows
-<!-- Dùng Mermaid flowchart, :::mermaid wrapper, không dùng () -->
+<!-- Use Mermaid flowchart, :::mermaid wrapper, no () -->
 
 ## 3. Screen Descriptions
 
 ### Screen 1: {Name}
-- **Purpose:** {mục đích}
-- **Key Elements:** {thành phần chính}
-- **Actions Available:** {hành động người dùng có thể thực hiện}
+- **Purpose:** {purpose}
+- **Key Elements:** {key elements}
+- **Actions Available:** {user actions available}
 
 ## 4. Navigation Structure
-<!-- Dùng Mermaid flowchart -->
+<!-- Use Mermaid flowchart -->
 
 ## 5. Interaction Patterns
-{Mô tả patterns: form submission, search, pagination...}
+{Describe patterns: form submission, search, pagination...}
 
 ## 6. Responsive Behavior
-{Mô tả breakpoints và behavior thay đổi}
+{Describe breakpoints and behavior changes}
 
 ---
 

package/.tas/templates/E2E-Execution-Report.md

@@ -51,7 +51,7 @@ environment: # dev | staging | prod
 ### {Test ID}: {Test Description}
 
 **AC Reference**: AC-{N}
-**Failure Reason**: {Mô tả ngắn gọn LÝ DO fail — ví dụ: "Button 'Submit' không hiển thị sau khi nhập email hợp lệ", "API trả về 401 thay vì 200", "Timeout sau 5s chờ màn hình Home load"}
+**Failure Reason**: {Brief description of WHY it failed — e.g.: "Button 'Submit' not visible after entering valid email", "API returns 401 instead of 200", "Timeout after 5s waiting for Home screen to load"}
 **Error Type**: {Assertion Failure | Timeout | Crash | Element Not Found}
 **Error Message**:
 ```

package/.tas/templates/Epic.md

@@ -15,7 +15,7 @@ last_ado_sync:
 > **PRD Reference:** {link to PRD section}
 
 ## Business Value
-{Mô tả giá trị kinh doanh}
+{Business value description}
 
 ## Scope
 ### In Scope

package/.tas/templates/Feature.md

@@ -14,10 +14,10 @@ parent_ado_id:
 > **Epic:** Epic-{NNN}
 > **Owner:** {PE name}
 > **Created:** {Date}
-> **Verified Date:** {Date khi status = Verified}
+> **Verified Date:** {Date when status = Verified}
 
 ## Description
-{Mô tả chức năng}
+{Feature description}
 
 ## User Stories
 | ID | Story | Priority | Estimate | Status |
@@ -29,26 +29,26 @@ parent_ado_id:
 - [ ] AC-2: {criteria}
 
 ## UI/UX Notes
-{Nếu có, reference đến design-spec.md}
+{If any, reference to design-spec.md}
 
 ## Technical Notes
-{Nếu có, reference đến SAD/ADR}
+{If any, reference to SAD/ADR}
 
 ## Integration Test Cases
-PE thiết kế khi tạo Feature. SE implement trong code.
+PE designs when creating Feature. SE implements in code.
 
 | ID | AC Ref | Scenario | Expected Result | Status |
 |----|--------|----------|-----------------|--------|
-| IT-1 | AC-1 | {Mô tả flow liên kết} | {Kết quả mong đợi} | - |
-| IT-2 | AC-2 | {Mô tả flow liên kết} | {Kết quả mong đợi} | - |
+| IT-1 | AC-1 | {Integration flow description} | {Expected result} | - |
+| IT-2 | AC-2 | {Integration flow description} | {Expected result} | - |
 
 ## E2E / Acceptance Test Cases
-PE thiết kế khi tạo Feature. PE verify trên Staging ở Phase 2 bằng /tas-verify.
+PE designs when creating Feature. PE verifies on Staging in Phase 2 using /tas-verify.
 
 | ID | AC Ref | User Scenario | Steps | Expected Result | Status | Verified Date |
 |----|--------|---------------|-------|-----------------|--------|---------------|
-| E2E-1 | AC-1 | {Scenario} | {Bước thực hiện} | {Kết quả mong đợi} | - | - |
-| E2E-2 | AC-2 | {Scenario} | {Bước thực hiện} | {Kết quả mong đợi} | - | - |
+| E2E-1 | AC-1 | {Scenario} | {Execution steps} | {Expected result} | - | - |
+| E2E-2 | AC-2 | {Scenario} | {Execution steps} | {Expected result} | - | - |
 
 ## Changelog
 | Date | Changes | Author |

package/.tas/templates/Func-Test-Spec.md

@@ -23,7 +23,7 @@ platform: # mobile | web | backend
 
 ## Test Case Naming Convention
 
-> Functional Tests dung type code **FT** theo format chuẩn TAS
+> Functional Tests use type code **FT** following TAS standard format
 
 ### Format
 ```
@@ -60,8 +60,8 @@ AL_E002_F002_S001_FT_003_E  - Functional Test Edge case
 
 ## AC to Functional Test Mapping
 
-> QUAN TRONG: Moi FT case PHAI reference AC-ID de dam bao traceability.
-> Khi AC thay doi, grep theo AC-ID de biet FT nao can update.
+> IMPORTANT: Every FT case MUST reference AC-ID to ensure traceability.
+> When AC changes, grep by AC-ID to know which FTs need update.
 
 | AC ID | AC Description (Given/When/Then) | FT Test ID | Test Scenario | Modifier | Priority | Status |
 |-------|----------------------------------|------------|---------------|----------|----------|--------|

package/.tas/templates/SAD.md

@@ -8,12 +8,12 @@
 
 ## 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 -->
+<!-- MANDATORY. Written for readers without technical background.
+  Required:
+  - 1.1 Purpose: Why this SAD exists, what problem it solves
+  - 1.2 Scope: Which systems, boundaries are/aren't covered
+  - 1.3 Key Objectives: 3-5 specific, measurable architecture objectives
+  Format: Short prose, max 1 page total -->
 
 ### 1.1 Purpose
 ### 1.2 Scope
@@ -24,12 +24,12 @@
 ## 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 -->
+  Required:
+  - 2.1 Vision Statement: 1-2 sentences describing "what this architecture aims for"
+  - 2.2 Architecture Principles: 4-8 principles guiding design decisions
+    (e.g.: Stateless services, API-first, Defense in depth, Fail fast)
+  - 2.3 Constraints & Assumptions: Technical/organizational constraints, accepted assumptions
+  Format: Bullet list for principles and constraints -->
 
 ### 2.1 Vision Statement
 ### 2.2 Architecture Principles
@@ -40,14 +40,14 @@
 ## 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) -->
+  Required:
+  - 3.1 Business Problem: Describe the business problem to solve
+  - 3.2 Stakeholders: Stakeholder table (role, concerns, influence)
+  - 3.3 Functional Requirements: List FR-xxx, each item has ID for traceability
+  - 3.4 Non-Functional Requirements: List NFR with specific metrics
+    (e.g.: Latency P99 < 300ms, Availability 99.9%, RPS 5000)
+  Should have: Priority (Must/Should/Could) for each requirement
+  Format: Table or numbered list with ID (FR-001, NFR-001) -->
 
 ### 3.1 Business Problem
 ### 3.2 Stakeholders
@@ -59,13 +59,13 @@
 ## 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
+  Required:
+  - 4.1 Current State: Current system (specify if greenfield)
+  - 4.2 Technology Stack: Table 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 -->
+  Should have: Current-state diagram if migration/modernization
+  Format: Table for Technology Stack -->
 
 ### 4.1 Current State
 ### 4.2 Technology Stack
@@ -75,14 +75,14 @@
 
 ## 5. System Context (C4 Level 1)
 
-<!-- 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)
+<!-- MANDATORY. Answers: "Where does this system sit in the ecosystem?"
+  Required:
+  - Mermaid flowchart: system in center, users and external systems around it
+  - Annotate each external system: name, role, communication protocol
+  Not needed: internal system details (leave for C4 Level 2)
+  Format: Mermaid flowchart (use :::mermaid wrapper, no () in node labels)
 
-  Ví dụ:
+  Example:
   :::mermaid
   flowchart TD
     U[fa:fa-user End User] -- |HTTPS| SYS[Your System]
@@ -95,33 +95,33 @@
 
 ## 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
+<!-- MANDATORY. Answers: "What containers does this system consist of?"
+  Required:
+  - Mermaid flowchart: all containers (web app, API, DB, cache, queue, ...)
+  - Each container: name, technology, main role
+  - Interaction flows between containers with protocol/label
+  Should have: Group by bounded context if large system
+  Format: Mermaid flowchart with subgraph to group by domain
 
-  Ví dụ node: WebApp["Web App\n(Next.js / Vercel)"] -->
+  Example node: WebApp["Web App\n(Next.js / Vercel)"] -->
 
 ---
 
 ## 7. Component View (C4 Level 3)
 
-<!-- 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ụ:
+<!-- CONDITIONAL — Required if system has high complexity or new team.
+  Answers: "What components are inside each container?"
+  Guidelines:
+  - Each complex container → separate subsection (7.1, 7.2, ...)
+  - Simple containers (proxy only, static files, thin wrapper) → skip
+  - Don't drill into every container — only those with significant internal logic
+  Each subsection requires:
+  - Mermaid flowchart listing components inside that container
+  - Each component: name, main responsibility, exposed interface
+  - Dependency direction between components (avoid circular)
+  Format: Mermaid flowchart with subgraph wrapper (container name), nodes are components
+
+  Example:
   :::mermaid
   flowchart TD
     subgraph API["API Service (NestJS)"]
@@ -135,89 +135,89 @@
 
 ### 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. -->
+<!-- Required: Mermaid component diagram as per above guidelines.
+  Should have: Brief description of this container's role before 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. -->
+<!-- Add subsection for each complex container. Delete this subsection if not needed. -->
 
 ---
 
 ## 8. Data Architecture & ERD
 
-<!-- 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 -->
+<!-- MANDATORY if system has persistence layer.
+  Required:
+  - ERD: entities, attributes (key fields only), relationships with cardinality
+  - Data flow overview: where data comes from/goes to, transforms where
+  Should have:
+  - Data classification: PII / Sensitive / Internal / Public for each entity
+  - Retention policy if compliance requirement exists
+  - Sharding/partitioning strategy if large data scale
+  Format: Mermaid erDiagram for ERD -->
 
 ---
 
 ## 9. Integration & Data Flow
 
-<!-- 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 -->
+<!-- MANDATORY if system integrates with external services or has async flows.
+  Required:
+  - Sequence diagram for each critical flow (auth, payment, order, ...)
+  - Async flows: queue/event-driven patterns must be clearly diagrammed
+  Should have: Error/retry flows for critical paths
+  Format: Mermaid sequenceDiagram, one 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
+<!-- MANDATORY if system exposes API (internal or external).
+  Required:
+  - API Style: REST / GraphQL / gRPC / Event-driven — and rationale
   - 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ó:
+  Should have:
   - 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 -->
+  - Idempotency handling for mutating operations
+  Don't include here: endpoint list, detailed request/response schemas
+    → Those belong to separate API Contract document (written when implementing)
+  Format: Bullet list or short table -->
 
 ---
 
 ## 10. Security Architecture
 
-<!-- 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)
+<!-- MANDATORY. This is an architectural concern, not implementation detail.
+  Required:
+  - Threat Model: attack surfaces, trust boundaries, top threats (use STRIDE if needed)
   - 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ó:
+  - Network Security Zones: public / DMZ / private / data tier and rules between zones
+  - Encryption: at-rest (algorithm, key management) and in-transit (TLS version, cert strategy)
+  Should have:
   - 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
+  - Compliance requirements: GDPR, PCI-DSS, SOC2, ... if applicable
   Format:
   - Threat model: table (Threat | Vector | Mitigation)
   - Auth flow: Mermaid sequenceDiagram
-  - Network zones: Mermaid flowchart với subgraph per zone -->
+  - Network zones: Mermaid flowchart with 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:
+<!-- MANDATORY. Each NFR-xxx in Section 3.4 must have corresponding strategy here (reference by ID).
+  Required — cover following categories if related NFR exists:
   - 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ó:
+  Should have:
   - 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
+  Format: Table with NFR ID column to trace back to Section 3.4
   | NFR ID | Category | Target | Strategy | Notes |
   |--------|----------|--------|----------|-------|
   | NFR-001 | Latency | P99 < 300ms | Redis cache L2, read replicas | Cache TTL 5m |
@@ -227,28 +227,28 @@
 
 ## 12. Deployment Topology
 
-<!-- MANDATORY. Trả lời: "Các components chạy ở đâu trong infrastructure?"
-  Bắt buộc:
+<!-- MANDATORY. Answers: "Where do components run in the infrastructure?"
+  Required:
   - 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)
+  - Environment matrix: dev / staging / prod — differences in scale, config, isolation
+  Should have:
+  - Network topology: public subnet / private subnet / data subnet and routing rules
+  - CI/CD pipeline overview: build → test → deploy flow and approval gates
+  - Container orchestration config if using K8s/ECS (namespace, resource limits)
   Format:
-  - Mermaid flowchart với subgraph per environment tier hoặc per network zone
+  - Mermaid flowchart with subgraph per environment tier or 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
+<!-- MANDATORY. Record all important architectural decisions and rationale.
+  Required: Each ADR entry includes Decision, Status, Date, Rationale
+  Should have: Alternatives considered and why not chosen
+  Format: Table — add row when new decision is made
   Status values: Proposed | Accepted | Deprecated | Superseded -->
 
 | ID | Decision | Status | Date | Rationale |
@@ -259,9 +259,9 @@
 ## 14. Risks & 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 -->
+  Required: Risk, Impact (H/M/L), Probability (H/M/L), Mitigation action
+  Should have: Owner and review date for each risk
+  Format: Table, sorted by Impact × Probability descending -->
 
 | Risk | Impact | Probability | Mitigation | Owner |
 |------|--------|-------------|------------|-------|

package/.tas/templates/Security-Report.md

@@ -18,9 +18,9 @@
 - **Severity:** Critical | High | Medium | Low
 - **Status:** Open | In Progress | Fixed | Accepted Risk
 - **Location:** {file:line}
-- **Description:** {Mô tả vấn đề}
-- **Recommended Fix:** {Cách fix cụ thể}
-- **Fixed Date:** {Date, nếu đã fix}
+- **Description:** {Issue description}
+- **Recommended Fix:** {Specific fix approach}
+- **Fixed Date:** {Date, if fixed}
 
 ## Scan History
 | Date | Scope | New Findings | Fixed | Remaining |