[cocolord]

Canonical Todo source binding serializes every native field twice to create an original JSON basis and validate its canonical digest. Reuse the complete, already validated bytes for that basis. JSON decoding preserves the same values; mapping insertion order remains a non-semantic source difference. Digest mismatch fallback, Python scalar facts, request scope, provenance and provider/lease/replay checks retain their existing owners.

Validation on macOS arm64, CPython 3.13.5 and Node 22.22.3:

• The original implementation passes two mapping-order/scalar characterization cases; the final implementation passes all nine canonical source cases across File/SQLite, including freshness, forged source, outage and large-response cases.
• A read-only comparison using the same native SQLite fields records four encodings for two original fields and two encodings for the candidate, with complete values and unchanged references in both arms.
• Four complete 101-Todo CLI lifecycles (checkout/isolated wheel × File/SQLite) preserve sum45, original completion time, four receipts, one debit, restart, refusal/replay and two normal native process exits each. The wheel's runtime source bytes match this commit.
• Standard premerge passed after restoring missing root TypeScript dev dependencies: six direct checks, ten catalog canaries, eight risk-profile smokes and the public-boundary check. The initial dependency-related semantic smoke failure is retained separately; no source or validation gate was weakened. Staged and committed bilingual checks passed.

This is a serialization refinement. Full marginal-cost/adoption benefit, installed-host and PostgreSQL host/wheel qualification remain open; frozen campaigns are unchanged. GitHub CI, independent exact-head review, merge readiness and maintainer merge authorization remain separate gates.

Integration status: this complete-basis refinement is incorporated into the combined #8372 proposal at head 7e20516, on current main including merged #8360 and #8011. The combined proposal carries source/wheel, real PostgreSQL and packaged browser evidence plus the unresolved report packet-contract validation hold. This component PR remains open and unmerged pending reconciliation; its validation above belongs to the original bd96861 head. Exact-head review, CI/readiness and maintainer merge authority remain required.

[mergify]

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

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

[loopx-agent]

Reviewer: model_agent, gpt-6.1-sol, OpenAI, runtime_reported, reasoning effort max

动机 / Motivation

在正式任务里打开 Todo 或继续受管 Turn 的操作者，会反复从权威存储读取任务和下一步。 一次读取需要处理用户与 Agent 两组任务字段。原版先各自保存 JSON 再重复编码校验。候选保留已经校验的完整字节，实测从四次字段编码降到两次。 在 File 和 SQLite 上，重排映射键仍能使用原来源。把布尔值改成整数、替换所有者、篡改计数或删掉字段仍会失去来源资格或被拒绝。 验证范围覆盖来源绑定、读回和恢复。完整端到端成本、安装宿主和收益归因留给独立资格验证。 这批证据确认一次读取少做了编码和摘要工作。长期延迟、跨宿主部署与整套运行成本仍需单独测量。

改动思路 / Approach

保持现有 TypeScript 权威读取和 Python 兼容传输的边界，复用已校验内容，决策和持久状态仍由原所有者处理。 本 PR 交付一处完整字段编码复用及其来源校验，合并路由需要与含同一改动的 #8372 协调。 现有读取先绑定当前存储修订、游标和完整字段摘要，再把结果交给 Todo、配额与 Turn 的既有消费方。过期或篡改后的读回进入原有拒绝和恢复路径。完整的来源校验有实际调用方，省掉的是重复的中间编码和相等标量摘要。

具体改动 / Changes

关键代码讲解

• bind_canonical_todo_sources。先对完整字段验证摘要，成功后把同一份 UTF-8 字节留作以后比较的依据。摘要不匹配时仍走完整的调用方输入路径。 提交源码
• canonical_todo_source_reference。在原请求里解码完整依据再比较。映射键顺序可以变化，列表顺序和布尔、整数等类型仍参与判断，受保护事实有变化就失去原来源。 提交源码

配套测试覆盖映射重排和布尔转整数的来源拒绝。双语改动追加了实测账本，原有验收条款与性能门槛仍在正文。 我按当前目标主干的 docs/architecture/rfcs/monorepo-distribution-split-v0.md 对照了全量差异，规范版本为 69ddc610846f98b8d9b6c5c374ac4aefdd2d4ed0。I2 的单一权威读取、I8 的完整和新鲜上下文、I9 的可复核测量范围都能对应到上述实现与验证。 版本固定的规范

对主干的风险 / Risks

与 #8372 共用的 Python 文件和回归测试逐字节一致。此独立分支与当前 main 有冲突，合并前应先确定采用哪一个提案，避免重复引入。 最危险的反例是将看似相等的值当成原事实。直接替换数字类型、删除字段、改写嵌套所有者和换用旧游标都应被拒绝。恢复原值后能继续从同一作用域读回，长任务的回归也验证原结算只发生一次。

PASS。File/SQLite 的 11 个候选测试与 11 个基线测试均通过。包含来源重放、provider outage 和 101 条 Todo 继续执行只结算一次。 精确 diff 检查和双语 RFC 检查均通过。反例在同一个真实入口运行。原提交拒绝错误数据，移除类型保护的变体才接受了它。

我的整体评价 / Verdict

没有阻塞评审的代码发现。原有任务继续执行与 CLI 使用路径得到保留，减少的编码次数已有可复核的 File 和 SQLite 对照。核对了 Todo 与报告的 CLI 数据和消费路径，当前改动属于来源绑定与验证，视觉评审范围为空。 宿主安装、浏览器和完整链路成本仍属独立验证范围。合并就绪仍取决于分支冲突和组件提交的协调。

English verdict: APPROVE at bd96861. Exact-head File and SQLite checks preserved source provenance and replay. The same component is in #8372, and the standalone branch still has an integration conflict.