universal-dev-standards 6.7.5 → 6.9.0

package/bundled/locales/zh-TW/core/governance-layer.md

@@ -1,8 +1,9 @@
 ---
 source: ../../../core/governance-layer.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-05-07
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-08-20
+source_hash: 15ca18717240
 status: current
 ---
 
@@ -10,8 +11,8 @@ status: current
 
 > **語言**: [English](../../../core/governance-layer.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2026-05-07
+**版本**: 1.1.0
+**最後更新**: 2026-08-20
 **適用範圍**: 所有具有多 Agent 或多角色 AI 工作流程的軟體專案
 **範疇**: universal
 **產業標準**: 無（UDS 原創）
@@ -130,9 +131,79 @@ Vision（方向）→ Mission（邊界 + 紅線）→ Goals（可量測的 KPI
 | `signatory` | 接受風險的人員或角色 |
 | `gates_bypassed` | 列舉所有繞過的人工閘門 |
 | `risks_accepted` | 明確描述已接受的風險 |
+| `review_by` | 本次接受失效、必須重新做一次判斷的日期 |
 
 若無有效的風險接受條款，pipeline **必須拒絕啟動（fail-closed）**。
 
+### 接受到期
+
+`review_by` 已過的條款**不是有效條款**。pipeline 必須 fail closed，與完全沒有條款時一模一樣。
+
+`date` 記錄的是「何時接受了這個風險」，不是「何時該重新判斷」。沒有 `review_by`，簽過一次的接受就永遠有效——當初支持它的條件可能已經改變、簽署人可能已經離開專案，而條款裡每一個欄位讀起來仍然完全正確。
+
+到期時，必須施用且只能施用下列三種處置之一，與[技術債標準 → 到期處置](tech-debt-standards.md#到期處置)所定義的三種相同：
+
+| 處置 | 意義 |
+|------|------|
+| **重新接受** | 由當下的簽署人重新簽署，並給出新的 `review_by` |
+| **撤銷** | 移除該繞過，恢復人工閘門 |
+| **延期** | 新的 `review_by` **與**書面理由，一起記下 |
+
+**禁止自動延長 `review_by`。** 那會把一道 fail-closed 的閘門變成 fail-open，而所有欄位看起來都還是對的——失效之所以隱形，正是因為條款仍然驗證得過。
+
+---
+
+## 待裁決事項
+
+「還沒決定」是一種治理狀態，不是治理的缺席。規格裡的未決問題、提出但未批准的紅線、沒有 owner 的 KPI——每一項都是有人被期待要做的決定，而每一項對「只讀已做成決定」的檢查都是隱形的。
+
+待裁決事項與已接受風險**同級受治理**：它們帶時鐘，而且必須可被列舉。
+
+**規則 GOV-PD-001（必要）**——專案必須宣告待裁決事項**記在哪裡**，以及**什麼標記代表一項待裁決**：一個固定的 token（狀態值、標籤、字面標記字串），不得是自由書寫的散文。列舉不該取決於讀者猜中當初用了哪些字。三份分別寫「TBD」「待拍板」「待確認」的文件，是三份無法被列舉的文件；一個宣告過的標記讓三份都找得到。
+
+**規則 GOV-PD-002（必要）**——列舉待裁決事項時，必須同時回報總數**與**無法解析的來源份數（見[匯總報告](#匯總報告)）。「查無待裁決事項」在不知道走訪集合有多大時，不帶任何資訊。
+
+**規則 GOV-PD-003（必要）**——每一項待裁決事項都帶一個**裁決期限日期**。到期時適用與逾期技術債相同的三種處置——**做出決定**、**撤回這個問題**、或**延期並寫明理由**。禁止自動延期。
+
+**規則 GOV-PD-004（必要）**——若沒有任何東西在排程上列舉待裁決事項，專案必須帶一份**無人看管宣告**，寫明負責人、複查頻率與最後複查日期——與技術債登記表被要求的兩態規則相同。沒有被列舉是可接受的；沒有被列舉又沒有宣告則不可接受。
+
+> 一項沒有日期的待裁決事項，在行為上與「決定不做」完全相同。差別只在於待裁決的形式讓人以為還有人會去看它。
+
+---
+
+## 匯總報告
+
+每一份治理報告——合規摘要、閘門報告、KPI 匯總、紅線掃描——都是對某個集合提出的宣稱。這個宣稱的價值，恰好等於它對「自己判不了什麼」的交代的價值。
+
+**規則 GOV-RPT-001（必要）**——報告必須印出三個數字，不能只印兩個：**通過**、**失敗**、**判不了**（無法解析的檔案、缺欄位、來源不可達、不支援的格式）。
+
+**規則 GOV-RPT-002（必要）**——「判不了」**不得**併入「通過」，也**不得**省略。一份解析不了的檔案不是一份乾淨的檔案。只印「N 項檢查通過」的報告，不論 N 是多少都不合規。
+
+**規則 GOV-RPT-003（必要）**——報告必須寫出自己的**分母**以及分母是怎麼推導出來的。範圍來自硬編碼清單的報告，是一份關於那份清單的報告，不是關於這個專案的報告：清單之外的東西全部腐壞，它照樣是綠的。要用「走訪並排除」推導集合，不要用列舉——見[類別層級修正](class-level-fix.md)。
+
+**規則 GOV-RPT-004（必要）**——正向與負向計數分開回報；絕不合併成單一的合規分數。**一個「什麼都不做」與「把工作做完」得分相同的指標，量的不是那份工作。**「11 項中通過 5 項」與「檢查器從未啟動」產生同一個數字，而單一分數分不出這兩者。
+
+**規則 GOV-RPT-005（建議）**——當報告的正確性取決於它自己的工具能運作時，加一隻金絲雀：一個輸入已知會失敗、因此**必須**失敗的檢查。若金絲雀通過了，整份報告不可信，必須整份回報為「判不了」，而不是綠燈。
+
+---
+
+## 新鮮度指標
+
+**規則 GOV-FRESH-001（必要）**——任何新鮮度／停滯指標都必須指名它讀的是下列哪一個時鐘：
+
+| 時鐘 | 回答的問題 | 可以從哪裡讀 |
+|------|-----------|-------------|
+| **編輯時間** | 這份產物上次被改動是多久以前？ | 檔案 mtime、最後動到它的 commit、「最後更新」欄位 |
+| **對帳時間** | 這份產物上次與它宣稱在描述的真實來源做比對是多久以前？ | 那次比對被記下的日期——沒有別的東西能提供它 |
+
+**規則 GOV-FRESH-002（必要）**——兩者**不得**共用同一個欄位或同一個欄位標題。它們回答不同的問題，而同一份產物可以在其中一個上滿分、在另一個上任意地舊：一份今天剛編輯、內容從未與現實對過的文件，以編輯時間算是零天，以對帳時間算是無上限。
+
+**規則 GOV-FRESH-003（必要）**——只有編輯時間可取得時，報告必須把該欄標示為編輯時間，**並且**把對帳時間回報為「判不了」（GOV-RPT-001）——絕不能標成新鮮，也絕不能省略不提。
+
+**規則 GOV-FRESH-004（建議）**——對帳時間只有在「由執行該比對的東西自己記下」時才有意義。事後由人手動填入的日期是一項斷言，不是一次量測；請如實標示。
+
+> 這是「單軸裝多維」的失敗：一個欄位，被兩個不同的問題讀取。這個欄位永遠不會被抓到是錯的，因為從來沒有人問過它在回答哪一個問題。
+
 ---
 
 ## 治理檔案結構
@@ -156,4 +227,46 @@ governance/
 - [ ] Goals 清單存在，每個 KPI 均含：id、metric_name、threshold、measurement_method
 - [ ] 沒有任何 KPI 使用模糊詞彙（「改善」、「提升」、「更好」）
 - [ ] 若 `gate.mode = trace_only`，`mission.md` 中存在風險接受條款
+- [ ] 每一份風險接受條款都有 `review_by` 日期，且沒有任何一份已經過期
+- [ ] 專案已宣告待裁決事項記在哪裡、以及哪一個固定標記代表一項待裁決
+- [ ] 每一項待裁決事項都有裁決期限日期
+- [ ] 待裁決事項要麼被某個會執行的東西列舉，要麼被無人看管宣告涵蓋
+- [ ] 每一份治理報告都分開印出「通過／失敗／**判不了**」，並寫出分母與分母的推導方式
+- [ ] 沒有任何報告把正向與負向計數合併成單一分數
+- [ ] 每一個新鮮度指標都指名自己讀的是編輯時間或對帳時間，且兩者不共用欄位
 - [ ] 所有 AI 評估器以 0.4/0.3/0.3 權重評分，且任一軸 < 0.3 即不通過
+
+---
+
+## 執行現實
+
+> **本標準對它的任何一條規則都不提供檢查器——不只是 1.1.0 新增的那些，也包括自 1.0.0 起就在裡面的那條 fail-closed 風險接受要求。這是已知代價，寫在這裡，而不是留給採用者自己撞到。**
+> 
+> 2026-08-20 實測：`review_by`、`risks_accepted`、`gates_bypassed` **沒有出現在任何程式裡**——UDS CLI 沒有，任何消費端也沒有。那句寫著 pipeline「必須拒絕啟動」的條款，在它被寫下來的三個半月裡，**從來沒有讓任何一條 pipeline 拒絕啟動過**。把這件事講明白不是外加的但書，它就是本節自己的規則套用在本節身上；而本節的初稿只列出新規則為未執行，那會讓人以為舊的那條有在執行。
+>
+> UDS 定義的是這些要求，它不提供執行這些要求的程式。想要它們被執行的採用者必須自己寫那支列舉器、那支三態計數報告器、那個對帳日期記錄器——而多數人不會寫。那正是本標準所描述的失敗，現在同樣適用於本標準自己。
+>
+> 所以最低標準**不是**「去把工具做出來」，而是：**任何被記載為待裁決、已接受、或新鮮的東西，要麼指向一個會執行的檢查，要麼明白說出沒有東西在看它。** 宣告「無人看管」是合規的。無人看管卻不宣告，才是這些規則真正禁止的唯一結果，因為只有它會讓讀者對「有沒有東西在看」產生誤解。
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.1.0 | 2026-08-20 | 新增：風險接受條款的 `review_by` 欄位 + 接受到期的三種處置與禁止自動延期；待裁決事項（GOV-PD-001..004）；匯總報告（GOV-RPT-001..005——通過／失敗／判不了、分母推導、不得合併成單一分數、金絲雀）；新鮮度指標（GOV-FRESH-001..004——編輯時間與對帳時間不得共用欄位）；執行現實說明；合規檢查清單擴充 |
+| 1.0.0 | 2026-05-07 | 初始版本：Vision/Mission/Goals 三層架構、紅線格式、評估器整合、風險接受條款、合規檢查清單 |
+
+---
+
+## 相關標準
+
+- [技術債標準](tech-debt-standards.md) — 「到期處置」定義了本標準沿用的三種處置
+- [類別層級修正](class-level-fix.md) — 以走訪並排除而非列舉推導集合（GOV-RPT-003）
+- [驗證證據](verification-evidence.md) — 為何綠燈必須被證明來自一個真的在運作的檢查（GOV-RPT-005）
+
+---
+
+## 授權
+
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 釋出。

package/bundled/locales/zh-TW/core/iac-design-principles.md

@@ -2,8 +2,8 @@
 source: ../../../core/iac-design-principles.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 6cf9c75621e0
+last_synced: 2026-07-23
+source_hash: beecfddec375
 status: current
 ---
 

package/bundled/locales/zh-TW/core/incident-response.md

@@ -2,8 +2,8 @@
 source: ../../../core/incident-response.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: b1c1a516710b
+last_synced: 2026-07-23
+source_hash: 251b05a9fd51
 status: current
 ---
 

package/bundled/locales/zh-TW/core/model-provenance.md

@@ -2,8 +2,8 @@
 source: ../../../core/model-provenance.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 62e6b25a38dd
+last_synced: 2026-07-23
+source_hash: 59e471405e7e
 status: current
 ---
 
@@ -15,6 +15,8 @@ status: current
 > **AI 最佳化版本**: `ai/standards/model-provenance.ai.yaml`
 > **規格**: XSPEC-255 (cross-project/specs/XSPEC-255-model-provenance-policy.md)
 
+**Scope**: universal
+
 ## 概述
 
 模型選擇不只是「成本 × 品質」——還有 **第三軸：模型的*來源*是否被客戶接受**（地緣政治 /

package/bundled/locales/zh-TW/core/pii-classification.md

@@ -1,17 +1,17 @@
 ---
 source: ../../../core/pii-classification.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: f4ff92c3fe1d
-status: stale
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-07-23
+source_hash: 16bf07c4e383
+status: current
 ---
 
 # PII 分類與處理標準
 
 > **Language**: [English](../../../core/pii-classification.md) | 繁體中文
 
-> **版本**: 1.0.0 | **狀態**: Active | **更新日期**: 2026-06-17
+> **版本**: 1.1.0 | **狀態**: Active | **更新日期**: 2026-06-19
 > **AI 最佳化版本**: `ai/standards/pii-classification.ai.yaml`
 > **規格**: XSPEC-066（cross-project/specs/XSPEC-066-uds-compliance-audit-pack.md）
 
@@ -90,6 +90,41 @@ TIER-1 或 TIER-2 PII 的跨國境傳輸 MUST 遵循適用的傳輸機制。EU
 - **`database-standards`**——資料字典欄位帶有 PII 等級與 REQ-002 的文件化目的／
   法律依據。
 
+## PII 發現與交接契約
+
+上述整合僅指出了消費方，但交接需要明確定義的**觸發點、介面、負責人與狀態**——
+否則「驅動遮罩規則」只是一種主張，而非契約。本節沿用 `data-contract` REQ-005
+的消費方註冊模型，以及 `agent-communication-protocol` §3 的結構化交接形式。
+
+### 觸發點——分類何時啟動
+
+| 時機 | 發生的事 |
+|------|----------|
+| 新功能設計 | REQ-006 PII 衝擊評估**須於**實作前為每個新 PII 欄位分類 |
+| PR／掃描時 | 帶有 PII 但無等級標記的欄位為**阻擋（blocking）**發現（CI） |
+| 資料字典變更 | `database-standards` 欄位新增／移除 PII 等級 → 重新通知消費方 |
+
+### 介面——傳遞的內容
+
+生產方產出物是每個欄位的**PII 分類登錄（registry）**項目：
+`{ field, tier (TIER-1/2/3), purpose, legal_basis, masking_rule, retention }`。
+消費方依此註冊（依 `data-contract` REQ-005），並於變更時收到通知。
+
+### 負責人與已註冊消費方
+
+| 角色 | 職責 |
+|------|------|
+| 資料負責人／功能作者 | **產出**分類結果（REQ-001／REQ-006） |
+| `logging-standards`（消費方） | 對非正式環境中的 TIER-1/2 套用 `masking_rule` 並記錄日誌 |
+| `audit-trail`（消費方） | 記錄必備的存取／匯出／刪除事件 |
+| `security-standards`（消費方） | 對 TIER-1 強制執行靜態／傳輸中加密 |
+| 隱私／合規負責人 | 於任何新增 TIER-1 欄位或分類變更時**收到通知** |
+
+### 狀態轉換
+
+`Found（已發現）→ Classified（已分類，已指定等級）→ Handled（已處理：遮罩／加密／已設定保留期）→ Verified（已驗證：消費方確認規則已套用）`。
+停留在 `Found`（有 PII 但無等級）狀態的欄位**將阻擋發布**（REQ-001 + 上述 PR 時觸發規則）。
+
 ## 相關規格
 
 - XSPEC-066 — UDS 合規與稽核標準包（本標準來源）
@@ -99,4 +134,5 @@ TIER-1 或 TIER-2 PII 的跨國境傳輸 MUST 遵循適用的傳輸機制。EU
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
+| v1.1.0 | 2026-06-19 | 新增：PII 發現與交接契約（觸發點／介面／負責人／狀態），使宣稱與 logging-standards／audit-trail 的交接成為明確契約而非空談（XSPEC-292 T16） |
 | v1.0.0 | 2026-06-17 | 初版——REQ-001~006：PII 等級、資料最小化、非正式環境遮罩、保留／刪除、跨境傳輸、PIA（XSPEC-066） |

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

@@ -2,8 +2,8 @@
 source: ../../../core/prd-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 3addb642ee83
+last_synced: 2026-07-23
+source_hash: 73615684c1be
 status: current
 ---
 
@@ -15,6 +15,8 @@ status: current
 > **AI 最佳化版本**: `ai/standards/prd-standards.ai.yaml`
 > **規格**: XSPEC-069（cross-project/specs/XSPEC-069-uds-product-layer-pack.md）
 
+**Scope**: universal
+
 ## 概觀
 
 本標準定義**產品需求文件（PRD）**的結構、內容要求與生命週期治理。涵蓋五大必備

package/bundled/locales/zh-TW/core/product-metrics-standards.md

@@ -2,8 +2,8 @@
 source: ../../../core/product-metrics-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: e37a44aefd92
+last_synced: 2026-07-23
+source_hash: 111babd0b39d
 status: current
 ---
 
@@ -15,6 +15,8 @@ status: current
 > **AI 最佳化版本**: `ai/standards/product-metrics-standards.ai.yaml`
 > **規格**: XSPEC-069（cross-project/specs/XSPEC-069-uds-product-layer-pack.md）
 
+**Scope**: universal
+
 ## 概觀
 
 本標準定義團隊如何**選擇、結構化與治理產品指標**。涵蓋框架選用矩陣（成長型用

package/bundled/locales/zh-TW/core/release-readiness-gate.md

@@ -2,8 +2,8 @@
 source: ../../../core/release-readiness-gate.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-02
-source_hash: 3d156e19680e
+last_synced: 2026-07-23
+source_hash: 622d8cb59abb
 ---
 
 # 發布就緒閘門（Release Readiness Gate）

package/bundled/locales/zh-TW/core/resource-cost-boundary.md

@@ -2,8 +2,8 @@
 source: ../../../core/resource-cost-boundary.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: a9be6a420041
+last_synced: 2026-07-30
+source_hash: 9c3d4359e7a0
 status: current
 ---
 

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

@@ -1,8 +1,8 @@
 ---
 source: ../../../core/retrospective-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
 ---
 
@@ -90,6 +90,8 @@ Open ──► In Progress ──► Done
   └──► Cancelled（附原因）
 ```
 
+> Retrospective 記下的**延後項目**（`Action Items`、`Previous Action Items Review` 中仍為 Open 的列、附理由 Cancelled 的項目）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ### 追蹤規則
 
 1. 在每次回顧的**開頭**檢視所有未完成的行動項目。

package/bundled/locales/zh-TW/core/reverse-engineering-standards.md

@@ -1,15 +1,15 @@
 ---
 source: ../../../core/reverse-engineering-standards.md
-source_version: 1.2.0
-translation_version: 1.2.0
-last_synced: 2026-06-27
+source_version: 1.3.0
+translation_version: 1.3.0
+last_synced: 2026-08-20
 status: current
 ---
 
 # 反向工程標準
 
-**版本**: 1.2.0
-**最後更新**: 2026-06-27
+**版本**: 1.3.0
+**最後更新**: 2026-08-20
 **適用範圍**: 所有需要將程式碼轉換為規格文件的專案
 
 > **語言**: [English](../../../core/reverse-engineering-standards.md) | [繁體中文](reverse-engineering-standards.md)
@@ -58,10 +58,13 @@ status: current
 | **程式碼掃描** | 分析程式碼結構、API、資料模型 | 技術清單 | [已確認] |
 | **測試分析** | 解析現有測試以取得驗收條件 | 草擬驗收條件 | [已確認]/[推論] |
 | **隱含規則掃描** | 掃描非 HTTP 持久化寫入路徑中未文件化的規則 | 隱含規則清單 + 三問解答 | [已確認]/[推論]/[未知] |
+| **授權範圍擷取** | 擷取每一個以操作者自身身分為界的查詢述詞 | 自我限縮述詞清單 + 必要的負向測試 | [已確認]/[推論]/[未知] |
 | **缺口識別** | 列出需要人類輸入的未知項目 | 缺口分析文件 | [未知] 項目 |
 | **規格生成** | 生成草擬規格 | 草擬 SPEC-XXX.md | 混合確定性 |
 | **人類審查** | 利害關係人驗證與填補缺口 | 已驗證的規格 | [已確認] |
 
+> **註（v1.3.0）**：**授權範圍擷取** 階段與隱含規則掃描並行——詳見下方[授權範圍擷取（自我指涉的查詢述詞）](#授權範圍擷取自我指涉的查詢述詞)。隱含規則掃描處理的是「因為跑在請求路徑**之外**而隱形」的規則；本階段處理的是「坐在一條被完整操作過的請求路徑**之上**卻仍然隱形」的規則：一個以操作者自身身分為界的 `WHERE` 述詞。它讀起來就像眾多過濾條件之一，而一次把它丟掉的重寫，會回傳形狀完全正確的資料——屬於所有人的資料。
+>
 > **註（v1.2.0）**：在程式碼掃描／測試分析之後、缺口識別之前，插入一個 **隱含規則掃描** 階段——詳見下方[隱含規則掃描（非 HTTP 持久化規則）](#隱含規則掃描非-http-持久化規則)。標準程式碼掃描只提取 HTTP 入口點與資料模型，但持久化欄位的值經常由**非 HTTP 路徑**（cron、佇列、計算欄、trigger、ORM hook）寫入，其業務規則從未被文件化——這是跨語言重寫或跨 DB 遷移時遺漏邏輯的最高發來源。
 
 ---
@@ -105,6 +108,80 @@ pre-flight（規劃期）。任何三問未獲解答的非 HTTP 寫入欄位會
 
 ---
 
+## 授權範圍擷取（自我指涉的查詢述詞）
+
+> **工作流程位置**：與隱含規則掃描並行——在程式碼掃描／測試分析之後、缺口識別之前。
+
+**自我指涉述詞**是一個以「誰在問」為界限來限縮結果集的查詢條件：`WHERE tenant_id = :current_user_tenant`、`WHERE owner = :uid`、`WHERE dept_id = (SELECT dept_id FROM member WHERE account = :uid)`。它就是那一行把「列出帳號」變成「列出**你的**帳號」的條件。
+
+本階段要回答的問題很窄、也很機械：
+
+> **舊碼裡每一個以操作者自身身分為界的查詢述詞，新碼有沒有等價的述詞？**
+
+不是「回傳的形狀一不一樣」，也不是「有沒有回傳資料」。是**等價的述詞**：同一個欄位，綁定到同一個「自己」的定義。
+
+### 為什麼它需要自己的階段
+
+授權不是一個被漏掉的關注點——任何像樣的測試分類法都已經點名跨租戶存取是該測的東西。這個關注點不會消失，**它是不會被想起來**。有三個性質讓這個特定缺陷能穿過每一道本該擋住它的閘門：
+
+1. **那條安全關鍵的程式碼看起來像個過濾條件。** 界限住在 `WHERE` 子句裡，不在請求／回應契約裡。負責移植「取得所有帳號」的人看到的是一個 `SELECT` 和一個 `JOIN`；租戶述詞讀起來就是眾多條件之一。
+2. **基於形狀的斷言看不見範圍。** 一個以某個有效管理員身分呼叫該 endpoint、斷言 `200` 加非空清單的測試，在「範圍限縮正確」與「範圍限縮被整條刪掉」兩種情況下**完全一樣地通過**。契約測試、對等快照、response DTO 比對在此結構上全是盲的：兩種情況下回應都是良構的，它只是屬於所有人。
+3. **有一個共用的 resolver，不等於這個 call site 有在用它。** 已經被燒過一次的程式庫通常會長出一支共用的範圍解析工具。一個新的或被忽略的 call site 可以從頭重寫這個查詢而從未呼叫它——此時那支工具的存在反而具有主動誤導性，因為它讀起來像是覆蓋。
+
+### 清單來源（derive，機械化）
+
+掃描舊系統的資料存取層來列舉候選述詞——不要靠回憶。模式依技術棧調整；目標是任何「右手邊解析成**呼叫者自己的值**」的條件：
+
+| 訊號 | 範例 |
+|------|------|
+| **直接自我綁定** | `WHERE <col> = :currentUser` / `:uid` / `$operatorId` / `session.user_id` |
+| **租戶／組織／擁有者欄位** | `tenant_id`、`org_id`、`master_account`、`owner_id`、`dept_id`、`company_id` 與呼叫者導出的值比較 |
+| **解析呼叫者範圍的子查詢** | `WHERE dept_id = (SELECT dept_id FROM member WHERE account = :uid)` |
+| **依角色分支的查詢建構** | 依 `role`／`account_type` 分支，而**每個分支**套用不同範圍——要列舉每一個分支，不是只列 happy path 走到的那個 |
+| **在 SQL 之外套用的範圍** | ORM global scope、query builder mixin、repository 基底類別、row-level security 政策、注入過濾條件的 middleware |
+
+最後一列很重要：一個述詞可以由 `SELECT` 語句從未提及的東西來執行。只 grep SQL 會回報一個**比實際更小**的集合，而在這裡，更小的集合讀起來恰好就像更安全的集合。
+
+### 逐項記錄
+
+對每個候選項記錄——`[已確認]` 必須附 `file:line` 引用：
+
+| 欄位 | 內容 |
+|------|------|
+| **位置** | 舊碼中的 `file:line` |
+| **述詞** | 條件的原文 |
+| **自我綁定** | 它解析到哪一個呼叫者導出的值，以及那個值是怎麼取得的 |
+| **觸發分支** | 哪一個角色／參數／程式路徑會走到這個述詞 |
+| **確定性** | `[已確認]`／`[推論]`／`[未知]` |
+
+每個 `[未知]`——你無法從程式碼判定的範圍——都交給缺口識別由人類處理。絕不臆測，也絕不假設它不存在。
+
+### Oracle（detect）——述詞等價性，逐 call site
+
+對每個記錄下來的述詞，在移植後的程式碼中驗證：
+
+1. **存在字面上的等價物**——同一個欄位，綁定到同一個「自己」的定義。一個「剛好對現有資料回傳相同列」的不同欄位不是等價物，它是一個帶到期日的巧合。
+2. **每一個分支都被涵蓋。** 若舊碼依角色套用不同範圍，每個分支都需要各自被驗證過的等價物。把五個角色分支塌縮成一個粗糙的「這是不是管理員？」檢查，等於用一個權限取代了一道界限。
+3. **這個 call site 有呼叫共用 resolver。** 若新系統把範圍限縮集中在某支工具裡，要確認**這一個** call site 真的有呼叫它。那支工具存在於程式庫別處，不構成關於這個 endpoint 的證據。
+
+### 必要的負向測試
+
+**規則 RE-AUTH-001（必要）**——每一個已確認的自我限縮述詞都必須被一個**負向測試**鎖住：由操作者 **A** 發出請求，斷言的是操作者 **B** 的紀錄**不存在**於回應中。A 與 B 都是有效、已認證、且有權使用該 endpoint 的操作者。
+
+斷言的對象必須是**不存在**。斷言 `200`、斷言清單非空、斷言回應 schema 相符的測試，都不構成充分證據，且**不得**被計為該述詞的覆蓋——因為把範圍限縮子句刪掉之後，它們每一個都照樣通過。
+
+在信任這個測試之前，有一個好用的自我檢查：**在一份暫存副本裡把範圍限縮述詞刪掉，重跑一次。** 如果測試還是通過，那它就不是在測範圍，不管它的名字怎麼寫。
+
+### Gate 時機
+
+擷取為 pre-flight（規劃期）；負向測試為 pre-UAT。
+
+**規則 RE-AUTH-002（必要）**——任何「移植後等價物未經驗證」或「沒有負向測試」的自我限縮述詞，一律標為 `not_implemented` 並 **block cutover**。一道未經驗證的授權界限是已知遺漏風險，不是可接受的缺口——它的失敗模式是跨租戶資料外洩，而且它會以綠燈出貨。
+
+> **來歷。** 本階段源自一次真實的 PHP → C# 遷移：一個以租戶為界的帳號列表 endpoint 在重寫過程中弄丟了它的隔離述詞。移植版把「依角色限縮範圍」換成粗糙的「這個帳號是不是任何一個已啟用的管理員？」檢查，於是不論是誰在問，它都回傳資料庫裡的每一個帳號。它出貨了、通過了所有既有測試（那個方法一個測試都沒有），最後是客戶回報「我看到了不該看到的帳號資訊」才被發現。
+
+---
+
 ## 核心原則
 
 ### 1. 確定性框架
@@ -446,6 +523,7 @@ Feature: 購物車
 
 | 版本 | 日期 | 變更內容 |
 |------|------|----------|
+| 1.3.0 | 2026-08-20 | 新增：授權範圍擷取階段（自我指涉的查詢述詞）——derive 訊號含 SQL 之外的範圍執行點、逐項記錄附 `file:line`、涵蓋每個角色分支與逐 call site resolver 使用的述詞等價性 oracle、規則 RE-AUTH-001（必要負向測試，斷言另一操作者的紀錄「不存在」）與 RE-AUTH-002（未驗證述詞 block cutover）（issue [#166](https://github.com/AsiaOstrich/universal-dev-standards/issues/166)） |
 | 1.2.0 | 2026-06-27 | 新增：隱含規則掃描階段（非 HTTP 持久化寫入路徑擷取）——4 類 derive 清單 + 三問 oracle + 非 HTTP Devil's Advocate + PHP type-juggling 補述 + 確定性/`file:line`（XSPEC-284 R4/AC-8） |
 | 1.1.0 | 2026-06-18 | 新增：失敗處理與升級章節——解析失敗／高未知比例／被推翻推論的升級 + 規則 RE-FAIL-001（XSPEC-292 T7） |
 | 1.0.0 | 2026-01-19 | 初始發布 |

package/bundled/locales/zh-TW/core/runbook.md

@@ -2,8 +2,8 @@
 source: ../../../core/runbook.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 443fb8c4e692
+last_synced: 2026-07-30
+source_hash: 7cb3480f8fda
 status: current
 ---
 

package/bundled/locales/zh-TW/core/schema-evolution.md

@@ -2,8 +2,8 @@
 source: ../../../core/schema-evolution.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 0e8f6242bf38
+last_synced: 2026-07-30
+source_hash: ccb8d5139586
 status: current
 ---
 

package/bundled/locales/zh-TW/core/secret-management-standards.md

@@ -2,8 +2,8 @@
 source: ../../../core/secret-management-standards.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 1bb70238135b
+last_synced: 2026-07-30
+source_hash: d8efae1ed265
 status: current
 ---
 

package/bundled/locales/zh-TW/core/slo-sli.md

@@ -2,8 +2,8 @@
 source: ../../../core/slo-sli.md
 source_version: 1.0.0
 translation_version: 1.0.0
-last_synced: 2026-06-17
-source_hash: 8a24ef8525c7
+last_synced: 2026-07-30
+source_hash: f07ba7eb1c1f
 status: current
 ---
 

package/bundled/locales/zh-TW/core/spec-driven-development.md

@@ -45,6 +45,8 @@ SDD 在不同的成熟度層級運作：規格優先（完成後丟棄）、規
 | **AC YAML Sidecar** | 建議在 AC 超過 3 條時使用 .ac.yaml（機器可讀 AC） |
 | **AI Agent 行為** | 可選章節，用於在規格中定義 Agent 角色、規則、品質檢查、限制 |
 
+> 規格記下的**延後項目**（未納入／不在本版的條目、open questions、仍待確認的 assumptions）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ## AC 格式
 
 UDS 支援兩種 AC 記法。**GWT 為預設與首選**（Forward Derivation／BDD 場景生成依賴它）。**EARS**（Easy Approach to Requirements Syntax，IBM Rational）為可選補充，對事件／狀態／恆常／異常需求表達更精準。

package/bundled/locales/zh-TW/core/tech-debt-standards.md

@@ -1,14 +1,14 @@
 ---
 source: ../../../core/tech-debt-standards.md
-source_version: 1.0.0
-translation_version: 1.0.0
-last_synced: 2026-04-10
+source_version: 1.1.0
+translation_version: 1.1.0
+last_synced: 2026-08-20
 status: current
 ---
 
 # 技術債管理標準
 
-> 版本: 1.0.0 | 最後更新: 2026-04-01
+> 版本: 1.1.0 | 最後更新: 2026-08-20
 
 ## 概述
 
@@ -48,6 +48,73 @@ status: current
 | 10 | **Created Date** | 登記日期 |
 | 11 | **Target Resolution Date** | 計劃解決日期 |
 
+### 登記表儲存選項
+
+登記表可存放於下列任一位置，但每個選項**只有在同時滿足右欄的到期檢查條件時才合法**：
+
+| 選項 | 適用對象 | 到期檢查條件 |
+|------|---------|-------------|
+| `docs/tech-debt-registry.md` | 小型團隊 | 有一支 repo 檢查會解析該表格，並在有列超過 Target Resolution Date 時失敗——**或**該檔帶有「無人看管宣告」 |
+| Issue tracker（GitHub Issues、Jira） | 較大團隊 | 有一個排程查詢實際會**執行**並發出告警；沒有人打開的儲存查詢不算檢查——**或**帶有「無人看管宣告」 |
+| 專用試算表 | 非技術利害關係人 | 僅當該表以明訂頻率匯出到某個會被檢查讀取的位置時才合法——**或**帶有「無人看管宣告」 |
+
+> **這一欄為什麼必須加。** 一份沒有任何程式讀得到的登記表，滿足本節其餘每一條要求：11 個欄位齊全、有 Owner、有 Target Resolution Date。它沒有任何地方是錯的——直到日期過了，然後什麼都沒發生。試算表選項**刻意不移除**（試算表常是出錢的人唯一會打開的格式）；不再合法的是「任何一種儲存方式成為日期無聲過期的地方」。
+
+### 到期處置
+
+一個過了卻沒有任何後果的 **Target Resolution Date**，與根本沒有日期無從分辨。本小節定義「日期到了」是什麼意思。
+
+#### 三種合法處置
+
+項目到達 Target Resolution Date 時，必須發生且只能發生下列三者之一，並且必須留下痕跡：
+
+| 處置 | 意義 | 必留痕跡 |
+|------|------|---------|
+| **做掉（Resolve）** | 把事情做完 | 關閉登記項 + `Tech-Debt: TD-NNN resolved` commit footer |
+| **撤銷（Withdraw）** | 決定不做，並刪掉這筆記載 | 標記為撤銷，附理由與日期。它不再被計為技術債，因為它已經不是了 |
+| **延期（Extend）** | 設定新的 Target Resolution Date | 新日期**與**書面理由必須一起記下；先前的日期保持可見（用附加，不要覆蓋） |
+
+沒有第四種處置。「仍然開著、日期過了、沒有人看」不是本標準允許的狀態——那正是本小節存在要指名的失敗。
+
+**規則 TD-EXP-001（必要）**——項目超過 Target Resolution Date 而三種處置皆未施用，該登記表即不合規。到期是一個發現，不是中性的背景狀態。
+
+**規則 TD-EXP-002（必要，禁止事項）**——到期**不得**被實作成**自動延期**或**自動關閉**。
+
+- 自動延期使日期變得不可證偽：它永遠不會被錯過，所以它從未量到任何東西。
+- 自動關閉在沒有任何人做出決定的情況下刪掉了那筆記載。
+
+兩者都讓時鐘停止，且都不留下「時鐘停了」的痕跡。一個唯一的消費者是「把它往後推的排程」的日期，只是裝飾。
+
+**規則 TD-EXP-003（必要）**——延期時理由必須記在新日期旁邊。只改日期不是延期，那是一次蓋了時間戳的刪除。
+
+**規則 TD-EXP-004（建議）**——被延期三次以上、期間沒有記錄任何進度的項目，應重新分流為**撤銷**候選。反覆延期是「沒有人打算做這件事」的證據；老實記下這件事，比第四個日期對下一位讀者更有用。
+
+#### 無人看管宣告
+
+不是每個團隊都有能力跑一支檢查。**沒有自動到期檢查的登記表仍然合規——但前提是它把這件事寫出來。**
+
+「無人看管宣告」是寫在登記表內部、可見且帶日期的一段陳述：
+
+```
+無人看管——沒有任何自動檢查在讀這份登記表的到期項目。
+由 <負責人> 以 <頻率> 人工複查。最後複查日期：<日期>。
+```
+
+**規則 TD-EXP-005（必要）**——登記表必須處於下列兩種狀態之一，且必須讓讀者看得到它處於哪一種：
+
+1. **已受檢（Checked）**——有一支具名、跑得起來的檢查在讀這份登記表，並在項目超過 Target Resolution Date 時失敗。
+2. **無人看管（Unattended）**——沒有這樣的檢查，但帶有無人看管宣告，且宣告中寫明負責人、複查頻率與最後複查日期。
+
+兩種狀態都不處於的登記表即為不合規。這份宣告不是形式：它就是「知道沒有東西在看的讀者」與「以為有東西在看的讀者」之間的全部差別。
+
+**規則 TD-EXP-006（必要）**——無人看管宣告裡的「最後複查日期」本身，受該宣告自己所寫的頻率約束。最後複查日期比自己宣告的頻率還舊的宣告，本身就是一個到期項目，三種處置同樣適用於它。
+
+> **本標準不提供任何檢查器，這是已知代價——寫在這裡，而不是留給採用者自己撞到。**
+>
+> UDS 定義的是要求，它不提供一支執行該要求的程式。想要**已受檢**狀態的採用者必須自己寫那支檢查，而多數團隊不會寫——那正是上面描述的失敗模式，現在同樣適用於本小節自己。
+>
+> 所以這裡的最低標準**不是**「去建一支檢查器」，而是**「絕不讓一份登記表在無聲中變成無人看管」**。宣告 `無人看管` 只要一段文字，而且完全合規。無人看管**卻不宣告**才是本標準真正禁止的唯一結果，因為只有它會讓讀者對「有沒有東西在看」產生誤解。
+
 ## 3. 預算分配
 
 | 團隊狀態 | 預算 | 說明 |