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

package/bundled/locales/zh-CN/integrations/openspec/AGENTS.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../../integrations/openspec/AGENTS.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-01-13
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-23
 status: current
 ---
 
@@ -100,11 +100,25 @@ openspec list                  # 列出活跃变更
 openspec list --specs          # 列出规格
 openspec show [item]           # 显示变更或规格
 openspec validate [item]       # 验证变更或规格
-openspec archive <change-id> [--yes|-y]   # 部署后归档（添加 --yes 用于非交互执行）
+openspec archive <change-id> [--yes|-y]   # 部署后归档
+
+# 浏览与状态
+openspec view                  # 交互式仪表板
+openspec status                # 显示产物完成进度
+openspec instructions          # 获取创建产物的增强指引
+openspec templates             # 显示已解析的模板路径
+
+# Schema 管理
+openspec schemas               # 列出可用的工作流程 schema
+openspec schema init           # 初始化新 schema
+openspec schema fork           # 分叉现有 schema
+openspec schema validate       # 验证 schema
+openspec schema which          # 显示使用中的 schema
 
 # 项目管理
 openspec init [path]           # 初始化 OpenSpec
 openspec update [path]         # 更新指令文件
+openspec config                # 管理设置
 
 # 交互模式
 openspec show                  # 提示选择
@@ -113,6 +127,10 @@ openspec validate              # 批量验证模式
 # 调试
 openspec show [change] --json --deltas-only
 openspec validate [change] --strict
+
+# 工具
+openspec completion            # Shell 集成支持
+openspec feedback              # 通过 GitHub 提交反馈
 ```
 
 ### 指令标志
@@ -123,6 +141,13 @@ openspec validate [change] --strict
 - `--no-interactive` - 禁用提示
 - `--skip-specs` - 归档时不更新规格
 - `--yes`/`-y` - 跳过确认提示（非交互归档）
+- `--no-validate` - 归档时不执行验证
+- `--sort` - 列表输出排序
+- `--profile` - 指定初始化配置文件
+- `--requirements` / `--no-scenarios` / `-r` - 过滤 show 输出
+- `--all` / `--changes` / `--specs` - 过滤验证范围
+- `--concurrency` - 并行验证并发数
+- `--schema` - 指定 status/instructions/templates 的 schema
 
 ## 目录结构
 

package/bundled/locales/zh-CN/integrations/spec-kit/AGENTS.md

@@ -1,116 +1,183 @@
 ---
 source: ../../../../integrations/spec-kit/AGENTS.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-01-13
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-03-23
 status: current
 ---
 
 # Spec Kit 指令
 
-使用 Spec Kit 进行规格驱动开发的 AI 编码助手指令。
+> **语言**: [English](../../../../integrations/spec-kit/AGENTS.md) | 简体中文
+
+**版本**: 1.1.0
+**最后更新**: 2026-03-23
+
+为使用 Spec Kit 进行规格驱动开发的 AI 编程助手提供指引。
 
 ## 使用方式
 
-将此文件复制到您的项目，或包含在 AI 助手的系统指令中。
+将此文件复制到您的项目中，或纳入您的 AI 助手系统指令。
 
 ---
 
 ## 使用 Spec Kit 进行规格驱动开发
 
-当此项目启用 Spec Kit 时，您必须遵循**规格驱动开发（SDD）**方法论。
+当 Spec Kit 在此项目中启用时，您必须遵循**规格驱动开发 (SDD)** 方法论。
 
-### 核心原则：规格优先，代码其次
+### 核心原则：先规格，后代码
 
-**规则**：没有对应的已核准规格，不得进行任何功能性代码变更。
+**规则**：在没有对应已批准规格的情况下，不得进行任何功能性代码变更。
 
-**例外情况**：
-- 紧急修复（立即恢复服务，事后记录）
-- 琐碎变更（错字、注释、格式）
+**例外**：
+- 紧急修复（立即恢复服务，事后补文档）
+- 微小变更（错别字、注释、格式调整）
 
 ---
 
 ## Spec Kit 指令
 
-当 Spec Kit 可用时，优先使用这些指令：
+### CLI 指令
 
 | 指令 | 说明 |
 |------|------|
-| `/spec create <title>` | 创建新规格 |
-| `/spec list` | 列出所有活跃规格 |
-| `/spec show <id>` | 显示规格详情 |
-| `/spec approve <id>` | 标记规格为已核准 |
-| `/spec close <id>` | 关闭已完成规格 |
-| `/spec archive <id>` | 归档规格 |
+| `specify init <project-name>` | 初始化新的 SDD 项目 |
+| `specify check` | 验证已安装的工具（git、AI agents） |
 
-### 指令优先顺序
+**Init 选项：**
+
+| 标志 | 说明 |
+|------|------|
+| `--ai <agent>` | 选择 AI 助手（claude、gemini、copilot、cursor-agent、windsurf 等） |
+| `--ai-skills` | 以 agent skills 而非斜杠命令安装 |
+| `--here` | 在当前目录中初始化 |
+| `--force` | 合并时跳过确认 |
+| `--script ps` | PowerShell 脚本（Windows/跨平台） |
+| `--no-git` | 跳过 git 仓库初始化 |
+| `--debug` | 启用详细输出 |
+| `--branch-numbering timestamp` | 使用时间戳式分支命名 |
 
-**规则**：始终优先使用 Spec Kit 指令，而非手动编辑文件。
+### 斜杠命令（工作流程）
+
+当 Spec Kit 可用时，使用以下斜杠命令进行 SDD 工作流程：
+
+| 命令 | 阶段 | 说明 |
+|------|------|------|
+| `/constitution` | 设定 | 建立项目治理原则 |
+| `/specify` | 提案 | 定义需求与用户故事 |
+| `/clarify` | 讨论 | 通过结构化问题解决规格歧义 |
+| `/plan` | 设计 | 创建技术实现计划 |
+| `/tasks` | 规划 | 生成可执行的任务分解 |
+| `/analyze` | 审查 | 检查跨产物的一致性 |
+| `/implement` | 实现 | 执行任务以构建功能 |
+
+### 命令优先级
+
+**规则**：始终优先使用 Spec Kit 命令，而非手动编辑文件。
 
 **理由**：
 - **一致性**：确保规格结构遵循 schema
-- **可追溯性**：自动生成 ID 和链接
-- **验证**：内建检查防止无效状态
+- **可追溯性**：自动生成 ID 与建立链接
+- **验证**：内置检查防止无效状态
 
 ---
 
 ## SDD 工作流程
 
 ```
-┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│     讨论     │───▶│     提案     │───▶│     审查     │───▶│     实现     │
-└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
-                                                                   │
-                                                                   ▼
-                                        ┌──────────────┐    ┌──────────────┐
-                                        │     归档     │◀───│     验证     │
-                                        └──────────────┘    └──────────────┘
+┌──────────────┐    ┌──────────────┐    ┌──────────────┐
+│ Constitution │───▶│   Specify    │───▶│   Clarify    │
+└──────────────┘    └──────────────┘    └──────────────┘
+                                               │
+                    ┌──────────────┐    ┌───────▼──────┐
+                    │  Implement   │◀───│  Plan/Tasks  │
+                    └──────────────┘    └──────────────┘
+                           │
+                    ┌──────▼───────┐
+                    │   Analyze    │
+                    └──────────────┘
 ```
 
 ### 工作流程阶段
 
-| 阶段 | 说明 | 操作 |
+| 阶段 | 说明 | 命令 |
 |------|------|------|
-| **讨论** | 厘清需求与探索方案 | 讨论记录 |
-| **提案** | 定义变更内容和原因 | `/spec create` |
-| **审查** | 利益相关者核准 | `/spec approve` |
-| **实现** | 执行已核准规格 | 代码变更 |
-| **验证** | 确认实现符合规格 | 测试 |
-| **归档** | 关闭并归档规格 | `/spec close` |
+| **Constitution** | 定义项目治理原则 | `/constitution` |
+| **Specify** | 定义需求与用户故事 | `/specify` |
+| **Clarify** | 通过结构化问题解决歧义 | `/clarify` |
+| **Plan** | 创建技术实现计划 | `/plan` |
+| **Tasks** | 生成可执行的任务分解 | `/tasks` |
+| **Implement** | 执行任务以构建功能 | `/implement` |
+| **Analyze** | 检查跨产物的一致性 | `/analyze` |
 
 ---
 
-## 任何任务之前
+## 工作流程强制闸门
+
+**重要**：在执行任何工作流程阶段之前，你**必须**检查先决条件。
+
+### 阶段闸门
+
+| 阶段 | 先决条件 | 失败时 |
+|------|----------|--------|
+| Specify | Constitution 已建立（首次时） | → 先执行 `/constitution` |
+| Plan | 需求已通过 `/specify` 定义 | → 先执行 `/specify` |
+| Implement | 计划已批准、任务已生成 | → 先执行 `/plan` 再执行 `/tasks` |
+| Commit (feat/fix) | 检查活跃的规格 | → 建议加上 `Refs: SPEC-XXX` |
+
+### 会话启动协议
+在会话开始时，检查是否有活跃的工作流程：查找 `.specify/` 目录或活跃的规格文件。
+若发现活跃的工作流程 → 告知用户并提供继续的选项。
+
+参考：`.standards/workflow-enforcement.ai.yaml`
+
+---
+
+## 执行任何任务之前
 
 **上下文检查清单**：
-- [ ] 检查活跃规格：`/spec list`
-- [ ] 变更前审查相关规格
-- [ ] 确认无冲突规格
-- [ ] 非琐碎变更需创建规格
+- [ ] 检查活跃的规格：查找 `.specify/` 目录
+- [ ] 在进行变更前审查相关规格
+- [ ] 确认没有冲突的规格存在
+- [ ] 若变更非微小则创建规格
 
 **可跳过规格的情况**：
-- 错误修复（恢复预期行为）
-- 错字、格式、注释
-- 依赖更新（非破坏性）
-- 配置变更
+- Bug 修复（恢复预期行为）
+- 错别字、格式、注释
+- 依赖项更新（非破坏性）
+- 配置文件变更
+
+---
+
+## 目录结构
+
+```
+.specify/
+├── templates/                    # 核心 spec-kit 模板
+├── extensions/
+│   └── <ext-id>/templates/      # 扩展模板
+├── presets/
+│   └── <preset-id>/templates/   # 预设自定义
+└── templates/overrides/          # 项目本地覆盖（最高优先）
+```
 
 ---
 
 ## 规格文档模板
 
-手动创建规格时，使用此结构：
+手动创建规格时，请使用以下结构：
 
 ```markdown
 # [SPEC-ID] 功能标题
 
 ## 摘要
-简述提议变更。
+简要描述提议的变更。
 
 ## 动机
-为何需要此变更？解决什么问题？
+为何需要此变更？它解决什么问题？
 
 ## 详细设计
-技术方案、受影响组件、数据流程。
+技术方案、受影响的组件、数据流。
 
 ## 验收标准
 - [ ] 标准 1
@@ -120,55 +187,58 @@ status: current
 列出对其他规格或外部系统的依赖。
 
 ## 风险
-潜在风险和缓解策略。
+潜在风险与缓解策略。
 ```
 
 ---
 
-## 与通用文档规范的集成
+## 与 Universal Dev Standards 集成
 
-### Commit 消息
+### 提交消息
 
-在 commit 消息中引用规格 ID：
+在提交消息中引用规格 ID：
 
 ```
-feat(auth): 实现登录功能
+feat(auth): implement login feature
 
-实现 SPEC-001 登录功能，支持 OAuth2。
+Implements SPEC-001 login functionality with OAuth2 support.
 
 Refs: SPEC-001
 ```
 
 ### 代码审查
 
-审查者应确认：
-- [ ] 变更符合已核准规格
-- [ ] 无超出规格的范围蔓延
+审查者应验证：
+- [ ] 变更符合已批准的规格
+- [ ] 未超出规格范围
 - [ ] 规格验收标准已达成
 
 ---
 
 ## 最佳实践
 
-### 应该做的
-- 保持规格聚焦且原子化（每个规格一项变更）
-- 包含清晰的验收标准
+### 应做
+
+- 保持规格聚焦且原子化（每个规格一个变更）
+- 包含明确的验收标准
 - 将规格链接到实现 PR
+- 使用 `/analyze` 验证一致性
 - 完成后归档规格
 
-### 不应该做的
-- 规格核准前开始编码
-- 实现期间修改范围而不更新规格
-- 让规格处于悬而未决状态（始终关闭或归档）
-- 跳过验证步骤
+### 不应做
+
+- 在规格批准前开始写代码
+- 在实现期间修改范围却未更新规格
+- 让规格处于未决状态（应始终关闭或归档）
+- 在需求模糊时跳过 `/clarify` 步骤
 
 ---
 
-## 相关规范
+## 相关标准
 
 - [规格驱动开发](../../../../core/spec-driven-development.md) - SDD 方法论
-- [Commit 消息指南](../../../../core/commit-message-guide.md) - Commit 惯例
-- [代码签入规范](../../../../core/checkin-standards.md) - 签入要求
+- [提交消息指南](../../../../core/commit-message-guide.md) - 提交惯例
+- [代码签入标准](../../../../core/checkin-standards.md) - 签入要求
 
 ---
 
@@ -176,10 +246,11 @@ Refs: SPEC-001
 
 | 版本 | 日期 | 变更 |
 |------|------|------|
+| 1.1.0 | 2026-03-23 | 更新以反映 Spec Kit v0.4.0 实际的 CLI 命令与斜杠命令 |
 | 1.0.0 | 2025-12-30 | 初始 Spec Kit 集成 |
 
 ---
 
-## 许可证
+## 许可协议
 
-本文档以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 许可发布。
+本文档依 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 许可发布。

package/bundled/locales/zh-CN/skills/ac-coverage-assistant/SKILL.md

@@ -0,0 +1,126 @@
+---
+source: ../../../../skills/ac-coverage-assistant/SKILL.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-24
+status: current
+description: |
+  分析验收条件（AC）与测试之间的追踪关系，产生覆盖率报告。
+  使用时机：验证 AC 覆盖率、检查测试追踪性、发布前审查。
+  关键字：AC, acceptance-criteria, coverage, traceability, 验收条件, 覆盖率。
+---
+
+# AC 覆盖率助手
+
+> **语言**: [English](../../../../skills/ac-coverage-assistant/SKILL.md) | 简体中文
+
+分析验收条件（AC）与测试之间的追踪关系，并产生覆盖率报告。
+
+## 与 `/coverage` 的区别
+
+| 方面 | `/coverage` | `/ac-coverage` |
+|------|-------------|----------------|
+| **范围** | 代码级别（行/分支/函数） | 需求级别（AC 到测试） |
+| **输入** | 源代码 + 测试运行器 | SPEC 文件 + 测试标注 |
+| **问题** | "多少代码被测试了？" | "哪些 AC 有测试？" |
+| **输出** | 覆盖率百分比 | 追踪矩阵 + 差距报告 |
+
+## 工作流程
+
+1. **解析 SPEC** — 从规格文件中提取 AC 定义（AC-1、AC-2……）
+2. **扫描测试** — 使用标准链接惯例搜索测试文件中的 `@AC` 和 `@SPEC` 标注
+3. **构建矩阵** — 将每个 AC 映射到其测试引用（文件、测试名称、行号）
+4. **分类状态** — 将每个 AC 标记为 ✅ 已覆盖、⚠️ 部分覆盖 或 ❌ 未覆盖
+5. **计算覆盖率** — 套用公式：`覆盖率 % = (已覆盖 + 部分覆盖 × 0.5) / 总计 × 100`
+6. **产生报告** — 输出标准化 Markdown 报告
+
+## 标注惯例
+
+测试必须使用标准标注引用其来源 AC：
+
+```typescript
+// TypeScript/JavaScript
+describe('AC-1: 使用有效凭证登录', () => {
+  // @AC AC-1
+  // @SPEC SPEC-001
+  it('should redirect to dashboard on successful login', () => { ... });
+});
+```
+
+```python
+# Python
+class TestAC1_UserLogin:
+    """AC-1: 使用有效凭证登录
+    @AC AC-1
+    @SPEC SPEC-001
+    """
+    def test_redirect_to_dashboard(self): ...
+```
+
+```gherkin
+# BDD Feature
+@SPEC-001 @AC-1
+Scenario: 使用有效凭证登录
+```
+
+## 覆盖率门槛
+
+| 门槛 | 默认值 | 执行时机 |
+|------|--------|---------|
+| **提交** | 80% | 功能分支合并时必须达标 |
+| **发布** | 100% | 生产环境发布时必须达标 |
+| **警告** | 60% | 触发覆盖率警告 |
+
+门槛可通过 `--threshold` 参数或项目配置自定义。
+
+## 报告格式
+
+产生的报告遵循 `core/acceptance-criteria-traceability.md` 的标准格式：
+
+```markdown
+# AC 覆盖率报告
+
+**规格**: SPEC-001 — 功能名称
+**产生日期**: 2026-03-18
+**覆盖率**: 75% (6/8 AC)
+
+## 摘要
+
+| 状态 | 数量 | 百分比 |
+|------|------|--------|
+| ✅ 已覆盖 | 5 | 62.5% |
+| ⚠️ 部分覆盖 | 2 | 25.0% |
+| ❌ 未覆盖 | 1 | 12.5% |
+
+## 追踪矩阵
+
+| AC-ID | 描述 | 状态 | 测试引用 |
+|-------|------|------|---------|
+| AC-1 | 使用有效凭证登录 | ✅ | auth.test.ts:15 |
+| AC-2 | 拒绝无效凭证 | ✅ | auth.test.ts:32 |
+| ...   | ...              | ... | ... |
+
+## 差距
+
+- **AC-8**: 社交登录 — 被 OAuth 沙箱阻塞
+
+## 行动项目
+
+1. [ ] AC-8: 建立 OAuth 沙箱（预计完成时间：待定）
+```
+
+## 下一步引导
+
+`/ac-coverage` 完成后，AI 助手应建议：
+
+> **AC 覆盖率分析完成。建议下一步：**
+> - 覆盖率达标 → 执行 `/checkin` 品质关卡
+> - 有未覆盖 AC → 执行 `/derive-tdd` 补齐测试
+> - 有部分覆盖 AC → 检查缺少的边界情况
+
+## 参考
+
+- 核心规范：[acceptance-criteria-traceability.md](../../../../core/acceptance-criteria-traceability.md)
+- SPEC：[SPEC-AC-COVERAGE.md](../../../../docs/specs/skills/SPEC-AC-COVERAGE.md)
+- 相关：[test-coverage-assistant](../test-coverage-assistant/SKILL.md)（代码级别覆盖率）
+- 相关：[checkin-assistant](../checkin-assistant/SKILL.md)（品质关卡）

package/bundled/locales/zh-CN/skills/api-design-assistant/SKILL.md

@@ -0,0 +1,100 @@
+---
+source: ../../../../skills/api-design-assistant/SKILL.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-03-23
+status: current
+description: |
+  引导 API 设计，遵循 REST、GraphQL 和 gRPC 最佳实践。
+  使用时机：设计 API、审查端点、API 版本决策。
+  关键字：API, REST, GraphQL, gRPC, endpoint, versioning, 接口设计。
+---
+
+# API 设计助手
+
+> **语言**: [English](../../../../skills/api-design-assistant/SKILL.md) | 简体中文
+
+引导 API 设计，遵循 REST、GraphQL 和 gRPC 最佳实践。
+
+## 快速参考 — REST 惯例
+
+### HTTP 方法
+
+| 方法 | 用途 | 幂等性 |
+|------|------|--------|
+| GET | 读取资源 | 是 |
+| POST | 创建资源 | 否 |
+| PUT | 替换资源 | 是 |
+| PATCH | 部分更新 | 否 |
+| DELETE | 删除资源 | 是 |
+
+### 状态码
+
+| 代码 | 说明 |
+|------|------|
+| 200 | 成功 |
+| 201 | 已创建 |
+| 204 | 无内容（删除成功） |
+| 400 | 请求格式错误 |
+| 401 | 未认证 |
+| 403 | 无权限 |
+| 404 | 资源不存在 |
+| 409 | 资源冲突 |
+| 422 | 验证失败 |
+| 429 | 请求过多（限流） |
+| 500 | 服务器内部错误 |
+
+### URL 命名规则
+
+| 模式 | 示例 | 说明 |
+|------|------|------|
+| 集合 | `/users` | 资源集合 |
+| 单一资源 | `/users/{id}` | 单一资源 |
+| 子资源 | `/users/{id}/orders` | 子资源 |
+| 动作 | `/users/{id}/activate` | 动作（仅限 POST） |
+
+## 设计工作流程
+
+```
+DEFINE ──► DESIGN ──► VALIDATE ──► DOCUMENT
+```
+
+### 1. Define — 定义需求
+厘清使用者、使用场景、数据模型和非功能性需求。
+
+### 2. Design — 设计端点
+套用 RESTful 惯例、定义请求/响应 Schema、规划版本策略。
+
+### 3. Validate — 验证一致性
+检查命名一致性、错误格式统一、分页模式。
+
+### 4. Document — 生成文档
+产出 OpenAPI/Swagger 规格或 GraphQL Schema 文档。
+
+## 版本策略
+
+| 策略 | 示例 | 优点 |
+|------|------|------|
+| URL 路径 | `/v1/users` | 简单、明确 |
+| Header | `Accept: application/vnd.api+json;v=1` | URL 干净 |
+| Query | `/users?version=1` | 容易测试 |
+
+## 使用方式
+
+- `/api-design` - 交互式 API 设计引导
+- `/api-design /users` - 审查特定端点设计
+- `/api-design --graphql` - GraphQL Schema 设计引导
+
+## 下一步引导
+
+`/api-design` 完成后，AI 助手应建议：
+
+> **API 设计完成。建议下一步：**
+> - 执行 `/sdd` 建立正式规格文档
+> - 执行 `/testing` 规划 API 测试策略
+> - 执行 `/docs` 生成 API 文档
+> - 审查安全性 → 执行 `/security`
+
+## 参考
+
+- 核心规范：[api-design-standards.md](../../../../core/api-design-standards.md)