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

package/bundled/locales/zh-CN/core/model-selection.md

@@ -0,0 +1,112 @@
+---
+source: ../../../core/model-selection.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+> **语言**: [English](../../../core/model-selection.md) | 简体中文
+
+# AI 模型选择策略
+
+**版本**: 1.0.0
+**最后更新**: 2026-03-20
+**适用范围**: 使用多层级模型的 AI 辅助开发
+**范围**: universal
+**灵感来源**: [Superpowers](https://github.com/obra/superpowers) — subagent-driven-development (MIT)
+
+---
+
+## 目的
+
+定义基于任务复杂度的 AI 模型分级选择策略。使用能胜任的最便宜模型，仅在必要时升级。
+
+---
+
+## 术语表
+
+| 术语 | 定义 |
+|------|------|
+| 模型层级 | 代表模型能力和成本的分类级别 |
+| 复杂度信号 | 表明所需能力的任务可观察特征 |
+| 升级 | 在低层级模型失败后升级到更高层级模型 |
+
+---
+
+## 核心原则 — 成本效率
+
+> **始终使用与任务复杂度匹配的最便宜模型层级。**
+
+---
+
+## 三层模型分类
+
+### 第 1 层：快速层（Fast）
+
+**用途**: 机械性实现 — 单一文件、明确规格、无需判断。
+
+**复杂度信号**:
+- 修改单一文件
+- 规格完全明确
+- 不需要设计判断
+- 重复性、基于模式的工作
+
+**示例**:
+- 更新 `package.json` 版本号
+- 添加新的 export 语句
+- 修复拼写错误
+- 在文件中重命名变量
+
+### 第 2 层：标准层（Standard）
+
+**用途**: 需要跨文件理解和适度判断的任务。
+
+**复杂度信号**:
+- 修改 2-5 个文件
+- 需要理解上下文
+- 需要适度的设计判断
+- 遵循已有模式
+
+**示例**:
+- 实现新的 API 端点
+- 添加带有测试的新功能
+- 重构模块
+
+### 第 3 层：推理层（Reasoning）
+
+**用途**: 需要深度分析、架构决策或创造性问题解决的任务。
+
+**复杂度信号**:
+- 修改 5 个以上文件
+- 需要架构决策
+- 涉及权衡取舍
+- 需要创新解决方案
+
+**示例**:
+- 设计新的系统架构
+- 调试复杂的竞态条件
+- 大规模重构
+
+---
+
+## 升级规则
+
+| 条件 | 动作 |
+|------|------|
+| 低层级模型产出错误结果 | 升级到更高层级 |
+| 任务比预期更复杂 | 重新评估复杂度信号 |
+| 连续 2 次失败 | 直接升级到推理层 |
+
+---
+
+## 相关标准
+
+- [代理派遣与并行协调](agent-dispatch.md)
+- [验证证据](verification-evidence.md)
+
+---
+
+## 许可证
+
+本标准采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 发布。

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

@@ -0,0 +1,104 @@
+---
+source: ../../../core/performance-standards.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+> **语言**: [English](../../../core/performance-standards.md) | 简体中文
+
+# 性能标准
+
+**版本**: 1.1.0
+**最后更新**: 2026-01-29
+**适用范围**: 所有软件项目
+**范围**: universal
+**行业标准**: ISO/IEC 25010 Performance Efficiency
+**参考**: [sre.google](https://sre.google/books/)
+
+> **详细说明和优化技术请参阅 [性能指南](../../../core/guides/performance-guide.md)**
+
+---
+
+## 目的
+
+本标准定义软件性能工程的综合指南，涵盖性能需求、测试方法和监控实践。
+
+**参考标准**:
+- [ISO/IEC 25010:2011](https://www.iso.org/standard/35733.html) - 性能效率
+- [Google SRE Book](https://sre.google/books/) - 站点可靠性工程
+
+---
+
+## 性能需求模板
+
+### NFR 格式
+
+```markdown
+### NFR-PERF-XXX: [标题]
+
+**类别**: 性能效率 > [时间行为/资源利用/容量]
+**优先级**: P1/P2/P3
+
+**需求**:
+| 百分位 | 目标 | 最大值 |
+|--------|------|--------|
+| p50 | Xms | Yms |
+| p95 | Xms | Yms |
+| p99 | Xms | Yms |
+
+**条件**: [负载、数据量等]
+**度量**: [工具、采样、报告]
+```
+
+---
+
+## 常见性能目标
+
+| 系统类型 | 响应时间（p95） | 吞吐量 | 可用性 |
+|---------|----------------|--------|--------|
+| **电商** | < 200ms | 1000+ rps | 99.9% |
+| **内部工具** | < 500ms | 100+ rps | 99.5% |
+| **批处理** | 不适用 | 10K+ 记录/分钟 | 99% |
+| **实时系统** | < 50ms (p99) | 10K+ rps | 99.99% |
+| **API 网关** | < 100ms | 5K+ rps | 99.95% |
+
+---
+
+## 性能测试类型
+
+| 测试类型 | 目的 | 工具 |
+|---------|------|------|
+| **负载测试** | 验证正常负载下的性能 | k6, JMeter, Gatling |
+| **压力测试** | 发现系统的断裂点 | k6, Locust |
+| **浸泡测试** | 检测内存泄漏和资源耗尽 | k6（长时间运行） |
+| **峰值测试** | 验证突发流量处理能力 | k6, JMeter |
+
+---
+
+## 性能监控
+
+### 关键指标
+
+| 指标 | 描述 | 告警阈值 |
+|------|------|---------|
+| 响应时间（p95） | 95% 请求的响应时间 | > 目标的 1.5× |
+| 错误率 | 失败请求的百分比 | > 1% |
+| 吞吐量 | 每秒请求数 | < 预期的 80% |
+| CPU 使用率 | 处理器利用率 | > 80% |
+| 内存使用率 | 内存利用率 | > 85% |
+
+---
+
+## 相关标准
+
+- [部署标准](deployment-standards.md)
+- [安全标准](security-standards.md)
+- [测试标准](testing-standards.md)
+
+---
+
+## 许可证
+
+本标准采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 发布。

package/bundled/locales/zh-CN/core/pipeline-integration-standards.md

@@ -0,0 +1,238 @@
+---
+source: ../../../core/pipeline-integration-standards.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-23
+status: current
+---
+
+# Pipeline 整合标准
+
+> **语言**: [English](../../../core/pipeline-integration-standards.md) | 简体中文
+
+**适用范围**: 所有使用自动化开发 Pipeline 的软件项目
+**Scope**: universal
+
+---
+
+## 概述
+
+Pipeline 整合标准定义自动化开发 Pipeline 应如何读取项目配置、执行开发阶段，以及根据项目情境调整行为。本标准为 AI 辅助及 CI/CD 驱动的开发工作流程提供一套与语言、框架无关的通用模型。
+
+## 参考资料
+
+| 标准／来源 | 内容 |
+|-----------|------|
+| ISO/IEC 12207 | 软件生命周期流程 |
+| ISO/IEC 15504 (SPICE) | 流程评估 |
+| Continuous Delivery（Jez Humble） | Pipeline 设计原则 |
+| DORA Metrics | 部署频率、前置时间、MTTR、变更失败率 |
+
+---
+
+## 配置契约
+
+### UDS 配置区块
+
+使用自动化 Pipeline 的项目必须在标准配置区块中声明其 Pipeline 偏好。配置区块通常放置于项目的 manifest 文件中（例如 `manifest.json`、`uds.config.json` 或等效文件）。
+
+### 标准开关名称
+
+| 开关 | 类型 | 默认值 | 描述 |
+|------|------|--------|------|
+| `autoSpecGeneration` | boolean | false | 自动从 PRD／用户故事产生 SDD 规格 |
+| `autoDerive` | boolean | false | 规格核准后自动衍生 BDD／TDD／ATDD |
+| `autoTDD` | boolean | false | 衍生完成后自动进入 TDD RED 阶段 |
+| `autoCheckin` | boolean | false | 所有品质关卡通过后自动提交 |
+| `autoBatch` | boolean | false | 自动批次累积待提交的变更 |
+
+### 开关语义
+
+每个开关控制特定的 Pipeline 行为：
+
+| 开关 | 开启时 | 关闭时 |
+|------|--------|--------|
+| `autoSpecGeneration` | Pipeline 从输入产生规格草稿并提交审查 | 需手动创建规格 |
+| `autoDerive` | 规格核准后 Pipeline 自动执行衍生（BDD／TDD／ATDD） | 通过命令手动衍生 |
+| `autoTDD` | 衍生完成后 Pipeline 设定 RED 状态并创建测试骨架 | 开发者手动进入 TDD |
+| `autoCheckin` | 所有关卡通过（测试、lint、覆盖率）后 Pipeline 自动提交 | 开发者手动提交 |
+| `autoBatch` | Pipeline 累积变更并在达到阈值时合并 | 每次变更个别提交 |
+
+### 配置范例
+
+```json
+{
+  "pipeline": {
+    "autoSpecGeneration": true,
+    "autoDerive": true,
+    "autoTDD": true,
+    "autoCheckin": false,
+    "autoBatch": false,
+    "context": "greenfield"
+  }
+}
+```
+
+### 配置读取规则
+
+1. **安全默认值**：所有开关默认为 OFF（手动模式）
+2. **明确声明**：Pipeline 必须在读取配置后才能确定开关状态，不得假设
+3. **运行时覆写**：CLI flag 或环境变量可覆写文件式配置
+4. **验证**：Pipeline 在执行前必须验证配置值
+
+---
+
+## Pipeline 阶段模型
+
+### 标准六阶段 Pipeline
+
+```
+┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
+│  1.PLAN  │───▶│  2.SPEC  │───▶│ 3.DERIVE │───▶│ 4.BUILD  │───▶│ 5.REVIEW │───▶│6.CHECKIN │
+│ 需求分析  │    │ 规格撰写  │    │ 测试衍生  │    │ 实现构建  │    │ 审查验证  │    │ 提交签入  │
+└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
+```
+
+### 阶段定义
+
+| 阶段 | 输入 | 输出 | 品质关卡 |
+|------|------|------|---------|
+| **Plan（规划）** | PRD、用户故事、需求 | 结构化需求文档 | 需求已审查 |
+| **Spec（规格）** | 需求 | 含验收条件的 SDD 规格 | 规格已核准 |
+| **Derive（衍生）** | 已核准的规格 | BDD 场景、TDD 骨架、ATDD 表格 | 1:1 验收条件对应已验证 |
+| **Build（构建）** | 测试骨架 ＋ 规格 | 实现代码 | 测试通过（RED→GREEN） |
+| **Review（审查）** | 实现 ＋ 测试 | 审查意见 | 审查已核准 |
+| **Checkin（签入）** | 已核准的变更 | 已提交的代码 | 所有品质关卡通过 |
+
+### 阶段依赖性
+
+- 每个阶段的输出为下一阶段的输入
+- 未经明确配置不得跳过任何阶段
+- 品质关卡失败必须阻挡进入下一阶段
+
+---
+
+## 开发情境分类
+
+### 情境类型
+
+| 情境 | 描述 | 典型场景 |
+|------|------|---------|
+| **Greenfield** | 全新项目或功能，无既有代码 | 新增模块、新服务、新产品 |
+| **Brownfield** | 需修改的既有代码库 | 为旧有代码新增功能、重构 |
+| **Adhoc** | 小型、独立的变更 | Bug 修复、配置变更、Hotfix |
+
+### 情境策略矩阵
+
+| 阶段 | Greenfield | Brownfield | Adhoc |
+|------|-----------|------------|-------|
+| **Plan** | 完整需求分析 | 优先进行影响分析 | 快速评估 |
+| **Spec** | 完整 SDD | Delta SDD（仅变更部分） | 可选（重大变更才需要） |
+| **Derive** | 完整衍生 | 针对性衍生 | 跳过（除非复杂） |
+| **Build** | 从零开始 TDD | 修改既有代码 ＋ 新测试 | 直接修复 |
+| **Review** | 完整审查 | 聚焦于变更的审查 | 快速审查 |
+| **Checkin** | 标准签入 | 标准签入 | 标准签入 |
+
+### 情境自动检测启发式规则
+
+Pipeline 应使用下列信号自动检测情境：
+
+| 信号 | Greenfield 指标 | Brownfield 指标 | Adhoc 指标 |
+|------|----------------|----------------|-----------|
+| 文件数量 | 无文件或极少文件 | 已建立的代码库 | 不适用 |
+| 变更范围 | 新目录／模块 | 修改既有文件 | 变更 1–3 个文件 |
+| 测试覆盖率 | 无既有测试 | 既有测试套件 | 既有测试已涵盖该区域 |
+| 规格是否存在 | 无规格 | 既有规格 | 可能有也可能没有 |
+
+### 情境覆写
+
+开发者可在配置中明确指定情境：
+
+```json
+{
+  "pipeline": {
+    "context": "brownfield"
+  }
+}
+```
+
+或通过 CLI flag 指定：
+```bash
+pipeline run --context=greenfield
+```
+
+---
+
+## 整合验证
+
+### Pipeline 实现者检查清单
+
+实现本标准的整合者必须验证以下项目：
+
+| 检查项目 | 要求 | 验证方式 |
+|---------|------|---------|
+| 配置读取 | Pipeline 从配置中读取所有开关 | 单元测试：模拟配置 → 验证行为 |
+| 默认值处理 | 未配置的开关默认为 OFF | 单元测试：空配置 → 手动模式 |
+| 阶段执行 | 6 个阶段依序执行 | 整合测试：完整 Pipeline 执行 |
+| 关卡强制执行 | 失败的关卡阻挡下一阶段 | 整合测试：注入失败 → 验证阻挡 |
+| 情境感知 | Pipeline 根据情境类型调整 | 整合测试：各情境 → 验证阶段 |
+| 覆写支持 | CLI flag 覆写文件配置 | 单元测试：文件 ＋ flag → flag 优先 |
+
+### 验证规则
+
+1. **配置 Schema 验证**：对照已知开关名称进行验证；对未知键值发出警告
+2. **开关类型安全**：所有开关必须为 boolean；拒绝非 boolean 值
+3. **情境枚举值**：情境必须为以下其中之一：`greenfield`、`brownfield`、`adhoc`
+4. **阶段完整性**：Pipeline 必须报告哪些阶段已执行、哪些已跳过
+
+---
+
+## 反模式
+
+| 反模式 | 影响 | 正确做法 |
+|--------|------|---------|
+| 硬编码 Pipeline 行为 | 无法适应项目需求 | 在运行时读取配置 |
+| 忽略情境类型 | 执行错误的阶段 | 检测或读取情境配置 |
+| 跳过品质关卡 | 有问题的代码进入代码库 | 在每个阶段强制执行关卡 |
+| 全有或全无的自动化 | 用户完全回避 Pipeline | 允许逐开关的细粒度控制 |
+| 静默跳过阶段 | 失去可追踪性 | 记录并报告所有跳过决策 |
+
+---
+
+## 最佳实践
+
+### 应做事项
+
+- ✅ 在执行任何阶段前先读取配置
+- ✅ 所有开关默认为 OFF（安全默认值）
+- ✅ 在 Pipeline 启动时记录哪些开关为启用状态
+- ✅ 报告阶段执行状态（已执行／已跳过／失败）
+- ✅ 允许逐阶段的细粒度开关控制
+- ✅ 在使用前验证配置 Schema
+- ✅ 支持通过 CLI 覆写配置
+
+### 不应做事项
+
+- ❌ 未读取配置即假设开关状态
+- ❌ 静默跳过阶段而不记录
+- ❌ 忽略品质关卡失败
+- ❌ 硬编码 Pipeline 行为
+- ❌ 混用情境策略（例如：Greenfield 规格 ＋ Adhoc 构建）
+
+---
+
+## 相关标准
+
+- [规格驱动开发（Spec-Driven Development）](spec-driven-development.md) — Spec 阶段工作流程
+- [正向衍生标准（Forward Derivation Standards）](forward-derivation-standards.md) — Derive 阶段实现
+- [签入标准（Check-in Standards）](checkin-standards.md) — Checkin 阶段品质关卡
+- [变更批次标准（Change Batching Standards）](change-batching-standards.md) — 签入前的批次合并
+- [验收条件追踪（Acceptance Criteria Traceability）](acceptance-criteria-traceability.md) — 跨阶段验收条件追踪
+
+---
+
+## 版本历程
+
+| 版本 | 日期 | 变更内容 |
+|------|------|---------|
+| 1.0.0 | 2026-03-18 | 初始版本 — 配置契约、六阶段 Pipeline 模型、情境分类 |

package/bundled/locales/zh-CN/core/project-context-memory.md

@@ -0,0 +1,124 @@
+---
+source: ../../../core/project-context-memory.md
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-24
+status: current
+---
+
+> **语言**: [English](../../../core/project-context-memory.md) | 简体中文
+
+# 项目情境记忆标准
+
+**版本**: 1.1.0
+**最后更新**: 2026-03-16
+**适用范围**: 所有使用 AI 助手的软件项目
+**范围**: uds-specific
+
+---
+
+## 目的
+
+本标准定义一个结构化系统，用于捕获、检索和执行**项目特定的**上下文、架构决策和领域知识。与开发者记忆（通用且可迁移的）不同，项目情境记忆充当特定代码库的"长期大脑"，确保 AI 助手遵守本地惯例和历史决策。
+
+---
+
+## 快速参考
+
+### 记忆条目模式
+
+| 字段 | 类型 | 描述 |
+|------|------|------|
+| `id` | string | 唯一标识符（`PRJ-YYYY-NNNN`） |
+| `type` | enum | `decision` / `convention` / `structure` / `glossary` |
+| `summary` | string | 上下文的单行摘要 |
+| `status` | enum | `active` / `proposed` / `deprecated` |
+| `scope` | list | 此规则适用的文件或目录 |
+
+### 存储位置
+
+条目存储为**带有 YAML Frontmatter 的 Markdown**，确保人类可读性（文档）和机器可解析性。
+
+- **目录**: `.project-context/`
+- **格式**: `.md` 文件
+
+---
+
+## 1. 记忆模式
+
+### 1.1 完整模式定义
+
+```markdown
+---
+id: "PRJ-2026-0001"              # 必需：唯一 ID
+type: decision                   # 必需：类别
+status: active                   # 必需：active | proposed | deprecated
+created_at: "2026-02-09"         # 必需：ISO 日期
+confidence: 1.0                  # 必需：0.0–1.0
+
+# 范围与触发器（情境感知）
+scope:                           # 此规则适用的位置
+  - "src/api/**"
+  - "src/services/**"
+triggers:                        # 唤醒此记忆的关键字/模式
+  - "错误处理"
+  - "API 响应"
+---
+
+# [摘要标题]
+
+## 决策
+[描述决策内容]
+
+## 原因
+[为什么做出这个决策]
+
+## 影响
+[这个决策影响什么]
+```
+
+---
+
+## 2. 记忆类型
+
+| 类型 | 描述 | 示例 |
+|------|------|------|
+| `decision` | 架构或技术决策 | "使用 PostgreSQL 而非 MongoDB" |
+| `convention` | 编码惯例或风格 | "所有 API 返回包含 `data` 和 `error` 字段" |
+| `structure` | 项目结构规则 | "测试文件与源文件在同一目录" |
+| `glossary` | 领域术语定义 | "用户 = 付费客户，访客 = 未注册用户" |
+
+---
+
+## 3. 记忆检索
+
+### 3.1 自动激活
+
+AI 助手在处理请求时，应自动检查：
+
+1. 当前编辑文件是否在某条记忆的 `scope` 范围内
+2. 用户请求中是否包含某条记忆的 `triggers` 关键字
+3. 任务类型是否与某条记忆的 `type` 匹配
+
+### 3.2 手动查询
+
+```bash
+# 查看所有活跃记忆
+ls .project-context/*.md
+
+# 搜索特定主题
+grep -l "API" .project-context/*.md
+```
+
+---
+
+## 相关标准
+
+- [情境感知加载](context-aware-loading.md)
+- [开发者记忆](../../../core/developer-memory.md)
+
+---
+
+## 许可证
+
+本标准采用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 发布。

package/bundled/locales/zh-CN/core/requirement-engineering.md

@@ -0,0 +1,49 @@
+---
+source: ../../../core/requirement-engineering.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+---
+
+> **语言**: [English](../../../core/requirement-engineering.md) | 简体中文
+
+# 需求工程标准
+
+**版本**: 1.0.0
+**最后更新**: 2026-01-28
+**适用范围**: 所有软件项目
+**范围**: universal
+**行业标准**: IEEE 830-1998, IEEE 29148-2018, SWEBOK v4.0
+**参考**: [computer.org](https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4)
+
+---
+
+## 摘要
+
+需求工程是在整个开发生命周期中系统性地获取、分析、规范和验证软件需求的过程。它基于行业标准（包括 IEEE 830-1998、IEEE 29148-2018、SWEBOK v4.0 和 ISO/IEC 25010）提供编写、管理和验证需求的理论基础。
+
+该过程涵盖功能需求（系统应该做什么）、非功能需求（性能、安全、可用性等品质属性）和约束。用户故事（敏捷格式）配合验收条件（Given-When-Then）作为主要规格格式，通过 INVEST 准则（Independent、Negotiable、Valuable、Estimable、Small、Testable）进行验证。
+
+---
+
+**完整指南: [需求工程指南](../../../methodologies/guides/requirement-engineering-guide.md)**
+
+---
+
+## 快速参考
+
+| 方面 | 说明 |
+|------|------|
+| **核心过程** | 获取 → 分析 → 规范 → 验证 |
+| **需求类型** | 功能需求（FR）、非功能需求（NFR）、约束 |
+| **优先级排序** | MoSCoW、P0-P3、Kano 模型 |
+| **品质模型** | ISO/IEC 25010（8 个特征） |
+| **标准** | IEEE 830、IEEE 29148、SWEBOK v4.0 |
+
+## 相关标准
+
+- [规格驱动开发](../../../core/spec-driven-development.md)
+- [正向推导标准](../../../core/forward-derivation-standards.md)
+- [行为驱动开发](behavior-driven-development.md)
+- [测试标准](testing-standards.md)