universal-dev-standards 5.17.0 → 6.1.0

package/bundled/locales/zh-CN/docs/USER-MANUAL.md

@@ -63,7 +63,7 @@ Universal Development Standards 是一套为 AI 时代设计的**语言无关、
 | 问题 | UDS 解决方案 |
 |------|-------------|
 | 团队 commit message 格式不一致 | 通过 `/commit` 标准化 Conventional Commits |
-| Code review 漏看关键问题 | 通过 `/review` 执行 8 维度系统性审查 |
+| Code review 漏看关键问题 | 通过 `/code-review` 执行 8 维度系统性审查 |
 | AI 工具给出不一致的建议 | 统一标准让 AI 工具读取并遵循 |
 | 新人加入团队需要数周上手 | 清晰的标准和引导式工作流程 |
 | 测试覆盖率期望不明确 | 测试金字塔定义明确比例（70/20/7/3） |
@@ -71,10 +71,10 @@ Universal Development Standards 是一套为 AI 时代设计的**语言无关、
 
 ### 设计哲学
 
-**"碰一点，保护一点"** — 你不需要一次导入全部 48 个标准。UDS 专为渐进式导入设计：
+**"碰一点，保护一点"** — 你不需要一次导入全部 140+ 个标准。UDS 专为渐进式导入设计：
 
 - 先只用 `/commit` — 零成本，立即见效
-- 接着加入 `/review` — 在合并前捕捉问题
+- 接着加入 `/code-review` — 在合并前捕捉问题
 - 团队适应后，逐步引入 `/tdd` 和 `/sdd`
 
 > **Boy Scout Rule**：让代码比你找到它时更好。每次碰到代码，顺手加一点保护（测试、文档）。
@@ -142,7 +142,7 @@ npx universal-dev-standards init
 
 ```
 your-project/
-├── .standards/           # 48 个 AI 标准（.ai.yaml 文件）
+├── .standards/           # AI 标准（.ai.yaml 文件）
 │   ├── testing.ai.yaml
 │   ├── commit-message.ai.yaml
 │   ├── code-review.ai.yaml
@@ -458,14 +458,14 @@ Refs: SPEC-001
 | `test` | 测试 | `test(auth): 新增登录测试` |
 | `chore` | 维护 | `chore(deps): 更新依赖包` |
 
-### `/review` — 代码审查
+### `/code-review` — 代码审查
 
-提交前，用 `/review` 进行系统性审查：
+提交前，用 `/code-review` 进行系统性审查：
 
 ```bash
-/review                    # 审查当前分支所有变更
-/review src/auth.js        # 审查特定文件
-/review feature/login      # 审查特定分支
+/code-review                    # 审查当前分支所有变更
+/code-review src/auth.js        # 审查特定文件
+/code-review feature/login      # 审查特定分支
 ```
 
 **8 个审查维度：**
@@ -504,7 +504,7 @@ Refs: SPEC-001
 | **规格** | `/sdd`, `/requirement`, `/brainstorm` | 规格驱动开发 |
 | **推演** | `/derive-all`, `/derive-bdd`, `/derive-tdd`, `/derive-atdd` | 从规格生成测试 |
 | **开发** | `/tdd`, `/bdd`, `/atdd` | 方法论工作流程 |
-| **质量** | `/commit`, `/review`, `/checkin`, `/coverage`, `/ac-coverage` | 日常质量管理 |
+| **质量** | `/commit`, `/code-review`, `/checkin`, `/coverage`, `/ac-coverage` | 日常质量管理 |
 | **文档** | `/docs`, `/docgen`, `/changelog`, `/release` | 文档与发布 |
 | **反向** | `/reverse`, `/reverse-sdd`, `/reverse-bdd`, `/reverse-tdd` | Legacy Code 反向工程 |
 | **重构** | `/refactor` | 重构指导 |
@@ -522,7 +522,7 @@ Refs: SPEC-001
 
 ```bash
 /commit     # 标准化 commit message
-/review     # 提交前自我审查
+/code-review     # 提交前自我审查
 ```
 
 > 只需要这两个指令，就能立即提升代码质量。
@@ -569,7 +569,7 @@ Refs: SPEC-001
 12:00  /commit                # 标准化提交
        → feat(auth): 新增双因素认证
 
-12:05  /review                # 最终审查
+12:05  /code-review                # 最终审查
        → 0 BLOCKING, 1 SUGGESTION
 ```
 
@@ -599,7 +599,7 @@ A: 不会。UDS 是语言无关、框架无关的。它定义的是流程和质
 A: 不用。核心标准是 Markdown 文件，人类直接阅读也完全适用。AI 工具只是让流程更顺畅。
 
 **Q: 团队中只有我用可以吗？**
-A: 可以。渐进式导入的设计就是为了这个场景。先自己用 `/commit` 和 `/review`，等团队看到效果再推广。
+A: 可以。渐进式导入的设计就是为了这个场景。先自己用 `/commit` 和 `/code-review`，等团队看到效果再推广。
 
 **Q: 和 ESLint / Prettier 冲突吗？**
 A: 互补关系。ESLint/Prettier 处理代码格式，UDS 处理更高层次的开发流程和质量标准。
@@ -624,7 +624,7 @@ uds init
 
 ### 推荐学习路径
 
-1. 先用 `/commit` + `/review` 养成习惯
+1. 先用 `/commit` + `/code-review` 养成习惯
 2. 遇到新功能时试试 `/sdd`
 3. 不确定下一步时，输入 `/dev-workflow`
 

package/bundled/locales/zh-CN/docs/specs/system/memory-adoption-strategy.md

@@ -0,0 +1,105 @@
+---
+source: docs/specs/system/memory-adoption-strategy.md
+source_version: 1.0.0
+translation_version: 1.0.0
+status: current
+---
+
+# 记忆采用策略
+
+**状态**: Archived
+
+> **语言**: [English](../../../../../docs/specs/system/memory-adoption-strategy.md) | 简体中文
+
+本文档提供策略指引，帮助跨不同团队规模与运营模式采用 Universal Development Standards (UDS) 的记忆系统。它帮助用户决定如何构建自身的 **Project Context Memory (PCM)** 与 **Developer Persistent Memory (DPM)**，以发挥最大效益。
+
+---
+
+## 1. 决策矩阵
+
+选择最适合你运营模式的策略：
+
+| 策略 | 目标对象 | 存储位置 | 知识流向 | 主要效益 |
+| :--- | :--- | :--- | :--- | :--- |
+| **数字花园 (Digital Garden)** | 独立开发者、自由职业者 | 本机全局 (`~/.uds/memory`) | Project → User | **可携性**：你的经验随你而行。 |
+| **仓库中心 (Repo-Centric)** | 初创公司、小型团队 | 项目本地 (`.project-context/`) | User → Project | **一致性**：为新成员提供"开箱即用"的上手体验。 |
+| **轴辐式 (Hub-and-Spoke)** | 企业、多项目组织 | Git Submodule／Registry | Hub ↔ Spoke | **标准化**：在严格边界内强制落实合规。 |
+
+---
+
+## 2. 策略 A：数字花园 (独立／自由职业者)
+
+**理念**："我是知识的载体。"
+
+目标是在许多临时项目之间积累个人经验。AI 扮演你的个人结对编程伙伴，学习 *你的* 偏好。
+
+### 配置
+- **全局 memory**：启用。将特定技术栈的洞见（例如"React Tips"、"Python Tricks"）存储于 `~/.uds/memory/`。
+- **项目 memory**：最小化。仅存储凭证、特定路径或临时性的业务逻辑。
+
+### 工作流程
+1.  **遇到问题**：在项目 A 中解决一个棘手的 React 渲染错误。
+2.  **提升 (Promote)**：告诉 AI："将这个存成通用的 React 模式到我的全局 memory。"
+3.  **重复使用**：打开项目 B。当你编写类似代码时，AI 会立即建议该模式，因为它读取了 `~/.uds/memory`。
+
+### 设置
+```bash
+# 1. Create global directory
+mkdir -p ~/.uds/memory
+
+# 2. (Optional) Initialize as git repo for backup
+cd ~/.uds/memory && git init
+```
+
+---
+
+## 3. 策略 B：仓库中心 (小型团队)
+
+**理念**："仓库即真实来源 (Source of Truth)。"
+
+目标是确保每位团队成员（以及他们的 AI Agent）拥有完全相同的上下文。个人偏好不应凌驾于项目惯例之上。
+
+### 配置
+- **全局 memory**：**停用** 或只读。避免"在我的机器／AI 上可以运行"的问题。
+- **项目 memory**：完整。所有架构决策、代码风格与领域术语均存放于 `.project-context/`，并提交至 Git。
+
+### 工作流程
+1.  **上手 (Onboarding)**：新成员 clone 仓库。
+2.  **即时上下文**：他们的 AI 读取 `.project-context/`，立即得知："我们采用 Hexagonal Architecture"与"变量必须使用 snake_case"。
+3.  **共识**：当团队在 Code Review 中对新规则达成共识时，由一人指示 AI："将这条规则加入 Project Context。"
+4.  **同步**：新的 `.md` 文件被提交并推送。每个人在下次 `git pull` 时获取更新。
+
+---
+
+## 4. 策略 C：轴辐式 (企业)
+
+**理念**："治理与合规。"
+
+目标是在数百个项目之间共享共通标准，同时允许本地的灵活性。
+
+### 配置
+- **核心层（轴 The Hub）**：一个专用的 Git 仓库（例如 `acme-corp/standard-memory`），内含全公司的安全规则与架构模式。
+- **项目层（辐 The Spoke）**：本地 `.project-context/`，用于应用程序专属的逻辑。
+
+### 实现：Git Submodules
+每个项目将中央 memory 作为 submodule 挂载。
+
+```bash
+# In Project A, B, and C:
+git submodule add git@github.com:acme-corp/standard-memory.git .standards/shared
+```
+
+### 工作流程
+1.  **政策更新**：安全团队在 Hub 仓库中更新"Auth Standards"。
+2.  **传播 (Propagation)**：各项目更新其 submodule，以拉取新标准。
+3.  **验证**：CI/CD 管线检查项目代码是否符合 `.standards/shared` 中更新后的规则。
+
+---
+
+## 5. 总结
+
+| 如果你想要… | 采用策略… |
+| :--- | :--- |
+| 在不同接单工作之间停止重复造轮子 | **数字花园 (Digital Garden)** |
+| 让新进人员在第一天就能产出 | **仓库中心 (Repo-Centric)** |
+| 确保 50+ 个微服务遵循安全规格 | **轴辐式 (Hub-and-Spoke)** |

package/bundled/locales/zh-CN/docs/user/FAQ.md

@@ -0,0 +1,132 @@
+---
+source: docs/user/FAQ.md
+source_version: 1.0.0
+translation_version: 1.0.0
+status: current
+---
+
+# UDS 常见问题
+
+> **语言**: [English](../../../../docs/user/FAQ.md) | 简体中文
+
+---
+
+## 安装与设置
+
+**Q：`uds init` 和 `uds update` 有什么区别？**
+
+`uds init` 用于首次设置：它会复制标准、配置你的 AI 工具，并安装 skill。
+`uds update` 则是把已初始化的项目升级到最新的 UDS 版本，过程中不会重新配置。
+
+**Q：不用 Claude Code 也能使用 UDS 吗？**
+
+可以。UDS 支持 Claude Code、Cursor、GitHub Copilot、Windsurf，以及任何会读取指令文件的 AI 工具。运行 `uds init` 并选择你的工具，它就会配置对应的文件（`.cursorrules`、`CLAUDE.md` 等）。Skill 为 Claude Code 专属；对于其他工具，标准与等同 CLAUDE.md 的文件仍然适用。
+
+**Q：我已经有一份 `CLAUDE.md`，`uds init` 会覆盖它吗？**
+
+不会。`uds init` 会把 UDS 内容合并进你既有的文件，以清楚标记的区块追加 UDS 段落。你原有的内容会被保留。
+
+---
+
+## Skill 与命令
+
+**Q：什么是 Skill？**
+
+Skill 是预先构建好的 AI 工作流，当你在 Claude Code 输入 `/command` 时就会激活。例如 `/sdd` 会激活 Spec-Driven Development（规格驱动开发）skill，引导你创建 spec 文件。Skill 存储在 `skills/<name>/SKILL.md`，并由 Claude Code 自动加载。
+
+**Q：Skill 和 Standard 有什么区别？**
+
+**Standard（标准）** 是书面准则（Markdown 或 YAML），说明某件事该怎么做（例如「commit-message」标准定义了 Conventional Commits 格式）。**Skill** 则是运用这些标准来执行某个流程的 AI 工作流。标准是知识库；Skill 是执行层。
+
+**Q：为什么我在 Claude Code 菜单里看不到某个 skill？**
+
+可能有三个原因：
+1. **UDS 未初始化**：运行 `uds check` 确认
+2. **超出 skill 预算**：当 skill 很多时，Claude Code 会截断列表。请参阅 [skill-budget-tuning.md](../../../../docs/skill-budget-tuning.md) 调整哪些 skill 会显示
+3. **Tier 3 skill**：Tier 3 skill 默认隐藏以节省 context。它们仍可通过 `/<name>` 调用。若要显示，请在你的 `settings.json` 中覆盖——参阅 [skill-budget-tuning.md](../../../../docs/skill-budget-tuning.md)
+
+**Q：菜单里看不到的 skill 还能用吗？**
+
+可以。无论是否出现在菜单中，每个 skill 都能直接输入 `/<name>` 来调用。例如即使 `brainstorm-assistant` 是 Tier 3 而未列出，`/brainstorm` 仍然有效。
+
+**Q：我怎么知道哪个命令会触发哪个 skill？**
+
+完整的「命令对 skill」对照请见 [COMMANDS-INDEX.md](../../../../docs/user/COMMANDS-INDEX.md)，或以 skill 为中心的视图 [SKILLS-INDEX.md](../../../../docs/user/SKILLS-INDEX.md)。
+
+**Q：我怎么停用一个从不使用的 skill？**
+
+在你的 `.claude/settings.json` 中：
+```json
+{
+  "skillOverrides": {
+    "brainstorm-assistant": "disabled"
+  }
+}
+```
+所有覆盖选项请见 [skill-budget-tuning.md](../../../../docs/skill-budget-tuning.md)。
+
+---
+
+## 规格驱动开发
+
+**Q：每次变更都得写 spec 吗？**
+
+不用。建议在功能、user story 与较具规模的变更时撰写 spec。对于小型 bug 修正或重构，`/commit` 与 `/code-review` 就足够了。经验法则：若实现会花超过 2 小时，写 spec 会有帮助。
+
+**Q：spec 存放在哪里？**
+
+默认位于项目根目录的 `specs/SPEC-NNN-<slug>.md`。格式遵循 UDS spec-driven-development 标准。
+
+**Q：什么是 AC（Acceptance Criterion，验收条件）？**
+
+验收条件是一条可测试的陈述，用来定义一个功能何时算「完成」。例如：「Given 一位已注册用户，When 他以正确凭证登录，Then 他会取得有效的 session token。」AC 驱动测试覆盖并防止范围蔓延。
+
+---
+
+## 更新与版本
+
+**Q：我要如何把 UDS 更新到最新版？**
+
+```bash
+uds update
+```
+
+这会下载最新的标准与 skill，同时保留你项目专属的定制化。
+
+**Q：我要如何查看当前的 UDS 版本？**
+
+```bash
+uds --version
+# 或
+cat .standards/manifest.json | grep version
+```
+
+**Q：更新 UDS 会破坏我现有的 spec 或 CLAUDE.md 吗？**
+
+不会。标准更新保持向后兼容。Spec 是你的文件，`uds update` 绝不会动它们。CLAUDE.md 只有在你明确运行 `uds init --force` 时才会被修改。
+
+---
+
+## 架构
+
+**Q：什么是「双层架构（Dual-Layer Architecture）」？**
+
+UDS 有两层：
+- **Core Standards（核心标准，`.standards/` — Markdown 文件）**：人类可读的准则、完整理论、边界情况
+- **AI Standards（AI 标准，`.standards/` — `.ai.yaml` 文件）**：同一份标准的 token 精简、为 AI 优化的版本，专为 Claude Code 的 context window 设计
+
+当 Skill 运行时，它会读取 `.ai.yaml` 文件。当开发者想了解背后理由时，则阅读 `.md` 文件。
+
+**Q：`skills/` 和 `.standards/` 有什么区别？**
+
+`skills/` 包含驱动 Claude Code 中 `/command` 的 SKILL.md 文件，它们是工作流。
+`.standards/` 包含底层知识库（Core Standards + AI Standards）。Skill 引用标准；标准不引用 skill。
+
+**Q：什么是 Skill Tier？（DEC-061）**
+
+Tier 控制 Claude Code 的 context 预算有多少用于 skill 描述：
+- **Tier 1**：永远以完整描述列出（15 个 skill — 每日使用）
+- **Tier 2**：默认以完整描述列出（28 个 skill — 每周使用）
+- **Tier 3**：默认仅列出名称（12 个 skill — 专家／事件驱动）
+
+所有 tier 都能通过 `/<name>` 完整调用。Tier 只影响 _列出_ 的行为。

package/bundled/locales/zh-CN/docs/user/GETTING-STARTED.md

@@ -0,0 +1,144 @@
+---
+source: docs/user/GETTING-STARTED.md
+source_version: 1.0.0
+translation_version: 1.0.0
+status: current
+---
+
+# UDS 入门指南
+
+> **语言**: [English](../../../../docs/user/GETTING-STARTED.md) | 简体中文
+
+本指南带你走过 UDS 从零开始，直到完成第一份 AI 辅助的 spec 与 commit。
+预估时间：**5 分钟**。
+
+---
+
+## 先决条件
+
+- Node.js ≥ 20.0.0（`node --version`）
+- 一个 AI 编程助手：Claude Code（建议）、Cursor、GitHub Copilot 或类似工具
+
+---
+
+## 步骤 1 — 安装
+
+```bash
+npm install -g universal-dev-standards
+uds --version
+```
+
+> **不想全局安装？** 使用 `npx universal-dev-standards init` 即可不安装直接运行。
+
+---
+
+## 步骤 2 — 初始化你的项目
+
+在你的项目目录内运行 `uds init`：
+
+```bash
+cd your-project
+uds init
+```
+
+交互式向导将会：
+1. 检测你的 AI 工具（Claude Code、Cursor 等）
+2. 复制标准到 `.standards/`
+3. 配置你 AI 工具的指令文件（例如 `CLAUDE.md`）
+4. 安装你所选择的 skill
+
+初始化后，你应该会看到：
+```
+.standards/          ← AI 可读的标准
+CLAUDE.md            ← 已更新 UDS 指引（Claude Code）
+```
+
+> **已经有 CLAUDE.md？** `uds init` 会采合并方式——不会覆盖你既有的内容。
+
+---
+
+## 步骤 3 — 你的第一份 Spec（`/sdd`）
+
+在写代码之前，先创建一份 spec：
+
+1. 在你的项目中打开 Claude Code
+2. 输入：`/sdd` 并按 Enter
+3. 描述你想要构建的东西（例如「新增用户以 email + 密码登录」）
+4. Claude 会在 `specs/SPEC-NNN-*.md` 创建一份 spec 文件
+
+这份 spec 会记录：
+- **Background（背景）** — 为什么需要这个功能
+- **Acceptance Criteria（验收条件，AC）** — 可测试的结果
+- **Out of Scope（范围外）** — 明确的边界
+
+> **为什么要先写 spec？** AC 驱动的开发能减少范围蔓延，并让 review 更快。
+> `/sdd` 遵循 UDS Spec-Driven Development（规格驱动开发）标准。
+
+---
+
+## 步骤 4 — 编写代码（搭配 TDD 或 BDD）
+
+有了 spec 之后，选择你的工作流：
+
+| 工作流 | 命令 | 适用时机 |
+|--------|------|----------|
+| 测试驱动开发 | `/tdd` | 编写单元／集成测试 |
+| 行为驱动开发 | `/bdd` | 编写功能场景 |
+| 直接实现 | — | 简单、已充分理解的任务 |
+
+TDD 示例：
+```
+/tdd specs/SPEC-001-user-login.md
+```
+Claude 会引导你走过 RED → GREEN → REFACTOR 循环。
+
+---
+
+## 步骤 5 — Commit（`/commit`）
+
+准备好要 commit 时：
+
+```
+/commit
+```
+
+Claude Code 将会：
+1. 审查你已 stage 的变更
+2. 生成一则符合 [Conventional Commits](https://www.conventionalcommits.org/) 格式的消息
+3. 在 commit 前把消息显示给你确认
+
+> **安全推送？** 在 `git push` 前使用 `/push` 取得额外的质量门禁。
+
+---
+
+## 常用命令速览
+
+| 任务 | 命令 |
+|------|------|
+| 浏览所有 skill | `/dev-workflow` |
+| 创建 spec | `/sdd` |
+| TDD 工作流 | `/tdd` |
+| BDD 工作流 | `/bdd` |
+| 生成 commit | `/commit` |
+| 安全推送 | `/push` |
+| 架构决策 | `/adr` |
+| 代码审查 | `/code-review` |
+
+完整列表请见 [SKILLS-INDEX.md → 触发时机速查](../../../../docs/user/SKILLS-INDEX.md#觸發時機速查-when-to-use)。
+
+---
+
+## 疑难排解
+
+- **找不到 skill**：输入 `uds check` 验证安装状态
+- **CLAUDE.md 未更新**：重新运行 `uds init --force`
+- **Claude Code 菜单中未显示 skill**：见 [TROUBLESHOOTING.md](../../../../docs/user/TROUBLESHOOTING.md)
+
+---
+
+## 后续步骤
+
+- **探索所有 skill**：[SKILLS-INDEX.md](../../../../docs/user/SKILLS-INDEX.md)
+- **自定义 skill 显示**：[skill-budget-tuning.md](../../../../docs/skill-budget-tuning.md)
+- **每日工作流模式**：[DAILY-WORKFLOW-GUIDE.md](../../adoption/DAILY-WORKFLOW-GUIDE.md)
+- **理解架构**：[GLOSSARY.md](../../../../docs/user/GLOSSARY.md)

package/bundled/locales/zh-CN/docs/user/GLOSSARY.md

@@ -0,0 +1,178 @@
+---
+source: docs/user/GLOSSARY.md
+source_version: 1.0.0
+translation_version: 1.0.0
+status: current
+---
+
+# UDS 术语表
+
+> **语言**: [English](../../../../docs/user/GLOSSARY.md) | 简体中文
+
+UDS 专属，或在 UDS 语境下有特定用法的术语。
+
+---
+
+## A
+
+**AC（Acceptance Criterion，验收条件）**
+一条可测试的陈述，定义一个功能何时算完成。以 Given-When-Then 或一般英文撰写。AC 记录在 Spec 文件中，并在测试里被引用。
+_参见：`/atdd`、`/sdd`、`acceptance-test-driven-development` 标准_
+
+**Activity（活动）**
+在 DEC-051 四层分类模型中，Activity 是一个具名的工作流步骤（例如「编写失败的测试」、「执行回归测试」）。Activity 定义于 UDS 标准中，并由 Skill 执行。
+
+**ADR（Architecture Decision Record，架构决策记录）**
+记录一项重大技术决策的文件：上下文、考量过的选项、所选方案，以及后果。
+_参见：`/adr`、`adr-standards` 标准_
+
+**ATDD（Acceptance Test-Driven Development，验收测试驱动开发）**
+一种实践做法：在开始实现前先定义验收条件，并编写测试来验证这些 AC。桥接 BDD 与 TDD。
+_参见：`/atdd`_
+
+---
+
+## B
+
+**BDD（Behavior-Driven Development，行为驱动开发）**
+一种使用自然语言 Given-When-Then 场景来描述系统行为的开发实践。场景同时作为文档与测试规格。
+_参见：`/bdd`、`behavior-driven-development` 标准_
+
+**Bundle（Bundle 层）**
+包含在 `npm install` 包中的 UDS 标准子集（供采用者使用）。与 Source 层不同——后者包含所有标准，含治理与维护工具。
+_参见：DEC-045_
+
+---
+
+## C
+
+**Core Standard（核心标准）**
+位于 `core/`（以及 `.standards/*.md`）的 Markdown 文件，包含某个 UDS 标准完整、人类可读的版本。涵盖背后理由、边界情况、示例与参考资料。
+_对比：AI Standard_
+
+**AI Standard（AI 标准）**
+位于 `.standards/`（以及 `ai/standards/`）的 `.ai.yaml` 文件，是 Core Standard 的 token 精简、为 AI 优化的编码。Skill 在执行时读取它。
+
+---
+
+## D
+
+**DEC（Decision，决策）**
+记录于 `dev-platform/cross-project/decisions/DEC-NNN-*.md` 的跨项目架构或产品决策。DEC 依序编号，追踪重大选择背后的「为什么」。
+
+**Dual-Layer Architecture（双层架构）**
+UDS 的两层设计：Core Standards（完整知识、人类可读）+ AI Standards（token 精简、机器可读）。Skill 使用 AI Standards；开发者阅读 Core Standards。
+
+---
+
+## S
+
+**SDD（Spec-Driven Development，规格驱动开发）**
+一种 UDS 实践做法：在写代码前先创建规格文件。Spec 定义背景、范围、验收条件与范围外项目。
+_参见：`/sdd`、`spec-driven-development` 标准_
+
+**Skill**
+封装为 SKILL.md 文件的预建 AI 工作流。在 Claude Code 输入 `/<name>` 即可激活。Skill 运用 AI Standards 来实现 UDS 的活动。
+_参见：[SKILLS-INDEX.md](../../../../docs/user/SKILLS-INDEX.md)_
+
+**Skill Budget（Skill 预算）**
+Claude Code 的 context window 中保留用于列出可用 skill 的比例。当有 55+ 个 skill 时，描述可能被截断。UDS 以 Tier 来管理这项预算。
+_参见：DEC-061、[skill-budget-tuning.md](../../../../docs/skill-budget-tuning.md)_
+
+**Skill Tier（Skill 分级，DEC-061）**
+依使用频率对 skill 进行分类，借此控制列出行为：
+- **Tier 1（Core）**：15 个 skill，每日使用，永远以描述列出
+- **Tier 2（Advanced）**：28 个 skill，每周使用，默认以描述列出
+- **Tier 3（Specialist）**：12 个 skill，事件驱动，默认仅列出名称（仍可通过 `/<name>` 调用）
+
+**Standard（标准）**
+涵盖某项特定实践（例如 commit 消息、API 设计、测试）的 UDS 准则文件。标准与技术、语言无关。每个标准同时存在为 Core Standard（`.md`）与 AI Standard（`.ai.yaml`）。
+
+**Source（Source 层）**
+完整的 UDS 仓库，包含所有标准、治理工具与维护脚本。是 Bundle 层的超集。
+_参见：DEC-045_
+
+---
+
+## T
+
+**TDD（Test-Driven Development，测试驱动开发）**
+一种在实现代码前先编写测试的开发实践。RED-GREEN-REFACTOR 循环：写一个失败的测试 → 让它通过 → 重构。
+_参见：`/tdd`、`test-driven-development` 标准_
+
+---
+
+## U
+
+**UDS（Universal Development Standards，通用开发标准）**
+本项目。一套与语言无关、与框架无关的软件开发质量汇集，含 149 个核心标准、55 个 AI skill 与 51 个斜线命令。
+
+**UDS Manifest（`uds-manifest.json`）**
+所有 UDS 标准与 skill 的机器可读索引。包含统计数据、skill 对命令的对照，以及分类归属。供 UDS CLI 与文档生成器使用。
+
+---
+
+## X
+
+**XSPEC（Cross-Project Spec，跨项目规格）**
+位于 `dev-platform/cross-project/specs/XSPEC-NNN-*.md` 的规格文件。用于影响多个子项目（UDS、VibeOps、telemetry）的功能，或新的 UDS 功能。
+_依集中化政策（2026-04-22），所有新 spec 一律创建为 XSPEC。_
+
+---
+
+## 术语规范化（Canonical Forms，标准形式）
+
+> 跨标准反复出现的术语与符号之单一真实来源（XSPEC-292 T6）。这些表格把**既有、刻意为之**的惯例明文化，让新标准对齐而非漂移。它们**不会**重新命名任何东西——多数看似「双重术语」的情况其实是依层级设计、各得其所（例如 JSON body 中的 `createdAt` 对比数据库字段的 `created_at` 是正确的，并非冲突）。
+
+### 依层级的字段命名
+
+同一个概念依其所在层级的惯例书写。跨越层级边界是一种转换，而非不一致。
+
+| 层级 | 惯例 | 示例 |
+|------|------|------|
+| 结构化日志（JSON） | `snake_case` | `trace_id`、`request_id`、`http_method`、`db_table` |
+| API JSON body | `camelCase` | `createdAt`、`firstName`、`httpStatus` |
+| API 查询参数 | `snake_case` | `?sort_by=created_at` |
+| URL 路径片段 | `kebab-case` | `/user-profiles` |
+| HTTP header 名称 | `lowercase-hyphen` | `x-request-id`、`traceparent` |
+| 数据库数据表／字段 | `snake_case`（单数数据表）| `user_account`、`created_at` |
+| 代码标识符 | 语言原生 | `camelCase`（JS/TS）、`snake_case`（Python/Go）|
+
+_标准：`logging-standards`、`api-design-standards`、`database-standards`。_
+
+### 测试层级缩写
+
+大写＝该术语；小写＝环境标识符。`IT` 永远指 Integration Testing（集成测试），绝非 Information Technology。
+
+| 缩写 | 全称 | 典型环境 |
+|------|------|----------|
+| `UT` | Unit Testing（单元测试）| `local` |
+| `IT` | Integration Testing（集成测试）| `local` / `ci` |
+| `ST` | System Testing（系统测试）| `ci` / `sit` |
+| `E2E` | End-to-End Testing（端到端测试）| `staging` |
+| `AT` | Acceptance Testing（验收测试）| — |
+| `UAT` | User Acceptance Testing（用户验收测试）| — |
+| `SIT` | System Integration Testing（系统集成测试，该术语）；`sit` 是 SIT **环境** id | `ci` |
+
+_标准：`testing`（testing-standards）、`test-governance`。_
+
+### 状态：文字 vs 符号
+
+**文字**是标准／机器可读的值；**符号**是可选的视觉呈现。两者成对，并非互相竞争。
+
+| 标准文字 | 符号 | 领域 |
+|----------|------|------|
+| `covered` | ✅ | AC／测试覆盖 |
+| `partial` | ⚠️ | AC／测试覆盖 |
+| `uncovered` | ❌ | AC／测试覆盖（测试缺口）|
+| `not_implemented` | 🚫 | AC（代码缺口，非测试缺口）|
+
+_领域专属的生命周期各自维持独立的状态机——ADR（`Proposed → Accepted → Deprecated → Superseded`）、文档生命周期（`draft → active → archived`），以及上方的 AC 覆盖彼此不同，**不会**被合并。标准：`acceptance-criteria-traceability`、`adr-standards`、`documentation-structure`。_
+
+---
+
+## 另见
+
+- [FAQ.md](FAQ.md) — 常见问题
+- [SKILLS-INDEX.md](../../../../docs/user/SKILLS-INDEX.md) — 所有 skill 与描述
+- [GETTING-STARTED.md](GETTING-STARTED.md) — 首次设置