universal-dev-standards 5.16.0 → 6.0.0

package/bundled/locales/zh-TW/core/versioning.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/versioning.md
-source_version: 1.2.0
-translation_version: 1.2.0
-last_synced: 2025-12-30
+source_version: 1.5.0
+translation_version: 1.5.0
+last_synced: 2026-07-01
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 # 語義化版本標準
 
-**版本**: 1.2.0
-**最後更新**: 2025-12-30
+**版本**: 1.5.0
+**最後更新**: 2026-07-01
 **適用範圍**: 所有有版本發布的軟體專案
 
 ---
@@ -161,6 +161,72 @@ Format: `MAJOR.MINOR.PATCH+BUILD`
 - Use for CI/CD tracking
 - Include in artifacts but not in version comparison
 
+> **關鍵：build metadata 不得作為部署的區分依據。**
+> 由於工具鏈在優先序與比較中忽略 `+build`（如上），兩個僅 build metadata 不同的建置
+> （`1.2.3+abc` vs `1.2.3+def`）對**版本比較工具**而言**無法區分**——回滾目標與 `semver` 比較
+> 視為同一個發布。用 `+sha` 區分行為不同的已部署建置是一種治理逃逸：版本號不再是 changelog /
+> SBOM / 稽核 / 回滾 / SLA / CVE 範圍的 join key。任何 ship 的變更 MUST 取得真正的版本 bump 或
+> 唯一不可變的 artifact 身分（見下方 **部署版本身分**）——`+sha` **不能**替代。
+
+---
+
+## 部署版本身分
+
+> 來源：一個反覆出現的失敗模式——多個行為不同的 hotfix 建置以**同一個 `X.Y.Z`** 部署，僅靠
+> `+sha` 區分，於是「prod 跑的是哪個 / 修補 X 是否真的上了」退化成 commit 考古。
+
+本節規範**可部署單元**的身分——無論該單元對專案而言是什麼（容器 image、tarball、已發布套件）。
+它與下方的 [發布流程](#發布流程)（描述一套具體的單機發布流程）互補；此處的身分規則**不論部署機制
+為何皆適用**。
+
+### 核心不變量
+
+**每個唯一的可部署建置 artifact MUST 帶有唯一、不可變的版本身分（版本號本體 + commit sha）。**
+部署、*晉升（promote）*、或*回滾（rollback）*一個**既有** artifact MUST NOT 改變其身分。
+
+- **錨定在 artifact，而非部署動作。** 新建置（原始碼或依賴不同）⇒ 新版本。*同一個*建置在環境間
+  移動（staging → prod，build-once-deploy-many）、重新部署（blue-green / canary）、或回滾，是
+  **同一個** artifact、保留其身分——MUST NOT 重新 bump。在 promote/rollback 上重新 bump 會讓版本
+  號謊報實際在跑的東西。（回滾還原一個先前的 artifact 時，是還原該 artifact 的原始身分，而非鑄造
+  一個新身分。）
+- **絕不讓兩個不同的建置共用同一個 `X.Y.Z`。**
+
+### 自動強制，而非靠紀律
+
+此不變量 SHOULD 由自動機制強制，而非單靠人為紀律——上述失敗模式*正是*忘記手動 bump。下列任一皆滿足：
+
+- **commit 驅動的發布自動化**（`semantic-release` / `standard-version`，見 [自動化工具](#自動化工具)）：
+  在 CI 中由 commit 歷史推導並 bump 版本，使人無從忘記 bump。
+- **git-height 衍生版本**（MinVer / Nerdbank.GitVersioning / GitVersion）：版本由 git 提交拓撲
+  推導，故碰撞結構上不可能。對 polyglot / .NET / JVM 專案 RECOMMENDED（自動化工具一節原本以 Node
+  為主）——見 [自動化工具](#自動化工具) 下的 git-height 子節。注意 monorepo 與 squash-merge 工作流
+  的注意事項。
+- **CI 唯一性閘**：若算出的版本已存在於 git tag 或 registry，則 release 失敗。
+
+### 不可變 artifact（交叉引用）
+
+唯一的*號碼*是必要但不充分——*artifact* 本身也必須不可變且內容定址（例如容器 image 以 digest 引用
+而非可變 tag）。具體的 artifact 層級要求——把部署釘在內容位址、禁止 tag/版本重用——**歸
+container-image-standards** 且將於該標準訂定；本標準只要求版本身分本身保持唯一且不可變。
+
+### Build 身分可被觀測（需求）
+
+**已部署的服務 MUST 透過可查詢的 endpoint（專用的 `/version`，或嵌入 `/health`）暴露其 build 身分
+——`version + commit sha + build time`**，讓維運者不必檢視二進位或做 commit 考古就能知道確切在跑
+什麼。理由：手動版本號可能碰撞（如上），所以 ops 需要 `sha` 才能區分共用同一個 `X.Y.Z` 的兩個 build。
+
+需求：
+
+- 暴露的 `sha` MUST 與已部署 artifact 的 sha 相符——是**可驗證、非自述**（由建置推導，不可手打）。
+- 該 endpoint SHOULD 受存取控制；公開的 build 身分 endpoint 會洩漏內部 commit 身分。
+- 部署後驗證 MUST 斷言回傳的 sha 等於已部署 artifact 的 sha
+  （見 [Phase 5: Post-release Verification](#phase-5-post-release-verification-驗證階段)），而非僅
+  斷言版本號正確。
+
+這是部署 / 可觀測性的關切：具體的驗證*機制*（如何抓取 endpoint 並把斷言接進 gate）**歸
+deployment-standards**（將於該標準訂定），而 **supply-chain-attestation** 已提供 provenance 作為
+「此 artifact 確實來自此 sha」的密碼學背書。
+
 ---
 
 ## 初始開發
@@ -436,8 +502,10 @@ sudo ./upgrade.sh
 # 1. 檢查服務狀態
 systemctl status your-service
 
-# 2. 檢查應用程式版本
-curl http://localhost:PORT/api/version
+# 2. 檢查應用程式 build 身分（version + commit sha + build time）
+#    斷言回傳的 sha 與已部署 artifact 的 sha 相符——不只是版本號。
+curl http://localhost:PORT/version    # 或 /health（若 build 身分嵌入其中）
+# 預期: {"version": "1.2.1", "sha": "<deployed-artifact-sha>", "buildTime": "..."}
 
 # 3. 檢查日誌無錯誤
 tail -100 /path/to/app.log | grep -i error
@@ -445,7 +513,9 @@ tail -100 /path/to/app.log | grep -i error
 
 **成功標準**:
 - 服務正常運行
-- API 回應正確版本號
+- `/version`（或 `/health`）回應正確版本號**且**回傳與已部署 artifact 相符的 commit sha——
+  僅版本號相符並不足夠，因為兩個 build 可能共用同一個 `X.Y.Z`
+  （見 [Build 身分可被觀測](#build-身分可被觀測需求)）
 - 日誌無致命錯誤
 - 功能驗證通過
 
@@ -600,6 +670,29 @@ npm install --save-dev semantic-release
 }
 ```
 
+### git-height 衍生版本（polyglot：.NET / JVM / 多語言）
+
+上述工具以 Node/npm 為主。對 **.NET、JVM 或多語言專案**，優先採用 **git-height 衍生版本**：
+版本由 git tag 圖加上「自上一個 tag 以來的 commit 數（commit height）」自動計算，而非存在
+人工編輯的檔案中。由於版本是 git 歷史的確定性函數，**兩個不同的建置不可能碰撞到同一個版本號**，
+且沒有任何手動 bump 步驟會被忘記——這正是它從結構上（而非靠紀律）滿足
+[部署版本身分](#部署版本身分)的原因。
+
+| Tool | Ecosystem | 說明 |
+|------|-----------|------|
+| **MinVer** | .NET / MSBuild | 由最近的 git tag 加 commit height 推導版本；無需設定檔、無需 build server 整合 |
+| **Nerdbank.GitVersioning** (nbgv) | .NET（也支援 Node 等） | 讀取 `version.json`；將 version + git height + commit id 烙印進 assembly 與套件 |
+| **GitVersion** | Polyglot（.NET，加上語言無關的 CLI） | 可設定的版本模式（如 Mainline、Continuous Delivery / Continuous Deployment），由分支與 tag 拓撲驅動 |
+
+**如何選擇：**
+
+- **Node / npm 專案** → commit 驅動的自動化（`semantic-release` / `standard-version`，見上）：bump 由 Conventional Commits 推導。
+- **Polyglot / .NET / JVM 專案** → git-height 衍生工具（MinVer / Nerdbank.GitVersioning / GitVersion）：版本由 git tag + commit height 推導。
+
+兩類都消除了會被忘記的手動 bump。**注意事項：** 在 monorepo 中，單一 repo 範圍的 commit height
+未必能乾淨對應到各套件的版本，而 squash-merge 工作流會改變 commit height——請對照你的 tagging
+慣例驗證推導出的版本。
+
 ---
 
 ## 依賴版本範圍
@@ -643,113 +736,14 @@ npm install --save-dev semantic-release
 
 ---
 
-## 破壞性變更溝通
-
-### 1. Deprecation Warnings (N-1 Version)
-
-```javascript
-// Version 1.5.0 - Add deprecation warning
-/**
- * @deprecated Use authenticateV2() instead. Will be removed in v2.0.0
- */
-function authenticate(username, password) {
-  console.warn('[DEPRECATED] authenticate() will be removed in v2.0.0. Use authenticateV2()');
-  return authenticateV2(username, password);
-}
-```
-
-### 2. API 版本化策略
-
-根據需求選擇 API 版本化策略：
-
-| 策略 | 格式 | 優點 | 缺點 |
-|------|------|------|------|
-| URL 路徑 | `/api/v1/users` | 清晰、易於路由 | URL 污染 |
-| 查詢參數 | `/api/users?version=1` | 可選版本 | 快取問題 |
-| 標頭 | `Accept: application/vnd.api.v1+json` | URL 乾淨 | 較不可見 |
-| 內容協商 | `Accept: application/vnd.api+json;version=1` | RESTful | 複雜 |
+## 破壞性變更與棄用
 
-**建議**：大多數 API 使用 URL 路徑版本化（對開發者最清晰）。
+破壞性變更會驅動 **MAJOR** 版本號遞增（見[遞增規則](#遞增規則)）——這正是 SemVer 向消費者傳達不相容變更的方式。API *契約層級*的演進與退役細節，由負責該領域的標準各自掌管，使每條規則都有單一真實來源：
 
-### 3. 棄用時間線
+- **API 版本化策略、向後相容性檢查清單（何謂破壞性變更）、程式碼中的棄用註記、以及遷移指南模板** → [API 設計標準](api-design-standards.md#api-版本控制策略)
+- **棄用生命週期、依 API 分級的最短通知期間、`Sunset` / `Deprecation` 標頭、以及消費者通知** → [棄用與日落標準](deprecation-standards.md#api-棄用)
 
-棄用 API 功能時遵循此時間線：
-
-```
-v1.0.0 - 功能引入
-v1.5.0 - 新增棄用警告（最少 N-1 版本）
-v2.0.0 - 移除功能（記錄在遷移指南中）
-```
-
-**棄用期間指南**：
-
-| API 類型 | 最短棄用期間 |
-|----------|-------------|
-| 內部 API | 1 個次要版本 |
-| 合作夥伴 API | 2 個次要版本 + 3 個月 |
-| 公開 API | 2 個次要版本 + 6 個月 |
-| 關鍵基礎設施 | 最少 1 年 |
-
-### 4. 向後相容性檢查清單
-
-發布前驗證這些向後相容性規則：
-
-**不要破壞（不升級主版本號）**：
-- [ ] 移除公開 API 端點
-- [ ] 移除必填請求欄位
-- [ ] 新增必填請求欄位
-- [ ] 變更回應欄位類型
-- [ ] 變更錯誤碼含義
-- [ ] 移除消費者依賴的回應欄位
-
-**安全變更（次要/修補版本）**：
-- [ ] 新增可選請求欄位
-- [ ] 新增回應欄位
-- [ ] 新增端點
-- [ ] 新增錯誤碼
-- [ ] 改善錯誤訊息
-- [ ] 效能改進
-
-### 5. 遷移指南（N 版本）
-
-```markdown
-# 遷移指南：v1.x 到 v2.0
-
-## 破壞性變更
-
-### 1. authenticate() 已移除
-
-**Before (v1.x)**:
-```javascript
-const token = await authenticate('user', 'pass');
-```
-
-**After (v2.0)**:
-```javascript
-const token = await authenticateV2({ username: 'user', password: 'pass' });
-```
-
-### 2. API response format changed
-
-**Before (v1.x)**:
-```json
-{ "data": { "user": {...} } }
-```
-
-**After (v2.0)**:
-```json
-{ "user": {...} }
-```
-
-Update your code:
-```javascript
-// Before
-const user = response.data.user;
-
-// After
-const user = response.user;
-```
-```
+本標準僅保留版本號規則：不相容變更必須以 MAJOR 遞增發布，棄用則應在退役前的某個 MINOR 版本先行宣告（見 [MAJOR 版本](#major-version-x00)指南）。
 
 ---
 
@@ -839,6 +833,8 @@ semver.major('2.3.1');  // 2
 - [Changelog Standards](changelog-standards.md) - 變更日誌標準
 - [Git Workflow Standards](git-workflow.md) - Git 工作流程標準
 - [Commit Message Guide](commit-message-guide.md) - Commit 訊息規範
+- [API Design Standards](api-design-standards.md) - API 版本化策略、向後相容性規則、遷移指南
+- [Deprecation & Sunset Standards](deprecation-standards.md) - 棄用生命週期與最短通知期間
 
 ---
 
@@ -846,6 +842,10 @@ semver.major('2.3.1');  // 2
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.5.0 | 2026-07-01 | Added: 自動化工具新增 git-height 衍生版本工具（MinVer / Nerdbank.GitVersioning / GitVersion），適用 polyglot / .NET / JVM 專案（UDS #138 R2）；將「Build 身分可被觀測」提升為需求——已部署服務 MUST 透過可查詢 endpoint 暴露 `version + commit sha + build time`——並於 Phase 5 部署後驗證新增 commit-sha + build-time 斷言（UDS #138 R3） |
+| 1.4.0 | 2026-06-24 | Moved out (to single sources): API Versioning Strategies (de-duplicated), Deprecation Timeline + per-tier periods, Backward Compatibility Checklist, Migration Guide template — now owned by api-design-standards / deprecation-standards (XSPEC-298 R8, UDS #126) |
+| 1.3.0 | 2026-06-23 | Added: Deployment Version Identity section; build-metadata-as-deployment-discriminator caveat (from UDS #138) |
+| 1.2.0 | 2025-12-30 | Added: API Versioning Strategies, Deprecation Timeline, Backward Compatibility Checklist |
 | 1.1.3 | 2025-12-24 | Added: Related Standards section |
 | 1.1.2 | 2025-12-11 | Improved: Upgrade package naming example to use generic placeholders instead of hardcoded project names |
 | 1.1.1 | 2025-12-04 | Refactored: CHANGELOG exclusion rules to be more generic (removed project-specific directories) |

package/bundled/locales/zh-TW/docs/CHEATSHEET.md

@@ -1,8 +1,8 @@
 # UDS 速查表
 
-> Quick reference for all UDS features | Last updated: 2026-05-14
+> Quick reference for all UDS features | Last updated: 2026-06-20
 
-**Language**: [English](../../../docs/CHEATSHEET.md) | 繁體中文 | [简体中文](../../zh-CN/docs/CHEATSHEET.md)
+**Language**: [English](../../../docs/user/CHEATSHEET.md) | 繁體中文 | [简体中文](../../zh-CN/docs/CHEATSHEET.md)
 
 ---
 
@@ -34,6 +34,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 |
@@ -52,6 +53,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" |
@@ -64,12 +66,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 |
@@ -85,7 +87,7 @@
 | `ai-instruction-standards` | Create and maintain AI instruction files (CLAUDE.md, AGENTS. |
 | `api-design-assistant` | Guide API design following REST, GraphQL, and gRPC best prac |
 | `atdd-assistant` | "[UDS] Guide through Acceptance Test-Driven Development work |
-| `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 crea |
 | `changelog-guide` | "[UDS] Generate and maintain CHANGELOG.md entries" |
@@ -105,7 +107,8 @@
 | `error-code-guide` | Design consistent error codes following the PREFIX_CATEGORY_ |
 | `git-workflow-guide` | Guide Git branching strategies, branch naming, and merge ope |
 | `incident-response-assistant` | Guide incident response, root cause analysis, and post-morte |
-| `journey-test-assistant` | "[UDS] 從專案描述生成連貫使用者旅程測試計畫（TESTPLAN）與 E2E 骨架" |
+| `journey-test-assistant` | "[UDS] Generate coherent user journey test plans (TESTPLAN)  |
+| `knowledge-graph` | "[UDS] Trace spec/decision/code impact chains via a knowledg |
 | `logging-guide` | Implement structured logging with proper log levels and sens |
 | `metrics-dashboard-assistant` | "[UDS] Track development metrics, code quality indicators, a |
 | `migration-assistant` | "[UDS] Guide code migration, framework upgrades, and technol |
@@ -120,7 +123,7 @@
 | `release-standards` | "[UDS] Guide release process and changelogs" |
 | `requirement-assistant` | "[UDS] Write user stories and requirements following INVEST  |
 | `retrospective-assistant` | [UDS] Guide structured team retrospectives for Sprint and Re |
-| `reverse-engineer` | "[UDS] System archeology — reverse engineer code across Logi |
+| `reverse-engineer` | "[UDS] System archeology - reverse engineer code across Logi |
 | `runbook-assistant` | Guide runbook creation, maintenance, and drill exercises. |
 | `security-assistant` | Guide security review and vulnerability assessment following |
 | `security-scan-assistant` | Guide automated security scanning, dependency auditing, and  |
@@ -174,6 +177,7 @@
 | `anti-hallucination` | This standard defines strict guidelines for AI ass |
 | `anti-sycophancy-prompting` | This standard defines techniques and rules for des |
 | `api-design-standards` | This standard defines comprehensive guidelines for |
+| `audit-trail` | Audit Trail Standards |
 | `behavior-driven-development` | Behavior-Driven Development (BDD) Standards |
 | `behavior-snapshot` | Behavior Snapshot Standard |
 | `branch-completion` | Define a standardized workflow for completing deve |
@@ -188,13 +192,16 @@
 | `circuit-breaker` | Circuit Breaker Standard |
 | `code-review-checklist` | This standard provides a comprehensive checklist f |
 | `commit-message-guide` | Standardized commit messages improve code review e |
+| `container-image-standards` | Container Image Build and Security Standards |
 | `container-security` | 容器安全標準 |
 | `containerization-standards` | Containerization Standards |
 | `context-aware-loading` | This standard defines a protocol for AI tools to s |
 | `contract-testing-standards` | Contract testing verifies that a provider (API ser |
 | `cost-budget-test` | Cost Budget Test Standards |
 | `cross-flow-regression` | This standard defines cross-flow regression testin |
+| `data-contract` | Data Contract Standards |
 | `data-migration-testing` | Data Migration Testing |
+| `data-pipeline` | Data Pipeline Standards |
 | `database-standards` | This standard defines guidelines for database desi |
 | `deployment-standards` | This standard defines guidelines for safely deploy |
 | `deprecation-standards` | Deprecation & Sunset Standards |
@@ -221,22 +228,30 @@
 | `git-worktree` | Define a lifecycle for using Git worktrees to isol |
 | `governance-layer` | A governance layer provides a shared anchor for al |
 | `health-check-standards` | Health Check Standards |
+| `iac-design-principles` | Infrastructure as Code Design Principles |
 | `immutability-first` | Immutability-First Architecture Standard |
+| `incident-response` | Incident Response Standards |
+| `knowledge-graph-memory` | This standard defines a **relationship schema** so |
 | `knowledge-transfer-standards` | Knowledge Transfer Standards |
+| `license-compliance` | License Compliance Standards |
 | `llm-output-validation` | LLM 輸出驗證標準 |
 | `logging-standards` | Logging Standards |
 | `mock-boundary` | This document defines rules for what can and canno |
+| `model-provenance` | Model Provenance Policy Standards |
 | `model-selection` | Define a cost-effective strategy for selecting AI  |
 | `mutation-testing` | Mutation testing evaluates test suite effectivenes |
 | `no-cicd-deployment` | No-CI/CD Deployment Strategy |
 | `observability-standards` | Observability Standards |
 | `packaging-standards` | This standard defines a Recipe-based packaging fra |
 | `performance-standards` | This standard defines comprehensive guidelines for |
+| `pii-classification` | PII Classification and Handling Standards |
 | `pipeline-integration-standards` | Pipeline Integration Standards |
 | `pipeline-security-gates` | Pipeline Security Gates（CI Pipeline 安全檢查點） |
 | `policy-as-code-testing` | Policy as Code 測試標準 |
 | `postmortem-standards` | Postmortem Standards (Blameless Post-Incident Review) |
+| `prd-standards` | Product Requirements Document Standards |
 | `privacy-standards` | Privacy Standards |
+| `product-metrics-standards` | Product Metrics Framework Standards |
 | `project-context-memory` | This standard defines a structured system for capt |
 | `project-structure` | This standard defines conventions for project dire |
 | `prompt-regression` | Prompt Regression Standards |
@@ -247,18 +262,24 @@
 | `release-readiness-gate` | This standard defines a **single, aggregated Relea |
 | `replay-test` | Replay Test Standards |
 | `requirement-engineering` | Requirement Engineering Standards |
+| `resource-cost-boundary` | Resource / Cost Boundary Declaration Standards |
 | `retrospective-standards` | Retrospectives are structured team reflections tha |
 | `retry-standards` | Retry Standards |
 | `reverse-engineering-standards` | This standard defines the principles, workflows, a |
 | `rollback-standards` | Rollback Standards（回滾標準） |
 | `runbook-standards` | Runbook Standards |
+| `runbook` | Runbook Writing Standards |
 | `sast-advanced` | This standard defines Advanced Static Application  |
+| `schema-evolution` | Schema Evolution Standards |
+| `secret-management-standards` | Secret Management and Credential Hygiene Standards |
 | `secure-op` | Secure-Op：AI Agent 安全操作標準 |
 | `security-decision` | Security Decision Standard |
 | `security-standards` | This standard defines comprehensive security guide |
 | `security-testing` | This document defines the security testing methodo |
+| `self-review-protocol` | This standard mandates a **self-review pass** on l |
 | `server-ops-security` | 伺服器操作安全標準 |
 | `skill-standard-alignment-check` | Skill-Standard Alignment Check |
+| `slo-sli` | SLO/SLI Definition Standards |
 | `slo-standards` | SLO Standards (Service Level Objectives) |
 | `smoke-test` | Smoke Test Standards |
 | `spec-driven-development` | Spec-Driven Development (SDD) Standards |
@@ -277,7 +298,9 @@
 | `timeout-standards` | Timeout Standards |
 | `token-budget` | Token Budget Zone Standard |
 | `translation-lifecycle-standards` | Translation lifecycle standards: MISSING vs OUTDAT |
+| `user-story-mapping` | User Story Mapping Standards |
 | `verification-evidence` | Establish an "Iron Law" that no task can be claime |
+| `verification-oracle` | Verification Oracle Standards |
 | `versioning` | This standard defines how to version software rele |
 | `virtual-organization-standards` | This standard treats the AI ecosystem as a "Virtua |
 | `workflow-enforcement` | Workflow Enforcement Standards |
@@ -332,6 +355,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 |
 | `install-hooks.mjs` | Install Hooks |
 | `install-hooks.sh` | DEPRECATED: Use 'node scripts/install-hooks.mjs' i |
@@ -340,6 +364,7 @@
 | `pre-release-check.sh` | Pre-release Check Script |
 | `pre-release.ps1` | Pre-Release Preparation Script for Universal Devel |
 | `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/DEV-WORKFLOW-MAPPING.md

@@ -34,7 +34,7 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 | I | **需求與設計** | `/brainstorm` `/requirement` `/sdd` `/reverse` | 從構想到規格 |
 | II | **測試驅動開發** | `/bdd` `/atdd` `/tdd` `/coverage` `/derive` | 先設計測試再寫程式 |
 | III | **程式碼開發** | `/refactor` `/reverse` | 撰寫與改善程式碼 |
-| IV | **品質保證** | `/checkin` `/review` | 提交前與程式碼審查 |
+| IV | **品質保證** | `/checkin` `/code-review` | 提交前與程式碼審查 |
 | V | **版本與提交** | `/commit` `/changelog` `/release` | 版本管理、提交、發布 |
 | VI | **文件與架構** | `/docs` `/docgen` `/struct` | 文件與專案結構 |
 | VII | **工具與標準參考** | `/discover` `/guide` | 健康檢查與參考資料 |
@@ -83,7 +83,7 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 | 指令 | 功能說明 | 輸入 | 輸出 |
 |------|----------|------|------|
 | `/checkin` | 提交前品質驗證 | 暫存的變更 | 通過/失敗檢查清單（建置、測試、密碼、風格） |
-| `/review` | 系統化程式碼審查（10 個面向） | 程式碼差異或 PR | 含嚴重性前綴的審查意見 |
+| `/code-review` | 系統化程式碼審查（10 個面向） | 程式碼差異或 PR | 含嚴重性前綴的審查意見 |
 
 ### V. 版本與提交
 
@@ -144,7 +144,7 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 步驟 9:  /refactor           提升程式碼品質
 步驟 10: /checkin            驗證品質關卡
 步驟 11: /commit             建立 Conventional Commit
-步驟 12: /review             程式碼審查（若有 PR）
+步驟 12: /code-review             程式碼審查（若有 PR）
 步驟 13: /docs               更新文件
 步驟 14: /changelog          更新 CHANGELOG
 步驟 15: /release            發布版本
@@ -191,7 +191,7 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 |------|------|----------|
 | **本文件**（DEV-WORKFLOW-MAPPING.md） | 階段與指令對照，快速參考 | 尋找合適指令的開發者 |
 | [DAILY-WORKFLOW-GUIDE.md](../../../adoption/DAILY-WORKFLOW-GUIDE.md) | 詳細的日常工作流程與決策樹 | 學習 UDS 採用模式的開發者 |
-| [CHEATSHEET.md](../../../docs/CHEATSHEET.md) | 所有 UDS 功能一頁總覽 | 快速查閱 |
+| [CHEATSHEET.md](../../../docs/user/CHEATSHEET.md) | 所有 UDS 功能一頁總覽 | 快速查閱 |
 | `/dev-workflow` skill | Claude Code 中的互動式指南 | AI 輔助開發 |
 
 ---
@@ -213,7 +213,7 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 | 改善程式碼結構 | `/refactor` |
 | 提交前檢查 | `/checkin` |
 | 建立提交訊息 | `/commit` |
-| 審查程式碼品質 | `/review` |
+| 審查程式碼品質 | `/code-review` |
 | 更新文件 | `/docs` 或 `/docgen` |
 | 準備發布版本 | `/changelog` 然後 `/release` |
 | 查詢標準 | `/guide [topic]` |
@@ -221,4 +221,4 @@ Universal Development Standards (UDS) 提供 **20+ 斜線指令**，涵蓋整個
 
 ---
 
-[完整功能參考](../../../docs/FEATURE-REFERENCE.md) | [GitHub](https://github.com/AsiaOstrich/universal-dev-standards)
+[完整功能參考](../../../docs/reference/FEATURE-REFERENCE.md) | [GitHub](https://github.com/AsiaOstrich/universal-dev-standards)