universal-dev-standards 6.7.5 → 6.9.0

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

@@ -1,8 +1,8 @@
 ---
 source: ../../CHANGELOG.md
-source_version: 6.7.5
-translation_version: 6.7.5
-last_synced: 2026-08-18
+source_version: 6.9.0
+translation_version: 6.9.0
+last_synced: 2026-09-14
 status: current
 ---
 
@@ -17,6 +17,68 @@ status: current
 
 ## [Unreleased]
 
+## [6.9.0] - 2026-09-14
+
+### 採用者升級注意
+
+- **uds update 不再自動刪除檔案；會列出可移除的 UDS 舊檔，加 --prune 才會刪，且只刪 UDS 自己寫過的檔案。原本依賴自動清檔的流程請加上 --prune。**（#168、#165，詳見「修正」）
+- **--content-mode 給了不認得的值，現在會印出警告並照舊使用 index（6.8.0 也是產生 index 的內容）；7.0.0 起會改成直接報錯。** `--content-mode full` 已棄用，會解析為 `index` 並附說明。（詳見「棄用」）
+- **以 `uds init -y` 安裝的 Codex、OpenCode 等非 Claude 工具，技能現在會裝進它們自己的目錄**（例如 Codex 是 `.agents/skills/`），不再裝進 `.claude/skills/`。既有安裝跑 `uds update` 會自動遷移。（詳見「修正」）
+- **Antigravity 現在會拿到 `.agents/skills/` 與 `.agents/AGENTS.md`**，以前是什麼都沒有、指示檔寫成 `INSTRUCTIONS.md`。Antigravity 只在該目錄是已登記的專案時才會讀 `.agents/`，`uds init` 會印出這個提示。
+- **6.8.0 以前 uds init --with-hooks 寫進 .claude/settings.json 的 hook 是從未執行的字串格式，uds update 不會處理 hook，重跑 uds init --with-hooks 也不會刪掉舊項目與 scripts/hooks/*.js。要取得可用的 hook，請重跑 uds init --with-hooks，並可手動刪除舊的 .js 項目。**
+
+### 修正
+
+- **`uds update` 不再靠「查一張雜湊表」來決定檔案是誰的（XSPEC-384，issue [#165](https://github.com/AsiaOstrich/universal-dev-standards/issues/165) 與 [#168](https://github.com/AsiaOstrich/universal-dev-standards/issues/168)）。** 兩位使用者對同一支指令回報了方向相反的缺陷：它刪掉了使用者手寫放在 `.standards/` 下的專案文件，沒有警告、沒有 diff、沒有詢問、沒有備份（#168，是逐行比對 `git status` 才發現的）；同時它把 registry 已經移除的標準留在 manifest 與磁碟上，而 `upstream.version` 照樣前進到「最新」（#165）。兩者都源自同一個布林值在回答兩個彼此獨立的問題——**這個檔是不是 UDS 寫的**、**它現在還是不是現行標準**——而每個 issue 各撞上這個超載軸的一端。所有權現在改成在 UDS 寫入的當下記錄，存進 manifest 新增的 `provenance` 欄位，並以複製動作實際回傳的路徑為鍵，而不是從來源檔名重新推算的路徑（正是那個重新推算，讓 `fileHashes` 裡出現五筆 `.standards/options/<name>.ai.yaml`，而真正的檔案住在 `options/<category>/<name>.ai.yaml`）。provenance 是唯增的，`fileHashes` 是當前狀態；若兩者同進同退，provenance 會在同一刻一起失效，也就毫無作用。刪除現在必須兩件事同時成立，其餘每一種組合一律保留，**並印出保留的理由**。無法判定所有權時歸向保留——那正是舊程式不肯選的那一邊。既有安裝沒有 provenance，因此首次升級無從歸屬、也不會刪任何東西；provenance 只在一次完整寫入全套標準的執行結束時才建立。刪除另外需要新的 `--prune` 旗標，刻意不用 `--yes`：`--yes` 會被設在 CI 裡，讓它一併授權刪除，等於正好在沒有人看得到的地方把破壞性路徑打開。「預設就刪」的分階段策略放在單一具名常數（`PRUNE_POLICY`），因為 XSPEC-384 §4 尚未裁決。每一份刪除報告都印出分母——檢查了幾個、我方擁有幾個、非我方幾個、判不了幾個、排除幾個以及為什麼——因為一份只列出動作對象的報告，與「它只看到這幾個」無從分辨。兩個 issue 都由先證明會紅的測試釘住。
+- **九個工具裡有八個，技能被裝進它們不會讀的目錄。** 非互動路徑（`uds init -y`）下，除了 Claude Code 以外每個能裝技能的工具，技能都被寫進 `.claude/skills/`；一個 codex repo 下 `--mode skills -y` 會得到零個技能、零則訊息。現在「能不能裝技能」與「要不要走 marketplace」都改成問路徑表；偵測到、但沒有查證路徑的工具什麼都不裝而且會出聲；`uds update` 轉換舊 manifest 時會重新推導工具，不再假設 `claude-code`。Codex 那句未經查證的 `fallbackSkillsPath: '.claude/skills/'` 已移除。互動流程從來沒有這個問題。
+- **Roo Code 永遠裝不起來。** 路徑表裡有它，偵測器裡沒有；它的識別字在一張表叫 `roo`、其他地方都叫 `roo-code`，於是 `uds init` 把指示寫進根目錄的 `roo-code.md`。偵測改用 `.roo/` 與 `.roorules`（刻意不用 `.clinerules`，那是 Cline 自己的標記）；技能也不再退回 `.claude/skills/`，因為 Roo Code 文件列出的位置裡沒有它。依據是 Roo Code 的文件，沒有在真的 Roo Code 上實測。
+- **Antigravity：UDS 六個月來什麼都沒幫它裝，而且寫的指示檔是它不會讀的那一份（XSPEC-355 OQ6）。** 技能改裝進 `.agents/skills/`、指示改寫進 `.agents/AGENTS.md`，由工具的二進位檔、隨附說明文件、以及一次帶誘餌路徑的實跑三方確認。它的 tier 從 `minimal` 升為 `partial`。
+- **UDS 至今出貨的每一支 hook 都是死的，而採用者拿到四支壞掉的 hook。** hook 項目寫成裸字串（只有物件形式會跑）；`scripts/hooks` 沒有進 npm 套件；hook 是 ESM `.js`，在 `"type": "commonjs"` 下會失敗（改為 `.mjs`）；commit message 驗證掛在 `UserPromptSubmit`，每打一句話就跑一次、每次 exit 1（改掛 `PreToolUse(Bash)`，只看真正的 `git commit -m`）。
+- **`uds check` 的還原會拿一份過期模板蓋掉生成的整合檔。** Claude Code 那份是 140 行、最後修改於 2026-03-25 的檔案。還原現在改用安裝器記下的設定重新生成，受管區塊外的內容不動；Antigravity 與 Gemini CLI 第一次有了還原路徑，Codex 的後備來源也不再指向不存在的目錄。
+- **Codex／OpenCode 的 `AGENTS.md` 沒有揭露句。** 2026-08-18 的揭露修正只到了兩個產生器中的一個；選 codex 或 opencode 時，`AGENTS.md` 走的是另一個。兩種語言、兩種輸出格式都已修正。
+- **cline、windsurf、roo-code 與 Antigravity 的整合檔只寫「照 commit-message 規則」，沒有寫出規則本身。** 格式與合法型別現在直接寫在檔案裡，與 Codex 那份原本的做法相同。
+
+### 新增
+
+- **`turn-completion-integrity`——agent 不得在說了下一步之後、沒做就結束回合。** 由 Stop hook 在回合結束時執法，而不是寫成指令。偵測器附英文與 zh-TW 語言包及做過突變測試的語料；它會讀使用者的最後一則訊息，所以被叫停不會被當成未兌現的承諾；逐項列出「誰卡在誰身上」的清單被認得是合法的結束方式；「做完跟我說，我再驗」被當成條件式。`uds init --with-hooks` 現在會在你的語言沒有語言包時警告，因為在未列出的語言下，hook 裝好了卻不可能觸發。含 zh-TW 與 zh-CN 翻譯。
+- **`deferred-item-exit`——六條標準會產出延後項目，而沒有一條說那些項目要去哪（XSPEC-391）。** 一位採用者的一次設計工作產出了一份 ADR 與一份規格，其中帶有五個標為「待決定」／「另案處理」／「不在 v1」的項目，而**五項全都沒有進入任何追蹤系統**。原因不是健忘。對會產出這類項目的六條標準——`adr-standards`、`spec-driven-development`、`retrospective-standards`、`feature-discovery-standards`、`code-review-checklist`、`acceptance-criteria-traceability`——grep `issue|tracker|backlog|task id|work item` 共 13 個命中，而**沒有任何一個是出口**：ADR 的 `Technical Story` 是輸入參照、retrospective 把 tracker 當指標來源、feature-discovery 把工單當需求輸入、AC-traceability 只對外部阻塞的覆蓋要求連結，而 code-review 的 8 個命中全是英文單字 "issues"，意思是「問題」。每條標準都說明如何把自己的文件寫好；文件寫完就是終點。新標準把缺少的那個關係陳述一次——延後項目在文件之外有一個可追溯的出口，而文件帶著那個出口的識別碼——六條產出端標準加上 `brainstorm-assistant` skill 各自取得**一行指向它的指標，而不是一份副本**，因為同一條規則的六份副本會往六個方向腐壞。**載體刻意不指定**：issue、受追蹤的 TODO、manifest 的一列、backlog 檔案裡的一行都符合，判準是「這個項目離開文件了嗎」，永遠不是「用了哪個工具」。三個發現決定了條文。第一，出口必須在產出該文件的那次變更落地*之後*仍然解析得到——兩個觀察到的洩漏滿足其他所有條件，仍然遺失了項目（待辦寫進一個會被本次合併關閉的 issue；待辦寫進出口的留言，被後續留言推出視線）。第二，**連結存在不等於連結有效**：回報者自己的閘門會放行他最強的那個例子——一份寫著「與 issue #19 一併決定」的文件，而 #19 裡根本沒有這件事——所以 DEX-005/006 要求「有連結且內容已驗證」與「有連結、內容未驗證」永遠不得印出同一個綠，因為一個被回報成通過的未知，比一個被回報成未知的未知更糟。第三，錨點是文件的**結構**（ADR 的 `Consequences`、規格的範圍外章節、retrospective 的 `Action Items`），不是它的措辭：結構可以窮舉，措辭清單不行，所以 DEX-008 要求任何措辭清單都要宣告其涵蓋率未知，DEX-009 要求任何窗口大小（「3 行以內」）都要載明來歷，否則標為未校準。依 DEC-049，這條標準完全寫成「必須存在的關係」，絕不寫成「必須維持它的機制」——而且它在自己的本文裡明白寫出 **UDS 不為它提供任何閘門**，因為一條陳述了規則卻沒有東西執行它的標準，不承認這一點時比承認時更糟。`adr-standards` 另外補上一條它從未陳述過的邊界（對它 grep `acceptance criteria|\bAC\b|驗收` 得到**零**命中，對照組 `acceptance-criteria-traceability` 為 84 個命中）：**驗收標準只在一處維護——SPEC**，ADR 以連結指向它——被複製的清單有兩個擁有者，其中一個永遠不會被更新，實測後果是工作出貨後 ADR 裡的勾選框全部仍是未勾選，而只讀規格的覆蓋率工具看不到它。
+- **`AUTH_SCOPE_EXTRACTION`——租戶界限是一個 `WHERE` 子句，而遷移流程裡沒有任何東西強迫你去找它（`reverse-engineering-standards` 1.3.0，issue [#166](https://github.com/AsiaOstrich/universal-dev-standards/issues/166)）。** 一次真實的 PHP → C# 遷移中，一個以租戶為界的帳號列表 endpoint 在重寫過程中弄丟了它的隔離述詞：依角色限縮範圍被換成粗糙的「這個帳號是不是任何一個已啟用的管理員？」檢查，於是不論是誰在問，它都回傳資料庫裡的每一個帳號。它出貨了、通過了所有既有測試（那個方法一個測試都沒有），最後是客戶回報「我看到了不該看到的帳號資訊」才浮現。`test-completeness-dimensions` 的維度 4 早就點名跨租戶存取，所以缺的從來不是維度，缺的是一個在遷移當下強迫想起它的步驟。有三個性質讓這一類缺陷穿過每一道閘門：那條安全關鍵的程式碼因為住在查詢裡而非請求／回應契約裡，讀起來就像眾多過濾條件之一；基於形狀的斷言看不見範圍，所以「200 加非空清單」在子句被刪掉之後照樣通過；而程式庫別處存在一支共用 scope resolver 會被讀成覆蓋，同時一個新的 call site 正在不呼叫它地重寫這個查詢。新階段與隱含規則掃描並行，機械化地推導出每一個以操作者自身身分為界的述詞——包含由 ORM global scope、repository 基底類別、RLS 政策、注入過濾條件的 middleware 在 SQL 之外執行的範圍，因為只 grep SQL 會回報一個比實際更小的集合，而在這裡更小的集合讀起來恰好就像更安全的集合。每個命中都記下 `file:line`、自我綁定與觸發分支；oracle 是「每個角色分支、逐 call site 的述詞等價性」，不是輸出形狀。RE-AUTH-001 要求一個斷言另一操作者紀錄**不存在**的負向測試（附自我檢查：在暫存副本裡把述詞刪掉，若測試還是通過，那它從來就不是在測範圍）；RE-AUTH-002 則對任何「移植後等價物未經驗證」的述詞 block cutover。
+- **寫下來的日期現在必須代表某件事（`tech-debt-standards` 1.1.0、`governance-layer` 1.1.0）。** 登記表範本從 1.0.0 起就要求 `Owner` 與 `Target Resolution Date`，而兩份標準裡沒有任何一處說那個日期過了會怎樣——對 `core/tech-debt-standards.md` grep `overdue|past due|expired|exceed` 零命中，而對照組 grep `Owner` 有命中，證明那個「查無」是真的、不是查詢工具壞掉。更嚴重的是 `Registry Storage Options` 把「專用試算表」列為完全合法：一份沒有任何程式讀得到的表格滿足本節其餘每一條要求，它沒有任何地方是錯的——直到日期過了，然後什麼都沒發生。`tech-debt-standards` 新增**到期處置**——到期時只有三種合法處置（做掉／撤銷／延期並寫明理由）、TD-EXP-001..006、明文禁止把到期實作成自動延期或自動關閉（兩者都讓時鐘停止，且都不留下停了的痕跡），以及給跑不動檢查的團隊的合規替代方案**無人看管宣告**。每個儲存選項現在都帶著「在什麼條件下它才合法」；試算表刻意保留，因為它常是出錢的人唯一會打開的格式。`governance-layer` 新增風險接受條款的 `review_by`（`review_by` 已過的接受不是有效條款，pipeline 必須 fail closed，與沒有條款時一樣）、**待裁決事項**（GOV-PD-001..004——待裁決是一種帶時鐘、帶固定列舉標記的受治理狀態，不是自由書寫的散文）、**匯總報告**（GOV-RPT-001..005——通過／失敗／**判不了**分開印出、寫出分母與其推導方式、不得合併成單一分數，因為一個「什麼都不做」與「把工作做完」得分相同的指標，量的不是那份工作），以及**新鮮度指標**（GOV-FRESH-001..004——指標必須指名自己讀的是編輯時間還是對帳時間，兩者不得共用欄位；一份今天剛編輯、從未與現實對過的文件，在其中一個時鐘上是零天、在另一個上是無上限）。兩份標準都在標準本文裡明白寫出 UDS 對這些規則不提供任何檢查器：最低標準不是「去建一支檢查器」，而是「絕不讓一筆記載在無聲中變成無人看管」。
+- **`uds audit --effects` —— 一道去問「這個回報成功的元件，到底做了什麼沒有」的閘門（XSPEC-383 R8）。** 形狀 D：可達、被呼叫、跑得動、回傳 `{ok: true}`，而它什麼都沒碰。R3 的可達性閘門看不見它——**可達性問的是入邊（誰呼叫它），形狀 D 的病灶在出邊（它最終碰到什麼），方向相反**。根因是**宣稱與證據共用同一個作者**：回傳值既是「我做了什麼」也是唯一的證據，而型別系統驗的那個形狀，對真實作與空殼**完全同構**。本閘門走訪每個宣告的實作的呼叫圖，量它是否觸及跨程序邊界。**邊界集合從 runtime 自讀**——由家族根名規則走訪 `builtinModules` 展開（`fs`、`child_process`、`net`/`dgram`/`tls`、`http`/`https`/`http2`、`dns`、`worker_threads`），不是手打清單，因此 `fs/promises` 與未來任何子路徑都不需要改程式；且**每條規則都印出自己展開了幾個**，展開 0 個就是規則過期了。免 import 的全域 API（`fetch`、`WebSocket`、`process.dlopen`）先探測當前 runtime 才納入，這個 Node 沒有的那些也一併印出來。家族**用 glob 宣告**在 `.uds/effect-boundary.json`，**不用檔名清單**——檔名清單在有人加上第七個 adapter 的那一刻就不再為真，而那正是本閘門存在的理由。判定三態：零命中判 RED（家族中位數 > 0 時帶「兄弟有對照組」的佐證；整個家族全為零時**組內比較集體沉默**，報告會明說這個 RED 只由絕對零判準支撐）；零命中但帶著無法分類的外部相依則是 **UNDECIDABLE 並 exit 2**——判成綠是 fail-open，判成紅是誣告。依 R7-b，**宣告 `NOT_IMPLEMENTED` 且從不回傳成功形狀的實作是合法的，不需要白名單**——這個連言很重要：只認關鍵字的話，那個字就是每個空殼將來要走的洞，而兩者同時出現的檔案會被**指名判 RED**。R7-c 抽出字串拼接產生的網域（模板內插與 `+` 串接一律折成 `*`，所以 `` `https://${env}.api.acme.example` `` 仍可判定，`` `https://api.${tld}` `` 不可判定），對照**來源可插拔**的持有清單：檔案、環境變數，或**指令**——那正是接註冊商或雲帳戶 DNS zone API 的位置。**宣告了卻讀不到 → exit 2**，絕不當成「清單為空所以什麼都合法」。基線是 **TSV，每列一個到期日**（§7.11.2），格式壞掉的列 exit 2，因為**壞掉的基線不是「沒有基線」**。做的過程中它第一次自測就抓到自己的真缺陷：**type-only import 被當成呼叫圖的邊**，於是空殼繼承了介面檔的邊界命中而判綠——型別 import 編譯後整行消失，把它算成命中是**憑空多出來的綠燈**。那個案例現在由一支專屬對照臂釘住。**它證明不了什麼**：碰到的那個邊界是不是**對的**那一個——打一發裝飾性 log 請求就能過關。那是 R9，本輪未做。UDS 自己沒有效果家族，所以不帶 config 直接跑會 exit 2，這是設計而非故障；CI 跑的是 `--self-test`，十七臂（五個探針對照組、分母、綠、紅、R7-b 濫用、R7-b 豁免、跨檔呼叫圖、邊界金絲雀、網域金絲雀、讀不到清單、空集合、不可判定、探針失效）在一份為本 repo 自己寫的合成語料上各自證明得出來。
+- **一道採用者跑得動的錯誤出口閘門。** `templates/gates/check-error-exit.mjs` 現在隨套件出貨。`uds check` 會在有 `src/` 卻沒有這道閘門的專案上報告，但從不寫入；`uds update` 會說明它是什麼並提議寫入，預設答案是**不要**，檔案已存在時絕不覆蓋。閘門容許一個檔案格式化錯誤訊息，第二個出現時才判紅；設定好之前一律 exit 2。
+- **`brainstorm-assistant`：判官現在需要心智，不只需要座位（XSPEC-388）。** BQS D4 必須同時有獨立 context 與宣告的模型層級才算通過，模型層級只能用 `core/model-selection.md` 的廠商中立標籤表達，指名具體廠商模型即違規。CONVERGE 評審提示改寫為「目標＋約束」。沒有移除任何 v3 機制。
+- **`llms.txt` 改為生成，不再手寫。** 由 `uds-manifest.json`、`core/`、`skills/`、`integrations/REGISTRY.json` 與 `cli/package.json` 推導，`--check` 在已提交的檔案差一個位元組時就失敗。
+
+### 變更
+
+- **P1 與 P3 回到探針集，而它們當初被砍的理由，現在成了另一種錯誤的實例（XSPEC-408）。** 兩者都在 2026-07-23 以「基線已通過」為由退役：在沒有安裝 UDS 的情況下對 Antigravity CLI 1.0.14 執行，模型會先讀檔再回答（P1），也會主動給出自己的推薦（P3）。這些觀察仍然成立；站不住的是退役這個結論。**每一支探針量的是兩件事——一個行為與一個宣告的標記——而被推翻的只有行為。** P1 的退役紀錄自己就寫出了這一點（「剩下的是：UDS 要求明確的 `[Source: <path>]` 標註，而基線用的是 markdown 檔案連結」），接著卻引用 §2.2「探針斷言結構，不斷言用詞」把剩下的部分丟掉。那個讀法不可能正確，因為 **P2 正是靠比對四個字面標籤存活**，而且是整組裡最耐用的探針；§4 自己的總結也早已得出「always-read 層耐用的部分看起來是宣告的形式與內部慣例，而不是知識」，而兩支宣告形式的探針就被砍在它下面幾段。§2.2 現在寫出它本來就該承載的區分：比對模型碰巧寫出的句子，量到的是運氣；比對**標準要求模型印出的標記**，量到的是標準有沒有送達。P1 與 P3 改寫成只問這個較窄的問題，而且兩者現在都會在答案*事實正確但沒有標記*時明確失敗——那正是它們存在要抓的情形。它們的 §2.3 入場基線不花任何一次新執行：留存的 2026-07-23 逐字稿重新計分後，`[Source:` 出現 **0 次**、`[Recommended]` 出現 **0 次**，各自都對照同一個讀取器在同一份檔案裡找到的陽性控制字串，所以那個 0 是「不存在」，而不是搜尋壞掉。`scripts/check-reinstated-probe-baselines.ts` 在每次 CI 執行時重新推導這兩個數字——一個讀過一次就打進文件的 0 是一枚戳，而這個 repo 已經記錄過戳會發生什麼事——其 `--self-test` 臂涵蓋標記出現（紅）、控制字串缺失（判不了，絕不是綠）與空逐字稿（判不了），三者皆經突變確認。**這件事沒有做到的**：提高 n。每支探針一次執行、一個工具、一個前沿模型、重讀一遍。`DELTA-TREND.md` 把這次重新計分記在它自己的子表裡，並明文禁止併入上方的總表；Codex 那一列加註其 50% 指的是*已退役*的 P1/P3——Codex 沒有留存任何 P1/P3 逐字稿，所以不像 Antigravity 有東西可以重新計分。當初讓這些探針被退役的那群對象——採用者在 aider 與 continue-dev 下執行的本機與量化模型——至今仍未被量測過，而一支探針的全部價值，就是在那群對象不再需要這條規則時告訴你。復原探針是把感測器裝回去；它沒有說它會讀到什麼。
+- **技能：每一個兄弟檔現在都能從自己的 `SKILL.md` 一跳到達。** 原本有 13 個兄弟檔（3,193 行）沒有任何東西指向它們，另有 56 個只能經由另一個兄弟檔到達；`skills/` 與各語系樹的 168 個兄弟檔現在全部是一跳，每一條指路都寫明檔案內容與何時該讀。這消除的是結構風險，並不證明兄弟檔真的會被讀。
+- **出貨的 `.ai.yaml` 的 `meta.updated` 改取自來源檔的 git 歷史**；git 查無紀錄時直接省略該欄位，不再用手打的日期或 transform 執行當天。
+- **`governance-layer`：Enforcement Reality 一節現在也點名較舊的風險接受欄位**（`review_by`、`risks_accepted`、`gates_bypassed`）沒有任何程式在讀。
+- **相依套件：** `chalk` 5.6.2 → 6.0.0、`js-yaml` 5.2.1 → 5.2.3（CLI 執行期）；`eslint`、`globals`、`lint-staged`、`tsx`（開發用）。
+- **repo 內部驗證（不影響採用者拿到的內容）：** 實跑 `uds init` 的採用者指示檔檢查；走訪路徑表每個工具的安裝路徑閘門；實際執行已安裝 Stop hook 的 hook 投遞閘門；比對內容的 bundle parity；skill 觸發面閘門；出貨戳一致性檢查器；翻譯 `source_hash` 棘輪；名稱提及分類器；STATUS.md 矛盾閘門；本 repo 的 `.claude/skills` 副本改為生成；skill 金絲雀儀器（XSPEC-408 R2）與它的首批真跑；P7 探針砍除；bump／sync 往返檢查移到每次 CI；測試套件不再受機器語系影響。
+
+### 棄用
+
+- **`contentMode: 'full'`——一個既有模式的第二個名字（XSPEC-357 R7）。** manifest schema 接受它、`--content-mode` 提供它、init 提示把它包裝成「拿 context 預算換合規」的取捨（「完整嵌入所有規則、約 10-15 KB、合規率最高」），而且每一個 `partial` 層級的工具都被自動指派它。這些一項都沒有被實作：產生器對模式的唯一判斷是 `=== 'minimal'`，因此 `full` 與 `index` 走同一條分支，**在實測的 24 組（工具 × 語言）組合中寫出逐位元相同的檔案**，且對照組證明該比較確實抓得到差異（`full` 對 `minimal` 在 24 組中全部不同）。它也不可能照宣稱的方式運作——`.standards/` 約 248k token，遠超過任何整合檔案裝得下的量。採用者是在兩個標籤之間選擇同一種行為，而那個標籤承諾了一個不存在的差異；文件甚至以法規理由建議銀行核心系統採用 `full`。**這次棄用對採用者的代價是零**：`--content-mode full` 仍然接受並解析為 `index`（附說明），manifest 中記錄的 `full` 會在下次讀取時改寫為 `index`，而由於兩個模式本來就產生相同的位元組，**任何專案產生的檔案都不會改變**。不認得的模式仍然解析為 `index`，但現在會印出警告並寫明那個值；7.0.0 起會改成直接報錯。`check-adopter-instruction-files.ts` 裡的 `content-mode=full` 情境——正是它「8 個檔案全部逐位元相同」的發現促成了這次移除——一併移除，而不是留著拿 `index` 跟 `index` 比、然後永遠回報「相同」。
+## [6.8.0] - 2026-08-20
+
+### 新增
+
+- **一道去問「這條 `uds <cmd>` 指示真的跑得動嗎」的閘門（XSPEC-383 R4）。** 2026-08-19 查到三個頂層指令（`uds install`、`uds lint`、`uds sync`）與兩個旗標（`uds check --spec-size`、`uds spec create --boost`）出現在出貨的指引裡而**它們都不存在**——落點包括 `quickstart.js`（它的整個工作就是「快速找到對的指令」）與 `integration-generator.js`（它把指令**寫進每一個採用者的 `CLAUDE.md`／`AGENTS.md`**）。兩處早已修掉（`465335e4`），而**沒有任何東西在確認那個修正會維持**。`check-command-existence.mjs` 走訪 `core/`、`locales/`、`ai/standards/`、`cli/src/`、`skills/`、`docs/` 與 repo 根目錄的 `*.md`，抽出每一個 `uds <cmd>` 樣式，用 `uds <path> --definitely-not-a-real-flag` 對本次 commit 自己的 CLI 探測——**不是 `--help`**：commander 對**未知**指令會回答通用指令表而不是報錯，而那正是 `uds lint`／`uds sync` 在第一輪檢查中存活的原因。
+- **同一支探針對現況再跑一次，翻出第一次事故的修正從未碰到的漂移。** `uds workflow`（v6.0.0 移除）在 `docs/user/CHEATSHEET.md`、`docs/reference/FEATURE-REFERENCE.md`、`skills/workflows/README.md`（及 zh-TW／zh-CN 鏡像）**被當成現行指令展示了五個月**，而 `docs/MIGRATION-v6.md` 自己就給了能抓到它的那條 grep。`uds config --lang`／`--mode` 從未存在（root `README.md`、兩份 locale、`docs/reference/INTEGRATION-VERIFICATION.md`）。`uds agent install --all` 把位置參數寫成旗標。`uds reverse-tdd` 是為了一段 GitHub Actions 範例**虛構出來的 CLI**。`uds check --interactive` 不存在，因為互動模式本來就是預設。**29 個發現，29 個修好，0 個殘留。**
+- **一道去問「有沒有人到得了這段程式碼」的閘門（XSPEC-383 R3）。** 單元測試證明函式是對的，對「有沒有使用者叫得到」一個字都沒說。2026-04-07 有一次 commit 加了 `spec-linter.js`（172 行、14 個測試全過）與 `sync.js`（133 行）——**兩者都從未被註冊**，而同一天有下游產品把自己接上 `npx uds lint --json`，一個因此永遠不會存在的指令。四個半月，兩邊全綠，中間沒有一條通的路。`check-module-reachability.mjs` 從 package.json 的 `bin` 與 `main` 出發做 BFS，**手查找到 2 個，走訪找到 24 個**，含整個九模組的 `src/flow/` 子系統。
+- **`uds lint`（XSPEC-383 R5）。** 註冊那個 linter 自 2026-04-07 起就在等的指令，帶著兩項禁得起真實 spec 考驗的檢查：相依有效性與篇幅。
+
+### 變更
+
+- **雜湊前先正規化行尾（#155）。** `uds check` 比對的是磁碟上的原始 bytes，於是 Windows 在 `core.autocrlf=true` 下的 checkout 把每個 LF 換成 CRLF，**每一個雜湊都不再吻合**——而「N 個檔案已修改」這句話，無論是有人改了 N 個檔還是平台改寫了每一個換行，讀起來完全一樣。走訪另外找到兩套從不經過 `hasher.js` 的雜湊實作，四處全修。新增 21 個測試，含負向對照：真實內容差異與尾隨空白差異，在 CRLF checkout 上仍須偵測得到。`uds check --force` 的輸出前後逐位元組相同，既有 manifest 不需要重新蓋章。
+- **使用說明產生器改為問 CLI，而不是背誦一份清單。** `scanCliCommands` 把 `cli/bin/uds.js` 讀進一個變數然後忽略它，改用一份註記著「based on uds.js analysis」的手寫陣列。於是**每一次重新產生都把已移除的 `uds workflow` 寫回文件**，也從來不會加入 `uds lint`。現在它解析 `uds --help`——CLI 對自己有哪些指令的權威回答，涵蓋任何單檔解析看不到的註冊寫法（`mcp` 完全由另一個模組註冊）。涵蓋率從 19/24 變成 **23/23**。
+
+### 移除
+
+- **`uds sync` 與 AC 覆蓋檢查（XSPEC-383 R5，選項 E）。** `sync.js` 零消費者。AC 覆蓋檢查對 93 份真實 spec 量測，回報 98 條驗收條件中 0 條被覆蓋——**不是因為它們沒有測試**，而是因為它用**位置**生成 AC 識別字（`AC-1`、`AC-2`）而不是讀規格宣告的那些，再用寫死的 `@` 前綴去找。一個寫 `AC-045-001` 並且標註不帶 `@` 的專案，無論追溯做得多完整都會得到零覆蓋。**它報的不是「這個專案沒有追溯」，而是「我用我自己的慣例去找，找不到」，而這兩句話印出來一模一樣。** 它是移除而不是留著不接：它是一個正確實作了一個唯一已知消費者並不使用的慣例的東西，躺在樹上等著被人重新接上。跨 repo 的 AC 識別字慣例調解是協商，不是補丁，另案處理。
+
 ## [6.7.5] - 2026-08-18
 
 ### 變更

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

@@ -14,7 +14,7 @@ status: current
 
 Universal Development Standards 是一個語言無關、框架無關的文件化標準框架。它提供：
 
-- **核心規範** (`core/`)：150 個基礎開發標準
+- **核心規範** (`core/`)：152 個基礎開發標準
 - **AI 技能** (`skills/`)：用於 AI 輔助開發的 Claude Code 技能
 - **CLI 工具** (`cli/`)：用於採用標準的 Node.js CLI
 - **整合** (`integrations/`)：各種 AI 工具的配置

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

@@ -2,8 +2,8 @@
 source: ../../README.md
 source_version: 6.0.0
 translation_version: 6.0.0
-last_synced: 2026-07-08
-source_hash: add024721b5a
+last_synced: 2026-08-19
+source_hash: d978c5775a25
 status: current
 ---
 
@@ -15,7 +15,7 @@ status: current
 
 > **語言**: [English](../../README.md) | 繁體中文 | [简体中文](../zh-CN/README.md)
 
-**版本**: 6.7.5 | **發布日期**: 2026-08-18 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
+**版本**: 6.9.0 | **發布日期**: 2026-09-14 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
 
 語言無關、框架無關的軟體專案文件標準。透過 AI 原生工作流，確保不同技術堆疊之間的一致性、品質和可維護性。
 
@@ -76,10 +76,10 @@ npx universal-dev-standards init
 <!-- UDS_STATS_TABLE_START -->
 | 類別 | 數量 | 說明 |
 |----------|-------|-------------|
-| **核心標準** | 150 | 通用開發準則 |
+| **核心標準** | 152 | 通用開發準則 |
 | **AI Skills** | 55 | 互動式技能 |
 | **斜線命令** | 51 | 快速操作 |
-| **CLI 指令** | 22 | 專案設定與維護 |
+| **CLI 指令** | 23 | 專案設定與維護 |
 <!-- UDS_STATS_TABLE_END -->
 
 > **5.0 新功能？** 請參閱[預發布說明](../../docs/PRE-RELEASE.md)了解新功能詳情。
@@ -198,9 +198,9 @@ uds uninstall   # 從專案移除標準
 
 | 參數 | 指令 | 說明 |
 | :--- | :--- | :--- |
-| **提交語言** | `uds config --lang zh-TW` | 設定 AI 提交訊息的偏好語言 |
+| **提交語言** | `uds config set output_language traditional-chinese` | 設定 AI 提交訊息的偏好語言 |
 | **標準** | `uds init` | 安裝所有可用標準 |
-| **工具模式** | `uds config --mode skills` | 在 Skills、Standards 或兩者之間切換 |
+| **工具模式** | `uds config --type content_mode` | 在 Skills、Standards 或兩者之間切換 |
 
 ---
 

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

@@ -13,7 +13,7 @@ status: current
 <!-- UDS_SUPPORTED_VERSIONS_START -->
 | 版本 | 支援狀態 |
 |------|--------|
-| 6.7.5 | ✅ 最新正式版 |
+| 6.9.0 | ✅ 最新正式版 |
 | < 6.0.0 | ❌ 已終止支援 |
 <!-- UDS_SUPPORTED_VERSIONS_END -->
 

package/bundled/locales/zh-TW/core/acceptance-criteria-traceability.md

@@ -195,6 +195,8 @@ Coverage = (5 + 2×0.5) / 8 = 6/8 = 75%
 | 基礎設施限制 | 測試環境限制 | 解決方案計畫 |
 | 延後至下一迭代 | 已與利害關係人確認 | Ticket 參照 |
 
+> 本標準產出的**延後項目**（`Gaps` 的 Uncovered AC／Partial AC、上表的例外、報告的 `Action Items`）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ---
 
 ## AC 覆蓋率報告格式

package/bundled/locales/zh-TW/core/adr-standards.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/adr-standards.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-03-26
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-08-24
 status: current
 ---
 
@@ -10,8 +10,8 @@ status: current
 
 > **語言**: [English](../../../core/adr-standards.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-03-26
+**版本**: 1.1.0
+**最後更新**: 2026-08-24
 **適用範圍**: 所有進行架構決策的軟體專案
 **範疇**: universal
 **產業標準**: ISO/IEC/IEEE 42010（架構描述）、TOGAF ADR
@@ -89,6 +89,23 @@ status: current
 - [相關 ADR、SPEC、PR 或外部參考]
 ```
 
+> 此範本中記下的**延後項目**（`Consequences` 下的既受風險與負面後果、被考慮而未採用的選項）適用 [deferred-item-exit](deferred-item-exit.md)。
+
+---
+
+## 驗收標準只在 SPEC 維護一份
+
+一份 ADR 記錄的是**決策**，它不帶自己的一份驗收標準。當一個決策有驗收標準時，
+它們**只在一處維護——SPEC**，而 ADR 以連結（`Technical Story` 或 `Links`）指向它。
+
+一份被複製的 AC 清單有兩個擁有者，而只有其中一個會被更新。實測後果是：
+實作完成、SPEC 的勾選框打勾，ADR 那一份**整份留在未勾選狀態**——
+讀 ADR 的人於是認為什麼都沒做，而讀 SPEC 的 AC 覆蓋率工具**根本看不到 ADR 裡那一份**。
+
+> 本條是關於 **AC 在哪裡維護**的邊界規則，不涉及 AC 的寫法或標註慣例。
+> AC 格式見 [spec-driven-development](spec-driven-development.md)；
+> AC 對驗證項的可追溯性見 [acceptance-criteria-traceability](acceptance-criteria-traceability.md)。
+
 ---
 
 ## ADR 編號
@@ -187,6 +204,8 @@ docs/adr/
 - [ ] **狀態**設定正確
 - [ ] **連結**到相關工件
 - [ ] 檔案存放在 `docs/adr/` 且命名正確
+- [ ] **沒有任何驗收標準被複製進 ADR** — 一律連結到維護它們的那份 SPEC
+- [ ] 每一個**延後項目**都載明其出口的識別字（[deferred-item-exit](deferred-item-exit.md)）
 
 ---
 
@@ -200,6 +219,8 @@ docs/adr/
 | 沒有後果分析 | 分析不完整 | 一定要列出正面和負面結果 |
 | 背景模糊 | 對未來讀者無用 | 包含具體的限制條件和驅動因素 |
 | 編輯已接受的 ADR | 歷史遺失 | 改用取代（Supersede）而非編輯 |
+| 把 SPEC 的驗收標準複製進 ADR | 兩個擁有者、只有一個會更新；ADR 那份留在未勾選，覆蓋率工具也看不到它 | 只在 SPEC 保留一份，並以連結指向 |
+| 既受風險沒有出口 | ADR 是唯一的載體，而它現在已被核准 | 給它一個出口，並在此載明該出口 |
 
 ---
 

package/bundled/locales/zh-TW/core/ai-instruction-standards.md

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/ai-instruction-standards.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-05-28
+source_version: 1.1.1
+translation_version: 1.1.1
+last_synced: 2026-08-19
 status: current
 ---
 
@@ -215,7 +215,7 @@ translation_version: {本翻譯的版本}
 |------|------|--------|
 | **Canonical 擁有者** | `core/{name}.md`、`core/{name}.ai.yaml`、`skills/{name}/SKILL.md` | 維持 L1/L2/L3/L4 為英文；每次 breaking change 時 bump `source_version` |
 | **Locale 維護者** | `locales/{lang}/...` 檔 | `translation_version` 對齊 `source_version`；翻譯 L1（必）、L2（選）、L3（必）、L4（建議）|
-| **採用者（下游專案）** | 自己的 `.claude/skills/`、`CLAUDE.md` 等 | 用 `uds install --locale {lang}` 安裝；**絕不**手動修改 canonical 檔（要客製化請用 locale 變體或 overlay）|
+| **採用者（下游專案）** | 自己的 `.claude/skills/`、`CLAUDE.md` 等 | 用 `uds init --locale {lang}`（首次）或 `uds update --locale {lang}`（重新同步）安裝；**絕不**手動修改 canonical 檔（要客製化請用 locale 變體或 overlay）|
 
 ### Chimera 防範
 
@@ -237,7 +237,8 @@ Pre-commit / CI lint 強制 error 級規則；warn 級規則只在 dashboard 揭
 採用者透過 UDS CLI 安裝指令檔：
 
 ```bash
-uds install --locale zh-TW   # 以繁體中文安裝 skills 與 standards
+uds init --locale zh-tw     # 首次以繁體中文安裝 skills 與 standards
+uds update --locale zh-tw   # 對既有採用重新同步
 ```
 
 **Locale 解析優先順序**：
@@ -258,7 +259,7 @@ uds install --locale zh-TW   # 以繁體中文安裝 skills 與 standards
 若採用者已手動修改過專案中的 canonical 檔（例：在 `.claude/skills/` 翻譯了描述）：
 
 1. **辨識 chimera**：比對採用者檔案與 UDS canonical / canonical 的 locale 變體。
-2. **安裝正確變體**：執行 `uds install --locale {lang}` 替換 chimera 為 locale 變體。
+2. **安裝正確變體**：執行 `uds update --locale {lang}` 替換 chimera 為 locale 變體。
 3. **保留專案級客製**：若 chimera 含合理的專案級客製（非翻譯），抽出為 overlay 或記錄到客製化日誌（例：`UDS-CUSTOMIZATION.md`）。
 4. **丟棄純翻譯**：chimera 中純翻譯部分直接丟棄——locale 變體會取代它。
 
@@ -270,8 +271,9 @@ uds install --locale zh-TW   # 以繁體中文安裝 skills 與 standards
 | 更新 canonical | 改進英文 source | Bump `source_version`；通知 locale 維護者 |
 | 翻譯 / 同步 locale | 新增或更新 locale 內容 | Bump `translation_version`；參照當前 `source_version` |
 | 檢查覆蓋率 | 定期 review | 看自動產生的 `locales/COVERAGE.md` |
-| 帶 locale 安裝 | 採用者初設或重新同步 | `uds install --locale {lang}` |
-| 跑 i18n lint | Commit 前 / CI | `uds lint --i18n` |
+| 帶 locale 安裝 | 採用者初設 | `uds init --locale {lang}` |
+| 帶 locale 重新同步 | 既有採用 | `uds update --locale {lang}` |
+| 跑 i18n lint | Commit 前 / CI | `uds check --i18n` |
 
 ---
 

package/bundled/locales/zh-TW/core/code-review-checklist.md

@@ -286,6 +286,8 @@ Is there a specific reason for this approach?
 
 > 此評論前綴方式與 [Conventional Comments](https://conventionalcomments.org/) 規範一致，該規範在團隊和工具間標準化了審查回饋格式。
 
+> Review 產出的**延後項目**（本次未改而被接受的非阻斷留言：`⚠️ IMPORTANT`、`💡 SUGGESTION`、`[SUGGESTION]`、`[NIT]`）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ### 替代方案：文字標籤
 
 對於偏好純文字標籤（無 emoji）的團隊：

package/bundled/locales/zh-TW/core/container-image-standards.md

@@ -2,8 +2,8 @@
 source: ../../../core/container-image-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: ac8280a5b7cf
+last_synced: 2026-07-23
+source_hash: 6bf9872a3d26
 status: current
 ---
 

package/bundled/locales/zh-TW/core/contract-testing-standards.md

@@ -2,8 +2,8 @@
 source: ../../../core/contract-testing-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-02
-source_hash: 2afa2fe434a6
+last_synced: 2026-07-23
+source_hash: b2b6acbac739
 ---
 
 # 合約測試標準（Contract Testing Standards）

package/bundled/locales/zh-TW/core/cross-flow-regression.md

@@ -1,20 +1,21 @@
 ---
 source: ../../../core/cross-flow-regression.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-06-02
-source_hash: 2f7bdbe6dc36
-status: stale
+source_version: 1.0.1
+translation_version: 1.0.1
+last_synced: 2026-07-23
+source_hash: 33da58d89648
+status: current
 ---
 
 # 跨流程回歸（Cross-Flow Regression）
 
 > **語言**：[English](../../../core/cross-flow-regression.md) | 繁體中文
 
-**版本**：1.0.0
-**最後更新**：2026-05-05
+**版本**：1.0.1
+**最後更新**：2026-06-18
 **適用範圍**：所有具有多個 user flow 或業務流程的軟體專案
 **Scope**：universal
+**Owning Spec**：XSPEC-294（與 flow-based-testing 互補；不重疊）
 **業界標準**：ISTQB Advanced Test Analyst（Regression Test Strategy）
 **參考資料**：`core/flow-based-testing.md`、`core/testing-standards.md`
 

package/bundled/locales/zh-TW/core/data-contract.md

@@ -2,8 +2,8 @@
 source: ../../../core/data-contract.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: ef59d3f2e128
+last_synced: 2026-07-23
+source_hash: 013be9325b53
 status: current
 ---
 

package/bundled/locales/zh-TW/core/data-migration-testing.md

@@ -2,8 +2,8 @@
 source: ../../../core/data-migration-testing.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-28
-source_hash: 990309b5e8b1
+last_synced: 2026-07-23
+source_hash: bda91214a3b7
 status: current
 ---
 

package/bundled/locales/zh-TW/core/data-pipeline.md

@@ -2,8 +2,8 @@
 source: ../../../core/data-pipeline.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 5a7a49049bd8
+last_synced: 2026-07-23
+source_hash: 725ebadd1c75
 status: current
 ---