驗證義務膨脹與 Completion Drift v0.2

——當 Review、Validation 與風險想像持續重寫「完成」的邊界

English Title: Verification-Obligation Expansion and Completion Drift: When Review Continuously Rewrites the Boundary of Done
系列：《綠燈錯置：AI 操作意圖不對齊與完成失真》05 / 08
作者： Neo.K × AI 協作
版本： v0.2
日期： 2026-09-16
文件性質： AI 工程／Agent 工作流／Requirements Engineering／Code Review／Scope Governance／Completion Semantics
承接： A01〈綠燈錯置〉、A02〈表觀成功與實質完成的分離〉、A03〈局部正確與全域失敗〉、A04〈流程代理錯置〉
後續接口： A06〈生成—治理缺口〉、A08〈同質綠燈〉、Global-First Completion / Completion Supervisor

機構： EveMissLab／一言諾科技有限公司

摘要

Review、verification、validation、red-team 與 adversarial testing 的目的，是揭露錯誤、補足證據與降低風險。然而，在高能力 AI Agent 工作流中，這些機制還可能產生另一種較少被明確建模的失敗：每一輪 review 都能找到新的可能改善點、hypothetical risk、hardening idea、architecture alternative 或 edge case；若工作流將所有新 finding 自動升格成完成前的 mandatory obligation，則「完成」的邊界會持續向外移動。

本文提出驗證義務膨脹（Verification-Obligation Expansion）與Completion Drift（完成漂移）。令初始授權任務的必要義務集合為：

\mathcal O_0.

在時間 $t$ ，review / validation 產生新 finding 集合：

\mathcal F_t.

若工作流不經 scope relevance、material evidence、risk、authority 與 intent 判定，就直接執行：

\mathcal O_{t+1} = \mathcal O_t \cup \mathcal F_t,

則 obligation frontier 可以隨 review 次數單調擴張，即使原始使用者目標沒有改變：

Intent_{t+1}=Intent_t.

當：

|\mathcal O_{t+1}| > |\mathcal O_t|

主要來自 reviewer-generated possibilities，而不是原始 scope、真實 defect、新外部條件或經授權的需求變更，本文稱之為：

\boxed{ \text{Completion Drift}. }

這不是反對 requirements change。既有 requirements engineering 研究清楚指出，需求變更往往不可避免，且 requirements volatility 與 rework、schedule overrun、cost overrun、functional-size growth 與 architecture impact 有關。成熟工程系統必須允許合法 scope evolution。本文真正區分的是：

\boxed{ \text{Authorized Requirement Change} \neq \text{Reviewer-Induced Completion Drift}. }

前者改變 canonical target；後者則是在 canonical target 未改變時，讓 verifier、reviewer、subagent 或安全流程偷偷取得產品 scope authority。

本文提出一套 obligation promotion model。任一新 finding $f$ 若要升格成 blocking obligation，至少應滿足：

\boxed{ Blocking(f) = InScope(f) \land Material(f) \land EvidenceSupported(f) \land RequiredInvariantViolation(f). }

若 finding 屬於新產品能力、optional hardening、future-proofing、low-impact polish、runtime-only validation 或純 hypothetical concern，則應分流成：

NONBLOCKING, \quad DEFERRED, \quad NEW\_TASK, \quad OUT\_OF\_SCOPE,

而不是自動阻止當前完成。

本文進一步建立 Completion Frontier、Obligation Generation Rate、Closure Rate、Review-Loop Depth、Scope Authority、Bounded Reopening、Marginal Review Yield 與 Completion Certificate 等概念，並將作者既有 Implicit Superpowers、Global-First Completion 與 Completion Supervisor 中的 review-loop closure 原則形式化。

核心主張為：

\boxed{ \text{A reviewer may discover obligations. It does not automatically own the authority to create them.} }

中文即：

Reviewer 可以發現問題，但不能因為它能想到問題，就自動取得重新定義產品完成條件的權力。

1. 問題：為什麼一個接近完成的任務可以永遠完成不了？

考慮以下 Agent workflow：

Implement
→ Review
→ Fix
→ Review
→ New concern
→ Fix
→ Review
→ New hardening idea
→ Fix
→ Security review
→ New hypothetical risk
→ Fix
→ Architecture review
→ Better future-proof design
→ Refactor
→ Review
→ ...

每一個 review finding 都可能「有道理」。

甚至每一輪修改都可能真的改善產品。

但如果原始任務只是：

把功能 A 做到目前 release acceptance boundary。

那麼問題就來了：

誰決定 review 新想到的每一件事，都屬於這一次完成的必要條件？

如果答案是：

reviewer 想到了，所以就是 blocker，

則：

\boxed{ \text{Reviewer} \rightarrow \text{ScopeOwner}. }

這是角色越權。

2. Review Finding 與 Requirement 不是同一種物件

令：

f

是一個 review finding。

它可以表示：

已存在的 bug；
specification violation；
performance risk；
security issue；
maintainability concern；
style concern；
optional refactor；
feature suggestion；
future-proofing idea；
hypothetical edge case；
different architecture preference。

但：

\boxed{ \text{Finding} \neq \text{Requirement}. }

Requirement 需要來自一個有 authority 的來源，例如：

original user intent；
accepted specification；
contract；
policy；
law / compliance；
explicit product decision；
authorized change request；
required invariant。

Review 的主要功能是：

\boxed{ \text{discover evidence about the product}. }

不是：

\boxed{ \text{unilaterally redefine the product}. }

3. Canonical Scope

令初始任務 canonical scope 為：

S_0.

其必要目標為：

G_0.

必要 constraints：

K_0.

必要完成義務：

\mathcal O_0.

則：

\boxed{ C_0 = (S_0,G_0,K_0,\mathcal O_0) }

可視為該次工作的 Completion Contract。

這不意味它永遠不可修改。

而是任何重大修改都需要：

\boxed{ \text{Change Event} + \text{Authority} + \text{Updated Canonical State}. }

不能只因 review 文字出現，就默默修改：

C_0.

4. Completion Frontier

令時間 $t$ 尚未閉合的 mandatory obligations 為：

\mathcal O_t^{open}.

本文定義：

\boxed{ F_C(t) = \mathcal O_t^{open} }

為：

Completion Frontier

如果：

|F_C(t)|\rightarrow0,

表示任務向完成收斂。

但如果每當：

|F_C(t)|

下降，

review 又加入新的 mandatory obligations：

\Delta^+\mathcal O_t,

則：

|F_C(t+1)| = |F_C(t)| - R_t + G_t,

其中：

$R_t$ ：本輪 resolved obligations；
$G_t$ ：本輪新增 mandatory obligations。

若長期：

G_t\ge R_t,

則：

\boxed{ F_C(t)\not\rightarrow\varnothing. }

任務理論上就可以永遠不完成。

5. Obligation Generation Rate 與 Closure Rate

定義：

\lambda_O = \frac{ \text{new mandatory obligations} }{ \text{unit review / time} }.

定義 closure rate：

\mu_C = \frac{ \text{resolved mandatory obligations} }{ \text{unit review / time} }.

若：

\boxed{ \lambda_O>\mu_C, }

則 mandatory backlog：

B_O(t)

持續增長。

這與 verification backlog 類似，但更危險：

verification backlog 是：

還沒驗的東西越積越多。

obligation expansion 是：

「必須做的東西」本身越驗越多。

6. Completion Drift 的正式定義

令 canonical intent：

I_t.

若：

I_{t+1}=I_t,

且沒有新的 mandatory external constraint：

K_{t+1}=K_t,

也沒有 material evidence 證明原 completion contract 缺漏：

E_{\mathrm{material}}=0,

但：

\mathcal O_{t+1}^{mandatory} \supset \mathcal O_t^{mandatory},

則本文稱：

\boxed{ \text{Completion Drift}. }

直覺上：

目標沒有變，但「完成」一直變遠。

7. Completion Drift 不等於 Requirements Volatility

這一點必須嚴格區分。

Requirements engineering 已長期研究：

Requirements Volatility

即 project lifecycle 中 requirement 的：

addition；
deletion；
modification；
change；
churn。

需求變更可能來自：

customer need 改變；
business rule 改變；
technology change；
environment change；
regulatory change；
stakeholder learning；
initial misunderstanding。

這些變更完全可能是合理而必要的。

因此：

\boxed{ \text{RequirementChange} \nRightarrow \text{BadEngineering}. }

本文關心的是：

\boxed{ \text{Unowned / Unauthorized Expansion of Mandatory Completion Conditions}. }

所以：

\boxed{ \text{RequirementsVolatility} \neq \text{CompletionDrift}. }

8. 外部研究：需求變更是真實成本，不應被假裝不存在

既有研究顯示 requirements volatility 不是抽象問題。

Nurmuliani 的長期 industrial case study 指出 requirements changes 在開發過程中不可避免，並以 addition、deletion、modification、reason、origin 等分類分析 change request；這些分類可用於估計 rework / effort。

一項 2002 IEEE survey-based empirical study報告 requirements volatility 與 schedule overrun、cost overrun 有顯著關係。

Ferreira 等人在超過 300 名 software project managers / practitioners 的 survey 中，也將 requirements volatility 描述為 common project risk，並研究 process factors 與 volatility 的關聯。

Peña 與 Valerdi 的 systems engineering 研究則提出五項觀察，其中包括：

volatility 增加 project functional size；
requirements change 造成 engineering-product rework；
因而增加 systems engineering effort；
越晚發生的 change，effort impact 通常越大；
addition / deletion / modification 的 impact 不相同。

因此本文不是要：

凍結 requirement，永遠不准變。

相反地：

\boxed{ \text{Change must be explicit because change has real cost}. }

9. Authorized Change

一個合法的 completion-boundary change 可表示為：

\chi_t = ( \text{source}, \text{reason}, \text{authority}, \text{impact}, \text{newScope}, \text{newObligations} ).

若：

Authorized(\chi_t)=1,

則：

C_t \rightarrow C_{t+1}.

此時 completion frontier 合法改變。

例如：

User:
除了原本登入，現在也要補 MFA。

則：

I_{t+1}\neq I_t.

新的 obligations 當然可以加入。

這不是 drift。

這是：

\boxed{ \text{Scope Evolution}. }

10. Evidence-Triggered Reopening

另一個合法 expansion 是：

review 發現原本沒看到、但其實已違反既有 requirement 的 defect。

例如原始 requirement：

user data must not be lost

review 發現：

save path can overwrite sole original on crash

雖然這個 blocker 沒寫在原始 todo，

但它已經被：

K_0

隱含要求。

因此：

\boxed{ \text{New Evidence} \rightarrow \text{Old Obligation Reopened}. }

這也不是 completion drift。

它是：

Bounded Reopening

因為 reopening 仍被：

S_0,G_0,K_0

限制。

11. 新 Requirement 與新 Evidence 必須分開

Review 最容易犯的錯誤之一，是把：

\text{new evidence}

和：

\text{new product desire}

混在一起。

例如 reviewer 說：

目前只有 literal search。支援 regex 會更好。

這可能是：

\boxed{ \text{FeatureSuggestion}. }

不是：

\text{BugEvidence}.

若原 requirement 沒有 regex，

就不能因為：

「更好」

而自動：

\text{regexSupport} \in \mathcal O^{\mathrm{mandatory}}.

12. Review Finding Taxonomy

作者既有 Implicit Superpowers 已提出五分法：

1. spec violation
2. in-scope defect
3. optional hardening
4. new scope
5. runtime-only validation

本文擴張成七類。

F1 — Specification Violation

明確違反：

S_0/G_0/K_0.

預設 blocking。

F2 — In-Scope Defect

雖未逐字寫入 spec，但直接破壞既有 required goal / invariant。

通常 blocking。

F3 — Evidence Gap

目前無法證明是否成立。

應 route validation。

不應直接假設 failure。

F4 — Optional Hardening

降低非必要風險、改善 maintainability、future-proof。

預設 nonblocking / deferred。

F5 — New Scope

真正新增 capability / constraint / product direction。

需要 scope authority。

F6 — Runtime / Environment Validation

不是 code change，而是需要：

target platform；
browser；
production-like environment；
benchmark；
visual / interaction test。

應轉到對應 verifier。

F7 — Speculative Concern

目前只有：

可能、也許、理論上。

沒有：

\text{Mechanism} + \text{Witness} + \text{Materiality}.

預設不能 blocking。

13. Finding Promotion Rule

令 review finding：

f.

要升格為 blocking obligation：

f\rightarrow o_b,

至少要求：

\boxed{ \text{Promote}(f) = InScope(f) \land Material(f) \land EvidenceSupported(f) \land ViolatesRequiredGoalOrInvariant(f). }

其中：

InScope

問題落在目前授權產品域。

Material

不是 trivial / cosmetic / irrelevant。

EvidenceSupported

有：

reproducible witness；
concrete causal mechanism；
deterministic evidence；
strong relevant inference。

RequiredGoalOrInvariant

真的破壞「必須成立」的東西。

這比：

\text{ReviewerConcern}(f)=1

嚴格得多。

14. Reviewer 不擁有 Product Scope

本文提出：

\boxed{ \text{ReviewerAuthority} = \text{EvidenceAuthority} \neq \text{ScopeAuthority}. }

reviewer 可以有很高 authority 去判斷：

這裡有 bug。

但未必有 authority 判斷：

所以產品現在必須新增另一個 feature。

Scope owner 可以是：

user；
product owner；
contract；
policy owner；
legal / compliance authority；
explicit governance process。

因此：

\boxed{ \text{Finding} \rightarrow \text{Classification} \rightarrow \text{AuthorizedDisposition}. }

而不是：

\text{Finding} \rightarrow \text{MandatoryWork}.

15. Verifier 也不擁有 Scope

同理：

\boxed{ \text{Verifier} \neq \text{ProductOwner}. }

一個 test 只能驗證它 encoded 的 contract。

如果 test 新增：

must support 10,000 concurrent users

但 canonical scope 只要求：

local desktop MVP

那麼：

\text{Test}=\text{RED}

不能自動證明：

\text{Product}=\text{Incomplete}.

可能是：

\boxed{ \text{ValidatorScope} > \text{ProductScope}. }

A01 稱這為 validator / scope misalignment。

A05 則關心：

validator scope 如何被偷偷轉成新的 mandatory obligation。

16. Test-Induced Scope Expansion

AI 很容易：

generate tests

然後把生成出的 test 當成新的 truth。

例如原 requirement：

input length <= 1000

AI 自己生成：

test 1,000,000-char input must complete in <10ms

test FAIL。

接著 AI 說：

performance blocker.

這形成：

\boxed{ \text{SelfGeneratedTest} \rightarrow \text{SelfGeneratedRequirement} \rightarrow \text{SelfBlocking}. }

本文稱為：

Test-Induced Scope Expansion

防止方法是：

\boxed{ \text{Test} \rightarrow \text{RequirementRef}. }

每個 blocking test 應能回答：

它在驗哪一條既有 requirement / invariant？

17. Security Category Inflation

另一種常見 completion drift 是：

ordinary engineering
→ hypothetical abuse
→ security concern
→ full security scope
→ new security requirements

這在真正：

auth；
credential；
privilege；
untrusted attack surface；
sensitive data；
consequential third-party harm；

存在時可能完全必要。

但若沒有 trigger，

則：

\boxed{ \text{ImaginedAttack} \nRightarrow \text{MandatorySecurityProject}. }

Global-First Completion 因此要求：

不要因為可以想像 hypothetical attack，就自動把普通 correctness work 轉成 adversarial security simulation。

18. Architecture Purity Inflation

Reviewer 也可能：

works correctly
→ architecture could be cleaner
→ refactor
→ better abstraction possible
→ refactor again

形成：

\boxed{ \text{Abstract Perfection} \rightarrow \text{Mandatory Completion Condition}. }

這非常危險。

因為 abstraction space 幾乎沒有自然終點。

對任何：

A_t,

總能想像：

A_{t+1}

「更漂亮」。

因此：

\boxed{ \text{Better Architecture Exists} \nRightarrow \text{Current Task Incomplete}. }

19. Hardening Infinity

安全、可靠性、robustness、performance 都具有類似問題。

例如：

works for 10k
→ why not 100k?
→ why not 1M?
→ what about Byzantine input?
→ what about cosmic-ray corruption?
→ what about hostile kernel?

每一個問題本身都可以是合法研究方向。

但有限任務需要：

\boxed{ \text{Bounded Threat / Reliability Model}. }

否則：

\mathcal O

可以無限增長。

所以：

\boxed{ \text{OpenWorldRisk} \neq \text{FiniteTaskObligation}. }

20. AI 為什麼特別容易放大 Completion Drift

人類 reviewer 想新 concern 需要：

C_{\mathrm{idea}}>0.

AI 生成 concern 的邊際成本非常低：

C_{\mathrm{idea}}^{AI}\downarrow.

所以：

find more edge cases
find more attack paths
find more refactors
find more future-proofing ideas
find more style improvements

可以幾乎無限進行。

因此：

\boxed{ \text{Concern Generation Capacity} \gg \text{Concern Resolution Capacity}. }

如果所有 concern 都 promotion：

\lambda_O\uparrow\uparrow.

Completion drift 就會成為結構性現象，而不是偶發問題。

21. 多 Agent Debate 也可以變成 Obligation Generator

假設：

Agent A: implementation
Agent B: reviewer
Agent C: adversarial reviewer
Agent D: architecture reviewer
Agent E: security reviewer

若每一個 Agent 的 output contract 都是：

找到更多問題。

那麼整體 objective 可能變成：

\boxed{ \max |\mathcal F|. }

而不是：

\boxed{ \min |\mathcal O^{open}_{mandatory}|. }

於是：

FindingCount\uparrow

被錯當成：

Quality\uparrow.

這就是：

Reviewer Objective Misalignment

22. Completion Supervisor 的真正目標

作者既有 Global-First Completion 已明確提出：

Problem exists != Completion failed
Local imperfection + intact global invariants can still be complete

以及：

Completion Supervisor 應優化 close actionable obligations，不是 maximize number of findings。

本文形式化為：

\boxed{ Objective_{completion} = \min |\mathcal O^{open}_{actionable,in\text{-}scope}|. }

不是：

\max|\mathcal F|.

23. Obligation State Machine

每一 obligation 應有明確狀態：

OPEN
RESOLVED
BLOCKED_EXTERNAL
DEFERRED_BY_SCOPE
NONBLOCKING
OUT_OF_SCOPE
NEW_TASK_CANDIDATE
SUPERSEDED

因此 finding 不需要永遠消失。

它可以被：

\text{Deferred}

而當前任務仍然：

\text{Complete}.

這是非常重要的工程能力：

\boxed{ \text{Remembering an imperfection} \neq \text{being blocked by the imperfection}. }

24. Blocking 與 Nonblocking 是語義，不是嚴重程度形容詞

一個 issue 可以：

severe-looking

但：

\text{OutOfScope}.

另一個 issue 可以：

tiny

卻直接破壞 required invariant。

因此：

\boxed{ \text{Blocking} \neq \text{Scary}. }

更精確地：

Blocking(f) = f\text{ prevents authorized completion}.

不是：

Blocking(f) = f\text{ sounds serious}.

25. Optional Hardening 為什麼特別容易被錯誤升格

Hardening 常具有：

正當性；
專業感；
可量化改善；
很難說「不好」。

例如：

多加一層 validation 比較安全。

幾乎總是聽起來合理。

但：

\boxed{ MarginalSafetyGain>0 }

不代表：

\boxed{ MandatoryBeforeRelease=1. }

仍需：

\text{Benefit} > \text{Cost}

且：

ScopeRelevant=1.

26. Requirements Volatility 與 Architecture Impact

既有研究顯示 requirements volatility 不只增加 project management cost，也會影響 architecture。

Dasanayake 等人的 exploratory case study 將 requirements volatility 描述為可能造成：

higher defect density；
project delays；
cost overruns；

並特別研究 software architecture 如何承受持續 requirement changes。

這支持本文一個重要治理原則：

真正的 scope change 要被正式承認，因為它可能要求 architecture re-evaluation。

反過來：

不應讓 reviewer 透過一條 comment 無聲地造成 architecture scope change。

因此：

\boxed{ \text{ArchitectureAffectingFinding} \rightarrow \text{ChangeControl} }

而不是：

\text{ArchitectureAffectingFinding} \rightarrow \text{SilentMandatoryRefactor}.

27. Code Review 研究：Review 確實會產生大量 change，但 change 類型不同

Modern Code Review 的 empirical research 已建立 review change taxonomy。

Panichella 與 Zaugg 分析：

211 review changes / commits；
648 review comments；
10 open-source projects；
再以 52 名 developers survey 補 taxonomy。

Fregnan、Petrulio 與 Bacchelli 2022 年研究三個大型 open-source projects，發現 review 過程中的 change 有多種來源與類型，且多數 review changes 與 evolvability concern 有關；他們也觀察到多數 review changes 並非直接由 reviewer comments 觸發。

這些研究非常重要，因為它提醒：

\boxed{ \text{Review Change} }

本來就不是同質集合。

因此 AI workflow 更不應把：

all review findings

壓成：

all blockers

28. Review-Loop Depth

定義每一 defect / finding 的 review depth：

D_R(f) = N_{\mathrm{review\ rounds}}.

對一個 release：

\overline D_R = \frac{1}{n} \sum_i D_R(f_i).

高：

D_R

本身不是錯。

例如 difficult concurrency bug 可能需要多輪。

真正危險的是：

D_R\uparrow

同時：

\Delta Evidence\rightarrow0

或：

\Delta MandatoryClosure\rightarrow0.

此時接近：

\boxed{ \text{Review Livelock}. }

29. Review Livelock

定義 review state：

R_t.

若：

R_t \rightarrow R_{t+1} \rightarrow R_{t+2}

持續產生活動，

但：

|\mathcal O^{open}_{mandatory}|

沒有趨近零，

且：

I_t

沒有合法變更，

則：

\boxed{ \text{Review Livelock}. }

系統一直：

review；
fix；
report；
reopen；

卻沒有終止。

30. Completion Frontier Drift Rate

定義 mandatory frontier size：

F_t = |\mathcal O_t^{mandatory,open}|.

若本輪關掉：

r_t

項，但新增：

g_t

項：

F_{t+1} = F_t-r_t+g_t.

定義：

\boxed{ D_C(t) = g_t-r_t }

為概念性的：

Completion Frontier Drift

若：

D_C(t)>0

長期成立，

則 task 越做越遠。

若：

D_C(t)<0,

則向 closure 收斂。

31. Scope Expansion Ratio

令：

N_{\mathrm{new\ mandatory}}

是 review 後新增 mandatory obligations。

其中真正經 authorized scope change / material evidence 支持者為：

N_{\mathrm{justified}}.

定義：

\boxed{ SER = \frac{ N_{\mathrm{new\ mandatory}} - N_{\mathrm{justified}} }{ N_{\mathrm{new\ mandatory}}+\epsilon }. }

可稱：

Scope Expansion Ratio

若：

SER\rightarrow1,

表示大部分 expansion 不是由 legitimate change / evidence 驅動。

32. Obligation Promotion Precision

將被升格為 blocker 的 findings 記為：

B.

後續經 scope owner / independent audit 確認真的應 blocking 的為：

B^\ast.

定義：

\boxed{ PP_B = \frac{|B\cap B^\ast|}{|B|}. }

即：

Blocking Promotion Precision

如果 reviewer 非常 aggressive：

Recall\uparrow,

但：

PP_B\downarrow,

就會造成大量 false blocker。

因此 review quality 不能只看：

\text{issues found}.

還要看：

\boxed{ \text{correctly promoted issues}. }

33. New Scope 必須走 Authority Transition

若 finding 真正要求：

S_t \rightarrow S_{t+1},

則應觸發：

\boxed{ \text{ScopeAuthorityTransition}. }

例如：

Reviewer:
我們應該把 local-only app 改成 cloud sync。

這不是普通 fix。

它是：

\text{ProductDirectionChange}.

因此應：

finding
→ proposal
→ scope owner
→ accept / reject / defer

而不是：

finding
→ blocker
→ implement

34. Risk Discovery 與 Risk Imagination

必須區分：

\text{RiskDiscovery}

與：

\text{RiskImagination}.

前者有：

evidence；
mechanism；
applicable environment；
realistic precondition。

後者只有：

理論上可能。

本文不否定 speculative analysis。

它可以進：

\text{RiskBacklog}.

但：

\boxed{ \text{SpeculativeRisk} \nRightarrow \text{CurrentReleaseBlocker}. }

除非：

\text{Materiality} + Likelihood/Exposure + \text{ScopeRelevance} + \text{RequiredPolicy}

成立。

35. Open World 與 Finite Task

現實世界永遠可以再問：

還有別的 bug 嗎？
還有別的 attack 嗎？
還有別的 optimization 嗎？
還有更漂亮的 abstraction 嗎？

因此：

\boxed{ \text{Absolute Completeness} }

通常不可作有限工程任務的停止條件。

需要的是：

\boxed{ \text{Scoped Finite Closure}. }

令：

\Omega

為 target domain，

\mathcal O_{\mathrm{mandatory}}

為 mandatory obligations，

\tau_E

為 required evidence threshold，

則 completion：

\text{Complete} = [ \mathcal O_{\mathrm{mandatory}}^{\mathrm{open}} = \varnothing ] \land [ Evidence\ge\tau_E ].

不要求：

\text{No conceivable imperfection in the universe}.

36. Stop Discipline 是完成能力的一部分

一個成熟 reviewer 不只要會：

找問題。

還要會：

知道什麼時候不應再擴張當前任務。

因此：

\boxed{ \text{ReviewCompetence} = \text{Detection} + \text{Classification} + \text{Prioritization} + \text{StopDiscipline}. }

沒有 stop discipline 的 reviewer，可能：

FindingRecall\uparrow

但：

TaskCompletion\downarrow.

37. Marginal Review Yield

令第 $k$ 輪 review 取得新的 material evidence：

\Delta E_k.

新增 justified blocking obligation：

\Delta B_k^\ast.

cost：

C_k.

定義：

\boxed{ Y_R(k) = \frac{ w_E\Delta E_k + w_B\Delta B_k^\ast }{ C_k }. }

稱：

Marginal Review Yield

當：

Y_R(k)\rightarrow0

且沒有 mandatory audit requirement，

則：

\boxed{ \text{StopReview}. }

38. Review Saturation

若連續：

m

輪 review 都：

沒有新 material evidence；
沒有新 in-scope blocker；
只有 optional hardening / stylistic concern；
required evidence 已足夠；

則可以定義：

\boxed{ ReviewSaturated=1. }

此時再加 reviewer：

\text{Reviewer}_{n+1}

不應因為：

可能還能找到什麼

而自動阻止完成。

39. Bounded Review

可設定：

review_policy:
  mandatory_rounds: 1
  extra_round_trigger:
    - unresolved blocker
    - changed affected cone
    - material new evidence
    - high-risk policy requirement
  stop_when:
    - no blocking obligations
    - required evidence sufficient
    - marginal review yield low

這不是 arbitrary timebox。

而是：

\boxed{ \text{Evidence-Conditioned Review Budget}. }

40. Affected-Cone Revalidation

如果修復只改動：

\Delta S

且 causal affected cone：

Cone(\Delta S),

則預設只需要：

V(Cone(\Delta S))

加上必要 boundary / global gate。

不應每次：

\Delta S_{\mathrm{local}}

都：

\text{reopen all obligations}.

否則每一個 fix 都可能讓：

F_C

重新膨脹。

41. 不要讓每次修復重置「宇宙」

某些 workflow 在每次 patch 後：

re-review whole repository
re-threat-model whole product
re-open architecture choices
re-run all possible concerns

等同：

S_t \rightarrow S_0^{\mathrm{unknown}}.

也就是不承認已經閉合的 evidence。

成熟系統應保留：

\boxed{ \text{ClosureMemory}. }

只有在：

Affected(\Delta S,o_i)=1

時 reopen：

o_i.

42. Closure Memory

每個 obligation：

o_i

應保存：

id:
requirement_ref:
status:
evidence:
closed_at_version:
affected_by:
reopen_condition:

因此：

Closed(o_i,t)

不是永遠真。

但也不是每次 edit 都變 false。

而是：

\boxed{ Reopen(o_i) \iff ReopenCondition_i(\Delta S)=1. }

這能大幅減少 review recursion。

43. Findings Ledger

本文建議維護 finding ledger，而不是把所有 finding 直接變 todo。

finding:
  id: F-104
  source: reviewer-2
  type: OPTIONAL_HARDENING
  scope_relation: in-scope-nonblocking
  evidence:
    - benchmark-ref
  materiality: low
  disposition: DEFERRED
  blocker: false
  new_task_candidate: true

這讓系統可以：

Remember(f)

同時：

\neg BlockCurrentTask(f).

44. Reviewer Scope Contract

Reviewer 的 prompt / role contract 應明確寫：

You may:
- identify defects,
- identify evidence gaps,
- classify risks,
- propose improvements.

You may not:
- silently redefine product scope,
- convert optional hardening into mandatory work without justification,
- treat every hypothetical concern as a blocker,
- reopen closed obligations without an affected-state or evidence reason.

因此 reviewer 是：

\boxed{ \text{EvidenceGenerator} + \text{Classifier} + \text{Challenger} }

而不是：

\boxed{ \text{UnlimitedScopeExpander}. }

45. Independent Reviewer 也不能逃過 Scope Discipline

「獨立」只表示：

EvidenceCorrelation\downarrow.

它不代表：

ScopeAuthority\uparrow.

所以：

\boxed{ \text{IndependentReviewer} \neq \text{IndependentProductOwner}. }

這一點對 A08 的 multi-agent independent validation 很重要。

46. Review Finding 的五問

Global-First Completion 已提出一個非常實用的 finding gate：

Is it inside the original scope closure?
Is there a concrete mechanism or witness?
What causal scale and radius does it have?
Does it violate a required invariant or goal?
Is it blocking, nonblocking, deferred, or a new-task candidate?

本文將其形式化為：

Q(f) = ( \text{Scope}, \text{Evidence}, \text{Radius}, \text{Invariant}, \text{Disposition} ).

若這五個欄位沒有完成，

則：

\boxed{ \text{Finding} }

不應直接進：

\text{MandatoryObligation}.

47. Finding Disposition

建議 disposition：

BLOCKING_IN_SCOPE
NONBLOCKING_IN_SCOPE
VALIDATION_REQUIRED
DEFERRED_BY_SCOPE
OUT_OF_SCOPE
NEW_TASK_CANDIDATE
REJECTED_NO_EVIDENCE
SUPERSEDED

只有：

BLOCKING\_IN\_SCOPE

自動阻止：

\text{Completion}.

48. Completion Certificate

本文提出概念性：

completion_certificate:
  canonical_scope_version: S-12

  mandatory_obligations:
    total: 18
    resolved: 18
    open: 0

  blockers:
    open: []

  findings:
    nonblocking: 4
    deferred: 3
    out_of_scope: 2
    new_task_candidates: 5

  review:
    rounds: 2
    saturated: true
    latest_material_new_evidence: false

  validation:
    required_evidence_sufficient: true

  scope_changes:
    accepted:
      - CR-02
    pending: []

  status: COMPLETE

重要的是：

certificate 可以明確承認還有 imperfections。

但：

\boxed{ NoActionableInScopeBlocker=1. }

49. Completion 不等於零缺陷

A05 的一個核心防誤讀：

\boxed{ \text{Complete} \nRightarrow \text{Perfect}. }

一個 release 可以：

有 low-impact known issue；
有 future hardening；
有 backlog；
有 new feature candidate；

仍然：

Complete_{\mathrm{scope}}=1.

否則任何真實大型軟體都幾乎無法「完成」。

50. 完成是一個 Scope-Relative Predicate

更精確地：

\boxed{ Complete(X\mid S,I,K,E). }

不是：

Complete(X).

其中：

$S$ ：scope；
$I$ ：intent；
$K$ ：required constraints / invariants；
$E$ ：required evidence standard。

所以：

Complete(X\mid S_1)

可以成立，

同時：

Complete(X\mid S_2)=0.

如果：

S_2>S_1.

這不是矛盾。

51. Completion Drift 的幾種來源

本文暫分十類。

D1 — Reviewer Scope Capture

reviewer 直接把建議變 requirement。

D2 — Test-Induced Scope Expansion

AI 自己生成 test，再讓 test 生成 requirement。

D3 — Security Inflation

hypothetical threat 變 mandatory security project。

D4 — Architecture Purity Inflation

「更漂亮」變「不做就不能完成」。

D5 — Future-Proofing Inflation

可能的未來 requirement 先變當下 blocker。

D6 — Performance Target Inflation

100ms 通過後又要求 50ms、10ms，沒有新 contract。

D7 — Reliability Infinity

不斷擴張 fault model。

D8 — Multi-Agent Finding Maximization

每個 subagent 以 finding count 為隱性 objective。

D9 — Closure Memory Loss

已驗證項目被每輪重新視為未知。

D10 — Authority Ambiguity

沒有人明確擁有 stop / scope decision，所以 workflow 預設繼續。

52. legitimate scope discovery 不能被 drift theory 壓掉

反過來也要避免另一個錯誤。

如果 review 發現：

原 specification 根本不足以完成使用者意圖。

例如使用者說：

我要可以安全儲存文件。

spec 只寫：

Save button writes file.

review 發現：

crash consistency；
overwrite guard；
encoding；
permission error；

完全未處理。

此時有可能：

SpecificationAlignment<1.

因此：

\boxed{ \text{Review} \rightarrow \text{IntentRecovery} \rightarrow \text{AuthorizedSpecRevision} }

是合理的。

關鍵是：

要顯式標記「我們正在修規格」。

而不是假裝：

這只是原 task 裡本來就明確存在的另一個小 blocker。

53. Change Control 不是官僚儀式，而是 Authority Boundary

A04 批評不必要 ceremony。

但 A05 反而需要某種 change control。

因為：

\text{ScopeChange}

是一個真正 authority transition。

因此：

\boxed{ \text{ChangeControl} }

的最小功能不是填表。

而是確保：

什麼變了？
為什麼變？
誰授權？
哪些 obligations 新增／刪除／修改？
completion boundary 是否更新？
downstream evidence 是否失效？

只要做到這些，change control 可以非常輕。

54. Scope Diff

每次合法 scope change：

S_t\rightarrow S_{t+1}

應產生：

\boxed{ \Delta S_t. }

例如：

scope_diff:
  added:
    - MFA support
  removed: []
  modified:
    - session lifetime: 24h -> 12h
  reason:
    - product-owner decision

這樣 completion frontier 的擴張才可追溯。

55. Obligation Diff

同理：

\Delta\mathcal O_t = ( \mathcal O^+, \mathcal O^-, \mathcal O^\Delta ).

每個新增 obligation 都應有：

\text{provenance}.

例如：

ORIGINAL_INTENT
SPEC_REQUIREMENT
DISCOVERED_DEFECT
POLICY
AUTHORIZED_SCOPE_CHANGE
LEGAL
CONTRACT

而不是：

REVIEWER_THOUGHT_OF_IT

直接當成 mandatory provenance。

56. Stop Authority

大型 Agent 系統常定義：

planner；
implementer；
reviewer；
verifier；

卻沒定義：

誰有權宣布「夠了」？

因此需要：

\boxed{ \text{StopAuthority}. }

它可以屬於：

Completion Supervisor；
product owner；
architect；
policy engine；
user。

Stop authority 的職責不是忽略風險。

而是：

\boxed{ \text{separate remaining possibilities from remaining obligations}. }

57. Open Findings ≠ Open Obligations

這句應固定：

\boxed{ \mathcal F^{open} \neq \mathcal O^{open}_{mandatory}. }

一個產品可以有：

|\mathcal F^{open}|=100

但：

|\mathcal O^{open}_{mandatory}|=0.

例如：

50 future enhancements；
30 documentation polish；
20 optional optimizations。

當前 release 仍可以完成。

58. Review Budget 與 Risk

review budget：

B_R

應由：

B_R^\ast = f( \text{Risk}, \text{Irreversibility}, \text{Novelty}, \text{EvidenceGap}, \text{ScopeSize}, \text{ChangeRadius} )

決定。

不是：

B_R^\ast = f( \text{how many reviewers are available} ).

這和 APR / Adaptive Process Depth 的資源治理一致。

59. Risk-Weighted Obligation Priority

對 mandatory obligation：

o_i,

定義：

p_i = w_s ScopeCriticality_i + w_r Risk_i + w_d DependencyCentrality_i + w_e EvidenceGap_i.

則修復順序應：

p_i\downarrow

排序。

而不是：

reviewer 最新講的先做。

60. Queue Discipline

可維護：

BLOCKERS
VALIDATION
NONBLOCKING
DEFERRED
NEW_TASKS

review finding 先進：

\text{Inbox}

再分類。

不要直接：

\text{Inbox} \rightarrow BLOCKERS.

這個簡單 queue separation 可以防止大量 completion drift。

61. Review 不是 Requirements Elicitation 的無限替代品

Review 確實可以發現 requirements defect。

但如果每輪 review 都持續發現：

我們其實不知道產品要什麼，

那真正問題可能不是：

\text{Implementation}.

而是：

Specification / Intent.

此時應升級 diagnosis：

\text{Review} \rightarrow \text{IntentRecovery}.

而不是：

\text{Review} \rightarrow \text{MorePatch}.

62. Completion Drift 與 Responsibility-Layer Misalignment

如果 reviewer 一直在 micro 層產生：

patch
patch
patch

但新 issue 都來自：

\text{Architecture}

或：

\text{Specification},

則：

\lambda_O

可能持續高。

這時應：

\boxed{ \text{Instance} \rightarrow \text{Pattern} \rightarrow \text{Architecture} \rightarrow \text{Substrate}. }

而不是：

再多找一個 reviewer。

這是 Global-First v2.1 的 structural-defect escalation。

63. Completion Drift 與 A06

A06 將研究：

V_{\mathrm{generation}} > V_{\mathrm{verification/governance}}.

A05 提供其中另一種 backlog：

\boxed{ \text{Obligation Backlog}. }

AI 不只生成 code。

AI 還可以快速生成：

concerns；
tests；
edge cases；
hardening ideas；
alternate architectures。

所以：

V_{\mathrm{concern}}

也可能遠大於：

V_{\mathrm{closure}}.

64. Completion Drift 與 A08

A08 將討論多 Agent：

\text{ManyAgents} \neq \text{IndependentPerspectives}.

A05 再補：

即使 agents 真有不同 perspective，

也不能讓：

N_{\mathrm{reviewers}}

直接控制：

|\mathcal O_{\mathrm{mandatory}}|.

否則：

\boxed{ \text{MoreIndependentReview} }

反而可能造成：

\boxed{ \text{MoreCompletionDrift}. }

所以 independent validation 仍需要：

\text{ScopeBinding}.

65. 實驗設計

可以比較兩種 workflow。

Control — Unbounded Review Promotion

all findings
→ mandatory
→ fix
→ re-review
→ all new findings mandatory

Treatment — Scope-Bound Review

finding
→ classify
→ promote only justified blockers
→ defer new scope
→ bounded reopening
→ stop on closure

測：

\text{TaskSuccess},

\text{EscapedDefects},

\text{WallClock},

\text{TokenCost},

\text{ReviewRounds},

\text{MandatoryObligationCount},

\text{ScopeExpansionRatio},

\text{BlockingPromotionPrecision}.

66. 主要可驗證假說

H1 — Scope-Bound Review Reduces Drift

SER_{\mathrm{treatment}} < SER_{\mathrm{control}}.

H2 — Blocking Precision Improves

PP_{B,\mathrm{treatment}} > PP_{B,\mathrm{control}}.

H3 — Review Depth Decreases

在品質不顯著下降下：

D_{R,\mathrm{treatment}} < D_{R,\mathrm{control}}.

H4 — Completion Time Decreases

T_{\mathrm{complete,treatment}} < T_{\mathrm{complete,control}}.

H5 — Escaped Critical Defect 不增加

\text{CriticalEscape}_{\mathrm{treatment}} \le \text{CriticalEscape}_{\mathrm{control}} + \epsilon.

如果 H1–H5 大致成立，代表 scope discipline 並非降低 rigor，而是降低 false blocker。

67. 最小工程實作

第一版甚至不需要複雜 runtime。

只要 review finding 強制輸出：

finding_id:
type:
requirement_ref:
evidence:
causal_radius:
materiality:
disposition:
blocking:
scope_change_required:

並要求：

blocking=true

時：

requirement_ref != null
OR
explicit invariant / policy / authorized change ref != null

就能消掉很多無來源 blocker。

68. Reviewer Prompt Patch

可以加入：

Do not equate "could be improved" with "blocks completion."

For every finding:
1. identify the violated requirement/invariant, if any;
2. provide concrete evidence or mechanism;
3. classify scope relation;
4. classify blocker status;
5. do not create new product requirements unless routed as a scope-change proposal.

Optional hardening and new scope must not silently block the current task.

這是一個非常小但高價值的 guard。

69. Completion Supervisor Patch

Completion Supervisor 每輪做：

1. Read canonical scope/version.
2. Inspect open mandatory obligations.
3. Ingest new findings.
4. Classify findings.
5. Promote only justified blockers.
6. Route validation gaps.
7. Route scope changes to authority.
8. Preserve closure memory.
9. Compute marginal review yield.
10. Stop when actionable in-scope obligations are closed.

這就是 A05 的最小 runtime。

70. 本文核心命題

本文 v0.2 收束成十六條。

P1 — Finding / Requirement Separation

\boxed{ \text{Finding} \neq \text{Requirement}. }

P2 — Reviewer / Scope Owner Separation

\boxed{ \text{ReviewerAuthority} \neq \text{ScopeAuthority}. }

P3 — Verifier / Product Owner Separation

\boxed{ \text{Verifier} \neq \text{ProductOwner}. }

P4 — Requirements Change Legitimacy

\boxed{ \text{RequirementChange} \nRightarrow \text{EngineeringFailure}. }

合法 change 應被管理，而不是禁止。

P5 — Completion Drift

若 intent / mandatory external constraints 未變，卻持續新增無充分依據的 mandatory obligations，則：

\boxed{ \text{CompletionDrift}=1. }

P6 — Obligation Promotion Gate

\boxed{ \text{Promote}(f) = \text{InScope} \land \text{Material} \land \text{EvidenceSupported} \land \text{RequiredViolation}. }

P7 — Optional Hardening Non-Blocking Default

\boxed{ \text{OptionalHardening} \nRightarrow \text{Blocker}. }

P8 — Speculative Concern Non-Blocking Default

\boxed{ \text{HypotheticalConcern} \nRightarrow \text{MandatoryImplementation}. }

P9 — Test Non-Authority

\boxed{ \text{GeneratedTest} \nRightarrow \text{GeneratedRequirement}. }

P10 — Bounded Reopening

\boxed{ \text{ClosedObligation} }

只應在 affected state / new material evidence / authorized scope change下 reopen。

P11 — Open Finding / Open Obligation Separation

\boxed{ \text{OpenFindings} \neq \text{OpenMandatoryObligations}. }

P12 — Completion Non-Perfection

\boxed{ \text{Complete} \nRightarrow \text{Perfect}. }

P13 — Scoped Completion

\boxed{ \text{Complete}(X\mid \text{Scope},\text{Intent},\text{Constraints},\text{Evidence}). }

P14 — Stop Discipline

\boxed{ \text{ReviewCompetence} = \text{Detection} + \text{Classification} + \text{Prioritization} + \text{StopDiscipline}. }

P15 — Completion Objective

\boxed{ \min |\mathcal O^{open}_{actionable,in\text{-}scope}| }

優於：

\max|\mathcal F|.

P16 — Scope Change Requires Authority

\boxed{ \text{ScopeChange} \Rightarrow \text{AuthorityTransition}. }

71. 結論

Review、validation 與 red-team 的價值非常高。

但正因為它們能發現問題，才必須嚴格區分：

\boxed{ \text{能發現問題} }

和：

\boxed{ \text{有權決定哪些問題必須在這一次完成前解決}. }

在 AI 時代，finding 的生成成本正在快速下降。

高能力模型可以持續產生：

edge cases；
risk scenarios；
refactoring opportunities；
future-proofing ideas；
alternate architectures；
additional tests。

因此真正的瓶頸逐漸不再是：

找不到問題。

而可能是：

沒有機制阻止所有「可能的問題」一起變成「現在的義務」。

如果工作流沒有 scope binding、obligation classification、closure memory 與 stopping rule，就可能形成：

\text{Review} \rightarrow \text{Fix} \rightarrow \text{Review} \rightarrow \text{NewRequirement} \rightarrow \text{Fix} \rightarrow \cdots

最終：

\boxed{ \text{Completion Frontier}\rightarrow\infty. }

所以成熟 Agent 系統不能只具有：

\text{IssueDetection}.

它還必須具有：

\boxed{ \text{IssueClassification} + \text{ScopeGovernance} + \text{ObligationPromotionControl} + \text{ClosureMemory} + \text{StopDiscipline}. }

本文留下的最終原則是：

\boxed{ \textbf{ A reviewer may discover new possibilities. Only authorized evidence and scope changes may redefine what "done" means. } }

中文即：

Reviewer 可以發現新的可能性；但只有經授權的需求變更、既有義務的真實違反與足夠證據，才能重新定義「完成」的邊界。

參考文獻

A. 外部研究

Nurmuliani, N. (2007). Investigating requirements volatility during software development projects: an empirical study. University of Technology Sydney, PhD thesis.
以 industrial long-term case study 分析 requirements change 的 types、reasons、origins 與 rework / effort。
Nurmuliani, N., Zowghi, D., & Powell, S. (2004 / related APSEC work). Requirements volatility empirical studies.
需求變更對 cost / schedule / rework 的工程影響。
Zowghi, D., Nurmuliani, N. (2002). A study of the impact of requirements volatility on software project performance. Ninth Asia-Pacific Software Engineering Conference. DOI: 10.1109/APSEC.2002.1182970.
Ferreira, S., Collofello, J., Shunk, D., & Mackulak, G. (2011). Reducing the risk of requirements volatility: findings from an empirical survey. Journal of Software Maintenance and Evolution: Research and Practice. DOI: 10.1002/smr.515.
Survey 覆蓋超過 300 名 software development practitioners / project personnel。
Jayatilleke, S., & Lai, R. (2018). A systematic review of requirements change management. Information and Software Technology, 93, 163–185. DOI: 10.1016/j.infsof.2017.09.004.
系統性回顧 requirements change management，強調 requirement change 在軟體流程中的必要性與管理需求。
Peña, M., & Valerdi, R. (2015). Characterizing the Impact of Requirements Volatility on Systems Engineering Effort. Systems Engineering, 18, 59–70. DOI: 10.1111/sys.21288.
研究指出 requirements volatility 增加 functional size、rework 與 systems-engineering effort，且 late change impact 較大。
Dasanayake, S., Aaramaa, S., Markkula, J., & Oivo, M. (2019). Impact of requirements volatility on software architecture: How do software teams keep up with ever-changing requirements? Journal of Software: Evolution and Process, 31(6), e2160. DOI: 10.1002/smr.2160.
Panichella, S., & Zaugg, N. (2020). An Empirical Investigation of Relevant Changes and Automation Needs in Modern Code Review. Empirical Software Engineering, 25, 4833–4872. DOI: 10.1007/s10664-020-09870-3.
建立 modern code review change taxonomy；分析 211 review changes / commits、648 review comments、10 個 open-source projects，並 survey 52 名 developers。
Fregnan, E., Petrulio, F., & Bacchelli, A. (2022). The evolution of the code during review: an investigation on review changes. Empirical Software Engineering, 27, Article 177. DOI: 10.1007/s10664-022-10205-7.
研究 review changes 的類型、trigger 與 patch factors；顯示 review changes 並非同質集合。

B. Neo.K / EveMissLab 既有研究

Neo.K. 〈綠燈錯置——AI 時代「通過驗證」不等於「完成意圖」的新型不對齊〉，2026.
Neo.K. 〈表觀成功與實質完成的分離〉，A02 v0.2，2026.
Neo.K. 〈局部正確與全域失敗〉，A03 v0.2，2026.
Neo.K. 〈流程代理錯置：當 Planning、Review 與 Verification 開始冒充 Progress〉，A04 v0.2，2026.
Neo.K. Implicit Superpowers — 將外顯流程改造成內隱 Agent Governance 的改造提案, v0.1, 2026.
Neo.K. Global-First Completion, v2 / v2.1, 2026.
Neo.K. Global Completion Theory, v1.0, 2026.
Neo.K. Parallel Experiment Scorecard / Architect Evaluation，2026.
提出 review-loop depth、scope discipline、BLOCKER / RELEASE-DEBT / FUTURE-HARDENING 分離與 stop discipline。

End of A05 v0.2