universal-dev-standards 5.17.0 → 6.0.0

package/bundled/locales/zh-TW/core/no-cicd-deployment.md

@@ -0,0 +1,219 @@
+---
+source: ../../../core/no-cicd-deployment.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: dbe8c04bf6a4
+status: current
+---
+
+# No-CI/CD Deployment Strategy
+
+> **Language**: [English](../../../core/no-cicd-deployment.md) | 繁體中文
+
+> **補充**: 本文件補充 `deployment-standards.md`，專注於無 CI/CD 平台（GitHub Actions / GitLab CI）環境下的可靠部署設計。
+
+## 核心三層架構
+
+```
+Layer 1: 防止錯誤部署
+  └─ set -euo pipefail、版本 tag 強制、deploy.lock
+
+Layer 2: 驗證部署正確
+  └─ Smoke Test、健康檢查、版本號比對、自動 rollback
+
+Layer 3: 快速回復能力
+  └─ Blue-Green 切換、< 30 秒 rollback
+```
+
+## Layer 1：防止錯誤部署
+
+### Shell 腳本強制執行
+
+所有部署腳本必須以下列標頭開始：
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+```
+
+- `set -e`：任何命令失敗立即退出
+- `set -u`：引用未定義變數視為錯誤
+- `set -o pipefail`：管線中任何命令失敗都會傳播錯誤
+
+### 強制部署順序
+
+```bash
+echo "[1/4] 執行測試..."
+npm test
+
+echo "[2/4] 建置產物..."
+npm run build
+
+echo "[3/4] 推送到伺服器..."
+rsync -avz --delete ./dist/ user@server:/app/
+
+echo "[4/4] 驗證部署..."
+./verify.sh || { echo "驗證失敗，執行 rollback..."; ./rollback.sh; exit 1; }
+```
+
+### deploy.lock 防並發
+
+```bash
+LOCK_FILE="/tmp/deploy.lock"
+trap "rm -f $LOCK_FILE" EXIT
+
+if [ -f "$LOCK_FILE" ]; then
+  echo "❌ 部署進行中（PID: $(cat $LOCK_FILE)），請等待完成"
+  exit 1
+fi
+
+echo $$ > "$LOCK_FILE"
+```
+
+### 版本 Tag 強制
+
+```bash
+CURRENT_TAG=$(git describe --exact-match --tags HEAD 2>/dev/null || echo "")
+if [ -z "$CURRENT_TAG" ]; then
+  echo "❌ 當前 commit 沒有版本 tag，請先執行："
+  echo "   git tag v$(cat VERSION) && git push --tags"
+  exit 1
+fi
+```
+
+## Layer 2：驗證部署正確
+
+### Smoke Test 腳本 (verify.sh)
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+HEALTH_URL="${HEALTH_URL:-https://example.com/health}"
+EXPECTED_VERSION=$(cat VERSION)
+MAX_RETRIES=3
+RETRY_INTERVAL=5
+
+for i in $(seq 1 $MAX_RETRIES); do
+  RESPONSE=$(curl -sf --max-time 10 "$HEALTH_URL" 2>/dev/null) && break
+  echo "健康檢查失敗 ($i/$MAX_RETRIES)，等待 ${RETRY_INTERVAL}s..."
+  sleep $RETRY_INTERVAL
+done
+
+ACTUAL_VERSION=$(echo "$RESPONSE" | python3 -c "import json,sys; print(json.load(sys.stdin)['version'])")
+
+if [ "$ACTUAL_VERSION" != "$EXPECTED_VERSION" ]; then
+  echo "❌ 版本不符！預期 $EXPECTED_VERSION，實際 $ACTUAL_VERSION"
+  exit 1
+fi
+
+echo "✅ 版本驗證通過：$ACTUAL_VERSION"
+```
+
+### 健康檢查端點規格
+
+應用程式必須提供 `/health` 端點，回應格式：
+
+```json
+{
+  "status": "ok",
+  "version": "1.2.3",
+  "timestamp": "2026-04-26T10:00:00Z"
+}
+```
+
+## Layer 3：快速回復能力
+
+### Blue-Green 架構
+
+```
+[Nginx]
+  │
+  ├─── Blue (port 3001) ← 穩定版（當前 active）
+  └─── Green (port 3002) ← 新版（部署目標）
+```
+
+**Nginx 配置**：
+
+```nginx
+upstream app {
+  server 127.0.0.1:3001;  # blue
+  # server 127.0.0.1:3002;  # green（切換時啟用此行並停用上一行）
+}
+
+server {
+  listen 80;
+  location / {
+    proxy_pass http://app;
+  }
+}
+```
+
+### Rollback 腳本 (rollback.sh)
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+CURRENT=$(readlink /app/current)
+if [[ "$CURRENT" == *"green"* ]]; then
+  TARGET="/app/blue"
+else
+  TARGET="/app/green"
+fi
+
+ln -sfn "$TARGET" /app/current
+nginx -s reload
+
+echo "✅ 已切回 $TARGET（$(date -u +%Y-%m-%dT%H:%M:%SZ)）"
+
+# 記錄 rollback 事件
+echo "{\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"event\":\"rollback\",\"from\":\"$CURRENT\",\"to\":\"$TARGET\",\"operator\":\"$(whoami)\"}" >> /var/log/deployments.jsonl
+```
+
+### 完整 Makefile
+
+```makefile
+.PHONY: deploy rollback verify
+
+deploy:
+	@./deploy.sh
+
+rollback:
+	@./rollback.sh
+
+verify:
+	@./verify.sh
+
+status:
+	@echo "Current: $$(readlink /app/current)"
+	@curl -s $${HEALTH_URL:-http://localhost/health} | python3 -m json.tool
+```
+
+## Deployment Log 格式
+
+每次部署（成功或失敗）都必須寫入 JSON Lines 格式的日誌：
+
+```json
+{"timestamp":"2026-04-26T10:00:00Z","version":"1.2.3","git_commit":"abc1234","operator":"albert","result":"success","duration_seconds":45,"slot":"green"}
+{"timestamp":"2026-04-26T11:30:00Z","version":"1.2.4","git_commit":"def5678","operator":"albert","result":"failure","duration_seconds":12,"slot":"green","error":"version_mismatch"}
+```
+
+## 適用場景
+
+| 場景 | 建議 |
+|------|------|
+| 個人 VPS / 小型專案 | Layer 1 + Layer 2（無需 Blue-Green） |
+| 自架伺服器（多人團隊） | 三層全套 + deploy.lock |
+| Air-gapped 環境 | 三層全套 + 本地 artifact registry |
+| 容器化部署 | 搭配 `docker compose` 執行 |
+
+## 相關標準
+
+- `deployment-standards.ai.yaml` — 有 CI/CD 平台的部署策略（本文件的補充前提）
+- `health-check-standards.ai.yaml` — /health 端點設計規範
+- `circuit-breaker.ai.yaml` — 斷路器整合（進階場景）
+
+
+**Scope**: universal

package/bundled/locales/zh-TW/core/packaging-standards.md

@@ -1,8 +1,9 @@
 ---
 source: ../../../core/packaging-standards.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-04-15
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-06-10
+source_hash: aa338edba3b1
 status: current
 ---
 
@@ -10,8 +11,8 @@ status: current
 
 > **語言**: [English](../../../core/packaging-standards.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-04-15
+**版本**: 1.1.0
+**最後更新**: 2026-05-26
 **適用性**: 使用 UDS-aware 工具鏈的專案
 **範圍**: 通用 (Universal)
 
@@ -202,6 +203,75 @@ targets:
 
 ---
 
+## Archive 格式完整性
+
+當打包步驟產生將由部署腳本消費的 archive（`.zip`、`.tar.gz`、`.tar.bz2` 等）時，**真實的二進位格式必須與副檔名相符**。命名為 `.zip` 的檔案必須是真正的 ZIP archive（PKZip magic `PK\x03\x04`），而非改名的 tar archive。
+
+> **為何強制要求：** archive 格式不符會在下游觸發靜默失敗。PowerShell 的 `Expand-Archive` 和 `[System.IO.Compression.ZipFile]::ExtractToDirectory()` 接受 tar 改名的 `.zip` **而不拋出錯誤**——檔案被讀取，什麼都沒有解壓縮，也沒有例外。若部署腳本的下一步是破壞性的（例如「刪除現有安裝目錄」），運行中的安裝就會被摧毀而無任何替代物。
+
+### 發布前驗證
+
+每個產生 archive 的打包步驟**必須**在宣告成功前包含格式驗證。最低驗證要求：
+
+| 格式 | 驗證單行指令 |
+|---|---|
+| `.zip` | `python -c "import zipfile; zipfile.ZipFile('out.zip').namelist()"` 必須成功 |
+| `.zip`（Unix） | `file out.zip` 必須回報 `Zip archive data`，**而非** `POSIX tar archive` |
+| `.tar.gz` | `tar -tzf out.tar.gz >/dev/null` 必須成功 |
+| 任何格式 | 選用：雜湊比對預期檔案的 manifest |
+
+驗證失敗必須在發布前中止打包管線。
+
+### 各平台設定範例
+
+**Windows — 應該這樣做：**
+
+```powershell
+# 選項 A：PowerShell 內建（產生真正的 ZIP）
+Compress-Archive -Path "publish\*" -DestinationPath "dist\patch.zip" -Force
+
+# 選項 B：.NET API（產生真正的 ZIP）
+Add-Type -Assembly System.IO.Compression.FileSystem
+[System.IO.Compression.ZipFile]::CreateFromDirectory(
+    "publish", "dist\patch.zip", "Optimal", $false
+)
+```
+
+**Windows — 不應該這樣做：**
+
+```bash
+# ❌ git-bash / busybox tar -a -cf 在 Windows 上不可靠
+# -a「依副檔名自動」旗標會產生副檔名為 .zip 的 POSIX tar archive。
+# `file patch.zip` → "POSIX tar archive (GNU)"（而非 "Zip archive data"）
+cd publish && tar -a -cf "../dist/patch.zip" api/
+```
+
+**類 Unix — 應該這樣做：**
+
+```bash
+# ZIP archive 使用 'zip'（BSD/Linux）
+zip -r dist/patch.zip publish/
+
+# tar.gz archive 使用 'tar -czf'（不加 -a）——明確且確定性
+tar -czf dist/patch.tar.gz publish/
+
+# 發布前驗證
+file dist/patch.zip            # 預期 "Zip archive data"
+python -c "import zipfile; zipfile.ZipFile('dist/patch.zip').namelist()"
+```
+
+### 消費端防禦
+
+生產端無法保證消費端一定會驗證。消費端（部署腳本）**必須**在任何破壞性動作前驗證 archive 完整性。消費端需求請參閱[部署標準 — 防禦性部署順序](deployment-standards.md#防禦性部署順序)。
+
+### 失敗模式參考（真實事故）
+
+一個 Windows IIS 正式部署腳本（2026-05-24）在 git-bash 中使用 `tar -a -cf patch.zip api/` 產生其發行 archive。消費端的 PowerShell 部署腳本接著執行 `Expand-Archive`（對 tar 改名檔案靜默空操作），繼續對運行中的 `apiDir` 執行 `Remove-Item -Recurse`，然後從一個不存在的來源執行 `Copy-Item`（因為什麼都沒有被解壓縮）。運行中的安裝被清除，AppPool 停止，正式環境中斷約 3 分鐘，直到完成基於備份的回滾。
+
+（a）生產端使用自動副檔名 tar，加上（b）消費端未驗證解壓縮輸出，兩者組合在任何步驟都沒有拋出錯誤的情況下摧毀了運行中的安裝。
+
+---
+
 ## 相關標準
 
 - [部署標準](deployment-standards.md) — 打包後的部署階段
@@ -215,6 +285,7 @@ targets:
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| 1.1.0 | 2026-05-26 | 新增：Archive 格式完整性章節——真實格式必須符合副檔名規則、驗證單行指令、Windows 正確/錯誤做法清單、真實事故參考（XSPEC-231 / 關閉 issue #113） |
 | 1.0.0 | 2026-04-15 | 初始發行 — XSPEC-034 Phase 1 |
 
 ---

package/bundled/locales/zh-TW/core/performance-standards.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/performance-standards.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-03-24
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-06-17
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/performance-standards.md) | 繁體中文
 
-**版本**: 1.1.0
-**最後更新**: 2026-01-29
+**版本**: 1.2.0
+**最後更新**: 2026-06-17
 **適用性**: 所有軟體專案
 **範圍**: 通用 (Universal)
 **業界標準**: ISO/IEC 25010 效能效率
@@ -126,6 +126,83 @@ status: current
 
 ---
 
+## 遷移非功能性對等（XSPEC-286）
+
+> 屬於 [XSPEC-284](https://github.com/AsiaOstrich/universal-dev-standards) 9 軸遷移完整性矩陣的**軸⑥（非功能）**。涵蓋舊系統重構/重寫時「功能對了、資料對了，但**跑起來不一樣**」這一類遺漏。本節在上述通用基線/漂移機制之上**新增遷移專屬**的 before/after 語義，**不取代**通用效能框架。
+
+### 為何是真缺口
+
+上述通用基線管理回答的是「**這個版本**相較**它自己**先前的基線是否回歸」，**不**回答「**新**系統是否與它取代的**legacy**對等」。重寫時（如 PHP 單請求 → .NET 共享狀態多執行緒），legacy 的延遲/吞吐/隔離特性多為**隱性、未文件化**，使 per-request 功能對等與 behavior-snapshot 對等都通過，系統卻悄悄跑得更慢、耗盡更小的連線池、或丟失某個鎖語義。
+
+### 差分神諭，非絕對門檻
+
+遷移對等以 **legacy 為基線** + **宣告容差**，而非上述表格的絕對目標。legacy 量測到的行為就是 oracle，「回歸不超過宣告容差」即 pass。讓分歧自報，而非靠人記得列舉每條熱路徑。
+
+### 步驟 1 — 機械化擷取非功能基線（R3）
+
+legacy 非功能特性多為隱性。從 legacy artifact **機械化**推導基線（不靠人腦回憶）：
+
+| 來源 | 推導出的基線項 |
+|------|---------------|
+| 關鍵路由 / controller | 各關鍵路徑 p50 / p95 / p99 延遲 |
+| 熱點查詢 / 慢查詢 log | 每查詢延遲、掃描列數 |
+| 背景作業 / cron | 作業時長、吞吐（records/min） |
+| 連線池設定 | min/max 連線數、idle/connection timeout |
+| 逾時 / rate-limit 設定 | 每端點逾時、requests/min、burst |
+| 交易設定 | 隔離級別（READ COMMITTED / REPEATABLE READ / SERIALIZABLE） |
+
+擷取的集合**同時**是回歸 gate 的比較基線**與**資源/限制 parity（步驟 4）的待驗清單。
+
+### 步驟 2 — 效能回歸差分 gate（R1）
+
+對每條基線路徑，量測新系統對應路徑，與 **legacy 基線**在宣告容差內比較。
+
+| 指標 | 預設遷移容差 | block 條件 |
+|------|-------------|-----------|
+| p50 延遲 | ≤ +10%（vs legacy） | > +10% |
+| p95 延遲 | ≤ +15%（vs legacy） | > +15% |
+| p99 延遲 | ≤ +20%（vs legacy） | > +20% |
+| 吞吐 | ≤ -10%（vs legacy） | > -10% 下降 |
+
+容差**每路徑可配**（批次作業與互動端點不同）。**shadow** 起手（只量測不 block）以收樣校準每路徑容差，再升為 blocking。
+
+**Gate 時機**：pre-UAT（簽核前抓回歸）**與** post-cutover（抓只在真實生產負載下浮現的回歸）。
+
+### 步驟 3 — 並發隔離驗證（R2）
+
+同一資源（同筆記錄 / 同帳戶餘額 / 同序號）可能被多並發操作存取。legacy 的鎖 / 交易隔離 / 順序保證屬**隱性行為**，重寫常被改變——而**功能測試與 behavior-snapshot 對等都抓不到**（per-request 對等 ≠ 並發對等，與「per-request ≠ data-at-rest」同源盲區）。
+
+**方法**：以併發壓力觸發 race，斷言**領域不變量**而非逐一檢查輸出。
+
+| 不變量類別 | 範例斷言 |
+|-----------|---------|
+| 守恆 | N 次並發轉帳後 `SUM(balance)` 不變 |
+| 唯一性 | 並發配號下無重複序號 |
+| 無遺失更新 | 已 commit 的寫入不被靜默覆寫 |
+| 順序 | 並發下事件依保證順序套用 |
+
+偵測到**隔離降級**（如 legacy SERIALIZABLE → 新 READ COMMITTED、或移除列鎖）即 block。不變量由領域定義；並發案例與狀態轉移/時序不變量重疊時，**狀態機/時序由 XSPEC-287（軸⑧）負責**，並發競態由本節（軸⑥）負責——見 XSPEC-287 §邊界。
+
+**Gate 時機**：pre-UAT。
+
+### 步驟 4 — 資源 / 限制 parity（R4）
+
+驗證 legacy 資源限制不被重寫**無意**改變（逾時從 30s 悄悄降到 5s 會讓長作業失敗；更小的連線池會串行化流量）。納入非功能對帳清單：
+
+- [ ] 請求 / 操作**逾時**與 legacy 一致（或變更已宣告）
+- [ ] **Rate limit**（requests/min、burst）與 legacy 一致
+- [ ] **連線池** min/max 與 idle/connection timeout 與 legacy 一致
+- [ ] **批次大小**與 legacy 一致
+- [ ] **交易隔離級別**與 legacy 一致（與步驟 3 交叉檢查）
+
+每項要嘛匹配、要嘛有**宣告且具理由**的差異。未宣告的差異即已知回歸風險，block cutover。
+
+### 完整性宣告（矩陣對齊）
+
+當本節宣告三件事——**清單來源**（步驟 1 機械化基線）、**oracle**（步驟 2 回歸差分 + 步驟 3 不變量斷言）、**gate 時機**（pre-UAT + post-cutover）——即滿足遷移完整性矩陣軸⑥。複用通用基線/漂移與 `observability-assistant` 量測機制——本節只新增遷移 before/after 與並發隔離語義，不重造通用效能框架。
+
+---
+
 ## 相關標準
 
 - [部署標準](deployment-standards.md)
@@ -133,3 +210,5 @@ status: current
 - [測試標準](testing-standards.md)
 - [需求工程](requirement-engineering.md) - NFR 文件
 - [日誌標準](logging-standards.md) - 效能日誌
+- [行為快照](behavior-snapshot.md) - 功能對等 oracle（與遷移非功能對等互補）
+- [完整覆蓋測試](full-coverage-testing.md) - 並發維度交叉引用

package/bundled/locales/zh-TW/core/pii-classification.md

@@ -0,0 +1,102 @@
+---
+source: ../../../core/pii-classification.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-17
+source_hash: f4ff92c3fe1d
+status: stale
+---
+
+# PII 分類與處理標準
+
+> **Language**: [English](../../../core/pii-classification.md) | 繁體中文
+
+> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **AI 最佳化版本**: `ai/standards/pii-classification.ai.yaml`
+> **規格**: XSPEC-066（cross-project/specs/XSPEC-066-uds-compliance-audit-pack.md）
+
+## 概觀
+
+本標準定義**個人可識別資訊（PII）**與敏感個資如何分類、標記、儲存、傳輸與銷毀。
+涵蓋三級資料敏感度分類、各級必備處理控制、資料最小化原則、同意管理要求、保留／
+刪除排程，以及跨境傳輸限制。與 GDPR 第 9 條、CCPA 及一般 privacy-by-design 原則
+對齊。
+
+本標準屬於**合規與稽核標準包**（XSPEC-066）。其定義的 PII 等級驅動
+`logging-standards` 執行的遮罩規則，以及 `audit-trail` 記錄的必備資料存取事件。
+
+> **範圍**：本標準定義*分類等級*與各級*處理控制*。具體遮罩／tokenization 函式庫、
+> 存放加密金鑰的 secrets store，以及 PIA 工作流程工具屬採用者的選擇。
+
+## 需求
+
+| ID | 規則 | 等級 |
+|----|------|------|
+| REQ-001 | PII 資料敏感度分類（TIER-1/2/3） | MUST |
+| REQ-002 | 資料最小化與目的限制 | MUST |
+| REQ-003 | 非正式環境的 PII 遮罩與匿名化 | MUST |
+| REQ-004 | 資料保留與刪除排程 | MUST |
+| REQ-005 | 跨境資料傳輸控制 | MUST |
+| REQ-006 | 新功能的 PII 衝擊評估（PIA） | SHOULD |
+
+### REQ-001 — PII 資料敏感度分類
+
+所有含個人資訊的資料欄位，MUST 在儲存或處理前分類為以下三級之一：
+
+| 等級 | 範例 | 必備控制 |
+|------|------|----------|
+| **TIER-1**（高度敏感） | 健康資料、金融帳號、政府識別碼、生物特徵、密碼、SSN | 靜態與傳輸中加密、存取記錄、不快取 |
+| **TIER-2**（敏感） | 全名 + 聯絡資訊組合、位置歷史、行為輪廓、IP 位址 | 傳輸中加密、存取控制 |
+| **TIER-3**（一般 PII） | 僅名、國家層級位置、一般人口統計 | 標準存取控制 |
+
+### REQ-002 — 資料最小化與目的限制
+
+系統 MUST 僅蒐集明確聲明目的所必需的最少 PII。資料模型中每個 PII 欄位 MUST 具備
+文件化的業務目的與法律依據（同意、契約、正當利益、法律義務）。蒐集未具文件化目的
+的 PII 為 **PROHIBITED**。目的限制 MUST 被強制執行：為目的 A 蒐集的資料，未經另行
+同意 MUST NOT 用於不相關的目的 B。
+
+### REQ-003 — 非正式環境的 PII 遮罩與匿名化
+
+除非明確需要並經核准，PII MUST NOT 存在於非正式環境（開發、staging、測試）。測試／
+staging 資料庫 MUST 使用匿名化或合成資料。任何核准的例外 MUST 有時限、受存取控制
+並文件化。PII MUST 在應用日誌中遮罩：email 顯示為 `u***@domain.com`、電話為
+`+1-XXX-XXX-1234`、卡號為 `****-****-****-1234`。
+
+### REQ-004 — 資料保留與刪除排程
+
+每個含 PII 的資料類別 MUST 具備文件化保留排程，其最大保留期須對齊法律要求與業務
+需要。MUST 對超過保留期的資料實作自動刪除。刪除 MUST 可驗證（刪除收據或稽核日誌）。
+行使刪除權（right to erasure）的使用者 MUST 在 30 天內（GDPR）或 45 天內（CCPA）
+收到刪除確認。
+
+### REQ-005 — 跨境資料傳輸控制
+
+TIER-1 或 TIER-2 PII 的跨國境傳輸 MUST 遵循適用的傳輸機制。EU → 非適足性國家的
+傳輸 MUST 使用標準契約條款（SCC）或拘束性企業規則。資料落地（residency）要求 MUST
+記載於系統設計中。跨境傳輸 MUST 記錄目的地國家與法律依據。
+
+### REQ-006 — 新功能的 PII 衝擊評估
+
+任何引入新 PII 蒐集或處理的新功能或系統變更，SHOULD 在實作前進行隱私衝擊評估
+（PIA）。PIA MUST 記載：蒐集何種 PII、目的、法律依據、保留期、第三方分享，以及
+風險緩解。含 TIER-1 PII 的功能須強制 PIA；TIER-2 為建議。
+
+## 與既有標準的整合
+
+- **`audit-trail`**——TIER-1／TIER-2 PII 讀取、匯出與刪除請求為必備稽核事件。
+- **`logging-standards`**——執行本標準要求的遮罩規則。
+- **`security-standards`**——TIER-1 的靜態／傳輸加密控制引用專案安全基線。
+- **`database-standards`**——資料字典欄位帶有 PII 等級與 REQ-002 的文件化目的／
+  法律依據。
+
+## 相關規格
+
+- XSPEC-066 — UDS 合規與稽核標準包（本標準來源）
+- DEC-041 — EU AI Act 2026 合規（PII 處理作為合規支柱）
+
+## 變更紀錄
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| v1.0.0 | 2026-06-17 | 初版——REQ-001~006：PII 等級、資料最小化、非正式環境遮罩、保留／刪除、跨境傳輸、PIA（XSPEC-066） |

package/bundled/locales/zh-TW/core/pipeline-security-gates.md

@@ -0,0 +1,126 @@
+---
+source: ../../../core/pipeline-security-gates.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-06-10
+source_hash: a2d6e88e26c8
+status: current
+---
+
+# Pipeline Security Gates（CI Pipeline 安全檢查點）
+
+> **Language**: [English](../../../core/pipeline-security-gates.md) | 繁體中文
+
+---
+
+## 概述
+
+本標準定義嵌入 CI pipeline 各階段的安全檢查點，涵蓋 SAST、DAST、SCA（含 SBOM）和機密掃描，並明確規定各類發現的阻斷（Block）、警告（Warn）、記錄（Log）行為。
+
+---
+
+## 核心原則
+
+- **機密掃描在 pre-commit**：所有包含機密的提交都必須被阻擋，不得例外
+- **SAST 在建置後**：Critical 和 High 等級發現阻斷 pipeline
+- **SCA + SBOM 在封包階段**：追蹤相依套件風險並產生物料清單
+- **DAST 在 staging 部署後**：對運行中的應用進行動態掃描
+- **安全閘門失敗 = pipeline 失敗**：不得視為可忽略的警告
+- **任何繞過都需審計軌跡**：禁止靜默跳過安全閘門
+
+---
+
+## 安全閘門位置與配置
+
+### 1. Pre-Commit — 機密掃描
+
+| 項目 | 說明 |
+|------|------|
+| 掃描範圍 | 所有 staged 檔案 |
+| 推薦工具 | gitleaks、trufflehog、detect-secrets |
+| 阻斷條件 | 任何機密模式匹配 |
+| 可跳過 | 否（`never_skip: true`） |
+
+**重要**：此閘門必須在程式碼進入版本控制前執行，一旦機密進入 git 歷史便需要完整的機密輪換程序。
+
+---
+
+### 2. Post-Build — SAST（靜態應用安全測試）
+
+| 項目 | 說明 |
+|------|------|
+| 掃描範圍 | 原始碼 + 建置產出物 |
+| 推薦工具 | semgrep、codeql、sonarqube |
+| 阻斷條件 | Critical、High |
+| 警告條件 | Medium |
+| 僅記錄 | Low、Info |
+
+---
+
+### 3. Package Stage — SCA + SBOM
+
+| 項目 | 說明 |
+|------|------|
+| 掃描範圍 | 相依套件 + 容器映像 |
+| 推薦工具 | trivy、syft、grype、dependabot |
+| 阻斷條件 | Critical CVE（有可用修復版本） |
+| 警告條件 | High CVE、過時相依套件 |
+| SBOM 格式 | SPDX、CycloneDX |
+
+**SBOM 用途**：上傳至 dependency-track 或 grype-db 進行持續監控。
+
+---
+
+### 4. Post-Staging Deploy — DAST（動態應用安全測試）
+
+| 項目 | 說明 |
+|------|------|
+| 掃描範圍 | 運行中的 staging 應用程式 |
+| 推薦工具 | ZAP、nuclei、BurpSuite Enterprise |
+| 阻斷條件 | Critical |
+| 需審核批准 | High |
+| 警告條件 | Medium |
+
+---
+
+## 嚴重性回應矩陣
+
+| 嚴重性 | 動作 | 通知對象 | SLA |
+|--------|------|---------|-----|
+| Critical | 阻斷 pipeline | 資安團隊 | 立即 |
+| High | 阻斷 pipeline | 團隊主管 | 當日 |
+| Medium | 警告 + 需審核批准 | 開發者 | 下個 Sprint |
+| Low | 僅記錄 | 無 | Backlog |
+
+---
+
+## 繞過政策
+
+**預設禁止繞過**。
+
+若有特殊情況：
+- **例外流程**：需書面資安審核 + 審計日誌記錄
+- **緊急繞過**：時效性令牌（time-limited token）+ 強制事後審查
+
+---
+
+## 整合點
+
+| 整合項目 | 說明 |
+|---------|------|
+| 機密管理 | 整合 HashiCorp Vault 或 AWS Secrets Manager 進行機密注入 |
+| SBOM 註冊表 | 上傳 SBOM 至 dependency-track 或 grype-db 持續監控 |
+| 事故回應 | Critical 發現自動建立事故單 |
+
+---
+
+## 相關標準
+
+- [security-standards.md](../../../core/security-standards.md) — 應用安全基礎標準
+- [pipeline-integration-standards.md](../../../core/pipeline-integration-standards.md) — CI 管線整合標準
+- [deployment-standards.md](../../../core/deployment-standards.md) — 部署基礎原則
+- AI 格式：[pipeline-security-gates.ai.yaml](../../../ai/standards/pipeline-security-gates.ai.yaml)
+
+---
+
+**Scope**: universal