universal-dev-standards 6.9.0 → 6.11.0

package/bin/uds.js

@@ -138,6 +138,7 @@ program
   .option('--no-agents-md', 'Skip AGENTS.md generation')
   .option('--with-hooks', 'Install enforcement hooks declared by the installed standards')
   .option('--content-layout <layout>', 'Content layout (flat, layered) [default: flat]')
+  .option('--claude-target <target>', 'Claude Code integration target: project (default, writes CLAUDE.md) or local (writes CLAUDE.local.md — not committed to git; gitignore it yourself)')
   .option('-y, --yes', 'Use defaults, skip interactive prompts')
   .option('-E, --experimental', 'Enable experimental features (methodology)')
   .option('--force', 'Bypass UDS source-repo self-adoption guard (DEC-044 / XSPEC-071)')
@@ -228,6 +229,7 @@ program
   .option('--force', 'Force update all files, ignoring hash comparison')
   .option('--prune', 'Delete .standards/ files UDS wrote but no longer ships (listed without this flag; never touches files UDS did not write)')
   .option('--rollback', 'Rollback to the most recent backup')
+  .option('--claude-target <target>', 'Switch an existing install to a different Claude Code integration target: project (CLAUDE.md) or local (CLAUDE.local.md) — moves the UDS block, keeps your content, no reinstall')
   .option('--locale <locale>', 'Override locale for skills install (zh-tw, zh-cn, en); also reads .uds/install.yaml + UDS_LOCALE env')
   .action(updateCommand);
 

package/bundled/core/agent-communication-protocol.md

@@ -1,5 +1,13 @@
 # Agent Communication Protocol
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 > **Language**: English | [繁體中文](../locales/zh-TW/core/agent-communication-protocol.md)
 
 **Version**: 1.0.0

package/bundled/core/branch-completion.md

@@ -1,5 +1,13 @@
 # Branch Completion Workflow
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 > **Language**: English | [繁體中文](../locales/zh-TW/core/branch-completion.md)
 
 **Version**: 1.0.0

package/bundled/core/change-batching-standards.md

@@ -1,5 +1,13 @@
 # Change Batching Standards
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 > **Language**: English | [繁體中文](../locales/zh-TW/core/change-batching-standards.md)
 
 **Applicability**: All software projects using automated development pipelines

package/bundled/core/execution-history.md

@@ -1,5 +1,13 @@
 # Execution History Repository Standards
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 **Applicability**: All AI-assisted software projects
 **Scope**: universal
 **Version**: 1.0.0

package/bundled/core/pipeline-integration-standards.md

@@ -1,5 +1,13 @@
 # Pipeline Integration Standards
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 > **Language**: English | [繁體中文](../locales/zh-TW/core/pipeline-integration-standards.md)
 
 **Applicability**: All software projects using automated development pipelines

package/bundled/core/workflow-enforcement.md

@@ -1,5 +1,13 @@
 # Workflow Enforcement Standards
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 **Applicability**: All software projects using structured development methodologies
 **Scope**: universal
 

package/bundled/core/workflow-state-protocol.md

@@ -1,5 +1,13 @@
 # Workflow State Protocol
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **Reference only — UDS does not install this standard.** Its machine-readable
+> `.ai.yaml` was removed in 6.0.0; the document is kept here for the adoption
+> layer that implements it, and is **not distributed by `uds init` or
+> `uds update`**. The list this notice is checked against is
+> [`scripts/reference-only-standards.json`](../scripts/reference-only-standards.json);
+> the migration record is [`docs/MIGRATION-v6.md`](../docs/MIGRATION-v6.md) §2.
+
 **Version**: 1.0.0
 **Last Updated**: 2026-03-17
 **Applicability**: All projects using multi-phase AI workflows

package/bundled/locales/zh-CN/CHANGELOG.md

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.9.0
-translation_version: 6.9.0
-last_synced: 2026-09-14
+source_version: 6.11.0
+translation_version: 6.11.0
+last_synced: 2026-09-18
 status: current
 ---
 
@@ -17,6 +17,52 @@ status: current
 
 ## [Unreleased]
 
+## [6.11.0] - 2026-09-18
+
+### 修复
+
+- **`uds update --plan`／`--apply` 对整合文件永远不会收敛：即使刚跑完 `--apply`、文件内容与生成器会生成的内容逐字节相同，仍会显示 `Migrate Block: N`。** `diffIntegrations` 对任何带有 UDS 标记的整合文件都无条件产生 `migrate_block` 动作——"我们一律更新整合文件，因为内容是动态生成的"——因为 desired state 从未带有可比对的哈希（`hash: null`，注释说"生成后才计算"，但从未真正算过）。desired-state calculator 现在会用 `--apply` 自己会用的同一条路径（`buildToolIntegrationConfig` ＋ `generateIntegrationContent`）生成整合文件内容，并只对 UDS 区块算哈希，让 `diffIntegrations` 能像其他每个类别一样分辨"内容已经相符"与"内容不同"，哈希相符时报告 `unchanged` 而非 `migrate_block`。一份区块真的过期的文件（手动编辑过，或由旧版 CLI 生成）仍会照旧产生 `migrate_block`。生成失败（例如 registry 解不出某个工具）时回退为修正前的无条件行为，不会让计划崩溃。
+- **`uds check` 可能在同一次运行里对同一个整合文件打印两条互相矛盾的"已引用"宣告。** `standardsReferenced`（"已引用 {count}/{total} 项标准"）扫描整个整合文件正文——标准名称在任何地方被提到都算。`standardsNotReferenced`（"未引用的标准（可选）："）只看结构化的 `Reference:`／`参考:` 行。一个标准在文件散文中被提到、却没有列在任何 `Reference:` 行上，会在同一次运行里同时满足第一条宣告、又落在第二条宣告里——同一个词（"已引用"／"引用"），量测的是两件不同的事，读起来像矛盾。三语的第二条消息都已改写成精确描述它实际检查的内容（没有出现在 `Reference:`／`参考:` 行），取代原本笼统的"未引用"宣告。
+- **单纯的 `uds update --plan` 与 `uds check` 从未提示 Skills 或 Commands 版本落后最新 UDS 发行版。** 版本落后只由 `uds update --plan --skills`／`--plan --commands` 计算——一般的协调 `--plan`（不带范围标志）调用的是另一个从未触及这件事的函数，`uds check` 则完全没有对等的检查。用户跑纯粹的 `--plan` 或 `check` 时，看到的是一份干净的报告，尽管 Skills 落后了一整个小版本，也没有任何提示说带范围的 plan、或 `uds update --skills` 有事可做。两者现在都会在任何已安装的 Skills 或 Commands 版本落后时，打印简短的"`<工具>`（`<位置>`）：v旧 → v新"提示，并附上修复命令。这比照既有的顶层"Version: X → Y ⚠"行，而非整合区块完整性检查（XSPEC-418 R1）：落后最新版是用户更新前的常态，不是像 UDS 区块被修改／丢失那样的合规缺陷，因此不会让 `uds check --ci` 失败。
+- **6.10.0 的死链接修正（P2）把一条写着 6.0.0 之前文件名的引用直接删掉，而不是改写它，还可能留下一个悬空的逗号。** `resolveStandardReferences` 比对一行 `Reference:` 的 stem 时只查 manifest 已安装清单，从未查过 `STANDARD_ID_MAPPING`（conversion-rules.js）——这正是 `yaml-generator.js` 别处已在用、记录"旧文件名 → 现行 id"的对照表。一行写着旧文件名 `.standards/commit-message-guide.md` 而项目其实装了 `commit-message` 的引用，看起来和一个项目刻意不装、已停用的 UDS 标准一模一样，于是被整行删掉，而不是改写成 `.standards/commit-message.ai.yaml`。另外，删掉一项引用后的逗号清理只处理了尾部逗号、重复逗号、逗号前多余空格，没处理"一行里第一项引用被删掉、逗号紧贴在冒号后面"的状况（`Reference:, .standards/other.ai.yaml`）。整段改写为"拆项 → 解析或舍弃 → 重新 join"，取代在原地修补被删字符串周围标点的做法。
+- **被 6.10.0 `resolveStandardReferences` 缺陷删掉的主要标准引用，即使套用上面的修正也不会自己回来。** 把删除动作留下的悬空逗号清掉，修好的只是那一行的标点，不是把被删掉的项目带回来——像"## 提交讯息标准"这样的 UDS 模板段落活在 UDS 标记之外，一旦某一项被删掉，就没有任何东西会重新生成那段内容。针对这个特定情境新增一个范围刻意收窄的自动修复机制：当一行的标题与某个 UDS 模板标题完全相同（`RULE_TEMPLATES` 出货的任一语言版本），而且该模板的主要引用（它自己"`Reference:`"／"`參考:`"行上的第一个 `.standards/...` 项）不在文件那一行里，且该标准确实已安装，就会把它补回该行最前面——行内其他内容（项目自有条目、options 文件、既有顺序）原样不动，不会补回任何次要模板条目，用户自己写的段落（任何其他标题）一律不碰。此修复是幂等的。只修复 6.10.0 那次删除造成的问题，不尝试修复由无关手动编辑造成的引用损坏。
+- **单纯的 `uds update` 从未修复上面 Q1 缺陷留下的坏掉的 `integrationConfigs[file].categories`——只有 `--sync-refs` 会。** 一份已经带着 `categories: []`（来自较旧、有缺陷的 `--sync-refs` 运行）的 manifest，会在之后每一次单纯的 `uds update --yes` 都维持坏掉：该命令自己的整合同步步骤会写 `integrationBlockHashes`，却完全不会读取 `integrationConfigs`，所以没有任何东西修正它——而下一次 `uds check --restore-missing` 就会用那份坏掉的存储配置重建整合文件，再次悄悄漏掉段落。`uds update` 现在会用 `--sync-refs` 同样的方式（`calculateCategoriesFromStandards`）修复空的或无法识别的 `categories` 值，而已经有效的列表维持原样不动，让单纯的 update 不会每次都变成完整的重新同步。
+- **`uds update --sync-refs`／`--integrations-only`／`uds check --migrate`／`uds config` 可能悄悄把 `manifest.version` 降级，同一条同步路径还会在一份正常的 3.4.0 manifest 上算出空的分类集合。** 五个写入点写死了一个较旧的 schema 版本字面值（`'3.1.0'`／`'3.2.0'`／`'3.3.0'`），而不是 CLI 当前的 schema 版本（`3.4.0`）——对一份已经是最新版的 manifest 执行上述任一命令，都会把版本写回旧的。另外，`calculateCategoriesFromStandards`（`--sync-refs` 用来决定 CLAUDE.md／AGENTS.md 该含哪些段落的函数）用文件名查每个标准，但 3.4.0 manifest 存的是纯 stem（`commit-message`，而非 `commit-message.ai.yaml`）——每次查询都落空，分类集合变成空的，下一次 `--sync-refs`（或 `--restore-missing` 重建）就会重新生成一份完全漏掉反幻觉／commit-message／code-review 段落的文件。两者现在都在同一个真实来源处修复：一个共用的 `bumpManifestVersion` 辅助函数，只会让 manifest 版本朝最新前进，不会倒退；以及同文件里别处已在用、支持 stem 的分类查找（`categoryForStandard`）。这让分类计算恢复成 `--sync-refs` 在 6.10.0 之前的算法——依实际已安装的标准计算，而非固定列表——所以完整重新生成（`--sync-refs`、`--integrations-only`，或单纯的 `uds update`）现在会写出每一个有模板、且背后有已安装标准的段落（目前 9 段），而不只是全新 `uds init` 播种的那 3 段；对一个已经有完整段落的项目做纯区块更新则不受影响。
+- **一句单纯提到 UDS 标记文字的句子，可能被误认成真正的区块边界，导致从那句话到真正 END 标记之间的所有内容——包含采用者自己的内容——都被删除（v3.5.0–6.10.0）。** 每一个定位标记的调用点都直接用 `content.indexOf('<!-- UDS:STANDARDS:START -->')`／`.indexOf('...:END -->')`，这会匹配到文件中任何位置出现的标记文字：一句逐字引用标记语法来解释它的句子（本项目自己的 CLAUDE.md 就是这样做），或代码区块里含有它的示例，都和真正的边界无从分辨。这影响了所有四条会重新生成整合文件 UDS 区块的写入路径：`uds update --integrations-only`、`uds update --apply` 的 `migrate_block` reconciler 路径、`uds update --sync-refs`，以及 `uds check --restore`（XSPEC-418 R6 让它也会恢复受损的 UDS 区块）。标记现在只在（去除首尾空白后）独占一整行、且那一行不在 fenced code block（``` ／ ~~~）内时才算数；所有调用点现在都经过同一个共用的 `locateMarkerBlock` 辅助函数，并以静态扫描守卫测试强制执行，避免未来的调用点又退回直接用 `indexOf`／`includes`。含有两组真正标记对的文件（损坏，或手动编辑出错）不再被猜测——每条写入路径都会拒绝执行并列出两个标记所在行号，`uds check` 也会明确报告这个状态，不再并入"已修改"或"找不到标记"。
+- **`uds check --ci` 可能画面上打印整合区块的 ✗，结尾却仍宣称项目符合标准并以退出码 0 收尾。** `checkIntegrationBlocksIntegrity` 的检查结果（区块被修改／丢失／UDS 标记被移除）算出来也打印出来了，却在最终判定被丢弃——判定只看标准文件完整性。若你的 CI 一直对某个 CLAUDE.md／GEMINI.md 等文件的 UDS 区块实际上已被移除或改动的项目显示绿灯，那就是这个缺陷；`--ci` 现在会正确地失败，直到区块被恢复（`uds update --integrations-only`）或项目以其他方式恢复同步为止。交互式 `uds check`（不加 `--ci`）不受影响——仍以退出码 0 收尾，不中断一般使用。（XSPEC-418 R1）
+- **整合文件（CLAUDE.md、CLAUDE.local.md、AGENTS.md 等）同时被整份内容与 UDS 区块两套哈希追踪，两套检查在同一次运行里可能互相矛盾。** 全新 `uds init` 从不为这些文件记录整份哈希，但 `uds update --integrations-only` 会——跑过一次之后，用户在 UDS 区块**外**的任何修改（正是 marker-based update 承诺保留的自定义内容）都会让 `uds check --ci` 报 `CLAUDE.md（已修改）` 并退出码 1，而同一次输出里自己的区块完整性检查却说区块完好。另外，`uds check --restore` 正确地重写了损坏的区块（保留区块外内容，没有数据丢失），却只更新了整份哈希，从未更新区块哈希——于是下一次 check 对一个刚被正确恢复的区块报 `CLAUDE.md（UDS 区块已修改）`。整合文件现在不再写入 `fileHashes`（只写入本来就只追踪区块的 `integrationBlockHashes`）——走查了所有写入点，不只最初报告的两处，包括 `--apply`／`--plan` 的 reconciler 路径与 `--sync-refs`；已有 manifest 里这类文件残留的整份哈希，会在下一次 `uds update`（或 `uds check --restore`／`--migrate`）时被移除，区块哈希保留。`uds check --restore` 恢复整合文件后，现在会把区块哈希更新为实际写入的内容。已用一份真实采用者的 manifest（恰好带有这个残留字段）验证：同一份输入，修正前 `uds check --ci` 退出码 1，修正后退出码 0。后续复核另发现两个缺口，一并修掉：`uds check --restore` 过去对受损的 UDS 区块完全无作用——它靠的是 `fileStatus`，而那完全由 `fileHashes` 构建，已不含整合文件，于是它悄悄恢复了 0 个文件而区块仍是坏的；`--restore` 现在也会恢复被判定为「已修改」或「标记丢失」的区块（不动区块外内容，`--restore-missing` 行为不变）。另外，因为上面新增的清除逻辑只挂在写入路径，已有 manifest 里残留的整份哈希若不曾跑过写入，纯 `check` 永远没有机会清掉它——标准文件完整性检查现在也会在读取时跳过同时被 `integrationBlockHashes` 追踪的键，让未跑过 `update` 的已有项目也能报告干净。（XSPEC-418 R6）
+
+### 新增
+
+- **`uds init --claude-target <project|local>` 与 `uds update --claude-target <project|local>`：在已有团队 `CLAUDE.md` 的仓库里个人采用 UDS。** 过去 UDS 的 Claude Code 集成一律写入 `CLAUDE.md`——团队共用、会进版本控制的文件——没有任何改写目标的方式。在已有团队 `CLAUDE.md` 的仓库里个人采用 UDS 的用户，只能手动把 UDS 区块移到 `CLAUDE.local.md`（Claude Code 原生支持、紧接在 `CLAUDE.md` 之后读入的文件），而从那一刻起 `check`／`update`／`uninstall` 全都报告错误，或悄悄写回团队文件——包括在例行孤儿清理中把移动后文件自己的哈希当作"孤儿"删除。
+  `uds init` 的 `--claude-target local` 从一开始就把集成内容写进 `CLAUDE.local.md`；团队的 `CLAUDE.md` 完全不会被动到。`uds update --claude-target <project|local>` 则让**已有**安装不必重装就能切换目标：从旧文件移除 UDS 区块（保留写在里面的其他内容；若旧文件在移除后只剩 UDS 内容则整个删除，与 `uninstall` 既有规则一致）、写入新目标、并更新 manifest，不论新目标是否已存在手动移过去的区块。`check`、`update`（含 `--integrations-only`／`--force`）与孤儿哈希清理现在都经同一个函数解出工具的实际目标文件，不再各自假设默认值——从未使用 `--claude-target` 的项目完全不受影响：manifest 只有在选择 `local` 时才会多出 `integrationTargets` 字段。`--claude-target` 不影响 `AGENTS.md`；若不想让它进版本控制，一样要自己通过 `.git/info/exclude` 排除。UDS 不会自动把 `CLAUDE.local.md` 写进 `.gitignore`——请自行加入——且因为它未受版本控制，只存在于创建它的那个 git worktree。详见 [CLI-INIT-OPTIONS.md](docs/CLI-INIT-OPTIONS.md)（"Claude Code 集成目标文件"一节）。（XSPEC-418 R2–R4）
+
+## [6.10.0] - 2026-09-16
+
+### 修复
+
+- **`uds update --apply` 会忘掉它没有动到的每一个斜杠命令，而 `uds check` 说一切完整。** 一个装有 51 个 OpenCode 命令的项目，三个文件内容漂移：plan 列出那三个，`--apply` 之后 manifest 只剩三条 `commandHashes`——另外 48 个文件仍在磁盘上，却没有任何东西在跟踪它们。同一次 `uds check` 同时打印「Commands: 51 installed」与「✓ All command files intact (3 files)」，而篡改那 48 个之一，两行都不会变（2026-09-16 于干净临时项目在 6.9.0 上实测）。reconciler 在合并新哈希前，会先删掉该工具的所有哈希键——只有在安装器重装了该工具全部命令时才正确，`uds update` 自己的调用点如此，plan 这条路不是。现在改为合并，与 skills 路径一贯的做法相同；plan 标记删除时，只移除该文件那一条。`uds check` 另外列出磁盘上没有任何哈希覆盖的命令文件，两个数字不再能各说各话。
+- **集成文件指向磁盘上不存在的标准，而引用检查说它们同步。** 以 `--format ai` 安装的项目，`uds update --integrations-only` 写出 `Reference: .standards/anti-hallucination.md` 与 `.standards/checkin-standards.md`，这两个文件只存在于 `human` 格式。规则模板一律以 `.md` 书写引用路径，不看实际安装格式；而规则段落位于 UDS 标记之外，标记式更新从不刷新它们——由旧版 CLI 首次写出的文件，在该文件停止发布两个主版本之后，仍留着 `.standards/commit-message-guide.md`。现在无论生成新文件还是更新既有文件，引用路径都会对照本项目实际安装的标准与格式解析；指向未采用标准的引用会被移除，而不是留成死链接。`uds check` 改为报告「文件不存在」的引用，而不是以去掉扩展名的名称比对。只有 UDS 自己发布的标准会被移除：项目自行放进 `.standards/` 的文件，其引用原样保留。
+- **`uds check` 建议执行 `uds update --sync-refs`，而它跑不起来。** manifest 没有 `integrationConfigs` 时 `--sync-refs` 直接中止，而这个键只有 `uds init` 的交互流程会写入——以 `uds init -y` 创建的项目从第一天起就是 `{}`，所以一个全新的 6.9.0 项目，已经处在那段错误信息归咎于「旧版本、手动复制」的状态。`--sync-refs` 现在会从 manifest（integrations、AI 工具、标准、选项）重建配置，而不是拒绝执行；`uds check` 只在它确实可执行时才提它，否则改指 `uds update --integrations-only`。
+- **`uds check` 把已采用的标准报成索引中缺少。** id 对文件名的表只从 `source.ai` 建立，但部分 registry 条目的 `source` 是字符串——`zh-tw-locale` 是 `extensions/locales/zh-tw.md`——于是它安装出的 `.standards/zh-tw.md` 从未被认出，在明明列出该文件的集成文件上显示「67/68 项标准已引用，缺少：zh-tw-locale」。
+- **引用同步把选项文件报成孤儿，并建议 UDS 已不再发布的文件名。** 选项记在 `manifest.options` 而非 `manifest.standards`，于是每个 `.standards/options/*.ai.yaml` 引用都被报成「未在 manifest 中」；而「未引用的标准」清单来自一张手写的 6.0.0 之前文件名表（`git-workflow.md`、`error-code-standards.md`、`project-structure.md`）。现在选项会被认得，清单也只列出本项目实际持有的文件。
+- **`uds check` 把 `AGENTS.md` 列了两次。** Codex 与 OpenCode 共用同一份文件，而检查是逐工具而非逐文件进行。现在每个文件只报告一次，并标明共用它的工具。
+- **七条 `core/*.md` 标准自 6.0.0 起就没有被安装过，而它们一个字都没说（[#180](https://github.com/AsiaOstrich/universal-dev-standards/issues/180)）。** 它们的 `.ai.yaml` 在 6.0.0 被移除，文档则刻意留在 `core/` 作为采用层的参考——这个决定合理，也记在 `docs/MIGRATION-v6.md` §2 与 `scripts/reference-only-standards.json` 里，但**没有记在读者真正会遇到它的地方**。迁移指南在升级时读一次，`core/` 是持续被读的：走访它来回答「UDS 有哪些标准」的人或 agent 会数到 152 份，其中七份 `uds init` 从未安装过。七份现在都在开头带一段 `<!-- UDS:REFERENCE-ONLY -->` 告示，英文、繁中、简中三份都有，并指向迁移记录与那份机器可读清单。新闸门（`npm run check:reference-only`，已接进 CI 并附两臂自测）从 registry 里每一条 `source.human` 现算出货面，把它与 `core/*.md` 的差集当成 reference-only 集合，要求每一份都要披露——**反过来也要求正在出货的文档不得带着这段告示**，所以一条重新开始出货的标准不会留下一句谎话。用现算而不是比对那七个名字，是为了让下一次缩减范围不会重演同一种沉默。
+- **`--format human` 的安装把 `testing-standards.md` 挂在两个标准 id 下送出，而全覆盖那一份从来没送到。** `full-coverage-testing` 的 registry 条目把 `source.human` 指到 `core/testing-standards.md`，于是 `core/full-coverage-testing.md`——一条活着的标准，最近一次维护是 XSPEC-288——没有任何人装得到，而 human 格式的 manifest 里同一条路径出现两次。`check-registry-completeness.ts` 的 Check 2 看不到它：那支只要 human 或 ai 任一条路径出现在 registry 文字里就算通过，而 ai 那条在。由上面那支闸门首跑时抓到，是七份预期之外的第八份。修正前后各跑一次真正的 `uds init --format human` 验证。
+- **`uds update --sync-refs` 写进去的标准数，`uds check` 当场否认。** manifest 有 73 条标准的项目，`--sync-refs` 把 CLAUDE.md 改成宣告 76 条，`uds check` 随即回「索引宣告 76 条标准，manifest 实际有 73 条」；而 `--integrations-only` 算得出正确数字，于是它看起来像计数错误，其实是**来源错误**。`--sync-refs` 是从 `integrationConfigs[文件名]` 重新生成的，那里面的 `installedStandards` 是安装当时的快照、**没有任何路径会更新它**——跨大版本升级过的项目，它仍列着 6.0.0 就停止发布的标准，而它列什么，文件内容就是什么。现在改为从 manifest 重新生成；旧快照只剩 `outputLanguage` 还有发言权。
+- **已安装标准索引在每个项目都写「options 0」。** `uds init` 把安装清单缩成纯文件名，而下游一律以 `/options/` 这个路径片段判断选项——在 `contentLayout: flat` 下根本没有目录可以还原它。一个有 66 条核心标准与 7 个选项的项目，被告知自己有「73 条（core 73、options 0）」。同一个缩减也让 AGENTS.md 里每个选项文件都被写成 `.standards/<名称>.ai.yaml`，比选项实际安装的位置高一层，于是每一条都是死链接。现在路径完整传递，AGENTS.md 的选项写在 `.standards/options/`，并依项目实际格式而非一律假设 `ai`。
+- **照着迁移指南做，会让 `uds check` 报错，而它给的解法不可能成功。** MIGRATION-v6 §2 说要手动删掉七个已降级的 `.ai.yaml`。删掉之后 `fileHashes` 记录还在，`uds check` 于是把七个文件报成遗失并建议 `uds check --restore`，而那个还原在每一个文件上都失败（「无法判断来源」）——上游自 6.0.0 起就没有来源了。现在，一个 UDS 已不再发布的文件不见了，会与真正的遗失分开报告；`uds update` 会清掉那些记录并逐笔说出清了什么，**包含已经在最新版的项目**。`--prune` 碰不到它们：它删的是走访 `.standards/` 时找得到的文件。
+- **UDS 重新生成了 AGENTS.md，却没有记下自己写了什么。** `uds update --integrations-only` 之后紧接着 `uds check`，会在一个只有 UDS 动过的文件上报 `AGENTS.md（已修改）`。三个写 AGENTS.md 的调用点都记了 `integrationBlockHashes`，没有一个记 `fileHashes`。现在已存在的记录会被更新；manifest 没在追踪的文件仍然不会被纳入追踪。
+- **在 Windows PowerShell 上，跑成功看起来像失败。** 进度消息走 stderr，而 PowerShell 5.1 会把原生命令的任何 stderr 输出包成 `NativeCommandError`——**包括报告成功的那一句**。改动前实测：stdout 9 行、stderr 2 行，两行都是 spinner。47 个 spinner 现在一律写 stdout。
+- **删除计划用同一句话解释三种完全不同的情况。** 「no longer in desired state」同时被打给「上游已移除的标准」「项目自己取消选取的选项」「desired state 根本没有建模的路径」。现在理由会说出是哪一种。`.standards/release-config.yaml` 则完全不再是删除候选：它是 `uds init` 依用户挑的发布模式写出、`uds config` 会改写的文件，删掉它是在丢掉一个设置却自称在对账。
+- **一个 .NET Framework 项目拿到四个命令，其中三个跑不动。** `.csproj` 自 2017 年起同时指涉两套互不兼容的构建系统，而检测只看扩展名：旧式项目拿到 `dotnet build`（以 `MSB4019` 失败）与 `dotnet list package --vulnerable`（对 `packages.config` 项目静静地什么都不报）。旧式项目现在 `build` 给 `msbuild`，其余留白。
+- **每一份生成的指示文件，开头都叫 AI 去读一个永远不会被安装的目录。** 九个工具、每种语言，全都以「**优先**读取 `core/` 中的精简规则」开场。`uds init` 安装到 `.standards/`，从来没有在采用者的项目里建立过 `core/`。同样两句话有 36 份副本、错法一模一样。现在它们指向 `.standards/`，并有一支测试走访生成结果。
+- **`uds update` 把中文的 CLAUDE.md 改写成英文。** `uds init` 依 `display_language` 生成集成文件内容，而每一条重新生成的路径都是从 `output_language`（commit 消息语言，默认 `english`）推导的。现在内容语言依 `display_language`。
+
+### 新增
+
+- **`uds check` 现在会报出指示文件里提到、但实际不存在的路径。** 先前它只读 `Reference:`／`参考:` 开头的行、而且只看 `.standards/` 路径。UDS 标记之外、由旧版安装留下、之后没有任何重新生成会回头看的散文，把 agent 指向不存在的文件。这支扫描以**文件存不存在**为准而非以路径长相为准，网址里的路径也会被排除。它首跑就找到了本次修正中的两项缺陷。
+
 ## [6.9.0] - 2026-09-14
 
 ### 采用者升级注意

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

@@ -15,7 +15,7 @@ status: current
 
 > **语言**: [English](../../README.md) | [繁體中文](../zh-TW/README.md) | 简体中文
 
-**版本**: 6.9.0 | **发布日期**: 2026-09-14 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.11.0 | **发布日期**: 2026-09-16 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
 
 语言无关、框架无关的软件项目文档标准。通过 AI 原生工作流，确保不同技术栈之间的一致性、质量和可维护性。
 

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

@@ -13,7 +13,7 @@ status: current
 <!-- UDS_SUPPORTED_VERSIONS_START -->
 | 版本 | 支持状态 |
 |------|--------|
-| 6.9.0 | ✅ 最新正式版 |
+| 6.11.0 | ✅ 最新正式版 |
 | < 6.0.0 | ❌ 已终止支持 |
 <!-- UDS_SUPPORTED_VERSIONS_END -->
 

package/bundled/locales/zh-CN/core/agent-communication-protocol.md

@@ -8,6 +8,13 @@ status: current
 
 # Agent 通信协议
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 > **语言**: [English](../../../core/agent-communication-protocol.md) | 简体中文
 
 **版本**: 1.0.0

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

@@ -10,6 +10,13 @@ status: current
 
 # 分支完成工作流程
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 **版本**: 1.0.0
 **最后更新**: 2026-03-20
 **适用范围**: 所有使用 Git 分支工作流的项目

package/bundled/locales/zh-CN/core/change-batching-standards.md

@@ -8,6 +8,13 @@ status: current
 
 # 变更批次标准
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 > **语言**: [English](../../../core/change-batching-standards.md) | 简体中文
 
 **适用范围**: 所有使用自动化开发流程的软件项目

package/bundled/locales/zh-CN/core/execution-history.md

@@ -8,6 +8,13 @@ status: current
 
 # 执行历史存储库标准
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 > **语言**: [English](../../../core/execution-history.md) | 简体中文
 
 **版本**: 1.0.0

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

@@ -8,6 +8,13 @@ status: current
 
 # Pipeline 整合标准
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 > **语言**: [English](../../../core/pipeline-integration-standards.md) | 简体中文
 
 **适用范围**: 所有使用自动化开发 Pipeline 的软件项目

package/bundled/locales/zh-CN/core/workflow-enforcement.md

@@ -8,6 +8,13 @@ status: current
 
 # 工作流程强制执行标准
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 **适用范围**：所有使用结构化开发方法论的软件项目
 **范围**：通用
 

package/bundled/locales/zh-CN/core/workflow-state-protocol.md

@@ -8,6 +8,13 @@ status: current
 
 # 工作流程状态协议
 
+<!-- UDS:REFERENCE-ONLY since=6.0.0 -->
+> **仅供参考——UDS 不会安装这条标准。** 它的机器可读文件 `.ai.yaml` 已于 6.0.0 移除；
+> 本文档保留在此，供实现它的采用层参考，**不由 `uds init` 或 `uds update` 发布**。
+> 本告示所对照的清单是
+> [`scripts/reference-only-standards.json`](../../../scripts/reference-only-standards.json)，
+> 迁移记录见 [`docs/MIGRATION-v6.md`](../../../docs/MIGRATION-v6.md) §2。
+
 > **语言**: [English](../../../core/workflow-state-protocol.md) | [繁體中文](../../zh-TW/core/workflow-state-protocol.md)
 
 **版本**: 1.0.0

package/bundled/locales/zh-CN/docs/CHEATSHEET.md

@@ -1,6 +1,6 @@
 # UDS 速查表
 
-> Quick reference for all UDS features | Last updated: 2026-09-14
+> Quick reference for all UDS features | Last updated: 2026-09-18
 
 **Language**: [English](../../../docs/user/CHEATSHEET.md) | [繁體中文](../../zh-TW/docs/CHEATSHEET.md) | 简体中文
 

package/bundled/locales/zh-CN/docs/CLI-INIT-OPTIONS.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../docs/CLI-INIT-OPTIONS.md
-source_version: 3.5.1
-translation_version: 3.5.1
-last_synced: 2026-01-15
+source_version: 3.5.2
+translation_version: 3.5.2
+last_synced: 2026-09-18
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **语言**: [English](../../../docs/CLI-INIT-OPTIONS.md) | [简体中文](../../zh-TW/docs/CLI-INIT-OPTIONS.md) | 简体中文
 >
-> **版本**: 3.5.0
-> **最后更新**: 2026-01-09
+> **版本**: 3.5.2
+> **最后更新**: 2026-09-18
 
 本文档详细说明 `uds init` 命令的每一个选项，包含使用情境、影响范围和建议选择。
 
@@ -835,8 +835,49 @@ uds init --experimental
 | 不生成 AGENTS.md | `--no-agents-md` | 跳过 AGENTS.md 生成 |
 | 强制执行 Hooks | `--with-hooks` | 安装强制执行 hooks（commit-msg、security、logging） |
 | 内容布局 | `--content-layout` | 内容布局（`flat`、`layered`）- 默认：`flat` |
+| Claude Code 目标文件 | `--claude-target` | Claude Code 集成内容要写到哪里：`project`（`CLAUDE.md`，默认）或 `local`（`CLAUDE.local.md`） |
 | 模式（已弃用） | `-m, --mode` | 安装模式（skills, full）- 请改用 `--skills-location` |
 
+### Claude Code 集成目标文件（`--claude-target`）
+
+UDS 默认把 Claude Code 内容写进 `CLAUDE.md`——团队共用、会进版本控制的那个文件。
+若你是在一个**已有团队 `CLAUDE.md`** 的仓库里**个人采用** UDS，改用
+`--claude-target local`：UDS 会改写入 `CLAUDE.local.md`，这是
+[Claude Code 原生支持](https://code.claude.com/docs/en/memory.md)、
+紧接在 `CLAUDE.md` 之后读入的文件，且完全不动团队的文件。
+
+```bash
+# 在有团队 CLAUDE.md 的仓库里个人采用
+uds init -y --claude-target local
+```
+
+使用前有三件事要知道：
+
+1. **要自己把它加进 gitignore。** UDS 不会写 `.gitignore` 或
+   `.git/info/exclude`——请自行把 `CLAUDE.local.md` 加进其中一个，
+   否则它会像任何新文件一样被提交。
+2. **只存在于创建它的那个 worktree。** 因为（你 gitignore 之后）它是未受版本控制的文件，
+   在某个 `git worktree` 创建的 `CLAUDE.local.md` 在同一个仓库的另一个 worktree
+   里看不到——每个 worktree 有自己的工作目录，未受版本控制的文件不会在 worktree 之间共享。
+   若你使用多个 worktree，需要在每一个里分别执行
+   `uds init --claude-target local`（或下方的 `uds update --claude-target local`）。
+3. **`AGENTS.md` 不受影响。** `--claude-target` 只改变 Claude Code 内容要写到哪里。
+   若 `--agents-md` 生成了通用的 `AGENTS.md` 摘要，它仍照常写进 `AGENTS.md`；
+   若也不想让它进版本控制，一样要自己排除（例如通过 `.git/info/exclude`）。
+
+已经用默认目标文件装好了，想不重装就切换？`uds update` 支持同一个标志：
+
+```bash
+# 把已有安装的 Claude Code 内容从 CLAUDE.md 移到 CLAUDE.local.md
+uds update --claude-target local
+
+# 移回去
+uds update --claude-target project
+```
+
+这会从旧文件移除 UDS 区块（保留你自己写在里面的其他内容）、写进新文件，并更新
+manifest——之后 `uds check` 校验的是新目标文件，不是旧的。
+
 ### 完整 CLI 示例
 
 ```bash
@@ -876,6 +917,12 @@ uds init -y --output-lang traditional-chinese --locale zh-cn
 
 # PHP 项目
 uds init -y --lang php --framework fat-free
+
+# 在有团队 CLAUDE.md 的仓库里个人采用
+uds init -y --claude-target local
+
+# 之后把已有安装切换到 CLAUDE.local.md，不需要重装
+uds update --claude-target local
 ```
 
 ---

package/bundled/locales/zh-CN/docs/FEATURE-REFERENCE.md

@@ -1,7 +1,7 @@
 # UDS 功能参考手册
 
 > Universal Development Standards - 完整功能文档
-> Auto-generated | Last updated: 2026-09-14
+> Auto-generated | Last updated: 2026-09-18
 
 **Language**: [English](../../../docs/reference/FEATURE-REFERENCE.md) | [繁體中文](../../zh-TW/docs/FEATURE-REFERENCE.md) | 简体中文
 
@@ -54,6 +54,7 @@
 | `--no-agents-md` | Skip AGENTS.md generation |
 | `--with-hooks` | Install enforcement hooks declared by the installed standards |
 | `--content-layout` | Content layout (flat, layered) [default: flat] |
+| `--claude-target` | Claude Code integration target: project (default, writes CLAUDE.md) or local (writes CLAUDE.local.md — not committed to git; gitignore it yourself) |
 | `-y, --yes` | Use defaults, skip interactive prompts |
 | `-E, --experimental` | Enable experimental features (methodology) |
 | `--force` | Bypass UDS source-repo self-adoption guard (DEC-044 / XSPEC-071) |
@@ -155,6 +156,7 @@
 | `--force` | Force update all files, ignoring hash comparison |
 | `--prune` | Delete .standards/ files UDS wrote but no longer ships (listed without this flag; never touches files UDS did not write) |
 | `--rollback` | Rollback to the most recent backup |
+| `--claude-target` | Switch an existing install to a different Claude Code integration target: project (CLAUDE.md) or local (CLAUDE.local.md) — moves the UDS block, keeps your content, no reinstall |
 | `--locale` | Override locale for skills install (zh-tw, zh-cn, en); also reads .uds/install.yaml + UDS_LOCALE env |
 
 ### `uds skills`

package/bundled/locales/zh-CN/docs/MIGRATION-v6.md

@@ -32,14 +32,13 @@ UDS 6.0.0 是 **major** 版本：包含一项 breaking 更名、移除 8 个已
 
 **不受影响**：指涉外部工具内建 review 命令（如 Codex）的 `/review` 字样与 UDS 无关，刻意保留原样。
 
-## 2. 移除：8 个已弃用的机器可读标准（`.ai.yaml`）
+## 2. 移除：7 个已弃用的机器可读标准（`.ai.yaml`）
 
-这 8 个标准的 runtime 已于 5.4.0 移交采用层（XSPEC-086/095；UDS 定义活动、采用层编排流程——DEC-049），其 `.ai.yaml` stub 如期移除：
+这些标准的 runtime 已于 5.4.0 移交采用层（XSPEC-086/095；UDS 定义活动、采用层编排流程——DEC-049），其 `.ai.yaml` stub 如期移除：
 
 | 移除的 `.ai.yaml` | 保留的人类可读文件 |
 |---|---|
 | `agent-communication-protocol` | `core/agent-communication-protocol.md` |
-| `agent-dispatch` | `core/agent-dispatch.md` |
 | `branch-completion` | `core/branch-completion.md` |
 | `change-batching-standards` | `core/change-batching-standards.md` |
 | `execution-history` | `core/execution-history.md` |
@@ -51,7 +50,12 @@ UDS 6.0.0 是 **major** 版本：包含一项 breaking 更名、移除 8 个已
 
 - 若从未直接载入这些 `.ai.yaml`：不需动作——人类可读概念仍留在 `core/` 作为参考文件。
 - 若采用层（agent runtime、orchestrator、CI）曾载入这些 stub：在自家工具链实作等效机制。这些 stub 自 5.4.0 起本身就是指向此方向的弃用告示。
-- 这些标准不再由 `uds init` / `uds update` 发布。专案 `.standards/` 中既有副本不会被自动删除——想要干净树的话请手动移除。
+- 这些标准不再由 `uds init` / `uds update` 发布。每一份保留下来的 `core/*.md` 都在自己的开头写明这件事，而 `scripts/reference-only-standards.json` 是那份清单的机器可读版本。
+- **`agent-dispatch` 曾在这张表上，现在不在了。** 它的 `.ai.yaml` 已于 XSPEC-362 R5a 恢复、正常发布，而本指南在那之后仍把它列为已移除，跨了两个大版本。**你的 manifest 里若还有它，那是对的。**
+- 专案 `.standards/` 中既有副本不会被自动删除。请用 **`uds update --prune`**，不要手动删：
+  - `--prune` 会连同 `fileHashes` 里的记录一起移除。手动删只删掉文件，记录还在，`uds check` 会把每一个报成「遗失」并建议 `uds check --restore`——**而那个还原不可能成功**，因为上游已经没有来源了。
+  - **从 6.8.x 以前升上来之后的第一次 `uds update` 什么都不会删**，不论你加什么旗标：此时还没有文件归属记录，而 UDS 不会凭一笔不存在的记录删东西。先跑一次 `uds update`，再跑 `uds update --prune`。
+  - `--prune` 不会清 `integrationConfigs[<文件名>].installedStandards`。那份快照正是 `uds update --sync-refs` 重新生成时所依据的东西，所以残留在那里的项目仍可能把错的标准数写进你的 CLAUDE.md。`uds update --integrations-only` 则是从 manifest 重算。
 
 ## 3. 移除：4 个已弃用的 CLI 命令
 

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.9.0
-translation_version: 6.9.0
-last_synced: 2026-09-14
+source_version: 6.11.0
+translation_version: 6.11.0
+last_synced: 2026-09-18
 status: current
 ---
 
@@ -17,6 +17,53 @@ status: current
 
 ## [Unreleased]
 
+## [6.11.0] - 2026-09-18
+
+### 修正
+
+- **`uds update --plan`／`--apply` 對整合檔永遠不會收斂：即使剛跑完 `--apply`、檔案內容與產生器會產生的內容逐位元組相同，仍會顯示 `Migrate Block: N`。** `diffIntegrations` 對任何帶有 UDS 標記的整合檔都無條件產生 `migrate_block` 動作——「我們一律更新整合檔，因為內容是動態產生的」——因為 desired state 從未帶有可比對的雜湊（`hash: null`，註解說「產生後才計算」，但從未真的算過）。desired-state calculator 現在會用 `--apply` 自己會用的同一條路徑（`buildToolIntegrationConfig` ＋ `generateIntegrationContent`）產生整合檔內容，並只對 UDS 區塊算雜湊，讓 `diffIntegrations` 能像其他每個類別一樣分辨「內容已經相符」與「內容不同」，雜湊相符時回報 `unchanged` 而非 `migrate_block`。一份區塊真的過期的檔案（手動編輯過，或由舊版 CLI 產生）仍會照舊產生 `migrate_block`。產生失敗（例如 registry 解不出某個工具）時回退成修正前的無條件行為，不會讓計畫當掉。
+- **`uds check` 可能在同一次執行裡對同一個整合檔印出兩則互相矛盾的「已參考」宣告。** `standardsReferenced`（「{count}/{total} 項標準已參考」）掃描整個整合檔本文——標準名稱在任何地方被提到都算。`standardsNotReferenced`（「未參考的標準（選用）：」）只看結構化的 `Reference:`／`參考:` 行。一個標準在檔案散文中被提到、卻沒有列在任何 `Reference:` 行上，會在同一次執行裡同時滿足第一則宣告、又落在第二則宣告裡——同一個詞（「已參考」／「參考」），量測的是兩件不同的事，讀起來像矛盾。三語的第二則訊息都已改寫成精確描述它實際檢查的內容（沒有出現在 `Reference:`／`參考:` 行），取代原本籠統的「未參考」宣告。
+- **單純的 `uds update --plan` 與 `uds check` 從未提示 Skills 或 Commands 版本落後最新 UDS 釋出版。** 版本落後只由 `uds update --plan --skills`／`--plan --commands` 計算——一般的調和 `--plan`（不帶範圍旗標）呼叫的是另一個從未碰觸這件事的函式，`uds check` 則完全沒有對等的檢查。使用者跑純粹的 `--plan` 或 `check` 時，看到的是一份乾淨的報告，儘管 Skills 落後了一整個小版本，也沒有任何提示說帶範圍的 plan、或 `uds update --skills` 有事可做。兩者現在都會在任何已安裝的 Skills 或 Commands 版本落後時，印出簡短的「`<工具>`（`<位置>`）：v舊 → v新」提示，並附上修復指令。這比照既有的頂層「Version: X → Y ⚠」列，而非整合區塊完整性檢查（XSPEC-418 R1）：落後最新版是使用者更新前的常態，不是像 UDS 區塊被修改／遺失那樣的合規缺陷，因此不會讓 `uds check --ci` 失敗。
+- **6.10.0 的死連結修正（P2）把一則寫著 6.0.0 之前檔名的參考直接刪掉，而不是改寫它，還可能留下一個懸空的逗號。** `resolveStandardReferences` 比對一行 `Reference:` 的 stem 時只查 manifest 已安裝清單，從未查過 `STANDARD_ID_MAPPING`（conversion-rules.js）——這正是 `yaml-generator.js` 別處已在用、記錄「舊檔名 → 現行 id」的對照表。一行寫著舊檔名 `.standards/commit-message-guide.md` 而專案其實裝了 `commit-message` 的參考，看起來和一個專案刻意不裝、已停用的 UDS 標準一模一樣，於是被整行刪掉，而不是改寫成 `.standards/commit-message.ai.yaml`。另外，刪掉一項參考後的逗號清理只處理了尾端逗號、重複逗號、逗號前多餘空白，沒處理「一行裡第一項參考被刪掉、逗號緊貼在冒號後面」的狀況（`Reference:, .standards/other.ai.yaml`）。整段改寫成「拆項 → 解析或捨棄 → 重新 join」，取代在原地修補被刪字串周圍標點的作法。
+- **被 6.10.0 `resolveStandardReferences` 缺陷刪掉的主要標準參考，即使套用上面的修正也不會自己回來。** 把刪除動作留下的懸空逗號清掉，修好的只是那一行的標點，不是把被刪掉的項目帶回來——像「## 提交訊息標準」這樣的 UDS 範本段落活在 UDS 標記之外，一旦某一項被刪掉，就沒有任何東西會重新產生那段內容。針對這個特定情境新增一個範圍刻意收窄的自動補回機制：當一行的標題與某個 UDS 範本標題完全相同（`RULE_TEMPLATES` 出貨的任一語言版本），而且該範本的主要參考（它自己「`Reference:`」／「`參考:`」行上的第一個 `.standards/...` 項）不在檔案那一行裡，且該標準確實已安裝，就會把它補回該行最前面——行內其他內容（專案自有項目、options 檔、既有順序）原樣不動，不會補回任何次要範本項目，使用者自己寫的段落（任何其他標題）一律不碰。此修復是冪等的。只修復 6.10.0 那次刪除造成的問題，不嘗試修復由無關手動編輯造成的參考損壞。
+- **單純的 `uds update` 從未修復上面 Q1 缺陷留下的壞掉 `integrationConfigs[file].categories`——只有 `--sync-refs` 會。** 一份已經帶著 `categories: []`（來自較舊、有缺陷的 `--sync-refs` 執行）的 manifest，會在之後每一次單純的 `uds update --yes` 都維持壞掉：該指令自己的整合同步步驟會寫 `integrationBlockHashes`，卻完全不會讀取 `integrationConfigs`，所以沒有任何東西修正它——而下一次 `uds check --restore-missing` 就會用那份壞掉的儲存設定重建整合檔，再次悄悄漏掉段落。`uds update` 現在會用 `--sync-refs` 同樣的方式（`calculateCategoriesFromStandards`）修復空的或無法辨識的 `categories` 值，而已經有效的清單維持原樣不動，讓單純的 update 不會每次都變成完整的重新同步。
+- **`uds update --sync-refs`／`--integrations-only`／`uds check --migrate`／`uds config` 可能悄悄把 `manifest.version` 降版，同一條同步路徑還會在一份正常的 3.4.0 manifest 上算出空的分類集合。** 五個寫入點寫死了一個較舊的 schema 版本字面值（`'3.1.0'`／`'3.2.0'`／`'3.3.0'`），而不是 CLI 目前的 schema 版本（`3.4.0`）——對一份已經是最新版的 manifest 執行上述任一指令，都會把版本寫回舊的。另外，`calculateCategoriesFromStandards`（`--sync-refs` 用來決定 CLAUDE.md／AGENTS.md 該含哪些段落的函式）用檔名查每個標準，但 3.4.0 manifest 存的是純 stem（`commit-message`，而非 `commit-message.ai.yaml`）——每次查詢都落空，分類集合變成空的，下一次 `--sync-refs`（或 `--restore-missing` 重建）就會重新產生一份完全漏掉反幻覺／commit-message／code-review 段落的檔案。兩者現在都在同一個真實來源處修復：一個共用的 `bumpManifestVersion` 輔助函式，只會讓 manifest 版本朝最新前進，不會倒退；以及同檔案裡別處已在用、支援 stem 的分類查找（`categoryForStandard`）。這讓分類計算恢復成 `--sync-refs` 在 6.10.0 之前的算法——依實際已安裝的標準計算，而非固定清單——所以完整重新產生（`--sync-refs`、`--integrations-only`，或單純的 `uds update`）現在會寫出每一個有範本、且背後有已安裝標準的段落（目前 9 段），而不只是全新 `uds init` 播種的那 3 段；對一個已經有完整段落的專案做純區塊更新則不受影響。
+- **一句單純提到 UDS 標記文字的句子，可能被誤認成真正的區塊邊界，導致從那句話到真正 END 標記之間的所有內容——包含採用者自己的內容——都被刪除（v3.5.0–6.10.0）。** 每一個定位標記的呼叫點都直接用 `content.indexOf('<!-- UDS:STANDARDS:START -->')`／`.indexOf('...:END -->')`，這會比對到檔案中任何位置出現的標記文字：一句逐字引用標記語法來解釋它的句子（本專案自己的 CLAUDE.md 就是這樣做），或程式碼區塊裡含有它的範例，都和真正的邊界無從分辨。這影響了所有四條會重新產生整合檔 UDS 區塊的寫入路徑：`uds update --integrations-only`、`uds update --apply` 的 `migrate_block` reconciler 路徑、`uds update --sync-refs`，以及 `uds check --restore`（XSPEC-418 R6 讓它也會還原受損的 UDS 區塊）。標記現在只在（去除前後空白後）獨占一整行、且那一行不在 fenced code block（``` ／ ~~~）內時才算數；所有呼叫點現在都經過同一個共用的 `locateMarkerBlock` 輔助函式，並以靜態掃描守衛測試強制執行，避免未來的呼叫點又退回直接用 `indexOf`／`includes`。含有兩組真正標記對的檔案（損壞，或手動編輯出錯）不再被猜測——每條寫入路徑都會拒絕執行並列出兩個標記所在行號，`uds check` 也會明確回報這個狀態，不再併入「已修改」或「找不到標記」。
+- **`uds check --ci` 可能畫面上印出整合區塊的 ✗，結尾卻仍宣稱專案符合標準並以結束碼 0 收尾。** `checkIntegrationBlocksIntegrity` 的檢查結果（區塊被修改／遺失／UDS 標記被移除）算出來也印出來了，卻在最終判定被丟棄——判定只看標準檔完整性。若你的 CI 一直對某個 CLAUDE.md／GEMINI.md 等檔案的 UDS 區塊實際上已被移除或改動的專案顯示綠燈，那就是這個缺陷；`--ci` 現在會正確地失敗，直到區塊被復原（`uds update --integrations-only`）或專案以其他方式恢復同步為止。互動式 `uds check`（不加 `--ci`）不受影響——仍以結束碼 0 收尾，不中斷一般使用。（XSPEC-418 R1）
+- **整合檔（CLAUDE.md、CLAUDE.local.md、AGENTS.md 等）同時被整份內容與 UDS 區塊兩套雜湊追蹤，兩套檢查在同一次執行裡可能互相矛盾。** 全新 `uds init` 從不替這些檔案記錄整份雜湊，但 `uds update --integrations-only` 會——跑過一次之後，使用者在 UDS 區塊**外**的任何修改（正是 marker-based update 承諾保留的自訂內容）都會讓 `uds check --ci` 報 `CLAUDE.md（已修改）` 並結束碼 1，而同一次輸出裡自己的區塊完整性檢查卻說區塊完好。另外，`uds check --restore` 正確地重寫了損壞的區塊（保留區塊外內容，沒有資料遺失），卻只更新了整份雜湊，從未更新區塊雜湊——於是下一次 check 對一個才剛被正確還原的區塊報 `CLAUDE.md（UDS 區塊已修改）`。整合檔現在不再寫進 `fileHashes`（只寫進本來就只追蹤區塊的 `integrationBlockHashes`）——走訪了所有寫入點，不只原始回報的兩處，包含 `--apply`／`--plan` 的 reconciler 路徑與 `--sync-refs`；既有 manifest 裡這類檔案殘留的整份雜湊，會在下一次 `uds update`（或 `uds check --restore`／`--migrate`）時被移除，區塊雜湊保留。`uds check --restore` 還原整合檔後，現在會把區塊雜湊更新成實際寫入的內容。已用一份真實採用者的 manifest（恰好帶有這個殘留欄位）驗證：同一份輸入，修正前 `uds check --ci` 結束碼 1，修正後結束碼 0。後續複核另發現兩個缺口，一併修掉：`uds check --restore` 過去對受損的 UDS 區塊完全無作用——它靠的是 `fileStatus`，而那完全由 `fileHashes` 建構，已不含整合檔，於是它悄悄還原了 0 個檔案而區塊仍是壞的；`--restore` 現在也會還原被判定為「已修改」或「標記遺失」的區塊（不動區塊外內容，`--restore-missing` 行為不變）。另外，因為上面新增的清除邏輯只掛在寫入路徑，既有 manifest 裡殘留的整份雜湊若不曾跑過寫入，純 `check` 永遠沒有機會清掉它——標準檔完整性檢查現在也會在讀取時略過同時被 `integrationBlockHashes` 追蹤的鍵，讓未跑過 `update` 的既有專案也能回報乾淨。（XSPEC-418 R6）
+
+### 新增
+
+- **`uds init --claude-target <project|local>` 與 `uds update --claude-target <project|local>`：在已有團隊 `CLAUDE.md` 的 repo 裡個人採用 UDS。** 過去 UDS 的 Claude Code 整合一律寫入 `CLAUDE.md`——團隊共用、會進版控的檔案——沒有任何改寫目標的方式。在已有團隊 `CLAUDE.md` 的 repo 裡個人採用 UDS 的使用者，只能手動把 UDS 區塊搬到 `CLAUDE.local.md`（Claude Code 原生支援、緊接在 `CLAUDE.md` 之後讀入的檔案），而從那一刻起 `check`／`update`／`uninstall` 全都回報錯誤，或悄悄寫回團隊檔案——包含在例行孤兒清理中把搬移後檔案自己的雜湊當「孤兒」刪掉。
+  `uds init` 的 `--claude-target local` 從一開始就把整合內容寫進 `CLAUDE.local.md`；團隊的 `CLAUDE.md` 完全不會被動到。`uds update --claude-target <project|local>` 則讓**既有**安裝不必重裝就能切換目標：從舊檔移除 UDS 區塊（保留寫在裡面的其他內容；若舊檔在移除後只剩 UDS 內容則整個刪除，與 `uninstall` 既有規則一致）、寫入新目標、並更新 manifest，不論新目標是否已存在手動搬過去的區塊。`check`、`update`（含 `--integrations-only`／`--force`）與孤兒雜湊清理現在都經同一個函式解出工具的實際目標檔，不再各自假設預設值——從未使用 `--claude-target` 的專案完全不受影響：manifest 只有在選擇 `local` 時才會多出 `integrationTargets` 欄位。`--claude-target` 不影響 `AGENTS.md`；若不想讓它進版控，一樣要自己透過 `.git/info/exclude` 排除。UDS 不會自動把 `CLAUDE.local.md` 寫進 `.gitignore`——請自行加入——且因為它未受版控，只存在於建立它的那個 git worktree。詳見 [CLI-INIT-OPTIONS.md](docs/CLI-INIT-OPTIONS.md)（「Claude Code 整合目標檔」一節）。（XSPEC-418 R2–R4）
+
+## [6.10.0] - 2026-09-16
+
+### 修正
+
+- **`uds update --apply` 會忘掉它沒有動到的每一個斜線命令，而 `uds check` 說一切完整。** 一個裝有 51 個 OpenCode 命令的專案，三個檔案內容漂移：plan 列出那三個，`--apply` 之後 manifest 只剩三筆 `commandHashes`——另外 48 個檔案仍在磁碟上，卻沒有任何東西在追蹤它們。同一次 `uds check` 同時印出「Commands: 51 installed」與「✓ All command files intact (3 files)」，而竄改那 48 個之一，兩行都不會變（2026-09-16 於乾淨暫存專案在 6.9.0 上實測）。reconciler 在合併新雜湊前，會先刪掉該工具的所有雜湊鍵——只有在安裝器重裝了該工具全部命令時才正確，`uds update` 自己的呼叫點是如此，plan 這條路不是。現在改為合併，與 skills 路徑一直以來的做法相同；plan 標記刪除時，只移除該檔案那一筆。`uds check` 另外列出磁碟上沒有任何雜湊涵蓋的命令檔，兩個數字不再能各說各話。
+- **整合檔指向磁碟上不存在的標準，而參考檢查說它們同步。** 以 `--format ai` 安裝的專案，`uds update --integrations-only` 寫出 `Reference: .standards/anti-hallucination.md` 與 `.standards/checkin-standards.md`，這兩個檔案只存在於 `human` 格式。規則模板一律以 `.md` 書寫參考路徑，不看實際安裝格式；而規則段落位於 UDS 標記之外，標記式更新從不刷新它們——由舊版 CLI 首次寫出的檔案，在該檔案停止出貨兩個主版本之後，仍留著 `.standards/commit-message-guide.md`。現在無論是產生新檔或更新既有檔案，參考路徑都會對照這個專案實際安裝的標準與格式解析；指向未採用標準的參考會被移除，而不是留成死連結。`uds check` 改為回報「檔案不存在」的參考，而不是以去掉副檔名的名稱比對。只有 UDS 自己出貨的標準會被移除：專案自行放進 `.standards/` 的檔案，其參考原字不動。
+- **`uds check` 建議執行 `uds update --sync-refs`，而它跑不起來。** manifest 沒有 `integrationConfigs` 時 `--sync-refs` 直接中止，而這個鍵只有 `uds init` 的互動流程會寫入——以 `uds init -y` 建立的專案從第一天起就是 `{}`，所以一個全新的 6.9.0 專案，已經處在那段錯誤訊息歸咎於「舊版本、手動複製」的狀態。`--sync-refs` 現在會從 manifest（integrations、AI 工具、標準、選項）重建設定，而不是拒絕執行；`uds check` 只在它確實可執行時才提它，否則改指 `uds update --integrations-only`。
+- **`uds check` 把已採用的標準報成索引中缺少。** id 對檔名的表只從 `source.ai` 建立，但部分 registry 條目的 `source` 是字串——`zh-tw-locale` 是 `extensions/locales/zh-tw.md`——於是它安裝出的 `.standards/zh-tw.md` 從未被認出，在明明列出該檔的整合檔上顯示「67/68 項標準已參考，缺少：zh-tw-locale」。
+- **參考同步把選項檔報成孤兒，並建議 UDS 已不再出貨的檔名。** 選項記在 `manifest.options` 而非 `manifest.standards`，於是每個 `.standards/options/*.ai.yaml` 參考都被報成「未在 manifest 中」；而「未參考的標準」清單來自一張手寫的 6.0.0 之前檔名表（`git-workflow.md`、`error-code-standards.md`、`project-structure.md`）。現在選項會被認得，清單也只列出這個專案實際持有的檔案。
+- **`uds check` 把 `AGENTS.md` 列了兩次。** Codex 與 OpenCode 共用同一份檔案，而檢查是逐工具而非逐檔案進行。現在每個檔案只回報一次，並標明共用它的工具。
+- **七條 `core/*.md` 標準自 6.0.0 起就沒有被安裝過，而它們一個字都沒說（[#180](https://github.com/AsiaOstrich/universal-dev-standards/issues/180)）。** 它們的 `.ai.yaml` 在 6.0.0 被移除，文件則刻意留在 `core/` 當作採用層的參考——這個決定合理，也記在 `docs/MIGRATION-v6.md` §2 與 `scripts/reference-only-standards.json` 裡，但**沒有記在讀者真正會遇到它的地方**。遷移指南在升級時讀一次，`core/` 是持續被讀的：走訪它來回答「UDS 有哪些標準」的人或 agent 會數到 152 份，其中七份 `uds init` 從未安裝過。七份現在都在開頭帶一段 `<!-- UDS:REFERENCE-ONLY -->` 告示，英文、繁中、簡中三份都有，並指向遷移紀錄與那份機器可讀清單。新閘門（`npm run check:reference-only`，已接進 CI 並附兩臂自測）從 registry 裡每一條 `source.human` 現算出貨面，把它與 `core/*.md` 的差集當成 reference-only 集合，要求每一份都要揭露——**反過來也要求有在出貨的文件不得帶著這段告示**，所以一條重新開始出貨的標準不會留下一句謊話。用現算而不是比對那七個名字，是為了讓下一次縮減範圍不會重演同一種沉默。
+- **`--format human` 的安裝把 `testing-standards.md` 掛在兩個標準 id 底下送出，而全覆蓋那一份從來沒送到。** `full-coverage-testing` 的 registry 條目把 `source.human` 指到 `core/testing-standards.md`，於是 `core/full-coverage-testing.md`——一條活著的標準，最近一次維護是 XSPEC-288——沒有任何人裝得到，而 human 格式的 manifest 裡同一條路徑出現兩次。`check-registry-completeness.ts` 的 Check 2 看不到它：那支只要 human 或 ai 任一條路徑出現在 registry 文字裡就算通過，而 ai 那條在。由上面那支閘門首跑時抓到，是七份預期之外的第八份。修正前後各跑一次真正的 `uds init --format human` 驗證。
+- **`uds update --sync-refs` 寫進去的標準數，`uds check` 當場否認。** manifest 有 73 條標準的專案，`--sync-refs` 把 CLAUDE.md 改成宣告 76 條，`uds check` 隨即回「索引宣告 76 條標準，manifest 實際有 73 條」；而 `--integrations-only` 算得出正確數字，於是它看起來像計數錯誤，其實是**來源錯誤**。`--sync-refs` 是從 `integrationConfigs[檔名]` 重新產生的，那裡面的 `installedStandards` 是安裝當時的快照、**沒有任何路徑會更新它**——跨大版本升級過的專案，它仍列著 6.0.0 就停止出貨的標準，而它列什麼，檔案內容就是什麼。現在改為從 manifest 重新產生，正如 `buildToolIntegrationConfig` 自己的註解一直寫著的那樣；舊快照只剩 `outputLanguage` 還有發言權，避免一個早於該選項的 manifest 把使用者的選擇悄悄重設。
+- **已安裝標準索引在每個專案都寫「options 0」。** `uds init` 把安裝清單縮成純檔名，而下游一律以 `/options/` 這個路徑片段判斷選項——在 `contentLayout: flat` 底下根本沒有目錄可以還原它。一個有 66 條核心標準與 7 個選項的專案，被告知自己有「73 條（core 73、options 0）」。同一個縮減也讓 AGENTS.md 裡每個選項檔都被寫成 `.standards/<名稱>.ai.yaml`，比選項實際安裝的位置高一層，於是每一條都是死連結——而它們就列在一句「你必須讀這些標準」底下。現在路徑完整傳遞，AGENTS.md 的選項寫在 `.standards/options/`，並且依專案實際格式而非一律假設 `ai`（`--format human` 的專案先前拿到的是一串 `.ai.yaml` 檔名，而它手上是 `.md`）。
+- **照著遷移指南做，會讓 `uds check` 報錯，而它給的解法不可能成功。** MIGRATION-v6 §2 說要手動刪掉七個已降級的 `.ai.yaml`。刪掉之後 `fileHashes` 紀錄還在，`uds check` 於是把七個檔案報成遺失並建議 `uds check --restore`，而那個還原在每一個檔案上都失敗（「無法判斷來源」）——上游自 6.0.0 起就沒有來源了。**工具要求採用者推翻它自己的文件，用的還是一個它已經知道跑不動的指令。** 現在，一個 UDS 已不再出貨的檔案不見了，會與真正的遺失分開回報、用灰色、並給出真的有用的解法；`uds update` 會清掉那些紀錄並逐筆說出清了什麼，**包含已經在最新版的專案**——照指南做過的人必然都在那個狀態。`--prune` 碰不到它們：它刪的是走訪 `.standards/` 時找得到的檔案，而這些正是已經不在那裡的。
+- **UDS 重新產生了 AGENTS.md，卻沒有記下自己寫了什麼。** `uds update --integrations-only` 之後緊接著 `uds check`，會在一個只有 UDS 動過的檔案上報 `AGENTS.md（已修改）`。三個寫 AGENTS.md 的呼叫點都記了 `integrationBlockHashes`，沒有一個記 `fileHashes`。現在已存在的紀錄會被更新；manifest 沒在追蹤的檔案仍然不會被納入追蹤——那份摘要本來就是給採用者擴寫的。
+- **在 Windows PowerShell 上，跑成功看起來像失敗。** 進度訊息走 stderr，而 PowerShell 5.1 會把原生指令的任何 stderr 輸出包成 `NativeCommandError`——**包括 `✔ 已重新產生 2 個整合檔案` 這句報告成功的話**。改動前實測：stdout 9 行、stderr 2 行，兩行都是 spinner。47 個 spinner 現在一律寫 stdout，成功的一趟 stderr 是空的。
+- **刪除計畫用同一句話解釋三種完全不同的情況。** 「no longer in desired state」同時被印給「上游已移除的標準」「專案自己取消選取的選項」「desired state 根本沒有模型化的路徑」——三種情況的正確反應各不相同。現在理由會說出是哪一種，以及重新選取能不能把檔案救回來。`.standards/release-config.yaml` 則完全不再是刪除候選：它是 `uds init` 依使用者挑的發版模式寫出、`uds config` 會改寫的檔案，刪掉它是在丟掉一個設定卻自稱在對帳。它被保留，而且理由會被印出來，不是默默跳過。
+- **一個 .NET Framework 專案拿到四個指令，其中三個跑不動。** `.csproj` 自 2017 年起同時指涉兩套互不相容的建置系統，而偵測只看副檔名：舊式專案（`<TargetFrameworkVersion>`、沒有 `Sdk` 屬性）拿到 `dotnet build`（以 `MSB4019` 失敗）與 `dotnet list package --vulnerable`（對 `packages.config` 專案靜靜地什麼都不報，因為它只讀 `PackageReference`）。舊式專案現在 `build` 給 `msbuild`，其餘留白——未知生態那一支本來就回傳空字串「讓使用者自己填」，而**一個人類會補完的空格，勝過一個看起來很權威、第一次執行就失敗的指令**。
+- **每一份生成的指示檔，開頭都叫 AI 去讀一個永遠不會被安裝的目錄。** 九個工具、每種語言，全都以「**優先**讀取 `core/` 中的精簡規則（例如 `core/testing-standards.md`）」開場。`uds init` 安裝到 `.standards/`，從來沒有在採用者的專案裡建立過 `core/`——那是標準在 UDS repo 裡的位置，不是在採用它的 repo 裡。同樣兩句話有 36 份副本、錯法一模一樣，而且乾淨的 6.9.0 安裝就會寫出它們。現在它們指向 `.standards/`，並有一支測試走訪生成結果，讓第十個工具沒辦法把它重新帶回來。
+- **`uds update` 把中文的 CLAUDE.md 改寫成英文。** `uds init` 依 `display_language` 產生整合檔內容，而每一條重新產生的路徑都是從 `output_language`（commit 訊息語言，預設 `english`）推導的。現在內容語言依 `display_language`，只有在沒有顯示語言設定可依據時才退回 `output_language`。
+
+
+### 新增
+
+- **`uds check` 現在會報出指示檔裡提到、但實際不存在的路徑。** 先前它只讀 `Reference:`／`參考:` 開頭的行、而且只看 `.standards/` 路徑——對「參考同步」而言那是正確的範圍（那些行是 UDS 自己生成的），對「這條指示有沒有指到東西」而言則是錯的範圍。UDS 標記之外、由舊版安裝留下、之後沒有任何重新產生會回頭看的散文，把 agent 指向不存在的檔案。這支掃描以**檔案存不存在**為準而非以路徑長相為準，所以一個真的有自己 `core/` 目錄的專案不會被冤枉，網址裡的路徑也會被排除。它首跑就找到了本次修正中的兩項缺陷。
+
 ## [6.9.0] - 2026-09-14
 
 ### 採用者升級注意