fix(todos): verify repository delivery before completion - #3558
Conversation
a9b5da8 to
0e10b8f
Compare
cocolord
changed the title
|
Updated this PR to the minimal, root-cause fix at Changed surfaces: Todo completion admission, repository delivery verification, Todo/Turn execution-workspace wiring, completion CAS, contract docs, terminal replay behavior, and the Windows POSIX-only lifecycle test. Checks run locally: 144 focused tests passed (1 Windows-only skip), Ruff passed, maintainability ratchet passed, public-boundary scan passed, and standard GitHub Actions on Intentional exclusions: no provider/model session behavior, no new |
c88b05d to
c0f9332
Compare
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
Exact-head review: no blocking findings
Reviewed head a4c84cd4584837adef55f25ccf9257f2c83a515b against base e059b1757c2a5ab8eb909f55d068c70b05a7f6b9.
Review coverage:
- repository identity, live remote default-branch lookup, clean-worktree and ancestor checks;
- validation/remote TOCTOU handling and mutation-lock source/HEAD binding;
- typed exemptions for monitors, blockers, user gates, user actions, and non-write research Todos;
- fail-closed Chat receipts and auto-research worker failure propagation across agent/model/provider handoffs;
- typed-state, domain-neutrality, behavior-change disclosure, and guidance-vs-obligation lenses;
- cross-group caller/signature consistency.
Validation reviewed:
- focused Python tests: 158 passed;
- TypeScript control-plane tests: 123 passed;
- LoopX premerge canary: 18/18 passed, 0 manual holds;
- Ruff,
git diff --check, public/private boundary scan, and focused auto-research smokes passed.
Local npm run typecheck:control-plane could not run because this checkout lacks the tsc dependency (tsc: command not found); this is an environment skip rather than a reported type failure. GitHub checks remain authoritative for the final merge gate.
Future-facing scope pass: no additional refactor is needed in this PR. The repository-delivery rule is localized in the Todo completion boundary, while callers only provide the actual execution workspace and consume typed rejection.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次评审针对精确 head a4c84cd4584837adef55f25ccf9257f2c83a515b。PR 希望把代码交付 Todo 的完成语义从调用方自报证据收紧为机器校验：只有执行工作区属于目标仓库、工作树干净、且当前提交已进入远端默认分支时，才能把 agent 交付 Todo 写成 done；同时保持 monitor、blocker、user gate/action 和无写入研究 Todo 的原有完成行为。
改动思路
核心规则集中在 repository_delivery.py，由 run_completion_validation_gate_with_source 在锁外校验仓库、远端默认分支和声明的 validation command，再由 locked_todo_completion_transaction 在写锁内绑定 Todo source、HEAD 与先前收据，避免换工作区或换提交后复用验证结果。CLI todo complete、Turn settlement 和 auto-research worker 都向该边界传入真实执行工作区；Chat 与 worker loop 把被拒绝的完成传播为失败，不再记录假成功。文档说明了默认分支可达性、handoff 不替代交付证据、以及未合并分支应保持 open/deferred。
正向路径是：执行 checkout 匹配 task_repository → 工作树干净 → 远端默认分支包含 HEAD → 可选 validation 在同一 checkout 通过 → 锁内 HEAD/source 再匹配 → 写入 done 和机器生成的 commit 收据。负向路径包括错误 origin、dirty worktree、未合并 HEAD、validation 后换 commit 或远端改写；这些路径返回 typed failure，Todo 保持未完成，Chat/worker 也停止继续投影成功。
具体改动
repository_delivery.py新增 write-Todo 分类、origin 归一化、实时默认分支查询、对象补取和 ancestry 校验。completion_validation.py与completion_transaction.py把仓库收据纳入 source snapshot、validation 和锁内 CAS；todos.py负责传递工作区并把已验证 commit 追加到 evidence。cli_commands/todo.py、cli_commands/turn.py、worker_runtime.py接入执行工作区；worker_loop.py和chat_todo_actions.py对完成拒绝 fail closed。- 合同文档补充 repository delivery completion 语义；测试覆盖错误仓库、脏工作树、未合并分支、伪 tracking ref、远端推进/改写、validation TOCTOU、terminal replay、handoff、event projection、CLI/Chat/worker 传播，以及 Windows 的 POSIX-only 路径。
对主干的风险
[P1 blocker] todo_requires_repository_delivery 在 repository_delivery.py:26-29 直接比较原始 task_class，因此任何没有显式写入 task_class 的 agent Todo 都会绕过新门禁。LoopX 的现有 typed contract 明确允许省略该字段，并通过 normalize_todo_task_class(None, text=..., action_kind=...) 将普通 agent Todo 归一为 advancement_task；todo add 的 --task-class 也是可选参数。实测一个含 task_repository 和 required_write_scopes=[\"loopx/**\"]、但省略 task_class 的 Todo，todo_requires_repository_delivery 返回 False。这会让旧状态和最小 CLI 调用仍可直接完成，正好破坏本 PR 要建立的交付不变量。
请在该分类器中使用现有 normalize_todo_task_class，传入 Todo 的 text 与 action_kind，并补一个“省略 task_class 但归一后为 advancement_task”的完成级回归测试；同时保留显式/推断 monitor 的豁免测试，避免把 monitor 文本误分类为交付 Todo。
PR 当前还与 main 冲突，属于合并就绪性 hold；这不替代上述语义 blocker。其余已检查的 typed-state、domain-neutrality、默认行为披露和 guidance-vs-obligation 表述未发现额外阻塞项。
我的整体评价
整体架构方向正确：仓库交付权威被放在 Todo completion 的 typed 边界，而不是散落到各调用方；失败传播、远端 ancestry、validation/HEAD 绑定和 event projection 的覆盖也较完整。独立运行相关测试得到 166 passed, 1 skipped，git diff --check 通过，GitHub 上 11 个适用检查均为通过。但缺失字段是合法且常见的 typed 状态，当前直接字符串比较造成真实绕过，所以结论为 REQUEST_CHANGES。修复归一化缺口并解决与 main 的冲突后可重新评审。
English verdict: REQUEST_CHANGES on exact head a4c84cd4584837adef55f25ccf9257f2c83a515b. The architecture and focused validation are strong, but repository-delivery enforcement is bypassed whenever a valid agent Todo omits explicit task_class; use the existing typed task-class normalizer and add an implicit-advancement regression test. Validation: 166 passed, 1 skipped; diff check and all applicable GitHub checks passed.
a4c84cd to
f9be536
Compare
|
Addressed the remaining typed-state blocker and rebased the PR again after the What changed:
Validation on the rebased branch:
Future-facing scope pass: the repair reuses the existing typed normalizer in |
70b5874 to
1269f82
Compare
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Exact head: 3558@1269f8283a4221f60660b638c662b655ec90b7c9
English verdict: APPROVE. The requested typed-state fix is present:
repository-delivery admission now uses the existing task-class normalizer, so
legacy or event-projected agent Todos cannot bypass the gate merely by omitting
explicit task_class, while typed and inferred monitor work remains exempt.
动机
这个 PR 收紧代码交付 Todo 的完成语义：对声明了目标仓库和写入意图的
agent advancement task，done 不再只依赖调用方提供的验证文本，而要验证实际
执行工作区、干净状态、远端默认分支可达性和同一提交上的 validation。此前复审
发现分类器直接比较原始 task_class，而仓库契约允许该字段缺省并通过现有
normalizer 推导类型，因此合法的旧 Todo 或 event-projected Todo 可能绕过新门禁。
改动思路
仓库交付规则仍由 control_plane/todos/repository_delivery.py 单点拥有；
completion_validation.py 在锁外执行远端与声明验证，completion_transaction.py
在锁内重新校验 Todo source、HEAD 和远端结果，CLI、Turn、Chat 与 Auto Research
只传入真实 workspace 或消费 typed rejection。新修复没有新增第二套分类逻辑，
而是直接调用 normalize_todo_task_class(task_class, text, action_kind)。
正向路径：agent advancement Todo 声明 task_repository 和 write intent →
执行 checkout 的 origin、clean worktree、HEAD 和远端默认分支 ancestry 通过 →
可选 validation 在同一 checkout 运行 → 锁内重新确认相同 source/HEAD →
完成 Todo 并追加机器生成的 commit receipt。负向路径：错误仓库、dirty
worktree、未合入分支、远端历史替换、validation 后换 HEAD、Chat 或 worker
完成被拒绝，都会 fail closed，不写入虚假成功。
具体改动
repository_delivery.py：规范化 repository identity，实时读取远端默认分支，
检查 clean worktree 和 commit ancestry，并生成不含本地路径/原始 Git 输出的
typed receipt。当前修复让todo_requires_repository_delivery复用现有
normalize_todo_task_class，输入 stored text/title 与action_kind。completion_validation.py/completion_transaction.py：把仓库验证绑定到
completion source snapshot，并在 validation 后和写锁内重新校验，关闭 TOCTOU。todos.py与 CLI/Turn/Auto Research 调用方：传递真实 execution workspace；
Chat 和 worker loop 将 rejected completion 投影为失败并停止后续成功路径。- 文档说明仅 write-scoped advancement task 受此门禁；monitor、blocker、
user action/gate 和无写入研究任务保持原行为。 - 测试覆盖错误 origin、dirty worktree、未合入提交、伪 tracking ref、远端推进
或改写、validation/HEAD 漂移、terminal replay、handoff、CLI/Chat/worker
传播、event projection，以及本轮新增的隐式 advancement 和隐式 monitor。
关键符号复核：
todo_requires_repository_delivery使用 typed normalizer 后，缺省
task_class的普通 agent Todo 会归一为advancement_task；action_kind=monitor
仍归一为 monitor。validate_repository_delivery每次从实际 checkout 读取 origin、dirty state、
HEAD 和远端默认分支，不信任本地 tracking ref。run_completion_validation_gate_with_source将仓库验证与 caller-approved
validation 绑定到同一 workspace，并在 validation 后重新验证 HEAD。locked_todo_completion_transaction在持锁阶段再次验证 source 和 repository
receipt，阻止并发变更或 stale receipt 被提交。run_auto_research_worker_loop与ChatTodoActionMixin对 completion rejection
fail closed，不会把未完成 Todo 继续投影成成功进度。
对主干的风险
本轮未发现剩余业务 blocker。该变更有意改变 write-scoped advancement Todo 的
默认完成行为，并已在合同文档中披露；monitor、blocker 和 user lane 的豁免由
typed enum/normalizer 保持，不依赖新的 substring denylist。远端曾出现两类非本
PR 失败：主干 thin prompt 预算回归（已由 #3591 修复并合入）以及一次 Windows
Effect runtime crash-recovery flake；后者在同代码主干 run 中通过，已通过
content-identical signed head 触发新一轮验证，最终 merge 应以该轮 CI 为准。
验证证据：
- 5 个相关测试文件：
175 passed, 1 skipped。 - 最终基线上的 repository-delivery + 原 CI budget 回归：
25 passed, 37 deselected。 - changed-surface Ruff：通过。
- sandbox 外
loopx canary premerge --from-git-diff：18/18，通过且无 manual hold。 - public/private boundary scan 与
git diff --check：通过。 - 最新远端 head 的 DCO、dependency review、Frontstage build、release build、
SonarCloud、Windows lifecycle 和 Linux full pytest 全部通过。
我的整体评价
修复把交付判定放在正确的 Todo completion authority 上，并复用已有 typed
task-class contract，没有新增平行状态或宽泛兼容层。此前 P1 已被直接修复，rebase
冲突也只保留了主干现行测试语义。基于当前代码与验证，结论为 APPROVE；
正式 approval 因作者身份不可用，请维护者在当前 exact head 上复审。
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
Approval conclusion (author-owned PR; GitHub blocks formal self-approval)
Exact head: 3558@1269f8283a4221f60660b638c662b655ec90b7c9
English verdict: APPROVE. The requested typed-state fix is present:
repository-delivery admission now uses the existing task-class normalizer, so
legacy or event-projected agent Todos cannot bypass the gate merely by omitting
explicit task_class, while typed and inferred monitor work remains exempt.
动机
这个 PR 收紧代码交付 Todo 的完成语义：对声明了目标仓库和写入意图的
agent advancement task，done 不再只依赖调用方提供的验证文本，而要验证实际
执行工作区、干净状态、远端默认分支可达性和同一提交上的 validation。此前复审
发现分类器直接比较原始 task_class，而仓库契约允许该字段缺省并通过现有
normalizer 推导类型，因此合法的旧 Todo 或 event-projected Todo 可能绕过新门禁。
改动思路
仓库交付规则仍由 control_plane/todos/repository_delivery.py 单点拥有；
completion_validation.py 在锁外执行远端与声明验证，completion_transaction.py
在锁内重新校验 Todo source、HEAD 和远端结果，CLI、Turn、Chat 与 Auto Research
只传入真实 workspace 或消费 typed rejection。新修复没有新增第二套分类逻辑，
而是直接调用 normalize_todo_task_class(task_class, text, action_kind)。
正向路径：agent advancement Todo 声明 task_repository 和 write intent →
执行 checkout 的 origin、clean worktree、HEAD 和远端默认分支 ancestry 通过 →
可选 validation 在同一 checkout 运行 → 锁内重新确认相同 source/HEAD →
完成 Todo 并追加机器生成的 commit receipt。负向路径：错误仓库、dirty
worktree、未合入分支、远端历史替换、validation 后换 HEAD、Chat 或 worker
完成被拒绝，都会 fail closed，不写入虚假成功。
具体改动
repository_delivery.py：规范化 repository identity，实时读取远端默认分支，
检查 clean worktree 和 commit ancestry，并生成不含本地路径/原始 Git 输出的
typed receipt。当前修复让todo_requires_repository_delivery复用现有
normalize_todo_task_class，输入 stored text/title 与action_kind。completion_validation.py/completion_transaction.py：把仓库验证绑定到
completion source snapshot，并在 validation 后和写锁内重新校验，关闭 TOCTOU。todos.py与 CLI/Turn/Auto Research 调用方：传递真实 execution workspace；
Chat 和 worker loop 将 rejected completion 投影为失败并停止后续成功路径。- 文档说明仅 write-scoped advancement task 受此门禁；monitor、blocker、
user action/gate 和无写入研究任务保持原行为。 - 测试覆盖错误 origin、dirty worktree、未合入提交、伪 tracking ref、远端推进
或改写、validation/HEAD 漂移、terminal replay、handoff、CLI/Chat/worker
传播、event projection，以及本轮新增的隐式 advancement 和隐式 monitor。
关键符号复核：
todo_requires_repository_delivery使用 typed normalizer 后，缺省
task_class的普通 agent Todo 会归一为advancement_task；action_kind=monitor
仍归一为 monitor。validate_repository_delivery每次从实际 checkout 读取 origin、dirty state、
HEAD 和远端默认分支，不信任本地 tracking ref。run_completion_validation_gate_with_source将仓库验证与 caller-approved
validation 绑定到同一 workspace，并在 validation 后重新验证 HEAD。locked_todo_completion_transaction在持锁阶段再次验证 source 和 repository
receipt，阻止并发变更或 stale receipt 被提交。run_auto_research_worker_loop与ChatTodoActionMixin对 completion rejection
fail closed，不会把未完成 Todo 继续投影成成功进度。
对主干的风险
本轮未发现剩余业务 blocker。该变更有意改变 write-scoped advancement Todo 的
默认完成行为，并已在合同文档中披露；monitor、blocker 和 user lane 的豁免由
typed enum/normalizer 保持，不依赖新的 substring denylist。远端曾出现两类非本
PR 失败：主干 thin prompt 预算回归（已由 #3591 修复并合入）以及一次 Windows
Effect runtime crash-recovery flake；后者在同代码主干 run 中通过，已通过
content-identical signed head 触发新一轮验证，最终 merge 应以该轮 CI 为准。
验证证据：
- 5 个相关测试文件：
175 passed, 1 skipped。 - 最终基线上的 repository-delivery + 原 CI budget 回归：
25 passed, 37 deselected。 - changed-surface Ruff：通过。
- sandbox 外
loopx canary premerge --from-git-diff：18/18，通过且无 manual hold。 - public/private boundary scan 与
git diff --check：通过。 - 最新远端 head 的 DCO、dependency review、Frontstage build、release build、
SonarCloud、Windows lifecycle 和 Linux full pytest 全部通过。
我的整体评价
修复把交付判定放在正确的 Todo completion authority 上，并复用已有 typed
task-class contract，没有新增平行状态或宽泛兼容层。此前 P1 已被直接修复，rebase
冲突也只保留了主干现行测试语义。基于当前代码与验证，结论为 APPROVE；
正式 approval 因作者身份不可用，请维护者在当前 exact head 上复审。
1269f82 to
9bda718
Compare
|
@huangruiteng 请复审 exact head 已 rebase 到最新 Typed-state blocker 仍由既有 |
|
Exact-head CI update for |
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次复审针对精确 head 9bda718afb02b902143a7d863ff64f1b1c7e644d。PR 要把 write-scoped agent advancement Todo 的 done 从“调用方声称已验证”收紧为机器可验证的仓库交付：执行工作区必须属于声明的 task_repository、工作树干净，且 HEAD 已进入远端默认分支；同时不改变 monitor、blocker、user action/gate 和无写入研究 Todo 的完成语义。
上一轮 P1 是合法 Todo 省略显式 task_class 时会绕过门禁。当前 head 已在 todo_requires_repository_delivery 中复用 normalize_todo_task_class(task_class, text, action_kind)，并为隐式 advancement、隐式 monitor 和 event-projected Todo 增加完成级覆盖，因此该 blocker 已关闭。
改动思路
责任边界保持集中：repository_delivery.py 负责 typed admission、仓库 identity、远端默认分支和 ancestry；run_completion_validation_gate_with_source 把实际 checkout、声明 validation 和同一 HEAD 绑定；locked_todo_completion_transaction 在写锁内重新核对 Todo source、origin、clean state 与 commit；CLI、Turn、Chat 和 Auto Research 只提供真实 execution workspace 或消费 typed rejection。
正向路径为：归一化后是 agent advancement task，并声明 repository + write intent → origin/clean/remote ancestry 通过 → 可选 validation 在同一 checkout 执行 → validation 后和锁内保持相同 source/HEAD → 写入 done 与机器生成的 commit receipt。负向路径覆盖 workspace 缺失、错误 origin、dirty checkout、未进入默认分支、伪造 tracking ref、validation 后换 commit/远端历史替换以及 Chat/worker completion rejection；这些路径均保持 Todo 未完成并 fail closed。
具体改动
todo_requires_repository_delivery现在使用现有 typed task-class normalizer；缺省task_class的普通 agent Todo 进入门禁，action_kind=monitor仍获得 typed 豁免。validate_repository_delivery从实际 execution checkout 读取 origin、worktree、HEAD 和远端默认分支，不信任本地 tracking ref，并生成不含本地路径或原始 Git 输出的收据。- completion validation/transaction 通过 source snapshot、post-validation recheck 与锁内 commit/source 比对关闭跨 checkout、跨 revision 和 stale receipt 复用。
- CLI/Turn/Auto Research 传递真实 workspace；Chat 与 worker loop 对拒绝结果停止成功投影。
- 文档披露 write-scoped advancement Todo 的新默认完成语义；测试覆盖物化及 event-projected Todo、handoff、terminal replay、Windows fail-closed 路径和主要 TOCTOU 场景。
关键 symbol 复核包括 todo_requires_repository_delivery、validate_repository_delivery、run_completion_validation_gate_with_source、locked_todo_completion_transaction 和 run_auto_research_worker_loop。typed-state、domain-neutrality、默认行为披露及 guidance-vs-obligation 四个 lens 均未发现新的阻塞项。
对主干的风险
未发现阻塞性问题。此次行为变化只作用于已有 repository + write intent 的 agent advancement Todo，豁免由 typed enum/normalizer 决定，没有新增 substring denylist 或产品特定控制面措辞。代码量约 1,460 行，其中约 757 行是完成边界的正负路径测试；生产改动分布在既有 Todo completion authority 及其实际 callers，属于与高风险交付不变量相称的范围，没有看到可安全删除的平行抽象。future-facing pass 认为无需在本 PR 继续扩张；更大的整理会削弱本次变更的可审阅性。
本地证据：六个相关测试文件 178 passed, 1 skipped；changed-surface Ruff 与 git diff --check 通过；premerge canary 的 18 项中 17 项及 public/private boundary 全部通过、0 manual hold。唯一失败是 cli-output-budget-regression-smoke.py 创建临时 base worktree 时，被本机 repository reference-transaction hook 以 fatal: Needed a single revision 拒绝，尚未进入被测 CLI differential，属于该 host 的设置失败而非 PR 行为断言失败。远端 exact-head 的 11 个适用检查（含 Linux pytest、Windows lifecycle、DCO、Dependency Review 和 builds）均为成功。
残余风险是本机未完成该一项临时-worktree differential；GitHub 的完整 exact-head checks 和其余 focused/canary coverage 足以支持代码评审结论，但合并仍应以当前 head 不漂移且远端 required checks 保持绿色为准。
我的整体评价
上一轮指出的真实 typed-state 绕过已经直接修复，并用 materialized/event-projected 的正负例固定。交付权威仍位于正确的 Todo completion boundary，调用方只负责提供执行上下文和传播失败，没有引入第二套分类源。基于 exact-head diff、关键调用链、负路径、focused tests、远端 checks 与边界扫描，本轮结论为 APPROVE。
English verdict: APPROVE on exact head 9bda718afb02b902143a7d863ff64f1b1c7e644d. The prior implicit-task_class bypass is fixed through the existing typed normalizer and covered for both materialized and event-projected Todos, while monitor exemptions remain typed. No blocking finding remains. Local validation: 178 passed, 1 skipped; Ruff and diff hygiene passed; 17/18 premerge selections plus the public-boundary scan passed with zero manual holds. The sole local canary failure was a host reference-transaction hook rejecting creation of the smoke's temporary base worktree before the differential ran; all 11 applicable exact-head GitHub checks are successful.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
这个能力你感觉重要么，agent 会没改代码以为自己改了么😂
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次复审针对 exact head 9bda718afb02b902143a7d863ff64f1b1c7e644d，base 为 ea9fcc3eeeaa2d636ef8f5a421d200630444511c。PR 希望把 write-scoped agent advancement Todo 的完成语义从调用方自报“已经验证”收紧为机器校验：实际执行 checkout 必须匹配 task_repository、工作树干净，且 HEAD 已进入远端默认分支；monitor、blocker、user action/gate 与无写入研究 Todo 保持原完成行为。上一轮关于隐式 task_class 的 P1 已在当前 head 通过现有 typed normalizer 修复，这部分复核通过。
但 maintainer 随后的问题“agent 会没改代码以为自己改了么”揭示了当前 contract 尚未覆盖的核心失败模式：现在的 receipt 证明的是“某个干净默认分支 checkout 存在”，不是“这个 Todo 对应的代码改动确实发生并交付”。
改动思路
当前调用链是：todo_requires_repository_delivery 用 role、归一化 task class、task_repository 和 write intent 决定是否启用门禁；validate_repository_delivery 校验 origin、dirty state、当前 HEAD 与远端默认分支 ancestry；run_completion_validation_gate_with_source 在声明 validation 前后绑定 checkout/HEAD；locked_todo_completion_transaction 在 Todo 写锁内重核 source 与同一 HEAD；CLI、Turn、Chat 和 Auto Research 传入实际 workspace，并把 typed rejection 传播为失败。
正向路径中，一个真正已合入默认分支的 Todo 会得到 todo_repository_delivery_v0 verified receipt，随后在同一 source/HEAD 上写入 done 和机器生成的 commit evidence。负向路径中，错误 origin、dirty checkout、未合并 HEAD、伪 tracking ref、validation 后换 HEAD/改写远端，以及 Chat/worker completion rejection 都 fail closed。
缺失的负向路径是 no-op delivery：如果 patch 没有应用、改在另一个 checkout、或 agent 误以为已修改代码，只要它从一个干净的最新默认分支 checkout 调用 complete，当前 validate_repository_delivery 仍会返回 verified；没有 Todo 起始 revision、Todo-bound exact delivery commit 或其他 delta lineage 可证明这次 Todo 实际产生了交付。
具体改动
repository_delivery.py集中实现 typed admission、repository identity、实时远端默认分支读取、clean worktree、commit object 与 ancestry 校验。todo_requires_repository_delivery已正确复用normalize_todo_task_class(task_class, text, action_kind)，因此省略显式 task class 的普通 agent Todo 不再绕过，推断 monitor 仍豁免。completion_validation.py先读取 materialized/event-projected Todo source，再执行 repository delivery 和 caller-approved validation，并在 validation 后重验 commit/remote；completion_transaction.py把 role、task repository、capabilities/scopes 等纳入 source snapshot，在锁内重验 source 和 workspace commit。todos.py将 verified commit 追加为机器 evidence；CLI 与 Turn 提供真实 execution workspace；Chat 对未应用 transition 抛出失败；Auto Research worker 将 completion rejection 提升为 turn/loop failure，不再继续投影成功。- 文档披露 repository + write intent advancement Todo 的新默认完成规则；测试大量覆盖错误仓库、脏树、未合并分支、远端漂移、validation TOCTOU、handoff、terminal replay、event projection、Windows fail-closed，以及隐式 advancement/monitor 分类。
关键 symbols 复核了 todo_requires_repository_delivery、validate_repository_delivery、run_completion_validation_gate_with_source、locked_todo_completion_transaction 和 run_auto_research_worker_turn/Chat consumer。typed-state、domain-neutrality、默认行为披露和 guidance-vs-obligation lens 未发现额外问题；production code 位于现有 Todo completion authority 及实际 callers，scope-fit 合理，约一半 diff 是高风险完成边界的正负测试。
对主干的风险
[P1 blocker] validate_repository_delivery 在 repository_delivery.py:121-226 只证明当前 checkout 的 HEAD 是远端默认分支的 ancestor。它没有将该 HEAD 与 Todo 创建/claim/lease 时的 baseline 比较，也没有要求 Todo-bound exact delivery commit。因此“完全没有为该 Todo 产生任何新提交”的 checkout 与真实交付 checkout 在 receipt 上不可区分。
我独立用当前实现验证了这一点：在一个刚从远端默认分支创建、工作树干净且没有为测试 Todo 产生任何新 commit 的 checkout 上，给定 role=agent、task_class=advancement_task、匹配的 task_repository 与 required_write_scopes，validate_repository_delivery 返回 status=verified。也就是说，agent 的 patch 若静默 no-op、落在错误 worktree，或者它误认为代码已改，随后从干净 main 完成 Todo，门禁仍会把 Todo 写成 done；这正是 maintainer 问题中的 false completion。
最小修复应把 delivery receipt 绑定到 Todo 的可审计变更 lineage，而不是仅绑定当前仓库状态：例如保存/复用 Todo 开始时的 exact baseline，并要求一个超出 baseline、已进入目标默认分支的 delivery commit；若支持“接手时改动已由别人合入”，则需要显式提供并校验 Todo-bound exact commit/PR receipt，而不能把任意当前 main HEAD 当作该 Todo 的交付。请至少补一个完成级回归测试：全新 write-scoped Todo 在 clean current-main checkout 上没有任何 Todo-specific delta 时必须拒绝完成；同时保留已交付 exact commit、handoff 和 terminal replay 的正例。
独立验证方面，4 个相关测试文件 161 passed；changed-surface Ruff、git diff --check 与 public/private boundary scan 通过；远端 exact head 的 11 个 check-runs 均为 success 或预期 skipped。现有绿色测试证明 origin/dirty/ancestry/TOCTOU 和 caller 传播实现稳定，但测试集中没有覆盖上述 no-op false-delivery invariant，因此远端绿色不能关闭该 blocker。
我的整体评价
REQUEST_CHANGES。这个能力很重要：agent 确实可能因为 patch 未应用、操作错 worktree 或错误解释验证结果而“以为自己改了代码”；把 completion authority 放在 Todo 边界、校验真实 origin/default-branch 并让 Chat/worker fail closed 都是正确方向。当前 head 也已修复上一轮隐式 task-class 绕过。不过现有 receipt 只能证明 checkout 已处于可交付状态，不能证明这个 Todo 有任何交付，因而尚未满足 maintainer 明确提出的 no-op failure mode。补齐 Todo-bound delta/commit lineage 后，这套架构可继续复审；本结论不授权合并。
English verdict: REQUEST_CHANGES on exact head 9bda718afb02b902143a7d863ff64f1b1c7e644d. The prior implicit-task-class bypass is fixed, and the origin/clean-tree/default-branch/TOCTOU enforcement is well tested. However, a fresh clean checkout at current remote main with no Todo-specific change still receives status=verified, so an agent that made no code change can falsely complete a write-scoped Todo. Bind completion to a Todo baseline or explicit exact delivery commit/PR receipt and add a no-op clean-main rejection test. Validation: 161 focused tests passed; Ruff, diff hygiene, boundary scan, and all 11 applicable remote checks passed. Do not merge this exact head.
9bda718 to
4d8627d
Compare
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
动机
本次复审针对 exact head 4d8627de3f97fbad27c9820467d6bbdbb2456c4b，base 为 47ae23b67c3e11dc2f403bd96738b84a9057d527。上一轮 P1 指出：旧实现只证明当前 checkout 干净且位于远端默认分支，无法区分真实 Todo 交付与“agent 没有改代码、改错 worktree，随后从 clean main 调用 complete”的 false completion。
这个 failure mode 是真实且重要的。当前 head 不再把任意 clean-main HEAD 当作交付证明；write-scoped agent advancement Todo 必须在完成请求中显式绑定一个 exact delivery commit，缺失时 fail closed。
改动思路
责任仍集中在既有 Todo completion authority。validate_repository_delivery 同时验证执行 workspace 和 Todo 完成请求绑定的 exact commit：
- workspace origin 必须匹配
task_repository，worktree 必须干净； delivery_commit必须是完整、小写的 40/64 位 Git OID，并存在于实际 checkout；- 该 commit 必须同时是 workspace HEAD 与实时远端默认分支 revision 的 ancestor；
- 该 commit 的 first-parent 变更必须触及 Todo 声明的
required_write_scopes； - caller-approved validation 后以及 Todo 写锁内再次校验同一个 delivery commit，并锁定原 workspace HEAD，继续关闭跨 checkout、换 HEAD、远端漂移和 stale receipt 的 TOCTOU。
这采用了上一轮允许的“显式 Todo-bound exact delivery commit”路线，而没有在 Todo 创建/claim 时强制访问目标仓库。绑定发生在同一个 typed completion request 中：todo_id、execution workspace 与 exact commit 一起进入 completion transaction；任意当前 main HEAD 不再被自动推断为交付。
具体改动
repository_delivery.py：receipt 现在区分 Todocommit与workspace_commit；新增缺 commit、非法 OID、对象不存在、不在 workspace history、未进入远端默认分支、未触及 write scope、默认分支漂移等 typed status。merge commit 使用 first-parentdiff-tree -m，不会把合法 squash/merge 交付误判为空 delta。completion_validation.py/completion_transaction.py：锁外初验、声明 validation 后复核、锁内 CAS 都传递同一个 exact delivery commit；workspace HEAD 仍作为独立 TOCTOU fence。- CLI / Chat / Turn：
todo complete --delivery-commit <full-oid>、typed Chat complete 和 genericvalidated_completion都可传递该字段；非 completion result 或非法 OID 被 typed validation 拒绝。Codex CLI 当前不能产生validated_completion，因此没有扩张其 schema/prompt。 - 文档：明确 clean current-main checkout 本身不构成交付证明，write-scoped completion 必须提供 exact delivered commit。
- 回归覆盖：clean-main 无 commit、scope mismatch、unknown/malformed/uppercase commit、merge commit、远端推进、validation/HEAD/remote TOCTOU、handoff、event projection、CLI/Chat/Turn forwarding 与 terminal replay。
对主干的风险
行为变化有意且仅作用于声明 repository + write intent 的 agent advancement Todo；typed monitor、blocker、user gate/action 与无写入研究 Todo 保持原语义。exact commit 是调用方在 Todo 完成请求中声明的交付对象，LoopX 验证其对象、workspace/default-branch ancestry 和 write-scope delta；本 PR 不引入需要跨仓库读取的创建时 baseline，也不声称仅凭 Git 能证明提交作者的业务动机。
future-facing pass：本轮发现 turn_driver/executor.py 的新增校验曾使 maintainability ratchet 超过 1500 行门槛，最终把 delivery-commit 格式规则归位到已拥有 result-kind contract 的 transaction.py，executor 保持 1499 行；没有新增平行状态机或兼容 facade。public/private boundary 扫描通过，未包含本地路径、raw logs、credentials 或生成的 uv.lock。
验证证据：
- changed-surface focused tests：
204 passed； - changed-surface Ruff、Python compile、
git diff --check：通过； - 标准
loopx canary premerge --from-git-diff：direct checks 4/4、catalog 9/9、risk-profile 8/8、public boundary 1/1，零失败、零 warning、零 manual hold； - exact-head GitHub CI：DCO、Dependency Review、Linux pytest、Windows lifecycle、Pages/Release builds 与两项 SonarCloud 全部成功；
- merge base 精确等于当前 rebase 基线，PR 当前
MERGEABLE；全部 5 个分支 commit 均含 DCO，且 TRAE co-author trailer 恰好一次并位于末尾。
我的整体评价
此前的 no-op false-completion blocker 已被直接关闭：没有 exact commit 的 clean-main completion 会返回 delivery_commit_required，传入的 commit 还必须在真实 workspace/default branch history 中并触及声明 write scope。交付 authority 仍位于正确的 Todo completion boundary，调用方只负责显式提供 exact commit 和传播 typed rejection；scope 与验证强度与该 P1 相称。基于 exact-head diff、关键调用链、负路径、premerge 和远端 CI，本轮结论为 APPROVE。作者身份无法提交正式 self-approval，请维护者复审当前 exact head。
English verdict: APPROVE on exact head 4d8627de3f97fbad27c9820467d6bbdbb2456c4b. Clean current-main completion now fails without an explicit Todo-bound delivery commit, and the supplied full lowercase OID must exist in the execution checkout, be reachable from both workspace HEAD and the live remote default branch, and touch the declared write scope. Local focused tests: 204 passed; standard premerge: 18/18 selected checks plus all direct/public-boundary checks passed; all applicable exact-head GitHub checks are green. Formal approval remains maintainer-owned.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次复审锁定 exact head 4d8627de3f97fbad27c9820467d6bbdbb2456c4b，base 为 47ae23b67c3e11dc2f403bd96738b84a9057d527。PR 的目标是把 write-scoped agent advancement Todo 的完成从调用方自报“已经验证”收紧为机器校验：实际 execution checkout 必须匹配 task_repository、工作树干净、交付已经进入远端默认分支，并让 CLI、Turn、Chat 与 Auto Research 都传播同一 typed rejection。上一轮指出的隐式 task_class 绕过已在前一提交修复；新提交进一步要求调用方提供 exact delivery_commit，意图关闭“agent 没改代码却以为已经交付”的 no-op false completion。
改动思路
整条正向调用链是：todo_requires_repository_delivery 用 role、typed task class、repository 和 write intent 启用门禁；CLI todo complete --delivery-commit、Chat action 或 Turn validated_completion 提供一个完整小写 OID；run_completion_validation_gate_with_source 调用 validate_repository_delivery；后者校验真实 origin、clean worktree、live remote default branch、delivery commit 同时可达 workspace HEAD 与 remote default head，并通过 git diff-tree 检查它触及声明的 write scope；声明 validation 之后和 locked_todo_completion_transaction 写锁内再次绑定同一 workspace HEAD、默认分支和 delivery commit；成功后才写入 done 与机器 receipt。
负向路径覆盖缺失/畸形/未知 commit、错误仓库、dirty worktree、未合入 commit、commit 不在当前 workspace、默认分支或 workspace 在 validation 后漂移、commit 不触及 write scope，以及 Chat/worker completion rejection。这些路径均 fail closed。新实现也保留 monitor、blocker、user action/gate 和无 write intent 研究 Todo 的既有豁免。
但是当前新字段仍是调用方自报的 opaque OID，没有与 Todo 的创建、claim、hard lease、delivery PR 或开始时 baseline 建立 lineage。门禁只能证明“这个历史提交存在并碰过相同目录”，不能证明“这个提交交付了这个 Todo”。
具体改动
repository_delivery.py将 receipt 拆成commit（调用方提供的 delivery commit）和workspace_commit，新增 OID 规范化、merge/普通 commit changed-path 读取、write-scope matching，以及 workspace/remote 双 ancestry 校验；原有 origin、clean-tree、live-default-branch 和 TOCTOU 校验仍集中在这一 typed authority。completion_validation.py与completion_transaction.py在 pre-validation、post-validation 和写锁阶段重复验证 delivery commit，并继续用expected_workspace_commit约束 checkout 没有换 HEAD。- CLI/Chat/Turn surfaces 增加
delivery_commit：CLI 只允许todo complete；Chat 透传 opaque 值并由 completion boundary 验证；Turn host result 只允许validated_completion携带 40/64 位小写 OID。todos.py把该值传入完成事务并记录 verified receipt。 docs/project-agent-todo-contract.md披露新默认规则和最小命令。测试覆盖缺失、malformed、uppercase、unknown、out-of-scope、merge commit、remote advance、handoff、terminal replay、event-projected Todo、Chat/CLI/Turn 透传和 validation TOCTOU。- 全 PR 的其余 surface 仍与上一轮一致：CLI/Turn 负责提供真实 execution workspace，Chat 和 Auto Research 对拒绝停止成功投影，测试覆盖 materialized/event-projected Todo、Windows fail-closed 和主要调用方传播。
关键 symbols 复核了 todo_requires_repository_delivery、validate_repository_delivery、_delivery_commit_touches_todo_scope、run_completion_validation_gate_with_source、locked_todo_completion_transaction、validate_delivery_commit 及 CLI/Chat/Turn callers。typed-state、domain-neutrality、默认行为披露、guidance-vs-obligation 四个 lens 没有发现额外问题；生产逻辑仍位于已有 Todo completion authority，没有建立新的平行分类源。
对主干的风险
[P1 blocker] exact commit 没有绑定 Todo lineage，旧的无关 commit 可以伪装成交付。在 validate_repository_delivery 中，接受条件只是：调用方给出的 OID 是当前 workspace 与 remote default head 的 ancestor，并且该 commit 的 diff 至少匹配一个声明 write scope。代码没有检查 commit 晚于 Todo baseline、属于绑定的 PR/lease、或由任何机器 receipt 证明和该 Todo 相关。
我在 exact head 上独立复现：从当前 clean PR checkout 调用 validate_repository_delivery，构造一个全新的 write-scoped advancement Todo，并把当前 origin/main 的既有 commit 47ae23b67c3e11dc2f403bd96738b84a9057d527 当作 delivery_commit；该 commit 早于这个 Todo/测试、只是历史 main 提交，但因为它位于 workspace/remote ancestry 且碰过 loopx/**，函数返回 status=verified。因此 agent 若没有产生任何新改动，只需误报（或选择）一个历史 main OID，就仍能把 Todo 标记 done；这与上一轮 no-op blocker 是同一种 false completion，只是从“任意 clean HEAD”变成“任意碰过同 scope 的历史 commit”。新增测试只验证“不提供 OID会拒绝”，没有覆盖“提供无关历史 OID也应拒绝”。
最小修复应把 delivery commit 与 Todo 的审计 lineage 机器绑定。可选方案包括：记录 Todo 创建/claim/lease 时的 exact baseline 并要求 delivery commit 超出该 baseline；或消费一个与 Todo/PR 绑定、经过 readback 的 exact delivery receipt。若允许接手时别人已合入同一工作，也应要求显式的 Todo-bound receipt，而不是接受调用方任意挑选 ancestry 中的 commit。请补完成级回归：新 Todo 在 clean current-main checkout 上把一个 pre-Todo、同 scope 历史 commit 作为 --delivery-commit 时必须拒绝；同时保留真正 Todo-bound direct/merge commit、handoff 与 replay 正例。
独立验证方面，四个 completion/CLI/Chat/Turn 相关测试文件 194 passed；changed-surface Ruff、git diff --check 与 public/private boundary scan 通过。exact-head GitHub 的 11 个 check-runs 均 success 或预期 skipped。上述复现直接调用当前 production validator，并返回 verified，因此远端绿色与现有正负测试不能关闭这个缺失的不变量。
我的整体评价
REQUEST_CHANGES。新提交显著提高了门槛：缺失、伪格式、未合入或不触及 write scope 的 commit 都会 fail closed，CLI/Chat/Turn 也已接入同一 completion authority，方向正确。但 delivery_commit 目前只是另一个调用方声明，尚未成为 Todo-bound evidence；它仍允许“没有为 Todo 改任何代码”的 agent 通过一个旧 main commit 完成任务。把 commit 绑定到 Todo baseline、lease 或 exact PR/delivery receipt 后，这套方案才真正回答 maintainer 的 no-op failure mode。本结论不授权合并。
English verdict: REQUEST_CHANGES on exact head 4d8627de3f97fbad27c9820467d6bbdbb2456c4b. The new exact-commit, dual-ancestry, write-scope, and TOCTOU checks are well placed, but the supplied OID is not bound to the Todo. I reproduced a fresh write-scoped Todo accepting the pre-existing origin/main commit 47ae23b67c3e11dc2f403bd96738b84a9057d527 as status=verified merely because it is in workspace/remote ancestry and touched loopx/**. Thus an agent that made no change can still complete the Todo by naming an unrelated historical commit. Bind the delivery commit to a Todo baseline, lease, or exact PR/delivery receipt, and add a pre-Todo same-scope commit rejection test. Do not merge this exact head.
4d8627d to
c64ba1a
Compare
cocolord
left a comment
cocolord
left a comment
There was a problem hiding this comment.
动机
本次复审针对 exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c，base 为最新 origin/main@0233a2f32ca6bd4f86dad4eb215dd49428864a71。上一轮 P1 的独立复现成立：仅要求调用方给一个 exact commit 仍不足，因为一个 pre-Todo、同 write scope 的历史 main commit 也满足 object/ancestry/scope 条件。
当前 head 已把 delivery commit 与机器记录的 Todo 起始 lineage 绑定，不再接受调用方任意挑选 ancestry 中的旧 commit。
改动思路
复用现有 todo claim 作为工作开始边界，而不是增加第二套 sidecar 或要求 Todo 创建时跨仓库读取：
- write-scoped Todo 被 claim 时，LoopX 从实际 execution checkout 读取 live remote default branch；checkout 必须匹配
task_repository、干净且HEAD精确等于该远端 revision； - LoopX 把该 revision 写为机器拥有的
delivery_baseline_commit，调用方没有设置/覆盖该字段的 CLI、Chat 或 host input； - completion 的 exact
delivery_commit必须是 baseline 的严格后继，同时仍需位于 workspace HEAD 与 live remote default head ancestry 中并触及声明 write scope； - Todo 文本/role/task class/action/repository/write scopes/capabilities 等交付规格变化时 baseline 自动失效，必须重新 claim；仅 reassign 已 claim Todo 会保留同一 lineage；
- baseline 加入 completion source snapshot/CAS、Markdown codec、event-sourced projection 和下游 compact projections，防止 validation/lock/event readback 期间被替换或丢失。
因此 reviewer 的原复现 delivery_commit=0233a2f32（或任何 baseline 之前/等于 baseline 的同 scope 历史提交）会返回 delivery_commit_not_after_baseline，不会写入 done。
具体改动
repository_delivery.py：新增 claim baseline 捕获、共享 clean-workspace 校验、baseline object/strict-descendant 校验和 typed claim/completion receipts。todos.py/todo.py：todo claim从实际当前目录捕获 baseline；claim 失败保持 Todo 未认领；completion 延续 exact commit 验证。contract.py/line_update.py：加入只由内部 claim 写入的delivery_baseline_commitcodec；clear claim 或交付规格变更会清除 baseline。event_sourced_state.py与 Todo list/quota/summary projections：baseline 在 canonical event/Markdown roundtrip 和 CAS 中保留。- 文档：明确先在 clean remote-default checkout 执行
todo claim，再从交付 checkout 以 exact commit 完成。 - 回归：新增 pre-Todo 同 scope 历史 commit 拒绝、缺 baseline 拒绝、claim checkout 已有 pre-claim commit 拒绝、spec 变化 invalidation，并保留 direct/merge commit、handoff、terminal replay 与 event-projected 正例。
对主干的风险
该行为只收紧声明 repository + write intent 的 agent advancement Todo。monitor、blocker、user gate/action 与无 write intent Todo 不触发 baseline。老的 write-scoped Todo 若没有机器 baseline会 fail closed，需要在 clean remote-default checkout 上重新 claim；这是有意迁移行为，避免把现有 claimed_by 文本误当成交付 lineage。
future-facing pass：claim/completion 复用同一个 clean-workspace helper；baseline 规则位于已有 Todo repository-delivery authority，没有新 sidecar、平行 state machine 或任意调用方可写字段。loopx/todos.py maintainability ratchet 保持通过。
验证证据：
- latest-main 组合态：Todo completion + mutation authority + handoff + CLI/Chat/Turn suites
320 passed； - focused completion/CLI/Chat/Turn suites
207 passed； - changed-surface Ruff、Python compile、
git diff --check、maintainability ratchet：通过； - 标准 premerge：direct checks 4/4、catalog 9/9、risk-profile 8/8、public boundary 1/1，零失败、零 warning、零 manual hold；
- exact-head GitHub CI：DCO、Dependency Review、Linux pytest、Windows lifecycle、Pages/Release builds、SonarCloud 全部成功；
- PR 当前
MERGEABLE，merge base 精确等于0233a2f32；6 个分支 commit 均有 DCO 且 TRAE trailer 恰好一次并位于末尾。
我的整体评价
此前两轮指出的 false-completion 问题现在都关闭了：clean main 无 exact commit 不能完成；即使提供 pre-Todo、同 scope 的历史 commit，也因不严格晚于机器 claim baseline 而拒绝。交付证明绑定在 Todo lifecycle 的实际开始边界，handoff/replay 保留 lineage，规格变化强制重新 claim。基于 exact-head diff、负向复现、扩展 suites、premerge 和远端 CI，本轮结论为 APPROVE。作者身份无法提交正式 self-approval，请维护者复审当前 exact head。
English verdict: APPROVE on exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c. todo claim now records a machine-owned live-default-branch baseline from the real clean checkout, and completion requires an exact delivery commit that is a strict descendant of that baseline, remains in workspace/remote ancestry, and touches the declared write scope. A pre-Todo same-scope commit now fails with delivery_commit_not_after_baseline. Validation: 320 extended tests passed; standard premerge 18/18 plus all direct/public-boundary checks passed; all exact-head GitHub checks are green. Formal approval and merge remain maintainer-owned.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
未发现阻塞项。
动机
本次复审锁定 exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c。这个 PR 要解决的是 write-scoped agent advancement Todo 的“假完成”：调用方不能只说验证通过，LoopX 必须从实际 execution checkout 验证目标仓库、干净工作树、远端默认分支、Todo 对应的交付提交及声明 write scope。上一轮的 P1 blocker 是 exact delivery_commit 仍可指向 Todo 出现前、但恰好碰过同 scope 的历史提交；当前 head 新增机器拥有的 claim baseline，直接关闭该复现。
改动思路
交付 authority 仍集中在 loopx/control_plane/todos/repository_delivery.py，没有让 CLI、Chat、Turn 或 Auto Research 各自实现一套判断。todo claim 现在从真实 cwd 捕获 live remote default revision，要求 checkout 的 origin 匹配、工作树干净且 HEAD 正好等于该 revision，然后把它写为内部 delivery_baseline_commit。completion 继续要求完整小写 delivery_commit，并新增“baseline 是 delivery commit 的严格祖先”约束；delivery commit 仍须位于 workspace HEAD 和 live remote default head 的 ancestry 中，并触及 Todo 的 write scope。
正向路径是：在 clean remote-default checkout 上 claim → 写入 baseline → 实现、合并并从 delivered checkout 调用 complete → run_completion_validation_gate_with_source 验证 baseline、commit、origin、clean state、双 ancestry、scope 和声明 validation → locked_todo_completion_transaction 以包含 baseline 的 source snapshot 再做 CAS/TOCTOU 校验 → 写入 done 和机器 receipt。负向路径会拒绝缺 baseline、等于或早于 baseline 的历史 commit、错误 origin、dirty checkout、未合入/未知/畸形 commit、scope 不匹配、validation 后 HEAD/remote/source 漂移；Chat 和 worker 也不会把拒绝投影为成功。
具体改动
repository_delivery.py：capture_repository_delivery_baseline/prepare_repository_delivery_claim复用统一的 clean-workspace 与 live-default 读取；validate_repository_delivery新增 baseline object 和 strict-descendant 校验，并在 typed receipt 中同时记录 baseline、delivery commit、workspace commit 和 default branch。todos.py、cli_commands/todo.py：todo claim传入真实 execution cwd；write-scoped claim 失败时保持 Todo 未认领。已有同一 owner 的 claim 可重入并补齐 baseline，handoff 保留 lineage；clear claim 清除 baseline。contract.py、line_update.py：baseline 使用完整小写 40/64 位 OID 的 typed codec；Todo 的 text/role/task class/action/repository/write scopes/capabilities 等交付规格变化会使 baseline 失效，避免旧 receipt 授权新任务。completion_validation.py、completion_transaction.py：baseline 纳入完成证据和 source snapshot，锁外 validation 与锁内提交绑定同一交付规格。event_sourced_state.py及 list/quota/summary projections：baseline 在 Markdown、事件投影和 compact read model 中保持，不依赖私有 sidecar；文档补充先 claim、后 complete 的迁移与操作要求。- 全 PR 的既有 surface 仍覆盖 CLI/Turn/Chat/Auto Research 的 delivery commit 透传和 typed rejection；26 个 changed files 均已纳入复审。关键行为符号包括
todo_requires_repository_delivery、prepare_repository_delivery_claim、validate_repository_delivery、run_completion_validation_gate_with_source和locked_todo_completion_transaction。
对主干的风险
主要兼容性变化是：已有 write-scoped Todo 若只有 claimed_by 而没有机器 baseline，会 fail closed，需要从 clean remote-default checkout 重新执行同 owner 的 todo claim；文档已明确披露，这比静默接受旧状态安全。baseline 证明的是“交付提交发生在 claim 之后并触及声明 scope”，不是业务语义证明；scope 过宽时仍需 reviewer 检查提交与 Todo 的实际对应关系，但这不再允许上一轮的 pre-Todo 历史提交绕过，且没有新增调用方可写 baseline 的 CLI/host 字段。
typed-state lens 通过：task class 继续使用现有 normalizer，baseline/OID/status 都有 typed codec/receipt；domain-neutrality 通过；默认行为变化已在 docs 和回归中披露；这里是机器强制 completion obligation，没有把 hard gate 写成 guidance。future-facing pass 也合适：规则留在既有 Todo repository-delivery authority，claim 与 completion 复用同一 workspace helper，没有第二状态机或 speculative facade。
验证：我逐文件复核全 PR 和当前 498-line blocker-repair delta；changed-surface Ruff 与 git diff --check 通过。exact-tree focused run 中 146 项通过，63 项因当前仓库保护时段的全局 Git hook禁止测试夹具创建临时 commit 而未能独立执行，属于明确的环境 hold，不是断言失败；exact-head GitHub 的 DCO、Dependency Review、Linux pytest、Windows lifecycle、Pages/Release build 与 Sonar checks 均成功或预期 skipped。远端 head 在发布前再次确认为 c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c，PR 可合并但仍因既有 review state 显示 BLOCKED。
我的整体评价
批准。当前 head 用 machine-owned claim baseline 和 strict descendant 规则直接修复了上一轮的 Todo-lineage blocker，同时保留 origin、clean tree、live remote、write-scope、validation 和锁内 CAS 的 fail-closed 组合。变更量较大，但各 surface 都服务同一 repository-delivery completion contract，并有完整正负路径与投影覆盖；未发现新的阻塞问题。本结论只批准 exact head，不授权合并。
English verdict: APPROVE on exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c. The prior blocker is resolved: todo claim records a machine-owned live-default baseline, and completion accepts only a scope-matching delivery commit that is a strict descendant of that baseline and remains in workspace/remote ancestry. Ruff and diff hygiene passed; 146 exact-tree focused tests passed while 63 Git-fixture tests were independently blocked by the active repository change-window hook, and all applicable exact-head GitHub checks are green. No blocking findings; merge authority remains separate.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次复审锁定 exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c。PR 希望阻止 write-scoped Todo 在代码没有真正交付时被写成 done，这个问题方向成立；但当前 PR 没有关联 issue，也没有给出该失败的发生频率、影响范围、人工恢复成本或多个真实复现。缺少这些收益证据时，不能仅凭“门禁逻辑现在严密、测试和 CI 通过”判断它值得进入主干。
改动思路
当前方案把仓库交付证明扩展成一条跨生命周期协议：claim 时捕获机器拥有的远端默认分支 baseline，complete 时要求调用方提供 exact delivery commit，并验证 strict descendant、origin、clean tree、workspace/remote 双 ancestry、write scope、validation 与锁内 CAS。CLI、Turn、Chat、Auto Research、Markdown/event projection 和 compact summaries 都接入这一协议。正向和负向路径本身已做得较完整，但“完整实现这套方案”不等于“这套方案是解决原始问题的最小、可维护方案”。
具体改动
当前 exact head 涉及 26 个文件、+2532/-114：新增 repository_delivery.py 553 行，test_todo_completion_validation.py 增加 1198 行，并修改 Todo claim/completion transaction、state codec/projection、CLI/Chat/Turn 和 Auto Research caller。首个提交已经是 +852/-6；后续 review 发现 typed-class 绕过、clean-main no-op、历史 commit 冒充交付等真实缺口，又分别增加了约 +608/-60 和 +498/-80 的机制。每一轮都修好了上一条 blocker，但也让生产协议和维护面继续扩大。
这正说明需要从原始问题重新设计，而不是继续在当前机制上补洞。请先给出可复现的问题频率/严重度与最小不变量，并证明为什么不能在现有 completion/writeback 边界用更窄的 delivery receipt 或 reconciliation 规则处理；如果 claim baseline、全 caller 透传和持久化投影确实不可省略，再用这些证据支撑范围。否则应删除、拆分或重做为最小可行修复，而不是继续扩充当前分支。
对主干的风险
[P1 blocker] 当前收益—复杂度比例尚未成立。它为一个缺乏规模证据的假完成 case 新增跨 claim、completion、CLI 和状态投影的硬协议，并改变所有 write-scoped advancement Todo 的默认完成与迁移行为。长期成本包括新增状态 lineage、旧 Todo 缺 baseline 时的 fail-closed 迁移、多个 caller 的参数和失败传播，以及大量 Git/远端边界测试维护。绿色 CI 只能证明实现自洽，不能证明这些成本值得支付；此前 reviewer 要求的修复也不能自动形成“接近批准”的轨迹。
最小修复要求不是再加一条校验，而是先重置 scope：以原始失败为基线比较一个更窄的 completion-bound 方案、当前 claim-baseline 方案和暂缓/人工恢复方案，保留能关闭已证实 failure mode 的最小生产 surface，并删除其余机制。需要一个回归证明“窄方案仍会失败、当前额外 surface 才是必要条件”，否则维持阻塞。
我的整体评价
结论为 REQUEST_CHANGES。当前实现的 typed-state、TOCTOU、origin/ancestry 与正负测试质量不差，之前发现的具体漏洞也确实被修复；问题是 review 一直在优化方案完整性，没有持续验证方案是否值得存在。以现有证据，change_proportionality=not_yet_proven，属于 verdict blocker。请停止在当前架构上继续补代码，先缩小或重新论证范围。
English verdict: REQUEST_CHANGES on exact head c64ba1a3081d8bbb7c931c74dbf82ccde6cc510c. The implementation is coherent and well tested, but the original failure's frequency, severity, and recovery cost are not evidenced enough to justify a 26-file, +2532/-114 cross-lifecycle claim/completion/state/CLI protocol. Correctness, green CI, and closure of earlier implementation findings do not resolve this proportionality blocker. Reset from the original problem and reduce, split, or prove why the added production and maintenance surface is necessary.
Require turn-scoped agent advancement completion to consume matching durable writeback and quota spend receipts. Reject dirty repository worktrees at the existing quota workspace guard while leaving local control-state files and explicit non-delivery continuations unchanged. Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com> Co-authored-by: TRAE CLI <noreply@bytedance.com>
Document that accountable Git delivery must settle from a clean worktree and that turn-scoped advancement completion consumes matching writeback and quota spend receipts. Explicitly avoid claiming mainline or pull-request proof. Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com> Co-authored-by: TRAE CLI <noreply@bytedance.com>
c64ba1a to
be9ce57
Compare
|
@huangruiteng 请复审 exact head 动机本轮按上一条 改动思路当前 main 已经拥有 typed settlement identity、durable writeback、quota spend、delivery workspace causality 和 workspace matching。新 head 只复用两个现有 owner：
具体改动
对主干的风险当前 head 为 6 文件、 它只关闭已证实的 dirty-worktree false completion，并把 turn-scoped advancement 的状态变更后置到已有 receipt chain；不声称证明 mainline ancestry。若未来有数据证明还需 Todo-specific commit lineage，应作为独立 issue/PR 论证，而不是在本修复中预埋。 验证
我的整体评价自审结论为 APPROVE。typed-state 使用现有 task-class normalizer 与 settlement readback；规则 domain-neutral；默认变化已披露为 machine-enforced obligation；future-facing pass 通过删除平行机制完成，没有新增抽象。作者身份无法正式 self-approve，也无 English verdict: APPROVE on exact head |
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
这个 PR 想修复一个真实且重要的控制面漏洞：agent advancement Todo 不应在没有同一 turn 的 validated writeback 与 quota spend receipt 链时被标记完成；同时，Git 交付的 quota 结算应来自负责该次交付的 worktree。这个方向能防止“只改 Todo 状态、没有完成可追责交付”的假完成。
改动思路
实现分成两层。loopx/cli_commands/todo.py 通过 _completion_settlement_requirement 和 _completion_settlement_error，把 agent advancement completion 纳入 settlement 要求，同时豁免 same_agent_non_delivery、monitor、user action/gate 等非交付生命周期；handle_todo_command 在 turn-scoped completion 前读取 durable Todo，并按普通 completion 或 --no-follow-up 选择对应 settlement readback。loopx/control_plane/agents/workspace_guard.py 则新增 _git_worktree_is_clean，在 quota spend 时重新检查整个 worktree（排除 .codex/**、.loopx/**），把 dirty worktree 判成阻塞。文档与三个测试文件同步补充了该契约和局部覆盖。
正向路径的意图是：agent 在匹配的 Todo/turn/worktree 上完成验证与 durable writeback，quota spend 取得完整 receipt，随后 Todo completion 成功并回传 settlement result。负向路径的意图是：缺 receipt、foreign worktree 或 dirty worktree 时 fail closed，不能完成或花费 quota。
具体改动
docs/project-agent-todo-contract.md说明 accountable Git delivery 的 clean-worktree 条件，以及 advancement completion 必须先完成 receipt-backed settlement。loopx/cli_commands/todo.py增加 task class / continuation policy 的 typed 判定，并把非 terminal advancement completion 也接到 settlement gate。loopx/control_plane/agents/workspace_guard.py用git status --porcelain=v1 --untracked-files=all实时判断 worktree 是否干净，并将失败原因统一投影为 clean-workspace requirement。tests/control_plane/test_delivery_workspace.py覆盖 untracked file 会阻塞、.codex/**状态文件不阻塞；test_quota_settlement.py覆盖 advancement receipt requirement 与 non-delivery exemption；test_quota_settlement_cli.py调整已有 fixture 以声明 non-delivery 路径。
对主干的风险
[P0] spend 时对整个 worktree 再做无差别 clean 检查，会拒绝正常且已经通过验证的交付流程
当前精确 head be9ce57854836bbd638eb4a70f7e0cec8560d2e2 的 GitHub pytest 为 14 failed, 4850 passed, 12 skipped。失败并不只来自一个旧 fixture：terminal settlement tool、autonomous replan、Turn driver/e2e 和 MCP completion 等多条产品路径都在 validation 已通过后得到同一个失败：quota spend requires the clean workspace that produced the latest unspent accountable delivery，最终 quota_spent=false。
根因是 _git_worktree_is_clean() 在 spend 时重新扫描所有 tracked/untracked 产品文件，但正常 Turn 会在 refresh/validation 与 spend 之间生成或保留本次交付的受验证输出；这些输出让 worktree 变 dirty，于是新的 guard 把合法 settlement 当成 workspace drift。换言之，代码检查的是“spend 瞬间整个目录无差异”，而不是“spend 对应于已验证、可追责的 workspace snapshot / declared delivery output”。这与当前 Turn 和 terminal tool 的调用顺序不兼容。
请把 clean/causality 约束绑定到 accountable validation snapshot（例如记录被验证的 Git state 与允许的 declared/generated delivery outputs），或者显式区分本次交付产物与无关漂移，不要在 spend 时对整个 worktree 做无差别重判。修复后需要补齐并跑通 Turn e2e、terminal settlement tool、autonomous replan 以及 MCP completion 的 parity 回归；目前 MCP 失败返回还缺少调用方预期的 completed shape，说明 CLI-only gate 尚未保持各入口的生命周期一致性。
我的整体评价
receipt-backed advancement completion 的产品方向正确，typed task class / continuation policy 的边界也比基于文本的分类可靠；但 clean-worktree 的实现把“交付因果性”收紧成了一个与现有产物生命周期冲突的瞬时目录状态条件，因此目标问题尚未被安全解决，并造成 quota/Turn 热路径的广泛回归。本次结论为 REQUEST_CHANGES，该 head 不应合并。
验证：完整阅读 6 个 changed files 与关键符号；核对精确 head；检查 GitHub 全量 pytest 失败（14 failed）；并独立运行 delivery workspace / quota settlement / quota settlement CLI 聚焦测试，复现了 autonomous-replan settlement 被新 clean-workspace gate 拒绝。另有两项本地 fixture commit 因仓库保护窗口无法创建，不作为本结论依据。
未来向 scope-fit：值得保留的相邻重构，是把 workspace identity、validated snapshot 与 spend causality 收敛为同一个 typed contract；不建议继续在多个 CLI / MCP 入口分别追加例外。
English verdict: REQUEST_CHANGES at exact head be9ce57854836bbd638eb4a70f7e0cec8560d2e2. The new spend-time whole-worktree cleanliness check rejects valid, already-validated Turn, terminal-tool, autonomous-replan, and MCP settlement flows; GitHub pytest has 14 failures. Bind causality to the accountable validation snapshot or explicitly declared delivery outputs, then restore parity coverage across all completion entry points.
Remove the spend-time whole-worktree cleanliness check because validated Turn outputs legitimately remain in the delivery workspace. Keep receipt-gated advancement completion, return its blocker in a typed CLI shape, and make compatibility MCP fixtures explicitly non-delivery. Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com> Co-authored-by: TRAE CLI <noreply@bytedance.com>
|
@huangruiteng 请复审 exact head 动机上一轮 exact-head Linux CI 的 14 个失败证明：在 quota spend 时无差别重新要求整个 Git worktree clean，会把已验证但仍保留本次 Turn 输出的合法流程判为 drift。这个约束与现有 改动思路保留最小且与既有 settlement owner 一致的不变量：turn-scoped agent advancement Todo 只有在同一 Todo/turn 已具备 durable writeback 与 quota-spend receipts 后才能完成。workspace guard 恢复为 main 已有的 repository identity / worktree-kind 因果检查；它不再把 spend 瞬间的全树 cleanliness 当作 delivery provenance。 兼容 host/MCP 的既有 transaction 是 具体改动
对主干的风险当前 diff 为 7 文件、 验证
我的整体评价当前结论为 APPROVE pending exact-head CI。P0 的 spend-time whole-worktree regression 已直接移除；值得保留的 receipt gate 位于现有 Todo/settlement owner，typed-state、domain-neutrality、默认行为披露和 guidance-vs-obligation 均已复核。作者身份无法正式 self-approve，请 owner 在 CI 绿后复审。 English verdict: APPROVE pending exact-head CI on |
|
@huangruiteng exact head Exact-head CI is fully green. The invalid spend-time whole-worktree gate is removed, all 14 prior failure points pass locally, and the retained receipt-backed completion fence has 189 adjacent regressions passing. Please re-review this exact head. |
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
动机
本次复审针对精确 head f641a51605763d411b200f38f9c4c1688061a24b。PR 要解决的是 agent advancement Todo 的假完成：仅有 Todo 状态变化并不足以证明同一 turn 已产生 validated durable writeback 并消费 quota。上一轮 head 又把这一目标错误实现为 quota spend 时重扫整个 worktree cleanliness，导致已经完成验证、但仍保留合法 Turn 输出的 terminal、autonomous-replan、Turn 与 MCP 路径被误拒绝。当前 head 删除该错误门禁，将目标收敛为现有 settlement receipt 能力真正能够证明的 completion ordering。
改动思路
权威边界放在 todo complete 的既有 CLI/settlement owner 中。_completion_settlement_requirement 先用 typed task-class 与 continuation-policy contract 判断当前 Todo 是否属于需要结算的 agent advancement；_completion_settlement_error 再检查同一 goal/agent/todo/turn 的 settlement readback。只有 durable writeback 与 quota spend receipt 链完整时才进入 complete_goal_todo。显式 same_agent_non_delivery、monitor、user action/gate 等非交付生命周期保持原路径。
正向路径是：quota guard 建立 settlement identity → bounded work 完成 validation 与 durable writeback → 同一 identity 花费 quota → todo complete --turn-instance-id 读取完整链并提交 completion。负向路径是：advancement 通过兼容 MCP/host transaction 在 receipt 形成前请求完成；CLI 返回 typed blocker（completed=false、changed=false、matching settlement identity），Todo 保持 open。workspace guard 仅继续校验 repository identity/worktree kind，不再把 spend 瞬间的全树状态误当作交付因果性。
具体改动
loopx/cli_commands/todo.py增加 receipt-backed advancement completion admission，并在失败时返回可被 CLI/MCP 调用方稳定消费的 typed payload；成功后仍通过现有 readback 投影最终 settlement result。loopx/control_plane/agents/workspace_guard.py撤回 spend-time whole-worktree clean 检查及其错误文案，恢复已有 repository/worktree 匹配语义。docs/project-agent-todo-contract.md披露 advancement completion 的 machine-enforced receipt obligation，并明确旧式 host adapter 只有在显式 non-delivery 时可沿用 completion-before-refresh/spend 顺序。tests/control_plane/test_quota_settlement.py与 CLI suite 覆盖缺失/完整 receipt、typed exemption、Turn、terminal 与 autonomous-replan parity；两个 MCP suite 将兼容性 fixture 标为 non-delivery，并新增真实 advancement 缺 receipt 时 fail closed 的完成级回归。
关键代码讲解
_completion_settlement_requirement复用normalize_todo_task_class和normalize_todo_continuation_policy，没有引入 substring denylist 或第二套状态分类；agent advancement 默认进入门禁，typed non-delivery 才退出。_completion_settlement_error只消费QuotaSettlementReadback.settlement的 typed failure，不重新解释日志、worktree dirty state 或调用方证据。handle_todo_command在 blocker 分支不调用complete_goal_todo，而是返回带settlement_blocked_completion、identity、receipt failure 与稳定完成字段的结果，因此 Todo 状态和调用方协议保持一致。build_delivery_workspace_guard继续验证当前 repository/worktree 与 accountable delivery workspace 是否匹配，但不再把本次 Turn 的已验证输出误判为 drift。
对主干的风险
未发现剩余阻塞项。该 PR 有意改变 turn-scoped agent advancement Todo 的默认完成时序，属于 quota/Todo 热路径，但变化已在文档中明确为机器强制义务，且 typed exemption 保留了 monitor、user lane 与明确 non-delivery 兼容性；核心错误不再通过 fixture 例外或扩大 ignore 掩盖。当前 scope 为 7 文件、+263/-45，相较旧的 Git-lineage/claim-baseline 方案已收敛为现有 settlement owner 内的单一规则，没有新字段、CLI flag、ledger 或平行 authority。
独立验证：五个相关 settlement/CLI/MCP suites 得到 126 passed；最初 archive/shared-clone 的两项 repository-identity 假失败在将临时 clone 的 origin 恢复为真实 GitHub identity 后均通过。changed-surface Ruff、compileall、git diff --check 均通过；远端 exact-head Linux pytest、Windows lifecycle、DCO、Dependency Review、build 与 Sonar 检查全部 green。未独立重跑整个仓库 pytest，完整 Linux/Windows 覆盖由 exact-head CI 提供。
我的整体评价
结论为 APPROVE。上一轮 P0 已通过删除错误的 spend-time whole-worktree cleanliness gate 直接关闭，而不是修改 14 个失败路径来适配错误约束。保留下来的 receipt fence 与已有 settlement identity/readback authority 同域、可回滚且具备正负路径 parity；typed-state、domain-neutrality、默认行为披露、guidance-vs-obligation 与 change proportionality 均满足。future-facing scope pass 认为无需再加抽象；若未来需要证明 commit/PR/mainline lineage，应以独立问题和证据另行设计。
English verdict: APPROVE on exact head f641a51605763d411b200f38f9c4c1688061a24b. The invalid spend-time whole-worktree cleanliness gate is removed, while the remaining typed receipt-backed advancement completion fence fails closed consistently across CLI/MCP paths. Independent validation: 126 focused tests passed; Ruff, compile, and diff hygiene passed; all applicable exact-head CI checks are green.
2 participants
Summary
same_agent_non_delivery, monitor, user-action, user-gate, and unscoped lifecycle paths.Why this is the minimum
The confirmed failure involved an advancement Todo marked complete before the accountable writeback and quota-spend chain existed. Current
mainalready owns typed settlement identity, accountable writeback, quota spend, workspace causality, and delivery-workspace matching. This rewrite reuses those owners instead of adding claim-time baselines, caller-supplied delivery commits, remote/default-branch ancestry rules, Todo metadata fields, projection expansion, or caller-specific plumbing.This PR intentionally does not claim that a workspace receipt proves a particular commit or pull request reached
main, and it does not treat a dirty worktree at spend time as a generic settlement failure. That stronger delivery-provenance contract is deferred unless frequency/severity evidence proves it necessary.Validation
189 passed;4 passed;git diff --check: passed;18/18passed, zero failures, warnings, or manual holds;Windows lifecycle, DCO, dependency review, Pages/release builds, and SonarCloud.
Scope comparison
+2532/-114, including a 553-line Git verifier and claim-baseline state/projection protocol;+263/-45, no new state field, CLI flag, capability, caller plumbing, or Git ancestry protocol.Future-facing pass
Applied by deletion: completion remains in the existing Todo/settlement boundary, while the invalid spend-time whole-worktree cleanliness rule was removed after parity tests proved it conflicted with existing Turn output lifecycles. No parallel source of truth or speculative compatibility layer remains.