Skip to content

refactor(todos): reuse complete source display views per managed request - #8302

Open
cocolord wants to merge 2 commits into
mainfrom
codex/small-kernel-todo-projection-20261107
Open

cocolord wants to merge 2 commits into
mainfrom
codex/small-kernel-todo-projection-20261107

Conversation

@cocolord

@cocolord cocolord commented Nov 7, 2026 •

Copy link
Copy Markdown
Collaborator

Problem and result

A governed quota read repeatedly sends the same complete Todo display source for summary, planning and retained-terminal views. The existing TypeScript todo.context.page owner now composes those views once within an already revision-pinned logical request. Reuse compares complete source JSON and request options; changed sources, later requests and caller mutations remain isolated. Large and unscoped inputs retain their original transport, and malformed bundles fail before memoization.

This is one reversible increment of the small-kernel RFC. The complete provider-first Todo transaction remains open. Provider reads and authority, lease, quota, settlement and recovery rules retain their existing owners. Existing CLI and frontend callers keep the same output; this increment adds no caller-facing capability or settings journey.

Author declaration and acceptance

Written by a GPT-6 model agent through TRAE.

RFC: docs/architecture/rfcs/monorepo-distribution-split-v0.md. Verified PR base: main@94b91e48aa4a2cdafe9d4d31d918fe84d0112b41; final tested head: 7f85fce90ece3263626c0f1b099a8f01869f2d1a. Runtime source/wheel and cost qualification was recorded at eb39d796f2c492363841321d68237bebc2fe2b42; the final commit adds paired continuation design and PostgreSQL source qualification with unchanged runtime files.

Criterion Disposition Decisive evidence
I2: one owner and implementation path Existing TypeScript display owner composes the views; Python handles transport Frozen display fixtures and source-view isolation checks
I8: complete required context and fresh identities Complete input comparison; no Todo-id aliasing or cached authority reads Changed-source, mutable-result, scope-exit and real CLI refusal checks
I9: bounded performance and outcome claims Transport observations are diagnostic; complete benefit remains unqualified Matched synthetic CLI observations below
Complete provider-first transaction and wider milestone Ongoing; existing read/selection owners remain the next boundary No provider transaction is moved in this PR

Validation and packaged readback

  • Extended source corpus: 241 passed across runtime source reads, Todo summaries, handoff, quota planning transport and CLI settlement. The final response decoder's three focused checks passed. After rebasing, the entire runtime source batching file passed again: 16 passed.
  • Four TypeScript suites: 56 passed, zero skipped. Frozen fixtures independently cover all three display views.
  • Immutable baseline sensitivity fails at the expected repeated-source dispatch assertion. A dropped required-write-scope response mutation fails through the real SQLite guard at its independent scope oracle.
  • On the verified base/head, six complete 101-Todo source and isolated candidate-wheel File/SQLite CLI lifecycles preserve the verified sum artifact, original completion time, four receipts, one debit, restart recovery, malformed Vision/workspace refusal and evidence-replacement refusal. These are synthetic governed deliveries, with separate disposable authority stores.
  • Rebuilt the frontend bundle after the rebase, then built and installed a fresh candidate wheel in an isolated environment. Installed Python and TypeScript files match the tested source bytes. This is packaged readback, with no installed-host upgrade.
  • A separate 38,000-row source check returns the same complete planning output on base and head, exercising the existing private snapshot transport for a combined result larger than the inline response limit.
  • Standard premerge passed at the exact tested head: six direct checks, eight catalog checks, eight risk checks and one public-boundary check; zero failures, warnings or manual holds. Bilingual RFC and semantic-vocabulary checks passed. Initial dependency, test-double and stale frontend-bundle failures were corrected and retained as qualification history.

Representative source commands:

uv run --extra test python -m pytest tests/control_plane/test_runtime_source_read_batching.py tests/control_plane/test_todo_summary_projection.py tests/control_plane/test_handoff_context_projection.py tests/control_plane/test_quota_planning_transport.py tests/control_plane/test_quota_settlement_cli.py -q
node --test tests/control_plane_ts/todo_context_projection.test.ts tests/control_plane_ts/quota_selection.test.ts tests/control_plane_ts/quota_summary_transaction.test.ts tests/control_plane_ts/todo_summary_projection.test.ts
uv run --extra test loopx canary premerge --from-git-diff --git-diff-base origin/main

Cost, limits and next boundary

On macOS arm64 / CPython 3.13.5 / Node 26.0.0 / SQLite 3.53.1, the latest-base profiled guard changed JSON parameter bytes from 1,901,814 to 1,558,579 (about −18.0%) and calls from 90 to 88. Loaded modules stayed at 503. The RFC checkpoint retains its earlier-base diagnostic observations with their original provenance.

Three exploratory, unprofiled matched complete SQLite CLI pairs took 14.43/14.11/13.33 s on base and 15.47/13.54/12.87 s on head; medians were 14.11 and 13.54 s, with overlapping ranges. The first pair was slower on head. This does not establish a material speedup. Complete wire, daemon CPU, total memory, model cost, sustained benefit and actual adoption remain unqualified.

Next work moves canonical row materialization into the existing typed read/selection/vision owners before composing the complete provider-first transaction. The bilingual checkpoint separates provider snapshot facts from independent caller evidence and pending intents; strict Python-value compatibility remains required. Native PostgreSQL source composition now has real-backend evidence; the complete guard/wheel journey and new transaction still need qualification. I3 remains at least one minor release; M1/#8011, full R0/V10/R1, D2/D5/D6/D3, context/model/split-install and all frozen failures remain open. Related #8286 and #8290 remain separate proposals at their current exact heads; this PR does not adopt or compete with their repairs.

This completed author proposal is ready for independent review. Required CI, exact-head review and maintainer merge authorization remain separate gates. Premerge passed without self-merge authority; this PR has not been merged.

Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>
Signed-off-by: lusendong.6789 <lusendong.6789@bytedance.com>
Co-authored-by: TRAE CLI <traecli@bytedance.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator

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

动机 / Motivation

使用 LoopX 托管工作的人需要在一次调度里看清要做的任务,并在进程重启后从原任务继续。以前,同一次调度如果要读取待办摘要、执行计划和已结束任务,会把同一批任务数据多次传给投影进程。新实现可以传一次数据就取得三个结果;只需要一个结果的调用也会被打包,本次复现了额外计算和写盘。这次改动处理视图传输;任务存储、领取、权限和结算仍沿用原来的规则。

完整来源事务和端到端成本验收仍待完成;本 PR 可以先把复用限制在确实要读多种视图的路径。

改动思路 / Approach

复用完整来源的方向成立;打包范围应由知道要读取哪些视图的调用方决定。本次边界是一次托管请求中的 Todo 展示传输,已保存的 Todo、权限和结算仍由原有组件负责。 在实际 guard 中,Python 先拿到当前完整任务数据,再以完整 JSON 和传输选项在本次请求内识别可复用的结果。TypeScript 原投影函数仍解释任务状态;按任务 ID 寻找运行结果的调用方仍只取它要求的那一种。记录、权限和结算来源不经过这个缓存。优先让现有 quota 组装逻辑选择要读的视图,保留其他调用方的旧路径,可以交付这部分复用,不必等待整个来源事务重构。

具体改动 / Changes

关键代码讲解

  • effect_runtime.py:1622:在已固定运行时版本的请求中,只要来源和选项符合形状且输入不超过约 2 MiB,就把请求替换成三个视图。缓存键包含来源和选项;命中后重新解码,避免一处改动影响另一处。三种返回缺任何一项都会在写缓存之前失败。
  • context_projection.ts:35:按原 TypeScript 函数分别生成摘要、计划和保留终态。只有摘要使用已清除交接门禁;未改变记录类型或权限解释。现有 project_delivery_response(delivery_history.py:93)只请求 retained terminal,却会收到三个完整数组后丢掉另外两个。
  • 七个文件中,运行代码为 +49/−2;测试 +161,双语 RFC +103。最后一次更新增加配对的后续设计说明和 PostgreSQL 快照组合测试。现有单视图路径仍供大来源和非托管请求使用,File/SQLite 的持久记录和重放身份沿用原来的代码。

规范基线:docs/architecture/rfcs/monorepo-distribution-split-v0.md,修订 94b91e48aa4a2cdafe9d4d31d918fe84d0112b41。I2 已实现:保留原任务权限、投影和结算 owner。I8 已实现于本次对照的完整来源、门禁及原凭证路径:来源更新和下一次请求重新读取。I9 已按本切片落实:分开报告数据量、执行环境和范围。V10 / R0 的完整默认 SQLite 成本资格仍待验证。

对主干的风险 / Risks

[P2] 单视图读取会计算并写出两个无人消费的视图。 同一真实投影调用、相同 8,000 条开放 Todo 和继承关系,运行一次 retained terminal 读取。基线请求 1,128,077 B、响应 3,728,136 B,走套接字;候选请求 1,128,078 B,计算三套各 8,000 行,落盘并同步一个 11,184,165 B 的私有快照。最终投影哈希相同。只让该调用保留旧的单视图请求后,候选又返回 3,728,136 B,不再写快照。 写盘分支沿用既有校验,也会同步文件;输入小于 2 MiB 并不能保证三个结果都能留在 8 MiB 的套接字响应上限内。即使留在内联上限内,单视图也会承担其他两套计算。同机 Node v24.21.0、CPython 3.14.8,warm broker,每臂 5 次无传输探针计时:8,000 条 retained 视图中位数 0.216→0.835 s;15,000 条短记录 0.232→1.478 s。这是单个源码调用的诊断,不外推为整个 CLI、后端或长程收益。

保留通用单视图入口,把打包放到明确同时消费多种视图的组装调用方;继续由原 TypeScript 投影 owner 执行。增加仅消费一种视图的实际 transport 对照,并在默认 SQLite 路径同时核对请求、响应、临时文件和回执。

复现时,在基线与候选分别启动隔离的本地 Effect 进程,构造 8,000 条开放 Todo:ID 按 todo_build_00000 编号,每条短正文,successor_todo_ids 指向下一条。将其作为 {"items": rows},在 effect_runtime_request_scope() 中只调用一次 project_delivery_response(首条 Todo,delivery_outcome="outcome_gap",outcome_followthrough_required=True)。记录该次 todo.context.page 的响应和 _read_local_snapshot_response 收到的 result_ref.byte_count。对照路径仅给现有单视图源加对该分支无影响的 strip_text=False,从而跳过新打包条件;保留相同最终结果,并核对快照读没有发生。

验证 观察
PASS · 实际 File/SQLite 领取、校验、归档及恢复 源码 CLI 对同一 101 条 Todo fixture 的 File/SQLite 基线与候选四组均通过:一次独立校验、一次写回、一次扣额;四种原结算凭证和完成时间可恢复,已确认原 Effect 进程退出、新进程重放、替换证据被拒。
PASS · 多视图的预期收益 同一 101 条 Todo guard 的参数 JSON:File 841,869→726,162 B;SQLite 842,360→726,653 B;均 82→80 次调用,加载 503 模块不变。
FAIL · 仅消费一种视图 真实 Effect 返回保持相同;额外输出触发约 11.18 MB 私有文件写盘。
PASS · 回归与源码检查 前一提交的 242 项 Python 和四组实际 CLI 生命周期覆盖的实现、测试与依赖在新提交中逐字不变;新提交重跑 16 项批处理测试、60 项 TypeScript(含 56 项聚焦投影测试)和实际写盘复现。 类型检查、Ruff、双语 RFC 和差异检查通过。改变来源、交接门禁、调用方修改返回值、大来源、独立请求和缺失视图都有覆盖。
UNVERIFIED · PostgreSQL 最新提交新增 PostgreSQL 原生快照组合测试;本机没有隔离 PostgreSQL,测试加载后跳过,作者的数据库证据未独立复跑。
UNVERIFIED · 托管 CI 和独立安装 本轮采用源码验证,未查托管 CI。

语义与 CI 对齐

新键只在共同发布的 Python 和 TypeScript 间传递读视图,复用原 Todo 状态和权限语义;没有新持久状态、额外的执行授权或新的提示义务。大来源、不在请求 scope 的来源和其他投影模式仍走原路径。本轮的阻塞点是默认打开的投影工作量;现有测试通过不能排除这个回归。

我的整体评价 / Verdict

多视图复用减少了同一真实 guard 的调用与输入字节,且在 File 和 SQLite 的配对案例中保留了原任务、完成时间、回执和重启后的继续条件。单视图路径增加了等待和同步写盘,用户得到的内容相同,因此当前提交仍需修改。建议保留现有单视图通道,在明确需要多个结果的调用点打包,并重跑两种负载和原结算验证。本次改动位于托管 CLI 和共用 Todo 投影的内部传输层,没有改动页面布局。未运行已安装 App、真实模型、完整默认 SQLite 成本对照或长期采纳试验。

English verdict: REQUEST_CHANGES for 7f85fce90ece3263626c0f1b099a8f01869f2d1a. Keep one-view reads on the existing transport and bundle only at callers that request multiple views.

size = MAX_REQUEST_BYTES
# Reserve space for all three results under the existing ceiling.
# Larger sources retain their original single-view transport.
if size <= MAX_REQUEST_BYTES // 4:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

[P2] 只读取一个视图时保留现有通道。 同一真实投影调用、相同 8,000 条开放 Todo 和继承关系,运行一次 retained terminal 读取。基线请求 1,128,077 B、响应 3,728,136 B,走套接字;候选请求 1,128,078 B,计算三套各 8,000 行,落盘并同步一个 11,184,165 B 的私有快照。最终投影哈希相同。只让该调用保留旧的单视图请求后,候选又返回 3,728,136 B,不再写快照。 保留通用单视图入口,把打包放到明确同时消费多种视图的组装调用方;继续由原 TypeScript 投影 owner 执行。增加仅消费一种视图的实际 transport 对照,并在默认 SQLite 路径同时核对请求、响应、临时文件和回执。

This branch has not been deployed

No deployments
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