universal-dev-standards 6.13.0-beta.1 → 6.13.0-beta.4

package/bundled/ai/standards/turn-completion-integrity.ai.yaml

@@ -4,7 +4,7 @@
 id: turn-completion-integrity
 meta:
   version: "1.4.0"
-  updated: "2026-09-25"
+  updated: "2026-09-26"
   source: core/turn-completion-integrity.md
   description: An agent must not end a turn having stated a next action it did not take; enforced at turn end, not by instruction
   related:

package/bundled/core/turn-completion-integrity.md

@@ -159,10 +159,18 @@ actually wired into that harness's own config. As of v1.4.0:
 
 Codex's R9 exemption is best-effort, not silent failure: Codex's Stop payload
 gives the assistant's final message directly but not the human's, so reading
-the human side requires parsing a transcript file whose exact schema was not
-confirmed against a real installation at the time this table was written. A
-failed parse leaves the human side empty — detection still runs on the
-assistant's message, only the R9 exemption for that one turn may be missed.
+the human side requires parsing a transcript file. Confirmed against a real
+codex-cli 0.156.1 installation (2026-09-26): a user message in
+`~/.codex/sessions/**/*.jsonl` is a `{"type":"response_item","payload":
+{"type":"message","role":"user","content":[{"type":"input_text","text":...}]}}`
+record — the message lives under `payload`, not at the top level of the
+line or under a `message` key, and a `role: "developer"` record on the same
+shape is not a human message. The 6.13.0-beta.1 adapter read neither of the
+two shapes it tried against this real one, so R9 never exempted a turn on
+Codex; fixed for 6.13.0-beta.2. A failed parse (or an unrecognized record
+shape) still leaves the human side empty rather than throwing — detection
+still runs on the assistant's message, only the R9 exemption for that one
+turn may be missed.
 
 Cursor was evaluated and is not supported: whether its stop hook can actually
 block a turn in the way this standard requires was unresolved as of this

package/bundled/hooks/check-turn-completion-codex.mjs

@@ -23,12 +23,14 @@
  *
  * R9 (exempt a human-directed stop) is best-effort here. Codex's Stop payload
  * gives the assistant's last message directly but not the human's; this
- * adapter tries transcript_path for it (rollout.jsonl), tolerantly, because
- * its exact schema was not confirmed against a real Codex install at
- * authoring time. If that read fails or the field is null, the user side is
- * treated as empty — which means R9 cannot exempt that turn, not that the
- * check goes silent (last_assistant_message still drives detection). This is
- * the documented gap in core/turn-completion-integrity.md's Codex section.
+ * adapter reads transcript_path for it (rollout.jsonl), tolerantly. The real
+ * record shape has been confirmed against a codex-cli 0.156.1 install
+ * (2026-09-26; see extractMessage() below) — 6.13.0-beta.1 tried two guessed
+ * shapes that never matched it, so R9 never actually exempted a Codex turn.
+ * If the read still fails, or an unrecognized record type is seen, the user
+ * side is treated as empty — which means R9 cannot exempt that turn, not
+ * that the check goes silent (last_assistant_message still drives
+ * detection). See core/turn-completion-integrity.md's Codex section.
  *
  * Judgement (packs, cooldown, rolling window, self-echo) lives in
  * turn-completion/engine.mjs and is shared with every other adapter; this
@@ -43,12 +45,40 @@
 import { readFileSync } from 'node:fs';
 import { decide, isSelfEcho, runSelfTest, printLanguages } from './turn-completion/engine.mjs';
 
+/**
+ * A user-message record's `{ role, content }` payload, whichever of the
+ * plausible JSONL shapes `ev` turns out to be.
+ *
+ * 🔴 2026-09-26: verified against a real codex-cli 0.156.1
+ * `~/.codex/sessions/**\/*.jsonl` transcript. The actual shape is
+ * `{"type":"response_item","payload":{"type":"message","role":"user",
+ * "content":[{"type":"input_text","text":"…"}]}}` — the message lives under
+ * `ev.payload`, not `ev.message` and not `ev` itself. The two fallback shapes
+ * below were this file's original best-effort guesses (Claude-Code-style
+ * nested `message`, and a flat record); neither matches what Codex actually
+ * writes, so `bestEffortLastUserMessage` always returned '' and R9 (exempting
+ * a human-directed stop) never fired on Codex. They stay as fallbacks in case
+ * a different Codex version or record type uses one of them, but `ev.payload`
+ * is tried first since it is the confirmed real shape.
+ *
+ * Other record types seen in a real rollout (`event_msg`, `token_usage_record`,
+ * `session_meta`, `world_state`, and `response_item` payloads of type
+ * `reasoning`/`custom_tool_call`/…) do not have `role: "user"` on the object
+ * this function returns, so they fall through untouched. A `role: "developer"`
+ * message is deliberately NOT treated as a user message — only
+ * `payload.type === "message" && payload.role === "user"` counts.
+ */
+function extractMessage(ev) {
+  if (ev && ev.payload && ev.payload.type === 'message') return ev.payload;
+  if (ev && ev.message && typeof ev.message === 'object') return ev.message;
+  return ev;
+}
+
 /**
  * Best-effort extraction of the human's last message from a Codex transcript.
- * Tolerant of several plausible JSONL shapes because the exact rollout.jsonl
- * schema was not confirmed against a real install; any failure returns '',
- * which is the same as "cannot tell" (R5) — it does not stop
- * last_assistant_message from still being checked.
+ * Tolerant of several plausible JSONL shapes; any failure returns '', which
+ * is the same as "cannot tell" (R5) — it does not stop last_assistant_message
+ * from still being checked.
  */
 function bestEffortLastUserMessage(transcriptPath) {
   if (typeof transcriptPath !== 'string' || !transcriptPath) return '';
@@ -58,16 +88,13 @@ function bestEffortLastUserMessage(transcriptPath) {
       if (!line.trim()) continue;
       let ev;
       try { ev = JSON.parse(line); } catch { continue; }
-      // Try a few plausible shapes rather than committing to one: a nested
-      // { message: { role, content } } (Claude-Code-style rollout entry), or
-      // a flat { role, content }.
-      const msg = (ev && ev.message) || ev;
+      const msg = extractMessage(ev);
       if (!msg || msg.role !== 'user') continue;
       const c = msg.content;
       const text = typeof c === 'string'
         ? c
         : Array.isArray(c)
-          ? c.filter((p) => p && (p.type === 'text' || typeof p.text === 'string')).map((p) => p.text || '').join('\n')
+          ? c.filter((p) => p && (p.type === 'text' || p.type === 'input_text' || typeof p.text === 'string')).map((p) => p.text || '').join('\n')
           : '';
       if (text && text.trim() && !isSelfEcho(text)) user = text;
     }

package/bundled/hooks/turn-completion/engine.mjs

@@ -14,7 +14,7 @@
 import { readFileSync, mkdirSync, writeFileSync, existsSync } from 'node:fs';
 import { homedir } from 'node:os';
 import { join, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
+import { fileURLToPath, pathToFileURL } from 'node:url';
 import { detectCommitment, userAskedToStop } from './detect.mjs';
 
 export const VERSION = '1.2.0';
@@ -53,7 +53,16 @@ export async function loadPacks() {
   const failed = [];
   for (const id of SHIPPED_LOCALES) {
     try {
-      packs.push(await import(join(HERE, 'locales', `${id}.mjs`)));
+      // A filesystem path (`C:\...` on Windows) is not a valid ESM import
+      // specifier — dynamic `import()` needs a `file://` URL there. On
+      // POSIX both happen to look like absolute paths that Node accepts, so
+      // this went unnoticed until measured 2026-09-27 in CI
+      // (windows-latest): every pack failed to load, `failed` was silently
+      // non-empty, and every adapter test that expects a block/deny decision
+      // got `undefined` instead — the hook ran, found no packs, and let
+      // every turn end uninspected. pathToFileURL(...).href is the one
+      // form valid on every platform.
+      packs.push(await import(pathToFileURL(join(HERE, 'locales', `${id}.mjs`)).href));
     } catch (e) {
       failed.push({ id, why: String((e && e.message) || e) });
     }

package/bundled/hooks/turn-completion/locales/en.mjs

@@ -115,9 +115,18 @@ export function isAsking(text) {
  * here disables the check for the rest of the session, which is worse than a
  * missed block. It must read as an instruction to stop, not a mention of
  * stopping.
+ *
+ * 🔴 2026-09-27: `\bI'?m (heading|going) (home|out)\b` was dead code — it can
+ * never match, because isStopRequest() always calls normalize() first, and
+ * normalize() rewrites "I'm" to "I am" before this pattern ever sees the
+ * text (`\bI'll\b` -> "I will" etc. have the same shape, but no other branch
+ * here depended on the contracted form surviving normalize()). Verified: a
+ * bare "I'm heading out." tested false pre-fix, true once the pattern
+ * accounts for the post-normalize "I am" form. Written to match either form
+ * defensively, in case normalize()'s rewrite list ever changes.
  */
 const STOP_REQUEST =
-  /(\blet's (stop|pause|pick this up later)\b|\b(pause|stop) (here|for now|there)\b|\bhold (on|off)\b|\bthat's (enough|it) for (now|today)\b|\b(done|enough) for (now|today)\b|\bwrap (it |this )?up\b|\bcontinue (this )?later\b|\bpick (this|it) up (tomorrow|later)\b|\btake a break\b|\bI'?m (heading|going) (home|out)\b|\bgood ?night\b)/i;
+  /(\blet's (stop|pause|pick this up later)\b|\b(pause|stop) (here|for now|there)\b|\bhold (on|off)\b|\bthat's (enough|it) for (now|today)\b|\b(done|enough) for (now|today)\b|\bwrap (it |this )?up\b|\bcontinue (this )?later\b|\bpick (this|it) up (tomorrow|later)\b|\btake a break\b|\bI(?:'m| am) (heading|going) (home|out)\b|\bgood ?night\b)/i;
 
 export function isStopRequest(text) {
   return STOP_REQUEST.test(normalize(text));
@@ -184,4 +193,15 @@ export const stopCorpus = [
   [false, 'mentions stopping but is not one', 'Explain why the hook stops the turn.'],
   [false, 'asks for work', 'Stop using the hardcoded list and walk the registry instead.'],
   [false, 'ordinary instruction', 'Fix the detector and push it.'],
+  // 🔴 the "I'm heading (home|out)" branch above was dead code before this
+  // fix — normalize() rewrites "I'm" to "I am" before the pattern is tested,
+  // and the pattern required the contracted form. This case exercises it
+  // directly (no "let's pause"/"hold on" alongside it, unlike the two cases
+  // above that already passed for a different reason).
+  [true, "bare 'heading out', no other stop phrase nearby", "I'm heading out."],
+  [false, 'a leaving verb alone is an instruction to finish something BEFORE leaving, not a stop request', 'Before I head out, please finish the migration.'],
 ];
+// Mutation check (verified by hand, then reverted — see commit/handback
+// notes): reverting STOP_REQUEST's `I(?:'m| am)` back to the dead-code
+// `I'?m`-only form turns the "bare 'heading out'" case above false, which
+// fails `--self-test`.

package/bundled/hooks/turn-completion/locales/zh-TW.mjs

@@ -93,15 +93,28 @@ export function isAsking(text) {
   return ASKING.test(text);
 }
 
+// 🔴 2026-09-25 實測缺口：「我要出門了，等我回來再繼續」與「暫停，我要出門」
+// 都沒有被下面任何一支既有樣式接住——前者當天真的誤擋了一次真實的 Claude
+// Code 回合。R10 說叫停樣式放寬是危險方向（錯誤豁免會讓整個 session 的檢查
+// 失效），所以這裡刻意寫窄：離開類詞必須跟「稍後再續」或裸的「暫停」同時
+// 出現在同一小段裡，單獨出現的離開詞不算——「出門前把這三件做完」只有離開
+// 詞、沒有稍後再續，仍必須判 false（見下方 stopCorpus 的反例）。
+const LEAVING = '(出門|離開一下|先走)';
+const RESUME_LATER = '(等我回來|回來再|明天再|晚點再|待會再|待会再)';
+const LEAVE_THEN_LATER = `${LEAVING}[^。！？\\n]{0,12}${RESUME_LATER}|${RESUME_LATER}[^。！？\\n]{0,12}${LEAVING}`;
+const LEAVE_WITH_PAUSE = `暫停[^。！？\\n]{0,12}${LEAVING}|${LEAVING}[^。！？\\n]{0,12}暫停`;
+
 /**
  * The human asking for the turn to end. Kept narrow on purpose: a false
  * positive disables the check for the rest of the session.
  */
-const STOP_REQUEST =
+const STOP_REQUEST = new RegExp(
   // 🔴 `先停` 曾寫成裸的，而語料當場抓到「先**停用**那份硬編碼清單」——
   // 一句要求做事的指令被讀成叫我停。這個方向的誤判會把守衛整場關掉，
   // 所以 `停` 後面接得出動詞的字一律排除。
-  /(先暫停|暫停一下|先停(?![用止掉住])|停一下|先不要(做|動)|不用繼續|今天(先)?到這|先這樣|收工|下班|我要回家|明天再(說|弄|做)|改天再|先擱著|睡了|晚安)/;
+  '(先暫停|暫停一下|先停(?![用止掉住])|停一下|先不要(做|動)|不用繼續|今天(先)?到這|先這樣|收工|下班|我要回家|明天再(說|弄|做)|改天再|先擱著|睡了|晚安' +
+  `|${LEAVE_THEN_LATER}|${LEAVE_WITH_PAUSE})`
+);
 
 export function isStopRequest(text) {
   return STOP_REQUEST.test(text);
@@ -191,4 +204,14 @@ export const stopCorpus = [
   [false, '提到停止但不是叫停', '解釋一下這支 hook 為什麼會擋下回合。'],
   [false, '要求做事而句中有停', '先停用那份硬編碼清單，改成走訪註冊表。'],
   [false, '一般指令', '把偵測器修好然後推上去。'],
+  // 🔴 2026-09-25 真實使用者原話——當時真的誤擋了一次回合，見上方 STOP_REQUEST 的註解。
+  [true, '離開＋稍後再續（真實原話）', '我要出門了，等我回來再繼續'],
+  [true, '暫停＋離開（真實原話）', '暫停，我要出門'],
+  // 窄性反例：單獨的離開詞、或單獨的「稍後」詞，都不算叫停——那是要求
+  // 「在離開前」把事情做完，不是要收掉這一輪。
+  [false, '離開詞單獨出現：這是要求離開前做完，不是叫停', '出門前把這三件做完'],
+  [false, '稍後詞單獨出現，沒有離開詞：一樣是要求先做完', '等我回來前先把測試跑完'],
 ];
+// 突變驗證（手動跑過、已還原——見 commit/交接紀錄）：把 STOP_REQUEST 的
+// `LEAVE_THEN_LATER`／`LEAVE_WITH_PAUSE` 兩個新分支拿掉，上面兩筆「真實原話」
+// 會變 false，`--self-test` 隨之變紅，證明這兩筆真的在測新加的規則。

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.13.0-beta.1
-translation_version: 6.13.0-beta.1
-last_synced: 2026-09-25
+source_version: 6.13.0-beta.4
+translation_version: 6.13.0-beta.4
+last_synced: 2026-09-27
 status: current
 ---
 
@@ -17,6 +17,37 @@ status: current
 
 ## [Unreleased]
 
+## [6.13.0-beta.4] - 2026-09-28
+
+> **测试版** — 以 `npm install -g universal-dev-standards@beta` 安装。要测什么、已知限制、如何退回正式版：见 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。注意：6.13.0-beta.3 从未上架 npm，其内容随本版发布。
+
+### 修复
+
+- **`turn-completion-integrity` 的 Stop hook 在 Windows 上一路到 6.13.0-beta.3 都静默失效——它照跑、找不到任何语言包、然后放行每一轮对话，且什么都不打印。** `engine.mjs` 的 `loadPacks()` 用 `join(HERE, 'locales', ...)` 拼出每个语言包的路径，直接把这个文件系统路径交给动态 `import()`；在 Windows 上那是 `C:\...` 这种路径，不是合法的 ESM import 指定字符串（POSIX 上的绝对路径恰好也能被解析成合法指定字符串，这正是为何在 macOS/Linux 上从未被发现）。2026-09-27 于 CI（windows-latest）实测：每一个出货的语言包都加载失败，而每一个原本该回 `block`/`deny` 决策的适配层（Claude Code、Codex、Gemini CLI）全部返回 `undefined`。修复方式改用 `pathToFileURL(...).href`，与 `cli/src/utils/standard-fixer.js`／`standard-validator.js` 既有的正确写法一致。四支 `scripts/check-*.ts` 开发工具脚本有同样的写法（Windows CI job 不会跑到它们，因为它们只在 `ubuntu-latest` 上执行，但那里同样是坏的），一并以同样方式修正。新增一支全 repo 走查测试（`cli/tests/unit/scripts/no-fs-path-dynamic-import.test.js`）扫描 `scripts/`、`cli/src/`、`cli/scripts/` 找这个写法，未来新增的一处不需要有人记得这次事故也会被挡下。
+- **由 `uds init` 写入的 husky 管理 `.husky/pre-commit`，即使 `core.hooksPath` 已正确接好，在 Windows 上一路到 6.13.0-beta.3 都会让每一次提交失败，错误是 `error: cannot spawn .husky/pre-commit: No such file or directory`。** husky v9 自己的模板没有 shebang 行，这在 macOS/Linux 上一直能用，因为 POSIX git 在脚本没有 shebang 时（`ENOEXEC`）会回退用 `/bin/sh` 执行；git for Windows 没有这个后备机制，完全无法对没有 shebang 的文件 spawn，而且错误信息指向 hook 文件本身而非缺失的解释器——很容易被误判成 wiring 问题而非内容问题。`uds init` 现在会在缺少 shebang 时，于 husky 管理的 hook 最前面补上 `#!/bin/sh`，不分平台一律如此，无论是写新 hook 还是动到既有的采用者文件（只会插入，绝不重写采用者自己的 shebang 或任何其他行）。`uds check` 的 `[pre-commit]` 警告新增 `missingShebang` 信号，独立于 wiring 报告（一个 hook 可以完全接好但在 Windows 上仍因此失败），且维持既有设计，只读不写。
+
+## [6.13.0-beta.3] - 2026-09-27
+
+> **测试版** — 以 `npm install -g universal-dev-standards@beta` 安装。要测什么、已知限制、如何退回正式版：见 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+
+### Fixed
+
+- **`uds init` 会写入提交前检查（`.husky/pre-commit`，非 Node 项目则为 `.git/hooks/pre-commit`），却从未确认 git 真的会执行它。** 它依赖 husky 自己的 bootstrap 机制——`npm install` 触发 husky 的 `prepare` script 去设定 `core.hooksPath`——而这个时机只在**下一次** `npm install` 执行时才会发生；如果 `node_modules` 早就存在，这件事就永远不会发生。实测三个既有采用者（asiaostrich-telemetry-server、asiaostrich-telemetry-client、machine-setup，2026-09-26）：三者都有调用 `npx uds check` 的 `.husky/pre-commit`，但 `core.hooksPath` 均未设定，提交时检查从未跑过——而且完全没有任何错误信息。`uds init` 现在不再替用户安装 husky 或改动 package.json 的依赖；改为直接执行 `git config --local core.hooksPath .husky`（与 husky 自己 bootstrap 内部所做的事完全相同），让检查在 `uds init` 执行完就立刻生效，无论 husky 有没有安装。绝不覆盖用户既有的 `core.hooksPath`，或既有的 `.git/hooks/pre-commit`——两者都会被保留原状，并打印信息说明检查**未启用**及原因。非 Node 项目的原生 hook 路径也不再无条件覆写既有的 `.git/hooks/pre-commit`（过去会）。新增 `uds check` 警告 `[pre-commit]`：检测 UDS 写入的检查文件存在，但实际不在 git 真正会执行的路径上（涵盖直接设定、husky 自己的 `<dir>/_` shim 转发、以及原生默认路径三种形状），并附上修复方式——这就是像上述三个既有采用者这样“已经中招”的项目能发现问题的渠道。此警告仅提示、不影响 `uds check --ci` 的退出码，因为这是每个 clone 各自的本机设定落差，不是标准本身不合规。`core.hooksPath` 不会进版控，所以这道启用只对执行 `uds init` 的那个 clone 生效——信息与新警告都会说明这一点。
+
+- **后续修正（2026-09-27）：上面那个修法，若既有采用者手上的 `.husky/pre-commit` 还是 husky v8 旧模板（含 `_/husky.sh` 那一行），照做反而会让每一次提交都失败。** 实测其中一个既有采用者的一次性 clone：照 `uds check` 原本建议的修法（`git config --local core.hooksPath .husky`）执行，结果打印 `.husky/pre-commit: line 2: .husky/_/husky.sh: No such file or directory`，`git commit` 以 exit 1 失败——比原本“静默不跑”的缺陷更糟，因为 `.husky/_/` 这个目录只有在 husky 自己的 bootstrap 真的跑过后才存在，而直接把 `core.hooksPath` 设成 `.husky` 会让 git 原封不动地执行这个文件。`uds init` 的 `setupHuskyHook` 现在会检测并移除这一行后再改写 `.husky/pre-commit`（其余内容——用户自己加的命令、既有的 `uds check` 那一行——全部保留）；`uds check` 的 `[pre-commit]` 警告检测到这种旧模板时，不再只单独建议设定 hooksPath，改为给出“先删那一行、再设定 hooksPath”的两步修法——因为 `uds init` 对已初始化的项目会直接拒绝执行，修不了这三个既有采用者的问题。`git-hooks.js` 新增共用函数 `hasLegacyHuskyShLine`／`stripLegacyHuskyShLine`。
+
+- **`bump-version.mjs` 在“预发布→预发布”的版本升版时，把 `SECURITY.md`“最新正式版”那一行标错——实测发生于 6.13.0-beta.2 发版当下（2026-09-26），当时以手动更正。** 它的 `SECURITY.md` 修补逻辑找“裸版号（无后缀）那一行”来认定是正式版行；新的预发布版号（如 `6.13.0-beta.2`）永远带着连字符、永远不会符合“裸版号”，于是修补逻辑退而求其次改到唯一真正裸版号的那一行——也就是不相关的正式版行——把它的版号换成新的预发布版号，而原本该更新、已经过期的预发布行（仍是 `6.13.0-beta.1`）反而原封不动。已将产生表格的逻辑（`generate-docs.mjs` 原本就写对、但 `bump-version.mjs` 未使用）抽成共用的 `scripts/lib/security-versions.mjs`，两支脚本现在都改成用 `(version, stableVersion)` 整段重新产生 2 或 3 行的表格，而不是找一行去 patch——已针对全部四种版本类型转换（正式→正式、正式→预发布、预发布→预发布、预发布→正式）、三种语言，通过对隔离副本执行一次真正的端到端 `bump-version.mjs` 验证正确。`check-version-sync.sh` 原本的 SECURITY.md 检查只比对第一行数据的版号是否等于 `package.json`（一种位置代理，恰好抓到了这次事故）；现在还会逐行比对“标签”与“该行版号的形状”是否吻合（“最新正式版／Latest stable”行若版号带连字符、或“预发布版本／Pre-release”行若版号不带连字符，即使位置检查会通过，仍会被标记为错误）。
+
+## [6.13.0-beta.2] - 2026-09-26
+
+> **测试版** — 以 `npm install -g universal-dev-standards@beta` 安装。要测什么、已知限制、如何退回正式版：见 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+
+### 修复
+
+- **`uds uninstall` 从未移除 `installHooks()`／`installCodexHooks()`／`installGeminiHooks()` 写入的关卡——不只是 Codex 与 Gemini CLI（6.13.0-beta.1 记载的已知限制），Claude Code 自己的 `.claude/settings.json` 也有一模一样的缺口，而且从未被记录过。** `hooks` 这个 uninstall 分类原本只处理 `.husky/pre-commit` 与 `.git/hooks/pre-commit`；三个安装函数实际写入的配置文件完全没有任何 uninstaller 在管，导致每一个关卡在 `uds uninstall` 之后仍持续运行。新增的 `uninstallClaudeCodeHooks`／`uninstallCodexHooks`／`uninstallGeminiHooks`（`src/uninstallers/hook-uninstaller.js`）现在会精准移除 `.claude/settings.json`、`.codex/hooks.json`、`.gemini/settings.json` 里 UDS 安装的条目——判断依据是命令路径**加上**一份 UDS 目前确实有发布的脚本文件名清单，不是只看路径，这样用户自己放进 UDS 同一个 `scripts/hooks/` 目录下的 hook 就不会被误删。移除后变空的事件数组会一并从配置里移除；配置文件若因此变成完全空的对象（代表整份都是 UDS 写入的）就直接删除文件，否则保留文件并写回其余内容。JSON 格式损坏时报告错误并保持原样，不会覆写。已接入 `uds uninstall` 既有的 `hooks` 分类、`--dry-run` 预览，以及交互菜单里该分类的说明文字。
+- **Codex 适配层的 R9 豁免（「用户叫停就放行」）在真实 Codex 安装上从未真正生效过——`scripts/hooks/check-turn-completion-codex.mjs` 的 `bestEffortLastUserMessage()` 试过的两种记录形状都读不到字段。** 已对真实 codex-cli 0.156.1 的 `~/.codex/sessions/**/*.jsonl` 对话记录坐实：一条用户消息记录长这样——`{"type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":...}]}}`——消息位于 `payload` 之下，不在该条记录最外层、也不在 `message` 键下，所以该字段一直被读成不存在，R9 从未真正豁免过任何一轮 Codex 对话。现在优先读取 `payload.type === "message"`（其余记录类型若刚好用到原来那两种形状仍保留为后备），同时支持 `input_text` 内容项（与既有的 `text` 形状并存），且不把 `role: "developer"` 的记录当成用户消息。`core/turn-completion-integrity.md`「支持的执行环境」一节与 `docs/PRE-RELEASE.md` 已从「未对照真实安装验证过」更新为已坐实的真实形状。
+- **R9 的 zh-TW 叫停检测漏掉了「要离开、稍后再继续」这一族——已实测：「我要出门了，等我回来再继续」在 2026-09-25 真的误挡了一次 Claude Code 的对话完成关卡。** 这句与「暂停，我要出门」都没有被既有的任何一个 `STOP_REQUEST` 模式接住。新增两个窄模式：离开类词（出门／离开一下／先走）必须跟「稍后再续」类词（等我回来／回来再／明天再／晚点再／待会再）或裸的「暂停」同时出现在同一小段里——单独的离开词（例如「出门前把这三件做完」，这是要求离开前做完，不是叫停）语料仍必须判 false。顺手查了 en 语料包有没有同样的缺口，发现 `\bI'?m (heading|going) (home|out)\b` 是永远打不中的死代码：`isStopRequest()` 一律先调用 `normalize()`，会把 "I'm" 改写成 "I am"，只认缩写形式的模式因此永远匹配不到；已改为 `I(?:'m| am) (heading|going) (home|out)`，坐实裸的 "I'm heading out." 修复前为 false、修复后为 true。
+
 ## [6.13.0-beta.1] - 2026-09-26
 
 > **测试版** — 以 `npm install -g universal-dev-standards@beta` 安装。要测什么、已知限制、如何退回正式版：见 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。已知限制：`uds uninstall` 尚不会移除 Codex／Gemini CLI 设置里的关卡。

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

@@ -15,7 +15,7 @@ status: current
 
 > **语言**: [English](../../README.md) | [繁體中文](../zh-TW/README.md) | 简体中文
 
-**版本**: 6.13.0-beta.1 (Pre-release) | **发布日期**: 2026-09-26 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.13.0-beta.4 (Pre-release) | **发布日期**: 2026-09-28 | **授权**: [双重授权](../../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.13.0-beta.1 | ✅ 预发布版本 |
+| 6.13.0-beta.4 | ✅ 预发布版本 |
 | 6.12.0 | ✅ 最新正式版 |
 | < 6.0.0 | ❌ 已终止支持 |
 <!-- UDS_SUPPORTED_VERSIONS_END -->

package/bundled/locales/zh-CN/core/turn-completion-integrity.md

@@ -2,8 +2,8 @@
 source: ../../../core/turn-completion-integrity.md
 source_version: 1.4.0
 translation_version: 1.4.0
-last_synced: 2026-09-25
-source_hash: 8966d46d5f79
+last_synced: 2026-09-26
+source_hash: 401b74843abc
 status: current
 ---
 
@@ -154,9 +154,16 @@ agent 写下「我接着做 X」，然后结束回合，而 X 没有做。
 
 Codex 的 R9 豁免是尽力而为，不是静默失效：Codex 的 Stop payload 直接给出
 agent 的最后一条消息，却不给出用户的；要拿到用户那一侧必须解析一份
-对话记录文件，而它的确切格式在撰写本表时未对照真实安装验证过。解析失败时
-用户那一侧会变空——检测仍照样运行在 agent 消息上，只有那一轮的 R9 豁免
-可能漏掉。
+对话记录文件。已对真实 codex-cli 0.156.1 安装坐实（2026-09-26）：
+`~/.codex/sessions/**/*.jsonl` 里的一条用户消息长这样——
+`{"type":"response_item","payload":{"type":"message","role":"user",
+"content":[{"type":"input_text","text":...}]}}`——消息位于 `payload`
+之下，不在该行最外层、也不在 `message` 键下；同一种形状但
+`role: "developer"` 的记录不算用户消息。6.13.0-beta.1 的适配层尝试过的
+两种形状都不是这个真实形状，所以 R9 在 Codex 上从未真正豁免过任何一轮；
+6.13.0-beta.2 已修复。解析失败（或遇到无法识别的记录形状）时仍只是让
+用户那一侧变空、不会抛出异常——检测仍照样运行在 agent 消息上，只有那一轮
+的 R9 豁免可能漏掉。
 
 Cursor 已评估但不支持：截至撰写本文时，Cursor 的 stop hook 能不能真的
 拦下一个回合仍未确定，若对着一个没人验证过的契约交付一份适配层，

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

@@ -1,8 +1,8 @@
 ---
 source: ../../../docs/CLI-INIT-OPTIONS.md
-source_version: 3.6.0
-translation_version: 3.6.0
-last_synced: 2026-09-25
+source_version: 3.7.0
+translation_version: 3.7.0
+last_synced: 2026-09-26
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **语言**: [English](../../../docs/CLI-INIT-OPTIONS.md) | [简体中文](../../zh-TW/docs/CLI-INIT-OPTIONS.md) | 简体中文
 >
-> **版本**: 3.6.0
-> **最后更新**: 2026-09-25
+> **版本**: 3.7.0
+> **最后更新**: 2026-09-26
 
 本文档详细说明 `uds init` 命令的每一个选项，包含使用情境、影响范围和建议选择。
 
@@ -838,6 +838,34 @@ uds init --experimental
 | Claude Code 目标文件 | `--claude-target` | Claude Code 集成内容要写到哪里：`project`（`CLAUDE.md`，默认）或 `local`（`CLAUDE.local.md`） |
 | 模式（已弃用） | `-m, --mode` | 安装模式（skills, full）- 请改用 `--skills-location` |
 
+### 提交前标准检查（git hook 接线）
+
+`uds init` 一律会设定“`git commit` 时跑 `uds check`”——这不是标志，只要项目
+是 git 仓库就会执行。Node.js 项目（检测到 `package.json`）写入
+`.husky/pre-commit`，否则写入 `.git/hooks/pre-commit`，接着会确保 git 真的
+会执行它：设定 `git config --local core.hooksPath .husky`（非 Node 项目则
+保留原生 `.git/hooks` 默认不动）——这与 husky 自己的 `npx husky` bootstrap
+内部所做的事完全相同，只是直接做，让检查立刻生效，不论最后有没有装 husky。
+
+以下两件事是刻意不做的：
+
+- **替你安装 husky，或改动 `package.json` 的依赖。** husky 要不要作为依赖
+  由你决定；上面的接线不论有没有 husky 都能运作。若项目已经把 husky 列为
+  依赖，`uds init` 也会顺手串接它的 `prepare` script（`"prepare": "既有内容
+  && husky"`），让未来的 `npm install` 也保持 husky 自己的 bootstrap 同步
+  ——这是锦上添花，不是这道接线能否生效的关键。
+- **覆盖你自己的 git hook 设定。** 若 `core.hooksPath` 已经指向别处，或
+  `.git/hooks/pre-commit` 已经存在，`uds init` 会两者都不动，并打印检查
+  **未启用**及原因。
+
+`git config core.hooksPath` 是**本机、per-clone 的设定——不会进版控。**
+跑 `uds init` 只会让“跑过这个命令的那个 clone”生效；其他人 clone 这个
+仓库后要自己再跑一次 `uds init`（或 `uds check` 打印的那一行修复命令）。
+`uds check` 会检测“`.husky/pre-commit`／`.git/hooks/pre-commit` 存在，但
+实际不在 git 真正会执行的路径上”的情况——包含在这次修复之前就已采用
+UDS 的项目——并在 `[pre-commit]` 下回报同样的修复方式；此警告不影响
+`uds check --ci` 的退出码。
+
 ### Claude Code 以外的强制执行 Hooks
 
 `--with-hooks` 一定会安装进 `.claude/settings.json`。四个有 hook 支持的标准

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.13.0-beta.1
-translation_version: 6.13.0-beta.1
-last_synced: 2026-09-25
+source_version: 6.13.0-beta.4
+translation_version: 6.13.0-beta.4
+last_synced: 2026-09-27
 status: current
 ---
 
@@ -17,6 +17,37 @@ status: current
 
 ## [Unreleased]
 
+## [6.13.0-beta.4] - 2026-09-28
+
+> **測試版** — 以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、已知限制、如何退回正式版：見 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。注意：6.13.0-beta.3 從未上架 npm，其內容隨本版出貨。
+
+### 修復
+
+- **`turn-completion-integrity` 的 Stop hook 在 Windows 上一路到 6.13.0-beta.3 都靜默失效——它照跑、找不到任何語言包、然後放行每一輪對話，且什麼都不印。** `engine.mjs` 的 `loadPacks()` 用 `join(HERE, 'locales', ...)` 組出每個語言包的路徑，直接把這個檔案系統路徑交給動態 `import()`；在 Windows 上那是 `C:\...` 這種路徑，不是合法的 ESM import 指定字串（POSIX 上的絕對路徑恰好也能被解析成合法指定字串，這正是為何在 macOS/Linux 上從未被發現）。2026-09-27 於 CI（windows-latest）實測：每一個出貨的語言包都載入失敗，而每一個原本該回 `block`/`deny` 決策的介接層（Claude Code、Codex、Gemini CLI）全部回傳 `undefined`。修法改用 `pathToFileURL(...).href`，與 `cli/src/utils/standard-fixer.js`／`standard-validator.js` 既有的正確寫法一致。四支 `scripts/check-*.ts` 開發工具腳本有同樣的寫法（Windows CI job 不會跑到它們，因為它們只在 `ubuntu-latest` 上執行，但那裡同樣是壞的），一併以同樣方式修正。新增一支全 repo 走訪測試（`cli/tests/unit/scripts/no-fs-path-dynamic-import.test.js`）掃描 `scripts/`、`cli/src/`、`cli/scripts/` 找這個寫法，未來新增的一處不需要有人記得這次事故也會被擋下。
+- **由 `uds init` 寫入的 husky 管理 `.husky/pre-commit`，即使 `core.hooksPath` 已正確接好，在 Windows 上一路到 6.13.0-beta.3 都會讓每一次提交失敗，錯誤是 `error: cannot spawn .husky/pre-commit: No such file or directory`。** husky v9 自己的範本沒有 shebang 行，這在 macOS/Linux 上一直能動，因為 POSIX git 在腳本沒有 shebang 時（`ENOEXEC`）會退回用 `/bin/sh` 執行；git for Windows 沒有這個後備機制，完全無法對沒有 shebang 的檔案 spawn，而且錯誤訊息指向 hook 檔本身而非缺少的直譯器——很容易被誤判成 wiring 問題而非內容問題。`uds init` 現在會在缺少 shebang 時，於 husky 管理的 hook 最前面補上 `#!/bin/sh`，不分平台一律如此，無論是寫新 hook 還是動到既有的採用者檔案（只會插入，絕不重寫採用者自己的 shebang 或任何其他行）。`uds check` 的 `[pre-commit]` 警告新增 `missingShebang` 訊號，獨立於 wiring 回報（一個 hook 可以完全接好但在 Windows 上仍因此失敗），且維持既有設計，只讀不寫。
+
+## [6.13.0-beta.3] - 2026-09-27
+
+> **測試版** — 以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、已知限制、如何退回正式版：見 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+
+### Fixed
+
+- **`uds init` 會寫入提交前檢查（`.husky/pre-commit`，非 Node 專案則為 `.git/hooks/pre-commit`），卻從未確認 git 真的會執行它。** 它依賴 husky 自己的 bootstrap 機制——`npm install` 觸發 husky 的 `prepare` script 去設定 `core.hooksPath`——而這個時機只在**下一次** `npm install` 執行時才會發生；如果 `node_modules` 早就存在，這件事就永遠不會發生。實測三個既有採用者（asiaostrich-telemetry-server、asiaostrich-telemetry-client、machine-setup，2026-09-26）：三者都有呼叫 `npx uds check` 的 `.husky/pre-commit`，但 `core.hooksPath` 皆未設定，提交時檢查從未跑過——而且完全沒有任何錯誤訊息。`uds init` 現在不再替使用者安裝 husky 或改動 package.json 的依賴；改成直接執行 `git config --local core.hooksPath .husky`（與 husky 自己 bootstrap 內部做的事完全相同），讓檢查在 `uds init` 執行完就立刻生效，無論 husky 有沒有裝。絕不覆蓋使用者既有的 `core.hooksPath`，或既有的 `.git/hooks/pre-commit`——兩者都會被保留原狀，並印出訊息說明檢查**未啟用**及原因。非 Node 專案的原生 hook 路徑也不再無條件覆寫既有的 `.git/hooks/pre-commit`（過去會）。新增 `uds check` 警告 `[pre-commit]`：偵測 UDS 寫入的檢查檔存在，但實際不在 git 真正會執行的路徑上（涵蓋直接設定、husky 自己的 `<dir>/_` shim 轉呼叫、以及原生預設路徑三種形狀），並附上修復方式——這就是像上述三個既有採用者這樣「已經中招」的專案能發現問題的管道。此警告只提示不影響 `uds check --ci` 的結束碼，因為這是每個 clone 各自的本機設定落差，不是標準本身不合規。`core.hooksPath` 不會進版控，所以這道啟用只對執行 `uds init` 的那個 clone 生效——訊息與新警告都會說明這一點。
+
+- **後續修正（2026-09-27）：上面那個修法，若既有採用者手上的 `.husky/pre-commit` 還是 husky v8 舊範本（含 `_/husky.sh` 那一行），照做反而會讓每一次提交都失敗。** 實測其中一個既有採用者的拋棄式 clone：照 `uds check` 原本建議的修法（`git config --local core.hooksPath .husky`）執行，結果印出 `.husky/pre-commit: line 2: .husky/_/husky.sh: No such file or directory`，`git commit` 以 exit 1 失敗——比原本「靜默不跑」的缺陷更糟，因為 `.husky/_/` 這個目錄只有在 husky 自己的 bootstrap 真的跑過後才存在，而直接把 `core.hooksPath` 設成 `.husky` 會讓 git 原封不動地執行這個檔案。`uds init` 的 `setupHuskyHook` 現在會偵測並移除這一行後再改寫 `.husky/pre-commit`（其餘內容——使用者自己加的指令、既有的 `uds check` 那一行——全部保留）；`uds check` 的 `[pre-commit]` 警告偵測到這種舊範本時，不再只單獨建議設定 hooksPath，改成給「先刪那一行、再設定 hooksPath」的兩步修法——因為 `uds init` 對已初始化的專案會直接拒絕執行，修不了這三個既有採用者的問題。`git-hooks.js` 新增共用函式 `hasLegacyHuskyShLine`／`stripLegacyHuskyShLine`。
+
+- **`bump-version.mjs` 在「預發布→預發布」的版本升版時，把 `SECURITY.md`「最新正式版」那一列標錯——實測發生於 6.13.0-beta.2 發版當下（2026-09-26），當時以手動更正。** 它的 `SECURITY.md` 修補邏輯找「裸版號（無尾碼）那一列」來認定是正式版列；新的預發布版號（如 `6.13.0-beta.2`）永遠帶著連字號、永遠不會符合「裸版號」，於是修補邏輯退而求其次改到唯一真正裸版號的那一列——也就是不相關的正式版列——把它的版號換成新的預發布版號，而原本該更新、已經過期的預發布列（仍是 `6.13.0-beta.1`）反而原封不動。已將產生表格的邏輯（`generate-docs.mjs` 原本就寫對、但 `bump-version.mjs` 未使用）抽成共用的 `scripts/lib/security-versions.mjs`，兩支腳本現在都改成用 `(version, stableVersion)` 整段重新產生 2 或 3 列的表格，而不是找一列去 patch——已針對全部四種版本型態轉換（正式→正式、正式→預發布、預發布→預發布、預發布→正式）、三種語言，透過對隔離複本執行一次真正的端到端 `bump-version.mjs` 驗證正確。`check-version-sync.sh` 原本的 SECURITY.md 檢查只比對第一列資料的版號是否等於 `package.json`（一種位置代理，恰好抓到了這次事故）；現在還會逐列比對「標籤」與「該列版號的形狀」是否吻合（「最新正式版／Latest stable」列若版號帶連字號、或「預發布版本／Pre-release」列若版號不帶連字號，即使位置檢查會通過，仍會被標記為錯誤）。
+
+## [6.13.0-beta.2] - 2026-09-26
+
+> **測試版** — 以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、已知限制、如何退回正式版：見 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。
+
+### 修正
+
+- **`uds uninstall` 從未移除 `installHooks()`／`installCodexHooks()`／`installGeminiHooks()` 寫入的關卡——不只是 Codex 與 Gemini CLI（6.13.0-beta.1 記載的已知限制），Claude Code 自己的 `.claude/settings.json` 也有一模一樣的缺口，而且從未被記錄過。** `hooks` 這個 uninstall 分類原本只處理 `.husky/pre-commit` 與 `.git/hooks/pre-commit`；三支安裝函式實際寫入的設定檔完全沒有任何 uninstaller 在管，導致每一個關卡在 `uds uninstall` 之後仍持續執行。新增的 `uninstallClaudeCodeHooks`／`uninstallCodexHooks`／`uninstallGeminiHooks`（`src/uninstallers/hook-uninstaller.js`）現在會精準移除 `.claude/settings.json`、`.codex/hooks.json`、`.gemini/settings.json` 裡 UDS 安裝的項目——辨識依據是指令路徑**加上**一份 UDS 目前確實有出貨的腳本檔名清單，不是只看路徑，這樣使用者自己放進 UDS 同一個 `scripts/hooks/` 目錄底下的 hook 就不會被誤刪。移除後變空的事件陣列會一併從設定裡移除；設定檔若因此變成完全空的物件（代表整份都是 UDS 寫入的）就直接刪除檔案，否則保留檔案並寫回其餘內容。JSON 格式損壞時回報錯誤並保持原樣，不會覆寫。已接入 `uds uninstall` 既有的 `hooks` 分類、`--dry-run` 預覽，以及互動選單裡該分類的說明文字。
+- **Codex 轉接層的 R9 豁免（「使用者叫停就放行」）在真實 Codex 安裝上從未真的生效過——`scripts/hooks/check-turn-completion-codex.mjs` 的 `bestEffortLastUserMessage()` 試過的兩種紀錄形狀都讀不到欄位。** 已對真實 codex-cli 0.156.1 的 `~/.codex/sessions/**/*.jsonl` 逐字稿坐實：一則使用者訊息紀錄長這樣——`{"type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":...}]}}`——訊息住在 `payload` 底下，不在該筆紀錄最外層、也不在 `message` 鍵底下，所以那個欄位一直被讀成不存在，R9 從未真的豁免過任何一輪 Codex 回合。現在優先讀 `payload.type === "message"`（其餘紀錄型別若剛好用到原本那兩種形狀仍保留為後備），一併支援 `input_text` 內容項目（與既有的 `text` 形狀並存），且不把 `role: "developer"` 的紀錄當成使用者訊息。`core/turn-completion-integrity.md`「支援的執行環境」一節與 `docs/PRE-RELEASE.md` 已從「未對照真實安裝驗證過」更新為已坐實的真實形狀。
+- **R9 的 zh-TW 叫停偵測漏掉「要離開、稍後再續」這一族——已實測：「我要出門了，等我回來再繼續」在 2026-09-25 真的誤擋了一次 Claude Code 的回合完成關卡。** 這句與「暫停，我要出門」都沒有被既有的任何一支 `STOP_REQUEST` 樣式接住。新增兩支窄樣式：離開類詞（出門／離開一下／先走）必須跟「稍後再續」類詞（等我回來／回來再／明天再／晚點再／待會再）或裸的「暫停」同時出現在同一小段裡——單獨的離開詞（例如「出門前把這三件做完」，這是要求離開前做完，不是叫停）語料仍必須判 false。順手查了 en 語料包有沒有一樣的缺口，發現 `\bI'?m (heading|going) (home|out)\b` 是永遠打不中的死碼：`isStopRequest()` 一律先呼叫 `normalize()`，會把 "I'm" 改寫成 "I am"，只認縮寫形的樣式因此永遠配不到；已修成 `I(?:'m| am) (heading|going) (home|out)`，坐實裸的 "I'm heading out." 修前為 false、修後為 true。
+
 ## [6.13.0-beta.1] - 2026-09-26
 
 > **測試版** — 以 `npm install -g universal-dev-standards@beta` 安裝。要測什麼、已知限制、如何退回正式版：見 [docs/PRE-RELEASE.md](../../docs/PRE-RELEASE.md)。已知限制：`uds uninstall` 尚不會移除 Codex／Gemini CLI 設定裡的關卡。

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

@@ -15,7 +15,7 @@ status: current
 
 > **語言**: [English](../../README.md) | 繁體中文 | [简体中文](../zh-CN/README.md)
 
-**版本**: 6.13.0-beta.1 (Pre-release) | **發布日期**: 2026-09-26 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.13.0-beta.4 (Pre-release) | **發布日期**: 2026-09-28 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
 
 語言無關、框架無關的軟體專案文件標準。透過 AI 原生工作流，確保不同技術堆疊之間的一致性、品質和可維護性。
 

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

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

package/bundled/locales/zh-TW/core/turn-completion-integrity.md

@@ -2,8 +2,8 @@
 source: ../../../core/turn-completion-integrity.md
 source_version: 1.4.0
 translation_version: 1.4.0
-last_synced: 2026-09-25
-source_hash: 8966d46d5f79
+last_synced: 2026-09-26
+source_hash: 401b74843abc
 status: current
 ---
 
@@ -154,9 +154,16 @@ agent 寫下「我接著做 X」，然後結束回合，而 X 沒有做。
 
 Codex 的 R9 豁免是盡力而為，不是靜默失效：Codex 的 Stop payload 直接給
 agent 的最後一則訊息，卻不給使用者的；要拿到使用者那一側必須解析一份
-逐字稿檔案，而它的確切格式在撰寫本表時未對照真實安裝驗證過。解析失敗時
-使用者那一側會變空——偵測仍照樣跑在 agent 訊息上，只有那一輪的 R9 豁免
-可能漏掉。
+逐字稿檔案。已對真實 codex-cli 0.156.1 安裝坐實（2026-09-26）：
+`~/.codex/sessions/**/*.jsonl` 裡的一則使用者訊息長這樣——
+`{"type":"response_item","payload":{"type":"message","role":"user",
+"content":[{"type":"input_text","text":...}]}}`——訊息住在 `payload`
+底下，不在該行的最外層、也不在 `message` 鍵底下；同一種形狀但
+`role: "developer"` 的紀錄不算使用者訊息。6.13.0-beta.1 的轉接層試過的
+兩種形狀都不是這個真實形狀，所以 R9 在 Codex 上從未真的豁免過任何一輪；
+6.13.0-beta.2 已修正。解析失敗（或遇到辨識不出的紀錄形狀）時仍只是讓
+使用者那一側變空、不會拋出例外——偵測仍照樣跑在 agent 訊息上，只有那一輪
+的 R9 豁免可能漏掉。
 
 Cursor 已評估但不支援：截至撰寫本文時，Cursor 的 stop hook 能不能真的
 擋下一個回合仍未確定，若對著一個沒人驗證過的契約出一份轉接層，

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

@@ -1,8 +1,8 @@
 ---
 source: ../../../docs/CLI-INIT-OPTIONS.md
-source_version: 3.6.0
-translation_version: 3.6.0
-last_synced: 2026-09-25
+source_version: 3.7.0
+translation_version: 3.7.0
+last_synced: 2026-09-26
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../docs/CLI-INIT-OPTIONS.md) | 繁體中文 | [简体中文](../../zh-CN/docs/CLI-INIT-OPTIONS.md)
 >
-> **版本**: 3.6.0
-> **最後更新**: 2026-09-25
+> **版本**: 3.7.0
+> **最後更新**: 2026-09-26
 
 本文件詳細說明 `uds init` 命令的每一個選項，包含使用情境、影響範圍和建議選擇。
 
@@ -838,6 +838,34 @@ uds init --experimental
 | Claude Code 目標檔 | `--claude-target` | Claude Code 整合內容要寫到哪裡：`project`（`CLAUDE.md`，預設）或 `local`（`CLAUDE.local.md`） |
 | 模式（已棄用） | `-m, --mode` | 安裝模式（skills, full）- 請改用 `--skills-location` |
 
+### 提交前標準檢查（git hook 接線）
+
+`uds init`一律會設定「`git commit` 時跑 `uds check`」——這不是旗標，只要專案是
+git repo 就會執行。Node.js 專案（偵測到 `package.json`）寫入
+`.husky/pre-commit`，否則寫入 `.git/hooks/pre-commit`，接著會確保 git 真的會
+執行它：設定 `git config --local core.hooksPath .husky`（非 Node 專案則保留
+原生 `.git/hooks` 預設不動）——這與 husky 自己的 `npx husky` bootstrap 內部
+做的事完全相同，只是直接做，讓檢查立刻生效，不論最後有沒有裝 husky。
+
+以下兩件事是刻意不做的：
+
+- **替你安裝 husky，或動 `package.json` 的依賴。** husky 要不要是依賴由你
+  決定；上面的接線不論有沒有 husky 都能運作。若專案已經把 husky 列為依賴，
+  `uds init` 也會順手串接它的 `prepare` script（`"prepare": "既有內容 &&
+  husky"`），讓未來的 `npm install` 也保持 husky 自己的 bootstrap 同步——
+  這是錦上添花，不是這道接線能不能生效的關鍵。
+- **覆蓋你自己的 git hook 設定。** 若 `core.hooksPath` 已經指向別處，或
+  `.git/hooks/pre-commit` 已經存在，`uds init` 會兩者都不動，並印出檢查
+  **未啟用**及原因。
+
+`git config core.hooksPath` 是**本機、per-clone 的設定——不會進版控。**
+跑 `uds init` 只會讓「跑過這個指令的那個 clone」生效；其他人 clone 這個
+repo 後要自己再跑一次 `uds init`（或 `uds check` 印出的那一行修復指令）。
+`uds check` 會偵測「`.husky/pre-commit`／`.git/hooks/pre-commit` 存在，
+但實際不在 git 真正會執行的路徑上」的情況——包含在這個修正之前就已採用
+UDS 的專案——並在 `[pre-commit]` 底下回報同樣的修復方式；此警告不影響
+`uds check --ci` 的結束碼。
+
 ### Claude Code 以外的強制執行 Hooks
 
 `--with-hooks` 一定會安裝進 `.claude/settings.json`。四個有 hook 支援的標準

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "universal-dev-standards",
-  "version": "6.13.0-beta.1",
+  "version": "6.13.0-beta.4",
   "description": "CLI tool for adopting Universal Development Standards",
   "keywords": [
     "documentation",