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

package/bundled/locales/zh-CN/skills/spec-driven-dev/guide.md

@@ -1,41 +1,49 @@
 ---
 description: |
-  引導規格驅动开发 (SDD) 工作流程，在实作前規划变更。
-  使用时机：建立規格、提案、規划功能、使用 OpenSpec 或类似工具。
-  关鍵字：spec, specification, SDD, proposal, openspec, design doc, 規格, 提案, 设计文件。
-source: ../../../../skills/spec-driven-dev/SKILL.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-01-25
+  引导规格驱动开发 (SDD) 工作流程，在实现前规划变更。
+  使用时机：建立规格、提案、规划功能、使用 OpenSpec 或类似工具。
+  关键字：spec, specification, SDD, proposal, openspec, spec-kit, design doc, 规格, 提案, 设计文件。
+source: ../../../../skills/spec-driven-dev/guide.md
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-03-23
 status: current
 ---
 
-# 規格驅动开发指南
+# 规格驱动开发指南
 
-> **语言**: [English](../../../../skills/spec-driven-dev/SKILL.md) | 简体中文
+> **语言**: [English](../../../../skills/spec-driven-dev/guide.md) | 简体中文
 
-**版本**: 1.0.0
-**最後更新**: 2025-12-30
-**適用範圍**: Claude Code Skills
+**版本**: 1.2.0
+**最后更新**: 2026-03-23
+**适用范围**: Claude Code Skills
 
 ---
 
 ## 目的
 
-此技能引導您完成規格驅动开发 (SDD)，确保变更在实作前經過規划、记录和批准。
+本技能引导您完成规格驱动开发 (SDD)，确保变更在实现前经过规划、文档化和核准。
 
-## 快速參考
+## 会话启动协议
+
+每次会话开始时：
+
+1. **检查进行中的规格**：搜索 `docs/specs/`、`specs/`、`openspec/changes/` 或 `.specify/` 中的进行中工作
+2. **若发现进行中的规格** → 通知用户并提供继续的选项
+3. 在开始新工作前**检阅上下文**
+
+## 快速参考
 
 ### SDD 工作流程
 
 ```
 ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│     讨论     │───▶│     提案     │───▶│     审查     │───▶│     实作     │
+│   Discuss    │───▶│   Proposal   │───▶│    Review    │───▶│Implementation│
 └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
                                                                    │
                                                                    ▼
                                         ┌──────────────┐    ┌──────────────┐
-                                        │     封存     │◀───│     验证     │
+                                        │   Archive    │◀───│ Verification │
                                         └──────────────┘    └──────────────┘
 ```
 
@@ -43,188 +51,323 @@ status: current
 
 | 阶段 | 说明 | 产出 |
 |------|------|------|
-| **讨论** | 厘清需求与探索方案 | 讨论记录 |
-| **提案** | 定義变更内容与原因 | `proposal.md` |
-| **审查** | 利害关系人批准 | 批准记录 |
-| **实作** | 执行已批准的規格 | 程序码、测试、文件 |
-| **验证** | 确认实作符合規格 | 测试結果 |
-| **封存** | 关閉并封存 | 封存的規格及連結 |
+| **Discuss** | 捕捉模糊地带、锁定范围、建立必读清单 | 范围定义、规范参考 |
+| **Proposal** | 定义要变更什么以及为什么 | `proposal.md` |
+| **Review** | 利害关系人核准 | 核准记录 |
+| **Implementation** | 执行已核准的规格 | 代码、测试、文档 |
+| **Verification** | 确认实现符合规格（最多 3 次迭代） | 测试结果、追溯矩阵 |
+| **Archive** | 关闭并归档 | 带链接的已归档规格 |
+
+### 工作流程强制闸门
 
-### 核心原則
+**重要**：执行任何工作流程阶段前，必须检查先决条件。
 
-| 原則 | 说明 |
+| 阶段 | 先决条件 | 失败时 |
+|------|---------|--------|
+| Proposal | Discuss 完成、范围锁定 | → 先完成 Discuss 阶段 |
+| Implementation | 规格状态 = Approved | → 先取得核准 |
+| Verification | 所有 AC 都有代码 + 测试 | → 完成实现 |
+| Commit (feat/fix) | 检查进行中的规格 | → 建议规格参考 (Refs: SPEC-XXX) |
+| Archive | 所有任务完成、已验证 | → 完成剩余任务 |
+
+### 核心原则
+
+| 原则 | 说明 |
 |------|------|
-| **規格優先** | 没有批准的規格就不能进行功能变更 |
-| **工具優先** | 有 SDD 工具时優先使用工具指令 |
-| **方法論 > 工具** | SDD 可搭配任何工具或手动流程运作 |
+| **先评估** | 建立规格前评估范围和同步需求 |
+| **规格优先** | 没有已核准的规格不进行功能性变更 |
+| **工具优先** | 有 SDD 工具时优先使用其命令 |
+| **方法论 > 工具** | SDD 可搭配任何工具或手动流程 |
+| **双向同步** | 变更传播到所有相关产物 |
+| **简单优先** | 选择最简单的可行方案 |
+
+### 规格前评估
+
+建立规格前，回答以下问题：
+
+| 问题 | 选项 | 结果 |
+|------|------|------|
+| **范围？** | 项目特定 / 通用 | 决定是否需要核心规范 |
+| **交互式？** | 是 / 否 | 决定是否需要技能 |
+| **用户触发？** | 是 / 否 | 决定是否需要命令 |
+
+### 建立规格前
+
+- 总是先检查项目中是否已存在类似的规格
+- 建立新规格前先搜索现有规格目录
+- 优先修改现有规格而非建立重复的
+- 若需求不明确，先提出 1-2 个厘清问题
+
+### 「规格优先」的例外
+
+- 紧急修复（立即恢复服务，之后补文档）
+- 琐碎变更（错字、注释、格式）
+- 依赖套件更新（不破坏兼容性）
+- 配置变更
+
+## 详细阶段指引
+
+### Discuss 阶段
+
+Discuss 阶段确保在编写规格前解决所有歧义。
+
+#### 1. 建立治理原则
+
+预先定义项目惯例、约束和不可妥协的事项：
+
+- 项目的核心架构决策是什么？
+- 不可妥协的约束是什么（性能、安全、兼容性）？
+- 记录在 `project.md`、`CONTRIBUTING.md` 或等效文件中
+
+#### 2. 结构化厘清
+
+列出所有模糊点作为明确问题，逐一解决后再继续：
+
+```markdown
+## 厘清记录
+
+| # | 问题 | 选项 | 决定 | 理由 |
+|---|------|------|------|------|
+| 1 | 认证方式？ | OAuth2 / JWT / Session | OAuth2 | 业界标准，支持 SSO |
+| 2 | Token 存储？ | Cookie / LocalStorage | HttpOnly Cookie | XSS 防护 |
+```
 
-### 「規格優先」的例外情况
+#### 3. 锁定范围
 
-- 緊急修復（先恢復服务，之後再補文件）
-- 瑣碎变更（錯字、註解、格式調整）
+- 定义什么在范围内、什么在范围外
+- 识别可能受影响的相关规格
+- 建立必读的文件/规格清单
 
-## 提案範本
+### Implementation 阶段
+
+实现时遵循结构化方法：
+
+1. **仔细阅读提案/规格** — 理解所有需求和 AC
+2. **建立任务清单** — 分解为循序任务（在 `tasks.md` 或规格内）
+3. **依序实现任务** — 按顺序完成每个任务
+4. **完成后更新清单** — 标记任务为已完成
+5. **不要跳到下一阶段** — 直到所有任务完成
+
+### 需求用语
+
+在规格中使用精确语言：
+
+| 关键字 | 含义 | 用法 |
+|--------|------|------|
+| **SHALL/MUST** | 强制需求 | 「系统 SHALL 验证输入」 |
+| **SHOULD** | 建议做法 | 「API SHOULD 在 200ms 内响应」 |
+| **MAY** | 可选功能 | 「UI MAY 显示加载动画」 |
+
+避免模糊用语：「should try」、「might need」、「could possibly」
+
+## 简单优先
+
+### 默认原则
+
+- 每次变更默认少于 100 行新代码
+- 单一文件实现直到证明不足
+- 没有明确理由不引入框架
+- 选择无聊但经过验证的模式
+
+### 复杂度触发条件
+
+只有在具体证据下才增加复杂度：
+
+| 触发条件 | 需要的证据 |
+|---------|-----------|
+| 性能优化 | 分析数据显示瓶颈 |
+| 抽象层 | 3+ 个具体使用案例需要 |
+| 外部依赖 | 相较内建方案的明确理由 |
+| 多服务拆分 | 规模需求（>1000 用户、>100MB 数据） |
+
+## 命名规范
+
+### 规格 ID
+
+- 格式：`SPEC-NNN`（例如 `SPEC-001`、`SPEC-042`）
+- 在项目内循序编号
+
+### 变更 ID
+
+- 格式：kebab-case，动词开头
+- 前缀：`add-`、`update-`、`remove-`、`refactor-`
+- 范例：`add-two-factor-auth`、`update-payment-flow`、`remove-legacy-api`
+
+### 功能名称
+
+- 格式：动词-名词（例如 `user-auth`、`payment-capture`）
+- 每个功能单一目的
+- 10 分钟可理解性规则：若需要更久才能理解，就拆分
+- 描述需要「而且」时就拆分
+
+## 提案模板
 
 ```markdown
-# [SPEC-ID] 功能標題
+# [SPEC-ID] 功能标题
 
 ## 摘要
-簡要描述提案的变更。
+简短描述提案变更。
 
 ## 动机
-为什麼需要这个变更？解决什麼問題？
+为什么需要这个变更？解决什么问题？
 
 ## 详细设计
-技術方案、受影響的元件、数据流程。
+技术方法、受影响的组件、数据流。
 
-## 驗收标准
-- [ ] 标准 1
-- [ ] 标准 2
+## 验收条件
+- [ ] 条件 1
+- [ ] 条件 2
 
-## 相依性
-列出对其他規格或外部系统的相依性。
+## 依赖性
+列出对其他规格或外部系统的依赖。
 
-## 風險
-潛在風險及緩解策略。
+## 风险
+潜在风险和缓解策略。
 ```
 
 ## 详细指南
 
-完整标准請參考：
-- [規格驅动开发标准](../../../../core/spec-driven-development.md)
+完整标准请参阅：
+- [规格驱动开发标准](../../../../core/spec-driven-development.md)
 
-### AI 優化格式（节省 Token）
+### AI 优化格式（Token 效率）
 
-AI 助手可使用 YAML 格式文件以減少 Token 使用量：
-- 基礎标准：`ai/standards/spec-driven-development.ai.yaml`
+AI 助手可使用 YAML 格式文件以减少 token 用量：
+- 基本标准：`ai/standards/spec-driven-development.ai.yaml`
 
-## 与其他标准的集成
+## 与其他标准的整合
 
-### 与提交消息集成
+### 与 Commit 讯息
 
-在提交消息中引用規格 ID：
+在 commit 讯息中参照规格 ID：
 
 ```
-feat(auth): implement login feature
+feat(auth): 实现登录功能
 
-Implements SPEC-001 login functionality with OAuth2 support.
+实现 SPEC-001 使用 OAuth2 支持的登录功能。
 
 Refs: SPEC-001
 ```
 
-### 与 Check-in 标准集成
+### 与提交规范
 
-为規格提交程序码前：
+为规格提交代码前：
 
-- [ ] 規格已批准
-- [ ] 实作符合規格
-- [ ] 测试涵蓋驗收标准
-- [ ] PR 中引用規格 ID
+- [ ] 规格已核准
+- [ ] 实现符合规格
+- [ ] 测试涵盖验收条件
+- [ ] PR 中参照规格 ID
 
-### 与程序码审查集成
+### 与代码审查
 
 审查者应验证：
 
-- [ ] 变更符合已批准的規格
-- [ ] 没有超出規格的範圍擴張
-- [ ] 規格驗收标准已达成
+- [ ] 变更符合已核准的规格
+- [ ] 没有超出规格的范围蔓延
+- [ ] 规格的验收条件已满足
 
-## 範例
+## 常见 SDD 工具
 
-### ✅ 良好做法
+| 工具 | 说明 | 主要命令 |
+|------|------|---------|
+| **OpenSpec** | 规格管理 CLI | `openspec list`、`openspec show`、`openspec validate`、`openspec archive` |
+| **Spec Kit** | 斜线命令驱动的 SDD | `specify init`、`/specify`、`/clarify`、`/plan`、`/tasks`、`/implement` |
+| **手动** | 无工具，基于文件 | 手动建立 `specs/SPEC-XXX.md` |
 
-```markdown
-# SPEC-001 新增 OAuth2 登入
-
-## 摘要
-新增 Google OAuth2 登入，讓使用者可以用 Google 帳号登入。
+> **注意**：当项目中检测到 SDD 工具时，优先使用其原生命令而非手动编辑文件，以确保一致性和可追溯性。
 
-## 动机
-- 減少新使用者註冊的摩擦
-- 不储存密码以提升安全性
+## 同步验证
 
-## 驗收标准
-- [ ] 使用者可以点擊「使用 Google 登入」按鈕
-- [ ] 新使用者自动註冊
-- [ ] 現有使用者可連結 Google 帳号
-```
+完成规格后，验证同步：
 
-### ❌ 不良做法
+### 同步清单
 
 ```markdown
-# 新增登入
+## 同步状态
+
+### 范围：[通用|项目|工具]
 
-新增登入功能。
+- [ ] 核心规范：[已建立|已更新|不适用]
+- [ ] 技能：[已建立|已更新|不适用]
+- [ ] 命令：[已建立|已更新|不适用]
+- [ ] 翻译：[已同步|待处理|不适用]
 ```
-- 缺少規格 ID
-- 没有动机说明
-- 没有驗收标准
 
-## 常見 SDD 工具
+### 同步矩阵
 
-| 工具 | 说明 | 指令範例 |
-|------|------|----------|
-| **OpenSpec** | 規格管理 | `/openspec proposal`, `/openspec approve` |
-| **Spec Kit** | 輕量規格追蹤 | `/sdd create`, `/sdd close` |
-| **手动** | 無工具，文件式 | 手动建立 `specs/SPEC-XXX.md` |
+| 变更来源 | 同步至 |
+|---------|--------|
+| 核心规范 | → 技能、命令、翻译 |
+| 技能 | → 核心规范、命令、翻译 |
+| 命令 | → 技能、翻译 |
 
-## 最佳实踐
+## 最佳实践
 
-### 建议做法
+### 应该做的
 
-- ✅ 保持規格專注且原子化（一个規格一个变更）
-- ✅ 包含清晰的驗收标准
-- ✅ 將規格連結到实作 PR
-- ✅ 完成後封存規格
+- 建立规格前评估范围
+- 建立新规格前检查是否已存在
+- 保持规格聚焦且原子化（一个规格一个变更）
+- 包含使用 Given/When/Then 的明确验收条件
+- 使用 SHALL/MUST 表达强制需求
+- 将规格链接到实现 PR
+- 完成后归档规格
+- 关闭前验证同步状态
 
-### 避免做法
+### 不应该做的
 
-- ❌ 在規格批准前開始写程序
-- ❌ 实作期间修改範圍但不更新規格
-- ❌ 讓規格处於懸置状态（务必关閉或封存）
-- ❌ 跳過验证步骤
+- 规格核准前就开始写代码
+- 跳过范围评估或 Discuss 阶段
+- 实现期间修改范围而不更新规格
+- 让规格处于悬而未决状态（一定要关闭或归档）
+- 跳过验证步骤
+- 忘记同步相关产物
+- 没有具体证据就增加复杂度
 
 ---
 
-## 设置偵测
+## 配置检测
 
-此技能支援项目特定设置。
+本技能支持项目特定的配置。
 
-### 偵测順序
+### 检测顺序
 
-1. 检查工作區是否有 SDD 工具（OpenSpec、Spec Kit 等）
-2. 检查 `CONTRIBUTING.md` 中的規格工作流程文件
-3. 若無找到，**预设使用手动文件式工作流程**
+1. 检查工作区中的 SDD 工具：
+   - `openspec/` 目录 → 检测到 OpenSpec
+   - `.specify/` 目录 → 检测到 Spec Kit
+   - `specs/` 或 `docs/specs/` → 手动基于文件的工作流程
+2. 检查 `CONTRIBUTING.md` 中的规格工作流程文档
+3. 若未找到，**默认使用手动基于文件的工作流程**
 
 ### 首次设置
 
-若未找到设置：
+若未找到配置：
 
-1. 詢問使用者：「此项目尚未设置 SDD。您要设置 specs 目录嗎？」
-2. 建议在 `CONTRIBUTING.md` 中记录：
+1. 询问用户：「此项目尚未配置 SDD。是否要设置规格目录？」
+2. 建议记录在 `CONTRIBUTING.md`：
 
 ```markdown
-## 規格驅动开发
+## 规格驱动开发
 
-我們对所有非瑣碎的变更使用規格驅动开发。
+我们对所有非琐碎的变更使用规格驱动开发。
 
 ### 流程
 1. 在 `specs/` 目录建立提案
-2. 取得团队負責人批准
-3. 实作并在 PR 中引用規格
-4. 合併後封存規格
+2. 取得团队负责人核准
+3. 实现并在 PR 中参照规格
+4. 合并后归档规格
 
-### 規格範本
-請參考 `specs/TEMPLATE.md`
+### 规格模板
+请参阅 `specs/TEMPLATE.md`
 ```
 
 ---
 
 ## 相关标准
 
-- [規格驅动开发标准](../../../../core/spec-driven-development.md)
-- [提交消息指南](../../../../core/commit-message-guide.md)
-- [程序码审查检查清单](../../../../core/code-review-checklist.md)
+- [规格驱动开发标准](../../../../core/spec-driven-development.md)
+- [Commit 讯息指南](../../../../core/commit-message-guide.md)
+- [代码审查清单](../../../../core/code-review-checklist.md)
 
 ---
 
@@ -232,12 +375,14 @@ Refs: SPEC-001
 
 | 版本 | 日期 | 变更 |
 |------|------|------|
-| 1.0.0 | 2025-12-30 | 初始發布 |
+| 1.2.0 | 2026-03-23 | 新增：会话启动协议、工作流程强制闸门、Discuss 阶段（治理原则 + 厘清）、简单优先、命名规范、Implementation 阶段强化、需求用语、搜索指引、更新常见 SDD 工具 |
+| 1.1.0 | 2026-01-26 | 新增：规格前评估、同步验证、同步矩阵、强化最佳实践 |
+| 1.0.0 | 2025-12-30 | 初始版本 |
 
 ---
 
 ## 授权
 
-此技能採用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权。
+本技能以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授权释出。
 
-**來源**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)
+**来源**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)

package/bundled/locales/zh-TW/CLAUDE.md

@@ -14,7 +14,7 @@ status: current
 
 Universal Development Standards 是一個語言無關、框架無關的文件化標準框架。它提供：
 
-- **核心規範** (`core/`)：36 個基礎開發標準
+- **核心規範** (`core/`)：49 個基礎開發標準
 - **AI 技能** (`skills/`)：用於 AI 輔助開發的 Claude Code 技能
 - **CLI 工具** (`cli/`)：用於採用標準的 Node.js CLI
 - **整合** (`integrations/`)：各種 AI 工具的配置
@@ -200,7 +200,7 @@ node cli\bin\uds.js init --help
 
 ```
 universal-dev-standards/
-├── core/                  # 核心規範（36 個檔案）
+├── core/                  # 核心規範（49 個檔案）
 ├── skills/                # AI 工具技能
 │   └── claude-code/       # Claude Code 技能（26 個技能）
 ├── cli/                   # Node.js CLI 工具

package/bundled/locales/zh-TW/README.md

@@ -6,7 +6,7 @@
 
 > **語言**: [English](../../README.md) | 繁體中文 | [简体中文](../zh-CN/README.md)
 
-**版本**: 5.0.0-rc.6 (Pre-release) | **發布日期**: 2026-03-17 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 5.0.0 | **發布日期**: 2026-03-24 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
 
 語言無關、框架無關的軟體專案文件標準。透過 AI 原生工作流，確保不同技術堆疊之間的一致性、品質和可維護性。
 
@@ -55,9 +55,9 @@ npx universal-dev-standards init
 <!-- UDS_STATS_TABLE_START -->
 | 類別 | 數量 | 說明 |
 |----------|-------|-------------|
-| **核心標準** | 36 | 通用開發準則 |
-| **AI Skills** | 29 | 互動式技能 |
-| **斜線命令** | 30 | 快速操作 |
+| **核心標準** | 49 | 通用開發準則 |
+| **AI Skills** | 40 | 互動式技能 |
+| **斜線命令** | 45 | 快速操作 |
 | **CLI 指令** | 6 | list, init, configure, check, update, skills |
 <!-- UDS_STATS_TABLE_END -->
 

package/bundled/locales/zh-TW/SECURITY.md

@@ -0,0 +1,92 @@
+# 安全政策
+
+## 支援的版本
+
+<!-- UDS_SUPPORTED_VERSIONS_START -->
+| 版本 | 支援狀態 |
+|------|--------|
+| 5.0.0 | ✅ 最新正式版 |
+| < 5.0.0 | ❌ 已終止支援 |
+<!-- UDS_SUPPORTED_VERSIONS_END -->
+
+> **說明**：僅最新正式版與當前預發布分支會收到安全更新。
+
+---
+
+## 回報漏洞
+
+### 如何回報
+
+**請勿**以公開 GitHub issue 回報安全漏洞。
+
+請透過以下管道回報：
+
+1. **GitHub Security Advisories**（推薦）
+   - 前往 [Security Advisories](https://github.com/AsiaOstrich/universal-dev-standards/security/advisories/new)
+   - 這能確保回報是私密且可追蹤的
+
+2. **GitHub 私密漏洞回報**
+   - 前往 [回報漏洞](https://github.com/AsiaOstrich/universal-dev-standards/security)
+   - 依照引導流程回報
+
+### 回報內容
+
+請包含以下資訊：
+
+- **描述**：清楚說明漏洞內容
+- **重現步驟**：詳細的重現步驟
+- **影響範圍**：攻擊者可達成的影響
+- **受影響版本**：哪些版本受影響
+- **建議修復方式**：如果您有建議（選填）
+
+### 回應時間
+
+| 動作 | 時間 |
+|------|------|
+| 確認收到 | 48 小時內 |
+| 初步評估 | 7 天內 |
+| 修復發布（嚴重） | 14 天內 |
+| 修復發布（非嚴重） | 下次排程發布 |
+
+---
+
+## 安全範疇
+
+### 在範疇內
+
+| 元件 | 說明 |
+|------|------|
+| CLI 工具 (`cli/`) | 指令注入、路徑穿越、依賴漏洞 |
+| 標準內容 (`core/`) | 可能導致不安全實作的指引 |
+| GitHub Actions (`.github/workflows/`) | 工作流程注入、機密洩漏 |
+
+### 不在範疇內
+
+- 第三方依賴的漏洞（請回報給上游維護者）
+- 採用 UDS 標準的使用者專案中的問題
+- 社交工程攻擊
+
+---
+
+## 揭露政策
+
+我們遵循**協調揭露**原則：
+
+1. 回報者私下提交漏洞
+2. 我們確認並評估
+3. 我們開發並測試修復
+4. 我們發布修復
+5. 我們公開揭露漏洞（附上回報者致謝）
+
+除非回報者希望匿名，否則我們會在發布說明中致謝。
+
+---
+
+## 使用者安全建議
+
+在您的專案中使用 UDS 時：
+
+- 保持 UDS CLI 為最新版本
+- 採用前審閱標準（特別是 `security-standards.md`）
+- 定期對專案執行 `npm audit`
+- 遵循 `core/security-standards.md` 定義的安全標準