universal-dev-standards 6.14.0-beta.2 → 6.14.0-beta.4

package/bundled/locales/zh-CN/skills/comprehension-ladder/eval-cases.md

@@ -0,0 +1,261 @@
+---
+source: ../../../../skills/comprehension-ladder/eval-cases.md
+source_version: 1.0.0
+translation_version: 1.0.0
+last_synced: 2026-10-05
+source_hash: a2b33f2ef215
+status: current
+scope: universal
+description: |
+  理解阶梯技能的评估案例与跑法：5 段原文，各附理解题、标准答案与防护违反检查。尚未实跑。
+  Use when: 想衡量理解阶梯技能是否帮得上读者，或想重新检查它的三条防护。
+  Keywords: evaluation, eval cases, comprehension questions, answer key, guard violations, DEC-114.
+---
+
+# 理解阶梯：评估案例
+
+> **语言**: [English](../../../../skills/comprehension-ladder/eval-cases.md) | [繁體中文](../../../zh-TW/skills/comprehension-ladder/eval-cases.md) | 简体中文
+
+**状态：尚未实跑。** 本文件只有案例与跑法。没有调用过任何模型，也没有任何读者作过答。实跑完成之前，不要说本技能让文字比较好懂。
+
+下面五段原文都是为这次评估写的。它们不描述任何真实的客户、人物或系统。
+
+## 实跑会产出什么
+
+一次实跑产出两个数字：
+
+1. **前后的答对率。** 读者看原文时（A 组，「之前」）与看技能产出时（B 组，「之后」），答对题目的比例。
+2. **防护违反次数。** 技能的产出破坏 G1、G2 或 G3 的次数。
+
+建议的通过线，实跑前要与负责人谈定：B 组比 A 组高至少 10 个百分点，而且防护违反次数为 0。10 个百分点只是起始值，还没有校准过。
+
+## 跑法
+
+### 1. 产出
+
+每个案例都对原文跑一次技能。要求第 1 阶与第 2 阶。存下大纲与两阶的产出。若也要测第 3 阶，就要求它并存下 HTML 文件。
+
+五个案例使用同一个模型、同样的设置。记下模型名称。
+
+### 2. 分读者
+
+至少用 6 位读者。读者可以是人，也可以是模型。人给出的证据比较强。模型是比较便宜的替身。
+
+把读者分成人数相同的两组。
+
+| 案例 | 第 1 组读 | 第 2 组读 |
+|------|-----------|-----------|
+| 1 | A（原文） | B（技能产出） |
+| 2 | B | A |
+| 3 | A | B |
+| 4 | B | A |
+| 5 | A | B |
+
+每位读者每个案例只看一次。这样读者不会在一组学到答案，再带到另一组。
+
+B 组的读者只看技能产出，不看原文。
+
+### 3. 问题
+
+把该案例的题目交给每位读者。读者只能依手上拿到的文字作答，不得用任何其他来源。
+
+读者可以答「文字没有说」。对标为**未提及**的题目，这是正确答案。
+
+### 4. 评分
+
+依下面的标准答案评分。答案要符合「采计」栏才算对。标为**不确定语气**的题目，若答案把说法讲成确定，即使事实对了也算错。
+
+答对率 = 答对的题数 ÷ 全部答案数，各组分开算。
+
+### 5. 计算防护违反
+
+对照原文，检查每一份产出。下列情形，每一项各算一次。
+
+| 防护 | 一次违反是 |
+|------|------------|
+| G1 `no-new-facts` | 某一项或某一句，说了原文没说的事。每个案例的「陷阱」清单列出最可能的几种。 |
+| G2 `keep-hedges` | 原文的说法有不确定语气，产出的那一项却没有，或语气变得更强。每个案例的「不确定用词清单」列出这些用词。 |
+| G3 `trace-and-gaps` | 某一项没有「对应原文」、指到的位置不是它所宣称的位置，或没有「没涵盖」注记。另外：产出没有「这份大纲没有收的部分」清单。 |
+
+请第二个人也数同一批产出，再比对两份计数。不同时，逐项讨论，记下最后的计数。
+
+### 6. 回报
+
+填这张表。两个数字都要有。
+
+| 案例 | A 组答对 | B 组答对 | G1 | G2 | G3 |
+|------|----------|----------|----|----|----|
+| 1 | / | / | | | |
+| 2 | / | / | | | |
+| 3 | / | / | | | |
+| 4 | / | / | | | |
+| 5 | / | / | | | |
+| **合计** | **A 组答对率** | **B 组答对率** | | | |
+
+### 实跑规模
+
+说明实跑的规模，让负责人在开跑前决定模型与预算：
+
+- 产出步骤：5 次技能运行，加 5 次防护检查。共 10 次模型调用。
+- 读者步骤，若读者是模型：5 个案例 × 2 组 × 每组读者数。
+- 题目很短。最长的输入是一段原文或一份产出。
+
+模型与预算由负责人决定。这里不设置。
+
+---
+
+## 案例 1：搜索结果过期
+
+**类型**：含多处不确定语气的事件记录。
+
+### 原文
+
+> 昨晚商品目录导入之后，搜索页约有 3 小时显示旧的商品名称。最可能的原因是，导入之后搜索索引没有重建。我们认为导入工作先结束，重建步骤才排进队列，但我们还没有检查工作记录。顾客仍然可以购买那些商品。团队计划在星期四，替导入工作加上重建步骤，前提是记录证实了事件的先后顺序。没有人量过有多少顾客看到旧名称。
+
+### 问题与标准答案
+
+| # | 问题 | 类型 | 采计 |
+|---|------|------|------|
+| 1 | 搜索页显示旧名称的时间有多久？ | 事实 | 约 3 小时 |
+| 2 | 最可能的原因是什么？已经确认了吗？ | 不确定语气 | 导入之后索引没有重建。尚未确认：「最可能」 |
+| 3 | 工作记录检查过了吗？ | 事实 | 没有。还没有 |
+| 4 | 问题发生期间，顾客还能购买商品吗？ | 事实 | 能 |
+| 5 | 修复计划在什么时候？它取决于什么？ | 事实 | 星期四。取决于记录是否证实事件的先后顺序 |
+| 6 | 有多少顾客看到旧名称？ | 未提及 | 文字没有说。没有人量过 |
+
+### 不确定用词清单
+
+「约 3 小时」、「最可能」、「我们认为」、「还没有检查」、「前提是记录证实」、「没有人量过」。
+
+### 陷阱（原文没说的事实）
+
+受影响顾客的人数。原因已确认的说法。记录显示了事件先后顺序的说法。任何退款、营收或客服单的数字。
+
+---
+
+## 案例 2：退款核准流程
+
+**类型**：有分支的流程（适合第 2 阶）。
+
+### 原文
+
+> 顾客在 App 里申请退款。系统检查订单日期。订单超过 30 天，系统立刻驳回申请，并向顾客显示一条消息。订单在 30 天以内（含 30 天），系统把申请送给客服人员。客服人员在 2 个工作日内核准或驳回。客服人员核准后，系统把钱退回原付款方式，并发送电子邮件给顾客。超过 NT$5,000 的退款，还需要组长第二次核准。规格没有说组长要在多久内回复。
+
+### 问题与标准答案
+
+| # | 问题 | 类型 | 采计 |
+|---|------|------|------|
+| 1 | 45 天前的订单申请退款，会怎么处理？ | 事实 | 立刻驳回。顾客会看到一条消息 |
+| 2 | 刚好 30 天的订单申请退款，会怎么处理？ | 事实 | 送给客服人员（「30 天以内（含 30 天）」） |
+| 3 | 客服人员有多久可以决定？ | 事实 | 2 个工作日 |
+| 4 | 核准之后，钱退到哪里？ | 事实 | 原付款方式。顾客还会收到电子邮件 |
+| 5 | 哪些退款需要第二次核准？由谁核准？ | 事实 | 超过 NT$5,000 的退款。由组长 |
+| 6 | 组长要在多久内回复？ | 未提及 | 文字没有说 |
+
+### 不确定用词清单
+
+主张里没有不确定用词。文字明说了一个缺口：「规格没有说组长要在多久内回复。」产出必须保留这个缺口。
+
+### 陷阱
+
+组长的时限。消息的内容。刚好 NT$5,000 的退款规则。检查顾客历史记录的步骤。
+
+### 预期规模
+
+原文有 7 个 `mechanism` 项目（申请、日期检查、驳回、分流、客服决定、付款与电子邮件、组长核准），以及 1 个 `uncertainty` 项目（组长缺少时限）。每一阶都应该呈现同样的 8 项，或列出没有画的项目。
+
+---
+
+## 案例 3：重试函数
+
+**类型**：含数字与两处不确定说法的代码解说。
+
+### 原文
+
+> 函数 `fetchWithRetry` 最多调用付款 API 4 次。第一次调用立刻发生。调用失败后，它会先等一会儿，再做下一次。等待从 200 ms 开始，每次加倍，所以等待时间是 200 ms、400 ms 和 800 ms。它只在网络错误与 HTTP 状态 503 时重试。遇到其他状态，例如 400，它就停止并返回错误。4 次调用全部失败时，它抛出最后一个错误。程序没有加入随机抖动，所以许多同时失败的客户端可能会同时重试。我们还没有测试 API 返回状态 429 时会发生什么事。
+
+### 问题与标准答案
+
+| # | 问题 | 类型 | 采计 |
+|---|------|------|------|
+| 1 | 这个函数最多调用几次？ | 事实 | 4 次 |
+| 2 | 调用之间的等待时间是多少？ | 事实 | 200 ms、400 ms、800 ms |
+| 3 | 哪些失败会重试？ | 事实 | 网络错误与 HTTP 状态 503 |
+| 4 | 遇到状态 400 会怎样？ | 事实 | 停止并返回错误 |
+| 5 | 程序没有加入抖动。接下来可能发生什么？ | 不确定语气 | 许多同时失败的客户端可能会同时重试。这是一种可能，不是必然 |
+| 6 | 遇到状态 429 会怎样？ | 未提及 | 不知道。还没有测试过 |
+
+### 不确定用词清单
+
+「可能会同时重试」、「我们还没有测试」。
+
+### 陷阱
+
+状态 429 的行为（重试或不重试）。客户端确实会同时重试的说法。原文没有给的等待总时间上限。API 的名称。
+
+---
+
+## 案例 4：上传文件要存在哪里
+
+**类型**：三个选项与取舍（适合第 2 阶）。
+
+### 原文
+
+> 我们比较了三种存储用户上传文件的方式。选项 A：把文件放在应用服务器的磁盘上。它最便宜，也不需要新工具。但服务器一换，文件就会丢失，而且两台服务器无法共享文件。选项 B：使用云服务商的对象存储。以目前的量来说，费用约为每月 NT$600。更换服务器后文件仍在，任何一台服务器都能读取。它需要一次性的访问密钥设置。选项 C：使用网络文件共享。服务器之间可以共享文件，也不需要改程序。但它多出一台要维护的机器，而且我们认为，在高负载下它会比较慢。我们建议选项 B。我们还没有测试选项 C 的速度。
+
+### 问题与标准答案
+
+| # | 问题 | 类型 | 采计 |
+|---|------|------|------|
+| 1 | 文字说哪个选项在更换服务器后文件仍在？ | 事实 | 选项 B。（文字说选项 A 不会。对选项 C，文字没有说。） |
+| 2 | 选项 B 的费用是多少？ | 事实 | 以目前的量来说，约每月 NT$600 |
+| 3 | 哪个选项不需要改程序？ | 事实 | 选项 C |
+| 4 | 团队建议哪个选项？ | 事实 | 选项 B |
+| 5 | 在高负载下，选项 C 比较慢吗？ | 不确定语气 | 团队认为是，但还没有测试过 |
+| 6 | 选项 C 的费用是多少？ | 未提及 | 文字没有说 |
+
+### 不确定用词清单
+
+「约 NT$600」、「我们认为它会比较慢」、「我们还没有测试」。
+
+### 陷阱
+
+选项 A 或选项 C 的费用。选项 C 在更换服务器后文件仍在的说法。没有带不确定语气、就说选项 C 比较慢。原文没有给的建议理由。
+
+---
+
+## 案例 5：访问记录里的会话令牌
+
+**类型**：含未知事项与尚未评级风险的安全发现。
+
+### 原文
+
+> 审查 API 网关时，我们发现访问记录可能含有会话令牌。客户端把令牌放在网址的查询字符串、而不是放在请求头时，令牌就会出现在记录里。移动 App 2.3 版在个人资料页面这样做。网页客户端使用请求头，不受影响。记录保存 90 天，有 12 位工程师可以读取。我们没有找到有人使用过被记下的令牌的证据。风险大概是中等，但我们还没有正式评级。我们提出两项修改：移动 App 把令牌改放请求头，以及在记录中遮蔽查询字符串。我们还不知道有多少用户在用 App 2.3 版。
+
+### 问题与标准答案
+
+| # | 问题 | 类型 | 采计 |
+|---|------|------|------|
+| 1 | 令牌什么时候会出现在记录里？ | 事实 | 客户端把它放在网址的查询字符串、而不是请求头时 |
+| 2 | 哪些客户端受影响？ | 事实 | 移动 App 2.3 版，在个人资料页面。网页客户端不受影响 |
+| 3 | 记录保存多久？谁能读？ | 事实 | 90 天。12 位工程师 |
+| 4 | 有没有人被证实滥用被记下的令牌？ | 不确定语气 | 没有找到证据。这不等于「没有人这样做」 |
+| 5 | 风险有多严重？ | 不确定语气 | 大概是中等。尚未正式评级 |
+| 6 | 有多少用户在用 App 2.3 版？ | 未提及 | 还不知道 |
+
+### 不确定用词清单
+
+「可能含有」、「没有找到……证据」、「大概是中等」、「还没有正式评级」、「还不知道」。
+
+### 陷阱
+
+受影响用户的人数。没有任何令牌被滥用的说法。正式的风险等级（例如「高」或「中」）。修复日期。网页客户端有风险的说法。
+
+---
+
+## 实跑之后
+
+- 记下日期、模型名称、读者人数，以及谁计算防护违反。
+- 把填好的回报表放在本文件旁边。不要覆写案例。
+- 防护违反次数大于 0 时，先修技能，再去解读答对率。加了事实或拿掉不确定语气的产出，可能拉高答对率，却仍然误导读者。
+- 某段原文被发现有歧义时，把原文与答案一起修正，再重跑那个案例。

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.14.0-beta.2
-translation_version: 6.14.0-beta.2
-last_synced: 2026-09-30
+source_version: 6.14.0-beta.4
+translation_version: 6.14.0-beta.4
+last_synced: 2026-10-06
 status: current
 ---
 
@@ -17,6 +17,47 @@ status: current
 
 ## [Unreleased]
 
+## [6.14.0-beta.4] - 2026-10-06
+
+> **測試版**——以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、如何退回正式版：[docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+>
+> **行為改變：**`uds check --standard checkin-standards` 在 lint 或測試失敗時會失敗；非 Node 專案的原生 pre-commit hook 現在擋得住提交。見下方 Fixed 的相關條目。
+
+### 修正
+- **`extensions/` 現在放進 npm 套件，`uds init`、`uds update` 與 reconciler 只從套件內安裝擴充檔——三者都不再從 GitHub 下載。** 6.13.1 版套件裡 `extensions/` 底下的 7 個檔（語言風格規範、框架模式、繁中與簡中語系包）一個都沒有，所以 `uds init --lang csharp`、`--lang php`、`--framework fat-free`、`--locale zh-tw`／`zh-cn` 安裝時是去 GitHub `main` 下載。後果有兩個：離線或公司內網裝不了這些擴充；而且拿到的是 `main` 當天的內容，不是你所裝版本對應的那個檔。同一個備援也把缺少的 `zh-cn.md` 藏了好幾個月。現在 `cli/scripts/prepack.mjs` 會把整個目錄打包；套件內容一致性檢查會逐檔、逐位元比對 `extensions/` 與套件（以前只比對 `.ai.yaml` 標準，所以一個擴充檔都沒有的套件也會顯示「bundle parity holds」）；宣告的擴充檔若不在套件內，安裝會**失敗並點名該檔**——不下載、也不靜默略過。**誰會看到差別：**從 npm 安裝的人多拿到 7 個檔（約 152 KB），且這些檔不再發出任何網路請求；`uds update` 也從套件內更新 `manifest.extensions` 的項目。**沒有改的：**其他在本機缺檔時仍會嘗試 GitHub 的地方（標準、選項、整合檔、技能），以及 `uds check --diff`——它仍會從 GitHub `main` 抓任何追蹤檔（含擴充檔）的原稿來比對。這份清單列在規格裡，本次不動。新增的測試會執行 `npm pack`、把壓縮檔裝進拋棄式目錄、封鎖並記錄網路，對已安裝套件宣告的每一個擴充選項執行 `uds init`，再逐位元讀回每個已安裝的檔；第二支測試從套件移除一個宣告的檔，要求安裝以該檔的名稱失敗，且沒有任何下載嘗試。落實 dev-platform XSPEC-452 的 R1、R2、R3。
+- **`uds init --locale` 不分大小寫，且不支援的語系會明說**：`--locale zh-CN` 以前會安裝英文並回報成功，現在會裝簡體中文。不支援的值（例如 `fr`）仍改用英文安裝，但會印出警告，不再靜默。（dev-platform XSPEC-451 後續）
+
+- **行為改變——`uds check --standard checkin-standards` 在你的 lint 或測試失敗時現在會失敗；它以前會說「通過」。** 該驗證器原本是 `(npm test --if-present || echo "No test script")`。`--if-present` 本來就處理「沒有測試腳本」的情況；`|| echo` 因此只做了一件事：把失敗的 `npm test` 或 `npm run lint` 變成 exit 0。UDS 自己的 `test-governance` 標準要求閘門 fail-closed，它自己出貨的檢查卻沒做到。現在：lint 或測試腳本失敗會回非 0，並指出是哪一個（`FAILED: npm run test exited with 1`，後面接該腳本自己的輸出）；真的沒有該腳本不算失敗，並且**只有這時**才印 `No lint script`／`No test script`；`npm init` 為 `test` 寫的預設佔位（`echo "Error: no test specified" && exit 1`）視為沒有；沒有 `package.json` 的專案通過，並印出 lint 與測試**沒有**被執行；`package.json` 存在卻無法解析會失敗，不會被當成「沒有腳本」。缺 `CHANGELOG.md` 仍只是提示。**誰會看到差別：**pre-commit hook 執行 `check --standard checkin-standards` 的專案（UDS 在 2026-02-04 至 2026-03-04 寫的 hook，`uds update` 會把它保留成區塊的參數），以及在 CI 或腳本裡執行該指令的人。過去帶著失敗的測試也能提交成功的 commit，現在會被擋下——這正是目的。**怎麼處理：**執行 `npm test`／`npm run lint`，修掉它們回報的問題。沒有測試的專案不受影響。全新的 `uds init` 所寫的 hook 執行的是不帶參數的 `uds check`，它不評估這個驗證器；它該不該評估是另一個決定，本次不變。驗證器現在會執行 `node`，凡是在跑 `uds` CLI 的專案本來就有。
+- **`pipeline-security-gates` 驗證器不再在沒有任何 pipeline 提到安全閘門時通過。**它把 `grep` 接到 `head -1`，再以 `|| echo 'no-ci-pipeline'` 兜底；`head` 永遠回 0，所以兜底從不執行，這個檢查不可能失敗。現在改用 `grep -q`，除非 `.github/workflows/`、`.gitlab-ci.yml` 或 `Jenkinsfile` 提到 `secrets`、`sast`、`sca` 或 `dast`，否則回非 0。只有 `uds check --standard pipeline-security-gates` 會執行它。
+- **`uds init` 為非 Node 專案寫的原生 `.git/hooks/pre-commit` 現在真的能擋下 commit。**它原本把每個 linter 都寫成 `... 2>/dev/null || true`，把 `uds check 2>/dev/null || true` 也是，最後印出「Pre-commit checks passed」——什麼都擋不了，還把自己的錯誤藏起來。現在：已安裝的 linter（`ruff`、`go vet`、`cargo clippy`）失敗會擋下 commit，沒安裝的 linter 則略過；UDS 檢查改用與 husky hook 相同的標記區塊，所以它的結束碼會擋下 commit，而找不到 `universal-dev-standards` CLI 時會說明如何安裝並擋下，不再靜默略過。`uds uninstall` 會整段移除該區塊，連你改過的腳本也一樣。**磁碟上既有的 hook 維持原樣**——UDS 無法證明一個被改過的檔案是自己寫的，這一項也沒有隨本次變更附上遷移。
+- **`uds init --locale zh-cn` 現在可用。它以前會失敗並把整個安裝回滾。** 安裝程式宣告了 `zh-cn`，並會複製 `extensions/locales/zh-cn.md`，但這個檔案不存在（只有 `zh-tw.md`），所以安裝以 `extensions/locales/zh-cn.md: File not available` 收場，並移除它裝過的所有東西——沒有人能用簡體中文安裝 UDS，而且沒有任何測試用簡體中文跑過安裝，所以一直壞著。現在這個檔案存在了：它是以大陸通行術語寫成的簡體中文語系包（不是把繁體版逐字轉換——它的術語表寫「Performance → 性能」，繁體版寫的正好相反）。它以 `zh-cn-locale` 登錄在 `zh-tw-locale` 旁邊。新增的測試對安裝程式宣告的每一個語系實際執行真正的 `uds init`（清單從安裝程式讀出，不寫在測試裡），並讀回語系包、manifest 與已安裝的技能；有語系宣告了卻沒有對應檔，測試就會變紅並指出是哪個語系。理解階梯的安裝測試現在也讓 zh-CN 走 `uds init`。**npm 安裝的注意事項：**寫下這一條時 `extensions/` 不在 npm 套件裡，語系包是安裝時從 GitHub（`main`）下載的；現在它已放進套件（見上方 `extensions/` 那一條）。落實 dev-platform XSPEC-451 的 R1、R2。
+
+### 新增
+
+- **`ai-response-navigation` 1.3.0 → 1.4.0——R12 受控語言，其中一條為必須。** 把文字簡化會讓它更好讀，而最好讀的句子是肯定的句子，所以「簡化」會朝肯定的方向漂移：「可能」變成「是」。R12 把答案分成兩半。**12.1 屬必須**：為非原作者的讀者縮短、簡化、改寫或翻譯文字時，要保留寫作者的不確定語氣（might、could、probably、可能、推斷、尚未確認），不可把不確定的論斷改成確定的，也不可加入原文沒說的事實。只有這一部分的失敗會讓讀者相信不真實的事，而且不需要校準：檢查就是拿改寫前後比對，任何語言都做得到。**12.2 屬選用**，理由已寫進標準：以該語言自己的單位計句長（起始範圍，依語言校準）、同物同名、主動語態、一步一動作、少用分號、數字帶單位。R10 現在指向 R12。
+  - **不附英文詞典，並在標準裡明說。** 這些原則取自 ASD-STE100，但它的核可字表與時態限制依賴英文，不適用於中文或其他非英文文字。標準只取原則、不附任何字表，並警告：以空白斷詞的計數器會把一整段中文看成一個詞，永遠通過。
+  - **一組中文範例**：同一段文字的原文、約 80%、嚴格三個版本，全部保留不確定語氣，外加第四個更短卻錯誤的改寫（把「可能」改成直接陳述的原因、把「尚未重現」改成「已確認」）。同步 zh-TW 與 zh-CN、兩份 `.ai.yaml`，以及一支讀取實際出貨檔案的測試——必須條款被削弱或刪除時它會變紅。
+- **新增技能 `comprehension-ladder`（`/comprehend`）1.0.0 — 把一段難懂的 AI 輸出換成較好懂的形式，而且不改變事實。** 技能先從原文建立一份大綱，再從大綱做出最多三階：受控文字、Mermaid 圖、單檔 HTML 解說頁（可離線開啟，不從網路載入任何東西）。沒有影片階。**三條防護為必須**，各附正例與反例：不加原文沒有的事實、保留每一個不確定語氣（「可能」仍是「可能」）、每一項都附對應原文的位置與「沒涵蓋」註記。技能本身依 [ai-response-navigation](../../core/ai-response-navigation.md) 第 12 條（受控語言）寫成，防護 G2 就是 12.1 條。
+  - **尚未證明有幫助。** `skills/comprehension-ladder/eval-cases.md` 有 5 段為此撰寫的原文，各附理解題與標準答案，並附一套跑法，會產出兩個數字：前後的答對率，以及防護違反次數。實跑需要模型呼叫，目前還沒做。做完之前，技能不宣稱有效。
+  - 提供 `zh-TW` 與 `zh-CN` 版本，並登錄於 registry、manifest、`llms.txt` 與技能索引。有一支測試會在拋棄式專案裡執行真正的 `uds init`，讀回安裝後的技能：三條防護都在、且標為必須，HTML 階禁止外部資源，也沒有影片階。
+
+## [6.14.0-beta.3] - 2026-09-30
+
+> **測試版**——以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、如何退回正式版：[docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+>
+> **既有採用者：請執行一次 `uds update`。**舊版 `uds init` 寫進 pre-commit hook 的是單行 `npx uds check`，它可能請 npm 去拿一個叫 `uds`、但不是本專案的套件。新安裝不再寫這一行，而 `uds update` 會替換既有 `.husky/pre-commit` 裡 UDS 自己寫的那一行。另外：`uds uninstall` 只移除能證明是 UDS 寫的東西（早期 UDS 安裝的專案會保留一部分檔案並說明原因），`uds open-work next-action` 讀得懂寫成表格欄的下一步。
+
+### 變更
+
+- **`uds open-work next-action` 現在讀得懂寫成 Markdown 表格欄的「下一步」，不再只認小節標題與行內標籤。** 表頭在「下一步」詞彙內的欄（`Next action`、`Next step`、`下一步`、`下一動`，以及新加的 `回來要做什麼`）每一列都會被讀，回報帶行號與該列第一格內容，方便定位。詞彙仍然只有一份：標題、行內標籤與表頭都讀同一份。放在引用區塊（`> | … |`）裡的表格現在看得見；程式碼片段內或反斜線之後的 `|` 不再切開儲存格。欄數與表頭不一致的列會列為 `UNDECIDABLE`（判定不了），不會被當成空白；別處沒有違反時結束碼為 2，因為乾淨的結果只涵蓋了欄位的一部分。空白、`—`、`-` 的儲存格只計數、不評估，也不算 OWT-019 違反。此事是在真實工作紀錄上量測 DEC-122 H2 基準時發現的：80 列中有 32 列的欄數與表頭不同。`回來要做什麼` 是該工作紀錄實際使用的表頭（它的文字說明把該欄叫作 下一動），屬未校準判斷（OWT-016）。檢查器自己的突變測試新增八個表格突變，原有十七個仍然轉紅。
+
+### 修正
+
+- **`uds uninstall` 不再留下 UDS 自己寫的檔案，也不再移除它無法證明是 UDS 寫的東西。** 走過 `init` → `update --with-hooks` → `uninstall -y` 之後，它回報「已移除 5、已跳過 1、錯誤 0」，卻留下 `scripts/hooks/` 底下 15 個 hook 腳本、一個空的 `.codex/`、一份生成標頭仍指向已刪除 `.standards/` 的 AGENTS.md，以及 `uds init` 寫入的 `.git/hooks/pre-commit` 腳本主體。現在的規則是：整個檔案只有在 manifest 記錄了「UDS 寫的」（`installedArtifacts`，由 `init` 與 `update --with-hooks` 寫入）**而且**內容仍與記錄的雜湊相符時才會刪除。其他一律保留，並在輸出說明原因（`kept: modified since UDS wrote it`、`kept: no install record — ...`）。資料夾只有在 UDS 建立且現已為空時才移除；採用者自己的 `scripts/hooks/*.mjs`、`.agents/rules/*` 與 hook 項目都會保留。由舊版 UDS 安裝的專案沒有記錄，其腳本、AGENTS.md 生成文字與原生 pre-commit 主體會被保留並說明，而不是猜測。每一行「已移除」現在都對應一次真實的刪除或修改，帶著錯誤結束的執行也會以非 0 結束。
+- **`uds uninstall` 在沒有人能回答時不再畫出提示或噴錯誤堆疊，做不了事時也不再以 0 結束。** `--dry-run` 從不提示（它不寫任何東西），並預覽所有類別。沒有 `--yes` 又沒有終端機時，實際執行會以結束碼 2 拒絕，而不是假定「是」；提示被關閉時結束碼為 130；專案未初始化時結束碼為 1。
+- **`uds init --with-hooks` 在 Windows 上不再印出 `'chmod' is not recognized`。** pre-commit hook 原本用 try/catch 包住的 `execSync("chmod +x ...")` 賦予執行權限；catch 對程式碼藏起了失敗，但 `execSync` 已先把 cmd.exe 的錯誤送到終端機。現在改用 `fs.chmodSync`，並在沒有執行位元的 Windows 上略過此步驟。
+- **安全性：`uds init` 寫入的 pre-commit hook 不再向 npm 要一個叫 `uds`、但不是本專案的套件。** 該 hook 原本是單行 `npx uds check`。`npx` 先找 `node_modules/.bin` 與 `PATH`，兩處都沒有才去 npm registry，而 registry 上的 `uds` 是不相干的專案（維護者 wizawu、`github.com/wizawu/uds`、v0.3.6、2022 年後未更新、目前沒有 `bin`）。裝了 UDS 的機器不受影響；沒裝的 clone 則會用名稱去抓陌生人的套件——目前無害只是因為該套件*尚*無可執行檔，對方一旦發布帶 `uds` bin 的版本，每位採用者的每次 commit 都會執行它。`--no-install` 不是解法：用會記錄每個請求的本機 registry 實測（npm 10.9.9、11.20.0、12.1.0，三者一致），`npx --no-install uds` 仍會發出 `GET /uds`，而 `npx --no-install --package=universal-dev-standards uds` 完全找不到全域安裝。hook 現在兩者都不用：它在專案的 `node_modules/.bin`、再到 `PATH` 找 `universal-dev-standards`（套件本名，只有本專案能發布）並執行 `check`；兩處都找不到時印出該裝什麼並以非 0 結束——不跳過檢查、不下載任何東西，而且即使採用者自己的指令排在後面，檢查失敗也會擋下 commit。`uds uninstall` 依標記整塊移除新寫法。給人看的文字同樣修正：產生的 `CLAUDE.md`/`AGENTS.md` 區塊內的警告行與 hook 提示改寫為 `npx universal-dev-standards init` / `update`（警告行多了幾個 token，所以 `scripts/prompt-footprint-baseline.json` 依實測值各調高 3–6）。**既有採用者：**`uds update`（除了 `--skills`、`--commands`、`--integrations-only`、`--standards-only` 與 `--rollback` 之外的所有模式，以及 `--with-hooks`；`--plan` 只回報不寫入）會替換 `.husky/pre-commit` 中 UDS 自己寫的那一行——只認 UDS 曾產生過的兩種確切寫法（`npx uds check`，以及較早的 `npx uds check --standard checkin-standards`），且必須緊接在 `# UDS Standard Check` 標記下方；你自己寫或改過的行不會被動，並會連同行號回報。此步驟在「已是最新版本」的提前返回**之前**執行，所以標準已是最新的採用者也會被處理。`uds check` 現在會警告仍使用裸名稱的 hook。新增一個測試走訪 `npm pack` 出貨的全部內容，只要有字串以套件執行器（npx、bunx、pnpm dlx、yarn dlx、npm exec）執行裸名稱 `uds` 就會失敗；非 Node 專案的原生 hook（`uds check`，只從 `PATH` 解析、不經 registry）不受影響，維持原樣。
+
 ## [6.14.0-beta.2] - 2026-09-30
 
 > **測試版**——以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、如何退回正式版：[docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。

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

@@ -15,7 +15,7 @@ status: current
 
 > **語言**: [English](../../README.md) | 繁體中文 | [简体中文](../zh-CN/README.md)
 
-**版本**: 6.14.0-beta.2 (Pre-release) | **發布日期**: 2026-09-30 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.14.0-beta.4 (Pre-release) | **發布日期**: 2026-10-06 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
 
 語言無關、框架無關的軟體專案文件標準。透過 AI 原生工作流，確保不同技術堆疊之間的一致性、品質和可維護性。
 
@@ -77,7 +77,7 @@ npx universal-dev-standards init
 | 類別 | 數量 | 說明 |
 |----------|-------|-------------|
 | **核心標準** | 153 | 通用開發準則 |
-| **AI Skills** | 55 | 互動式技能 |
+| **AI Skills** | 56 | 互動式技能 |
 | **斜線命令** | 51 | 快速操作 |
 | **CLI 指令** | 24 | 專案設定與維護 |
 <!-- UDS_STATS_TABLE_END -->

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

@@ -13,7 +13,7 @@ status: current
 <!-- UDS_SUPPORTED_VERSIONS_START -->
 | 版本 | 支援狀態 |
 |------|--------|
-| 6.14.0-beta.2 | ✅ 預發布版本 |
+| 6.14.0-beta.4 | ✅ 預發布版本 |
 | 6.13.1 | ✅ 最新正式版 |
 | < 6.0.0 | ❌ 已終止支援 |
 <!-- UDS_SUPPORTED_VERSIONS_END -->

package/bundled/locales/zh-TW/core/ai-response-navigation.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/ai-response-navigation.md
-source_version: 1.3.0
-translation_version: 1.3.0
-last_synced: 2026-08-17
+source_version: 1.4.0
+translation_version: 1.4.0
+last_synced: 2026-10-05
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/ai-response-navigation.md) | 繁體中文 | [简体中文](../../zh-CN/core/ai-response-navigation.md)
 
-**版本**: 1.3.0
-**最後更新**: 2026-08-17
+**版本**: 1.4.0
+**最後更新**: 2026-10-05
 **適用範圍**: 所有使用 AI 輔助開發的專案
 **範圍**: universal
 **產業標準**: 無（新興 AI 工具實踐）
@@ -27,10 +27,13 @@ status: current
 
 **解決方案**：在每個實質性 AI 回應結尾附加標準化的「導航區塊」，包含情境模板、推薦標記和彈性選項數量。
 
-**範圍註記（v1.2.0，v1.3.0 擴充）**：規則 1–6 管的是答案**之後**要附什麼。
-規則 7–11 **全部屬選用**，管的是答案本身：先講發現（R7）、每輪重述進度（R8）、不要開場白（R9）、
-白話是主詞（R10）、每個選項都要帶自己的優劣而非只有推薦項有（R11）。新增的理由是——
-一個回應可以滿足規則 1–6 的每一條，同時把結論埋起來；
+**範圍註記（v1.2.0，v1.3.0、v1.4.0 擴充）**：規則 1–6 管的是答案**之後**要附什麼。
+規則 7–12 管的是答案本身：先講發現（R7）、每輪重述進度（R8）、不要開場白（R9）、
+白話是主詞（R10）、每個選項都要帶自己的優劣而非只有推薦項有（R11）、受控語言（R12）。
+規則 7–11 **屬選用**。**規則 12 是唯一的例外，而且只有一部分**：其中「簡化後的文字要保留寫作者的不確定語氣」
+這一條**屬必須**，其餘部分屬選用。新增的理由是——
+一個回應可以滿足規則 1–6 的每一條，同時把結論埋起來、用只有作者持有的詞彙講它、列出讀者還得自己比較的選項，
+或是靠「比證據更肯定」來變得好讀；
 **而找不到答案的讀者，不會因為結尾有一個正確的導航區塊被告知下一步而得到幫助。**
 
 ---
@@ -109,11 +112,13 @@ status: current
 
 ---
 
-## 導航之前的那個答案（規則 7–11，選用）
+## 導航之前的那個答案（規則 7–12）
 
 > **規則 7–9 借鑒自**：[`ayghri/i-have-adhd`](https://github.com/ayghri/i-have-adhd)（MIT），十條中取三條。
 > **規則 10–11 於 1.3.0 新增**，來源不同——使用者在同一次工作階段中兩度指出，
 > 一個正確且完整的回答讀不懂。當時規則 7–9 已經出貨且正在被遵守。
+> **規則 12 於 1.4.0 新增**，來源又不同：一則公開的建議——請 LLM 寫到「大約達到 ASD-STE100 的 80%」
+> （ASD-STE100 是技術文件用的受控英文標準）。只取它的原則；它的英文詞典與時態規則不取（見規則 12）。
 > 其餘七條刪去：兩條已被上方規則 1–2 涵蓋，五條與本標準衝突
 > （它的「不要 recap／不要結語」與規則 1 的導航區塊直接矛盾；它的「清單上限 5 項」
 > 會切斷證據表格與走訪分母）或與 [estimation-standards](estimation-standards.md) 重複。
@@ -122,8 +127,9 @@ status: current
 一個回應可以把結論埋在一整面證據底下，只要結尾附上正確的導航區塊，
 它仍然滿足本標準的每一條。**找不到答案的讀者，不會因為被告知下一步而得到幫助。**
 
-**這五條是選用的**，語義同規則 6：採用專案不必啟用，既有 skill 也不需回頭補。
-專案**可以**在自己的設定中把任一條提升為必須。**不可選的是它們必須有精確的觸發條件**——
+**規則 7–11 是選用的**，語義同規則 6：採用專案不必啟用，既有 skill 也不需回頭補。
+專案**可以**在自己的設定中把任一條提升為必須。**規則 12 有一條必須（12.1）**，其餘（12.2）選用；
+為什麼這樣分，規則內部有論證。**任何一條都不可選的是它們必須有精確的觸發條件**——
 一條鬆到永遠不會啟動的規則，與沒有這條規則無從分辨。
 
 ### 規則 7：先講發現，不要先講過程（選用）
@@ -181,6 +187,9 @@ status: current
 **為什麼它與 R7 是兩條**：R7 規範的是**先講發現再給證據**的順序。R10 規範的是**語域**——
 一個回應可以先講發現，卻仍然用只有作者持有的詞彙講那個發現。兩者都讓讀者無法行動，但它們是不同的失效。
 
+**白話不可以拿肯定語氣來換。** 把說明改成讀者的話就是一次改寫，而改寫正是「可能」悄悄變成「是」的地方。
+當 R10 套用在寫作者原本就有保留的論斷上，由[規則 12](#規則-12受控語言部分必須) 的 12.1（必須）管：不確定語氣要留著。
+
 ### 規則 11：每個選項都要帶自己的優劣（選用）
 
 **觸發條件**：要求讀者在兩個以上做法之間選擇的回應。
@@ -204,6 +213,93 @@ status: current
 
 **與規則 4 相輔**：選項數維持在 1–5。優劣讓每個選項讀起來更花力氣，所以這條規則讓規則 4 的上限**更**要緊，不是更不要緊。
 
+### 規則 12：受控語言（部分必須）
+
+**觸發條件**：為「不是原作者」的讀者撰寫、改寫、縮短、簡化或翻譯文字——典型是一位非專業的讀者，要靠這段文字做判斷或核准。
+
+受控語言（用變化換可預測性的寫作規則）讓文字更好讀。它有一個已知的失敗方式：最好讀的句子是肯定的句子，
+所以「簡化」會朝肯定的方向漂移。本規則取受控寫作的原則，並對這個漂移設一道硬性的停損。
+
+#### 12.1 簡化後的文字要保留不確定語氣（必須）
+
+不確定語氣是一個告訴讀者「這個論斷可以信到什麼程度」的詞：*可能、推斷、大概、尚未確認*——
+*might、could、probably、appears to、not yet confirmed*。它是資訊，不是贅詞。
+
+縮短、簡化、改寫或翻譯時：
+
+- **不可把不確定的論斷改成確定的。** 原文說「可能」，結果就說「可能」（或結果語言裡對等的說法）。
+- **不可為了省字而刪掉不確定語氣。** 目標是更短的句子；更肯定的句子不被允許。
+- **不可加入原文沒說的事實**——編出來的原因、編出來的「已確認」，是同一種失敗的另一個樣子。
+- 只有在論斷之後**已經被驗證**時，不確定語氣才可以拿掉；而且要由驗證（查了什麼、結果是什麼）取代它的位置。
+  只刪掉不確定語氣，不算驗證。
+
+**為什麼只有這一條是必須的**：只有它的失敗會讓讀者**相信不真實的事**，而不只是讓文字更難讀。
+它也不需要校準——檢查就是拿改寫前後兩份文字比對，人或模型在任何語言都做得到；
+而下面每一個門檻都取決於語言與讀者。
+
+#### 12.2 白話寫作原則（選用）
+
+讀者是非專業人士時套用。它們與語言無關：每一條都用該語言自己的單位來表達，不附任何詞表。
+
+| 原則 | 要求什麼 |
+|------|----------|
+| **句子短，以該語言自己的單位計** | 一句一個意思。**起始範圍**，不是上限：英文大約 15–25 個詞，中文大約 25–40 個字。遠超過範圍是「該拆句」的訊號，不是要計數的缺陷。依語言與讀者校準 |
+| **同一個東西只用一個名稱** | 每個東西選定一個名稱，全文都用它。不要為了文采換說法：讀者看到第二個名稱，會以為是第二個東西 |
+| **主詞明確、主動語態** | 說清楚誰做了什麼。施事者不明或不重要時，才用被動 |
+| **一步一動作** | 程序是編號清單，每項一個動作，不是一段文字 |
+| **少用分號** | 分號把讀者必須同時記住的兩個意思接在一起。拆成兩句或一份清單 |
+| **數字帶單位** | 「30 秒」「3 個檔案」「NT$1,200」——不要只寫「30」 |
+
+**為什麼是選用**：上面的範圍只是起始點，**沒有**對照讀者實際理解度校準過，也沒有檢查器在執行。
+一條**必須**的規則若附帶沒人能驗證的門檻，會產生機械式的遵守——句子被拆到不再像句子——
+而專家讀者可能反而更適合比較密的文字。這些原則是寫作者憑判斷套用的指引；12.1 才是不會彎的那一部分。
+
+#### 本規則不取 ASD-STE100 的什麼
+
+ASD-STE100 的**核可詞典**（每個核可的英文單字只有一個意思，並有一份封閉的允許字表）與它的**時態限制**，
+都依賴英文這個語言。它們**不適用於中文**或其他非英文文字，本標準**不附任何形式的字表**。
+只取 12.2 的原則，並改寫成每一條都能在任何語言套用。
+
+同理，不要用「以空白或 ASCII 字元斷詞」的計數器去衡量非英文文字：它把一整段中文看成一個「詞」，
+不論多長都通過。一把在某個語言上永遠是綠燈的量尺，在那個語言上什麼也沒量到。
+
+#### 範例：同一段文字、三種改寫，以及一個不被允許的改寫
+
+範例刻意用中文：本規則與語言無關，而中文正是只靠英文做法行不通的地方。三個有效版本都保留不確定語氣
+「可能」、「推斷」、「尚未」，且沒有加入原文沒有的事實。
+
+**原文**
+
+```text
+經過檢查，登入頁面在高流量時段回應變慢，這個問題可能是資料庫連線池被耗盡所造成的，我們推斷是因為上週的改版新增了一個會長時間佔用連線的查詢；目前尚未在測試環境重現，所以修復後的效果還需要被確認，建議在確認之前先不要對外宣布已經解決。
+```
+
+**約 80%**——句子較短，讀起來仍像一段文字
+
+```text
+登入頁面在高流量時段回應變慢。原因可能是資料庫連線池被耗盡。我們推斷，上週改版新增了一個查詢，它會長時間佔用連線。這一點尚未在測試環境重現，修復後有沒有效，也還沒確認。確認之前，建議先不要對外宣布已經解決。
+```
+
+**嚴格**——一行一個意思、加標籤、保留不確定語氣
+
+```text
+登入頁面在高流量時段回應變慢。
+1. 原因：可能是資料庫連線池被耗盡。
+2. 推斷：上週改版新增了一個查詢，這個查詢可能長時間佔用連線。
+3. 狀態：尚未在測試環境重現。
+4. 修復效果：尚未確認。
+5. 建議：確認之前，不要對外宣布已解決。
+```
+
+**不是有效的改寫**——最短，而且是錯的
+
+```text
+登入頁面變慢，原因是資料庫連線池被耗盡，已確認由上週改版造成。
+```
+
+最後這一版最短、也最好讀，卻兩度違反 12.1：「可能」變成直接陳述的原因，「尚未重現」變成「已確認」，
+而原文從沒說過這件事。讀者若憑它核准一個修復，就是被給了一件不真實的事。
+
 ---
 
 ## 情境模板
@@ -398,6 +494,7 @@ AI 需要使用者做出選擇或提供資訊時使用。
 | R9 | *（選用）* 不要開場白。結語仍為必須——見 R1 |
 | R10 | *（選用）* 白話是主詞；識別字放在主張之後當佐證 |
 | R11 | *（選用）* 每個選項都要說明換到什麼、代價是什麼——不只推薦那一個 |
+| R12 | **12.1 *（必須）***：簡化、縮短或翻譯時，保留不確定語氣——不可把「可能」改成「是」。12.2 *（選用）*：句子短（以該語言自己的單位計）、同物同名、主動語態、一步一動作、少用分號、數字帶單位。不附英文詞典——它無法移到其他語言 |
 
 | 豁免 | 不豁免 |
 |------|--------|
@@ -421,6 +518,7 @@ AI 需要使用者做出選擇或提供資訊時使用。
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| 1.4.0 | 2026-10-05 | 新增 R12 受控語言（語言中立）。一條必須（12.1：簡化後的文字要保留寫作者的不確定語氣——「可能」不會變成「是」、也不新增原文沒有的事實）；其餘（12.2：以該語言自己的單位計句長、同物同名、主動語態、一步一動作、少用分號、數字帶單位）屬選用，理由已寫進標準。取 ASD-STE100 的原則、不取它的英文詞典與時態規則，並在標準裡明說。附一組中文改寫對照（三種嚴格度），外加一個更短卻錯誤的改寫。R10 現在指向 R12，因為把論斷改成白話就是一次改寫，而改寫正是不確定語氣流失的地方 |
 | 1.3.0 | 2026-08-17 | 新增選用規則 R10–R11。R10 管語域：白話是句子的主詞、識別字當佐證——與 R7 不同,R7 管的是「先發現後證據」的順序,而一個回應可以先講發現卻仍用只有作者持有的詞彙講它。R11 把規則 2 從推薦選項擴及全部:只論證推薦項的清單等於把比較丟回給讀者,而沒標代價的選項讀起來像沒有代價 |
 | 1.2.0 | 2026-08-17 | 新增選用規則 R7–R9，管答案本身（先講發現、重述進度、不要開場白）。借鑒自 `ayghri/i-have-adhd`（MIT），十條取三；其餘七條因已被 R1–R2 涵蓋、與 R1 衝突、或與 estimation-standards 重複而刪去。規則 1–6 全部可以被一個把結論埋起來的回應滿足——R7–R9 補上這個缺口 |
 | 1.1.0 | 2026-06-10 | 新增規則 R6 選用模型級別標注（`〔模型：Fast｜Standard｜Capable〕`）；與廠商無關；不強制既有技能回改 |

package/bundled/locales/zh-TW/core/open-work-tracking.md

@@ -2,8 +2,8 @@
 source: ../../../core/open-work-tracking.md
 source_version: 1.1.0
 translation_version: 1.1.0
-last_synced: 2026-09-29
-source_hash: 0fcf3df23e12
+last_synced: 2026-09-30
+source_hash: fb60809a8ff2
 status: current
 ---
 
@@ -286,7 +286,7 @@ DEX-003 扮演的角色相同。上面每一條都指名了 artefact 與它們
 是採用專案的決定——與 [deferred-item-exit](deferred-item-exit.md) 對自己出口劃的界線相同。
 自 1.1.0 起，UDS 為 OWT-017–OWT-019 附上一支**參考判定程序**——npm 安裝包裡的 `uds open-work next-action | revision | separation`（`uds open-work self-test` 只跑檢查器自己的自測臂；在 UDS repo 的副本裡，`node scripts/check-open-work-tracking.mjs` 跑的是同一份程式）——
 作為 OWT-015 意義上的證據——它已被觀察到對違反的樣本回報失敗——供採用者直接執行或自行重做。
-它沒有接進任何 UDS 發版閘門，因為 UDS 本身沒有承載開放工作的地方可供它檢查。
+它沒有接進任何 UDS 發版閘門，因為 UDS 本身沒有承載開放工作的地方可供它檢查。對 OWT-019，它以同一份詞彙讀三種形狀的「下一步」欄位：小節標題、行內標籤、以及表頭在該詞彙內的表格欄（該欄每一列各算一個欄位）。欄數與表頭不一致的表格列會被列為「判定不了」（不會被當成空白；若別處沒有違反，結束碼是 2，不是通過）；空白、`—`、`-` 或已完成的儲存格只計數、不評估——它不算違反，因為 OWT-019 判斷的是「寫了的下一步有沒有點名對象」，沒寫是另一種失效，它不判定。
 
 本標準做的事，是讓那個決定顯形：OWT-014 保證這裡每一條**能**被判定，OWT-015 固定
 「一次判定要算數需要什麼」，OWT-005／OWT-011 固定「一次不完整的判定容許印出什麼」。

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

@@ -59,6 +59,7 @@ skills/
 | `refactoring-assistant` | `/refactor` | [UDS] 重構指引 |
 | `project-discovery` | `/discover` | [UDS] 評估專案健康度與風險 |
 | `brainstorm-assistant` | `/brainstorm` | [UDS] 結構化 AI 輔助發想 |
+| `comprehension-ladder` | `/comprehend` | [UDS] 把難懂的 AI 輸出換成受控文字、Mermaid 圖或離線 HTML 解說頁，不改變事實 |
 | `changelog-guide` | `/changelog` | [UDS] 產生 changelog 條目 |
 | `dev-workflow-guide` | `/dev-workflow` | [UDS] 將開發階段對應到 UDS 命令 |
 | `docs-generator` | `/docgen` | [UDS] 產生使用文件 |