universal-dev-standards 5.16.0 → 6.0.0

package/bundled/locales/zh-TW/docs/FEATURE-REFERENCE.md

@@ -1,23 +1,23 @@
 # UDS 功能參考手冊
 
 > Universal Development Standards - 完整功能文件
-> Auto-generated | Last updated: 2026-05-14
+> Auto-generated | Last updated: 2026-06-20
 
-**Language**: [English](../../../docs/FEATURE-REFERENCE.md) | 繁體中文 | [简体中文](../../zh-CN/docs/FEATURE-REFERENCE.md)
+**Language**: [English](../../../docs/reference/FEATURE-REFERENCE.md) | 繁體中文 | [简体中文](../../zh-CN/docs/FEATURE-REFERENCE.md)
 
 ---
 
 ## 目錄
 
 1. [CLI 指令](#cli-commands) (9)
-2. [斜線命令](#slash-commands) (49)
-3. [技能](#skills) (54)
+2. [斜線命令](#slash-commands) (51)
+3. [技能](#skills) (55)
 4. [代理](#agents) (5)
 5. [工作流程](#workflows) (5)
-6. [核心規範](#core-standards) (125)
-7. [腳本](#scripts) (55)
+6. [核心規範](#core-standards) (145)
+7. [腳本](#scripts) (57)
 
-**Total Features: 302**
+**Total Features: 327**
 
 ---
 
@@ -89,6 +89,7 @@
 | `--migrate` | Migrate legacy manifest to hash-based tracking |
 | `--offline` | Skip npm registry check for CLI updates |
 | `--force` | Bypass UDS source-repo self-adoption guard (DEC-044 / XSPEC-071) |
+| `--i18n` | Run i18n lint rules (XSPEC-239) across canonical + locale variants |
 
 ### `uds update`
 
@@ -109,6 +110,7 @@
 | `--plan` | Show reconciliation plan without executing (like terraform plan) |
 | `--force` | Force update all files, ignoring hash comparison |
 | `--rollback` | Rollback to the most recent backup |
+| `--locale` | Override locale for skills install (zh-tw, zh-cn, en); also reads .uds/install.yaml + UDS_LOCALE env |
 
 ### `uds skills`
 
@@ -164,6 +166,7 @@
 | `/check` | [UDS] Verify standards adoption status |
 | `/checkin` | "[UDS] Pre-commit quality gates verification" |
 | `/ci-cd` | "[UDS] Guide CI/CD pipeline design, configuration and optimization" |
+| `/code-review` | [UDS] Perform systematic code review with checklist |
 | `/commit` | [UDS] Generate commit messages following Conventional Commits standard |
 | `/config` | [UDS] Configure project development standards |
 | `/coverage` | [UDS] Analyze test coverage and provide recommendations |
@@ -182,6 +185,7 @@
 | `/guide` | [UDS] Access Universal Development Standards guides and references. |
 | `/incident` | "[UDS] Guide incident response, root cause analysis and post-mortem documentation" |
 | `/init` | [UDS] Initialize development standards in current project |
+| `/journey-test` | [UDS] Generate coherent user journey test plans (TESTPLAN) and E2E skeletons from a project description. |
 | `/methodology` | [UDS] Manage development methodology workflow |
 | `/metrics` | "[UDS] Track development metrics, code quality indicators and project health" |
 | `/migrate` | "[UDS] Guide code migration, framework upgrades and technology modernization" |
@@ -194,12 +198,12 @@
 | `/reverse-sdd` | [UDS] Reverse engineer code into SDD specification document |
 | `/reverse-tdd` | [UDS] Analyze BDD-TDD coverage gaps |
 | `/reverse` | [UDS] Reverse engineer code to Specs, BDD, or TDD coverage. |
-| `/review` | [UDS] Perform systematic code review with checklist |
 | `/runbook` | "[UDS] Guide runbook creation, maintenance, drills, and coverage reporting" |
 | `/scan` | "[UDS] Guide automated security scanning, dependency auditing and secret detection" |
 | `/sdd-retro` | [UDS] Create retroactive specs for untracked feat/fix commits |
 | `/sdd` | [UDS] Create or review specification documents for Spec-Driven Development |
 | `/security` | "[UDS] Guide security review and vulnerability assessment following OWASP standards" |
+| `/skill-builder` | [UDS] Identify repeated processes and build Skills with the right development depth. |
 | `/slo` | "[UDS] Guide SLI selection, SLO setting, and Error Budget management" |
 | `/tdd` | [UDS] Guide through Test-Driven Development workflow |
 | `/update` | [UDS] Update development standards to latest version |
@@ -217,7 +221,7 @@
 | `ai-instruction-standards` | Create and maintain AI instruction files (CLAUDE.md, AGENTS.md, .cursor/rules/, etc.) with proper structure. |
 | `api-design-assistant` | Guide API design following REST, GraphQL, and gRPC best practices. |
 | `atdd-assistant` | "[UDS] Guide through Acceptance Test-Driven Development workflow" |
-| `audit-assistant` | "[UDS] UDS Health & Feedback System \| UDS 健康檢查與回饋系統" |
+| `audit-assistant` | "[UDS] UDS Health & Feedback System" |
 | `bdd-assistant` | "[UDS] Guide through Behavior-Driven Development workflow" |
 | `brainstorm-assistant` | "[UDS] Structured AI-assisted brainstorming before spec creation" |
 | `changelog-guide` | "[UDS] Generate and maintain CHANGELOG.md entries" |
@@ -237,7 +241,8 @@
 | `error-code-guide` | Design consistent error codes following the PREFIX_CATEGORY_NUMBER format. |
 | `git-workflow-guide` | Guide Git branching strategies, branch naming, and merge operations. |
 | `incident-response-assistant` | Guide incident response, root cause analysis, and post-mortem documentation. |
-| `journey-test-assistant` | "[UDS] 從專案描述生成連貫使用者旅程測試計畫（TESTPLAN）與 E2E 骨架" |
+| `journey-test-assistant` | "[UDS] Generate coherent user journey test plans (TESTPLAN) and E2E skeletons from project description." |
+| `knowledge-graph` | "[UDS] Trace spec/decision/code impact chains via a knowledge graph (engine or Markdown fallback)" |
 | `logging-guide` | Implement structured logging with proper log levels and sensitive data handling. |
 | `metrics-dashboard-assistant` | "[UDS] Track development metrics, code quality indicators, and project health" |
 | `migration-assistant` | "[UDS] Guide code migration, framework upgrades, and technology modernization" |
@@ -252,7 +257,7 @@
 | `release-standards` | "[UDS] Guide release process and changelogs" |
 | `requirement-assistant` | "[UDS] Write user stories and requirements following INVEST criteria" |
 | `retrospective-assistant` | [UDS] Guide structured team retrospectives for Sprint and Release cycles. |
-| `reverse-engineer` | "[UDS] System archeology — reverse engineer code across Logic, Data, and Runtime dimensions" |
+| `reverse-engineer` | "[UDS] System archeology - reverse engineer code across Logic, Data, and Runtime dimensions" |
 | `runbook-assistant` | Guide runbook creation, maintenance, and drill exercises. |
 | `security-assistant` | Guide security review and vulnerability assessment following OWASP standards. |
 | `security-scan-assistant` | Guide automated security scanning, dependency auditing, and secret detection. |
@@ -295,9 +300,9 @@
 
 | Standard | 版本 | 說明 |
 |----------|---------|-------------|
-| `acceptance-criteria-traceability` | - |  |
+| `acceptance-criteria-traceability` | 1.1.0 |  |
 | `acceptance-test-driven-development` | 1.1.0 |  |
-| `accessibility-standards` | 1.0.0 | This standard defines comprehensive guidelines for creating accessible software  |
+| `accessibility-standards` | 1.1.0 | This standard defines comprehensive guidelines for creating accessible software  |
 | `adr-standards` | 1.0.0 | Architecture Decision Records capture the context, options, and rationale behind |
 | `adversarial-test` | - |  |
 | `agent-behavior-discipline` | 1.0.0 | This standard defines four behavioral disciplines for AI agents that elevate per |
@@ -306,76 +311,88 @@
 | `ai-agreement-standards` | 1.0.0 | This standard formalizes the interaction between Human (Acquirer) and AI (Suppli |
 | `ai-command-behavior` | 1.0.0 | This standard defines a structure for specifying AI Agent runtime behavior in co |
 | `ai-friendly-architecture` | 1.0.0 | This standard defines architecture and documentation practices that maximize the |
-| `ai-instruction-standards` | 1.0.0 | This standard defines best practices for creating and maintaining AI instruction |
-| `ai-response-navigation` | 1.0.0 | This standard defines navigation behavior for AI responses: every substantive AI |
+| `ai-instruction-standards` | 1.1.0 | This standard defines best practices for creating and maintaining AI instruction |
+| `ai-response-navigation` | 1.1.0 | This standard defines navigation behavior for AI responses: every substantive AI |
 | `alerting-standards` | 1.0.0 |  |
 | `anti-hallucination` | 1.5.1 | This standard defines strict guidelines for AI assistants to prevent hallucinati |
 | `anti-sycophancy-prompting` | 1.0.0 | This standard defines techniques and rules for designing prompts that elicit gen |
 | `api-design-standards` | 1.0.0 | This standard defines comprehensive guidelines for designing, building, and main |
+| `audit-trail` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `behavior-driven-development` | 1.1.0 |  |
 | `behavior-snapshot` | - |  |
 | `branch-completion` | 1.0.0 | Define a standardized workflow for completing development branches, including pr |
-| `browser-compatibility-standards` | 1.0.0 | This standard defines supported browser and device matrices, testing automation  |
+| `browser-compatibility-standards` | 1.0.2 | This standard defines supported browser and device matrices, testing automation  |
 | `capability-declaration` | - |  |
 | `cd-deployment-strategies` | - |  |
 | `change-batching-standards` | - |  |
 | `changelog-standards` | 1.0.2 | This standard defines how to write and maintain a CHANGELOG.md file to communica |
 | `chaos-engineering-standards` | 1.0.0 |  |
 | `chaos-injection-tests` | - |  |
-| `checkin-standards` | 1.6.0 | This standard defines quality gates that MUST be passed before committing code t |
+| `checkin-standards` | 1.7.0 | This standard defines quality gates that MUST be passed before committing code t |
 | `circuit-breaker` | - |  |
-| `code-review-checklist` | 1.3.0 | This standard provides a comprehensive checklist for reviewing code changes, ens |
+| `code-review-checklist` | 1.4.0 | This standard provides a comprehensive checklist for reviewing code changes, ens |
 | `commit-message-guide` | 1.3.0 | Standardized commit messages improve code review efficiency, facilitate automate |
+| `container-image-standards` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `container-security` | - |  |
 | `containerization-standards` | 1.0.0 |  |
 | `context-aware-loading` | 1.0.0 | This standard defines a protocol for AI tools to selectively load development st |
 | `contract-testing-standards` | 1.0.0 | Contract testing verifies that a provider (API server) and its consumers (client |
 | `cost-budget-test` | - |  |
-| `cross-flow-regression` | 1.0.0 | This standard defines cross-flow regression testing — verifying that changes to  |
+| `cross-flow-regression` | 1.0.1 | This standard defines cross-flow regression testing — verifying that changes to  |
+| `data-contract` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `data-migration-testing` | - |  |
+| `data-pipeline` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `database-standards` | 1.0.0 | This standard defines guidelines for database design, querying, migration, and o |
-| `deployment-standards` | 1.0.0 | This standard defines guidelines for safely deploying software to production, co |
+| `deployment-standards` | 1.1.0 | This standard defines guidelines for safely deploying software to production, co |
 | `deprecation-standards` | 1.0.0 |  |
 | `design-document-standards` | 1.0.0 |  |
-| `developer-memory` | 1.0.0 | This standard defines a structured system for capturing, retrieving, and surfaci |
+| `developer-memory` | 1.1.1 | This standard defines a structured system for capturing, retrieving, and surfaci |
 | `disaster-recovery-drill` | - |  |
 | `documentation-lifecycle` | 1.0.0 | This standard defines **when** to update documentation, **when** to check it, an |
 | `documentation-structure` | 1.5.0 | This standard defines a consistent documentation structure for software projects |
 | `documentation-writing-standards` | 1.2.0 | This standard defines documentation requirements based on project types and prov |
 | `dual-phase-output` | - |  |
 | `environment-standards` | 1.0.0 |  |
-| `error-code-standards` | 1.2.0 |  |
+| `error-code-standards` | 1.2.1 |  |
 | `estimation-standards` | 1.0.0 |  |
 | `execution-history` | 1.0.0 |  |
 | `failure-source-taxonomy` | - |  |
 | `feature-flag-standards` | 1.0.0 |  |
 | `feature-manifest-standard` | - |  |
 | `flaky-test-management` | - |  |
-| `flow-based-testing` | 1.3.0 | This document defines a systematic methodology for testing multi-step processes. |
-| `forward-derivation-standards` | 1.2.0 | This standard defines the principles and workflows for Forward Derivation—automa |
+| `flow-based-testing` | 1.3.1 | This document defines a systematic methodology for testing multi-step processes. |
+| `forward-derivation-standards` | 1.3.0 | This standard defines the principles and workflows for Forward Derivation—automa |
 | `frontend-design-standards` | 1.0.0 | This standard defines a machine-readable frontend design specification format (D |
 | `full-coverage-testing` | - |  |
 | `git-workflow` | 1.4.0 | This standard defines Git branching strategies and workflows to ensure consisten |
-| `git-worktree` | 1.0.0 | Define a lifecycle for using Git worktrees to isolate development work, ensuring |
+| `git-worktree` | 1.1.0 | Define a lifecycle for using Git worktrees to isolate development work, ensuring |
 | `governance-layer` | 1.0.0 | A governance layer provides a shared anchor for all agents and roles in a projec |
 | `health-check-standards` | - |  |
+| `iac-design-principles` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `immutability-first` | - |  |
+| `incident-response` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
+| `knowledge-graph-memory` | 1.0.0 | This standard defines a **relationship schema** so that specifications, decision |
 | `knowledge-transfer-standards` | 1.0.0 |  |
+| `license-compliance` | 2.1.0 | **Status**: Active | **Updated**: 2026-05-16 |  |
 | `llm-output-validation` | - |  |
-| `logging-standards` | 1.2.0 |  |
+| `logging-standards` | 1.4.0 |  |
 | `mock-boundary` | 1.0.0 | This document defines rules for what can and cannot be mocked in tests. Its goal |
-| `model-selection` | 1.0.0 | Define a cost-effective strategy for selecting AI model tiers based on task comp |
+| `model-provenance` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
+| `model-selection` | 1.0.1 | Define a cost-effective strategy for selecting AI model tiers based on task comp |
 | `mutation-testing` | 1.0.0 | Mutation testing evaluates test suite effectiveness by injecting artificial bugs |
 | `no-cicd-deployment` | - |  |
 | `observability-standards` | 1.0.0 |  |
-| `packaging-standards` | 1.0.0 | This standard defines a Recipe-based packaging framework that enables user proje |
-| `performance-standards` | 1.1.0 | This standard defines comprehensive guidelines for software performance engineer |
+| `packaging-standards` | 1.1.0 | This standard defines a Recipe-based packaging framework that enables user proje |
+| `performance-standards` | 1.2.0 | This standard defines comprehensive guidelines for software performance engineer |
+| `pii-classification` | 1.1.0 | **Status**: Active | **Updated**: 2026-06-19 |  |
 | `pipeline-integration-standards` | - |  |
 | `pipeline-security-gates` | - |  |
 | `policy-as-code-testing` | - |  |
 | `postmortem-standards` | 1.0.0 |  |
-| `privacy-standards` | 1.0.0 |  |
-| `project-context-memory` | 1.1.0 | This standard defines a structured system for capturing, retrieving, and enforci |
+| `prd-standards` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
+| `privacy-standards` | 1.1.0 |  |
+| `product-metrics-standards` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
+| `project-context-memory` | 1.2.0 | This standard defines a structured system for capturing, retrieving, and enforci |
 | `project-structure` | 1.2.0 | This standard defines conventions for project directory structure beyond documen |
 | `prompt-regression` | - |  |
 | `property-based-testing` | - |  |
@@ -385,21 +402,27 @@
 | `release-readiness-gate` | 1.0.0 | This standard defines a **single, aggregated Release Readiness Gate** that unifi |
 | `replay-test` | - |  |
 | `requirement-engineering` | 1.0.0 |  |
+| `resource-cost-boundary` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `retrospective-standards` | 1.0.0 | Retrospectives are structured team reflections that identify what worked well, w |
 | `retry-standards` | - |  |
-| `reverse-engineering-standards` | 1.0.0 | This standard defines the principles, workflows, and best practices for reverse  |
+| `reverse-engineering-standards` | 1.1.0 | This standard defines the principles, workflows, and best practices for reverse  |
 | `rollback-standards` | - |  |
 | `runbook-standards` | 1.0.0 |  |
+| `runbook` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `sast-advanced` | 1.0.0 | This standard defines Advanced Static Application Security Testing (SAST) practi |
+| `schema-evolution` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
+| `secret-management-standards` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `secure-op` | - |  |
 | `security-decision` | - |  |
 | `security-standards` | 1.1.0 | This standard defines comprehensive security guidelines for software development |
-| `security-testing` | 1.0.0 | This document defines the security testing methodology for software projects. It |
+| `security-testing` | 1.1.0 | This document defines the security testing methodology for software projects. It |
+| `self-review-protocol` | 1.0.0 | This standard mandates a **self-review pass** on large markdown edits before com |
 | `server-ops-security` | - |  |
 | `skill-standard-alignment-check` | - |  |
+| `slo-sli` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `slo-standards` | 1.0.0 |  |
 | `smoke-test` | - |  |
-| `spec-driven-development` | 2.2.0 |  |
+| `spec-driven-development` | 2.3.0 |  |
 | `standard-admission-criteria` | - |  |
 | `standard-lifecycle-management` | - |  |
 | `structured-task-definition` | 1.0.0 |  |
@@ -415,7 +438,9 @@
 | `timeout-standards` | - |  |
 | `token-budget` | - |  |
 | `translation-lifecycle-standards` | 1.0.0 | Translation lifecycle standards: MISSING vs OUTDATED distinction, semver-aware s |
+| `user-story-mapping` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `verification-evidence` | 1.0.0 | Establish an "Iron Law" that no task can be claimed as complete without verifica |
+| `verification-oracle` | 1.0.0 | **Status**: Active | **Updated**: 2026-06-17 |  |
 | `versioning` | 1.2.0 | This standard defines how to version software releases using Semantic Versioning |
 | `virtual-organization-standards` | 1.0.0 | This standard treats the AI ecosystem as a "Virtual Organization." It defines ho |
 | `workflow-enforcement` | - |  |
@@ -472,6 +497,7 @@
 | `fix-manifest-paths.ps1` | Fix Manifest Paths |
 | `fix-manifest-paths.sh` | Manifest Path Fixer |
 | `generate-docs.mjs` | Generate Docs |
+| `generate-locale-coverage.mjs` | Locale Coverage Generator |
 | `generate-version-manifest.mjs` | Generate Version Manifest (SPEC-SELFDIAG-001 REQ-9, AC-14) |
 | `install-hooks.mjs` | Install Hooks |
 | `install-hooks.sh` | DEPRECATED: Use 'node scripts/install-hooks.mjs' instead (cross-platform). |
@@ -480,6 +506,7 @@
 | `pre-release-check.sh` | Pre-release Check Script |
 | `pre-release.ps1` | Pre-Release Preparation Script for Universal Development Standards |
 | `pre-release.sh` | Pre-Release Preparation Script |
+| `setup-hooks.sh` | setup-hooks.sh — Install git hooks for UDS repo |
 | `setup-husky.mjs` | Cross-platform Husky Setup Script |
 | `sync-manifest.mjs` | Sync Manifest |
 

package/bundled/locales/zh-TW/docs/MIGRATION-v6.md

@@ -0,0 +1,88 @@
+# UDS 6.0.0 遷移指南
+
+> **語言**: [English](../../../docs/MIGRATION-v6.md) | 繁體中文 | [简体中文](../../zh-CN/docs/MIGRATION-v6.md)
+
+UDS 6.0.0 是 **major** 版本：包含一項 breaking 更名、移除 8 個已棄用的機器可讀標準與 4 個已棄用的 CLI 命令——以上皆自 5.4.0 起帶有「6.0.0 移除」預告。本指南涵蓋所有需要調整的事項。
+
+**TL;DR 檢查清單：**
+
+- [ ] 把所有 `/review` 呼叫改為 `/code-review`
+- [ ] 若腳本用到 `uds start` / `uds mission*` / `uds workflow*` / `uds flow*` / `uds sweep`，依 §3 遷移
+- [ ] 若採用層曾載入 8 個被移除的 `.ai.yaml` stub，改用自家 runtime 等效實作（§2）
+- [ ] 升級：`npm install -g universal-dev-standards@6`，然後在各專案跑 `uds update`
+
+---
+
+## 1. Breaking 更名：`/review` → `/code-review`
+
+`review` 命令/skill 更名為 `code-review`，使 skill frontmatter 名稱與其目錄（`code-review-assistant`）對齊。
+
+| 更名前 | 更名後 |
+|--------|--------|
+| `/review` | `/code-review` |
+| `skills/commands/review.md` | `skills/commands/code-review.md` |
+| `.gemini/commands/review.toml` | `.gemini/commands/code-review.toml` |
+| `flows/review.flow.yaml`（flow-id `review-flow`）| `flows/code-review.flow.yaml`（flow-id `code-review-flow`）|
+
+**你需要做的：**
+
+- 把自家 prompt、文件、CI 腳本、AI 指令檔（`CLAUDE.md`、`AGENTS.md`、`.cursor/rules/` 等）中的 `/review` 改為 `/code-review`。
+- 若你的 flow 引用了 flow-id `review-flow`（如 `workflow-prerequisites`），改為 `code-review-flow`。
+- 重跑 `uds update` 讓重生成的命令索引落進專案。
+
+**不受影響**：指涉外部工具內建 review 命令（如 Codex）的 `/review` 字樣與 UDS 無關，刻意保留原樣。
+
+## 2. 移除：8 個已棄用的機器可讀標準（`.ai.yaml`）
+
+這 8 個標準的 runtime 已於 5.4.0 移交採用層（XSPEC-086/095；UDS 定義活動、採用層編排流程——DEC-049），其 `.ai.yaml` stub 如期移除：
+
+| 移除的 `.ai.yaml` | 保留的人類可讀文件 |
+|---|---|
+| `agent-communication-protocol` | `core/agent-communication-protocol.md` |
+| `agent-dispatch` | `core/agent-dispatch.md` |
+| `branch-completion` | `core/branch-completion.md` |
+| `change-batching-standards` | `core/change-batching-standards.md` |
+| `execution-history` | `core/execution-history.md` |
+| `pipeline-integration-standards` | `core/pipeline-integration-standards.md` |
+| `workflow-enforcement` | `core/workflow-enforcement.md` |
+| `workflow-state-protocol` | `core/workflow-state-protocol.md` |
+
+**你需要做的：**
+
+- 若從未直接載入這些 `.ai.yaml`：不需動作——人類可讀概念仍留在 `core/` 作為參考文件。
+- 若採用層（agent runtime、orchestrator、CI）曾載入這些 stub：在自家工具鏈實作等效機制。這些 stub 自 5.4.0 起本身就是指向此方向的棄用告示。
+- 這些標準不再由 `uds init` / `uds update` 發佈。專案 `.standards/` 中既有副本不會被自動刪除——想要乾淨樹的話請手動移除。
+
+## 3. 移除：4 個已棄用的 CLI 命令
+
+四者皆於 5.4.0 標記 `@deprecated`（XSPEC-095）並預告 6.0.0 移除。流程編排屬採用層職責（DEC-049）。
+
+| 移除的命令 | 遷移路徑 |
+|---|---|
+| `uds start`、`uds mission:*`（status/pause/resume/cancel/list）| 用採用層的 mission runtime（如 VibeOps orchestrator）|
+| `uds workflow:*`（list/install/info/execute/status）| workflow 定義在 `flows/`；執行歸採用層 |
+| `uds flow:*`（create/list/validate/diff/export/import）| 直接撰寫 flow YAML；驗證/執行在採用層 |
+| `uds sweep` | 用 `/sweep` skill（同能力、skill 形式）|
+
+保留的命令：`init`、`update`、`check`、`audit`、`config`、`skills`、`release`、`hitl`、`run` 及其餘非編排類 CLI。
+
+## 4. 已棄用但 6.0.0「未」移除
+
+- **6 個 workflow skills** 標記為 `reference` 級並帶明顯棄用告示（XSPEC-291 §4）。它們仍隨版發佈；可按自己的節奏遷移。
+- 其他已棄用 runtime 命令帶結構化 `@superseded-by` 指標。
+
+## 5. 升級步驟
+
+```bash
+# 1. 升級 CLI
+npm install -g universal-dev-standards@6
+
+# 2. 在各消費專案
+uds update
+
+# 3. 掃自家設定的殘留引用
+grep -rn "/review\b" . --include="*.md" --include="*.toml" | grep -v code-review
+grep -rn "uds start\|uds workflow\|uds flow\|uds sweep" . --exclude-dir=node_modules
+```
+
+`uds check` 通過且上述 grep 乾淨，即完成遷移。

package/bundled/locales/zh-TW/docs/USAGE-MODES-COMPARISON.md

@@ -103,7 +103,7 @@ status: current
 | 學習曲線 | 低 | 高 | 低 |
 
 **說明**：
-- Skills 提供 `/commit`、`/tdd`、`/review` 等命令進行互動引導
+- Skills 提供 `/commit`、`/tdd`、`/code-review` 等命令進行互動引導
 - 規範文件需要開發者主動閱讀並應用
 - Skills 可自動偵測上下文（如 git status、專案語言）
 
@@ -177,7 +177,7 @@ status: current
 - Token 消耗最低
 - 互動體驗最佳
 - 無需管理額外文件
-- `/commit`、`/tdd`、`/review` 命令足夠日常使用
+- `/commit`、`/tdd`、`/code-review` 命令足夠日常使用
 
 **配置方式**：
 ```bash

package/bundled/locales/zh-TW/docs/USER-MANUAL.md

@@ -63,7 +63,7 @@ Universal Development Standards 是一套為 AI 時代設計的**語言無關、
 | 問題 | UDS 解決方案 |
 |------|-------------|
 | 團隊 commit message 格式不一致 | 透過 `/commit` 標準化 Conventional Commits |
-| Code review 漏看關鍵問題 | 透過 `/review` 執行 8 維度系統性審查 |
+| Code review 漏看關鍵問題 | 透過 `/code-review` 執行 8 維度系統性審查 |
 | AI 工具給出不一致的建議 | 統一標準讓 AI 工具讀取並遵循 |
 | 新人加入團隊需要數週上手 | 清晰的標準和引導式工作流程 |
 | 測試覆蓋率期望不明確 | 測試金字塔定義明確比例（70/20/7/3） |
@@ -71,10 +71,10 @@ Universal Development Standards 是一套為 AI 時代設計的**語言無關、
 
 ### 設計哲學
 
-**「碰一點，保護一點」** — 你不需要一次導入全部 48 個標準。UDS 專為漸進式導入設計：
+**「碰一點，保護一點」** — 你不需要一次導入全部 140+ 個標準。UDS 專為漸進式導入設計：
 
 - 先只用 `/commit` — 零成本，立即見效
-- 接著加入 `/review` — 在合併前捕捉問題
+- 接著加入 `/code-review` — 在合併前捕捉問題
 - 團隊適應後，逐步引入 `/tdd` 和 `/sdd`
 
 > **Boy Scout Rule**：讓程式碼比你找到它時更好。每次碰到程式碼，順手加一點保護（測試、文件）。
@@ -142,7 +142,7 @@ npx universal-dev-standards init
 
 ```
 your-project/
-├── .standards/           # 48 個 AI 標準（.ai.yaml 檔案）
+├── .standards/           # AI 標準（.ai.yaml 檔案）
 │   ├── testing.ai.yaml
 │   ├── commit-message.ai.yaml
 │   ├── code-review.ai.yaml
@@ -458,14 +458,14 @@ Refs: SPEC-001
 | `test` | 測試 | `test(auth): 新增登入測試` |
 | `chore` | 維護 | `chore(deps): 更新相依套件` |
 
-### `/review` — 程式碼審查
+### `/code-review` — 程式碼審查
 
-提交前，用 `/review` 進行系統性審查：
+提交前，用 `/code-review` 進行系統性審查：
 
 ```bash
-/review                    # 審查當前分支所有變更
-/review src/auth.js        # 審查特定檔案
-/review feature/login      # 審查特定分支
+/code-review                    # 審查當前分支所有變更
+/code-review src/auth.js        # 審查特定檔案
+/code-review feature/login      # 審查特定分支
 ```
 
 **8 個審查維度：**
@@ -504,7 +504,7 @@ Refs: SPEC-001
 | **規格** | `/sdd`, `/requirement`, `/brainstorm` | 規格驅動開發 |
 | **推演** | `/derive-all`, `/derive-bdd`, `/derive-tdd`, `/derive-atdd` | 從規格生成測試 |
 | **開發** | `/tdd`, `/bdd`, `/atdd` | 方法論工作流程 |
-| **品質** | `/commit`, `/review`, `/checkin`, `/coverage`, `/ac-coverage` | 日常品質管理 |
+| **品質** | `/commit`, `/code-review`, `/checkin`, `/coverage`, `/ac-coverage` | 日常品質管理 |
 | **文件** | `/docs`, `/docgen`, `/changelog`, `/release` | 文件與發布 |
 | **反向** | `/reverse`, `/reverse-sdd`, `/reverse-bdd`, `/reverse-tdd` | Legacy Code 反向工程 |
 | **重構** | `/refactor` | 重構指導 |
@@ -522,7 +522,7 @@ Refs: SPEC-001
 
 ```bash
 /commit     # 標準化 commit message
-/review     # 提交前自我審查
+/code-review     # 提交前自我審查
 ```
 
 > 只需要這兩個指令，就能立即提升程式碼品質。
@@ -569,7 +569,7 @@ Refs: SPEC-001
 12:00  /commit                # 標準化提交
        → feat(auth): 新增雙因素認證
 
-12:05  /review                # 最終審查
+12:05  /code-review                # 最終審查
        → 0 BLOCKING, 1 SUGGESTION
 ```
 
@@ -599,7 +599,7 @@ A: 不會。UDS 是語言無關、框架無關的。它定義的是流程和品
 A: 不用。核心標準是 Markdown 文件，人類直接閱讀也完全適用。AI 工具只是讓流程更順暢。
 
 **Q: 團隊中只有我用可以嗎？**
-A: 可以。漸進式導入的設計就是為了這個情境。先自己用 `/commit` 和 `/review`，等團隊看到效果再推廣。
+A: 可以。漸進式導入的設計就是為了這個情境。先自己用 `/commit` 和 `/code-review`，等團隊看到效果再推廣。
 
 **Q: 和 ESLint / Prettier 衝突嗎？**
 A: 互補關係。ESLint/Prettier 處理程式碼格式，UDS 處理更高層次的開發流程和品質標準。
@@ -624,7 +624,7 @@ uds init
 
 ### 推薦學習路徑
 
-1. 先用 `/commit` + `/review` 養成習慣
+1. 先用 `/commit` + `/code-review` 養成習慣
 2. 遇到新功能時試試 `/sdd`
 3. 不確定下一步時，輸入 `/dev-workflow`
 

package/bundled/locales/zh-TW/docs/specs/system/memory-adoption-strategy.md

@@ -0,0 +1,105 @@
+---
+source: docs/specs/system/memory-adoption-strategy.md
+source_version: 1.0.0
+translation_version: 1.0.0
+status: current
+---
+
+# 記憶採用策略
+
+**狀態**: Archived
+
+> **語言**: [English](../../../../../docs/specs/system/memory-adoption-strategy.md) | 繁體中文
+
+本文件提供策略指引，協助跨不同團隊規模與營運模式採用 Universal Development Standards (UDS) 的記憶系統。它幫助使用者決定如何架構自身的 **Project Context Memory (PCM)** 與 **Developer Persistent Memory (DPM)**，以發揮最大效益。
+
+---
+
+## 1. 決策矩陣
+
+選擇最適合你營運模式的策略：
+
+| 策略 | 目標對象 | 儲存位置 | 知識流向 | 主要效益 |
+| :--- | :--- | :--- | :--- | :--- |
+| **數位花園 (Digital Garden)** | 獨立開發者、自由工作者 | 本機全域 (`~/.uds/memory`) | Project → User | **可攜性**：你的經驗隨你而行。 |
+| **倉庫中心 (Repo-Centric)** | 新創公司、小型團隊 | 專案本地 (`.project-context/`) | User → Project | **一致性**：為新成員提供「開箱即用」的上手體驗。 |
+| **軸輻式 (Hub-and-Spoke)** | 企業、多專案組織 | Git Submodule／Registry | Hub ↔ Spoke | **標準化**：在嚴格邊界內強制落實合規。 |
+
+---
+
+## 2. 策略 A：數位花園 (獨立／自由工作者)
+
+**理念**：「我是知識的載體。」
+
+目標是在許多臨時專案之間累積個人經驗。AI 扮演你的個人結對程式設計夥伴，學習 *你的* 偏好。
+
+### 配置
+- **全域 memory**：啟用。將特定技術堆疊的洞見（例如「React Tips」、「Python Tricks」）儲存於 `~/.uds/memory/`。
+- **專案 memory**：最小化。僅儲存憑證、特定路徑或臨時性的商業邏輯。
+
+### 工作流程
+1.  **遇到問題**：在專案 A 中解決一個棘手的 React 渲染錯誤。
+2.  **提升 (Promote)**：告訴 AI：「將這個存成通用的 React 模式到我的全域 memory。」
+3.  **重複使用**：開啟專案 B。當你撰寫類似程式碼時，AI 會立即建議該模式，因為它讀取了 `~/.uds/memory`。
+
+### 設定
+```bash
+# 1. Create global directory
+mkdir -p ~/.uds/memory
+
+# 2. (Optional) Initialize as git repo for backup
+cd ~/.uds/memory && git init
+```
+
+---
+
+## 3. 策略 B：倉庫中心 (小型團隊)
+
+**理念**：「倉庫即真實來源 (Source of Truth)。」
+
+目標是確保每位團隊成員（以及他們的 AI Agent）擁有完全相同的脈絡。個人偏好不應凌駕於專案慣例之上。
+
+### 配置
+- **全域 memory**：**停用** 或唯讀。避免「在我的機器／AI 上可以運作」的問題。
+- **專案 memory**：完整。所有架構決策、程式撰寫風格與領域術語皆存放於 `.project-context/`，並提交至 Git。
+
+### 工作流程
+1.  **上手 (Onboarding)**：新成員 clone 倉庫。
+2.  **即時脈絡**：他們的 AI 讀取 `.project-context/`，立即得知：「我們採用 Hexagonal Architecture」與「變數必須使用 snake_case」。
+3.  **共識**：當團隊在 Code Review 中對新規則達成共識時，由一人指示 AI：「將這條規則加入 Project Context。」
+4.  **同步**：新的 `.md` 檔案被提交並推送。每個人在下次 `git pull` 時取得更新。
+
+---
+
+## 4. 策略 C：軸輻式 (企業)
+
+**理念**：「治理與合規。」
+
+目標是在數百個專案之間共享共通標準，同時允許在地的彈性。
+
+### 配置
+- **核心層（軸 The Hub）**：一個專用的 Git 倉庫（例如 `acme-corp/standard-memory`），內含全公司的安全規則與架構模式。
+- **專案層（輻 The Spoke）**：本地 `.project-context/`，用於應用程式專屬的邏輯。
+
+### 實作：Git Submodules
+每個專案將中央 memory 作為 submodule 掛載。
+
+```bash
+# In Project A, B, and C:
+git submodule add git@github.com:acme-corp/standard-memory.git .standards/shared
+```
+
+### 工作流程
+1.  **政策更新**：安全團隊在 Hub 倉庫中更新「Auth Standards」。
+2.  **傳播 (Propagation)**：各專案更新其 submodule，以拉取新標準。
+3.  **驗證**：CI/CD 管線檢查專案程式碼是否符合 `.standards/shared` 中更新後的規則。
+
+---
+
+## 5. 總結
+
+| 如果你想要… | 採用策略… |
+| :--- | :--- |
+| 在不同接案工作之間停止重複造輪子 | **數位花園 (Digital Garden)** |
+| 讓新進人員在第一天就能產出 | **倉庫中心 (Repo-Centric)** |
+| 確保 50+ 個微服務遵循安全規格 | **軸輻式 (Hub-and-Spoke)** |