Skip to content

fix(context): show one ready settlement recipe - #8238

Merged
huangruiteng merged 1 commit into
mainfrom
codex/progressive-single-settlement-recipe-20261107
Nov 7, 2026
Merged

huangruiteng merged 1 commit into
mainfrom
codex/progressive-single-settlement-recipe-20261107

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

A ready progressive read repeats the ordered plan’s writeback and spend commands in next_cli_actions. This change shows the ordered plan once when the ready Todo and original effect match and the fallback is an exact copy in the same order. The plan still carries every command and precondition. If the commands, order, effect, readiness, or plan version differ, the fallback remains visible. The captured field and direct output are unchanged.

Base: 79665b97a0a453380da02e15b1b62eee895147df. Head: da8439fb19f4cba20ebe61bead629758b4747328.

  • The actual File and SQLite CLI paths failed the duplicate check on main and passed after the fix. Both still expose all distinct CLI fields and can read the original fallback from the same immutable capture.
  • Five source modules: 355 passed, two failed. The two telemetry cases could not observe the start of a local usage cycle with context delivery off. Both failed at the same assertion when rerun against immutable main; their failure is retained. The isolated wheel passed 144 tests across both reader modules; 58 TypeScript tests, control-plane typecheck, and changed Python Ruff passed.
  • Exact-head standard premerge passed five direct and 13 selected checks. No remote CI result or merge authorization is asserted.

This reduces repeated text in one reader stage. It leaves admission, settlement and recovery ownership unchanged and does not qualify model usage or total task cost.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
@mergify

mergify Bot commented Nov 7, 2026

Copy link
Copy Markdown

This pull request has merge conflicts with main and cannot be merged
until they are resolved. Please rebase or merge the base branch, @loopx-agent.

Choose the remote for the base repository, not an out-of-date fork.
For a fork clone, first inspect git remote -v; upstream must point
to https://github.com/loopx-project/loopx.git. If it is absent, add it
with git remote add upstream https://github.com/loopx-project/loopx.git.
Then run:

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 HEAD

For a same-repository clone whose origin points to
https://github.com/loopx-project/loopx.git, use origin instead of
upstream for fetch/rebase. If you prefer merging the base, use
git merge <base-remote>/main and push normally.

Keep the DCO Signed-off-by trailer on every commit when you rebase.
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

@mergify mergify Bot added needs-rebase Mergify: the pull request has merge conflicts with its base branch and removed needs-rebase Mergify: the pull request has merge conflicts with its base branch labels Nov 7, 2026

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent | gpt-6.1-sol | OpenAI | runtime_reported | reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

同一项工作进入可执行状态后,使用 CLI 上下文的 Agent 需要从当前任务的捕获读到唯一清楚的结算顺序。旧首读同时列出有前置条件的写回、扣额步骤和一份逐字相同的命令列表。分页后同一命令看起来像两个入口。当任务、原执行身份和命令顺序都对得上,首读只展示带前置条件的计划。独立读取原捕获仍能取得原命令列表。这个切片只调整首读导航。准入、状态写入、恢复和扣额由原有组件负责。

真实模型在长程工作中的采用和总成本仍需验证。这里测量的是选定输入的源码 CLI。

改动思路 / Approach

由决定首读地址的 TypeScript 函数判断两份命令是否相同,复用原有捕获、分页和结算计划。判断范围是已就绪且绑定原执行身份的首读。非等价命令和原捕获继续由既有读取路径提供。 同一原捕获里的已就绪状态、所选 Todo、计划和心跳回执共同决定这次展示。先读到带前置条件的步骤,再按原身份验证、写回和扣额。历史引用和按字段恢复仍读原来的值。比较两组真正在运行的本地存储后,得到的任务、证据和结算次数一致。

具体改动 / Changes

关键代码讲解

  • initialContextReadPointers 比较就绪状态、Todo 和完整结算身份,只在写回与扣额命令逐字相同且顺序相同的情况下跳过备用列表。原步骤、前置条件和其他字段仍按原地址选择。progressive_context.ts:517
  • 旧的首读固定引用仍可回读原选择。没有固定地址的旧续页遇到摘要变化会拒绝,随后按原摘要读取同一捕获。quota_capture.py:491
  • 改动包含一个 TypeScript 选择器和一个 Python 验证文件。源码在两种存储上验证了首次读取、同一捕获恢复和结算;不同参数、顺序、effect、未就绪及未知计划版本都保留备用列表。test_context_first_read.py:406

以修订 79665b97a0a453380da02e15b1b62eee895147df 的 docs/reference/required-work-context.md 为规范。Ready settlement obligations 已实现,所有原步骤和前置条件均可执行。Distinct and unknown commands 已实现,差异命令保持可见。Same-capture recovery 已实现,原字节和固定引用可用。Model and complete costs 留待独立验收。

对主干的风险 / Risks

没有发现由本次改动引起的阻塞问题。主要风险是把相似但不等价的命令当重复,或让旧续页越过原摘要。五种不等价用例和旧读者都覆盖了这些路径。当前主干 dee5496632 已改变渐进读取的规划入口。我把 PR 应用到该修订的合并树并重跑两种实际存储,原验证、写回、扣额和终态均可执行。

验证 观察
PASS · File 和 SQLite 的真实 CLI 实际 CLI 在 File 和 SQLite 上按首读计划执行独立校验、写回、扣额和终态,四种回执沿用原 effect;重放后校验、写回、扣额各一次。首次读取和恢复没有改变原捕获,错误摘要被拒。同一合成输入的首读 JSON 减少 1,465 B;4,500 B 页预算下,File 与 SQLite 都从 7 页减到 6 页。
PASS · 旧捕获和恢复 旧版本生成的固定地址 reader 在新版本读回完全相同。没有固定地址的旧续页遇到选择摘要变化时拒绝,随后可从原捕获精确读取原 fallback。
PASS · 适用本地检查 78 项 TypeScript、类型检查、改动文件 Ruff 和双语 RFC 检查通过。标准 premerge 通过 5 项直接检查和 13 项选定检查。
FAIL · 已有分页用例 Python 256 过、1 败。同一 1,600 B 原始分页用例在基线和候选都于相同断言失败,诊断为放不下页元数据和一个 UTF-8 字符。该调用不进入本次改动的首读选择器。
FAIL · 已有工作流 Ruff 工作流范围 Ruff 在基线和候选均仅报未改测试第 184 行 F841,完整诊断相同。改动文件 Ruff 通过。
UNVERIFIED · 独立安装及真实模型 未独立重跑打包 wheel、已安装 App 或真实模型。本轮没有等待托管 CI。

语义与 CI 对齐

本次沿用现有就绪状态、结算计划和原执行身份。变化只在首读指针选择,不扩展共享状态词汇。工作流 Ruff 的红项保留为独立门禁。上表的本地结果不代表托管检查已通过。

我的整体评价 / Verdict

这次改动让已就绪的调用方看到一份可执行结算计划,并保留了原捕获的恢复入口。实际 File 和 SQLite 运行证实写回、扣额和重放语义一致,首读少一页。批准当前提交的代码改动。工作流 Ruff 仍需单独通过;这份评审的范围是源码和合成任务。改动只影响 CLI 交付给 Agent 的首读地址和呈现顺序。仓库的页面渲染不在改动路径上。未独立重跑打包 wheel、已安装 App 或真实模型。本轮没有等待托管 CI。

English verdict: APPROVE for da8439fb19f4cba20ebe61bead629758b4747328. The ready first read keeps one executable settlement recipe, with original capture recovery and once-only effects verified.

@huangruiteng
huangruiteng merged commit 72ca8f8 into main Nov 7, 2026
38 of 61 checks passed
@huangruiteng
huangruiteng deleted the codex/progressive-single-settlement-recipe-20261107 branch November 7, 2026 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants