universal-dev-standards 6.11.0 → 6.12.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,216 @@
1
+ # Open Work Tracking Standard - AI Optimized
2
+ # Source: core/open-work-tracking.md
3
+
4
+ standard:
5
+ id: open-work-tracking
6
+ name: Open Work Tracking Standard
7
+ description: 開放工作追蹤標準——承載開放工作的地方必須低摩擦收件、記錄解除條件、生成可推導欄位、印出分母、且在回合結束時被檢視而不阻斷
8
+
9
+ meta:
10
+ version: "1.0.0"
11
+ updated: "2026-09-23"
12
+ source: core/open-work-tracking.md
13
+ description: >
14
+ 三種不同的「工作不見了」的方式(沒地方記新想法、等待中沒有解除條件、
15
+ 沒有時鐘的計畫無聲腐爛)常被塞進同一份清單,而合併本身就是失敗的一部分。
16
+ 本標準是 deferred-item-exit 的下游一半:DEX 管「延後項目有沒有離開文件」,
17
+ 本標準管「離開之後抵達的那個承載庫,自己會不會腐壞」。
18
+
19
+ iron_law: >
20
+ 一個承載開放工作的地方,必須:不要求分類就能收下新項目、為每一個等待中項目記下解除條件、
21
+ 對可推導的欄位改用生成、回報還剩什麼時同時揭露看不到什麼、
22
+ 在控制權從 agent 交回人的那一刻被檢視——而且那個檢視不能讓回合失敗。
23
+
24
+ # ── 寫法約束:先讀這一段,它拘束下面每一條 ────────────────────────────────
25
+ # 與 deferred-item-exit 受的是同一條約束(DEC-049),套用在下游一層:
26
+ # 本標準只陳述關係,不規定承載庫用什麼工具/格式/系統實作。
27
+ writing_constraint:
28
+ basis: DEC-049
29
+ upstream: deferred-item-exit
30
+ admissible_what:
31
+ - "收件點欄位數必須具備的性質"
32
+ - "等待項目與解除條件之間必須存在的關係"
33
+ - "「這是最新的」這句宣稱必須從什麼可被證明"
34
+ - "一個回報數字與它看不到的部分之間的關係"
35
+ - "控制權交回人的那一點存在一個確認點,且它永不阻斷"
36
+ inadmissible_how:
37
+ - "收件點是哪個 app、檔案或工單系統"
38
+ - "輪詢解除條件的排程器或機器人"
39
+ - "具體用哪個雜湊函式、diff 工具或 CI 供應商"
40
+ - "儀表板版面或報告範本"
41
+ - "用什麼 hook 系統、shell 或 cron 實作確認點"
42
+ consequence: >
43
+ 本標準不附帶任何閘門。它只說一個承載開放工作的地方必須具備什麼性質;
44
+ 有沒有東西在檢查是採用專案的決定,而 OWT-014/OWT-015 是用來讓那個決定
45
+ 沒辦法被默默做掉的。
46
+
47
+ guidelines:
48
+ - "收件點必填欄位不得超過兩個——分類/優先級/負責人一律是 triage 時的動作,不得成為輸入門檻"
49
+ - "每個等待中項目都要記下**在等什麼**與**什麼事件視為解除**,解除條件應盡量機器看得到"
50
+ - "凡能從版控/規格標記/CI 結果推導出來的欄位,一律生成,不得手寫"
51
+ - "**生成區段的「最新」宣稱要能從內容本身證明**(例如來源雜湊),不能只靠一個人可以敷衍的日期"
52
+ - "**「內容可證明最新」與「日期宣稱最新、內容未驗證」是兩個不同狀態,不得合併成同一個通過**"
53
+ - "任何「還有 N 項」的數字,必須同時印出看得見多少、看不見多少——看不見的部分不得被讀成零"
54
+ - "確認點要出現在**控制權從 agent 交回人的那一刻**,不能只掛在 shell 啟動、CI 或文件被編輯時"
55
+ - "🔴 確認點**永遠不阻斷**——「還有工作沒做完」幾乎永遠為真,永遠為真的閘門會被關掉"
56
+ - "確認點與阻斷式檢查掛同一事件時,確認點的輸出要排在阻斷判決之前"
57
+ - "判定項目是等待中/未分類/已丟棄,走訪承載庫自己的結構欄位,不要只靠掃描散文措辭"
58
+ - "措辭清單可以補充結構欄位,但涵蓋率必須明示未知,乾淨結果不得回報成「沒有漏掉」"
59
+ - "超過門檻仍未分類的項目要在摘要裡被點名,不得被合併進一個總數"
60
+ - "項目從承載庫消失(drop)必須帶一句理由,不得只是消失"
61
+
62
+ # ── R5 vs turn-completion-integrity:掛同一事件,行為刻意相反 ──────────────
63
+ vs_turn_completion_integrity:
64
+ shared_event: "回合結束、控制權交回人類"
65
+ turn_completion_integrity:
66
+ watches: "agent 自己最後一則訊息裡,被說出口又被放棄的第一人稱承諾"
67
+ default_state: "罕見——只在明確做出承諾又被丟下時觸發"
68
+ on_violation: "擋住回合結束,直到承諾被解決或說明卡在誰身上"
69
+ this_standard:
70
+ watches: "承載庫裡的項目,看有沒有沒解除條件的、沒出口的、或過門檻還沒分類的"
71
+ default_state: "常見——「還有工作沒做完」幾乎永遠為真"
72
+ on_violation: "永不阻斷,只能回報(OWT-008)"
73
+ why_opposite: >
74
+ TCI 自己的規則(TCI R4)已經寫出這裡不能做成閘門的理由:
75
+ 一個在每個回合都為真的閘門會被關掉,關掉之後它什麼都不保護。
76
+ 開放工作非空幾乎永遠為真,所以本標準的確認點被設計成永不保留控制權。
77
+ ordering_when_co_located: "本標準先回報(OWT-009),即使該回合隨後被 TCI 擋下,回報仍然可見"
78
+
79
+ # ── 錨點:走訪結構,不走訪措辭(與 DEX-007/DEX-008 同形狀)───────────────
80
+ anchors:
81
+ principle: "判定等待中/未分類/已丟棄,讀承載庫自己描述該狀態的結構欄位——狀態欄、型別化標記、小節標題——而非散文措辭"
82
+ wording_heuristic:
83
+ allowed: true
84
+ but: "涵蓋率必須明示未知;一份含「等待」「未分類」的措辭清單,對用別的寫法表達的項目什麼也不保證"
85
+ general_form: class-level-fix
86
+
87
+ # ── 戳 vs 內容:與 DEX-005/DEX-006 同形狀,換了一個 artefact ──────────────
88
+ stamp_vs_content:
89
+ failure: >
90
+ 生成區段的時間戳很新,被誤讀成內容是新的。戳比內容舊的情況容易抓(比對修改紀錄);
91
+ 戳比內容新而內容本身已過期——隱形,因為「戳是新的」正是一次正確對帳看起來的樣子。
92
+ fix: "「最新」的宣稱要能從內容本身被證明(例如來源雜湊),不能只靠一個人可編輯的日期"
93
+ two_states_required:
94
+ - state: content_proven_current
95
+ meaning: "從內容本身可證明是最新的(例如雜湊比對一致)"
96
+ - state: date_claims_current_unverified
97
+ meaning: "日期看起來新,內容有沒有真的對過帳未知"
98
+ why_not_one_state: "把兩態合併成單一通過,正是這條規則要防的缺陷;一個被回報成通過的未知,比一個被回報成未知的未知更糟"
99
+
100
+ evidence_admissibility:
101
+ rule: "被提出作為本標準證據的檢查,必須已經被觀察到對一個刻意違反該要求的樣本回報失敗"
102
+ why: "一支從未失敗過的檢查,與一支不可能失敗的檢查,輸出一模一樣"
103
+ procedure_lives_in: class-level-fix
104
+ exit_code_caveat_lives_in: verification-evidence
105
+
106
+ anti_patterns:
107
+ - pattern: "收件表單有三個以上必填欄位"
108
+ why: "可量測地不再被使用;摩擦由正在打斷自己工作的人承擔"
109
+ - pattern: "「之後再看」而沒有解除條件"
110
+ why: "與被忘記無法分辨;沒有東西會讓它回來"
111
+ - pattern: "手動輸入、重複 git 或 CI 已知資訊的狀態"
112
+ why: "兩個擁有者,其中一個永遠不會被更新"
113
+ - pattern: "沒有內容證明的「最後對過帳」日期"
114
+ why: "內容真的被核對過,跟日期只是被打上去,看起來一模一樣"
115
+ - pattern: "「還有 47 項」而不寫分母"
116
+ why: "預設被讀成完整;看不見的大多數被誤讀成「都做完了」"
117
+ - pattern: "確認點掛在 shell 啟動而不是回合結束"
118
+ why: "只要沒人剛好開新 shell,它就持續漂移"
119
+ - pattern: "確認點擋住回合結束、理由是「還有工作沒做完」"
120
+ why: "每個回合都會觸發;永遠為真的閘門會被關掉,關掉之後什麼都不保護"
121
+ - pattern: "分類狀態只靠散文措辭判讀"
122
+ why: "正確到某個項目用清單沒預料到的方式寫出來為止"
123
+ - pattern: "項目從承載庫無聲消失"
124
+ why: "與一個弄丟它的 bug 無從分辨"
125
+
126
+ rules:
127
+ - id: OWT-001
128
+ rule: "新項目的收件點必填欄位不得超過兩個;分類/優先級/負責人一律是 triage 時的動作,不得成為輸入門檻"
129
+ severity: error
130
+ - id: OWT-002
131
+ rule: "標為等待中的項目,必須同時記下在等什麼與什麼事件視為解除"
132
+ severity: error
133
+ - id: OWT-003
134
+ rule: "能從版控/規格標記/CI 結果完整推導的欄位,一律生成,不得手寫"
135
+ severity: error
136
+ - id: OWT-004
137
+ rule: "生成區段的「最新」宣稱必須能從它所本的內容證明(例如來源雜湊),不能只靠一個人可編輯的日期"
138
+ severity: error
139
+ - id: OWT-005
140
+ rule: "「內容可證明最新」與「日期宣稱最新、內容未驗證」須回報為兩個相異狀態;合併為單一通過即不滿足 OWT-004"
141
+ severity: error
142
+ - id: OWT-006
143
+ rule: "任何「還有 N 項」的數字,須同時印出看得見多少來源、看不見多少來源;看不見的部分不得被讀成零"
144
+ severity: error
145
+ - id: OWT-007
146
+ rule: "開放工作摘要出現在控制權從 agent 交回人的那一刻,不能只掛在 session 開始、CI、或追蹤文件被編輯時"
147
+ severity: error
148
+ - id: OWT-008
149
+ rule: "開放工作摘要自己的結束路徑,不論輸入為何(含「還有很多項」)都不得改變回合的結果"
150
+ severity: error
151
+ - id: OWT-009
152
+ rule: "摘要與一道阻斷式檢查掛同一個回合結束事件時,摘要的輸出須排在阻斷判決之前"
153
+ severity: warning
154
+ - id: OWT-010
155
+ rule: "判定項目是等待中/未分類/已丟棄,須來自承載庫自定義的結構欄位,不得只靠掃描散文措辭"
156
+ severity: error
157
+ - id: OWT-011
158
+ rule: "以措辭啟發式補充結構欄位時,須明示其涵蓋率未知,且其乾淨結果不得回報為「沒有漏掉」"
159
+ severity: warning
160
+ - id: OWT-012
161
+ rule: "超過宣告門檻仍未分類的項目,須在開放工作摘要裡被個別點名,不得被合併進總數"
162
+ severity: error
163
+ - id: OWT-013
164
+ rule: "項目從承載庫移除而未變成規格、追蹤項目、或任何其他具名去向時,須帶一句理由;沒有理由的移除與靜默刪除無法分辨"
165
+ severity: error
166
+ - id: OWT-014
167
+ rule: "本標準的每一條要求都必須可表述為 artefact 之間可判定的關係;不能如此表述的要求不得進入本標準"
168
+ severity: error
169
+ - id: OWT-015
170
+ rule: "被提出作為本標準任一要求之證據的檢查,須已被觀察到對一個刻意違反該要求的樣本回報失敗;從未紅過的檢查不是可採信的證據"
171
+ severity: error
172
+ - id: OWT-016
173
+ rule: "本標準各要求所引用的任何窗口或閾值,須載明來歷,或標為未校準"
174
+ severity: warning
175
+
176
+ # ── 本標準在 UDS 側沒有閘門,這件事被記錄而非被暗示 ──────────────────────
177
+ enforcement:
178
+ automated_gate: false
179
+ why_not: >
180
+ 依上面的寫法約束,UDS 陳述關係,有沒有東西判定它是採用專案的決定。
181
+ UDS 不出貨承載開放工作的地方本身,只出貨要求它具備什麼性質的標準。
182
+ what_it_does_instead: >
183
+ OWT-014 保證這裡每一條「能」被判定;OWT-015 固定「一次判定要算數需要什麼」;
184
+ OWT-005/OWT-011 固定「一次不完整的判定容許印出什麼」。
185
+ honest_boundary: >
186
+ 一個採用本標準而什麼都沒建的專案並未違反它——但它同樣不能宣稱自己的開放工作
187
+ 承載庫具備這些性質,因為它沒有任何可採信的證據說明有。
188
+
189
+ # ── 證據強度與校準:誠實標注,不誇大 ─────────────────────────────────────
190
+ evidence_and_calibration:
191
+ origin: "XSPEC-427(2026-09-23),一個採用專案同一天做出並實跑的參考實作"
192
+ age_at_writing: "以小時計,單一使用者,單一 repo"
193
+ what_this_supports: "R1–R6 的形狀——每一條都對應一個當天觀察到的失效或使用者原話描述的模式"
194
+ what_this_does_not_support: "OWT-001 的「兩個欄位」與 OWT-012 的「兩週」這類具體閾值——這些是初始判斷,不是量測"
195
+ recalibration: "由採用專案自行決定與自行訂定時程;本標準不承諾覆核日期,如同它不承諾閘門"
196
+
197
+ related:
198
+ - id: deferred-item-exit
199
+ relation: "上游的同一個形狀:DEX 要求延後項目離開文件、抵達可追蹤出口,刻意不規定出口的載體。本標準接手出口存在之後的事,要求載體自己不要變成下一份東西會不見的文件"
200
+ - id: turn-completion-integrity
201
+ relation: "掛在同一個事件(回合結束)上,且被設計成行為相反——TCI 阻斷、本標準永不阻斷。見 vs_turn_completion_integrity"
202
+ - id: class-level-fix
203
+ relation: "OWT-011 揭露之措辭清單限制的通則形式,也是 OWT-015 所要求非空跑證據程序的來源"
204
+ - id: verification-evidence
205
+ relation: "OWT-015 所依賴的 exit code 與證據有效性推理的來源;也是 OWT-006/OWT-011 部分涵蓋例外該被登記的地方"
206
+
207
+ physical_spec:
208
+ applies_to:
209
+ - "任何承載跨回合/跨 session 開放工作的地方(收件匣、待辦清單、backlog、worklog 等,載體不限)"
210
+ deliverables:
211
+ - "收件點的欄位數(須 ≤ 2)"
212
+ - "每個等待中項目旁的解除條件"
213
+ - "生成區段旁的內容可證明性(而非僅時間戳)"
214
+ - "任何「還有 N 項」數字旁的看見/看不見分母"
215
+ - "掛在回合結束、永不阻斷的開放工作摘要"
216
+ - "超過門檻仍未分類項目的個別點名,與已丟棄項目的一句理由"
@@ -0,0 +1,333 @@
1
+ # Open Work Tracking Standard
2
+
3
+ > **Language**: English | [繁體中文](../locales/zh-TW/core/open-work-tracking.md)
4
+
5
+ **Version**: 1.0.0
6
+ **Last Updated**: 2026-09-23
7
+ **Applicability**: Any project that carries work across more than one working session and risks losing an item between them
8
+ **Scope**: universal
9
+
10
+ ---
11
+
12
+ ## Purpose
13
+
14
+ The deferred-item-exit standard requires that a deferred item leave its document for a traceable exit. It deliberately does not say what that exit is made of, or what keeps it from rotting once the item has arrived there. **This standard is that downstream half**: given that a carrier for open work exists, what must be true of the carrier itself so that it stays trustworthy. See [deferred-item-exit](deferred-item-exit.md).
15
+
16
+ 延後項目出口標準(deferred-item-exit)要求延後項目離開文件、抵達一個可追蹤的出口,
17
+ 但刻意不規定那個出口長什麼樣、也不規定項目抵達之後什麼東西防止它腐壞。
18
+ **本標準是那個下游的一半**:假設一個承載開放工作的地方已經存在,
19
+ 它自己必須具備什麼性質才不會慢慢變得不可信。見 [deferred-item-exit](deferred-item-exit.md)。
20
+
21
+ Three distinct ways work goes missing between sessions are routinely folded into one undifferentiated list, and the fold is itself part of the failure — a list built to catch all three catches none of them well:
22
+
23
+ 三種不同的「工作不見了」的方式,常被塞進同一份沒有分別的清單,而**這個合併本身就是失敗的一部分**——
24
+ 一份想同時接住三者的清單,通常一個都接不好:
25
+
26
+ | Symptom | Underlying problem | Mechanism needed |
27
+ |---|---|---|
28
+ | A new item surfaces mid-task and there is no low-friction way to record it | The item is time-sensitive; by the time recording it is convenient, it is forgotten | A capture point cheap enough to use without breaking the current task |
29
+ | An item is paused pending some other event | "Waiting" with no recorded release condition is indistinguishable from "forgotten" | A release condition recorded alongside the wait |
30
+ | A planned item has not been started and time passes | An item with no clock decays silently — nothing ever points back at it | A threshold, or a forced periodic look, that surfaces it again |
31
+
32
+ | 症狀 | 背後的問題 | 需要的機制 |
33
+ |---|---|---|
34
+ | 工作進行中冒出新項目,沒有低摩擦的地方可以記下它 | 項目有時效性,等到方便記錄時已經忘了 | 一個便宜到不會打斷當前工作的收件點 |
35
+ | 某項目因等待別的事件而暫停 | 「等待中」若沒有記錄解除條件,與「被忘記」無法分辨 | 與等待一起記錄的解除條件 |
36
+ | 已規劃的項目還沒動工,時間過去 | 沒有時鐘的項目會無聲腐爛——沒有東西會再指向它 | 一個門檻,或一次被迫的定期檢視,讓它重新浮現 |
37
+
38
+ Each requirement below traces to one row of that table, or to one of four failures observed the day this standard's design was drafted (see [Evidence and calibration](#evidence-and-calibration)). **None of the mechanisms is prescribed** — per the same constraint [deferred-item-exit](deferred-item-exit.md) states for its own exits, and for the same reason (DEC-049: UDS defines relations that must hold, adoption layers choose what maintains them).
39
+
40
+ 下面每一條要求都對應這張表的一列,或對應本標準設計當天觀察到的四個失效之一
41
+ (見〈[證據與校準](#evidence-and-calibration)〉)。**沒有任何一個機制被規定**——
42
+ 理由與 [deferred-item-exit](deferred-item-exit.md) 對自己出口的約束相同(DEC-049:
43
+ UDS 定義必須成立的關係,維持它的機制由採用層選擇)。
44
+
45
+ ---
46
+
47
+ ## How this standard is written — and why it is written that way
48
+
49
+ **Read this section before reading any requirement below. It governs all of them.**
50
+
51
+ UDS defines **activities**; adoption layers **orchestrate** them (DEC-049). A standard written as a workflow protocol, a file format, or a specific tool's configuration belongs to the adoption layer, not here — this is the same boundary [deferred-item-exit](deferred-item-exit.md) is held to, applied one layer downstream.
52
+
53
+ UDS 定義**活動**,採用層負責**編排**(DEC-049)。一份寫成工作流協定、檔案格式、
54
+ 或特定工具設定的標準屬於採用層,不屬於這裡——這與 [deferred-item-exit](deferred-item-exit.md)
55
+ 受的約束相同,只是套用在下游一層。
56
+
57
+ | Admissible here — **what** | Not admissible here — **how** |
58
+ |---|---|
59
+ | A property a capture point's field count must have | Which app, file, or ticket system is the capture point |
60
+ | A relation between a waiting item and its release condition | A scheduler or bot that polls for that condition |
61
+ | A property a "this is current" claim must be provable from | A specific hash function, diff tool, or CI provider |
62
+ | A relation between a reported count and what it could not see | A dashboard layout or report template |
63
+ | That a checkpoint exists at the point control returns to a human, and never blocks | Which hook system, shell, or cron implements it |
64
+
65
+ | 這裡容許——**what** | 這裡不容許——**how** |
66
+ |---|---|
67
+ | 收件點欄位數必須具備的性質 | 收件點是哪個 app、檔案或工單系統 |
68
+ | 等待項目與解除條件之間必須存在的關係 | 輪詢那個條件的排程器或機器人 |
69
+ | 「這是最新的」這句宣稱必須從什麼可被證明 | 具體用哪個雜湊函式、diff 工具或 CI 供應商 |
70
+ | 一個回報數字與它看不到的部分之間的關係 | 儀表板版面或報告範本 |
71
+ | 控制權交回人的那一點存在一個確認點,且它永不阻斷 | 用什麼 hook 系統、shell 或 cron 實作它 |
72
+
73
+ **Consequence, stated plainly**: this standard ships **no gate**. It says what must be true of a carrier for open work. Whether anything checks it is the adopting project's decision — [OWT-014](#requirements) and [OWT-015](#requirements) exist so that decision cannot be made silently.
74
+
75
+ **直說它的後果**:本標準**不附帶任何閘門**。它只說一個承載開放工作的地方必須具備什麼性質;
76
+ 有沒有東西在檢查,是採用專案的決定——[OWT-014](#requirements) 與 [OWT-015](#requirements)
77
+ 存在的目的,是讓那個決定沒辦法被默默做掉。
78
+
79
+ ---
80
+
81
+ ## The invariant
82
+
83
+ **A carrier of open work must (1) accept a new item without demanding classification, (2) record a release condition for every item it marks waiting, (3) generate any field a reliable source already determines, (4) disclose what it cannot see whenever it reports what remains, and (5) be checked at the moment control returns from agent to human — by something that cannot fail the turn.**
84
+
85
+ **一個承載開放工作的地方,必須:(1)不要求分類就能收下新項目、(2)為每一個標為等待中的項目記下解除條件、
86
+ (3)對任何有可靠來源可推導的欄位改用生成、(4)回報還剩什麼時同時揭露看不到什麼、
87
+ (5)在控制權從 agent 交回人的那一刻被檢視——而且那個檢視不能讓回合失敗。**
88
+
89
+ ---
90
+
91
+ ## Requirements
92
+
93
+ | ID | Requirement | Severity |
94
+ |---|---|---|
95
+ | **OWT-001** | A capture point for a new item requires no more than two fields to record it. Classification, priority, and ownership are triage-time actions, never entry-time gates | error |
96
+ | **OWT-002** | An item recorded as waiting states both what it is waiting for and what event counts as its release | error |
97
+ | **OWT-003** | A field whose value is fully derivable from version control, a spec marker, or a CI result is generated, not hand-written | error |
98
+ | **OWT-004** | A generated section's claim to be current is provable from the content it was generated from (e.g. a hash of the source), not asserted by a bare human-editable date | error |
99
+ | **OWT-005** | "Content-proven current" and "a date claims current, content unverified" are reported as two distinct states. A report that merges them into one pass state does not satisfy OWT-004 | error |
100
+ | **OWT-006** | Any "N items remain" figure states, beside it, how many sources it could see and how many it could not. The unseen portion is never read as zero | error |
101
+ | **OWT-007** | A summary of open work occurs at the point control returns from agent to human — not only at session start, in CI, or when a tracking document happens to be edited | error |
102
+ | **OWT-008** | The open-work summary's own exit path never changes the turn's outcome, on any input, including "many items remain" | error |
103
+ | **OWT-009** | Where the summary and a blocking check share an end-of-turn event, the summary's output precedes the blocking check's verdict | warning |
104
+ | **OWT-010** | Whether an item is waiting, unclassified, or dropped is determined from a structural field the carrier defines, not from scanning free-text wording alone | error |
105
+ | **OWT-011** | Where a wording heuristic supplements the structural field, its coverage is declared unknown, and a clean pass over it is not reported as "nothing was missed" | warning |
106
+ | **OWT-012** | An item left unclassified past the declared threshold is named individually in the open-work summary, not folded into an aggregate count | error |
107
+ | **OWT-013** | An item removed from the carrier without becoming a spec, a tracked item, or any other named destination carries a one-line reason. A drop with no reason is indistinguishable from silent deletion | error |
108
+ | **OWT-014** | Every requirement of this standard is expressible as a decidable relation over named artefacts. A requirement that cannot be so expressed does not belong in this standard | error |
109
+ | **OWT-015** | A check offered as evidence for any requirement here has been observed to report failure against a sample built to violate it. A check never observed red is not admissible evidence | error |
110
+ | **OWT-016** | Any window or threshold this standard's requirements reference carries its provenance, or is marked uncalibrated | warning |
111
+
112
+ ---
113
+
114
+ ## Capture must cost almost nothing
115
+
116
+ **OWT-001** exists because a capture point with a third required field measurably stops being used. The failure is not hypothetical friction — it is the specific, observed shape of "a new idea surfaces mid-task, and recording it competes with the task that produced it." A field for classification, priority, or ownership asked for **at entry time** is a bet that the person interrupting their own work will pay that cost; the bet is lost more often than it is won, and a capture point nobody uses is not a capture point, it is a form.
117
+
118
+ **OWT-001** 之所以存在,是因為多一個必填欄位的收件點,量測到的結果是**不被使用**。
119
+ 這不是假想的摩擦——它是「工作進行中冒出新想法,記下它要跟正在做的事搶時間」這個情境的具體形狀。
120
+ 在**輸入當下**就要求分類、優先級或負責人,是在賭「正在被打斷的人願意付那個成本」,
121
+ 而這個賭注輸的次數比贏的多;一個沒有人用的收件點不是收件點,是一張表單。
122
+
123
+ Triage — deciding where an item belongs — is a separate, later act. **OWT-012** and **OWT-013** govern what happens if triage never comes: the item is not allowed to sit invisible forever, and it is not allowed to disappear without a reason either.
124
+
125
+ 分類(決定項目屬於哪裡)是另一個、之後才做的動作。**OWT-012** 與 **OWT-013**
126
+ 規範分類永遠不來時會發生什麼:項目不准永遠隱形地待著,也不准無理由地消失。
127
+
128
+ ---
129
+
130
+ ## A waiting item without a release condition is a forgotten item wearing a status label
131
+
132
+ **OWT-002** names the difference between "paused, and something will bring it back" and "paused, forever, with a word attached that makes that not look like what it is." A release condition should be **machine-observable** where that is possible — a date, an identifier appearing somewhere, a file existing — so the item has a chance of surfacing itself instead of depending on a person remembering it exists. Where a machine-observable condition genuinely does not exist, a human-readable one is still required; **OWT-002 does not require automation, it requires that the condition be recorded at all.**
133
+
134
+ **OWT-002** 指出「暫停中、有東西會讓它回來」與「暫停中、永遠、只是貼了一個讓它看起來不像永遠的標籤」
135
+ 之間的差別。解除條件應盡可能是**機器看得見的**——一個日期、一個會出現的識別字、一個檔案存在——
136
+ 讓項目有機會自己跳出來,而不是依賴某個人記得它存在。真的找不到機器看得見的條件時,
137
+ 仍然要求一個人看得懂的條件;**OWT-002 不要求自動化,只要求那個條件被記下來這件事本身**。
138
+
139
+ ---
140
+
141
+ ## A stamp is cheaper to write than the truth, and a check that reads only the stamp cannot tell the difference
142
+
143
+ This is the same failure DEX-006 names for a different artefact, one layer removed. There, an identifier being present was mistaken for the exit it points to being correct. Here, **a generated section's timestamp being recent is mistaken for its content being current** — and the two diverge in a way that is invisible to any check comparing only dates:
144
+
145
+ 這是 DEX-006 在另一個 artefact 上點名的同一種失敗,只是換了一層。DEX-006 那邊,
146
+ 識別字的存在被誤讀成它指向的出口是對的;這裡,**生成區段的時間戳很新,被誤讀成內容是新的**——
147
+ 而這兩者分歧的方式,對任何只比較日期的檢查是隱形的:
148
+
149
+ - A stamp older than the content: caught trivially, by comparing the stamp to the file's own modification history.
150
+ - A stamp *newer* than the content, where the content itself went stale: **invisible**, because "the stamp is recent" is exactly what a correct reconciliation also looks like.
151
+
152
+ - 戳比內容舊:拿戳跟檔案自己的修改紀錄一比就抓到,微不足道。
153
+ - 戳**比內容新**,而內容本身已經過期:**隱形**,因為「戳是新的」正是一次正確對帳看起來的樣子。
154
+
155
+ **OWT-004** requires the currency claim to be provable from the content itself — for example, a hash of the source the section was generated from, stored beside the section, so a mismatch is detectable without trusting that whoever last touched the date also actually reconciled the content. **OWT-005** requires that "provably current" and "a date says so, unverified" never share one pass/fail bit, for the same reason DEX-005/DEX-006 require it of a deferred item's exit: an unknown reported as a pass is worse than an unknown reported as unknown, because the second one is still findable.
156
+
157
+ **OWT-004** 要求「這是最新的」這句宣稱可以從內容本身被證明——例如儲存一份該區段
158
+ 是從哪個來源生成的雜湊、放在區段旁邊,這樣不比對內容也能偵測到不一致,
159
+ 不必信任「最後動手改日期的人也真的對過帳」。**OWT-005** 要求「內容可證明是最新的」
160
+ 與「日期這麼說、內容未驗證」永遠不共用同一個通過/失敗位元,理由與 DEX-005/DEX-006
161
+ 要求延後項目出口做同一件事相同:一個被回報成通過的未知,比一個被回報成未知的未知更糟,
162
+ 因為後者還找得到。
163
+
164
+ ---
165
+
166
+ ## Coverage must state its own blindness
167
+
168
+ **OWT-006** requires that any "N items remain" figure be printed beside the count of sources it could see and the count it could not — not because the unseen count is expected to be zero, but because a reader cannot tell the difference between "11.7% coverage, and 386 items are invisible to this figure" and "11.7% coverage is complete" unless the denominator is printed next to it. A coverage figure with no stated blindness reads as complete by default, and that default is the failure this requirement exists to prevent.
169
+
170
+ **OWT-006** 要求任何「還有 N 項」的數字旁邊,同時印出它看得見多少來源、看不見多少來源——
171
+ 不是因為預期看不見的數字會是零,而是因為讀者分不出「涵蓋率 11.7%,而且有 386 項
172
+ 對這個數字完全隱形」與「涵蓋率 11.7% 就是全貌」,除非分母被印在旁邊。
173
+ 一個沒有聲明盲區的涵蓋率數字,預設會被讀成完整——而那個預設正是這條要求要防的失效。
174
+
175
+ ---
176
+
177
+ ## The checkpoint is a report, not a gate
178
+
179
+ **turn-completion-integrity** ([TCI](turn-completion-integrity.md)) and this standard's OWT-007–OWT-009 both attach to the same event — the moment an agent's turn ends and control returns to a human — and they are built to behave in opposite ways on purpose. Wiring both to one event without understanding why they differ produces either a checkpoint that blocks on something that is nearly always true, or a report mistaken for a gate:
180
+
181
+ **turn-completion-integrity**([TCI](turn-completion-integrity.md))與本標準的 OWT-007–OWT-009
182
+ 都掛在同一個事件——agent 的回合結束、控制權交回人類的那一刻——而它們被刻意設計成
183
+ **行為相反**。把兩者接到同一個事件卻不理解為什麼不同,會產出「擋在一件幾乎永遠為真的事情上的
184
+ 確認點」,或是「被誤認成閘門的報告」,兩者都不對:
185
+
186
+ | | [turn-completion-integrity](turn-completion-integrity.md) | This standard (OWT-007–009) |
187
+ |---|---|---|
188
+ | What it watches | The agent's own last message, for a first-person commitment that was stated and then abandoned | Whatever the carrier holds, for items with no release condition, no exit, or left unclassified past threshold |
189
+ | Default state | Rare — it fires only when a specific commitment was made in that message and then dropped | Common — "some work is still open" is close to always true |
190
+ | What a violation does | Blocks the turn from ending until the commitment is resolved or its blocker is named | Never blocks. It can only report (OWT-008) |
191
+ | Why the difference | The event it watches for is rare enough that blocking on it does not wear out its welcome | TCI's own rule names the reason this one cannot be a gate: *"A gate that is true on every turn is turned off, and then it protects nothing"* (TCI R4). Open work being non-empty is close to always true, so this checkpoint is built to never withhold control |
192
+ | Ordering when both are wired to the same event | — | Reports first (OWT-009), so its output is visible even on a turn TCI then blocks |
193
+
194
+ | | [turn-completion-integrity](turn-completion-integrity.md) | 本標準(OWT-007–009) |
195
+ |---|---|---|
196
+ | 它在看什麼 | agent 自己最後一則訊息,看有沒有一個第一人稱承諾被說出口又被放棄 | 承載庫裡的任何項目,看有沒有沒解除條件的、沒出口的、或過門檻還沒分類的 |
197
+ | 預設狀態 | 罕見——只在那則訊息裡明確做了承諾又被丟下時才觸發 | 常見——「還有工作沒做完」幾乎永遠為真 |
198
+ | 違反時會怎樣 | 擋住回合結束,直到承諾被解決或說明卡在誰身上 | 永不阻斷。只能回報(OWT-008) |
199
+ | 為什麼行為相反 | 它在看的事件本身夠稀少,擋在它上面不會把耐性用完 | TCI 自己的規則已經寫出這裡不能做成閘門的理由:**「一個在每個回合都為真的閘門會被關掉,關掉之後它什麼都不保護」**(TCI R4)。開放工作非空幾乎永遠為真,所以這個確認點被設計成永不保留控制權 |
200
+ | 兩者掛同一事件時的順序 | — | 先回報(OWT-009),所以即使那個回合隨後被 TCI 擋下,它的輸出仍然可見 |
201
+
202
+ ---
203
+
204
+ ## Anchors: structure, not wording
205
+
206
+ To decide whether an item is waiting, unclassified, or dropped, **read the carrier's own structural field for that state** — a status column, a typed marker, a section heading — the same way [deferred-item-exit](deferred-item-exit.md)'s DEX-007 requires walking a document's structure rather than its wording to find deferred items. **OWT-010** requires the structural field to exist and be the primary source of truth.
207
+
208
+ 判定一個項目是等待中、未分類、還是已丟棄,要**讀承載庫自己描述那個狀態的結構欄位**——
209
+ 一個狀態欄、一個型別化標記、一個小節標題——與 [deferred-item-exit](deferred-item-exit.md)
210
+ 的 DEX-007 要求走訪文件結構而非措辭來找延後項目是同一個道理。**OWT-010** 要求那個結構欄位
211
+ 存在,並且是真相的主要來源。
212
+
213
+ A free-text wording scan ("contains the phrase 'waiting on'") can legitimately supplement the structural field — it catches items dropped into prose that never made it into the structured field. But it inherits the same limit [class-level-fix](class-level-fix.md) names for any enumerated list: **it is correct until the next member arrives, phrased a way the list did not anticipate.** **OWT-011** requires its coverage be declared unknown, and forbids a clean pass over it from being reported as "nothing was missed."
214
+
215
+ 一次自由文字措辭掃描(「含有『等待』這個詞」)可以正當地補充結構欄位——
216
+ 它能抓到那些寫進散文、從沒真的填進結構欄位的項目。但它繼承了 [class-level-fix](class-level-fix.md)
217
+ 對任何列舉清單指出的同一個限制:**它正確到下一個成員用清單沒預料到的寫法出現為止。**
218
+ **OWT-011** 要求它的涵蓋率明示為未知,且禁止它跑出乾淨結果就被回報成「沒有漏掉」。
219
+
220
+ ---
221
+
222
+ ## A requirement that cannot be checked is not a requirement here
223
+
224
+ **OWT-014** is a constraint on this standard's own contents, the same role [deferred-item-exit](deferred-item-exit.md)'s DEX-003 plays for that standard. Every requirement above names artefacts and a relation between them that a reader — or something a project builds — can decide. A property this standard cared about but could not phrase this way was left out of the table rather than included as an unenforceable aspiration. One example: "the capture point actually gets used" is exactly the outcome OWT-001 exists to protect, but it is a claim about human behavior over time, not a decidable relation over an artefact at a point in time — so it is stated here, in prose, as the *reason* for OWT-001, and is not itself a numbered requirement.
225
+
226
+ **OWT-014** 是對本標準自身內容的約束,與 [deferred-item-exit](deferred-item-exit.md) 的
227
+ DEX-003 扮演的角色相同。上面每一條都指名了 artefact 與它們之間可被判定的關係。
228
+ 一個本標準在意、卻無法這樣措辭的性質,會被排除在表格之外,而不是被寫成一條無法執行的期望。
229
+ 舉一例:「收件點真的有被使用」正是 OWT-001 存在要保護的結果,但那是一句關於人類長期行為的宣稱,
230
+ 不是某個時間點上 artefact 之間可判定的關係——所以它以散文形式出現在這裡,
231
+ 作為 OWT-001 存在的**理由**,而不是一條有編號的要求。
232
+
233
+ ### A check that has never been red
234
+
235
+ **OWT-015** carries [deferred-item-exit](deferred-item-exit.md)'s DEX-004 forward unchanged in substance: **a check that has never failed and a check that cannot fail produce identical output.** Until a check claimed as evidence for any requirement above has been observed reporting failure against a sample deliberately built to violate that requirement, its passing is evidence that something ran, not evidence that the requirement holds. The procedure for producing that evidence, and why it must be done per sub-requirement rather than in aggregate, is not restated here — see [class-level-fix](class-level-fix.md) and [verification-evidence](verification-evidence.md).
236
+
237
+ **OWT-015** 原封不動地延續 [deferred-item-exit](deferred-item-exit.md) 的 DEX-004:
238
+ **一支從未失敗過的檢查,與一支不可能失敗的檢查,輸出一模一樣。** 在一支被宣稱為上面
239
+ 任一要求之證據的檢查,被觀察到「對一個刻意違反該要求的樣本回報失敗」之前,
240
+ 它的通過只是「有東西跑過」的證據,不是「要求成立」的證據。產生這份證據的程序、
241
+ 以及為何必須逐條而非整體進行,此處不複述——見 [class-level-fix](class-level-fix.md)
242
+ 與 [verification-evidence](verification-evidence.md)。
243
+
244
+ ### Thresholds carry their provenance
245
+
246
+ **OWT-016** carries DEX-009 forward: a threshold with no recorded origin is a threshold nobody can evaluate changing. This standard's own two numeric thresholds are marked accordingly in [Evidence and calibration](#evidence-and-calibration) below, rather than being asserted as settled.
247
+
248
+ **OWT-016** 延續 DEX-009:一個沒有來歷的閾值,是一個沒有人能評估要不要改的閾值。
249
+ 本標準自己的兩個數字閾值在下方〈[證據與校準](#evidence-and-calibration)〉裡照此標示,而非被斷言為已定案。
250
+
251
+ ---
252
+
253
+ ## Anti-patterns
254
+
255
+ | Anti-pattern | Why it fails |
256
+ |---|---|
257
+ | A capture form with three or more required fields | Measurably stops being used; the friction it adds is paid by whoever is interrupting their own work |
258
+ | "We'll revisit this" with no release condition | Indistinguishable from forgotten; nothing brings it back |
259
+ | A hand-typed status that duplicates what git or CI already know | Two owners, one of which is never updated |
260
+ | A "last reconciled" date with no content-derived proof | Looks identical whether the content was actually re-checked or the date was just typed |
261
+ | "47 items remain" with no stated denominator | Reads as complete by default; the invisible majority is mistaken for "done" |
262
+ | A checkpoint at shell startup instead of at turn end | Drifts for exactly as long as nobody happens to open a new shell |
263
+ | A checkpoint that blocks the turn on "some work remains" | Fires on every turn; a gate that is always true gets disabled, and then protects nothing |
264
+ | Triage status read only from prose wording | Correct until an item is phrased a way the wording list did not anticipate |
265
+ | An item that silently vanishes from the carrier | Indistinguishable from a bug that lost it |
266
+
267
+ | 反模式 | 為什麼會失敗 |
268
+ |---|---|
269
+ | 三個以上必填欄位的收件表單 | 可量測地不再被使用;那份摩擦由正在打斷自己工作的人承擔 |
270
+ | 「之後再看」而沒有解除條件 | 與被忘記無法分辨;沒有東西會讓它回來 |
271
+ | 手動輸入、重複 git 或 CI 已知資訊的狀態 | 兩個擁有者,其中一個永遠不會被更新 |
272
+ | 沒有內容證明的「最後對過帳」日期 | 內容真的被重新核對過,跟日期只是被打上去,看起來一模一樣 |
273
+ | 「還有 47 項」而不寫分母 | 預設被讀成完整;看不見的大多數被誤讀成「都做完了」 |
274
+ | 確認點掛在 shell 啟動而不是回合結束 | 只要沒人剛好開新 shell,它就持續漂移 |
275
+ | 確認點擋住回合結束、理由是「還有工作沒做完」 | 每個回合都會觸發;永遠為真的閘門會被關掉,關掉之後什麼都不保護 |
276
+ | 分類狀態只靠散文措辭判讀 | 正確到某個項目用清單沒預料到的方式寫出來為止 |
277
+ | 項目從承載庫裡無聲消失 | 與一個弄丟它的 bug 無從分辨 |
278
+
279
+ ---
280
+
281
+ ## What enforces this standard
282
+
283
+ **Nothing in UDS does, and that is recorded rather than implied.** UDS states the relations a carrier of open work must satisfy; whether anything decides them is the adopting project's call, per the [writing constraint](#how-this-standard-is-written--and-why-it-is-written-that-way) above — the same boundary [deferred-item-exit](deferred-item-exit.md) draws for its own exits.
284
+
285
+ **本標準沒有任何 UDS 側的閘門,而這件事是被記錄的,不是被暗示的。** UDS 陳述一個承載開放工作的地方
286
+ 必須滿足的關係;有沒有東西去判定它,依上面的[寫法約束](#how-this-standard-is-written--and-why-it-is-written-that-way),
287
+ 是採用專案的決定——與 [deferred-item-exit](deferred-item-exit.md) 對自己出口劃的界線相同。
288
+
289
+ What this standard does do is make that call visible: OWT-014 guarantees every requirement here **can** be decided, OWT-015 fixes what it takes for a decision to count, and OWT-005/OWT-011 fix what a partial decision is allowed to print.
290
+
291
+ 本標準做的事,是讓那個決定顯形:OWT-014 保證這裡每一條**能**被判定,OWT-015 固定
292
+ 「一次判定要算數需要什麼」,OWT-005/OWT-011 固定「一次不完整的判定容許印出什麼」。
293
+
294
+ ---
295
+
296
+ ## Evidence and calibration
297
+
298
+ This standard's shape comes from one adopting project's observations made and acted on the same day the standard was drafted (XSPEC-427, 2026-09-23): a capture point, a summary script with self-test arms, and an end-of-turn hook, built and run for the first time that day. **That reference implementation is hours old at the time of writing, has one user, and has run in one repository.** It is cited here only as the origin of the requirements' shape, never as validation of the specific thresholds below.
299
+
300
+ 本標準的形狀來自一個採用專案在標準草擬**同一天**做出並實跑的觀察(XSPEC-427,2026-09-23):
301
+ 一個收件點、一支帶自測臂的摘要腳本、一個掛在回合結束的 hook,當天第一次建立並執行。
302
+ **寫下這段文字時,那個參考實作只有幾小時大、只有一個使用者、只在一個 repo 跑過。**
303
+ 它在此被引用,僅作為要求形狀的出處,**絕不作為下面具體閾值的驗證**。
304
+
305
+ - **OWT-001's "no more than two fields"** and **OWT-012's "past the declared threshold"** (illustrated at two weeks in the originating observation) are **initial judgments, not measurements** — per OWT-016. No controlled comparison exists yet between two fields and three, or between a two-week and a four-week unclassified threshold.
306
+ - Recalibrating either number against real usage, or downgrading either into project-specific guidance, is the adopting project's decision to make and to date — this standard does not carry that commitment, the same way it carries no gate.
307
+
308
+ - **OWT-001 的「不超過兩個欄位」**與**OWT-012 的「過了宣告的門檻」**(在原始觀察中以兩週為例)
309
+ 依 OWT-016 是**初始判斷,不是量測結果**——兩個欄位跟三個欄位、兩週跟四週的未分類門檻,
310
+ 目前都沒有對照比較過。
311
+ - 依實際使用情況重新校準這兩個數字、或將其中任一個降級為專案特定指引,是採用專案自己的決定
312
+ 與自己的時程——本標準不承諾這件事,如同它不附帶閘門一樣。
313
+
314
+ ---
315
+
316
+ ## Relationship to other standards
317
+
318
+ - [deferred-item-exit](deferred-item-exit.md) — the upstream half of the same shape: DEX requires that a deferred item leave its document for a traceable exit and deliberately leaves the exit's carrier unspecified. This standard picks up **after** the exit exists, requiring the carrier itself not to become the next document things get lost in.
319
+ - [turn-completion-integrity](turn-completion-integrity.md) — attaches to the same event (turn end) and is built to behave oppositely: TCI blocks on a rare, specific abandoned commitment; this standard's checkpoint (OWT-007–OWT-009) never blocks, because the condition it watches for is close to always true. See [the comparison table](#the-checkpoint-is-a-report-not-a-gate).
320
+ - [class-level-fix](class-level-fix.md) — the general form of the wording-list limit OWT-011 discloses, and the source of the non-vacuous-evidence procedure OWT-015 requires.
321
+ - [verification-evidence](verification-evidence.md) — the source of the exit-code and evidence-validity reasoning OWT-015 depends on; also where a partial-coverage exception (OWT-006, OWT-011) is registered rather than merely disclosed once.
322
+
323
+ - [deferred-item-exit](deferred-item-exit.md) — 同一個形狀的上游一半:DEX 要求延後項目離開文件、
324
+ 抵達可追蹤的出口,並刻意不規定出口的載體。本標準接手**出口存在之後**的事,
325
+ 要求那個載體自己不要變成下一份東西會不見的文件。
326
+ - [turn-completion-integrity](turn-completion-integrity.md) — 掛在同一個事件(回合結束)
327
+ 上,且被設計成行為相反:TCI 擋在一個罕見、明確的被放棄承諾上;本標準的確認點
328
+ (OWT-007–OWT-009)永不阻斷,因為它在看的條件幾乎永遠為真。見〈[對照表](#the-checkpoint-is-a-report-not-a-gate)〉。
329
+ - [class-level-fix](class-level-fix.md) — OWT-011 揭露的措辭清單限制的通則形式,
330
+ 也是 OWT-015 所要求「非空跑證據」程序的來源。
331
+ - [verification-evidence](verification-evidence.md) — OWT-015 所依賴的 exit code
332
+ 與證據有效性推理的來源;也是 OWT-006/OWT-011 的部分涵蓋例外該被登記的地方,
333
+ 而不是揭露一次就放著。
@@ -1,8 +1,8 @@
1
1
  ---
2
2
  source: ../../CHANGELOG.md
3
- source_version: 6.11.0
4
- translation_version: 6.11.0
5
- last_synced: 2026-09-18
3
+ source_version: 6.12.0
4
+ translation_version: 6.12.0
5
+ last_synced: 2026-09-24
6
6
  status: current
7
7
  ---
8
8
 
@@ -17,6 +17,12 @@ status: current
17
17
 
18
18
  ## [Unreleased]
19
19
 
20
+ ## [6.12.0] - 2026-09-25
21
+
22
+ ### 新增
23
+
24
+ - **新标准 `open-work-tracking`——`deferred-item-exit` 的下游一半。** `deferred-item-exit` 要求被推迟的条目离开原文件、走向可追溯的出口,但刻意不规定出口的承载处;条目进入承载处之后,没有任何规则防止承载处本身腐坏。本标准以 16 条要求(OWT-001~016)补上:低摩擦的记录点(必填字段至多两个)、每个等待中的条目旁写明解除条件、可推导的字段由生成而非手写、以内容证明"最新"而非可随手改的时间戳、覆盖率数字要写出它看不到什么,以及每轮结束时报告未完成工作但**从不阻挡**的检查点。最后一点刻意与挂在同一事件、会阻挡的 `turn-completion-integrity` 相反;标准内附对照表,避免采用者把两者接成同一件事。其中两个数字门槛标明为初始判断、非测量结果。
25
+
20
26
  ## [6.11.0] - 2026-09-18
21
27
 
22
28
  ### 修复
@@ -14,7 +14,7 @@ status: current
14
14
 
15
15
  Universal Development Standards 是一个语言无关、框架无关的文件化标准框架。它提供:
16
16
 
17
- - **核心规范** (`core/`):152 个基础开发标准
17
+ - **核心规范** (`core/`):153 个基础开发标准
18
18
  - **AI 技能** (`skills/`):用于 AI 辅助开发的 Claude Code 技能
19
19
  - **CLI 工具** (`cli/`):用于采用标准的 Node.js CLI
20
20
  - **整合** (`integrations/`):各种 AI 工具的配置
@@ -15,7 +15,7 @@ status: current
15
15
 
16
16
  > **语言**: [English](../../README.md) | [繁體中文](../zh-TW/README.md) | 简体中文
17
17
 
18
- **版本**: 6.11.0 | **发布日期**: 2026-09-16 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
18
+ **版本**: 6.12.0 | **发布日期**: 2026-09-25 | **授权**: [双重授权](../../LICENSE) (CC BY 4.0 + MIT)
19
19
 
20
20
  语言无关、框架无关的软件项目文档标准。通过 AI 原生工作流,确保不同技术栈之间的一致性、质量和可维护性。
21
21
 
@@ -76,7 +76,7 @@ npx universal-dev-standards init
76
76
  <!-- UDS_STATS_TABLE_START -->
77
77
  | 类别 | 数量 | 说明 |
78
78
  |----------|-------|-------------|
79
- | **核心标准** | 152 | 通用开发准则 |
79
+ | **核心标准** | 153 | 通用开发准则 |
80
80
  | **AI Skills** | 55 | 互动式技能 |
81
81
  | **斜线命令** | 51 | 快速操作 |
82
82
  | **CLI 命令** | 23 | 项目设置与维护 |
@@ -13,7 +13,7 @@ status: current
13
13
  <!-- UDS_SUPPORTED_VERSIONS_START -->
14
14
  | 版本 | 支持状态 |
15
15
  |------|--------|
16
- | 6.11.0 | ✅ 最新正式版 |
16
+ | 6.12.0 | ✅ 最新正式版 |
17
17
  | < 6.0.0 | ❌ 已终止支持 |
18
18
  <!-- UDS_SUPPORTED_VERSIONS_END -->
19
19
 
@@ -1,6 +1,6 @@
1
1
  # UDS 速查表
2
2
 
3
- > Quick reference for all UDS features | Last updated: 2026-09-18
3
+ > Quick reference for all UDS features | Last updated: 2026-09-23
4
4
 
5
5
  **Language**: [English](../../../docs/user/CHEATSHEET.md) | [繁體中文](../../zh-TW/docs/CHEATSHEET.md) | 简体中文
6
6
 
@@ -260,6 +260,7 @@
260
260
  | `mutation-testing` | Mutation testing evaluates test suite effectivenes |
261
261
  | `no-cicd-deployment` | No-CI/CD Deployment Strategy |
262
262
  | `observability-standards` | Observability Standards |
263
+ | `open-work-tracking` | The deferred-item-exit standard requires that a de |
263
264
  | `packaging-standards` | This standard defines a Recipe-based packaging fra |
264
265
  | `performance-standards` | This standard defines comprehensive guidelines for |
265
266
  | `pii-classification` | PII Classification and Handling Standards |
@@ -1,7 +1,7 @@
1
1
  # UDS 功能参考手册
2
2
 
3
3
  > Universal Development Standards - 完整功能文档
4
- > Auto-generated | Last updated: 2026-09-18
4
+ > Auto-generated | Last updated: 2026-09-23
5
5
 
6
6
  **Language**: [English](../../../docs/reference/FEATURE-REFERENCE.md) | [繁體中文](../../zh-TW/docs/FEATURE-REFERENCE.md) | 简体中文
7
7
 
@@ -14,10 +14,10 @@
14
14
  3. [技能](#skills) (55)
15
15
  4. [代理](#agents) (5)
16
16
  5. [工作流程](#workflows) (5)
17
- 6. [核心规范](#core-standards) (152)
17
+ 6. [核心规范](#core-standards) (153)
18
18
  7. [脚本](#scripts) (59)
19
19
 
20
- **Total Features: 350**
20
+ **Total Features: 351**
21
21
 
22
22
  ---
23
23
 
@@ -516,6 +516,7 @@
516
516
  | `mutation-testing` | 1.1.0 | Mutation testing evaluates test suite effectiveness by injecting artificial bugs |
517
517
  | `no-cicd-deployment` | - | |
518
518
  | `observability-standards` | 1.0.0 | |
519
+ | `open-work-tracking` | 1.0.0 | The deferred-item-exit standard requires that a deferred item leave its document |
519
520
  | `packaging-standards` | 1.1.0 | This standard defines a Recipe-based packaging framework that enables user proje |
520
521
  | `performance-standards` | 1.2.0 | This standard defines comprehensive guidelines for software performance engineer |
521
522
  | `pii-classification` | 1.1.0 | **Status**: Active | **Updated**: 2026-06-19 | |
@@ -1,8 +1,8 @@
1
1
  ---
2
2
  source: ../../CHANGELOG.md
3
- source_version: 6.11.0
4
- translation_version: 6.11.0
5
- last_synced: 2026-09-18
3
+ source_version: 6.12.0
4
+ translation_version: 6.12.0
5
+ last_synced: 2026-09-24
6
6
  status: current
7
7
  ---
8
8
 
@@ -17,6 +17,12 @@ status: current
17
17
 
18
18
  ## [Unreleased]
19
19
 
20
+ ## [6.12.0] - 2026-09-25
21
+
22
+ ### 新增
23
+
24
+ - **新標準 `open-work-tracking`——`deferred-item-exit` 的下游一半。** `deferred-item-exit` 要求被延後的項目離開原文件、走向可追溯的出口,但刻意不規定出口的承載處;東西進了承載處之後,沒有任何規則防止承載處本身腐壞。本標準以 16 條要求(OWT-001~016)補上:低摩擦的記錄點(必填欄位至多兩個)、每個等待中的項目旁寫明解除條件、可推導的欄位由產生而非手寫、以內容證明「最新」而非可隨手改的時間戳、覆蓋率數字要寫出它看不到什麼,以及每輪結束時回報未完成工作但**從不阻擋**的檢查點。最後一點刻意與掛在同一事件、會阻擋的 `turn-completion-integrity` 相反;標準內附對照表,避免採用者把兩者接成同一件事。其中兩個數字門檻標明為初始判斷、非量測結果。
25
+
20
26
  ## [6.11.0] - 2026-09-18
21
27
 
22
28
  ### 修正
@@ -14,7 +14,7 @@ status: current
14
14
 
15
15
  Universal Development Standards 是一個語言無關、框架無關的文件化標準框架。它提供:
16
16
 
17
- - **核心規範** (`core/`):152 個基礎開發標準
17
+ - **核心規範** (`core/`):153 個基礎開發標準
18
18
  - **AI 技能** (`skills/`):用於 AI 輔助開發的 Claude Code 技能
19
19
  - **CLI 工具** (`cli/`):用於採用標準的 Node.js CLI
20
20
  - **整合** (`integrations/`):各種 AI 工具的配置
@@ -15,7 +15,7 @@ status: current
15
15
 
16
16
  > **語言**: [English](../../README.md) | 繁體中文 | [简体中文](../zh-CN/README.md)
17
17
 
18
- **版本**: 6.11.0 | **發布日期**: 2026-09-16 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
18
+ **版本**: 6.12.0 | **發布日期**: 2026-09-25 | **授權**: [雙重授權](../../LICENSE) (CC BY 4.0 + MIT)
19
19
 
20
20
  語言無關、框架無關的軟體專案文件標準。透過 AI 原生工作流,確保不同技術堆疊之間的一致性、品質和可維護性。
21
21
 
@@ -76,7 +76,7 @@ npx universal-dev-standards init
76
76
  <!-- UDS_STATS_TABLE_START -->
77
77
  | 類別 | 數量 | 說明 |
78
78
  |----------|-------|-------------|
79
- | **核心標準** | 152 | 通用開發準則 |
79
+ | **核心標準** | 153 | 通用開發準則 |
80
80
  | **AI Skills** | 55 | 互動式技能 |
81
81
  | **斜線命令** | 51 | 快速操作 |
82
82
  | **CLI 指令** | 23 | 專案設定與維護 |
@@ -13,7 +13,7 @@ status: current
13
13
  <!-- UDS_SUPPORTED_VERSIONS_START -->
14
14
  | 版本 | 支援狀態 |
15
15
  |------|--------|
16
- | 6.11.0 | ✅ 最新正式版 |
16
+ | 6.12.0 | ✅ 最新正式版 |
17
17
  | < 6.0.0 | ❌ 已終止支援 |
18
18
  <!-- UDS_SUPPORTED_VERSIONS_END -->
19
19
 
@@ -0,0 +1,255 @@
1
+ ---
2
+ source: ../../../core/open-work-tracking.md
3
+ source_version: 1.0.0
4
+ translation_version: 1.0.0
5
+ last_synced: 2026-09-23
6
+ source_hash: 8382d3f518a9
7
+ status: current
8
+ ---
9
+
10
+ # 開放工作追蹤標準
11
+
12
+ > **Language**: [English](../../../core/open-work-tracking.md) | 繁體中文
13
+
14
+ **版本**: 1.0.0
15
+ **最後更新**: 2026-09-23
16
+ **適用**: 任何跨越一個以上工作階段承載工作、有可能在階段之間遺失項目的專案
17
+ **範圍**: universal
18
+
19
+ ---
20
+
21
+ ## 目的
22
+
23
+ 延後項目出口標準(deferred-item-exit)要求延後項目離開文件、抵達一個可追蹤的出口,
24
+ 但刻意不規定那個出口長什麼樣、也不規定項目抵達之後什麼東西防止它腐壞。
25
+ **本標準是那個下游的一半**:假設一個承載開放工作的地方已經存在,
26
+ 它自己必須具備什麼性質才不會慢慢變得不可信。見 [deferred-item-exit](deferred-item-exit.md)。
27
+
28
+ 三種不同的「工作不見了」的方式,常被塞進同一份沒有分別的清單,而**這個合併本身就是失敗的一部分**——
29
+ 一份想同時接住三者的清單,通常一個都接不好:
30
+
31
+ | 症狀 | 背後的問題 | 需要的機制 |
32
+ |---|---|---|
33
+ | 工作進行中冒出新項目,沒有低摩擦的地方可以記下它 | 項目有時效性,等到方便記錄時已經忘了 | 一個便宜到不會打斷當前工作的收件點 |
34
+ | 某項目因等待別的事件而暫停 | 「等待中」若沒有記錄解除條件,與「被忘記」無法分辨 | 與等待一起記錄的解除條件 |
35
+ | 已規劃的項目還沒動工,時間過去 | 沒有時鐘的項目會無聲腐爛——沒有東西會再指向它 | 一個門檻,或一次被迫的定期檢視,讓它重新浮現 |
36
+
37
+ 下面每一條要求都對應這張表的一列,或對應本標準設計當天觀察到的四個失效之一
38
+ (見〈[證據與校準](#證據與校準)〉)。**沒有任何一個機制被規定**——
39
+ 理由與 [deferred-item-exit](deferred-item-exit.md) 對自己出口的約束相同(DEC-049:
40
+ UDS 定義必須成立的關係,維持它的機制由採用層選擇)。
41
+
42
+ ---
43
+
44
+ ## 本標準的寫法,以及為什麼這樣寫
45
+
46
+ **讀下面任何一條要求之前先讀這一段。它拘束它們全部。**
47
+
48
+ UDS 定義**活動**,採用層負責**編排**(DEC-049)。一份寫成工作流協定、檔案格式、
49
+ 或特定工具設定的標準屬於採用層,不屬於這裡——這與 [deferred-item-exit](deferred-item-exit.md)
50
+ 受的約束相同,只是套用在下游一層。
51
+
52
+ | 這裡容許——**what** | 這裡不容許——**how** |
53
+ |---|---|
54
+ | 收件點欄位數必須具備的性質 | 收件點是哪個 app、檔案或工單系統 |
55
+ | 等待項目與解除條件之間必須存在的關係 | 輪詢那個條件的排程器或機器人 |
56
+ | 「這是最新的」這句宣稱必須從什麼可被證明 | 具體用哪個雜湊函式、diff 工具或 CI 供應商 |
57
+ | 一個回報數字與它看不到的部分之間的關係 | 儀表板版面或報告範本 |
58
+ | 控制權交回人的那一點存在一個確認點,且它永不阻斷 | 用什麼 hook 系統、shell 或 cron 實作它 |
59
+
60
+ **直說它的後果**:本標準**不附帶任何閘門**。它只說一個承載開放工作的地方必須具備什麼性質;
61
+ 有沒有東西在檢查,是採用專案的決定——[OWT-014](#要求) 與 [OWT-015](#要求)
62
+ 存在的目的,是讓那個決定沒辦法被默默做掉。
63
+
64
+ ---
65
+
66
+ ## 不變量
67
+
68
+ **一個承載開放工作的地方,必須:(1)不要求分類就能收下新項目、(2)為每一個標為等待中的項目記下解除條件、
69
+ (3)對任何有可靠來源可推導的欄位改用生成、(4)回報還剩什麼時同時揭露看不到什麼、
70
+ (5)在控制權從 agent 交回人的那一刻被檢視——而且那個檢視不能讓回合失敗。**
71
+
72
+ ---
73
+
74
+ ## 要求
75
+
76
+ | ID | 要求 | 嚴重度 |
77
+ |---|---|---|
78
+ | **OWT-001** | 新項目的收件點必填欄位不得超過兩個。分類、優先級、負責人一律是 triage 時的動作,不得成為輸入門檻 | error |
79
+ | **OWT-002** | 標為等待中的項目,同時記下在等什麼與什麼事件視為解除 | error |
80
+ | **OWT-003** | 能從版控、規格標記、或 CI 結果完整推導的欄位,一律生成,不手寫 | error |
81
+ | **OWT-004** | 生成區段的「最新」宣稱能從它所本的內容證明(例如來源雜湊),不靠一個人可編輯的日期 | error |
82
+ | **OWT-005** | 「內容可證明最新」與「日期宣稱最新、內容未驗證」回報為兩個相異狀態。合併為單一通過即不滿足 OWT-004 | error |
83
+ | **OWT-006** | 任何「還有 N 項」的數字,旁邊同時印出看得見多少來源、看不見多少來源。看不見的部分不被讀成零 | error |
84
+ | **OWT-007** | 開放工作摘要出現在控制權從 agent 交回人的那一刻——不只是掛在 session 開始、CI、或追蹤文件被編輯時 | error |
85
+ | **OWT-008** | 開放工作摘要自己的結束路徑,不論輸入為何(含「還有很多項」)都不改變回合的結果 | error |
86
+ | **OWT-009** | 摘要與一道阻斷式檢查掛同一個回合結束事件時,摘要的輸出排在阻斷判決之前 | warning |
87
+ | **OWT-010** | 判定項目是等待中、未分類、還是已丟棄,來自承載庫自定義的結構欄位,不只靠掃描散文措辭 | error |
88
+ | **OWT-011** | 以措辭啟發式補充結構欄位時,明示其涵蓋率未知,其乾淨結果不回報為「沒有漏掉」 | warning |
89
+ | **OWT-012** | 超過宣告門檻仍未分類的項目,在開放工作摘要裡被個別點名,不被合併進一個總數 | error |
90
+ | **OWT-013** | 項目從承載庫移除而未變成規格、追蹤項目、或任何其他具名去向時,帶一句理由。沒有理由的移除與靜默刪除無法分辨 | error |
91
+ | **OWT-014** | 本標準的每一條要求都可表述為 artefact 之間可判定的關係。不能如此表述的要求不得進入本標準 | error |
92
+ | **OWT-015** | 被提出作為本標準任一要求之證據的檢查,已被觀察到對一個刻意違反該要求的樣本回報失敗。從未紅過的檢查不是可採信的證據 | error |
93
+ | **OWT-016** | 本標準各要求所引用的任何窗口或閾值,載明來歷,或標為未校準 | warning |
94
+
95
+ ---
96
+
97
+ ## 收件幾乎不能有成本
98
+
99
+ **OWT-001** 之所以存在,是因為多一個必填欄位的收件點,量測到的結果是**不被使用**。
100
+ 這不是假想的摩擦——它是「工作進行中冒出新想法,記下它要跟正在做的事搶時間」這個情境的具體形狀。
101
+ 在**輸入當下**就要求分類、優先級或負責人,是在賭「正在被打斷的人願意付那個成本」,
102
+ 而這個賭注輸的次數比贏的多;一個沒有人用的收件點不是收件點,是一張表單。
103
+
104
+ 分類(決定項目屬於哪裡)是另一個、之後才做的動作。**OWT-012** 與 **OWT-013**
105
+ 規範分類永遠不來時會發生什麼:項目不准永遠隱形地待著,也不准無理由地消失。
106
+
107
+ ---
108
+
109
+ ## 沒有解除條件的等待項目,是戴著狀態標籤的遺忘項目
110
+
111
+ **OWT-002** 指出「暫停中、有東西會讓它回來」與「暫停中、永遠、只是貼了一個讓它看起來不像永遠的標籤」
112
+ 之間的差別。解除條件應盡可能是**機器看得見的**——一個日期、一個會出現的識別字、一個檔案存在——
113
+ 讓項目有機會自己跳出來,而不是依賴某個人記得它存在。真的找不到機器看得見的條件時,
114
+ 仍然要求一個人看得懂的條件;**OWT-002 不要求自動化,只要求那個條件被記下來這件事本身**。
115
+
116
+ ---
117
+
118
+ ## 戳比事實好寫,而只讀戳的檢查分不出兩者
119
+
120
+ 這是 DEX-006 在另一個 artefact 上點名的同一種失敗,只是換了一層。DEX-006 那邊,
121
+ 識別字的存在被誤讀成它指向的出口是對的;這裡,**生成區段的時間戳很新,被誤讀成內容是新的**——
122
+ 而這兩者分歧的方式,對任何只比較日期的檢查是隱形的:
123
+
124
+ - 戳比內容舊:拿戳跟檔案自己的修改紀錄一比就抓到,微不足道。
125
+ - 戳**比內容新**,而內容本身已經過期:**隱形**,因為「戳是新的」正是一次正確對帳看起來的樣子。
126
+
127
+ **OWT-004** 要求「這是最新的」這句宣稱可以從內容本身被證明——例如儲存一份該區段
128
+ 是從哪個來源生成的雜湊、放在區段旁邊,這樣不比對內容也能偵測到不一致,
129
+ 不必信任「最後動手改日期的人也真的對過帳」。**OWT-005** 要求「內容可證明是最新的」
130
+ 與「日期這麼說、內容未驗證」永遠不共用同一個通過/失敗位元,理由與 DEX-005/DEX-006
131
+ 要求延後項目出口做同一件事相同:一個被回報成通過的未知,比一個被回報成未知的未知更糟,
132
+ 因為後者還找得到。
133
+
134
+ ---
135
+
136
+ ## 涵蓋率必須聲明自己的盲區
137
+
138
+ **OWT-006** 要求任何「還有 N 項」的數字旁邊,同時印出它看得見多少來源、看不見多少來源——
139
+ 不是因為預期看不見的數字會是零,而是因為讀者分不出「涵蓋率 11.7%,而且有 386 項
140
+ 對這個數字完全隱形」與「涵蓋率 11.7% 就是全貌」,除非分母被印在旁邊。
141
+ 一個沒有聲明盲區的涵蓋率數字,預設會被讀成完整——而那個預設正是這條要求要防的失效。
142
+
143
+ ---
144
+
145
+ ## 確認點是一份報告,不是一道閘門
146
+
147
+ **turn-completion-integrity**([TCI](turn-completion-integrity.md))與本標準的 OWT-007–OWT-009
148
+ 都掛在同一個事件——agent 的回合結束、控制權交回人類的那一刻——而它們被刻意設計成
149
+ **行為相反**。把兩者接到同一個事件卻不理解為什麼不同,會產出「擋在一件幾乎永遠為真的事情上的
150
+ 確認點」,或是「被誤認成閘門的報告」,兩者都不對:
151
+
152
+ | | [turn-completion-integrity](turn-completion-integrity.md) | 本標準(OWT-007–009) |
153
+ |---|---|---|
154
+ | 它在看什麼 | agent 自己最後一則訊息,看有沒有一個第一人稱承諾被說出口又被放棄 | 承載庫裡的任何項目,看有沒有沒解除條件的、沒出口的、或過門檻還沒分類的 |
155
+ | 預設狀態 | 罕見——只在那則訊息裡明確做了承諾又被丟下時才觸發 | 常見——「還有工作沒做完」幾乎永遠為真 |
156
+ | 違反時會怎樣 | 擋住回合結束,直到承諾被解決或說明卡在誰身上 | 永不阻斷。只能回報(OWT-008) |
157
+ | 為什麼行為相反 | 它在看的事件本身夠稀少,擋在它上面不會把耐性用完 | TCI 自己的規則已經寫出這裡不能做成閘門的理由:**「一個在每個回合都為真的閘門會被關掉,關掉之後它什麼都不保護」**(TCI R4)。開放工作非空幾乎永遠為真,所以這個確認點被設計成永不保留控制權 |
158
+ | 兩者掛同一事件時的順序 | — | 先回報(OWT-009),所以即使那個回合隨後被 TCI 擋下,它的輸出仍然可見 |
159
+
160
+ ---
161
+
162
+ ## 錨點:走訪結構,不走訪措辭
163
+
164
+ 判定一個項目是等待中、未分類、還是已丟棄,要**讀承載庫自己描述那個狀態的結構欄位**——
165
+ 一個狀態欄、一個型別化標記、一個小節標題——與 [deferred-item-exit](deferred-item-exit.md)
166
+ 的 DEX-007 要求走訪文件結構而非措辭來找延後項目是同一個道理。**OWT-010** 要求那個結構欄位
167
+ 存在,並且是真相的主要來源。
168
+
169
+ 一次自由文字措辭掃描(「含有『等待』這個詞」)可以正當地補充結構欄位——
170
+ 它能抓到那些寫進散文、從沒真的填進結構欄位的項目。但它繼承了 [class-level-fix](class-level-fix.md)
171
+ 對任何列舉清單指出的同一個限制:**它正確到下一個成員用清單沒預料到的寫法出現為止。**
172
+ **OWT-011** 要求它的涵蓋率明示為未知,且禁止它跑出乾淨結果就被回報成「沒有漏掉」。
173
+
174
+ ---
175
+
176
+ ## 一條無法被檢查的要求,不是這裡的要求
177
+
178
+ **OWT-014** 是對本標準自身內容的約束,與 [deferred-item-exit](deferred-item-exit.md) 的
179
+ DEX-003 扮演的角色相同。上面每一條都指名了 artefact 與它們之間可被判定的關係。
180
+ 一個本標準在意、卻無法這樣措辭的性質,會被排除在表格之外,而不是被寫成一條無法執行的期望。
181
+ 舉一例:「收件點真的有被使用」正是 OWT-001 存在要保護的結果,但那是一句關於人類長期行為的宣稱,
182
+ 不是某個時間點上 artefact 之間可判定的關係——所以它以散文形式出現在這裡,
183
+ 作為 OWT-001 存在的**理由**,而不是一條有編號的要求。
184
+
185
+ ### 一支從未紅過的檢查
186
+
187
+ **OWT-015** 原封不動地延續 [deferred-item-exit](deferred-item-exit.md) 的 DEX-004:
188
+ **一支從未失敗過的檢查,與一支不可能失敗的檢查,輸出一模一樣。** 在一支被宣稱為上面
189
+ 任一要求之證據的檢查,被觀察到「對一個刻意違反該要求的樣本回報失敗」之前,
190
+ 它的通過只是「有東西跑過」的證據,不是「要求成立」的證據。產生這份證據的程序、
191
+ 以及為何必須逐條而非整體進行,此處不複述——見 [class-level-fix](class-level-fix.md)
192
+ 與 [verification-evidence](verification-evidence.md)。
193
+
194
+ ### 閾值必須帶著來歷
195
+
196
+ **OWT-016** 延續 DEX-009:一個沒有來歷的閾值,是一個沒有人能評估要不要改的閾值。
197
+ 本標準自己的兩個數字閾值在下方〈[證據與校準](#證據與校準)〉裡照此標示,而非被斷言為已定案。
198
+
199
+ ---
200
+
201
+ ## 反模式
202
+
203
+ | 反模式 | 為什麼會失敗 |
204
+ |---|---|
205
+ | 三個以上必填欄位的收件表單 | 可量測地不再被使用;那份摩擦由正在打斷自己工作的人承擔 |
206
+ | 「之後再看」而沒有解除條件 | 與被忘記無法分辨;沒有東西會讓它回來 |
207
+ | 手動輸入、重複 git 或 CI 已知資訊的狀態 | 兩個擁有者,其中一個永遠不會被更新 |
208
+ | 沒有內容證明的「最後對過帳」日期 | 內容真的被重新核對過,跟日期只是被打上去,看起來一模一樣 |
209
+ | 「還有 47 項」而不寫分母 | 預設被讀成完整;看不見的大多數被誤讀成「都做完了」 |
210
+ | 確認點掛在 shell 啟動而不是回合結束 | 只要沒人剛好開新 shell,它就持續漂移 |
211
+ | 確認點擋住回合結束、理由是「還有工作沒做完」 | 每個回合都會觸發;永遠為真的閘門會被關掉,關掉之後什麼都不保護 |
212
+ | 分類狀態只靠散文措辭判讀 | 正確到某個項目用清單沒預料到的方式寫出來為止 |
213
+ | 項目從承載庫裡無聲消失 | 與一個弄丟它的 bug 無從分辨 |
214
+
215
+ ---
216
+
217
+ ## 什麼在執行本標準
218
+
219
+ **UDS 側沒有任何東西在執行,而這件事是被記錄的,不是被暗示的。** UDS 陳述一個承載開放工作的地方
220
+ 必須滿足的關係;有沒有東西去判定它,依上面的[寫法約束](#本標準的寫法以及為什麼這樣寫),
221
+ 是採用專案的決定——與 [deferred-item-exit](deferred-item-exit.md) 對自己出口劃的界線相同。
222
+
223
+ 本標準做的事,是讓那個決定顯形:OWT-014 保證這裡每一條**能**被判定,OWT-015 固定
224
+ 「一次判定要算數需要什麼」,OWT-005/OWT-011 固定「一次不完整的判定容許印出什麼」。
225
+
226
+ ---
227
+
228
+ ## 證據與校準
229
+
230
+ 本標準的形狀來自一個採用專案在標準草擬**同一天**做出並實跑的觀察(XSPEC-427,2026-09-23):
231
+ 一個收件點、一支帶自測臂的摘要腳本、一個掛在回合結束的 hook,當天第一次建立並執行。
232
+ **寫下這段文字時,那個參考實作只有幾小時大、只有一個使用者、只在一個 repo 跑過。**
233
+ 它在此被引用,僅作為要求形狀的出處,**絕不作為下面具體閾值的驗證**。
234
+
235
+ - **OWT-001 的「不超過兩個欄位」**與**OWT-012 的「過了宣告的門檻」**(在原始觀察中以兩週為例)
236
+ 依 OWT-016 是**初始判斷,不是量測結果**——兩個欄位跟三個欄位、兩週跟四週的未分類門檻,
237
+ 目前都沒有對照比較過。
238
+ - 依實際使用情況重新校準這兩個數字、或將其中任一個降級為專案特定指引,是採用專案自己的決定
239
+ 與自己的時程——本標準不承諾這件事,如同它不附帶閘門一樣。
240
+
241
+ ---
242
+
243
+ ## 與其他標準的關係
244
+
245
+ - [deferred-item-exit](deferred-item-exit.md) — 同一個形狀的上游一半:DEX 要求延後項目離開文件、
246
+ 抵達可追蹤的出口,並刻意不規定出口的載體。本標準接手**出口存在之後**的事,
247
+ 要求那個載體自己不要變成下一份東西會不見的文件。
248
+ - [turn-completion-integrity](turn-completion-integrity.md) — 掛在同一個事件(回合結束)
249
+ 上,且被設計成行為相反:TCI 擋在一個罕見、明確的被放棄承諾上;本標準的確認點
250
+ (OWT-007–OWT-009)永不阻斷,因為它在看的條件幾乎永遠為真。見〈[對照表](#確認點是一份報告不是一道閘門)〉。
251
+ - [class-level-fix](class-level-fix.md) — OWT-011 揭露的措辭清單限制的通則形式,
252
+ 也是 OWT-015 所要求「非空跑證據」程序的來源。
253
+ - [verification-evidence](verification-evidence.md) — OWT-015 所依賴的 exit code
254
+ 與證據有效性推理的來源;也是 OWT-006/OWT-011 的部分涵蓋例外該被登記的地方,
255
+ 而不是揭露一次就放著。
@@ -1,6 +1,6 @@
1
1
  # UDS 速查表
2
2
 
3
- > Quick reference for all UDS features | Last updated: 2026-09-18
3
+ > Quick reference for all UDS features | Last updated: 2026-09-23
4
4
 
5
5
  **Language**: [English](../../../docs/user/CHEATSHEET.md) | 繁體中文 | [简体中文](../../zh-CN/docs/CHEATSHEET.md)
6
6
 
@@ -260,6 +260,7 @@
260
260
  | `mutation-testing` | Mutation testing evaluates test suite effectivenes |
261
261
  | `no-cicd-deployment` | No-CI/CD Deployment Strategy |
262
262
  | `observability-standards` | Observability Standards |
263
+ | `open-work-tracking` | The deferred-item-exit standard requires that a de |
263
264
  | `packaging-standards` | This standard defines a Recipe-based packaging fra |
264
265
  | `performance-standards` | This standard defines comprehensive guidelines for |
265
266
  | `pii-classification` | PII Classification and Handling Standards |
@@ -1,7 +1,7 @@
1
1
  # UDS 功能參考手冊
2
2
 
3
3
  > Universal Development Standards - 完整功能文件
4
- > Auto-generated | Last updated: 2026-09-18
4
+ > Auto-generated | Last updated: 2026-09-23
5
5
 
6
6
  **Language**: [English](../../../docs/reference/FEATURE-REFERENCE.md) | 繁體中文 | [简体中文](../../zh-CN/docs/FEATURE-REFERENCE.md)
7
7
 
@@ -14,10 +14,10 @@
14
14
  3. [技能](#skills) (55)
15
15
  4. [代理](#agents) (5)
16
16
  5. [工作流程](#workflows) (5)
17
- 6. [核心規範](#core-standards) (152)
17
+ 6. [核心規範](#core-standards) (153)
18
18
  7. [腳本](#scripts) (59)
19
19
 
20
- **Total Features: 350**
20
+ **Total Features: 351**
21
21
 
22
22
  ---
23
23
 
@@ -516,6 +516,7 @@
516
516
  | `mutation-testing` | 1.1.0 | Mutation testing evaluates test suite effectiveness by injecting artificial bugs |
517
517
  | `no-cicd-deployment` | - | |
518
518
  | `observability-standards` | 1.0.0 | |
519
+ | `open-work-tracking` | 1.0.0 | The deferred-item-exit standard requires that a deferred item leave its document |
519
520
  | `packaging-standards` | 1.1.0 | This standard defines a Recipe-based packaging framework that enables user proje |
520
521
  | `performance-standards` | 1.2.0 | This standard defines comprehensive guidelines for software performance engineer |
521
522
  | `pii-classification` | 1.1.0 | **Status**: Active | **Updated**: 2026-06-19 | |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "universal-dev-standards",
3
- "version": "6.11.0",
3
+ "version": "6.12.0",
4
4
  "description": "CLI tool for adopting Universal Development Standards",
5
5
  "keywords": [
6
6
  "documentation",
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "$schema": "https://json-schema.org/draft/2020-12/schema",
3
- "version": "6.11.0",
3
+ "version": "6.12.0",
4
4
  "lastUpdated": "2026-05-13",
5
5
  "description": "Standards registry for universal-dev-standards with integrated skills and AI-optimized formats",
6
6
  "formats": {
@@ -58,14 +58,14 @@
58
58
  "standards": {
59
59
  "name": "universal-dev-standards",
60
60
  "url": "https://github.com/AsiaOstrich/universal-dev-standards",
61
- "version": "6.11.0"
61
+ "version": "6.12.0"
62
62
  },
63
63
  "skills": {
64
64
  "name": "universal-dev-standards",
65
65
  "url": "https://github.com/AsiaOstrich/universal-dev-standards",
66
66
  "localPath": "skills",
67
67
  "rawUrl": "https://raw.githubusercontent.com/AsiaOstrich/universal-dev-standards/main/skills",
68
- "version": "6.11.0",
68
+ "version": "6.12.0",
69
69
  "note": "Skills are now included in the main repository under skills/"
70
70
  }
71
71
  },
@@ -1789,6 +1789,18 @@
1789
1789
  "skillName": null,
1790
1790
  "description": "A deferred item must leave the document: a traceable exit outside it, identified beside the item. The carrier is deliberately unspecified. A present link is not a working link — verified and unverified links are two states, never one green. Anchor on document structure, not wording"
1791
1791
  },
1792
+ {
1793
+ "id": "open-work-tracking",
1794
+ "name": "Open Work Tracking Standard",
1795
+ "nameZh": "開放工作追蹤標準",
1796
+ "source": {
1797
+ "human": "core/open-work-tracking.md",
1798
+ "ai": "ai/standards/open-work-tracking.ai.yaml"
1799
+ },
1800
+ "category": "reference",
1801
+ "skillName": null,
1802
+ "description": "Downstream of deferred-item-exit: once an item has an exit, its carrier must stay trustworthy. Capture costs no more than two fields; a waiting item records its release condition; derivable fields are generated, not hand-written; a coverage figure states what it could not see; a checkpoint at turn end reports open work but never blocks"
1803
+ },
1792
1804
  {
1793
1805
  "id": "verification-evidence",
1794
1806
  "name": "Verification Evidence Standard",
@@ -2283,7 +2295,7 @@
2283
2295
  "id": "license-compliance",
2284
2296
  "name": "License Compliance Standards",
2285
2297
  "nameZh": "授權合規標準",
2286
- "version": "6.11.0",
2298
+ "version": "6.12.0",
2287
2299
  "source": {
2288
2300
  "human": "core/license-compliance.md",
2289
2301
  "ai": "ai/standards/license-compliance.ai.yaml"
@@ -2295,7 +2307,7 @@
2295
2307
  "id": "verification-oracle",
2296
2308
  "name": "Verification Oracle Standards",
2297
2309
  "nameZh": "驗證 Oracle 標準",
2298
- "version": "6.11.0",
2310
+ "version": "6.12.0",
2299
2311
  "source": {
2300
2312
  "human": "core/verification-oracle.md",
2301
2313
  "ai": "ai/standards/verification-oracle.ai.yaml"
@@ -2307,7 +2319,7 @@
2307
2319
  "id": "model-provenance",
2308
2320
  "name": "Model Provenance Policy Standards",
2309
2321
  "nameZh": "模型來源政策標準",
2310
- "version": "6.11.0",
2322
+ "version": "6.12.0",
2311
2323
  "source": {
2312
2324
  "human": "core/model-provenance.md",
2313
2325
  "ai": "ai/standards/model-provenance.ai.yaml"
@@ -2319,7 +2331,7 @@
2319
2331
  "id": "resource-cost-boundary",
2320
2332
  "name": "Resource / Cost Boundary Declaration Standards",
2321
2333
  "nameZh": "資源/成本邊界宣告標準",
2322
- "version": "6.11.0",
2334
+ "version": "6.12.0",
2323
2335
  "source": {
2324
2336
  "human": "core/resource-cost-boundary.md",
2325
2337
  "ai": "ai/standards/resource-cost-boundary.ai.yaml"