universal-dev-standards 5.0.0-rc.8 → 5.0.0

package/bundled/locales/zh-TW/core/behavior-driven-development.md

@@ -0,0 +1,63 @@
+---
+source: ../../../core/behavior-driven-development.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 行為驅動開發（BDD）標準
+
+> **語言**: [English](../../../core/behavior-driven-development.md) | 繁體中文
+
+**版本**: 1.1.0
+**最後更新**: 2026-01-25
+**適用性**: 所有採用行為驅動開發的專案
+**範圍**: 通用 (Universal)
+**業界標準**: 無（Dan North 實踐，2006）
+
+---
+
+## 摘要
+
+行為驅動開發（BDD）是由 Dan North 於 2006 年創建的傳統開發方法論，旨在縮小業務與技術團隊之間的溝通鴻溝。軟體行為透過協作以 **Given-When-Then** 場景描述，使用 Gherkin 語法 — 一種利害關係人可以閱讀和驗證的自然語言格式。
+
+BDD 構成雙循環 TDD（GOOS 模式）的**外層循環**，BDD 場景驅動功能層級的行為，而 TDD 處理單元層級的實作。該方法論遵循「發現-表述-自動化」的工作流程，由 Three Amigos 協作（業務 + 開發 + 測試）確保共同理解。
+
+---
+
+**完整指南：[BDD 指南](../../../methodologies/guides/bdd-guide.md)**
+
+---
+
+## 快速參考
+
+| 面向 | 說明 |
+|------|------|
+| **核心工作流** | 發現 → 表述 → 自動化 |
+| **語言** | Gherkin（Given-When-Then） |
+| **測試層級** | 功能/場景測試 |
+| **參與者** | 開發人員 + BA + QA（Three Amigos） |
+| **工具** | Cucumber、Behave、SpecFlow |
+
+## Gherkin 語法範例
+
+```gherkin
+Feature: 使用者登入
+  作為一個已註冊的使用者
+  我希望能夠登入系統
+  以便存取我的個人資料
+
+  Scenario: 使用有效憑證登入
+    Given 使用者已在登入頁面
+    When 使用者輸入有效的帳號和密碼
+    Then 系統應重導至儀表板
+    And 顯示歡迎訊息
+```
+
+## 相關標準
+
+- [測試驅動開發](../../../core/test-driven-development.md)
+- [驗收測試驅動開發](acceptance-test-driven-development.md)
+- [規格驅動開發](spec-driven-development.md)
+- [測試標準](testing-standards.md)

package/bundled/locales/zh-TW/core/branch-completion.md

@@ -0,0 +1,76 @@
+---
+source: ../../../core/branch-completion.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 分支完成工作流程
+
+> **語言**: [English](../../../core/branch-completion.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-20
+**適用性**: 所有使用 Git 分支工作流的專案
+**範圍**: 通用 (Universal)
+**靈感來源**: [Superpowers](https://github.com/obra/superpowers) — finishing-a-development-branch (MIT)
+
+---
+
+## 目的
+
+定義分支完成的標準化工作流，包含前置檢查、四個完成選項與安全丟棄流程。防止過早合併、遺忘分支與意外資料遺失。
+
+---
+
+## 術語表
+
+| 術語 | 定義 |
+|------|------|
+| 分支完成 (Branch Completion) | 完成功能/修復分支工作的過程 |
+| 前置條件 (Prerequisites) | 分支被視為完成前必須滿足的條件 |
+| 丟棄確認 (Discard Confirmation) | 刪除工作前需要明確輸入的安全機制 |
+
+---
+
+## 核心原則 — 先測試再討論
+
+> **所有測試必須通過，才能討論完成選項。**
+
+---
+
+## 前置條件
+
+在選擇任何完成選項之前，必須通過以下檢查：
+
+| 檢查項目 | 說明 |
+|----------|------|
+| 所有測試通過 | `npm test` 或專案對應的測試指令 |
+| 無未提交的變更 | `git status` 顯示乾淨的工作目錄 |
+| 分支已與目標分支同步 | 已 rebase 或 merge 最新的目標分支 |
+| 程式碼品質通過 | linting、type check 等品質門檻 |
+
+## 四個完成選項
+
+| 選項 | 適用場景 | 指令 |
+|------|----------|------|
+| **Merge** | 功能完成，準備合併到目標分支 | `git merge` 或建立 PR |
+| **Squash Merge** | 多個小提交需要壓縮為一個 | `git merge --squash` |
+| **Rebase** | 保持線性歷史 | `git rebase target-branch` |
+| **Discard** | 放棄此分支的工作 | 需丟棄確認 |
+
+## 安全丟棄流程
+
+丟棄分支前必須：
+
+1. **確認** — 明確輸入分支名稱確認丟棄意圖
+2. **備份** — 建立標籤保留最後狀態：`git tag archive/branch-name`
+3. **清理** — 刪除本地和遠端分支
+
+## 相關標準
+
+- [Git Worktree 隔離](git-worktree.md)
+- [代理派遣與並行協調](agent-dispatch.md)
+- [提交規範](checkin-standards.md)
+- [Git 工作流](git-workflow.md)

package/bundled/locales/zh-TW/core/change-batching-standards.md

@@ -0,0 +1,265 @@
+---
+source: ../../../core/change-batching-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-18
+status: current
+---
+
+# 變更批次標準
+
+> **語言**: [English](../../../core/change-batching-standards.md) | 繁體中文
+
+**適用範圍**: 所有使用自動化開發流程的軟體專案
+**Scope**: universal
+
+---
+
+## 概述
+
+變更批次標準定義了待處理變更應如何累積、評估並合併為原子性提交。本標準填補了個別變更與提交之間的空白，提供在何時以及如何將多個相關變更批次整合為有機一體的規則。
+
+## 參考資料
+
+| 標準／來源 | 內容 |
+|------------|------|
+| SWEBOK v4.0 第 6 章 | 軟體配置管理 |
+| ISO/IEC 12207 | 配置管理流程 |
+| Continuous Delivery（Jez Humble） | 小批次原則 |
+| Lean Software Development | 批次大小最佳化 |
+
+---
+
+## 待處理變更狀態機
+
+### 狀態定義
+
+```
+┌─────────┐    threshold met    ┌─────────┐    merge success    ┌─────────┐
+│ PENDING │───────────────────▶│  READY  │────────────────────▶│ MERGED  │
+│ 等待中   │                    │ 就緒     │                     │ 已合併   │
+└─────────┘                    └─────────┘                     └─────────┘
+     ▲                              │                               │
+     │ reset                        │ merge failure                 │
+     │                              ▼                               ▼
+     │                        ┌─────────┐                    ┌──────────┐
+     └────────────────────────│ FAILED  │                    │ ARCHIVED │
+                              │ 失敗     │                    │ 已歸檔    │
+                              └─────────┘                    └──────────┘
+```
+
+### 狀態轉換
+
+| 來源 | 目標 | 觸發條件 | 動作 |
+|------|------|----------|------|
+| PENDING | PENDING | 新增變更 | 遞增計數器，重新評估門檻 |
+| PENDING | READY | 達到門檻 | 準備合併批次，執行合併前驗證 |
+| READY | MERGED | 合併成功 | 建立提交、清除批次、歸檔 |
+| READY | FAILED | 合併失敗 | 記錄失敗，保留變更 |
+| FAILED | PENDING | 重置 | 重新排入變更，清除失敗狀態 |
+| MERGED | ARCHIVED | 提交後 | 記錄批次元資料以供稽核 |
+
+---
+
+## 門檻策略
+
+### 門檻類型
+
+| 策略 | 參數 | 預設值 | 說明 |
+|------|------|--------|------|
+| **計數** | `maxChanges` | 5 | 累積 N 個個別變更後合併 |
+| **分數** | `maxScore` | 10 | 累積變更分數 ≥ M 時合併 |
+| **時間** | `maxAge` | 30m | 最舊的待處理變更超過 TTL 時合併 |
+| **手動** | — | — | 僅在使用者明確要求時合併 |
+
+### 變更評分
+
+每項變更依複雜度指派分數：
+
+| 變更類型 | 分數 | 範例 |
+|----------|------|------|
+| 微小 | 1 | 錯字修正、空白、註解更新 |
+| 次要 | 2 | 單一函式變更、變數重新命名 |
+| 標準 | 3 | 新增函式、修改邏輯流程 |
+| 複雜 | 5 | 多檔案變更、API 修改 |
+| 關鍵 | 8 | Schema 變更、破壞性變更 |
+
+### 門檻配置
+
+```json
+{
+  "batching": {
+    "strategy": "count",
+    "maxChanges": 5,
+    "maxScore": 10,
+    "maxAge": "30m",
+    "fallbackStrategy": "time"
+  }
+}
+```
+
+### 複合門檻
+
+多個門檻可以 OR 邏輯組合（第一個達到的門檻觸發合併）：
+
+```
+Merge when: changes ≥ 5 OR score ≥ 10 OR age ≥ 30m
+```
+
+---
+
+## 合併規則
+
+### 優先順序
+
+1. **相同規格親和性**：參照相同 SPEC-ID 的變更優先合併
+2. **相同檔案分組**：對相同檔案的變更合併在一起
+3. **依賴順序**：有依賴關係的變更依依賴順序合併
+4. **時間順序**：在相同優先級內，依建立順序合併
+
+### 衝突解決
+
+| 衝突類型 | 解決策略 | 備用方案 |
+|----------|----------|----------|
+| 同一檔案同一行 | 最新變更優先 | 手動解決 |
+| 重疊函式 | 盡可能進行語義合併 | 手動解決 |
+| 依賴衝突 | 先解決依賴關係 | 拒絕批次，拆分 |
+
+### 合併前驗證
+
+合併批次前，需驗證：
+
+| 檢查項目 | 必要性 | 說明 |
+|----------|--------|------|
+| 所有測試通過 | 是 | 對合併後狀態執行測試套件 |
+| 無 lint 錯誤 | 是 | 對合併後的檔案執行 linter |
+| 無衝突 | 是 | 確認乾淨合併，無衝突 |
+| 維持 AC 覆蓋率 | 建議 | AC 覆蓋率不降低 |
+
+---
+
+## 原子性保證
+
+### 全有或全無原則
+
+批次合併必須是原子性的：
+
+- **成功**：批次中的所有變更一起提交
+- **失敗**：批次中的任何變更都不提交；所有變更回到 PENDING 狀態
+
+### 原子性規則
+
+| 規則 | 說明 |
+|------|------|
+| **單一提交** | 每個合併批次恰好產生一個提交 |
+| **不允許部分合併** | 如果批次中任一變更驗證失敗，整個批次被拒絕 |
+| **支援回溯** | 失敗的合併必須將所有變更還原至 PENDING 狀態 |
+| **隔離性** | 批次合併不得影響批次以外的變更 |
+
+---
+
+## 回溯機制
+
+### 失敗處理
+
+當批次合併失敗時：
+
+1. **記錄失敗**：記錄批次中包含哪些變更以及什麼失敗
+2. **保留變更**：所有變更回到 PENDING 狀態
+3. **診斷**：識別失敗的變更
+4. **選項**：
+   - 修正失敗的變更並重試
+   - 移除失敗的變更並合併其餘部分
+   - 將批次拆分為較小的群組
+
+### 回溯觸發條件
+
+| 觸發條件 | 動作 | 自動執行？ |
+|----------|------|-----------|
+| 測試失敗 | 拒絕整個批次 | 是 |
+| lint 錯誤 | 拒絕整個批次 | 是 |
+| 合併衝突 | 拒絕並通知 | 是 |
+| 建置失敗 | 拒絕整個批次 | 是 |
+| 手動拒絕 | 回到 PENDING | 否 |
+
+---
+
+## 批次提交訊息格式
+
+批次提交應使用結構化訊息格式：
+
+```
+<type>(<scope>): <summary of batch>
+
+Changes included:
+- <change 1 description>
+- <change 2 description>
+- <change 3 description>
+
+Spec: SPEC-XXX (if applicable)
+Batch: N changes, score M
+```
+
+### 範例
+
+```
+feat(auth): implement login validation and error handling
+
+Changes included:
+- Add email format validation
+- Add password strength check
+- Add error message display
+- Add rate limiting for failed attempts
+
+Spec: SPEC-001
+Batch: 4 changes, score 11
+```
+
+---
+
+## 反模式
+
+| 反模式 | 影響 | 正確做法 |
+|--------|------|----------|
+| 無限累積 | 龐大且難以審查的提交 | 設定合理門檻 |
+| 混合不相關的變更 | 難以審查，難以回溯 | 依規格或功能分組 |
+| 部分提交 | 損壞的中間狀態 | 強制原子性 |
+| 忽略失敗 | 損壞的程式碼進入程式庫 | 合併前始終進行驗證 |
+| 無回溯計畫 | 失敗時遺失變更 | 失敗時保留變更 |
+
+---
+
+## 最佳實踐
+
+### 應該做的
+
+- ✅ 為自動批次設定明確的門檻
+- ✅ 依規格或功能分組變更
+- ✅ 提交前驗證整個批次
+- ✅ 使用原子性提交（全有或全無）
+- ✅ 失敗時保留變更
+- ✅ 記錄批次決策以供稽核
+
+### 不應該做的
+
+- ❌ 無限期累積變更
+- ❌ 在一個批次中混合不相關的變更
+- ❌ 提交部分批次
+- ❌ 忽略驗證失敗
+- ❌ 合併失敗時遺失變更
+
+---
+
+## 相關標準
+
+- [簽入標準](checkin-standards.md) — 提交的品質閘門
+- [Pipeline 整合標準](pipeline-integration-standards.md) — Pipeline 自動化
+- [提交訊息指南](commit-message-guide.md) — 提交訊息格式
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.0.0 | 2026-03-18 | 初始版本 — 狀態機、門檻策略、原子性保證 |

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

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/checkin-standards.md
-source_version: 1.4.0
-translation_version: 1.4.0
-last_synced: 2026-01-16
+source_version: 1.5.0
+translation_version: 1.5.0
+last_synced: 2026-03-18
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/checkin-standards.md) | 繁體中文
 
-**版本**: 1.4.0
-**最後更新**: 2026-01-16
+**版本**: 1.5.0
+**最後更新**: 2026-03-18
 **適用範圍**: 所有使用版本控制的軟體專案
 
 ---
@@ -83,6 +83,11 @@ pip install -r requirements.txt && python -m py_compile src/**/*.py
   - Coverage percentage not decreased
   - Critical paths are tested
 
+- [ ] **AC 覆蓋率已驗證**（若使用規格驅動工作流程）
+  - 所有驗收條件（AC）都有對應的測試（參見 [驗收條件追蹤標準](acceptance-criteria-traceability.md)）
+  - AC 覆蓋率達到專案門檻（預設：簽入 80%）
+  - 先前已覆蓋的 AC 沒有退化為未覆蓋
+
 **專案特定測試指令**:
 ```bash
 # Example: .NET project
@@ -403,6 +408,7 @@ git status
 | 變更累積 | 檔案 ≥5 個 或 行數 ≥200 行 | 建議 |
 | 連續跳過 | 連續跳過簽入 3 次 | 警告 |
 | 工作完成 | 結束前有未 commit 變更 | 強烈建議 |
+| 批次閾值 | 暫存變更達到設定閾值 | 建議 |
 
 ### 提醒行為
 
@@ -435,6 +441,33 @@ git status
 └────────────────────────────────────────────────┘
 ```
 
+### 批次閾值觸發
+
+當使用自動化 Pipeline 搭配變更批次合併時（參見 [變更批次合併標準](change-batching-standards.md)）：
+
+- **計數閾值**：累積變更 ≥ 設定的 `maxChanges` 時觸發
+- **分數閾值**：累積變更分數 ≥ 設定的 `maxScore` 時觸發
+- **時間閾值**：最舊的暫存變更超過設定的 `maxAge` 時觸發
+- **行為**：批次閾值觸發簽入建議，而非自動提交（除非啟用 `autoCheckin`）
+
+### 自動簽入
+
+當 Pipeline 配置中啟用 `autoCheckin` 時（參見 [Pipeline 整合標準](pipeline-integration-standards.md)）：
+
+| 前提條件 | 必要 | 說明 |
+|---------|------|------|
+| 所有測試通過 | 是 | 完整測試套件通過，包含新測試 |
+| Lint 清潔 | 是 | 已變更檔案無 lint 錯誤 |
+| AC 覆蓋率達標 | 是 | AC 覆蓋率達到專案門檻 |
+| 無衝突 | 是 | 與目標分支可清潔合併 |
+| 批次已驗證 | 是（如啟用批次） | 批次中所有變更一起驗證 |
+
+**安全規則**：
+- 自動簽入不得推送到受保護的分支
+- 自動簽入必須建立正確的 commit message（不是「auto-commit」）
+- 自動簽入必須可稽核（記錄誰/什麼/何時）
+- 使用者永遠可以覆蓋為手動提交
+
 ### 跳過後的追蹤
 
 當用戶選擇「稍後再 commit」時：
@@ -958,6 +991,7 @@ git commit -m "feat(module-c): add export to CSV feature"
 
 | 版本 | 日期 | 變更 |
 |---------|------|---------|
+| 1.5.0 | 2026-03-18 | 新增：AC 覆蓋率驗證、批次閾值觸發、自動簽入規則 |
 | 1.4.0 | 2026-01-16 | 新增：Bug 修復測試評估章節與決策矩陣 |
 | 1.3.0 | 2026-01-05 | 新增：SWEBOK v4.0 第 6 章（軟體配置管理）至參考資料 |
 | 1.2.5 | 2025-12-16 | Clarified: CHANGELOG update is for user-facing changes only, added to [Unreleased] section |

package/bundled/locales/zh-TW/core/context-aware-loading.md

@@ -0,0 +1,86 @@
+---
+source: ../../../core/context-aware-loading.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+# 情境感知標準載入
+
+> **語言**: [English](../../../core/context-aware-loading.md) | 繁體中文
+
+**版本**: 1.0.0
+**最後更新**: 2026-03-16
+**適用性**: 所有使用 AI 最佳化標準（.ai.yaml）的專案
+**範圍**: 通用 (Universal)
+
+---
+
+## 目的
+
+本標準定義 AI 工具根據當前任務情境選擇性載入開發標準的協定。AI 工具不會一次載入所有標準，而是始終載入核心集合，並按需啟動額外標準，以減少 token 使用量並提升焦點。
+
+---
+
+## 快速參考
+
+| 概念 | 說明 |
+|------|------|
+| **領域 (Domain)** | 一組相關標準的命名群組（如 `testing`、`quality`） |
+| **常駐載入 (Always-On)** | 無論任務為何都會在每次工作階段載入的標準 |
+| **按需載入 (On-Demand)** | 僅在任務情境符合其領域觸發條件時載入的標準 |
+| **Manifest 領域** | 領域到標準對應的單一事實來源（`manifest.json`） |
+
+---
+
+## 1. 領域分類
+
+### 1.1 常駐標準
+
+這些標準是每次 AI 互動的基礎，必須始終載入：
+
+| 標準 | 原因 |
+|------|------|
+| `anti-hallucination` | 防止每個任務中的虛構 |
+| `commit-message` | 每次工作階段都可能產生提交 |
+| `checkin-standards` | 品質關卡適用於所有變更 |
+| `project-context-memory` | 專案決策必須始終被尊重 |
+
+### 1.2 按需載入標準
+
+這些標準在偵測到對應的任務情境時自動載入：
+
+| 領域 | 觸發條件 | 載入的標準 |
+|------|----------|-----------|
+| `testing` | 撰寫測試、修改測試 | testing、unit-testing、integration-testing |
+| `security` | 認證、授權、密鑰 | security-standards |
+| `deployment` | CI/CD、部署、發布 | deployment-standards、changelog |
+| `documentation` | 文件、README | documentation-writing-standards |
+
+## 2. 載入協定
+
+### 2.1 工作流程
+
+```
+1. 載入常駐標準
+2. 分析使用者任務上下文
+3. 比對任務關鍵字與領域觸發條件
+4. 按需載入匹配的標準
+5. 在工作階段中保持已載入的標準
+```
+
+### 2.2 觸發比對
+
+AI 工具應透過以下方式比對觸發條件：
+
+| 比對方式 | 說明 |
+|----------|------|
+| 檔案路徑 | 修改 `tests/` 下的檔案觸發 testing 領域 |
+| 使用者指令 | `/tdd`、`/bdd` 等觸發 testing 領域 |
+| 關鍵字 | 使用者訊息中的「測試」、「部署」等關鍵字 |
+
+## 相關標準
+
+- [專案情境記憶](project-context-memory.md)
+- [反幻覺標準](anti-hallucination.md)