Repository navigation
feat(freshness): bind work reads and recover original-Turn settlement - #5677
xyx2002OvO wants to merge 63 commits into
Conversation
There was a problem hiding this comment.
Author validation correction — previous APPROVE conclusion withdrawn
此前由改动作者发布的 APPROVE 结论撤回。作者自检不能替代独立评审;基线复现只能说明失败来源,不代表当前 PR 的红色检查已经处理完成。
当前交付仍有两项未完成:处理 CI 失败并验证修复;获得独立评审。此前列出的本地通过项仍是验证证据,但不构成批准、完成交付或合并授权。PR 保持未合并。
This comment replaces the author's earlier approval conclusion. It records author validation only, not an independent review or approval. CI failures still need remediation and verification, and independent review remains outstanding. No merge is authorized by this comment.
Original reviewed head: a87ee49. The earlier validation record remains in the PR description; its baseline-failure attribution must not be read as resolution.
a87ee49 to
1e47484
Compare
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh
动机
长程执行中先完成结果、再决定下一步的 Agent 和读取进展的操作者。 以前执行期间新增要求可能没有进入原方向判断;现在结果先保留,再读当前要求重判,新增任务会拒绝旧方向而不重复已完成工作。 两个隔离 Goal、工程和研究四类注册 Agent 的实际 File/SQLite 调用保留了结果及同伴证据;新增任务使旧方向失效,拒绝时没有追加或扣额。 本轮不验收完整 Goal、长期模型收益、已安装 App、源机会话或新权限。 新功能的完整界面操作、真实模型效果和持续效率仍未验收;本次两个回归先由本 PR 修复。
“当前方向”是读完结果后的下一步判断,不是新的实施工作。本次独立验证支持这个有界收益,但关闭态读回出现回归,不能据此批准整个精确 head。
改动思路
入口是显式 --first-delivery 或 MCP first_delivery=true。实现前读结果依据,普通结果由现有 Todo CAS 提交;之后重新读方向依据并调用一次独立 Host,只能返回方向字段。TypeScript 比较真实 authority、依赖、lease、Goal/Agent/Turn 及相关 frontier,Python 负责 IO 和已有 journal 的恢复。模型推理在 provider/source 锁外;方向变旧时重判,成功结果及原扣额回执保留。需要终结的路径还检查提交后的全 Goal 方向,新增任务不能被旧的 no-followup 吞掉。
这比把旧 Vision 换上一个新 read ID 更可靠,也比重做实施节省重复工作。新的 read ID、用户选择与 Vision 判断属于不可推断的意图;进展显示从已有 Todo、run、spend 回执推导,不能另存一个成功布尔值。共用 checkpointProviderFacts、原 CAS/receipt 和 settlement owner 是合适的边界。MCP v0/v1 和旧 supplement 有真实持久消费者,需要保留,但共享 observer 必须隔离坏文件。
具体改动
完整 merge-base 6bfa358d3bced7f8b1effa4468adfbea0bce8dec → 772f442fcc0a17f9176695431a9e11526d626996,57 文件 +1932/-183;包括 CLI、MCP、managed executor、shared status/quota、File/SQLite fence、文档及验证。远端 base tip 已向前移动,不能把两 tip 的无关差异算成本 PR。本次看完整提交和 diff,不继承作者的自评或大测试数字。
独立规范是 docs/reference/protocols/goal-vision-replan-contract-v0.md,spec_revision 6bfa358d3bced7f8b1effa4468adfbea0bce8dec。Vision Checkpoint:本轮结果/新工作边界已实现;Read basis for checkpoint-only recovery:原身份和 real fence 路径通过,普通关闭态规则因下面 P2 不满足;Semantic History Continuity:成功重放、方向失效和 unknown 不能自证 Goal 完成,已核验。新文档的 first-delivery 承诺没有反过来充当自己的验收标准,整体 roadmap 与真实模型运营验收保持 open。
关键代码讲解
checkpointBasisSnapshot(checkpoint_read_context.ts:44):明确区分 result 与 direction,方向重新计算完整相关 frontier,其他 Agent 的独立工作不会进入自己的 lane;共享要求和相关依赖仍进入依据。terminalDeliveryBasisCheck(todo_delivery_context.ts:45):在最终 canonical head 上核对结果 token,重放先读原回执,必要的 terminal 还核对 indexed direction 与当前 frontier;CAS 重试保留同伴更新。prepare_first_delivery(direction_review.py:21):普通结果先提交再推理;异常保留原 Turn 和成功结果。方向最多两次推理,持续变化进入明确恢复,不能无限空转。Codex 路径新建临时 read-only 调用并去掉本次注入的 LoopX MCP;通用 Host 仍是受信任执行边界,未实测额外全局工具隔离。pending_first_delivery_progress(checkpoint_context_io.py:120):新 observer 扫描所有历史 JSON,先解析后按目的/Agent 过滤,异常直接泄漏到普通 status,形成下面的关闭态回归。
对主干的风险
[P2,阻塞] 把历史 receipt 损坏限制在观察范围。 在没有 first-delivery enrollment 的隔离 Goal,给 checkpoint-contexts 放一个正确摘要命名、内容损坏为 { 的历史 receipt。实际 File 和 SQLite status --goal-id … --agent-id …,base 两次 exit0/ok=true,head 两次 exit1/ok=false,完整错误为 Expecting property name enclosed in double quotes: line 1 column 2 (char 1);健康和旧 supplement 三组配对均通过。原因是 checkpoint_context_io.py:123–127 在 purpose/agent 判断前无保护地 json.loads,共享 collector、quota 和 bootstrap 都新增调用。一个与本次功能无关的旧文件现在可让普通进展读回失败;损坏不可被解释为“没有待恢复工作”,也不应该让其他 lane 失去状态。最小修复是在既有 observation owner 校验/隔离不完整读回,以 scoped unavailable/unknown 保留错误,同时让无关关闭态工作仍可读取;实际已 enrolled 的不确定提交继续 fail closed。补上 File/SQLite、其他 Agent、未启用和已启用 crash 的反向测试,不能只把全局异常吞掉。
[P2,阻塞] 恢复跨换行的生成一致性。 turn_contract_generated.py:3 和 .ts:3 把 SHA 改成 252c7ea…,但 canonical JSON 没改。独立复算 LF source 为 18404665…,把同一字节内容改成 CRLF 恰好得到 252c7ea…。相同 uv run --extra test python scripts/generate_turn_contract.py --check 在固定 base 通过、head 拒绝两份 stale artifacts;原生 semantic smoke 也因此失败。生成器按 raw bytes 算摘要,使 Windows 生成头无法在 LF checkout 满足当前检查。请固定 canonical newline/内容摘要并重新生成,或明确强制源的 LF 边界;同时在 LF/CRLF 输入上验证语义相同的生成结果。只保留 Windows 的绿色记录不解决这个 portable gate。重新跑 generator --check 以及 uv run --extra test loopx canary smoke-suite --script semantic-vocabulary-drift-smoke.py。
独立实际验证:head 181 Python pass,含 File/SQLite 进程写锁和 before-artifacts/after-json/after-markdown/after-index 崩溃、managed 单次实施/方向重判/失败恢复、MCP 结果→方向→一次扣额与新增任务 terminal 拒绝。固定 base 139 pass/7 fail:6个 MCP fixture 缺 connected-delivery 在 guard 被拒绝,另1个无 Vision replan 原 oracle 错误;head 修改对应 fixture/区分 missing-Vision obligation 后通过,未放宽产品 gate,新增未连接负例保留。它们是基线验证差异,不是本轮 7 个新回归。
TS focused 84 pass/15 PostgreSQL skipped;随后在一次性真实 PostgreSQL 16.2 跑 authority store/archive、lease、acceptance、delegation,共 441 pass/0 skip,补齐 shared terminal CAS 的实际 PostgreSQL 兼容检查。新 first-delivery 本身仍只支持 File/SQLite。TS typecheck、changed Ruff、diff check 和三个 UI contract 用例通过。语义 advisory 先执行(没有受支持的 carrier 候选,并不等于无新语义),完整 semantic smoke 的生成失败保留,未扩大预算。
独立另外走实际 CLI 的工程/研究两个 Goal、四个注册角色:peer update→自己的 result CAS 保留 peer evidence,方向读到 selected done,自己的 lane 排除 peer;后加入新的自己任务,旧 direction 返回 stale/frontier,无新 run/扣额,已提交结果仍 done、新任务仍 open。这些是 isolated authority/确定性 Host 验证,不是活动 Goal 改写或真实模型效果研究。最初 probe 给 agent todo add 带了不支持的 --agent-id,合法拒绝;改成已有 --claimed-by 后才采用结果,没有修改生产 parser。
界面改动只增加既有投影的 contract 检查;本轮没有重跑 packaged viewport/native App、Lark 外部写入或完整交互,也没有实测 Codex 模型或长期吞吐。CLI/MCP 新能力的完整可发现/可操作前端仍由现有展示 owner 验收,不能用这三个静态测试替代。历史 context 全量扫描和逐身份 settlement 读取有累积成本,尚未测量规模曲线;建议本次 observer 修复复用完整当前状态的一次读取,避免再加平行状态或静默截断 pending 工作。
语义与 CI 对齐
结果/方向 purpose、阶段和 v2 request 是已有 checkpoint/host owner 的本地显式扩展;没有创建新的 actor 生命周期或授权。receipt/schema/decision 必须由机器核对;direction-only 的操作禁令对通用 Host 仍是指令,不能叫作工具权限隔离。关闭态 observer 回归和 generated owner 不一致违反当前隔离/生成契约。按本 Goal wait_for_ci=false,未查询、轮询或等待远端 CI;本地通过、失败和未测分别保留。
我的整体评价
REQUEST_CHANGES。long_horizon=regression,user_experience=regression。 成功结果保留和原 Turn 恢复的有界收益成立:减少丢回复后的重复实施,新增任务能纠正旧方向。代价是正常路径多一次方向推理,发生 stale 时最多再一次;这是实际调用数量,不是净 token 或吞吐收益。关闭态 status 被旧文件击穿、跨平台 generation 失败修复前,整个 head 对持续运行和可用读回仍有负向影响,不能给批准。
future-facing pass 已核对共用 provider facts、CAS/receipt 与 typed decision owner;最小相关修复是 observer 的错误/枚举边界及 canonical generation。历史扫描规模优化可随同边界验证后收敛,不能只截断数据或增加一个人工同步成功字段。保留实际前端、真实模型收益和持续效率证据缺口,不新建平行路线图,不合并、dismiss 或升级本机。
English verdict: REQUEST_CHANGES — exact head 772f442. Two blocking P2 findings: malformed historical contexts break ordinary feature-off status on both real File/SQLite, and CRLF-derived generated hashes fail the LF native generator/semantic gate. Core staged recovery is supported by181 Python tests,441 isolated real PostgreSQL compatibility checks,84 focused TS passes and independent two-Goal/four-role authority walks. Extra direction inference and accumulated observation costs prevent a net long-run efficiency claim; packaged UI, live models and installed behavior remain unqualified.
| """Bounded to this Agent's enrolled local Turns; readback, never admission.""" | ||
| identities = {} | ||
| for path in (root / "goals" / goal_id / "checkpoint-contexts").glob("*.json"): | ||
| receipt = json.loads(path.read_text(encoding="utf-8")) |
There was a problem hiding this comment.
[P2] Keep malformed historical observations from breaking ordinary status
With first_delivery disabled, one malformed digest-named historical context makes the real status CLI exit 1 on both File and SQLite. The same fixed fixture exits 0 at the merge base. This JSON parse runs before purpose and Agent filtering, and the shared collector invokes it unconditionally.
Validate and contain this readback in the existing observation owner. Report scoped unavailable or unknown evidence while keeping unrelated disabled lanes usable. Preserve fail-closed handling for actual enrolled uncertain appends. Add both-provider disabled/other-Agent negatives alongside the enrolled crash/replay positives.
| """Generated by scripts/generate_turn_contract.py; do not edit. | ||
| Source: loopx/control_plane/turn_loop_controller_contract_v0.json | ||
| SHA256: 184046656dada524b5412be128424b840dc1d490eef5bf8a0c9e9e5bb786492a""" | ||
| SHA256: 252c7ea204f59809779aa2fed4a7998d5b0579d46bb141bd95f3711553b750c4""" |
There was a problem hiding this comment.
[P2] Keep the generated Turn digest independent of checkout newlines
The unchanged canonical JSON hashes to 18404665… in LF form. Replacing its newlines with CRLF produces exactly the committed 252c7ea… header. Consequently generate_turn_contract.py --check passes at the fixed base but rejects both generated files at this head; the native semantic smoke fails too.
Use canonical newline/content hashing or enforce the source LF boundary, regenerate both artifacts, and validate equivalent LF/CRLF source content. Rerun the native generator and semantic smoke; a Windows-only passing receipt does not satisfy this portable check.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
772f442 to
cd8a5a7
Compare
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent — gpt-6.1-sol (OpenAI); runtime_reported; reasoning_effort=xhigh
Exact reviewed head: cd8a5a7; immutable baseline: 9e78309
动机
先完成工作、再判断下一步的长程 Agent,以及查看当前进展和恢复失败的操作者。
执行后要求变化时,旧判断可能继续沿过期方向;这个提交先保存已验证结果,再读取当前要求,拒绝过期方向时保留结果,不重复实施。
实际 File/SQLite 两个工程与研究 Goal、四类角色保留同伴证据;新增任务使方向失效,拒绝时没有追加或扣额。临时 Codex 方向调用的三类失败却删除原实施会话绑定,后续 resume 失败。
本轮不验收完整 Goal、已安装 App、外部 Lark、真实模型效果或长期吞吐。
这项分段机制有实际用途:要求变化不应抹掉已经完成的结果,也不应逼迫 Agent 重做实施。当前提交修复了上轮历史坏 JSON 导致未参与角色 status 失败、生成文件 CRLF 校验误报两项问题。但新的临时方向调用仍能破坏原实施会话,暂不能交付为可靠的长程恢复能力。
改动思路
复用现有 Todo、checkpoint 和 Turn journal,而不是另建目标或 worker。实施前读取当前要求、完整相关任务和 provider fence,终态结果以带读取依据的 CAS 写入原 Todo;随后一次新方向调用只提出后续判断,refresh 再核对当前来源,最后由原 settlement 扣额。结果、方向、checkpoint 和 spend 是不同阶段;某阶段拒绝不等于前面的产物丢失,也不等于整个 Goal 已完成。
读取身份和 result/direction purpose 是无法从其它记录猜出的调用意图;任务版本、frontier、当前进展则从 canonical 状态生成。commit-attempt journal 是崩溃后辨认既有副作用的事实,不是第二份手动维护的 Goal 真相。Python 负责 host/filesystem IO,TS 的既有 checkpoint/Todo owner 负责依据、范围和终态规则。旧 persisted supplement 与独立 MCP v0/v1 消费者仍有读取用途,不能为了减代码直接删掉。
正向路径已沿真实隔离 authority 走到结果保存、同伴更新、新任务加入和拒绝过期 refresh;结果和同伴证据都保留。Codex 方向调用用新 session、read-only sandbox,并去掉本次注入的 MCP server;这不证明任意 provider 或全局工具配置的隔离。当前缺陷是它的错误清理仍指向原 Todo 的持久实施 session。
具体改动
完整 base-to-head 为 58 文件 +2106/-181:38 运行时、16 测试、2 文档、2 构建/生成配置;读取了全部 diff、涉及的生产文件和未改动调用方。本轮没有只继承旧评审结论。历史坏 receipt 现在产生 observation_unavailable 警告,未参与角色的合法下一步保持;已参与但来源不全的原 append 仍拒绝。生成器对读取、hash 与解析统一换行,LF/CRLF 都可用,真正内容改变仍会被发现。
依据既有 docs/reference/protocols/goal-vision-replan-contract-v0.md,spec_revision 9e78309,没有用本 PR 新写的规范替代独立验收:
- Vision Checkpoint:implemented,结果与目标结论分开,refresh 要求当前 Vision 或 unchanged reason;实际拒绝与恢复套件覆盖。此 PR 不关闭整个产品/接收方采用验收。
- Read basis for checkpoint-only recovery:implemented,原 Turn 身份、相关完整来源与有 fence 的 append 保留;File/SQLite 多角色实测显示同伴无关更新不改变自身任务范围、新相关工作能使方向失效。
- Semantic History Continuity:implemented,status 报告阶段及来源不足,旧 receipt 的存在不冒充 Goal 完成;历史坏数据不截断全部 status。完整 frontend、source-session enrollment、其它 provider 和实时模型采用仍按已声明阶段边界保留缺口。
关键代码讲解
checkpointBasisSnapshot(loopx/control_plane/goals/checkpoint_read_context.ts)从 canonical 要求、相关 Todo/frontier、provider fence 构成读取依据;不是靠列表显示前几项证明没有工作。terminalDeliveryBasisCheck(loopx/control_plane/coordination/todo_delivery_context.ts)在现有终态写入 owner 核对依据;result 写已验证产物,direction 不能绕过终态检查。prepare_first_delivery(loopx/control_plane/turn_driver/direction_review.py:21)给真实 run-once 入口准备分段调用,保留原 Turn 的 journal/恢复身份;不是只有 serializer 可达。pending_first_delivery_progress(loopx/control_plane/goals/checkpoint_context_io.py:137)隔离历史读取失败并保留严格恢复边界;坏 JSON 变来源警告,不能伪造结果已提交。run_codex_cli_host(loopx/control_plane/turn_driver/codex_cli.py:684)令 direction 使用临时新 session,并在store_session的第 734 行避免保存到主绑定;但discard_session和第 865 行失败分支仍会删除同一原 lineage 的持久绑定,产生下面的阻塞问题。
对主干的风险
[P2] 临时方向调用失败会删除原实施 session,破坏后续 resume。 已有正常实施在默认 Todo scope 下保存主 session 绑定后,执行 direction_review。进程返回 model_requires_newer_codex、session_missing 或 output_schema_rejected 任一错误,原来用于实施调用的失败清理仍执行 discard_session();它用原 lineage 删除持久绑定,尽管这个方向调用根本没使用或创建该绑定。随后原计划的 resume 在第三个进程启动前报 Codex CLI resume binding disappeared after planning。
独立复现调用真实 production adapter、真实 OS 子进程、真实 session 文件,再调用 production resume。子进程是受控 Codex 事件 fixture,不是付费实时模型;绑定的保存、删除及后续恢复由生产代码实际执行。成功方向调用保留文件并可 resume,三类失败均删除文件并阻止 resume。结果、Todo 与已有 quota 收据不因此被删除,不能把这个问题扩大成重扣额或已证实重复实施。
最小修复:在现有 session owner 同时隔离临时 direction 的保存和删除,保留普通实施失败原有失效规则。私下只在内存给失败清理增加 not direction_only 条件,同一个四场景 harness 全部保留主绑定并可 resume;这只是修复可行性证据,公开 head 仍有缺陷。增加三类错误的真实文件与冷 resume 回归,重跑 uv run --extra test python -m pytest -q tests/test_loopx_turn_codex_cli.py tests/control_plane/test_first_delivery_managed.py,并对普通实施失败验证原失效规则。
现有检查全部通过仍未覆盖该分支:相关 Python checkpoint/fence/fault/managed/MCP/status suites 162 passed(1 个 Pydantic unresolved annotation 警告);既有 Codex/Turn 164 passed;TS checkpoint/terminal/content digest 43 passed;独立 PostgreSQL 16.2 的六组实际 store/lease/acceptance/delegation/archive suites 443 passed,0 skip,隔离临时 server 已关闭。Ruff、TS typecheck、生成器 check、diff check、canary 10 catalog +8 risk +1 public boundary、全树 semantic/census 均通过。未查询或等待远程 CI。
同一真实 status harness 在固定 base/head、File/SQLite ×无记录/旧 supplement/其它角色坏记录六场景都正常返回、原状态不改,下一步相同。head 对坏记录额外提供来源警告;这是真实完整响应差异,不把所有输出都说成逐字相等。尚未完成所有共享 schema、prompt、accepted-input 和 persistence 表面的完整 feature-off 配对证明,因此 default_off_isolation=not_yet_proven;未发现一个新的已复现默认路径故障,也不因对象不存在就认证隔离。新能力目前是明确的 CLI/backend 阶段,未验证 packaged frontend 的可发现、操作、失败和持久读回旅程。
语义与 CI 对齐
扩展既有 checkpoint/Todo/Turn vocabulary,而非新增 actor 或授权来源;purpose、basis、stage 与响应使用现有 typed owner,通用规则不含领域专用词或 substring denylist。开发 advisory 37 source/0 supported carrier 仅是有限探针,另有全树 semantic、registry census 和生成器检查通过。默认未启用 first-delivery opt-in;参与后依据拒绝是机器义务,方向判断是建议,不能把强制 CAS 称为可忽略 guidance。临时 host 的实际权限与现有 session 生命周期仍必须分别证明,名称没有自动授权效果。
我的整体评价
REQUEST_CHANGES。long_horizon=regression、user_experience=regression:结果保存和过期方向拒绝在上述范围有正向价值,但临时方向的常见失败会毁掉独立主 session 的续接路径,令后续工作失去既有上下文、需要修复会话后再继续。这是当前 head 的具体错误,不是仅凭规模、模型身份或未来设想拒绝。
58 文件形成一个可独立回退的 opt-in 阶段,现有 owner 下实现分段结果与崩溃重放有必要,纯 status 文案无法保护先发生的写入。完整 frontend/真实模型效率的缺口已明确保留,不能把该阶段视为全能力完成。额外方向判断通常增加一次调用、最多两次尝试;能否用少返工抵消模型成本尚未测量,没有长程吞吐或节省比例。未来改动已检查:最高价值的 bounded pass 是在同一 Codex session owner 收敛 store/discard 的临时调用规则,不需要新框架;旧持久 receipt/独立 MCP 消费者兼容保留,未要求无依据的全面迁移。
两个历史阻塞点已在本 head 核验修复;上述新 session 缺陷仍阻塞。重新评审需公开修复 head、三类错误保留主绑定且恢复、普通实施失效规则保持,并补足声明所需的 feature-off 证据。结果与 Goal 验收分开,当前 runtime/control-plane 变更继续交由维护者合并。
English verdict: REQUEST_CHANGES — cd8a5a7. The historical malformed-receipt and CRLF defects are resolved, but an ephemeral direction-only Codex failure still discards the persistent implementation-session binding. Real production adapter/process/file/resume probes reproduce this for all three invalidating error categories; a successful direction call preserves it. Guard temporary-session failure cleanup, preserve ordinary implementation invalidation, and test cold resume. Result and quota receipts survive. Local suites and canary pass; full disabled-path parity, packaged frontend and sustained real-model efficiency remain unqualified. No remote CI was consulted.
| exact_goal_ref = dict(goal_ref) if isinstance(goal_ref, Mapping) else None | ||
|
|
||
| def store_session(observed_session_id: str) -> None: | ||
| if direction_only: |
There was a problem hiding this comment.
[P2] Preserve the persistent implementation-session binding on temporary direction failures. This added guard prevents storing the fresh direction session, but discard_session() and the invalidating-error branch below still use the original Todo lineage. After a main binding exists, model_requires_newer_codex, session_missing or output_schema_rejected from the ephemeral direction subprocess unlinks it; the subsequent planned resume raises before launch. Reproduced with the production adapter, an OS event fixture, actual session files and a subsequent production resume. Guard temporary-session cleanup as well, and retain ordinary implementation invalidation.
cd8a5a7 to
daf8744
Compare
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent | gpt-6.1-sol | OpenAI | runtime_reported | xhigh
Exact reviewed head: daf87448be08450237b59fd7b4e9d57180e0f462; immutable pre-change merge base: 77d23b7c09d6c1ee816d0c380c9935fbc67149f2. Full-PR re-review; earlier findings are independently rechecked below.
动机
先完成工作、再判断下一步的长程 Agent,以及关闭或恢复普通 Todo 的操作者。 工作做完后要求变化,旧判断可能继续沿过期方向;这个提交先保存已验证结果,再读取当前要求,拒绝过期方向时保留结果,减少重复实施。 结果与同伴证据保留、过期方向拒绝和临时方向会话隔离得到实测支持;但未启用功能的普通完成及成功后的同身份重试,在损坏 checkpoint 下从成功变为失败。 本轮不验收完整 Goal、已安装 App、外部 Lark、真实模型效果或长期吞吐。 普通关闭态完成与回执恢复尚有回归;完整关闭态跨入口对照、该能力的打包前端旅程、真实模型采用及长期净收益仍未验收。
改动思路
这次把“已有工作结果”和“接下来往哪走”拆成同一个原始 Turn 的两个阶段。Turn 是一次有身份的执行与记账周期;结果先经过原生 Todo 存储的比较后写入,方向再读取当前相关事实并重新判断,最后 refresh/spend 使用同一身份。结果保存并不代表目标验收完成,也不授予新的写入权限。
状态判断复用 TypeScript 的 checkpoint、Todo terminal、first-delivery 状态机和 provider fence;Python 负责实际文件锁、来源采集及 Codex 进程。purpose/read_context_id 是调用者所判断的读操作身份,不能从“安装了能力”或同伴状态推断;frontier/version/status 从现有 authority 派生,commit-attempt/receipt 是已尝试效果的崩溃恢复见证。CLI/guard/MCP 和 managed 请求有真实生产调用链,没有新建平行 Goal 真相。
正向路径是在结果提交后再读取方向;相关任务新增使旧方向失效时,结果、依赖和同伴证据保留,拒绝过期追加且不重复扣额。此前实测的工程/研究两个 Goal、四类角色场景,只在逐文件确认相关 owner 字节未变后复用;本轮重跑当前头的 provider/managed/真实进程及恢复测试。新增的方向进程现在同时跳过主实施会话的保存和清理,成功与三类失败均保留原绑定,后续冷启动 resume 可以继续。
具体改动
完整差异为 62 文件、+2212/-190:38 个生产路径,20 个测试及浏览器 fixture,2 个文档,2 个生成/配置路径。包括 CLI 注册和 Todo/refresh/quota/status/run-once,typed checkpoint/terminal/recovery,Python host/IO、MCP/KunlunCode/Lark adapter,run-history 投影与 turn-contract 生成;三个浏览器文件修正 fixture 的 authority/readback 表达,不构成该能力已打包前端交互的证明。与上次审查的 cd8a 逐文件对照:当前 PR 的 57/62 路径字节相同,5 个变化集中于 Codex 清理、其测试和浏览器 fixture;仍重读完整差异及实际调用者,没有继承旧 verdict。
关键代码讲解
checkpointBasisSnapshot(checkpoint_read_context.ts:44)从完整相关 canonical Todo、依赖、owner acceptance、Goal/agent vision 和来源身份生成读基准。无关全局更新时间不能替代相关输入;purpose 区分结果与方向,缺失或过期的覆盖内输入拒绝追加。terminalDeliveryBasisCheck(todo_delivery_context.ts:45)把新结果检查放进既有原生 terminal/CAS 边界;历史已提交回执应先返回,新的覆盖内提交再受读基准与 provider fence 约束。prepare_first_delivery(direction_review.py:21)由实际 run-once/managed producer 建立同一 Turn 的分阶段请求和 fresh direction,并沿既有 journal 恢复,避免另建执行/记账身份。delivery_result_context_input(checkpoint_context_io.py:201)为 terminal owner 捕获可选 enrollment 与来源;第 211 行在 capture 的 try 之外读取 enrollment,第 75 行解析损坏 JSON 时,普通未启用任务也会在原生历史回执查询前失败,这是当前 F1。run_codex_cli_host(codex_cli.py:668)的store_session/discard_session现在对 direction-only 都直接返回。相同真实进程/文件/随后 resume 脚本:旧 cd8a 三类错误删除主绑定,当前 daf 四个结果均保留并能继续;普通实施进程的错误失效规则仍由当前测试覆盖。
判断依据为已接受的 checkpoint 合同(固定基线),没有把本 PR 新增文字当独立验收标准:Vision Checkpoint 的结果/方向与 Goal 证明边界已实现;Read basis for checkpoint-only recovery 中普通首写保持原规则、同身份已提交效果可恢复的要求 not_met(F1);Semantic History Continuity 的按 agent 保留历史与坏来源显式 unknown 得到当前 status/observation 测试支持。roadmap 仍是局部阶段,不宣称闭合整个 R1。
对主干的风险
[P2] F1:可选 enrollment 读取提前阻断普通完成与历史回执恢复。 触发步骤:未启用 first-delivery、不提供 read token 的普通已准入 Turn;对应 effect-id 的旧 checkpoint supplement 文件损坏为 {;执行同身份 todo complete。CLI 仍传 settlement identity,Python provider wrapper 先调用 delivery_result_context_input → first_delivery_context_enrolled → JSON 解析,尚未到达既有原生 terminal 的回执优先恢复。File 和 SQLite 均 exit 1,错误是 Expecting property name enclosed in double quotes: line 1 column 2 (char 1)。首次完成时 Todo 仍 open;先健康完成再损坏文件重试时 Todo 已 done,但 CLI 同样失败。
相同独立公共 CLI 脚本,在固定 B 与 H 的真实一次性 File/SQLite authority 上各跑 none、有效旧 supplement、损坏匹配 receipt、健康提交后损坏再重试:基线 8/8 成功,当前 4/8 失败,另外 4 个正常/兼容场景成功。损坏场景 authority/run index 没有额外变化;这不是“结果被删除”或“双重扣费”的证据,问题是合法操作和已提交结果恢复被新读路径挡住,造成错误提示和人工介入。与此前无关 agent 的损坏文件 status 失败不是同一未修复分支:当前六个配对 status 场景全部成功,正常 action 保持,坏来源警告保留。
最小修复:在既有 terminal owner 中保留普通历史回执优先恢复,再处理可选 enrollment 的不可读来源;捕获错误必须有作用域,并保持真正已启用/状态不确定的追加 fail-closed。不能简单吞掉所有损坏 JSON 当“未启用”,也不能只搬 try 而破坏原请求/回执匹配。补 File/SQLite 关闭态首次完成及同身份 replay,保留已启用 unknown/stale/missing token 拒绝与无效果断言。
验证与失败归因
当前独立执行:133 项 checkpoint/provider/fault/MCP/observation/generator/host Python 测试通过;92 项 Codex/managed 测试通过,包含实际文件及独立解释器冷 resume;Python 保留 1 个 Pydantic lifespan unresolved-forward-reference 警告,未把它当失败或静默删除;30 项 TS 测试通过;独立实际 PostgreSQL 16.2 临时 server 的六套集成测试 450 项通过、0 skip,已停止 server。PG 结果只覆盖共享 authority 兼容性,不证明新的 PostgreSQL first-delivery enrollment。TS typecheck、turn-contract generator、changed Python Ruff、diff check、语义 advisory 后 full semantic、public/private scan 均通过。
原生 canary aggregate 仍红:5 个 direct checks 通过,19 个 selected checks 中 18 个通过;唯一失败是以较新 origin/main 9f6a87f 对照的小 status 输出预算:chars/UTF-8 +146、允许 145,compact +106、允许 104。另用相同 native 96 场景/oracle 固定本 PR 的 B/H,全部通过、小 status 尺寸 delta=0;再用固定 9f 对照 immutable B,复现同一个失败身份及细节,B/H 的该输出只差等长生成时间。归为 pre_existing_unrelated 的对照基线问题,保留原失败作为 merge diagnostic;没有放宽上限、缩 fixture 或把 aggregate 改成绿。它不掩盖 F1 的四个实际回归。
语义与 CI 对齐
复用并扩展已有 typed checkpoint/Todo/Turn 词汇,名称没有授予独立 peer 权限;没有引入领域子串分类器或产品/benchmark 专属强制语句。方向建议是 guidance,freshness/CAS 与 settlement 是机器约束。关闭态对照明确判为 not_isolated:完整 schema/prompt/input/迁移矩阵仍未全部证明,普通 terminal 已有具体反例。按当前 Goal capability 的 wait_for_ci=false 未查询、轮询或等待任何 GitHub CI;作者 CI 声明不算本轮独立验证。
我的整体评价
当前头 REQUEST_CHANGES。交付判断是 justified_increment:先保存结果再重判方向是有实际 caller、可回滚的局部机制;当前关闭态可靠性缺陷仍阻止交付。长程效果与用户体验的判断均为 regression:原本能完成及恢复的普通任务如今会在损坏可选文件上卡住,即便结果已保存也要求额外排查;旧 Codex 会话丢失已经独立修复,不继续当成当前 blocker。
机制范围基本成比例,沿既有 typed owner 扩展,新增状态有 producer 和持久恢复用途。兼容性的保留由原始 Turn/terminal/supplement 回执和独立 MCP 消费者支撑,不能只为减行数删除。相关未来改造应收敛到原生回执与 Python capture 的同一恢复边界;无需新建抽象或平行 authority。当前 full-shared-surface 关闭态证据、该能力打包前端操作、真实模型采用与长期净效率仍未 qualified。额外 fresh inference 可能减少返工,也增加调用与等待成本,不能从测试数或保存了 receipt 推断净收益。修复 F1 后需要重跑完整相关正负路径和既有回执恢复,重新核验当前 exact head。
English verdict: REQUEST_CHANGES - daf8744. Malformed optional checkpoint enrollment blocks feature-off ordinary completion and committed receipt replay on both File and SQLite (base8/8 succeeds; head4/8 fails). Previous Codex session loss is fixed; current native/provider tests pass, with the original canary budget failure preserved and independently attributed. No CI or merge authority claimed.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
daf8744 to
8ad8dc9
Compare
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent | gpt-6-astra | OpenAI | runtime_reported | xhigh
Exact reviewed head: 8ad8dc9a564d57c0e877a33f2998f4f351629034; immutable PR merge base: 715c8774074871fa4b96c7efb6306436fc4b30be (下文 B);本轮检查的 main:42e55a809eb94f13443d303d76118735d4112182 (下文 M)。
REQUEST_CHANGES,主要依据本轮维护者明确的架构与产品交付要求。 发布前作者将 head 更新到 8ad8dc9;我重新核对了 rebase 与增量,旧 F1 的普通历史恢复修复已进入该 head,不把旧失败直接算到新代码。后续交付方向是:基础 freshness、结果保留和恢复进入默认产品路径;额外独立 Host 的方向复核作为可选 capability,经一个由 kernel 管理生命周期的 typed hook 接入。 后者是本轮明确的设计调整,不把先前声明为 opt-in 的实现追溯成“隐瞒默认行为”。以下给出具体契约、迁移边界和分阶段 PR 建议;它们是待实现设计,不是当前 head 已提供的能力。
动机
受影响的是执行长程任务的 Agent,以及从 CLI、App 或 Lark 查看和恢复交付的操作者。Agent 按旧验收完成工作后,用户或同伴更新要求;继续使用旧方向可能遗漏新工作,而把整个 Turn 重跑又会重复已完成的实施。目标是提交时核对结果依据、保留合法完成的结果,再根据当前事实判断方向,并能在中断后从原 Turn 继续。当前 PR 已有结果与方向分阶段的实际调用链,最新 head 也修复了已证明普通历史的可选 receipt 恢复;默认保护与独立复核仍捆绑在 opt-in 流程中。完整默认产品接入、可选 reviewer 的配置/恢复旅程和真实模型净收益尚未验收。本轮不要求完成整个 Goal、跨主机协作、PostgreSQL 新协议 enrollment 或完整共享意图治理。
保留这个问题的解决方向。完全不做,无法解决执行期间依据变化及结果提交后的方向失效;只改提示词,无法关闭检查与提交之间的并发窗口。但“依据未过期”和“语义判断足够好”必须分开:前者是确定性提交条件,后者需要 Agent 判断;独立 reviewer 只是其中一种增强实现。hash/token 不能证明模型真正理解了目标,增加一次模型调用也不能自动证明更少返工。
改动思路
A. 收敛为默认 kernel 保证、可选 capability 策略、Host 实现三个边界
| 机制 | 目标归属及默认性 | 必须保留的约束 |
|---|---|---|
| 结果绑定读取依据,最终写入时校验相关事实 | 现有 Todo terminal / Goal typed owner;在完成适配的产品路径默认生效 | 依据来自实际交付给执行者的读取;禁止在提交时给旧结果补造新 token |
| 方向判断绑定当前依据 | 现有 checkpoint owner;遵守已有 checkpoint 触发规则 | 不增加“每次 heartbeat 都复核”的隐式义务;保留合法 in-flight exemption |
| 成功结果保留、exact replay、原 Turn 恢复 | 现有 receipt / Turn journal / settlement owner | 不因 reviewer 失败撤销结果、重做实施或创建新 Turn 绕过未决效果 |
| 额外独立 Host 审视当前方向 | 可选的、面向“交付方向复核”结果的 capability | 默认关闭增强复核;配置选择它以后,其必要性和失败行为必须明确 |
| 临时会话、只读工具面、进程超时和清理 | 已有 Host/provider adapter | 不存入或删除主实施 session;不能用 prompt 禁令冒充真实工具隔离 |
| 已保存/待判断/待结算/提交未知及可执行恢复动作 | 原有共享 projection 和产品交互 owner | 从持久事实派生;不能维护第二套“成功/完成”真相 |
基础方向判断仍由当前 owning Agent 基于新依据作出。可复用它的会话/续接能力,但这不等于模型零调用,也不能复用执行前旧 Vision。增强 capability 改变的是方向判断的实现方式,不替代 freshness、receipt、quota 或 terminal owner。
三种流程的实际差别:
| 路径 | 实施后如何判断方向 | 侵入与增补 |
|---|---|---|
| PR 前的既有流程 | 沿原有 Todo / checkpoint / settlement 规则提交;没有本次新增的结果与方向两次读绑定 | 原有回执/结算已存在,不能把此前描述为完全没有恢复或一致性保证 |
| 当前 PR 关闭开关 | 主执行路径仍走原逻辑,但共享 CLI、schema、读取与恢复代码有改动 | false 证明没选择增强执行,不自动证明所有共享表面与基线相同 |
| 当前 PR 开启开关 | 结果依据校验 → 保留结果 → 新方向读取 → 独立 Host → checkpoint/结算 | 确定性保护和额外推理捆绑,新增等待、尝试预算和失败恢复分支 |
| 建议目标 | 默认路径具有依据校验/保留/恢复,当前 Agent 提交新判断;配置可把判断实现切换为独立 reviewer | 默认强约束属于 owner;增强策略只接入一处 typed 判断端口 |
普通完成路径的目标结构:
flowchart TD
A[读取并绑定结果依据] --> B[当前 Agent 实施与验证]
B --> C[Kernel 在原生提交边界复核依据]
C --> D[提交并保留结果回执]
D --> E[读取当前方向依据]
E --> F{已解析并绑定的判断方式}
F -->|默认| G[当前 Agent 作出新方向判断]
F -->|显式选择增强 capability| H[受限 Host 独立复核]
G --> I[方向提案绑定本次读取身份]
H --> I
I --> J[Kernel 再校验依据并提交 checkpoint]
J --> K[原 Turn 按已有规则结算或恢复]
图不覆盖特殊顺序:no_followup 仍保留原来的 refresh → spend → terminal;必要时延后 Todo terminal 写入。terminal_ready 只是提案,最终仍须当前全 Goal frontier、验收与权限检查。不得为了统一图形而把最后一个 Todo 提前关闭。
B. Capability placement:先比较已有 owner,不再发明一套“复核系统”
仓库已有三个相关但不同的边界:
progress-review-sentinel:异步读取已捕获工作变化的 drift receipt,shadow展示,assist通过连续信号触发现有 replan obligation;它明确没有 Turn settlement/Goal acceptance 权限。todo_replan_cadence/ #5699:已合并的完成 Todo / settled work Turn 复核节奏,决定何时提出既有方向复核义务。新能力不能再加一个独立计数器,或把同一交付计算两次。- Goal Vision/checkpoint:当前 Agent 的方向判断、依据校验和提交归属。
本次独立 reviewer 的直接 caller outcome 是“为这一次交付 checkpoint 提供基于当前依据的方向判断”。建议先按独立的 direction-review capability 设计,复用既有配置、provider admission 和 Host 端口;这个名字是设计建议,注册前仍应做 catalog 冲突/所有权核对。它和 progress-review 的时点、失败语义、返回对象不同,不能直接把原有 assist 升级为阻塞 settlement。若作者选择扩展已有 capability,必须提供明确的新 operation/version,并证明旧 shadow/assist 契约完全保持。
核心协议/注册信息可以随 LoopX 分发,运行时增强行为仍默认关闭;已有 Codex/generic Host adapter 提供实现。独立安装/版本管理的 reviewer provider 才进入 packages/<provider> 或独立 distribution。不要把模型 prompt、provider-specific session 分支放进 typed kernel,也不要为了可安装而再造一层 capability。按照 extensions 的既有职责表,capability 提出策略结果,kernel 接受/拒绝并持有持久状态权威。
C. 新 hook 的定位:checkpoint decision,而非旁路 post-writeback
建议将窄端口称为 checkpoint_decision phase / Goal direction decision hook。名称暂定,最终复用或扩展已有语义登记;不要建立通用 before_every_write hook、任意命令回调、hook DAG 或新的 workflow engine。v0 只有一个实际调用点:既有交付流程需要当前方向判断、即将提交该 checkpoint 的边界。
| 对比 | 现有 post_writeback |
本次建议的 checkpoint_decision |
|---|---|---|
| 目的 | 已提交后提出后续 intent | 为既有必要 checkpoint 提供判断提案 |
| 来源 | 已提交主回执的有限投影 | 当前 decision basis + 原 Turn 身份 + 结果引用 |
| 是否属于主流程必要条件 | 否;failure_policy=isolate | 必要性由既有 checkpoint 规则及显式选定策略决定 |
| 失败 | 不改变主回执和匹配 quota spend 资格 | 该必要判断保持 pending;沿原 Turn 恢复 |
| 返回 | typed follow-up intent | typed direction proposal / typed evaluation failure |
| 持久提交者 | 后续另行准入的 executor | 原 checkpoint/Todo/settlement owner |
现有 Post-Writeback RFC §5 明确禁止 optional hook 成为第五个 primary settlement step;hook 失败不得阻止对应 quota 结算。不能改它的 isolate 定义来承接本 PR。新增 phase 必须单独登记注册/输入/结果/恢复语义,复用现有 admission/typed validation 结构;共享机制不代表共享失败策略。
“可选”是选择增强判断方式时的属性;一旦本次 checkpoint 已明确选择它作为必要判断实现,provider 失败不能被静默降级成成功。反过来,provider 也不能通过输出 required=true 给自己创设新义务。必要性始终来自 kernel 已有规则与 caller 的有效配置。
D. 建议的最小 typed 契约
以下是语义草图,不要求照抄新的字段或重复保存现有 identity;实现时优先引用已有类型和 journal 字段。
type DirectionDecisionInput = {
// Existing Goal/instance, Agent, Todo-or-obligation, Turn/effect identity.
identity: ExistingSettlementIdentity;
invocation: ExistingJournalInvocationRef;
// Captured from the admitted effective configuration, not provider output.
strategyBinding: {
capabilityId: string;
providerId: string;
policyRevision: string;
};
readContext: ExistingCheckpointReadContext;
result: CommittedResultRef | ValidatedPendingTerminalResultRef;
};
type DirectionDecisionOutput =
| {
kind: "proposal";
readContextId: string;
// Reuse registered direction decisions and existing Vision validation.
proposal: ExistingDirectionProposal;
}
| {
kind: "unavailable" | "failed";
reason: RegisteredBoundedReason;
};这里的 Existing* 是已有 owning contract 的引用占位符,不是建议新增同名类型。v0 只允许一个已选定 provider、一个当前有效 invocation。不要顺手实现多 reviewer 投票、动态选择 DAG 或任意 veto chain。
- 输入完整性:basis 由 kernel 从权威源组装,覆盖选中 Todo、依赖闭包、验收、共享要求、当前 Agent Vision、source/store identity、必要 lease,以及判断 scope 对应的完整 frontier。provider 不能自己提交“我认为相关”的缩水 Todo 列表。
agent_lane与goal使用已有 typed 选择规则;no-followup 用全 Goal scope。 - 私密边界:供模型判断的 basis 可能包含私有 Goal 内容,不能直接套用 post-writeback 的 public-safe 投影并宣称信息齐全。只能向已授权 provider 交付声明范围内的数据;公开状态/日志只保留必要摘要、opaque identity 和错误码。缺乏必要读取权限应报告 unavailable,不得用残缺视图证明“没有剩余工作”。
- 输出校验:精确匹配身份和
read_context_id,拒绝额外写入指令及非法字段。复用当前continue / revalidate_result / terminal_ready含义和 Vision/unchanged-reason 的互斥校验;最终合法性仍由既有 owner 判定。无需为了 hook 再复制一套 Todo/Goal 状态机。 - 作者与执行者身份:独立 Host 是原 owning Agent 已准入 checkpoint 请求的计算实现,不自动成为新 peer/manager,也没有替原 Agent 取得权限。journal 记录 caller 与 evaluator 来源;提交仍走原 Agent 的授权请求。若未来是真正另一个 Agent 给意见,应走现有 request/adoption 契约,不能把该回复直接冒充 owning Agent 的 Vision。
- 权限:proposal 不写 Todo、不修改 acceptance、不延长 lease、不扣 quota、不改变调度、不确认 Goal complete。kernel 在提交点重新检查当前权限和来源。已授权配置也不能覆盖后来的 stop/revocation。
E. 生命周期、并发与恢复要求
| 时点/事件 | owner 应执行的规则 |
|---|---|
| 选择策略 | 从既有机器默认/Goal override resolver 获取有效策略,在当前 Turn/checkpoint journal 中绑定;安装、doctor-ready、schema 存在都不等于启用 |
| 首次调用前 | 验证 scope、provider readiness、权限、成本/尝试预算;持久记录本次 invocation,再发出 Host 请求 |
| 运行模型 | 在 provider/source 写锁之外;使用已批准的读取/工具面。保留原实施 session |
| 收到提案 | 校验 schema、绑定、当前 invocation 和响应 digest;旧 attempt 的迟到回复不能覆盖新 attempt |
| 提交 checkpoint 前 | 在既有真实 source/provider fence 内重读当前依据并校验,然后提交;不能靠 hook 开始时的检查消除 TOCTOU |
| 依据变更 | 旧提案失效;读取新的依据并重新判断。保留原结果,不给旧判断换 token;本 Turn 自身结果写入通过独立 post-result 读取体现 |
| 回包丢失/进程重启 | 先读原 invocation、checkpoint 和 settlement 回执;已提交效果返回历史结果,未决效果先查明,不能盲目新建 Turn |
| provider 失败/超时/非法输出 | 保留已提交结果,给出带恢复 owner 的 typed pending/failure;不自动宣称审核通过,也不凭一条错误文本制造用户审批 gate |
revalidate_result |
保留既有结果证据,交给现有 repair/replan/验收路径处理差异;不直接重开 Todo、不删除结果、不把拒绝当作恢复已经完成 |
terminal_ready |
仍执行现有全局 frontier、验收、授权、refresh→spend→terminal 检查;新任务或变化的验收可以拒绝终结 |
| 策略中途关闭/升级 | 新 checkpoint 使用新配置;进行中的已绑定调用不因重读配置自动换 provider 或消失。授权撤销立即阻止新调用/提交;取消或改用基础路径必须有显式、留痕的恢复转换和新的判断 |
必须区分两种 replay:已提交效果的历史恢复优先于当前 freshness 检查;尚未提交的新决定必须检查当前依据。旧 receipt 不等于当前工作仍有权限,权限已撤销时不能发起新效果,但已经发生的历史事实仍应可读回。
必要的持久数据只是不可重新推导的绑定、已交付的读身份、调用尝试和已观察结果。result_committed / direction_pending / settled 等展示从已有回执派生。不要再加一份手工同步的 stage DB、第二套 quota 或新队列作为主事实。
重试总数和超时应沿原 Turn 持久计数,重启不能重置。可以以 PR 当前“最多两次方向尝试”为首个有界值,但应放在明确的 owning policy/已有预算边界,而非 scattered constants。模型请求的实际 usage 单独记录;Turn settlement 只扣一次不代表额外推理免费,也无法保证远端模型在回包丢失时只计费一次。预算耗尽的出口应明确到“恢复哪个步骤、由谁处理、如何继续”,不是无限循环 recommended_action。
F. 产品入口必须和默认化一起交付
普通用户不应复制两个 token 或手工区分 result/direction phase。CLI/MCP 可以保留专家级显式操作,managed host 和产品入口应沿已绑定 Turn 自动传递 identity,并在确实需要新判断时将完整依据交付给 Agent。
复用既有 Capability Center 的机器/Goal 配置 resolver 和编辑器;不要再做 first_delivery 与 reviewer-enabled 两个含义重叠的开关。增强能力需要显示用途、有效配置来源、额外成本/预算、provider 不可用、启用/关闭和持久读回。核心 freshness 不应成为一个默认不勾选的“更安全”选项。
交付读回至少区分“结果已保存,待方向判断”“方向已确认,待结算”“提交结果未知,正在/需要核对”。恢复动作由现有 typed action/host owner 执行,只恢复剩余阶段。App 必须验证实际点击后的持久结果及 reload;Lark 复用对应 audience 的 action/projection,若这一阶段没有可操作入口就明确保留未验收范围。静态目录行、复制命令按钮和共用 next_action 文本不构成完整旅程。
不支持的 source-session、provider、operation-tools 或 compound repair/replan 组合,必须在适当的准入点清楚说明范围。不能到结果提交后才发现方向 adapter 根本不可用,也不能静默降级后继续显示“已保护”。旧持久记录可按旧契约恢复,但不能追认它们已经通过新 freshness 校验。
具体改动
新 head 已 rebase 到 B;range-diff 显示前 12 个 PR commit 等价,浏览器 fixture 随 main 调整,新增 terminal 恢复与文档两个 commit。当前 B→H 完整差异为 62 文件、+2354/-187。生产路径覆盖 CLI Todo/refresh/run-once/status/quota、typed checkpoint/terminal/provider fence、managed executor/Host、MCP/KunlunCode guard、Lark/共享 readback;其余是聚焦测试、两个浏览器 fixture、两份文档和生成/语义登记。浏览器 fixture 修复不等于新增 capability 已有前端交互。
关键代码讲解
checkpointBasisSnapshot:purpose 区分结果和方向,方向使用完整相关 frontier;未知 Todo 字段默认进入依据,只有明确展示字段排除。这部分应收敛到默认读取/提交 owner。不要为了降低 stale 数量改为文本关键词“相关性”判断。terminalDeliveryBasisCheck:现有 terminal/CAS 检查当前来源与 provider head,no-followup 额外验证 indexed direction 及 terminal versions。这是 kernel 责任,不能移到锁外 hook 后直接信任结果。prepare_first_delivery/review_first_delivery:目前把提交结果、额外 Host、最多两次尝试、方向提案及 terminal 条件编排在同一路径。建议拆职责而不是复制流程:kernel/既有 TS owner 决定阶段与合法转换,capability 决定复核策略,Python 保留 Host IO。delivery_result_context_input:新 head 将可选 enrollment 的读取错误传入 native owner,保留普通请求指纹,先恢复已提交 receipt;未提交操作再验证原 ordinary writeback 是否足以证明损坏来源可忽略。这是 F1 修复的关键边界。evaluateFirstDelivery:已有纯校验/投影 seam,可用于收口提案契约;“响应合法”只能证明结构、身份与字段约束,不等于认可目标完成。run_codex_cli_host已同时隔离临时调用的 store/discard,搬迁时保留其回归覆盖。
其他接入也不能在重构时漏掉:MCP v2 分段 complete/vision 调用及 v0/v1 消费者;CLI 参数互斥;managed 原 plan 的恢复;status/quota 的来源不足和 pause 优先级;File/SQLite 的真实 fence;旧 supplement 与 commit-attempt 崩溃见证;generator 的 LF/CRLF 一致性。这些都有独立的兼容含义,不能把所有 purpose 合并成一个不带语义的字符串来减少行数。
独立规范基线为 docs/reference/protocols/goal-vision-replan-contract-v0.md,spec_revision=715c8774074871fa4b96c7efb6306436fc4b30be。没有用 PR 自己新增的 first-delivery 文档作为独立正确性 oracle。
| 原规范 criterion | 当前 head 判断 | 后续要求 |
|---|---|---|
| Vision Checkpoint | 分阶段实现可见,当前 suite 覆盖正向/拒绝路径;默认产品 adoption 尚未交付 | 保留 material closeout 与 in-flight 的现有区分,不靠新增 reviewer 无条件扩大触发频率 |
| Read basis for checkpoint-only recovery | F1 的已提交 receipt/已证明普通 writeback 恢复已修复;完整关闭态矩阵仍待补齐 | 保持 receipt-first;新操作依然校验依据,unknown 不能当 absent |
| Semantic History Continuity | 有派生进展与坏来源观察覆盖;长期规模成本未验证 | 保留按 Agent/原 Turn 的语义读回,不把 bounded display 的缺席当 canonical absence |
新 phase 还需对齐 Post-Writeback RFC 的隔离边界及 TypeScript migration RFC 的单一 decision owner。契约增量与实际调用点放进同一阶段;不要求先造一份无调用者的通用 hook 框架。
Roadmap 的对应关系:R1 是提交/失败/恢复的局部增量;R5 是相关 typed transaction 与持久权威边界;R4 的共享依据治理只得到部分支持,basis digest 不是完整意图修订协议。capability/provider 生命周期属于 S8。此工作不自动完成 R2 多 Agent 协作、R3 接收/返回或真实模型收益验收。
对主干的风险
F1 历史问题与本次修复:不再把旧失败当成新 head 的缺陷
旧 daf87448 的普通 todo complete 会在 Python enrollment JSON 解析处失败,尚未到 native terminal 的历史 receipt 恢复。本轮先独立复现:File/SQLite × 无 receipt、可解析旧 supplement、损坏匹配 receipt、健康提交后损坏再重放;旧 head 4 passed / 4 failed,旧不可变基线 8/8 通过。已有结果没有被删除,这不是重复扣额证据。原 finding
新 8ad8dc9 保留普通请求指纹,让已提交 terminal receipt 优先返回;对于尚未提交的操作,只在既有 ordinary writeback 及 indexed artifacts 证明普通历史、且没有 result enrollment receipt 时忽略损坏的共享 supplement。没有足够历史、已有结果 enrollment、损坏/不一致 writeback 仍返回 checkpoint_commit_unknown。
这个区别应保留:我们测试脚本知道“没启用”,不等于持久状态足以证明“没启用”。对不可证明的 enrollment fail closed,不能仅因旧版接受就称为新 bug;它应有明确的受影响 scope、可操作恢复和兼容说明。本轮另外用真实 ordinary writeback 作为独立前置事实,重跑 File/SQLite 的首次完成与冷 replay,并运行作者新增的反向保护测试;结果列在下面。请保留这些修复,不简单吞掉所有 malformed JSON,也不要为了拆 capability 再把 provider 读取放回历史 receipt 之前。
D1 — 当前维护者要求的架构调整:解除基础保护与独立推理的捆绑
这是一项交付方向要求,不是声称现有独立推理必然判断错误。当前 first_delivery_freshness 一路携带到 executor、Host、MCP、refresh、Todo 和 readback,选择基础保护同时选择额外 Host 与恢复分支。直接默认打开会把新的等待、provider 可用性和额外失败源推给普通任务;继续永久全量 opt-in 又不能交付已确定的默认保护目标。
请按 A–F 收口:确定性保护留在 owner,方向判断提供一个窄接口,默认 owning Agent、可选 capability provider。保留身份/fence/receipt 的必要复杂度;削减的是重复决策源、让调用者手工协调的协议分支和没有证据支撑的无条件额外推理。是否可合并以实际交付与验证判断,不以 62 文件或行数作为拒绝依据。
验收矩阵:区分当前证据与重构后必须新增的证据
| 场景 | 重构后的预期,不能只检查 happy path |
|---|---|
| 增强 capability 未配置/禁用/未安装 | 基础保护和既有正常流程成立;零 reviewer 调用;已证明未 enrollment 的普通完成不因坏的可选 receipt 受阻,不能把不确定历史当成已证明关闭 |
| 已安装但未启用,或只启用同 Goal 的另一 lane | 不自动扩大 scope;自己的 request/schema、prompt、读回、quota 与错误优先级按声明保持 |
| 新建 Todo/新 Turn | 按有效配置明确决定是否覆盖;不从旧 receipt 或“目录存在”推断 enrollment |
| 当前 Agent 基础路径 | 确实收到当前依据并作出新决定;没有自动给旧 Vision 刷新 token |
| 增强能力启用且成功 | 原 Host 实施一次、受限 reviewer 一次、原 owner 提交;正确回执和 usage 读回 |
| 选中 Todo/依赖/验收/共享要求变化 | 原决定拒绝;相关当前事实完整;拒绝后能重新判断并推进 |
| 独立 peer 更新、展示排序/分页/超出显示上限的工作 | 合法独立工作不被误阻断,完整相关 frontier 不被遗漏;不是只比较 decision code |
| reviewer 返回前又发生变化 | 提交点仍拒绝 stale;证明 final fence 有效 |
| 旧 token、跨 Agent/Turn token、迟到响应、重复/冲突响应 | 错误请求拒绝,不能替换当前 attempt;同身份相同效果按历史回执恢复 |
| reviewer 超时、非零退出、非法 schema、读权限不足 | 保留结果和实施 session,准确 failure/pending,预算有界,原 Turn 可恢复 |
| 在结果提交/方向提交/quota/terminal 间崩溃 | 原 receipt 决定恢复位置;不重复实施、不重复效果、不通过新 Turn 绕过 unknown |
| no-followup 后新增工作 | 最终 terminal 拒绝;保留合法结果,不把 terminal_ready 当 Goal 完成证明 |
| provider 卸载、配置升级/撤销、owner stop | 进行中状态可解释;立即尊重撤销,迟到结果不能获得新写权;无静默 fallback |
| App 操作后 reload / 配置 CAS 冲突 / provider unavailable | 有真实 backend 持久读回和授权的恢复动作;无第二份 UI 状态源 |
| 原 MCP v0/v1、旧 supplement、旧 Turn receipt、无关 provider | 有明确迁移和兼容测试;不追认旧记录已经通过新协议 |
| 真实模型对照 | 基础 Agent 与增强 reviewer 在相同任务/预算下比较返工、错误阻塞、人工介入、调用数、延迟、成本;不以 receipt/test 数量宣称收益 |
本轮验证记录
以下均为本轮独立执行,除单独标记的远端观察外,针对新 head 8ad8dc9:
| 检查 | 结果与范围 |
|---|---|
| Python 聚焦套件 | 173 passed,281.69 s;checkpoint read context / provider fence / first-delivery faults / managed / MCP / observation / terminal / Codex CLI,共 8 个文件,pytest -n 4 |
| 独立 ordinary-completion 反例 | File/SQLite × 无额外 receipt、旧 supplement、损坏匹配 receipt、提交后损坏并冷 replay;均先通过真实 CLI 写入 ordinary writeback,head 8/8 passed。不可变基线比较结果见下;未修改生产代码 |
| TypeScript | checkpoint_read_context.test.ts + content_digest_single_owner.test.ts,29 passed / 0 skipped |
| 静态/生成检查 | npm run typecheck:control-plane、uv run --extra test python scripts/generate_turn_contract.py --check、B→H git diff --check 均通过 |
| 语义 advisory | uv run --extra test python scripts/generate_semantic_inventory.py --changed-from 715c8774074871fa4b96c7efb6306436fc4b30be,37 changed sources / 0 supported candidates;这不是无新语义证明 |
| 完整语义检查 | uv run --extra test loopx canary smoke-suite --script semantic-vocabulary-drift-smoke.py,通过,57.847 s;不是全仓库 full-public canary |
| 当前 head 的远端 CI 观察 | 观察时 Summary 成功,build、adapter-contract、real PostgreSQL、DCO 等 7 个 job 仍 queued。pending 本身不是本 review 的 REQUEST_CHANGES 依据;merge readiness 单独保留 |
Python 复现命令:
uv run --extra test python -m pytest -q -n 4 \
tests/control_plane/test_checkpoint_read_context.py \
tests/control_plane/test_checkpoint_provider_fence.py \
tests/control_plane/test_first_delivery_faults.py \
tests/control_plane/test_first_delivery_managed.py \
tests/control_plane/test_first_delivery_mcp.py \
tests/control_plane/test_first_delivery_observation.py \
tests/control_plane/test_first_delivery_terminal.py \
tests/test_loopx_turn_codex_cli.py
node --no-warnings --experimental-sqlite --experimental-strip-types --test \
tests/control_plane_ts/checkpoint_read_context.test.ts \
tests/control_plane_ts/content_digest_single_owner.test.ts全部运行使用隔离的合成 Goal/runtime;未对活跃 Goal 做故障注入。旧 head 的 149 项通过及独立 4/8 失败属于历史证据,不累加到新 head 的通过数。最初独立测试的 fixture 导入路径、旧 TS 检查缺少新 worktree 依赖,以及一次 TS 测试目录输入错误均已修正;这些是本轮测试准备问题,不归因于 PR。新 head 的成功运行没有放宽断言或语义预算。
同一个带 ordinary writeback 前置事实的独立 8 用例,在当前 PR 不可变 merge base 715c8774074871fa4b96c7efb6306436fc4b30be 上也 8/8 passed(35.73 s),head 为 8/8 passed(43.67 s);使用各自源树加载 CLI/模块,fixture 语义相同。更早的 77d23b7 基线也通过,但不代替本次 B→H 比较。这只证明这 8 个普通路径场景,不证明全部 feature-off 隔离。
作者另报 343 项 Linux 测试、真实 PostgreSQL 检查及部分 packaged-browser 验证;它们属于作者证据,本轮没有独立重跑。作者也保留了 packaged aggregate 的 team-evidence-return-smoke 超时并报告固定基线同样失败;本轮不把这一未独立归因的历史/环境问题当成本 PR 已证实引入的 bug,也不声称整个 packaged suite 已通过。
新 hook/capability 尚未实现,因此上表不是通过清单;尤其默认 App/Lark 恢复、真实工具权限隔离、长期模型效果和全共享表面的关闭态矩阵仍是未验证。需要 PostgreSQL 兼容覆盖的共享 authority 变更必须保持其实际服务器检查;本轮不把 remote green 或旧 review 的测试数冒充本地独立执行,也不据此宣布新增 provider 被支持。
语义与 CI 对齐
现 head 扩展既有 checkpoint/Todo/Turn 的 purpose、stage 和响应词汇;不是新 actor 生命周期。新 phase 属于需要显式登记的共享协议增量;提案决策尽量复用现有枚举,capability 配置只表达调用者意图,不能成为第二套 Goal 状态。开发 advisory 与 full semantic 检查需要针对最终 diff 执行;仅有字符串扫描不能证明完整语义覆盖。
kernel 的 freshness、required checkpoint、scope、budget 和提交条件是机器义务,不能叫作可忽略 guidance。reviewer 的语义意见是 proposal;但当它被选为必要 checkpoint 的实现,未取得有效提案会阻止该阶段推进,不能把整个路径宣称为旁路建议。域中立要求适用于所有 Goal,避免把“代码交付/benchmark 分数”写进通用错误与判断枚举。F1 的已证明普通历史恢复已经修复;关闭态整体仍为 not_yet_proven,没有完成的 schema/prompt/accepted-input/persistence 配对证据保持 unverified,不能从几个通过的反例推广为完整隔离。
我的整体评价
当前实现包含值得保留的 justified_increment:真实 caller 已能绑定结果/方向依据并恢复原 Turn。当前 long_horizon=not_yet_proven、user_experience=not_yet_proven:F1 修复排除了已确认的普通历史恢复故障,但完整隔离和默认产品可操作恢复尚未 qualification;新的 capability/hook 分层也还没有实现。独立 reviewer 的净收益为 not yet proven,不能用多一层审视预设结果一定更好。
本轮 future-facing pass 的结论是:收口既有 terminal/checkpoint/Turn owner 与策略接口,保留真实历史消费者所需的兼容;不做全库 TS 重写,不造通用 workflow 框架。Python 继续承担必要 IO,相关语义编排回到既有 TS owner。原 MCP 版本、旧持久 receipt 的兼容应按独立升级边界保留;内部 co-deployed helper 的重叠分支则应能合并就合并。
建议分成三个有实际结果的 PR 阶段
建议把 #5677 调整为第一阶段,后两阶段引用它的具体交付;也可以用清晰标明 supersedes 的 successor 替换,但不要让两个分支并行维护相同 authority。以下是交付边界,不是要求机械按文件拆,也不要求一次性建立三个空 PR。
| 阶段 | 独立交付结果 | 必要范围 | 验收与剩余边界 |
|---|---|---|---|
| PR 1:结果/方向依据与原 Turn 恢复收敛 | 现有受支持 File/SQLite 路径能保护结果、拒绝 stale,并可靠恢复;保留 F1 修复 | 既有 typed result/checkpoint owner、receipt-first、相关 fence/unknown、必要 CLI/MCP 适配及精简文档;从核心编排拆出独立 Host 选择,但不单独发布空插件框架 | 真实首次提交、相关/无关并发、旧回执、崩溃、关闭态反例。若尚未接默认 host,明确这是协议/后端前置阶段,不能称默认产品能力完成;默认接入 owner 在 PR 2 |
| PR 2:基础保护进入默认产品路径 | 用户从已有入口正常交付,不需要 first-delivery 开关或手动搬 token;当前 Agent 基于新依据判断并能恢复 | 实际 managed/MCP/CLI 消费者、必要当前 Agent 续接、原配置/typed action/readback,以及 packaged frontend 的失败/恢复旅程;Lark 对应适用入口或明确未资格范围 | 无增强 reviewer 时走真实默认全过程,状态变化时重新判断,重启只恢复剩余阶段;验证配置/调用兼容、stop、no-followup;披露新默认和支持组合,更新旧默认测试与文档 |
| PR 3:可选方向复核 capability + checkpoint decision hook | 用户能在现有能力设置里选择独立 reviewer、看见有效范围/成本/不可用状态、关闭并恢复未完成判断 | 窄 phase 的 typed 注册/结果/生命周期 + 一个真实 Host provider + 现有配置编辑器/操作入口 + 端到端恢复,作为同一完整纵向包 | 默认关闭且与 PR 2 基础路径配对;成功/超时/非法输出/迟到/撤销/工具权限/主 session 保留;实际原 Turn readback;不以测试 provider 冒充 live-model 效果 |
PR 2 依赖 PR 1;PR 3 依赖基础判断/提交边界和实际产品接入。默认产品保护不应等待独立 reviewer 的模型效果研究,增强 capability 也不能只留下 CLI flag,把操作/恢复推到一个无限期 frontend follow-up。
每阶段至少有一个实际 caller 和失败后继续推进的证据。不要单独拆“只有 schema”“只有 serializer”“只有 hook registry”三个小 PR,反而让 reviewer 重建完整逻辑。若 PR 1 与 PR 2 的必要改动很紧密,应合并为一个可审查的完整基础交付包,而不是为了数量强拆。
只有出现真实第二个 provider、独立分发需求或已有实验结果需要代码变化时,才安排后续 provider/效果改进 PR。受控对照可以更新原 capability 的 qualification/checkpoint;不必为了“阶段 4”再造任务或外部插件 SDK。作者当前 PR 描述明确报告模型研究未通过 irrelevant-update gate;本轮没有独立重跑该研究,也不建议修改门槛来证明默认化。
回滚也按边界处理:PR 3 的增强策略关闭不应删除未决调用、历史 evidence 或基础 freshness;PR 2 回滚要检查旧二进制能否理解进行中的新 Turn;PR 1 已写入的新 receipt 格式需要兼容读回/迁移计划。任何回滚都不能偷偷消除尚未确定的提交,也不能重扣 quota。
下一轮请同时给出:最终 owner/capability/provider placement、调用链与失败语义、真实默认/增强两条旅程、F1 修复的反向保护及完整关闭态证据、兼容矩阵和阶段边界。先将可用的基础交付闭合,再用可选 capability 验证独立复核的价值。当前 head 保持 REQUEST_CHANGES,不涉及合并或忽略其他 review。
English verdict: REQUEST_CHANGES - 8ad8dc9. The updated head repairs receipt-first recovery for proven ordinary history; that old defect is not retained as a current finding. Changes are still requested for the maintainer-selected architecture/product boundary and incomplete full-surface isolation evidence. Separate default kernel freshness/recovery from an optional direction-review capability. Introduce only a narrowly scoped, kernel-supervised checkpoint-decision hook; preserve the existing non-blocking post-writeback contract, authority boundaries, original-Turn recovery and product readback. Deliver the core contract, default product adoption, and optional reviewer as cohesive stages with explicit compatibility and validation. The new architecture is a requested design direction, not a claim of shipped behavior or measured model benefit.
|
我 review 了一下,给了上面的建议 |
|
其中【现有 Post-Writeback RFC §5 明确禁止 optional hook 成为第五个 primary settlement step;hook 失败不得阻止对应 quota 结算。不能改它的 isolate 定义来承接本 PR。新增 phase 必须单独登记注册/输入/结果/恢复语义,复用现有 admission/typed validation 结构;共享机制不代表共享失败策略。】 这段酌情可参考或者不参考,maybe 复用和拓展 post writeback 也是一种选择,需要你评估一下 |
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
8ad8dc9 to
8979f57
Compare
|
PR1 scope adjustment is pushed at This is the permitted CLI/MCP protocol/backend prerequisite. Automatic independent direction Host execution, managed first-delivery enrollment, its attempt budget and terminal-only fields are removed from the final diff. Ordinary managed implementation, session behavior and its tests match main. Default owning-Agent continuation/product recovery remain the next stage; independent reviewer registration/input/result/recovery remain a separate stage. Post-Writeback §5 isolation and primary settlement steps are unchanged. Caller-authored direction now recovers stale post-result context by explicit reread and a new decision on the original Turn, retaining one result and one spend. The observer uses the existing checkpoint's explicit Validation:
Local study artifacts/raw logs/private planning stay excluded. This author update requests maintainer re-review of the narrower stage; it is not self-approval or a merge claim. 中文:本批收口为显式 CLI/MCP 基础保护与原 Turn 恢复。默认 Agent 续接、已提交结果修复和 protected terminal 改向由后续阶段闭合;独立 reviewer 另行登记完整契约。真实 File/SQLite 核心路径、并发 fence 与零写入拒绝已验证;普通 managed 代码与 main 一致,但其 Windows Codex fixture 剩余失败及广泛套件限制如上保留,请按新 head 复审。 |
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh
Reviewed exact head: 8979f570df27a6bf03bfb3e044fdcbcb4f143483. 重新核验当前完整 PR:51 files, +1886/-159。与上次已评审 head 比较时分开各自的 merge base;rebase 带入的上游改动没有被算作本 PR 新功能。
动机
在任务提交前后需要判断结果和下一步的人,可能读完旧状态后才提交:这期间另一个 Agent 已修改验收、依赖或工作集合,旧判断便不再适用。原有 checkpoint 恢复主要解决已写回 Turn 缺少方向记录的问题,不能据此证明首次提交也用了当前依据。这个 PR1 为显式选择保护的 CLI/MCP 调用方补齐有界路径:结果提交前核对所读依据,提交后另读方向,发生相关变化时只重做尚未成立的判断。可观察改善是保留成功结果和原 Turn,恢复方向时不重复任务或记账。本阶段交付后端前置路径;默认 Agent 自动续接、已提交结果修复、protected terminal 出口和完整产品旅程仍待后续阶段,不能据此宣布 Goal 完成或模型效果提高。
改动思路
沿用 Todo、checkpoint、Turn 和 provider CAS(比较当前版本后提交)的现有 owner,把结果依据与方向依据分开。关键规则由 TypeScript 判断,Python 捕获文件、提供 CLI/MCP 适配,模型判断和任务验证留在短锁之外。没有新增独立 reviewer 身份、模型调用、方向尝试预算或通用回滚权。
这次按上一轮 maintainer 接受的 PR1/PR2/PR3 分期重新审查,而不是要求 PR1 承担已明确后移的默认 Agent/UI 旅程。此前 managed enrollment、自动独立方向 Host、attempt-budget 及 terminal-specific 路径已从当前 PR 删除;原 Codex executor、普通 managed host 和其测试与当前 base 的 blob 相同,旧新增 reviewer 模块也在 base/head 均不存在。移除的是实际执行路径,并非仅改文案。
具体改动
spec_ref: docs/reference/protocols/goal-vision-replan-contract-v0.md; spec_revision: 8251ec80e0c327d28d13a1fd64e3f343a2aa3c0e(修改前规范)。独立分期依据是上轮 review #5425122971。逐项映射:Ownership Boundary 保留 Agent 自己判断方向及原有提交权限;Vision Checkpoint 保留 required/satisfied/not_required 区分,首轮 opt-in 要有当前方向决定;Read basis for checkpoint-only recovery 继续按原身份、当前依据和原回执恢复,既有 supplement 路径不被新 opt-in 替代;Acceptance 保留 agent-scoped checkpoint、status/quota 消费投影及无私有材料的验证。本次新增协议段是显式 first-delivery 扩展,不能反过来当作修改前规范的独立证明。PR1 的 CLI/MCP 前置阶段已交付,PR2 默认 owning-Agent 续接/产品采用、PR3 独立 reviewer 契约继续 deferred。
关键代码讲解
生产链路是 read_checkpoint_context → terminalDeliveryBasisCheck/原 Todo owner → resolveCheckpointReadContext → commitCheckpoint → 原 refresh/spend。结果提交在原回执恢复后检查相关事实、源文件及真实 provider head;无关 revision 重试不产生新判断,相关变化要求重新核验候选。方向提交验证完整 frontier 成员、用户义务、依赖、验收和 source identity。JSON/Markdown 有内容而索引未成立时保持 unknown;同 Agent 新 Todo/Turn 不能绕过未协调的原提交。MCP v2 三次调用分别读取结果、提交结果并读取方向、提交方向并结算;每一步提供新的正确性依据,原有 v0/v1 调用没有额外必填参数。
负向路径已独立运行:相关方向变化拒绝原 token,再读依据后恢复,同一原结果保留且只 spend 一次;protected no-follow-up 在新副作用前拒绝,普通旧 closeout 仍可用。历史观察损坏只给作用域内诊断,不能让其他 Agent 的 next-action 被覆盖;受保护原操作未知仍拒绝恢复写入。普通精确完成回执/可证明普通 writeback 可先恢复,不能把“JSON 读坏”猜作未开启保护。这也覆盖此前 F1 已修复的普通路径,未重新提出上一轮已撤回的无效损坏-fixture推断。
另以真实 CLI 和两个本地 provider 读取 1004 个 canonical Todos:agent_lane 精确保留 3 个本 Agent 项,goal scope 保留全部 1004 个,包括显示上限之外的最后一项;peer 工作没有被误算为本 Agent 义务。
本地验证:Python 176 passed(1 条既有 Pydantic 注解 warning);TS 聚焦 88 passed、15 个需 PG 的分支跳过,随后在隔离真实 PostgreSQL 16.2 上相关六套集成 450 passed、0 skipped。后者证明共享 owner 没有回归,不把新保护扩展为 PG 支持。不可变 base/head 上独立实际 CLI/MCP File/SQLite ordinary 调用、successor、cold replay、单次 spend 和未创建 protected history 的归一化观测完全相同。类型检查、Turn 生成一致性、286-site registry I/O manifest、全树语义 smoke、diff/public-boundary 检查均通过。没有查或等待 CI;没有改 active Goal/账本做故障测试;没有真实模型、付费调用或 packaged 默认 UI 验收。
对主干的风险
最强反例是已提交结果后 frontier 改变或方向写回中断:如果只看成功的 Todo,下一轮会错过当前义务或重复提交。本轮实际相关依据变化、torn append、丢失响应及精确 replay 均保留原身份和成功 artifacts,未增加第二次 spend;普通损坏 supplement 的可证明恢复与保护历史未知的拒绝分别测试。真实 File/SQLite 默认关闭对照相同,PG 只验证既有共享 owner,不声称新保护支持 PG。此阶段更多读取的历史成本尚未做规模测量,后续默认采用不能把该限制隐去。
语义与 CI 对齐
新 purpose、scope 和观察 stage 属于已有 Todo/checkpoint/Turn typed owner;read/status 是证据,实际拒绝是机器义务,不能说成建议。完整语义与生成检查已运行;CI 未查询或等待,APPROVE 不从 CI 颜色或作者声明推导。
我的整体评价
APPROVE,结论限于 justified_increment 的 PR1。长期正确性与恢复体验在这个边界内是正向:相关状态变化不再沿用旧判断,成功提交不会因方向重试再次执行或 debit;默认旧路径的额外操作为零。选保护时增加显式读取和决定步骤,这是正确性成本,不能将它宣传成已测得整体更快。历史 receipt 仍需完整扫描,尚未量化多 Goal、大量历史的持续读取成本;完整 Agent/App/Lark 体验和模型净效率继续未验收。此前宽泛多 Host 设计已经收缩到一个可独立验证、撤回的本地前置路径;继续沿原 owner 做后续产品采用,避免另建 reviewer 或结算决策源。未来整理已应用于同一恢复/依据 owner,当前没有必须再拆出的 speculative abstraction。该 approval 不自动解除旧 head 的 CHANGES_REQUESTED,也不授权合并或关闭业务 Goal。
English verdict: APPROVE this exact head as a justified, explicit local File/SQLite CLI/MCP prerequisite. Freshness, original-result recovery and single settlement are verified; default Agent adoption, protected terminal redirection, frontend journey, live-model utility and long-run cost remain outside this delivered stage.
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=xhigh
Exact reviewed head: 8979f570df27a6bf03bfb3e044fdcbcb4f143483; immutable baseline: 8251ec80e0c327d28d13a1fd64e3f343a2aa3c0e.
动机
面向从现有 LoopX 入口正常执行、交付任务的用户及其当前 Agent。执行期间 Todo、依赖或验收发生变化,旧依据上的结果和方向可能继续被提交;方向判断失败后,用户还可能需要手工恢复。希望普通执行默认核对结果依据,在既有 checkpoint 要求判断时由当前 Agent 根据最新事实作出新判断;保留合法结果,并从原 Turn 恢复剩余阶段,避免重复实施和结算。
当前 head 提供了显式 CLI/MCP 协议,但默认执行与完整产品恢复尚未接入。额外独立 Host 复核、模型普遍净收益、完整 Goal 验收及分布式原子性不属于本阶段完成声明。
本轮按维护者明确的第一阶段目标请求修改:基础保护默认化,并随现有产品入口一起交付;独立 Host 复核保持可选 capability + hook。 此前允许协议/后端前置先行的分期,以及 #5427697446 的有界 APPROVE,不替代这次的完整阶段要求。这是明确的交付边界调整,不是把已通过的 opt-in 底层机制重新判成运行时缺陷。
改动思路
当前实现复用已有 Todo、checkpoint、Turn receipt 和 settlement owner:读取结果依据 → 验证候选 → 原 Todo CAS 提交 → 读取提交后的方向依据 → 调用方提交新的 Vision/unchanged reason → 原 refresh/spend。TypeScript 保留依据判断与提交权限;Python 捕获来源、适配 CLI/MCP。方向和成功结果分开,旧判断不能自动换上新 token。
移除自动独立 direction Host、managed enrollment、临时 session 分支和方向尝试预算,是正确的解耦。下一步应把同一套基础保证接到正常执行链,由当前 Agent 续接方向判断;不是重新把旧的多 Host 整包开关改成 true,也不是要求每次 heartbeat 都增加方向推理。保留既有 not_required / typed in-flight 豁免、checkpoint cadence 和权限边界。独立 reviewer 后续通过 capability/hook 提供有界判断输入与结果,失败/恢复语义需明确,不获得 Todo、Goal、lease 或 quota 的写入权。
独立规范依据为修改前 goal-vision-replan-contract-v0.md,spec_ref docs/reference/protocols/goal-vision-replan-contract-v0.md,spec_revision 8251ec80e0c327d28d13a1fd64e3f343a2aa3c0e:Ownership Boundary、Vision Checkpoint、Read basis for checkpoint-only recovery 分别约束 owner、判断触发/豁免和原身份恢复。本阶段进一步默认采用来自当前维护者要求;本 PR 新增的 opt-in 文档不能反过来缩小该目标。总体 roadmap R1仍拥有持续执行与恢复结果,不以 receipt 或测试数量代替产品交付。
具体改动
当前完整 diff 为 51 files,+1886/-159:CLI/MCP 参数和 v2 分步交付、Todo 提交检查、checkpoint 读取/append 恢复、status/quota 投影、controller guard、生成与验证、协议/roadmap 文档。关键符号:checkpointBasisSnapshot 计算相关依据和完整 frontier;terminalDeliveryBasisCheck 在原回执恢复后检查真实提交 head;commitCheckpoint 在已有来源/provider fence 内提交并保留不确定性;evaluateHostTodoCompletion 组织 MCP 分步请求;pending_first_delivery_progress 供现有 readback 消费,不能授权提交。
1. 【阻塞】按完整第一阶段目标交付
| 第一阶段验收 | 当前 head 的缺口 | 请求的交付结果 |
|---|---|---|
| 结果 freshness 默认生效 | 只有显式读取 delivery_result 并传 --delivery-read-context 才进入保护 |
正常受支持执行由 owning caller 自动携带真实读取依据,在原 Todo owner 提交时检查 Todo、依赖和验收;相关变化先重新验证候选,无关 revision 不强迫重新判断 |
| 既有 checkpoint 要求方向判断时使用最新事实 | MCP first_delivery 默认 false;调用方需再次读取并传两个 read ID;默认 managed 未接入 |
当前 Agent 自动读取提交后的事实,作出新的 Vision/unchanged reason;基础保护不依赖独立 reviewer 的可用性,也不把旧判断重绑新 token |
| 合法结果保留与原 Turn 恢复 | 底层机制已具备,但正常执行和重启后的续接未完成产品验收 | 方向失效、响应丢失、重启后恢复原 Turn,只继续尚未成立的阶段;已提交合法结果与 quota receipt 保留,不重复实施、写入或扣额 |
| 普通完成、终结与状态变化后的恢复闭合 | protected no-followup 在本阶段被拒绝 | 补齐合法 terminal/no-followup 与新 frontier 出现后的恢复/改向出口;不能让默认用户进入一个只会拒绝、无合法续接的路径;不绕过既有独立验收或凭空创建无意义 successor |
| 现有产品入口可以操作、恢复、读回 | status/quota 已有投影,但默认 managed 与 packaged frontend 旅程后移 | 在真实 owning backend 上走通正常执行和失败/恢复;通过既有 frontend/CLI,以及适用的 Lark 入口读回结果、当前 pending 阶段与可执行下一步。用户不需要手动搬 token;投影不能只显示诊断而没有恢复操作 |
| 默认变化可审查、可回退 | 文档仍定义为 default-off 的后端 prerequisite | 同步披露最终默认行为、支持组合、旧参数/receipt 兼容与已有进行中 Turn 的恢复/回退边界;调整编码旧默认的测试和文档 |
请把本 PR 的实现与验收面向这个阶段收口,而不是通过把默认接入、终结恢复和产品旅程继续后移来降低目标。可以按 owner 分成可审查的提交;若确需依赖 PR 配套,应明确同一阶段的交付依赖与验收结果,不能把“前置 PR 可用”报告为“第一阶段完成”。复用现有 typed owner 和配置/交互面,不新建平行 freshness capability、决策源或通用 workflow 框架。
下一轮请提供:不带 first-delivery opt-in 的实际默认调用链;结果/方向发生相关变化的反例;原 Turn 的响应丢失和冷恢复;普通 terminal 与 changed-frontier 续接;必要产品入口的 packaged 操作及 owning state 读回。保留 stop、权限、现有 checkpoint 豁免和旧 supplement 恢复。开启基础保护不要求同步实现独立 reviewer。
2. 【研究建议】选一道 EdgeBench 题做对照与机制分析
建议选一个任务做小规模研究,优先考虑已有资料的 portfolio_risk_calibration,或另一个能观察多轮候选验证、结果保留和方向调整的任务。目的不是只交一个最终分数,而是回答:基础 freshness 在什么条件下纠正了旧判断?是否减少重复工作、避免丢失有效结果?新增读取、判断和恢复步骤的成本是多少?何时它没有帮助,甚至形成过度重判或停滞?
请接续已有 LoopX 研究,不另起一套实验/评分 authority:
- 中文调查:EdgeBench 的反馈、记忆与长程执行问题;对应 #5649。可先看 prompt、评分契约、会话连续性、提前结束及证据采用的混淆因素。
- Portfolio 十组实验报告与逐组配置。历史样本跨 evaluator/source cohort,不能直接当作本 PR 的 matched baseline,也不能据此宣称因果收益。
- 公开脱敏轨迹与精确配置。适合选事件做机制分析;请同时阅读 dataset card 的选择与脱敏范围,它不是完整原始轨迹。
- 当前 EdgeBench 运行指南及共享默认与消融配置指南。尤其核对 product/runner 两个 source pin、planned/seeded entry、有效工作 Turn cadence、反馈和 resume 的实际配置;当前新运行的默认与历史配置并不相同。
- S11 长程 Harness 研究 RFC:区分原生结果证据与机制研究,保留 benchmark-native verifier/score authority。
最小有用对照:固定的主干基线 vs 完成第一阶段的新默认路径;两组冻结题目/完整 evaluator、镜像、模型/effort、反馈、Host、runner、task entry、cadence、时间/token 预算和采样设置,只改变本研究的基础保护。为每组创建新的 attempt,核对实际安装版本与机制采用。可先一对试跑寻找机制问题,再以少量 matched repetitions 区分随机波动;不要挑最好的一次或混合版本曲线宣称提升。独立 reviewer 的增量效果留给后续单独对照。
同时记录 native best-so-far、last observed、终态工件独立复测、耗时/token、有效工作 Turn、重复实施/提交/扣额、stale 拒绝后的重新判断及恢复。挑出“原依据 → 候选验证 → 提交/拒绝 → 新方向 → 后续结果”的具体事件,说明证据是否真的被当前 Agent 采用。若任务自然没有触发相关状态变化,如实报告;另用同题的隔离故障实验验证相关/无关更新、丢响应和重启,标明它与官方原任务运行的区别,不改题目或评分来制造收益。交付简洁、可核验的 comparison + insight,负结果同样有价值;原始日志、凭证和私有状态留在实验侧。
这一点是研究建议,不把单题分数改善设为第一点确定性正确性的替代,也不要求先证明独立 Host 的普遍收益才交付默认基础保护。
对主干的风险
当前默认链仍可绕过这套新保护。最强反例是执行期间相关义务变化,普通 caller 没有 enrollment/read identity:opt-in 的所有测试都可能通过,却不能证明默认任务已获得保护。另一边,若直接把默认 false 改 true,而 managed/terminal/产品恢复尚未采用,可能把普通用户送入需要手工再次调用甚至只会拒绝的路径。应在原 owner 接入完整默认链,同时守住可继续推进和合法停止的边界。
默认路径也不是完全没有增补:共享 status/quota 会观察历史 receipt、展示 first_delivery_progress,对已参与的 pending Turn 更新 next-action,并隔离无法归属的损坏历史。区分新增观察成本与默认提交的 freshness;当前尚无历史规模/持续读取成本测量,研究中应保留这一限制。
本轮独立重跑:真实 File/SQLite CLI/MCP stale-direction 恢复、原结果/单次 spend、ordinary cold replay、历史损坏与受保护 no-followup 零新增效果,相关 Python 40 passed;checkpoint/Host/projection TypeScript 30 passed;Turn 生成一致性、全树 semantic smoke 与 diff check 通过。语义 advisory 检查 29 个 changed source snapshots,0 个受支持候选,不作为“无新语义”的证明。semantic smoke 首次因恢复 checkout 尚未安装 npm dev dependencies 而无法执行;按既有 bootstrap 安装后完整重跑通过,未改断言或预算。没有独立重跑本地 PostgreSQL、完整 packaged UI、实时模型或 EdgeBench scored study。远端已有部分检查成功、部分 queued;pending CI 不是本轮请求修改的理由。旧 review 的测试数字不作为本轮独立执行结果。
语义与 CI 对齐
purpose/scope/stage 是已有 Todo/checkpoint/Turn owner 的显式扩展;freshness 拒绝属于机器义务,next-action 属于观察/指导,两者不能混写。first_delivery=false 和显式 read 参数说明当前 activation;可见 capability、receipt 投影或状态字段不等于默认采用。没有新增 actor 写权限或 Goal 完成证明。后续必须披露真正的默认变化,并让 required checkpoint 判断和可选 Host/provider 的失败策略分别有明确契约;共享 hook 基础设施的具体复用方式可评估,不能默默改变既有调用的失败隔离语义。
我的整体评价
REQUEST_CHANGES。第一点阻塞:请完成维护者明确的一阶段“默认基础保护 + 现有产品闭环”。第二点建议:用一个 EdgeBench 任务做版本匹配的对照和 insight 分析,并接续上面的研究资料。 当前底层 freshness、结果保留和恢复方向值得保留,去掉自动多 Host 是合理收敛;停止在 default-off prerequisite 不满足这次交付目标。长期推进和普通用户恢复体验仍未在目标默认路径上被证明,不能用 CLI opt-in 成功或 test counts 替代。
future-facing pass:保留当前 Todo/checkpoint/settlement 的单一 typed owner,优先补默认 caller adoption 与合法 terminal/recovery seam;独立 reviewer capability/hook 留到真实后续契约,不为本阶段加入 speculative registry、并行决策权或测试专用产品结构。本 review 不合并、不 dismiss 既有讨论,也不启动 benchmark 工作。
维护者已授权补充联系方式:如果需要就一阶段边界、实现方案或实验设计进一步讨论,可以加维护者微信 huangrt00。
English verdict: REQUEST_CHANGES - exact head 8979f57. Deliver default core freshness, current-Agent checkpoint continuation, original-Turn recovery, terminal handling and the existing product journey as the maintainer's complete first stage; the explicit CLI/MCP prerequisite is insufficient for that target. A matched single-task EdgeBench comparison with mechanism insights is recommended, with current LoopX research links provided. Independent checks passed 40 Python and 30 TypeScript tests plus generation/semantic/diff checks; default product adoption and live-model utility remain unqualified.
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; reasoning_effort=max.
四个 P2 仍需处理,以下结论绑定完整 ee0f07dcbdcf290f9e8cfcd0d0a6e0ace4d61872:
-
历史观察应复用一次 typed settlement snapshot。
pending_first_delivery_progress在每个历史身份上调用完整结算读取;readQuotaSettlementSnapshot每次重读 events/runs。我的真实 File/SQLite 单已结算身份观察均返回无 pending,却各有 inspect_history、settlement.read、work_binding、evaluate 四次 RPC;每身份重复重建由当前循环直接可见。这不是 1000 条历史延迟或 token 的实测。请用已有 snapshot/batch owner 一次覆盖完整历史,保留最旧 pending、失读/损坏、来源变化、跨 Agent 与原身份一次效果,不能截断或另存一份 settled 缓存。此项对应当前维护者 CR1 与 S7。 -
独立 public-boundary 放行政策应拆出。
contract.py的 public_fixture_allowances、public_credential_placeholders 和扫描 allow/block 分支有独立 caller、隐私决策及回退边界,不属于原任务 freshness 的必要实现。依当前维护者 CR2 单独提交完整可评审政策和现有正反例;保留必要 Windows/私有 IO 保护,不能靠删有效覆盖缩小提案。默认关闭并不能解释为何需要同一发布边界。 -
原已报告的 replay 导入仍未修复。 当前已提交
HTTP fixture仍从删除前的loopx.chat_coordinator_checkpoint导入。我重新执行后真实 resume 返回200、result=1、debit=1、dispatch=1;随后 replay 确定ModuleNotFoundError、exit1,后续断言未到达。应改为loopx.hosts.chat_coordinator_checkpoint,完整跑通 replay/unavailable/restore 并保留断言。这里只证明验证消费者坏了,没有误报生产重复扣费。 -
当前新加入的维护预算失败必须同批结清。 标准 premerge 实际报告
chat_server.py从2020到2025行超过保留的2020 ceiling,并把新native_admission_observation标为未审 oversized decision function。请按现有 budget guide 比较同一 base/head 的职责、信息价值与代价后做有界收敛,或提交有证据且允许的审查基线决定;不能仅抬阈值、删有效语义或引用旧 head 的绿测。
动机 / Motivation
普通长任务的执行 Agent 和从原对话恢复任务的用户,会遇到执行期间要求变化、结果已经保留却仍欠方向判断或结算的情况。 例如任务完成后验收要求改变,系统应保留已完成结果,在原身份下让当前 Agent 核对新事实,再只补欠缺的步骤;用户不应复制事务信息或重复实现。
当前 HTTP 恢复确实得到一次 dispatch、result=1、debit=1;但完整重放夹具仍导入已删除模块而退出,历史观察也仍为每个身份重建结算快照。 可用的原结果保护值得保留,但不能把单次成功等同持续闭环和完整恢复。公开完整 replay 仍失败;默认历史观察未复用现有整段快照;独立 public-boundary 放行政策仍捆绑。安装/真实模型/长期净收益不在当前证据内。 标准 premerge 还暴露新加的模块/函数维护预算债务。本次不要求整个 controller 迁移、正式安装或新增付费模型实验;长期净收益与匹配完整成本仍是独立未证边界。
改动思路 / Approach
原工作依据、结果后的当前 Agent 判断和原身份恢复有可用增量,但当前提案必须先修复观察路径的重复整段历史读取,并拆出独立公私扫描政策。 当前可接受切片是同一工作依据→结果提交→按既有 checkpoint 要求判断→原 Turn 剩余结算→既有产品读回;平台 IO 保护可保留其必要前置,独立扫描放行策略应单独审查和回退。
核心路径仍应复用 typed checkpoint/Todo、原 journal/settlement,Python 负责必要来源与 Host/provider IO。原始依据是需要持久保留的事实,当前状态和 pending 展示从其派生;它不要求第二份手工同步状态。当前 Agent 的必要方向判断与可选观察 hook 分开,后者失败不制造新的主任务义务。
较小的完整修复是在原 owner 批量读取同一不可变结算快照,继续核完整历史和未知,再在原 Host 中补欠缺阶段。内部模块移动应更新实际消费者;独立扫描政策按自己的行为和回退边界评审。现有 C1/C4.3/C9.2 是复用和后续收敛方向,不要求先完成所有 controller 或研究工作。
具体改动 / Changes
接受框架:https://github.com/loopx-project/loopx/pull/5677#pullrequestreview-5430701531,不可变 review-5430701531;另按本轮维护者 CR1/CR2重判完整提案,而非沿旧批准轨迹继续堆修复。
| 原框架映射 | 本头证据与边界 |
|---|---|
| 默认原工作依据 | 已在原 typed owner 接线;沿旧精确版本原生证据与本头 blob 失效检查核对,不冒称重新安装。 |
| 当前Agent判断 | 当前真实 HTTP 通过原 store/controller/checkpoint,只有一次合成 SDK dispatch;独立 reviewer 仍非必需。 |
| 原身份恢复 | 当前正向 result1/debit1,但完整 replay 夹具失败,验收尚不完整。 |
| 合法终止与完整义务 | 原 terminal/frontier/receipt 恢复 owner 保留;旧验证按其原版本复用,不制造 successor。 |
| 产品入口 | 原运行栏/不可用恢复整页源未变;本次实际 HTTP 正向另验,完整 replay 缺口不能由画面填补。 |
| 默认与兼容说明 | 新默认、历史准入与回执边界保持;新增 display carrier/测试批次限额明确披露,非生产 SLO 或执行额度。 |
本次按真实 target merge base 4b2b97b7b726d902a20969e3911fd15d15b4bb2e 盘点 256 paths,+17199/-1315:20 个相对9394的变化逐项读完,其余236个旧审路径 blob 相同。旧240计数使用与f5的直接比较,不能当本次完整 diff 计数。新增部分涵盖 HTTP 私有回复在 composition root 的拼接、观察/预算语义、Windows私有IO分支与对应测试;完整权威路径仍作为整体判断。
当前相关四模块 274 passed,另14个原生 Windows 用例在 macOS 跳过;20路径中的 Python delta Ruff 通过。实际公共 HTTP fixture 的成功与失败分别保留。真实 File/SQLite 的已结算观察确认四次 RPC、源/索引/日志不变;大历史成本、Windows预算数字、真实模型和长期收益没有据此宣布通过。标准 premerge 为5/6直接检查通过,目录9/10、风险8/8、公开边界1/1;两个出现位置指向同一维护预算检查及其具名债务,另有1个原benchmark人工hold。总体未通过,精确CQR也因已复现的replay失败为fail;未把局部成功汇总成全绿。
对主干的风险 / Risks
最高风险是默认历史观察随累计状态增加重复整段读取,以及无法完成已提交的恢复验收;独立扫描放行政策还扩展了通用隐私决定面。修复应沿现有 snapshot owner,保留失读、最旧 pending、跨 Agent 和来源变化语义,避免“只看最近若干项”掩盖旧义务。
历史原生/typed/真实 PostgreSQL 与整页证据保留各自 revision,并通过逐 blob 与20路径 delta 判断复用范围;这次没有重跑新 PG、Windows、真实模型、正式安装或付费实验。新420/960秒限制是测试批次界限,不能宣称生产性能资格。没有查询远端 CI,也没有合并、安装或 dismiss 其他评审。
审查期间 target main 又合入 #7590/#7591 至 fb331f45c355152a4c1658af1e097f60a5840154。已核对相关 native capture 与 decision-stage 文档变化:新分阶段设计明确不撤销现行完整读取义务;它未进入本提案。本 PR merge base 和256路径集合不变,三条运行/范围事实与新预算失败不受此更新消除;未来整合应按新头重验实际输入与共同 owner。
我的整体评价 / Verdict
REQUEST_CHANGES。problem_context=justified_increment,但完整提案的 proportionality 需 simplify_now:保留已证明的原结果保护,先完成共享观察读取、政策分离、实际 replay 消费者修复及当前必需预算门。上述最小修复可在现有 owner 内独立审查,不以整个父级 roadmap 完成为前置。
长程效果和完整用户旅程仍为 not_yet_proven:单次恢复和前端状态成立,完整 replay 及历史增长下的持续成本尚缺。实际查看过 a80 打包整页的保留结果、暂停及观察不可用三态;本次 UI 源 blob 与其相同,因此仅复用这些具体视觉观察,当前 HTTP 另行运行。画面仍属于 a80 打包源和合成导航/SDK,当前源码/HTTP读回另验;正式安装、真实模型、Windows/live Lark和完整重放未获本次资格。没有把恢复技术资格或较大测试数提升为模型采用、长期效果或效率收益。
English verdict: REQUEST_CHANGES — retain the useful original-result recovery increment, reuse one existing typed settlement snapshot for historical observation, separate the independent public-scan allowance policy, and fix the still-broken committed replay consumer. Complete head: ee0f07dcbdcf290f9e8cfcd0d0a6e0ace4d61872. No duplicate production debit or matched long-horizon benefit is asserted.
…ions Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
|
CR3 的职责收敛已落到代码与协议表:现有 TS owner 统一方向返回分类/receipt 转换,Python 保留 Host 与锁内 IO;原工作读、结果后方向、原 no-followup、attempt/response binding 和 v0/v1/v2 的实际消费者保留。没有新增第二个协调器或 receipt-to-continuation authority,也没有把历史可读误当作可以删除现有生产者。 CR5 沿已有 fixture 参数化 File/SQLite 历史增长;方向 owner 移动后,同一 Host-return/持久化边界的故障注入也已适配,原退出、恢复、来源丢失、原结果/身份和零重复效果断言保留,受影响重跑 50 passed。 当前仍明确保留资格限制:两项并发默认读取在原 head 也复现 Windows 5秒 admission 锁超时;新 main 的 native-context EOF 测试在 Windows 不支持的旧入口失败,并在非 freshness 分支复现;当前 head 本地真实 PostgreSQL 未资格。完整通过/失败/未测、最新 packaged HTTP/browser 与桌面/窄屏证据都已写入 PR 描述,没有将历史测试或 runner-invalid 研究结果重标成当前通过。 CR4 后续研究仍需 baseline / freshness information only / full mechanism 的同材料、同预算、有效 runner 对照。本次未启动付费实验,未宣称普遍收益。 Author follow-up only: the implementation is proposed for review; dependency and qualification gaps remain, with no approval or merge claimed. |
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max
精确 head:3ed36655a20fef816a31038010be4ef16aafd549;完整差异基点:898363635d4737f84b6a673a9a11265a121b6f57。这是当前259路径的整审,另列相对上次 ee0f07d 的修复判断,不继承旧批准或把旧测试换成新头。
REQUEST_CHANGES:当前必需验证仍未通过。 两个维护债务仍在:chat_server.py 的2020→2025行超过原2020 ceiling,native_admission_observation 是新增未审 oversized_decision_function。当前全变更 Python Ruff 另有两项新 F401:chat_store.py 的 time、windows_extended_path。不可变基点的同维护 smoke 和同文件 Ruff 均通过。请有界修复,保留语义与有效覆盖,按新头重验。
动机 / Motivation
普通长任务的执行 Agent 和从原对话恢复任务的用户,会遇到结果已经保留、方向判断或原轮结算尚未完成的情况。
例如工作完成后要求变化,系统应保留已有结果,让当前 Agent 按原身份核对当前事实,再只补欠缺步骤;用户不应复制事务信息、重复实现或另找一个 reviewer。
当前完整打包 HTTP 路径已保留同一结果、原会话和原身份,完成一次方向 dispatch、一次扣额,重放与观察恢复不追加效果;默认历史观察已改为一次共享批量读取。
本次不要求整个 controller 迁移、正式安装或新模型实验;真实模型后续采用、匹配完整成本和长期净收益仍未获资格。
必需维护预算仍有两项新增债务,Ruff还有两项新增未用导入;当前PR还与main冲突,需作者整合后重新按精确head验证。
原接受目标是一个普通任务的可用闭环,不是增加检查记录或把每个动作变成独立 reviewer 门。保留已完成工作并在原轮补方向与结算,有直接价值;默认状态观察也不能因历史越来越长,反复为每个身份重读整段历史。当前这两层已走到真实入口,剩下的必需质量失败应在本提案处理,不能以一次恢复或大型测试数字替代。
改动思路 / Approach
原工作依据、必要的当前 Agent 判断与原身份恢复应由已有 typed checkpoint/journal/settlement owner共同完成;当前历史观察已复用一次完整结算快照,独立公私扫描政策已退出本提案。
当前 PR 边界是原依据→保留结果→既有要求下的当前 Agent 方向判断→原 Turn 剩余结算→现有 CLI/产品读回;必要平台 IO 防护保留,7602/7603独立前置尚未合入时不冒称已完成拆分采用。
完整机制仍有三种职责:规范依据和结算是正确性不变量,由 TypeScript owner 判定;宿主运行、文件原子写和 provider 读写是原 IO 责任;状态栏及历史观察只投影事实。只读观察无权修复收据、启动宿主、选择后继或扣额,来源不确定仍显示 unknown。必要方向判断由当前 Agent 完成,独立 reviewer 不是新强制条件。
| 上次问题 | 当前完整头观察 | 结论 |
|---|---|---|
| 每个历史身份重建完整结算快照 | 原生 N=1/3/5 均一次 bridge;完整index各读2次、event读1次 | CR1修复成立 |
| 独立公私扫描放行政策混入 | contract.py 与当前基点一致,当前完整差异无该政策 | CR2这部分已退出 |
| HTTP重放导入旧模块 | 当前提交夹具完整走过 replay、unavailable、restore | 原问题已解决 |
| 必需维护预算与静态检查 | 当前2项未审债务、2项F401 | 仍阻断 |
表格记录不同阶段的实际观察边界,不将更少读取次数当成完整费用或模型收益证明。
具体改动 / Changes
独立接受依据为维护者当前 review: #5677 (review) ,spec_revision:review-5685607407;同时保留原 review-5430701531 的默认原依据、当前 Agent 和原身份恢复框架。先读 accepted 方向和当前主干合同,再判断新实现;新改文档不自行认证接受。
CR1:implemented。共享现有 settlement snapshot,完整历史不按展示窗口截断,也不增加第二份 pending 表。CR2:implemented,指当前公私扫描政策已移出;平台保护仍保留,7602/7603尚未合入时不声称已采用其共享实现。CR3:implemented,限定当前实际 caller 的 owner 收敛与可用闭环,不要求同时完成未来 controller/C1/C2。CR4:deferred,三臂真实模型策略研究没有本轮执行授权,不是新增资格门。CR5:deferred,进一步合并同形 fixture 是维护建议,不能删除真实负例;当前继承的必需维护失败另须实际修复。
当前完整差异259路径、+17580/-1313:生产124路径+5731/-698,测试/夹具119路径+10726/-607,文档14路径+1121/-8(含四个PNG),生成文件2路径+2。与上次头比较235个当前变更 blob 相同,24个当前路径变化均已读完;也检查了实际基点、共享 caller、依赖及移出的扫描政策,未仅审最后一个修复 commit。
关键代码讲解
- pending_first_delivery_progress 仍从规范 Todo 和完整来源构造观察输入;现在一次交给 turn.first_delivery.observe,保留历史 receipt_names 的顺序与原身份。Python 不再逐身份桥接整段 settlement。
- observeFirstDelivery 复用严格 checkpoint history 与既有结算快照。两种解析对不完整尾部有不同义务,分别捕获一次并比较完整 index digest,不能混合变化中的来源。旧 pending、损坏/删除可恢复 proof、无法归属的坏记录和跨 Agent 范围都有真实反例。
- direction_return 收敛既有 Host 返回分类;wait、需要用户、失败、停止及成功仍绑定原 receipt,保留 attempts、原因与 response binding。checkpoint_continuation 负责已有 Host/锁内 IO,不成为第二份决定规则。
- readQuotaSettlementForAdmittedOwnerFromSnapshot 在同一规范 owner 和 snapshot 上读原身份,避免重建历史;不根据结果状态猜新业务准入。
- CoordinatorCheckpoints 沿现有 Chat HTTP/controller/store 恢复。公开 fixture 的旧137行导入已更正,当前完整打包实路终于到达所有重放及来源恢复断言,无须保留旧 module shim。
对主干的风险 / Risks
当前独立执行11个 Python 模块271通过、0跳过;8个 TypeScript 模块293通过、0跳过。原生 File/SQLite 的 N=1/3/5 已结算历史实际测到每次一个观察 RPC、两个完整index读取和一个事件读取;typed real-dispatch 的0/1/100/1000条,覆盖 intact、damaged、deleted,以及最旧未扣额、错误身份、尾部损坏和中途index变化。它们证明这条观察不再为每个身份重建整段快照,不证明整体线性时间、tokens 或美元净省。
隔离真实 PostgreSQL 16.15 store385、service11通过,0跳过;使用独立数据库,已回收本轮服务器和匿名卷。最初 service 环境只给一个 URL 的9过1跳过保留,随后补齐其已声明环境后11过,不把早期跳过直接改写成通过。当前构建及完整生产 HTTP/controller/store 路径成功:结果1、扣额0→1,方向 dispatch1、实现 dispatch0;原session/上游thread/identity及结果SHA保持。重放、4次 reload、来源不可用后只读重查与恢复均无新增效果。SDK确定性、外层导航合成,未调用真实付费模型。
保留上次 ee0f 的实际一身份4次RPC和旧导入失败;本轮额外旧头历史敏感性 driver 在规范 fixture 创建阶段就被拒绝,未得到有效观察,不能拿它当旧版规模/延迟测量。当前原生/typed history用例和此前具名来源承担已报告结论。更早六/八项 native、Windows 或科学诊断失败仍归原版本,未以本轮271测试宣布整仓或所有历史问题消失。
仍需修复的两项当前问题:
- 必需维护预算:标准 premerge直接5/6、catalog9/10通过,risk8/8、boundary1/1通过,整体失败且5个原人工 hold仍在。immutable 8983636 的同维护 smoke 通过、unreviewed=0;当前两个具名债务不属于无关基线红灯。按既有 budget guide 比较职责与信息价值,再做有界收敛或有依据的审查基线决定;不只抬限制、删断言或截断义务。
- 必需 Ruff:当前变更文件只报 chat_store.py 两项 F401;相同基点同文件 lint 通过。删除未用 time/windows_extended_path 即可,保留有用的 replace_retry_seconds=0.5 和共享原子写路径。配置指定17文件 mypy、完整 TS typecheck、diff、双语及58个提交 DCO 已通过,不能抵消 Ruff 失败。
语义与 CI 对齐
这是被接受的新默认正确性保证,不能把它虚称 opt-in 策略;历史准入仍按已保存原政策解码。当前 Agent 必需方向阶段与可选观察/记忆 hook 分开,后者不能制造新义务。新的批量 observer 复用原 typed 身份、purpose 和结算 owner;unknown、真正 Stop、原无后继终止与剩余义务均保留,未按正文子串推断权限。新文档的 consumer/退出表和预算资格仅描述实际边界,不授权截短指令或把历史 runner_invalid/countable=false/n=1改成研究通过。未查询、轮询或等待 CI。
我的整体评价 / Verdict
当前完整源码有可用增量。long_horizon:preserved,已保原工作承诺、身份和后续恢复,且观察增长反例有当前实证;持续自然模型采用、完整成本和净收益仍未证明。user_experience:improved,原对话只补欠缺阶段并读回,不增加身份复制、独立 reviewer 或新确认轮次。上述结论限于实际受测的源码和打包恢复边界。
原工作依据、必要的当前 Agent 判断与原身份恢复应由已有 typed checkpoint/journal/settlement owner共同完成;当前历史观察已复用一次完整结算快照,独立公私扫描政策已退出本提案。 当前 PR 边界是原依据→保留结果→既有要求下的当前 Agent 方向判断→原 Turn 剩余结算→现有 CLI/产品读回;必要平台 IO 防护保留,7602/7603独立前置尚未合入时不冒称已完成拆分采用。
本次实际查看了当前3ed打包整页的保留结果、暂停与来源不可用状态,桌面及390窄屏均包含产物卡、团队空态和底部输入;功能断言与视觉观察分列。 四张当前提交公开合成PNG也逐张查看,未见私有上下文。默认/暂停/不可用构图可读,但折叠、数据正确或无溢出不单独证明视觉效果。视觉未验证范围:正式安装、真实模型、原生Windows/live Lark及完整长内容成果详情不在本次打包恢复场景资格内;合成导航和确定性SDK边界保留。
REQUEST_CHANGES 保留给当前明确的必需维护和 Ruff 失败;不再重复已修复的 CR1、扫描政策或旧导入 finding。当前远端 DIRTY/CONFLICTING,作者整合后必须以新 head 再做适用整审与验证。本审查不授予 merge、dismissal、安装或新实验,也不要求额外模型研究才能完成这次有界修复。
English verdict: REQUEST_CHANGES — 3ed3665. The complete259-path proposal now reuses one full historical settlement snapshot, removes the unrelated scan policy, and passes the real packaged replay/unavailable/restore journey. 271 Python,293 typed and385+11 real PostgreSQL tests pass. Required premerge still has two introduced maintainability debts, and changed-file Ruff has two introduced unused imports; immutable-base checks pass. Preserve the useful recovery and repair those bounded failures, then requalify the integrated exact head.
| from loopx.control_plane.content_digest import ENVELOPED_SHA256_PATTERN | ||
|
|
||
|
|
||
| def native_admission_observation(payload: Any) -> dict[str, Any] | None: |
There was a problem hiding this comment.
[P2] 结清本提案引入的两个必需维护预算债务
当前标准premerge仍在两个必需维护债务失败:chat_server.py从2020增长到2025超过原2020 ceiling,新增native_admission_observation形成未审oversized_decision_function。不可变898同一维护smoke通过、unreviewed=0;当前unreviewed=2。请按既有budget guide有依据地归属/收敛或结清同diff审查基线,保留完整语义与断言;不能把5/6直接与9/10catalog写成全过。
There was a problem hiding this comment.
已在 c0bc9f61212274734e5f15ca9b40667e43983469 修复,并整合 main 544aa0fee 的六处冲突。
native_admission_observation 在原模块内分开成本测量与 quota 身份观察:原函数 41 statements / 64 decision points,现两个函数为 23/23 与 20/41;90/60 上限不变。107 组同输入的值/异常类型对照一致,完整维护及 CLI-output differential 195 passed;原身份、非法输入和增长断言保留。
Chat 的五行保留在 HTTP 组合 owner,为选定分页拼接 provider 回复历史;不下沉到通用投影。相同文件边界 2020→2025 行、Any/dict[Any] 仍 25/0,仅将该文件已审行数基线校准为 2025,不额外加余量,依据已写入 budget guide。整合后 collaboration_mcp 降到 1949 行,撤销其旧 2083 行豁免,恢复默认 2000 行约束。维护测试仅对齐原先已审的 cadence 依赖,zero-unreviewed/zero-stale 及负例全部保留。
精确新 head 原维护 smoke 为 unreviewed=0、stale=0;standard premerge 的 direct6/6、catalog10/10、risk8/8、boundary1/1 均通过,5项人工 hold 仍保留,整体为 manual_review_required,未写成整体通过或 merge-ready。首次临时目录嵌套仓库导致的两个 Git 敏感夹具失败另保留,改用仓库外隔离目录后,相同检查通过,未改断言。
新 head 还通过 303 项 typed 回归、完整变更 Python Ruff、TS typecheck、17文件 Linux-platform mypy,以及重建后的 packaged HTTP/controller/store 恢复、重放、不可用重查和来源恢复。扩大原生矩阵仍在收集,Windows 夹具及 PostgreSQL 资格边界单列在 PR 正文;这些数字不替代完整资格或独立评审。原3ed的两项维护失败不重标为通过。
There was a problem hiding this comment.
最终作者修复已推至 5d2772c64a86322b69ebd4fc452b283c6705f885,PR 正文已按修订来源更新。
两项维护债务、两项 F401 和 main 冲突已处理;共享原子写重试、身份/幂等及负例断言保留。集成过程中发现的 Windows 会话、journal 和 sidecar 长路径恢复,以及原 Turn 重规划顺序也已补齐。完整变更 191 个 Python 文件 Ruff、配置内 17 文件 mypy 和最终 5 项定向回归通过;先前的 8 项实际启动/恢复、13 项 sidecar、2 项重规划回归分别保留,数量不合并。
最终 standard premerge 在短且隔离的仓库外临时根得到 direct6/6、catalog10/10、risk8/8、boundary1/1,整体仍为 manual_review_required,5 项人工 hold 未绕过。嵌套长临时根的原失败也保留:目标 main 与 head 均复现 252 字符数据库路径的 SQLite WAL 初始化错误;缩短测试临时根不代表修好了这个独立存储缺口。
当前提案的 GitHub merge 验证已通过 PostgreSQL 16.15:store385、service11;实际 job。其余 CI 尚未完全结束;mutants job 的断言执行完成,但 artifact 上传 ETIMEDOUT 使检查失败,单 job 重跑被 GitHub 以 workflow 仍在运行拒绝,未宣称恢复成功。
三 Turn 的首轮 base/head 耗时为35.0/73.7秒;带并发干扰的复测16.8/74.4秒单列。只调整 Windows 外层测试看门狗,产品超时/配额不变,不宣称性能改善。历史失败、POSIX-only 跳过、平台前置 #7602/#7603 与精确 head owner 复审均保留;未合并。
English: Required review fixes are implemented and pushed. Applicable local checks and current-proposal PostgreSQL CI passed within their stated boundaries. Historical failures, SQLite long-path initialization, extra elapsed cost, unfinished CI/artifact-upload recovery and independent review remain explicit; this is not merge readiness.
| from pathlib import Path | ||
| import re | ||
| import threading | ||
| import time |
There was a problem hiding this comment.
[P2] 删除 chat_store 新增的两个未使用导入
完整变更Python的Ruff在此处报F401 import time,并在17行报windows_extended_path未使用;不可变898同文件lint通过。实际新增原子写参数走既有document_io,不需要这两条导入。请删除未用导入并重跑完整变更文件Ruff,保留replace_retry_seconds的实际恢复行为;无需旧shim或额外重构。
There was a problem hiding this comment.
已在 c0bc9f61212274734e5f15ca9b40667e43983469 删除未使用的 time 与 windows_extended_path 导入。write_json_atomic 的共享实现和 replace_retry_seconds=0.5 保留,没有增加旧 shim 或改变原子写恢复行为。
已对整合后完整 PR 差异的185个 Python 文件执行 Ruff,全部通过;相关 Chat 持久化/恢复与实际 packaged HTTP 路径另做验证。更新后的 PR 正文按新旧 head 分开记录结果,不用单文件 lint 代替完整变更检查。
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Signed-off-by: Tartar <xiaoyx67@mail2.sysu.edu.cn>
Coordination note: the delegation smoke hunk is duplicated in #7599This PR's diff removes the That exact removal is also the whole diff of #7599, opened separately as a It matters because the interception hides the fixture's later source refusal: Both changes remove the same line, so exactly one of them should carry it. Also worth noting for this PR: it extends the host-adapter settlement step Coordination: this PR and #7599 remove the same smoke lineThis PR removes the Separately, this PR extends the host-adapter settlement step vocabulary with |
|
This pull request has merge conflicts with Choose the remote for the base repository, not an out-of-date fork. git fetch upstream
git rebase upstream/main
# Resolve each conflict, git add the resolved files, then git rebase --continue.
git push --force-with-lease origin HEADFor a same-repository clone whose Keep the DCO |
loopx-agent
left a comment
There was a problem hiding this comment.
Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · reasoning_effort=max
REQUEST_CHANGES — 当前头仍有一个可复现的 Host 清理缺陷。 本次审查完整 head 5d2772c64a86322b69ebd4fc452b283c6705f885,基点 544aa0fee5dad33e3b70496dadfb3ffd36400e13,没有继承旧结论。唯一代码阻断是下面的 P2;其他未完成验证单独列明。
[P2] Job 观察失败后仍须释放原 Goal guard 和输出流
loopx/control_plane/turn_driver/host_process_transport.py:405–411 的 windows_job.finish() 先于 launch_scope.close() 和输出流关闭。若 Host setup 已失败且 Job 的进程查询又抛 OSError,后两步不会执行,Goal guard 仍被持有;后续同 Goal 工作可能一直受阻,原 setup 异常也被覆盖。外层关闭 Job handle 并不能退出这个 ExitStack。
独立探针走真实 run_host_process 和真实 Node bridge,仅替换 Windows Job IO 与平台选择,在 setup record 写入失败时注入 Job 查询错误。同一 fixture 的不可变 base 释放 guard/输出,当前 head 两者均未释放;仅在内存将 Job finish 包进内层 try/finally 后两者恢复释放,Job 失败仍保留。这是清理控制流反例,不是原生 Windows 资格证明。
| 同一失败输入 | base | 当前 head | 内存修复控制组 |
|---|---|---|---|
| guard 退出 / stdout 关闭 | true / true | false / false | true / true |
| 独立资源 oracle | PASS | FAIL | PASS |
最小修复:无论 Job finish 是否成功,都在嵌套 finally 释放原 launch scope 和输出流;不要吞掉 Job 失败或伪称已排空。保留该双失败回归,断言原 guard/输出释放且失败可观测,无需新增状态或扩大协议。
动机 / Motivation
使用 CLI、MCP 或个人工作区恢复任务的协调员,常会遇到“业务结果已写入,但下一步方向或结算尚未提交”。恢复若把它当一次新执行,可能重做工作、重复扣额或遗漏原承诺;这些成本会在持续工作中累积。结果已保留但方向未提交时,旧入口容易把保留结果当普通执行;拟改为读取原结果和当前义务,再提交方向并只结算一次。当前 HTTP 正常恢复成立,但 Windows Job 错误分支仍会遗留 Goal guard。 因而正常路径的改进值得保留,错误清理仍须修复。
本 PR 是原结果到后续方向/结算的一段完整恢复能力及其现有调用入口,不要求整个父 C1/C2、控制器重构或未来研究实验同时完成。观察结果、测试数量和合并记录都不能代替长程收益、模型采纳或安装后的资格。修复Job错误后的无条件清理;完成剩余当前头验证并保留原生平台/研究资格边界。
当前生产 HTTP/controller/native checkpoint 的独立实跑得到:原 result/session/upstream thread/identity 保持,1 result / 1 debit / 1 SDK direction dispatch;重复 replay 和 unavailable/restore 重读不增加这些计数。 SDK 是确定性夹具,不是付费模型,也没有声称本轮浏览器点击。
改动思路 / Approach
沿原 typed owner 读取 canonical Todo/provider head、原结果和原 Turn identity,先保留结果,再让协调员读取当前事实、提交方向,最后结算原 Turn。Python 继续承担 IO 和 Host/私有文件适配,进度是这些事实的投影,不是第二个 pending-result authority table。只改 UI 文案不能补上身份与持久化接缝;给历史加扫描上限则会改变义务,复用一次 typed settlement snapshot 更合适。
正常路径与失败路径的边界不同:重读进度、页面 reload 和 unavailable reread 都不应派发模型或任务;明确的“继续核验”才进入原 direction owner。Windows Job 能约束它拥有的进程,却不能让查询失败跳过外层 Goal guard 的无条件释放。当前修复应局限在原 finally,不需要新增表、CLI 开关或第二套 lifecycle。
具体改动 / Changes
完整差分 266 paths、+17725/-1362:生产125路径 +5735/-719、测试113路径 +10237/-604、example/smoke12路径 +582/-25、docs/assets11路径(含4PNG)、配置/生成物5路径。相对上次 3ed36655a20fef816a31038010be4ef16aafd549,229个当前变更路径逐 blob 未变,37个失效路径连同当前 callers、基点变化和独立验证重新检查;这不是只看最后一次修复,也没有把历史通过记录改称本头全绿。
接受依据是维护者 CR1–CR5 review frame,spec_ref https://github.com/loopx-project/loopx/pull/5677#pullrequestreview-5685607407,spec_revision 9394b2395f10c4537f6af995d821c3e2c2193e6a:
- CR1 implemented:原 typed settlement snapshot 批量读取;不加 pending 表、scan cap 或读取时 repair write。当前 TS 模块覆盖身份/历史/provider/readback。
- CR2 not_met:public-scan allowance 已从此差分分离;平台前置的保护应保留。上面的 Job 清理反例违反当前生命周期边界;#7602/#7603 的单独审查不自动消除这里仍存在的代码。
- CR3 implemented:实际 owner/consumer/retirement 接缝明确;原收据历史保留不等于所有旧请求 decoder 永久保留。当前 main 的 request-subject owner 被复用,不另造 binder。
- CR4 deferred:未来匹配三臂研究属于已接受的研究边界,保留无效/失败历史;不要求本次启动付费模型任务或声称收益。
- CR5 deferred:共享夹具的负例和 maintenance checks 保留;本轮完整 Python 选择尚未跑完,不能宣称独立全模块资格。最新 maintenance 预算与两个 Ruff 未使用导入的旧阻断已修复。
关键代码讲解
observeFirstDelivery:22聚合原 identities、历史与一次 settlement snapshot;corrupt/incomplete source 保持 unavailable,不生成新的权威事实。readQuotaSettlementSnapshot:367和checkpointBasisSnapshot保持原身份/current-source 对齐,业务结果先于后续方向,原结算可重放。run_host_process:264仍通过真实 Node supervisor 执行;Job finish 与 enclosing finally 的错误顺序就是本次反例。GoalLoopXMode:9区分“继续核验”和只读“重新读取”;没有把未知状态当新任务授权。
当前生产 HTTP/controller/native checkpoint 的独立实跑得到:原 result/session/upstream thread/identity 保持,1 result / 1 debit / 1 SDK direction dispatch;重复 replay 和 unavailable/restore 重读不增加这些计数。SDK 是确定性夹具,不是付费模型,也没有声称本轮浏览器点击。
对主干的风险 / Risks
本头独立 9个完整 TS 模块304 PASS;隔离真实 PostgreSQL16.15 store 385 PASS,另一个新数据库的 service suite 10 PASS / 1 SKIP,skip 是只检查另一个 URL 环境变量的说明性占位测试,两个实际 service integration 均已通过。最初把两个 suite 指向同一数据库产生的2个 identity-mismatch 失败已保留,归因是本轮 fixture 隔离错误;没有当成产品缺陷或抹去历史。
17个 Python 模块选择在900秒 wrapper 截止后仍有 uv 子进程,随后对已核对归属的 pytest 发 SIGINT 并收回结果:254个已完成用例通过,整个选择未完成,不是17模块全通过。维护者较早的111 PASS / 3 FAIL / 3 SKIP 与本头5节点修复记录仍只是它们各自的历史范围;未冒称独立复现全部作者计数。
标准本地 premerge 的4 direct、changed-Python compile、10 catalog、8 risk、1 public-boundary均通过,但返回失败含5 manual holds,所以没有称 merge gate 全绿。四张未变图片已单独查看像素和 PNG 文本/EXIF 元数据(无私有内容),benchmark-sensitive 维护者边界仍保留。191变更 Python Ruff、配置的 Linux-platform mypy17文件、全控制面 typecheck、63提交DCO和差分检查通过。CI策略为不等待,未查询/等待CI。
语义与 CI 对齐
semantic advisory 的两个候选分别是 LOCAL_SNAPSHOT_METHODS 的原 RPC 只读 allowlist 扩展、注册的 source_digest_guard IO classification;不是新的领域专属决策 owner。原 identity/current-source/one-settlement 是强制不变量,未来研究是建议,两者没有互换。Windows 外层测试 watchdog30→120与作者base/head35.0/73.7秒、噪声重复16.8/74.4秒明确保留;产品/POSIX限制未改,不能据此声称提速。当前完整 default-off/subject 范围矩阵未完成,有限绿测不替代全部共享表面隔离。
我的整体评价 / Verdict
正常恢复是一项有实际调用者的增量;CR1/CR3 的 owner 复用和结果到方向的顺序值得保留,当前大差分的维护成本也应如实承担。long_horizon regression 来自上述可复现 guard 清理失败,修复前不能批准;当前 HTTP 的用户恢复路径则有独立通过证据。先修原 finally 并加双失败回归,比再造状态机或扩大父 RFC 更有价值;无需额外人工确认来修这一已授权范围。
四张已提交的合成整页图已重新查看;与上次已审头逐 blob 相同。桌面主动作和核验状态相邻,窄屏控制换行且主动作可达;下方成果卡与长英文摘要保持层级,摘要省略,不暴露方法/hash。
视觉与资格的未验证范围:本轮没有重新构建或在浏览器重放整条 packaged UI;复用 c0bc9f6 所述合成捕获并核对当前图片/组件未变。当前生产 HTTP/controller/native checkpoint 单独实跑,SDK 为确定性夹具;正式安装、原生 Windows Job/DACL/长路径和长程净收益仍未资格化。 源图展示的是具体 fixture,不证明长期使用的可读性、生产数据新鲜度或模型采纳。当前画像不被测试数量、四张图或合法状态回执替代。
English verdict: REQUEST_CHANGES at 5d2772c64a86322b69ebd4fc452b283c6705f885. The whole 266-path increment has useful typed-owner and retained-result recovery, with current TS/PostgreSQL/HTTP evidence, but Job.finish can bypass the original Goal guard and stdout cleanup. A same-fixture base/head/repair counterexample confirms it. The Python selection and native Windows qualification remain incomplete; no CI, installed-runtime, long-horizon benefit or merge qualification is claimed.
| proc.wait() | ||
| finally: | ||
| if windows_job is not None: | ||
| windows_job.finish() |
There was a problem hiding this comment.
[P2] Job 查询/finish 抛错会跳过后面的 launch_scope.close() 和 stdout 关闭。真实 run_host_process/Node bridge 的 setup失败+Job观察失败反例:base释放guard/输出,当前head两者都未释放;仅内存嵌套finally修复后恢复释放。请用内层try/finally保证原guard和输出无条件释放,保留Job排空失败,并补该双失败回归。合成Job IO反例不冒称原生Windows资格。
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile loopx-project#3412, loopx-project#5677, loopx-project#7580 and loopx-project#7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile loopx-project#3412, loopx-project#5677, loopx-project#7580 and loopx-project#7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile loopx-project#3412, loopx-project#5677, loopx-project#7580 and loopx-project#7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile loopx-project#3412, loopx-project#5677, loopx-project#7580 and loopx-project#7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile loopx-project#3412, loopx-project#5677, loopx-project#7580 and loopx-project#7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
The C4.3 settlement obligation comparison listed a candidate slice: vocabulary unification. It was conditional on a question that had not been answered: do guard, lifecycle_completion and validation describe one obligation? Guessing it would have produced either a wrong merge or a wrong refusal to merge. The answer is no, so the candidate is withdrawn. - validation is not an executable effect in either runtime. TurnProviderStepKind excludes it, require_turn_provider_step_kind raises "validation is not a provider effect step", the reducer throws "unsupported base settlement step validation" if asked to run it, and the registry's own value note records that it is the one step the dispatcher never executes and carries no command template. - guard and lifecycle_completion are executed steps: the adapter runs them through run_cli with a continue_when that decides whether the rest of the plan runs. - The two value sets differ exactly where the question is asked. guard and lifecycle_completion occur only in A, validation only in B, and the repository advisory does not list them as a merge candidate. - lifecycle_completion has no counterpart in B. - One shipped caller already uses both vocabularies for one admission decision: governed_capability_execution.py classifies the admission snapshot with A's classify_host_guard_snapshot and then hands B a completed_phases that already contains validation. guard and validation name one obligation seen from two positions, so renaming them would hide that asymmetry and break B's "a phase is never executed" invariant. The entry also records what the confirmation leaves open: the vocabulary that does exist has no typed owner, its literal is written twice (an unexported STEP_KINDS and a private _STEP_KINDS), and the repository's inventory sees neither carrier, so the registry's drift smoke cannot cover it. That is a separate slice and must first reconcile #3412, #5677, #7580 and #7523. The derived RFC status index is regenerated, because it counts ledger entries per RFC and the new entry makes the checked-in index stale. No code, schema, wire, registry or default change. Validation: mkdocs build --strict for the docs site and both developer books; RFC bilingual check passed; docs-governance smoke passed; loopx canary premerge --from-git-diff green. Signed-off-by: xiaoan17 <anbc1224@gmail.com>
Goal And Delivered Outcome
Default protected CLI/MCP/managed work binds the original work read before mutation, retains validated candidates across relevant source changes, and resumes required post-result direction/settlement under the original Turn and Agent. Result, direction, accounting and Goal acceptance remain separate; historical admission and explicit first-delivery compatibility retain their boundaries.
Current head:
5d2772c64a86322b69ebd4fc452b283c6705f885. Target base reconciled through544aa0fee. This updates the owner review at 5685607407; it does not declare complete first-stage acceptance or merge readiness.Owner Review Changes
turn.first_delivery.observereuses one existing settlement snapshot plus one strict checkpoint index capture. Original identity decoding, settlement and progress use existing typed owners. There is no per-Turn bridge, history truncation, persisted pending-state table or observation repair/write. Damaged/deleted history still requires indexed identity and matching artifacts; conflicting or changed captures remain uncertain.loopx/contract.pymatches target main. No active configuration consumer was found, so no empty policy proposal was invented. Necessary platform behavior is independently proposed in fix(host): contain Windows Host descendants in an owned Job #7602 (Windows Host Job) and fix(runtime): enforce private IO and preserve Windows long paths #7603 (private IO/long paths). They are unmerged prerequisites; this branch retains protection until they land and can be integrated, rather than creating a temporary gap.checkpoint_read_context.tsowns direction-return classification and receipt transitions; Python retains Host execution and locked persistence. Original intent, attempts, stops, response bindings and v0/v1/v2 consumers are retained. The owner/consumer/retirement table separates original facts, derived stage and actual recovery. Unified capture/continuation proposals are not assumed to be shipped APIs.loopx.hosts.chat_coordinator_checkpointconsumer, with no shim. The complete packaged browser/production owning HTTP/controller scenario now reaches replay, original identity/session/result, unavailable observation, read-only reread and restored-source assertions.Observation Cost Boundary
Same synthetic history on a real File authority, through the production Python/TS path:
Actual File and SQLite CLI admission + MCP completion regressions cover 1/3/5 independent-Agent settled Turns and assert one batch RPC, two full index reads and one rollout read. TS filesystem cases cover 0/1/100/1000 intact/damaged/deleted histories, old pending accounting, lane isolation, incomplete tails, conflicts, artifact mismatch and changed captures. Todo-provider and unrelated status RPCs are excluded from this table. At zero history the new path also performs one Todo projection read (the old path did not). No full-command latency, model-token or general utility saving is claimed.
Author Declaration
ee0f07dcb, existing Goal checkpoint/Todo/settlement contracts, and current target main. Default admission, historical/explicit compatibility and original-Turn recovery are retained; independent platform prerequisites are proposed separately.Latest Required Review Fixes
Current proposal head:
5d2772c64a86322b69ebd4fc452b283c6705f885; target main integrated through544aa0fee.This update addresses review 5688804721:
chat_store.pyimports. The shared atomic writer andreplace_retry_seconds=0.5remain.Any/dict[str, Any]unchanged at 25/0. The reviewed line baseline is exactly 2,025 with no extra headroom; the existing budget guide records the rationale. Main integration reducedcollaboration_mcp.pyto 1,949 lines, so its obsolete 2,083-line exception was removed and the default 2,000 limit restored. The existing reviewed cadence dependency remains explicit.Validation And Remaining Qualification
04171d7c0recorded 111 passed, 3 failed, 3 skipped; its three failures were repaired in this head. That original run is not relabelled as a whole-module pass. Native context continuity remains explicitly POSIX-only.c0bc9f612: maintenance/CLI-output 195 passed, eight typed modules 303 passed, TS typecheck and packaged Chat build passed. The later expanded run recorded 137 passed, 4 failed, 1 skipped; its four failures were repaired and specifically rerun above. The earlier 281 passed, 26 failed, 2 errors run is also retained, not relabelled as passed.c0bc9f612; UI unchanged by later fixes965d779of head5d2772c64into main544aa0fee, using PostgreSQL 16.15: store conformance 385 passed, service 11 passed, 0 failures/skips. This is current-proposal remote evidence; no local PostgreSQL engine was available. Earlier peer evidence remains attributed to3ed36655a.ETIMEDOUT, causing its aggregate check to fail. A single-job rerun request was rejected because the workflow is still running; no successful rerun is claimed.Historical validation limits remain explicit: the initial repository-nested temporary run failed two Git-sensitive fixtures, while unchanged checks passed outside Git; one intermediate premerge was interrupted for a demonstrated source fix. Premerge at
04171d7c0and this head each recorded anauto-research-state-aware-wakeEffect-runtime initialization failure (risk 7/8) under a nested long temporary root. A synthetic direct-owner diagnostic on immutable main544aa0feeand head reproduced SQLite WAL initializationERR_SQLITE_ERROR/ code 14 at a 252-character database path; the failed first initialization also leaves an unversioned database that subsequent reads reject. No real Goal was used. The unchanged smoke and the final complete suite pass using shorter isolated temporary roots, but SQLite long-path initialization remains unqualified and must not be counted as fixed by session/journal path normalization. The original failures remain recorded. The first journal/Stop targeted follow-up recorded 4 passed and a 30-second smoke timeout before the measured Windows watchdog correction. Native Windows configured mypy retained eight POSIX-attribute errors. An exploratory explicit-file mypy followed imports beyond the configured lane and reported 5,593 errors in 630 files; that attempt is not a pass and no all-tree baseline attribution is claimed. Hosted CI must be read on this exact head; local results do not stand in for pending checks.Earlier Author Validation At
3ed36655aThe following earlier author rows retain their original revision and qualification limits.
3ed36655a20fef816a31038010be4ef16aafd549source tree, including the current-main integration. Earlier runs are identified below; suites overlap and counts must not be summed.test_checkpoint_history_isolation.pyactual File/SQLite 1/3/5 growth cases passed; the final integrated-source rerun also passed (2 parameterized cases, all three growth checkpoints per backend). Earlier observation/isolation combination: 18 passed.ee0f07dcb; the timeout was not increased or relabelled green.Visual Evidence
Current packaged source, synthetic Goal/navigation with the actual target HTTP/controller and deterministic SDK. Desktop 1512×982 and narrow 390×844 were inspected: retained result, settled state and unavailable-source recovery have distinct controls; no private operating context is shown. These are before/after resume states, not a claim of installed or live-model delivery.
Before resume, retained result (desktop):
After settlement/replay (narrow):
Unavailable source (desktop / narrow), with read-only reread:
Scope And Continuation
The author changes and reproducible regressions are submitted for review. Platform dependencies #7602/#7603 are open; their landing/integration and outstanding backend/environment qualification remain explicit. No approval, complete Goal certification, full harness benefit or merge is claimed.
Evaluation: two historical diagnostic scenarios
Combined methods and results.
Both use gpt-6.1-sol/high, the same runner and native weighted scoring, and a 7,200-second budget per arm. The unchanged-task arms ran serially once each; the target baseline is historical, with only freshness rerun after repair. The benchmark freshness snapshot is
a49afcd6c, not this current PR head. Both freshness runs remain runner_invalid; all four runs remain score_countable=false and matched_pair_countable=false. This is neither a leaderboard claim nor proof of a general or single-mechanism benefit. Full monetary cost is unknown; historical failures and original grades are retained.