universal-dev-standards 6.8.0 → 6.9.0

package/bundled/core/deferred-item-exit.md

@@ -0,0 +1,254 @@
+# Deferred Item Exit Standard
+
+> **Language**: English | [繁體中文](../locales/zh-TW/core/deferred-item-exit.md)
+
+**Version**: 1.0.0
+**Last Updated**: 2026-08-24
+**Applicability**: Any document a standard requires, in which an item can be recorded as deferred
+**Scope**: universal
+
+---
+
+## Purpose
+
+Several standards require documents that **produce deferred items** — an ADR's accepted risks and "decide later" notes, a spec's out-of-scope list, a retrospective's action items, a discovery matrix's unconfirmed candidates, a review's non-blocking suggestions, an AC report's gaps. Each of those standards says how to write the document well. **None of them says where those items go afterwards.**
+
+So they go nowhere. The item is recorded, the document is approved, and the record is the end of the line. Nothing announces it again, because the only thing that held it was prose inside a file that is now considered finished.
+
+有一批標準會**產出延後項目**——ADR 的既受風險與「之後再決定」、規格的未納入清單、
+retrospective 的 action items、探索矩陣裡未確認的候選、review 的非阻斷建議、AC 報告的缺口。
+每一條標準都規定了那份文件要怎麼寫好，**沒有一條規定那些項目之後去哪**。
+
+於是它們哪裡也沒去。項目被記下、文件被核准，**那筆紀錄就是終點**。
+沒有東西會再提起它，因為承載它的只有一份已被視為完成的檔案裡的一段文字。
+
+**This standard states the missing relation: a deferred item must leave the document.**
+
+**本標準補上那個缺失的關係：延後項目必須離開文件。**
+
+---
+
+## How this standard is written — and why it is written that way
+
+**Read this section before reading any requirement below. It governs all of them.**
+
+UDS defines **activities**; adoption layers **orchestrate** them (DEC-049; see [MIGRATION-v6](../docs/MIGRATION-v6.md) §2). Eight machine-readable standards were removed in 6.0.0 under that decision, seven of them workflow-state protocols. A standard written as an orchestration protocol belongs in the adoption layer, not here.
+
+The distinction this standard is held to:
+
+| Admissible here — **what** | Not admissible here — **how** |
+|---|---|
+| A relation that must exist between named artefacts | A state machine the artefacts must pass through |
+| A property a claim must have before it counts as evidence | A pipeline stage that must produce that claim |
+| A distinction a report must preserve | A report format, tool, or schema |
+| That a deferred item must have an exit | Which issue tracker, board, or file is the exit |
+
+**Every requirement below is stated as "what relation must exist", never as "what mechanism must maintain it".** UDS already carries a class of standards of exactly this shape — [acceptance-criteria-traceability](acceptance-criteria-traceability.md) requires that each AC be reachable from a test, and does not say what maintains that reachability. This standard is the same shape applied to deferred items.
+
+**Consequence, stated plainly**: this standard ships **no gate**. It says what must be true. Whether anything checks it is the adopting project's decision — and [DEX-004](#requirements) is what stops that decision from being made silently.
+
+UDS 定義**活動**，採用層負責**編排**（DEC-049）。6.0.0 依該決策移除八條機器可讀標準，
+其中七條正是工作流狀態協定。**一份寫成編排協定的標準屬於採用層，不屬於這裡。**
+
+本標準受此拘束：**每一條要求都寫成「必須存在什麼關係」，絕不寫成「應使用什麼機制維持它」。**
+UDS 本來就有一整類這個形狀的標準——[acceptance-criteria-traceability](acceptance-criteria-traceability.md)
+要求每一條 AC 都能被某個測試到達，而不規定用什麼維持那條可達性。本標準是同一個形狀，套用在延後項目上。
+
+**直說它的後果**：本標準**不附帶任何閘門**。它只說什麼必須為真。
+有沒有東西在檢查，是採用專案的決定——而 [DEX-004](#requirements) 是用來讓那個決定沒辦法被默默做掉的。
+
+---
+
+## The invariant
+
+**A deferred item recorded in a document must have a traceable exit outside that document, and the exit's identifier must appear in the document beside the item.**
+
+**一個記錄在文件裡的延後項目，必須在該文件之外有一個可追蹤的出口，而該出口的識別字必須寫在文件裡、緊鄰該項目。**
+
+### What counts as a deferred item
+
+Any item the document records as **not being done now, by this document**. Wording varies without limit — "to be decided", "out of scope for v1", "separate effort", "not yet implemented", "revisit later", "accepted risk", "we will look at this again". **The wording is not the definition**; the definition is the item's status relative to the work the document closes. See [Anchors](#anchors-structure-not-wording).
+
+### What counts as an exit
+
+**Deliberately unspecified.** An issue, a tracked TODO, a manifest entry, a row in a backlog file, a ticket in whatever system the project already runs — all satisfy this. The test is **"has this item left the document?"**, not "which tool was used?".
+
+An exit satisfies the invariant when all three hold:
+
+| # | Relation | Fails when |
+|---|---|---|
+| 1 | The exit exists outside this document | The item's only record is this document's prose |
+| 2 | The exit is addressable by an identifier written in the document | The document says "we'll pick this up later" with nothing to address |
+| 3 | The exit still resolves **after** the change that produced the document lands | The exit is closed, deleted, or superseded by that same change |
+
+Relation 3 is not hypothetical. Two observed leaks, both of which satisfy relations 1 and 2 and still lose the item:
+
+- The item is written into an issue that the merge closes. The document points at a record that stops existing the moment the work is accepted.
+- The item is written into a comment on the exit rather than into the exit's own body, and subsequent comments push it out of view. The exit resolves; reading the exit does not surface the item.
+
+出口的載體**刻意不指定**：issue、tracked TODO、manifest 條目、backlog 檔案的一列，
+專案已經在跑的任何工單系統——都算。判準是**「這個項目離開文件了嗎」**，不是「用了什麼工具」。
+
+上表第 3 條不是假想。兩個實際觀察到的洩漏都同時滿足第 1、2 條而仍然遺失項目：
+待辦寫進**會被本次合併關閉的 issue**（文件指向一筆在工作被接受的當下就停止存在的紀錄）；
+待辦寫進出口的**留言而非本體**，被後續留言推走（出口解析得到，讀出口卻讀不到那個項目）。
+
+---
+
+## Requirements
+
+| ID | Requirement | Severity |
+|---|---|---|
+| **DEX-001** | A deferred item recorded in a document has a traceable exit outside that document, and the document carries that exit's identifier beside the item | error |
+| **DEX-002** | The exit still resolves, and still carries the item, after the change that produced the document lands | error |
+| **DEX-003** | 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 |
+| **DEX-004** | A check offered as evidence for any requirement here has been observed to report failure against a deliberately violating sample. A check never observed red is not admissible evidence | error |
+| **DEX-005** | Verification establishes that the named exit **carries this item** — not merely that the identifier resolves | error |
+| **DEX-006** | "Linked and content-verified" and "linked, content unverified" are reported as two distinct states. A report that merges them into one pass state does not satisfy DEX-005 | error |
+| **DEX-007** | The anchor for "a deferred item is present here" is a structural location enumerable from the document's own defined structure | error |
+| **DEX-008** | Where a wording list supplements the structural anchor, its coverage is declared unknown, and a green result over it is not reported as complete | warning |
+| **DEX-009** | Any window or threshold used in that determination carries its provenance, or is marked uncalibrated | warning |
+
+---
+
+## A requirement that cannot be checked is not a requirement here
+
+**DEX-003** is a constraint on this standard's own contents. Each requirement above names artefacts and a relation between them, so that a reader — or something the project builds — can decide whether it holds. **A requirement that cannot be decided does not belong here**, however true it sounds.
+
+The reason is measured, not aesthetic: the first large batch of documents written under a rule of this kind dropped **five of five** deferred items. The rule was understood and the people were competent. What was missing was anything that could tell the difference between a document that satisfied it and one that did not.
+
+**DEX-003 是對本標準自身內容的約束。** 上面每一條都指名了 artefact 與它們之間的關係，
+使得「它成不成立」可以被判定。**一條無法被判定的要求不屬於這裡**，不論它聽起來多正確。
+
+理由是量出來的，不是美學：在這一類規則之下第一次大批產出文件，**五項延後項目全部漏掉**。
+規則被理解了，人也稱職。缺的是任何一個能分辨「滿足它的文件」與「不滿足它的文件」的東西。
+
+### A check that has never been red
+
+**DEX-004** is about what counts as evidence, not about what to build. **A check that has never failed and a check that cannot fail produce identical output.** Until one has been observed reporting failure against a sample built to violate the rule, it is not evidence that the rule holds — it is evidence that something ran.
+
+For how to prove a check non-vacuous, and why it must be done per sub-set rather than in aggregate, see [class-level-fix](class-level-fix.md); for why "it exited 0" is not the same as "it worked", see [verification-evidence](verification-evidence.md). **Neither procedure is restated here.**
+
+**DEX-004 講的是什麼算證據，不是要你去建什麼。** 一支從未紅過的檢查，與一支不可能紅的檢查，
+輸出一模一樣。在它被觀察到「對一個刻意違規的樣本回報失敗」之前，它不是「規則成立」的證據，
+只是「有東西跑過」的證據。
+
+證明檢查非空跑的做法、以及為何必須逐子集而非整體進行，見 [class-level-fix](class-level-fix.md)；
+「exit 0」為何不等於「它在工作」，見 [verification-evidence](verification-evidence.md)。**兩者都不在此複述。**
+
+---
+
+## The link exists is not the link works
+
+An identifier written beside a deferred item creates the appearance of an exit. Whether the exit **carries** the item is a separate question, and the two answers are not interchangeable.
+
+The instance that names this rule: a document read "to be decided together with issue #19", and issue #19 contained nothing about it. Relations 1, 2 and 3 above all hold. The item is still gone. **A gate that asks whether an identifier is present passes this document**, and its green is bit-for-bit identical to the green it prints over a document whose exits are real.
+
+一個寫在延後項目旁邊的識別字，製造出「有出口」的外觀。那個出口**有沒有承載**這個項目，
+是另一個問題，而兩個答案不能互換。
+
+命名這條規則的實例：文件寫著「與 issue #19 一併決定」，而 #19 裡根本沒有這件事。
+上面第 1、2、3 條全部成立，項目照樣不見了。**一道只問識別字在不在的閘門會放行這份文件**，
+而它印出的綠燈，與它印在出口都為真的文件上的綠燈，逐位元相同。
+
+### Two states, never one
+
+Establishing DEX-005 requires reading the exit's contents, which is materially more expensive than reading the document. **DEX-005 does not require that this be done everywhere at once.** It requires that the difference be visible:
+
+| State | Meaning |
+|---|---|
+| **Linked, content verified** | The exit was read and it carries this item |
+| **Linked, content unverified** | An identifier is present; whether it carries the item is unknown |
+| **No exit** | DEX-001 violated |
+
+Reporting the first two as one pass state is not a shortcut toward the rule — it is the defect the rule exists to prevent, made permanent and given a number. **An unknown reported as a pass is worse than an unknown reported as unknown**, because the second one is still findable.
+
+**兩態不得合併。** 「有連結且已驗證內容」與「有連結但內容未驗證」不得印出同一個綠。
+把前兩態合併成單一通過數，不是通往規則的捷徑——那正是這條規則要防的缺陷，
+被制度化並給了一個編號。**一個被回報成通過的未知，比一個被回報成未知的未知更糟**，因為後者還找得到。
+
+If a project can only afford the cheaper half today, that is a coverage gap of the kind [verification-evidence](verification-evidence.md) VE-012 and [class-level-fix](class-level-fix.md) CLF-008 already govern: **it must be registered with a date, not merely disclosed in prose.** Not restated here.
+
+---
+
+## Anchors: structure, not wording
+
+To decide "is there a deferred item here", **walk the document's structure**. The structure is defined by the standard that required the document, so it is enumerable. **The wording is not enumerable, and no list of it can be shown to be complete.**
+
+| Document | Structural locations where deferred items arise |
+|---|---|
+| ADR | `Consequences` → **Bad** / **Accepted risk**; `Links`; options considered and not chosen |
+| Spec | out-of-scope / not-in-this-version section; open questions; assumptions awaiting confirmation |
+| Retrospective | `Action Items`; `Previous Action Items Review` rows still Open; items Cancelled with a reason |
+| Feature discovery | zero-checkmark candidates; `dead_code_candidates`; candidates escalated to human observation |
+| Code review | non-blocking comment classes (`⚠️ IMPORTANT`, `💡 SUGGESTION`, `[SUGGESTION]`, `[NIT]`) accepted without a change in this change |
+| AC coverage report | `Gaps` → **Uncovered AC** / **Partial AC**; `Threshold Exceptions`; `Action Items` |
+
+判定「這裡有沒有延後項目」時，**走訪文件的結構**。結構由「要求產出這份文件的那條標準」所定義，
+因此可窮舉。**措辭不可窮舉，而且沒有任何一張措辭清單能被證明是完整的。**
+
+### When a wording list is used anyway
+
+Legitimate — a structural walk catches the item in its section, not the one dropped into a paragraph of narrative. But then **DEX-008 applies**: the list's coverage is unknown, that must be stated, and its green must not be read as "no deferred items were missed". A list containing "to be decided" and "out of scope" says nothing at all about the sentence "we will leave this one alone for now".
+
+**A gate that enumerates its own scope is correct until the fourth member arrives** — [class-level-fix](class-level-fix.md) is the general form of this failure. A wording list is that failure by construction; it can be used, but not believed.
+
+### Thresholds carry their provenance
+
+**DEX-009.** A determination like "the identifier must appear within 3 lines of the item" sets the recall of everything built on it. If nothing records where "3" came from, nobody can evaluate changing it, and nobody can tell whether it was measured or guessed. **Write down where the number came from, or mark it uncalibrated.** Both are acceptable; silence is not.
+
+**一個沒有來歷的閾值，是一個沒有人能檢查的決定。** 寫下它的來歷，或標為未校準——兩者都可以接受，沉默不行。
+
+---
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails |
+|---|---|
+| Recording a deferred item and approving the document | The document is the only carrier, and it is now finished |
+| An exit closed by the same change that created the document | The pointer resolves during the work and stops resolving after it |
+| The item written into a comment on the exit, not into the exit | The exit resolves; reading it does not surface the item |
+| Checking that an identifier is present | Present and correct print the same green |
+| One pass state covering verified and unverified links | Makes the previous row permanent and gives it a number |
+| A wording list treated as the definition of "deferred" | Correct until someone writes it a different way, and nothing says so |
+| A window size with no recorded provenance | Sets the recall of the whole determination; unreviewable |
+| A check that has never been observed failing | Indistinguishable from a check that cannot fail |
+
+---
+
+## What enforces this standard
+
+**Nothing in UDS does, and that is recorded rather than implied.** UDS states the relation; whether anything decides it is the adopting project's call, per the [writing constraint](#how-this-standard-is-written--and-why-it-is-written-that-way) above.
+
+What this standard does do is make that call visible: DEX-003 guarantees every requirement here **can** be decided, DEX-004 fixes what it takes for a decision to count, and DEX-006/DEX-008 fix what a partial decision is allowed to print. A project that adopts this standard and builds nothing has not violated it — but it also cannot claim its deferred items have exits, because it has no admissible evidence that any do.
+
+**Reopen condition**: were UDS ever to ship the documents themselves rather than the standards for them, a walk over the structural locations in [Anchors](#anchors-structure-not-wording) becomes possible in this repository, and the honest thing would be to run it.
+
+**本標準沒有任何 UDS 側的閘門，而這件事是被記錄的，不是被暗示的。** UDS 陳述關係；
+有沒有東西去判定它，依上面的寫法約束，是採用專案的決定。
+
+本標準做的事，是讓那個決定顯形：DEX-003 保證這裡每一條**能**被判定，DEX-004 固定「一次判定要算數需要什麼」，
+DEX-006／DEX-008 固定「一次不完整的判定容許印出什麼」。一個採用本標準而什麼都沒建的專案並未違反它——
+但它同樣不能宣稱自己的延後項目有出口，因為它沒有任何可採信的證據說明有。
+
+---
+
+## Standards that produce deferred items
+
+Each of these points here; **none of them restates the rule**, because six copies of one rule rot in six directions.
+
+- [adr-standards](adr-standards.md) — accepted risks, negative consequences, options not taken up
+- [spec-driven-development](spec-driven-development.md) — out-of-scope items, open questions, assumptions awaiting confirmation
+- [retrospective-standards](retrospective-standards.md) — action items, and previous ones still Open
+- [feature-discovery-standards](feature-discovery-standards.md) — unconfirmed candidates and `dead_code_candidates`
+- [code-review-checklist](code-review-checklist.md) — non-blocking comments accepted without a change
+- [acceptance-criteria-traceability](acceptance-criteria-traceability.md) — coverage gaps, threshold exceptions, report action items
+
+---
+
+## Relationship to other standards
+
+- [acceptance-criteria-traceability](acceptance-criteria-traceability.md) — the same shape one layer up: it requires that every AC be reachable from a verification item and leaves the mechanism open. This standard requires that every deferred item be reachable from an exit.
+- [class-level-fix](class-level-fix.md) — supplies the procedure DEX-004 requires evidence of, and the general form of the wording-list failure DEX-008 discloses.
+- [verification-evidence](verification-evidence.md) — VE-012's dated exception inventory is what a DEX-006 "unverified" population must be registered in, rather than disclosed once and left.
+- [self-review-protocol](self-review-protocol.md) — a self-review catches contradictions; a deferred item with no exit is an omission, which is the case self-review is known not to catch.

package/bundled/core/feature-discovery-standards.md

@@ -1,6 +1,6 @@
 # Feature Discovery Standards
 
-> **Version**: 1.0.0 | **Status**: Active | **Updated**: 2026-05-13
+> **Version**: 1.1.0 | **Status**: Active | **Updated**: 2026-08-24
 > **AI-optimized version**: `ai/standards/feature-discovery-standards.ai.yaml`
 > **Spec**: XSPEC-202 (cross-project/specs/XSPEC-202-feature-discovery-standards.md); related: XSPEC-199/200/201 (migration completeness protocol suite)
 
@@ -173,8 +173,11 @@ confidence value from this matrix becomes the manifest's `confidence` field.
 | `matrix-before-manifest` | Generating `feature-manifest.yaml` | Complete the cross-layer validation matrix first; only ≥1-checkmark items become `FM-NNN` entries; zero-checkmark items go to a separate `dead_code_candidates` list | required |
 | `dead-code-handling` | Call graph analysis reveals unreachable code | Never silently exclude unreachable functions; list as `dead_code_candidates`; account for dynamic dispatch; require human confirmation before classifying as dead code | required |
 
+> **Deferred items** this standard produces — zero-checkmark candidates, `dead_code_candidates`, and candidates escalated to human observation — are governed by [deferred-item-exit](deferred-item-exit.md). | 本標準產出的**延後項目**（零打勾候選、`dead_code_candidates`、升級為人工觀察的候選）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ## Related Standards
 
+- `deferred-item-exit` — the exit every unconfirmed candidate needs before this document is closed
 - `feature-manifest-standard` — represents confirmed candidates as `FM-NNN` entries
 - `behavior-snapshot` — verifies the manifest against observed runtime behavior
 - `reverse-engineering-standards` — broader legacy reverse-engineering process this
@@ -189,3 +192,4 @@ confidence value from this matrix becomes the manifest's `confidence` field.
 | Version | Date | Changes |
 |---------|------|---------|
 | v1.0.0 | 2026-05-13 | Initial — Deterministic-First principle, Software Form Taxonomy (7 forms), five static foundations, dynamic/human observation protocols, cross-layer validation matrix (XSPEC-202) |
+| v1.1.0 | 2026-08-24 | Pointer to `deferred-item-exit` for zero-checkmark candidates, `dead_code_candidates` and human-observation escalations (XSPEC-391 R5) |

package/bundled/core/governance-layer.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/governance-layer.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-05-07
+**Version**: 1.1.0
+**Last Updated**: 2026-08-20
 **Applicability**: All software projects with multi-agent or multi-role AI workflows
 **Scope**: universal
 **Industry Standards**: None (UDS original)
@@ -122,9 +122,79 @@ If a project relaxes human gates (e.g., `gate.mode = trace_only`), a **Risk Acce
 | `signatory` | Person or role accepting the risk |
 | `gates_bypassed` | Enumerated list of human gates that are bypassed |
 | `risks_accepted` | Explicit description of accepted risks |
+| `review_by` | Date on which this acceptance stops being valid and must be decided again |
 
 Without a valid Risk Acceptance Clause, the pipeline **must refuse to start (fail-closed)**.
 
+### Acceptance expiry
+
+A clause whose `review_by` has passed is **not valid**. The pipeline fails closed exactly as if no clause were present.
+
+`date` records when the risk was accepted; it does not record when the acceptance should be re-examined. Without `review_by`, an acceptance signed once stays in force forever — the conditions that justified it can change, and the signatory may no longer be on the project, while every field in the clause still reads as correct.
+
+On expiry, exactly one of three dispositions applies — the same three defined in [Tech Debt Standards → Overdue Handling](tech-debt-standards.md#overdue-handling):
+
+| Disposition | Meaning |
+|-------------|---------|
+| **Re-accept** | A current signatory signs again, with a new `review_by` |
+| **Withdraw** | The bypass is removed and the human gates are restored |
+| **Extend** | A new `review_by` **and** a written reason, recorded together |
+
+**Automatic extension of `review_by` is prohibited.** It converts a fail-closed gate into a fail-open one while leaving every field looking correct — the failure is invisible precisely because the clause still validates.
+
+---
+
+## Pending Decisions
+
+"Undecided" is a governance state, not the absence of one. An open question in a spec, a red line proposed but not ratified, a KPI with no owner — each is a decision someone is expected to make, and each is invisible to every check that only reads decisions already made.
+
+Pending decisions are governed **at the same level as accepted risks**: they carry a clock, and they must be enumerable.
+
+**Rule GOV-PD-001 (Required)** — The project MUST declare **where** pending decisions are recorded and **what marks one**: a fixed token (a status value, a label, a literal marker string), never free prose. Enumeration must not depend on a reader guessing which words were used. Three documents that say "TBD", "pending sign-off", and "to be confirmed" are three unenumerable documents; one declared marker makes all three findable.
+
+**Rule GOV-PD-002 (Required)** — Enumerating pending decisions MUST report a total **and** the number of sources that could not be parsed (see [Aggregate Reporting](#aggregate-reporting)). "No pending decisions found" carries no information without the size of the set that was walked.
+
+**Rule GOV-PD-003 (Required)** — Every pending decision carries a **decide-by date**. On expiry the same three dispositions apply as for an overdue debt item — **decide**, **withdraw the question**, or **extend with a written reason**. Automatic extension is prohibited.
+
+**Rule GOV-PD-004 (Required)** — If nothing enumerates pending decisions on a schedule, the project MUST carry an **Unattended Declaration** naming an owner, a review cadence, and the date of the last review — the same two-state rule the tech debt registry is held to. Unenumerated is acceptable; unenumerated and undeclared is not.
+
+> A decision left pending with no date behaves identically to a decision to do nothing. The only difference is that the pending form leaves people believing someone is still going to look at it.
+
+---
+
+## Aggregate Reporting
+
+Every governance report — compliance summary, gate report, KPI rollup, red-line scan — is a claim about a set. The claim is worth exactly as much as the report's account of what it could **not** evaluate.
+
+**Rule GOV-RPT-001 (Required)** — A report MUST print three counts, never two: **passed**, **failed**, and **undecidable** — items it could not evaluate at all (unparseable file, missing field, unreachable source, unsupported format).
+
+**Rule GOV-RPT-002 (Required)** — `undecidable` MUST NOT be folded into `passed`, and MUST NOT be omitted. An unparseable file is not a clean file. A report that prints only "N checks passed" is non-compliant regardless of N.
+
+**Rule GOV-RPT-003 (Required)** — A report MUST state its **denominator** and how it derived it. A report whose scope comes from a hardcoded list is a report about that list, not about the project: it stays green while everything outside the list rots. Derive the set by walking the project and excluding, never by enumerating — see [Class-Level Fix](class-level-fix.md).
+
+**Rule GOV-RPT-004 (Required)** — Report positive and negative counts separately; never collapse them into a single compliance score. **A metric on which doing nothing scores the same as doing the work is not measuring the work.** "5 of 11 checks passed" and "the checker never started" produce the same figure, and a single score cannot tell them apart.
+
+**Rule GOV-RPT-005 (Recommended)** — Where a report depends on its own tooling being functional, include a canary: a check with a known-failing input that MUST fail. If the canary passes, the report is not trustworthy and must be reported as wholly undecidable rather than as green.
+
+---
+
+## Freshness Metrics
+
+**Rule GOV-FRESH-001 (Required)** — Any freshness or staleness indicator MUST name which of two clocks it reads:
+
+| Clock | Answers | Can be read from |
+|-------|---------|------------------|
+| **Edit time** | How long since this artifact was last changed? | File mtime, last commit touching the file, a "last updated" field |
+| **Reconciliation time** | How long since this artifact was last compared against the source of truth it claims to describe? | The recorded date of that comparison — nothing else can supply it |
+
+**Rule GOV-FRESH-002 (Required)** — The two MUST NOT share a field or a column heading. They answer different questions, and an artifact can be maximally fresh on one and arbitrarily stale on the other: a document edited today whose contents were never checked against reality is zero days old by edit time and unbounded by reconciliation time.
+
+**Rule GOV-FRESH-003 (Required)** — Where only edit time is available, the report MUST label the column as edit time **and** report reconciliation age as `undecidable` (GOV-RPT-001) — never as fresh, and never by leaving it out.
+
+**Rule GOV-FRESH-004 (Recommended)** — Reconciliation time is only meaningful if the comparison is recorded by whatever performed it. A date a human types in after the fact is an assertion, not a measurement; label it as such.
+
+> This is the single-axis-overload failure: one field, read by two different questions. The field can never be caught being wrong, because it was never asked which question it was answering.
+
 ---
 
 ## Governance File Structure
@@ -148,4 +218,46 @@ governance/
 - [ ] Goals table is present with all KPIs containing: id, metric_name, threshold, measurement_method
 - [ ] No KPI uses vague language ("improve", "enhance", "better")
 - [ ] If `gate.mode = trace_only`, a Risk Acceptance Clause is present in `mission.md`
+- [ ] Every Risk Acceptance Clause has a `review_by` date, and no clause is past it
+- [ ] The project declares where pending decisions live and what fixed token marks one
+- [ ] Every pending decision has a decide-by date
+- [ ] Pending decisions are either enumerated by something that runs, or covered by an Unattended Declaration
+- [ ] Every governance report prints passed / failed / **undecidable** separately, and states its denominator and how it was derived
+- [ ] No report collapses positive and negative counts into one score
+- [ ] Every freshness indicator names whether it reads edit time or reconciliation time, and the two do not share a field
 - [ ] All AI evaluators weight correctness/mission_alignment/goal_achievement with fail-closed veto at < 0.3
+
+---
+
+## Enforcement Reality
+
+> **This standard ships no checker for any of its rules — not the ones added in 1.1.0, and not the fail-closed Risk Acceptance requirement that has been in it since 1.0.0. That is a known cost, stated here rather than left to be discovered.**
+>
+> Measured 2026-08-20: `review_by`, `risks_accepted`, and `gates_bypassed` appear in **no** program — not in the UDS CLI, not in any consumer. The clause that says a pipeline "must refuse to start" has never caused a pipeline to refuse to start, in the three and a half months it has been written down. Saying that plainly is not a caveat bolted onto this section; it is the section's own rule applied to the section itself, and an earlier draft of this text listed only the new rules as unenforced — which would have implied the older one was enforced.
+>
+> UDS defines these requirements; it does not provide a program that enforces them. Adopters who want them enforced must write the enumerator, the three-count reporter, and the reconciliation-date recorder themselves — and most will not. That is the same failure this standard describes, now applying to this standard.
+>
+> The minimum bar is therefore **not** "build the tooling". It is: **anything recorded as pending, accepted, or fresh must either point at something that runs, or say plainly that nothing is watching it.** Declaring `Unattended` is compliant. Being unattended without declaring it is the one outcome these rules forbid, because it is the only one that misleads the reader about whether anything is watching.
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.1.0 | 2026-08-20 | Added: `review_by` to the Risk Acceptance Clause + acceptance-expiry dispositions and prohibition on automatic extension; Pending Decisions (GOV-PD-001..004); Aggregate Reporting (GOV-RPT-001..005 — passed/failed/undecidable, denominator derivation, no collapsed score, canary); Freshness Metrics (GOV-FRESH-001..004 — edit time vs reconciliation time must not share a field); Enforcement Reality note; compliance checklist extended |
+| 1.0.0 | 2026-05-07 | Initial release: Vision/Mission/Goals three-layer schema, red lines format, evaluator integration, Risk Acceptance clause, compliance checklist |
+
+---
+
+## Related Standards
+
+- [Tech Debt Standards](tech-debt-standards.md) — Overdue Handling defines the three dispositions this standard reuses for expiry
+- [Class-Level Fix](class-level-fix.md) — Deriving a set by walking and excluding rather than enumerating (GOV-RPT-003)
+- [Verification Evidence](verification-evidence.md) — Why a green result must be shown to come from a working check (GOV-RPT-005)
+
+---
+
+## License
+
+This standard is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

package/bundled/core/retrospective-standards.md

@@ -2,8 +2,8 @@
 
 > **Language**: English | [繁體中文](../locales/zh-TW/core/retrospective-standards.md)
 
-**Version**: 1.0.0
-**Last Updated**: 2026-03-26
+**Version**: 1.1.0
+**Last Updated**: 2026-08-24
 **Applicability**: All software teams practicing iterative development
 **Scope**: universal
 **Industry Standards**: Scrum Guide (Sprint Retrospective), CMMI Level 3, ISO/IEC 12207 §6.3.6
@@ -199,6 +199,8 @@ Open ──► In Progress ──► Done
   └──► Cancelled (with reason)
 ```
 
+> **Deferred items** a retrospective records — `Action Items`, `Previous Action Items Review` rows still Open, and items Cancelled with a reason — are governed by [deferred-item-exit](deferred-item-exit.md). | Retrospective 記下的**延後項目**（`Action Items`、`Previous Action Items Review` 中仍為 Open 的列、附理由 Cancelled 的項目）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ### Tracking Rules
 
 1. Review all open action items at the **start** of each retrospective.

package/bundled/core/reverse-engineering-standards.md

@@ -1,7 +1,7 @@
 # Reverse Engineering Standards | 反向工程標準
 
-**Version**: 1.2.0
-**Last Updated**: 2026-06-27
+**Version**: 1.3.0
+**Last Updated**: 2026-08-20
 **Applicability**: All projects requiring code-to-specification transformation
 **Scope**: uds-specific
 **Industry Standards**: IEEE 830-1998, SWEBOK v4.0 Chapter 9
@@ -52,10 +52,13 @@ This standard defines the principles, workflows, and best practices for reverse
 | **Code Scanning** | Analyze code structure, APIs, data models | Technical inventory | [Confirmed] |
 | **Test Analysis** | Parse existing tests for acceptance criteria | Draft acceptance criteria | [Confirmed]/[Inferred] |
 | **Implicit Rule Scan** | Scan non-HTTP persistence write paths for undocumented rules | Implicit-rule inventory + three-question answers | [Confirmed]/[Inferred]/[Unknown] |
+| **Auth Scope Extraction** | Extract every query predicate that bounds results by the operator's own identity | Self-scoping predicate inventory + required negative tests | [Confirmed]/[Inferred]/[Unknown] |
 | **Gap Identification** | List unknowns requiring human input | Gap analysis document | [Unknown] items |
 | **Spec Generation** | Generate draft specification | Draft SPEC-XXX.md | Mixed certainty |
 | **Human Review** | Stakeholder validation and gap filling | Validated specification | [Confirmed] |
 
+> **Note (v1.3.0)**: An **Auth Scope Extraction** stage runs alongside Implicit Rule Scan — see [Auth Scope Extraction (Self-Referential Query Predicates)](#auth-scope-extraction-self-referential-query-predicates) below. Implicit Rule Scan covers rules that are invisible because they run **off** the request path. This stage covers a rule that is invisible while sitting **on** a fully-exercised request path: a `WHERE` predicate that bounds results by the operator's own identity. It reads as one filter among several, and a rewrite that drops it returns data of exactly the right shape — belonging to everyone.
+>
 > **Note (v1.2.0)**: An **Implicit Rule Scan** stage is inserted after Code Scanning / Test Analysis and before Gap Identification — see [Implicit Rule Scan (Non-HTTP Persistence Rules)](#implicit-rule-scan-non-http-persistence-rules) below. Standard code scanning extracts HTTP entry points and data models, but persistent field values are frequently written by **non-HTTP paths** (cron, queue, computed columns, triggers, ORM hooks) whose business rules are never documented — the highest-frequency source of missed logic in a cross-language rewrite or cross-DB migration.
 
 ---
@@ -99,6 +102,80 @@ When scanning PHP write paths, additionally flag **loose-comparison / type-juggl
 
 ---
 
+## Auth Scope Extraction (Self-Referential Query Predicates)
+
+> **Workflow position**: alongside Implicit Rule Scan — after Code Scanning / Test Analysis, before Gap Identification.
+
+A **self-referential predicate** is a query condition that bounds the result set by *who is asking*: `WHERE tenant_id = :current_user_tenant`, `WHERE owner = :uid`, `WHERE dept_id = (SELECT dept_id FROM member WHERE account = :uid)`. It is the line that turns "list the accounts" into "list **your** accounts".
+
+The question this stage answers is narrow and mechanical:
+
+> **For every predicate in the legacy code that bounds results by the operator's own identity, does the ported code have an equivalent predicate?**
+
+Not "does it return the same shape". Not "does it return data". An **equivalent predicate**: the same field, bound to the same notion of *self*.
+
+### Why this needs its own stage
+
+Authorization is not a missing concern — any competent test taxonomy already names cross-tenant access as something to test. The concern does not go missing; **it goes un-recalled**. Three properties make this specific defect survive every gate that would normally catch it:
+
+1. **The security-critical line looks like a filter.** The boundary lives inside a `WHERE` clause, not in the request or response contract. Someone porting "get all accounts" sees a `SELECT` and a `JOIN`; the tenant predicate reads as one more condition among several.
+2. **Shape-based assertions cannot see scope.** A test that calls the endpoint as some valid administrator and asserts `200` plus a non-empty list passes **identically** whether the scoping is correct or deleted outright. Contract tests, parity snapshots and response-DTO comparisons are all blind here by construction: the response is well-formed either way. It just belongs to everybody.
+3. **A shared resolver existing is not the same as this call site using it.** Codebases that have already been burned once typically grow a shared scope-resolver utility. A new or overlooked call site can reimplement the query from scratch and never call it — and the presence of the utility elsewhere is then actively misleading, because it reads as coverage.
+
+### Derive (mechanical list source)
+
+Enumerate candidate predicates by scanning the legacy data-access layer — do not work from recall. Adapt the patterns to the stack; the target is any condition whose right-hand side resolves to **the caller's own value**:
+
+| Signal | Examples |
+|--------|----------|
+| **Direct self-binding** | `WHERE <col> = :currentUser` / `:uid` / `$operatorId` / `session.user_id` |
+| **Tenant / org / owner columns** | `tenant_id`, `org_id`, `master_account`, `owner_id`, `dept_id`, `company_id` compared against a caller-derived value |
+| **Subquery resolving the caller's scope** | `WHERE dept_id = (SELECT dept_id FROM member WHERE account = :uid)` |
+| **Role-branched query construction** | Branches on `role` / `account_type` where **each branch** applies a different scope — enumerate every branch, not just the one exercised by the happy path |
+| **Scope applied outside SQL** | ORM global scopes, query-builder mixins, repository base classes, row-level-security policies, middleware that injects a filter |
+
+The last row matters: a predicate can be enforced by something the `SELECT` statement never mentions. A grep over SQL alone will report a **smaller** set than exists, and a smaller set here reads exactly like a safer one.
+
+### Record (per match)
+
+For every candidate, record — `[Confirmed]` requires a `file:line` citation:
+
+| Field | Content |
+|-------|---------|
+| **Location** | `file:line` in the legacy source |
+| **Predicate** | The exact condition text |
+| **Self-binding** | Which caller-derived value it resolves to, and how that value is obtained |
+| **Triggering branch** | Which role / parameter / code path reaches this predicate |
+| **Certainty** | `[Confirmed]` / `[Inferred]` / `[Unknown]` |
+
+Every `[Unknown]` — a scope you cannot determine from the code — goes to Gap Identification for a human. It is never guessed, and never assumed absent.
+
+### Oracle (detect) — predicate equivalence, per call site
+
+For each recorded predicate, verify in the ported code:
+
+1. **A literal equivalent exists** — the same field, bound to the same notion of self. A different field that "happens to give the same rows for current data" is not equivalent; it is a coincidence with an expiry date.
+2. **Every branch is covered.** If the legacy scoped differently per role, each branch needs its own verified equivalent. A port that collapses five role-branches into one coarse "is this an administrator?" check has replaced a boundary with a permission.
+3. **This call site invokes the shared resolver.** If the new system centralises scoping in a utility, confirm **this** call site actually calls it. The utility's existence elsewhere in the codebase is not evidence about this endpoint.
+
+### Mandatory negative test
+
+**Rule RE-AUTH-001 (Required)** — Every confirmed self-scoping predicate MUST be locked by a **negative test**: operator **A** issues the request, and the assertion is that operator **B**'s records are **absent** from the response. Both A and B are valid, authenticated, and authorized to use the endpoint.
+
+The assertion must be about **absence**. A test asserting `200`, or a non-empty list, or a matching response schema, is not sufficient evidence and MUST NOT be counted as coverage for this predicate — each of those passes with the scoping clause deleted.
+
+A useful self-check before trusting the test: **delete the scoping predicate in a scratch copy and re-run.** If the test still passes, it is not testing scope, whatever its name says.
+
+### Gate timing
+
+Pre-flight (planning) for extraction; pre-UAT for the negative tests.
+
+**Rule RE-AUTH-002 (Required)** — Any self-scoping predicate whose ported equivalent is unverified, or which has no negative test, is marked `not_implemented` and **blocks cutover**. An unverified authorization boundary is a known omission risk, not an acceptable gap — the failure mode is cross-tenant disclosure, and it ships green.
+
+> **Provenance.** This stage was derived from a real PHP → C# migration in which a tenant-scoped account-listing endpoint lost its isolation predicate during the rewrite. The port replaced per-role scoping with a coarse "is this account any enabled administrator?" check and returned every account in the database regardless of which tenant asked. It shipped, it passed every existing test — the method had none — and it was found when a customer reported seeing account information that should not have been there.
+
+---
+
 ## Core Principles
 
 ### 1. Certainty Framework
@@ -438,6 +515,7 @@ present a sub-threshold-confidence spec as authoritative.
 - [Test-Driven Development](test-driven-development.md) - Red-Green-Refactor cycle
 - [Acceptance Test-Driven Development](acceptance-test-driven-development.md) - Acceptance criteria
 - [Code Review Checklist](code-review-checklist.md) - Review guidelines
+- [Test Completeness Dimensions](test-completeness-dimensions.md) - Dimension 4 (Authorization) names the cross-tenant test; Auth Scope Extraction is the discovery step that determines which ones you need
 
 ---
 
@@ -445,6 +523,7 @@ present a sub-threshold-confidence spec as authoritative.
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 1.3.0 | 2026-08-20 | Added: Auth Scope Extraction stage (self-referential query predicates) — derive signals incl. non-SQL scope enforcement, per-match record with `file:line`, predicate-equivalence oracle covering every role branch and per-call-site resolver use, rule RE-AUTH-001 (mandatory negative test asserting the ABSENCE of another operator's records) and RE-AUTH-002 (unverified predicate blocks cutover) (issue [#166](https://github.com/AsiaOstrich/universal-dev-standards/issues/166)) |
 | 1.2.0 | 2026-06-27 | Added: Implicit Rule Scan stage (non-HTTP persistence write-path extraction) — 4 derive categories + three-question oracle + non-HTTP Devil's Advocate + PHP type-juggling note + certainty/`file:line` (XSPEC-284 R4/AC-8) |
 | 1.1.0 | 2026-06-18 | Added: Failure Handling & Escalation section — parse failure / high-unknown-ratio / contradicted-inference escalation + rule RE-FAIL-001 (XSPEC-292 T7) |
 | 1.0.0 | 2026-01-19 | Initial release |

package/bundled/core/spec-driven-development.md

@@ -1,7 +1,7 @@
 # Spec-Driven Development (SDD) Standards
 
-**Version**: 2.4.0
-**Last Updated**: 2026-08-17
+**Version**: 2.5.0
+**Last Updated**: 2026-08-24
 **Applicability**: All projects adopting Spec-Driven Development
 **Scope**: universal
 **Industry Standards**: None (Emerging 2025+ methodology)
@@ -36,6 +36,8 @@ SDD operates at different maturity levels: Spec-first (discard after completion)
 | **AC YAML Sidecar** | Recommended .ac.yaml for machine-readable AC (when >3 ACs) |
 | **AI Agent Behavior** | Optional section defining agent roles, rules, quality checks, constraints |
 
+> **Deferred items** a spec records — out-of-scope / not-in-this-version entries, open questions, and assumptions still awaiting confirmation — are governed by [deferred-item-exit](deferred-item-exit.md). | 規格記下的**延後項目**（未納入／不在本版的條目、open questions、仍待確認的 assumptions）適用 [deferred-item-exit](deferred-item-exit.md)。
+
 ## Acceptance Criteria Formats | AC 格式
 
 UDS supports two AC notations. **GWT is the default and preferred** (Forward Derivation / BDD scenario generation depends on it). **EARS** (Easy Approach to Requirements Syntax, IBM Rational) is an optional supplement that expresses event/state/ubiquitous/unwanted requirements more precisely.
@@ -101,6 +103,10 @@ falsify it.
 - [class-level-fix](class-level-fix.md) — the same discipline applied to *scope*: traverse the
   set rather than enumerate it.
 
+## What's New in v2.5.0
+
+- **Pointer to [deferred-item-exit](deferred-item-exit.md)** (XSPEC-391 R5). A spec's out-of-scope entries, open questions and unconfirmed assumptions are deferred items, and the invariant they must satisfy is stated once, there. **A pointer, not a summary** — six copies of one rule rot in six directions.
+
 ## What's New in v2.4.0
 
 - **An AC with no verification item is not an AC** (XSPEC-380 R5). Every acceptance criterion must have a verification item pointing at it; one that has none is demoted to a design intent rather than carried as an AC. Measured instance: a spec's `AC-7` had no matching Test Plan item, and the thing it protected stopped running **on the day the AC was written** — found three months later by accident. An AC is a claim about the world, and only something that touches the world can falsify it.