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

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

@@ -0,0 +1,48 @@
+---
+source: ../../../core/behavior-driven-development.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+> **语言**: [English](../../../core/behavior-driven-development.md) | 简体中文
+
+# 行为驱动开发（BDD）标准
+
+**版本**: 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 Guide](../../../methodologies/guides/bdd-guide.md)**
+
+---
+
+## 快速参考
+
+| 方面 | 说明 |
+|------|------|
+| **核心工作流** | 发现 → 公式化 → 自动化 |
+| **语言** | Gherkin（Given-When-Then） |
+| **测试层级** | 功能/场景测试 |
+| **参与者** | 开发者 + BA + QA（Three Amigos） |
+| **工具** | Cucumber、Behave、SpecFlow |
+
+## 相关标准
+
+- [测试驱动开发](../../../core/test-driven-development.md)
+- [验收测试驱动开发](acceptance-test-driven-development.md)
+- [规格驱动开发](../../../core/spec-driven-development.md)
+- [测试标准](testing-standards.md)

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

@@ -0,0 +1,112 @@
+---
+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)
+
+---
+
+## 目的
+
+定义分支完成的标准化工作流，包含前置检查、四个完成选项与安全丢弃流程。防止过早合并、遗忘分支与意外数据丢失。
+
+---
+
+## 术语表
+
+| 术语 | 定义 |
+|------|------|
+| 分支完成 | 完成功能/修复分支上工作的过程 |
+| 前置条件 | 分支被视为完成前必须满足的条件 |
+| 丢弃确认 | 删除工作前需要明确输入的安全机制 |
+
+---
+
+## 核心原则 — 测试优先于讨论
+
+> **所有测试必须通过，才能考虑任何完成选项。**
+
+---
+
+## 前置条件
+
+分支完成前，以下所有检查必须通过：
+
+| 检查项 | 命令（示例） | 必需 |
+|--------|-------------|------|
+| 所有测试通过 | `pnpm test` | 是 |
+| Lint 通过 | `pnpm lint` | 是 |
+| 类型检查通过 | `pnpm tsc --noEmit` | 是 |
+| 无未提交变更 | `git status --porcelain` | 是 |
+
+如果任何前置条件失败，分支**尚未准备好完成**。先修复问题。
+
+---
+
+## 四个完成选项
+
+### 选项 1：本地合并
+
+在本地机器上将分支合并到目标分支。
+
+```bash
+git checkout main
+git merge feature/my-feature
+git branch -d feature/my-feature
+```
+
+### 选项 2：创建 Pull Request
+
+推送分支并创建 PR 进行代码审查。
+
+```bash
+git push -u origin feature/my-feature
+gh pr create --title "功能描述" --body "变更说明"
+```
+
+### 选项 3：Squash 合并
+
+将所有提交压缩为单一提交后合并。
+
+```bash
+git checkout main
+git merge --squash feature/my-feature
+git commit -m "feat: 功能描述"
+git branch -d feature/my-feature
+```
+
+### 选项 4：丢弃分支
+
+安全丢弃不再需要的分支。
+
+⚠️ **丢弃确认**：必须明确输入确认才能删除。
+
+```bash
+git branch -D feature/my-feature        # 本地删除
+git push origin --delete feature/my-feature  # 远程删除
+```
+
+---
+
+## 相关标准
+
+- [Git Worktree 隔离](git-worktree.md)
+- [代理派遣与并行协调](agent-dispatch.md)
+
+---
+
+## 许可证
+
+本标准采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 发布。

package/bundled/locales/zh-CN/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-23
+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-CN/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 覆盖率已验证**（如使用规格驱动工作流）
+  - 所有验收条件有对应测试（参见[验收条件追溯标准](acceptance-criteria-traceability.md)）
+  - AC 覆盖率达到专案阈值（预设：签入时 80%）
+  - 已覆盖的 AC 未退化为未覆盖
+
 **专案特定测试指令**:
 ```bash
 # Example: .NET project
@@ -403,6 +408,7 @@ git status
 | 变更累积 | 档案 ≥5 个 或 行数 ≥200 行 | 建议 |
 | 连续跳过 | 连续跳过签入 3 次 | 警告 |
 | 工作完成 | 结束前有未 commit 变更 | 强烈建议 |
+| 批次阈值 | 待处理变更达到配置阈值 | 建议 |
 
 ### 提醒行为
 
@@ -448,6 +454,33 @@ git status
    ```
 3. **工作结束前** → If uncommitted changes exist, strongly recommend check-in
 
+### 批次阈值触发
+
+当使用自动化 Pipeline 与变更批次处理时（参见[变更批次合并标准](change-batching-standards.md)）：
+
+- **计数阈值**：累积变更数量 ≥ 配置的 `maxChanges` 时触发
+- **分数阈值**：累计变更分数 ≥ 配置的 `maxScore` 时触发
+- **时间阈值**：最旧的待处理变更超过配置的 `maxAge` 时触发
+- **行为**：批次阈值触发签入建议，而非自动提交（除非启用 `autoCheckin`）
+
+### 自动签入
+
+当 Pipeline 配置中启用 `autoCheckin` 时（参见 [Pipeline 整合标准](pipeline-integration-standards.md)）：
+
+| 前提条件 | 必须 | 说明 |
+|---------|------|------|
+| 所有测试通过 | 是 | 完整测试套件通过，包括新测试 |
+| Lint 通过 | 是 | 变更档案无 lint 错误 |
+| AC 覆盖率达标 | 是 | AC 覆盖率达到专案阈值 |
+| 无冲突 | 是 | 与目标分支可干净合并 |
+| 批次已验证 | 是（如启用批次） | 批次中所有变更已一并验证 |
+
+**安全规则**：
+- 自动签入**不得**推送到受保护的分支
+- 自动签入**必须**创建正式的 commit 讯息（非「auto-commit」）
+- 自动签入**必须**可稽核（记录 who/what/when）
+- 用户可随时以手动 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 |
@@ -976,6 +1010,10 @@ git commit -m "feat(module-c): add export to CSV feature"
 - [测试标准](testing-standards.md)（或使用 `/testing-guide` 技能）
 - [Commit 讯息规范](commit-message-guide.md)
 - [程序码审查清单](code-review-checklist.md)
+- [部署标准](deployment-standards.md) - 品质关卡与部署就绪性
+- [验收条件追溯标准](acceptance-criteria-traceability.md) - AC 覆盖率验证
+- [变更批次合并标准](change-batching-standards.md) - 批次阈值触发
+- [Pipeline 整合标准](pipeline-integration-standards.md) - 自动签入
 
 ---
 

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

@@ -0,0 +1,106 @@
+---
+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 使用并提高聚焦度。
+
+---
+
+## 快速参考
+
+| 概念 | 描述 |
+|------|------|
+| **域** | 一组命名的相关标准（如 `testing`、`quality`） |
+| **始终加载** | 无论任务如何，每个会话都加载的标准 |
+| **按需加载** | 仅在任务情境匹配其域触发器时加载的标准 |
+| **清单域** | 域→标准映射的唯一真实来源（`manifest.json`） |
+
+---
+
+## 1. 域分类
+
+### 1.1 始终加载的标准
+
+这些标准对每次 AI 交互都是基础性的，必须始终加载：
+
+| 标准 | 原因 |
+|------|------|
+| `anti-hallucination` | 在每项任务中防止捏造 |
+| `commit-message` | 每个会话都可能产生提交 |
+| `checkin-standards` | 品质关卡适用于所有变更 |
+| `project-context-memory` | 项目决策必须始终被尊重 |
+| `developer-memory` | 过去的见解应始终可用 |
+
+### 1.2 按需加载域
+
+| 域 | 标准 | 激活触发器 |
+|----|------|-----------|
+| `testing` | testing, unit-testing, integration-testing, tdd, bdd, atdd | 撰写测试、测试文件编辑、"测试覆盖率"讨论 |
+| `specification` | spec-driven-development, forward-derivation, reverse-engineering | `/sdd`、`/spec` 命令、规格文件编辑 |
+| `quality` | code-review, refactoring, security, performance, accessibility | `/review` 命令、PR 审查、"重构"讨论 |
+| `documentation` | documentation-structure, documentation-writing, changelog | 撰写文档、README/CHANGELOG 编辑 |
+| `workflow` | git-workflow, github-flow, squash-merge, versioning, deployment | 分支操作、发布准备、合并 |
+| `architecture` | ai-friendly-architecture, project-structure, error-codes, logging | 架构决策、项目设置 |
+
+---
+
+## 2. 激活协议
+
+### 2.1 加载决策流程
+
+```
+用户请求到达
+    │
+    ▼
+始终加载标准已就绪？ ──否──► 加载始终加载标准
+    │
+    是
+    ▼
+分析任务关键字与文件路径
+    │
+    ▼
+匹配到按需域？ ──否──► 仅使用始终加载标准
+    │
+    是
+    ▼
+加载匹配域的标准
+```
+
+### 2.2 触发器匹配规则
+
+| 触发器类型 | 示例 | 匹配域 |
+|-----------|------|--------|
+| 命令名称 | `/tdd`、`/bdd` | `testing` |
+| 文件路径 | `tests/**`、`*.test.ts` | `testing` |
+| 关键字 | "重构"、"安全" | `quality` |
+| 工作流阶段 | "发布准备" | `workflow` |
+
+---
+
+## 相关标准
+
+- [项目情境记忆](project-context-memory.md)
+- [AI 指令标准](../../../core/ai-instruction-standards.md)
+
+---
+
+## 许可证
+
+本标准采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 发布。