Skip to content

refactor(collaboration): converge return delivery and restart recovery in TypeScript - #6855

Open
hhyykk wants to merge 9 commits into
loopx-project:mainfrom
hhyykk:codex/ts-return-delivery-20261019
Open

hhyykk wants to merge 9 commits into
loopx-project:mainfrom
hhyykk:codex/ts-return-delivery-20261019

Conversation

@hhyykk

@hhyykk hhyykk commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

Author revision 7c20c6b00e91fd581aadfde1fb663a4cf67fc736 includes target main 6e8688d8d90f1c5a99fadf81def8e4ca2e79c925. The final upstream delta changes documentation and tests only; product bytes and the focused test sources behind the validation below are unchanged.

Current author revision: integrate main f72b67113ff42ccf385519222a530a11ce22659c into the existing return-delivery proposal. Recovery behavior remains with the existing native owner and original Host/provider adapters.

Current validation: 24 native transaction cases pass. Controlled transport executes the actual File/SQLite and Chat-store caller logic: 105 cases pass and 29 HTTP cases fail at the sandbox's denied socket boundary. These results do not establish normal runtime or installed qualification.

Performance hold remains. No new qualifying full SQLite CLI measurement could run through the normal managed runtime here. The prior +8.69% / +66.21ms and +22.35% / +140.96ms p95 failures remain failed evidence. This synchronization does not resolve that blocker or claim a performance improvement. Re-review and unchanged-budget qualification are required before merge.

Previous proposal and evidence (historical):

This replaces the two Python result-return coordinators with the existing TypeScript return owner. A completed request still returns to its original conversation; a recorded provider acceptance survives a response loss and restart without sending the result twice.

Current proposal: d03ba38a73d11e376e5638a52e9f48a861c6b2ab, integrating target main at 94e9f036f3b1d209cd04133ad87f710947fd512c. Hold merge: default SQLite cost qualification is not yet satisfied.

Implementation and boundaries

  • return_delivery.ts owns bounded scan selection, locked admission, provider-attempt checkpoints, retry/verification reduction and atomic delivery receipts. Python retains real source/Chat/authority observations, source fences and provider IO. The transaction and scan bridge totals 40 source lines; this is not a claim that all removed Python was pure decision logic.
  • Removes both obsolete Python coordinators and the private attempt-normalization RPC. Historical request/result/route/attempt identities, persisted receipts, public diagnostics and original conversation identity remain compatible. No new queue, permission owner or Python decision fallback.
  • Repairs both findings from the prior review: malformed candidate addresses cannot abort a valid return, and an actually missing original Session/Turn terminates an accepted attempt explicitly while preserving it. Invalid addresses now create no delivery receipt; that is an intentional strengthening of the old behavior.
  • Preserves provider_verification_unavailable after an exact verifier exception. Also preserves the typed prewrite failure causes already merged in #6873: they remain retryable before any accepted write, while an ordinary exception with identical text stays generic. This is implemented through the existing verifier classifier in the TypeScript owner.
  • Reuses the existing executable-revision request scope for one manager-inbox command. A real CLI trace retains the same three operations, reduces source snapshots from four to two, and keeps state and authority observations live.

The target-relative diff has 10 files: runtime +595/−990, tests +435/−81, docs +38/−6. Mainline UI/test changes are not duplicated in the PR diff. This is one return transaction cutover, not full Inbox/receiver acceptance, source-grant migration, a 2.0 upgrade executor, installed adoption or live-provider delivery qualification. No frontend behavior changes in this slice.

Validation and source attribution

The author subsequently merged main #6861 (only DSH/pnpm configuration/workflow). The complete 10-file target-relative diff and every corresponding base/head file blob are byte-identical to the measured dc45c128d / d2f6aefde proposal. Return callers, shared transport, dependencies and relevant package inputs are unchanged. The following executed evidence remains attributed to d2f6aefde and is reused after that invalidation check; no new cost pass is inferred for d03ba38a.

  • Source Python return/source/adapter suites: 382 passed. The 14 unchanged current-main typed-prewrite cases failed 11/14 before integration and now pass 14/14, including the untyped-text controls and real bound-owner HTTP path.
  • Native return transaction/publication suites: 32 passed. TypeScript typecheck, Ruff and staged/committed bilingual RFC checks passed.
  • Standard source premerge against the pinned target: 19 selected checks passed, including all 10 changed public files in the boundary scan.
  • Final wheel and sdist built after refreshing the required Chat bundle. Each installed into a separate fresh Python 3.14.8 environment; four changed product-source hashes matched the reviewed checkout. Each passed the normal CLI + canonical SQLite private-return and external accepted-write/restart path, plus the three focused recovery regressions. All imported product modules resolved inside that installation. Provider effects were synthetic; no live service was installed or contacted.
  • Exact target-versus-head functional comparison retained complete persisted result/delivery records, original Chat return, public status, full CLI JSON and effect counts. Both private and external paths matched after normalizing ISO clock values only. No fields were removed from comparison.

Remaining performance qualification

The accepted TypeScript migration performance contract still applies: warm non-durable transitions below 2 ms p95; no greater-than-5% or unexplained 25 ms additive full-CLI p95 regression. SQLite qualifies the default; no File-only performance gate is imposed.

Two fixed, alternating 32-pair canonical SQLite comparisons retained every sample:

Comparison External CLI p95 Result
907ede6e1 → fdbbd91c2 761.92 → 828.13 ms (+66.21 ms, +8.69%) Failed
907ede6e1 → 8af44c585 after the request-scope refinement 630.76 → 771.72 ms (+140.96 ms, +22.35%) Failed

The second run improved medians and measured API/drain crossing counts (31 → 11), but its tail remained worse. Scoped warm typed requests passed at 0.377 ms p95; cold/runtime-memory measurements and bounded profiles remain supporting diagnostics. They do not erase either failed full-CLI result. Profiles point to common CLI startup and fingerprint work but do not establish a Node/SQLite CPU regression cause.

The final d2f6aefde integration has complete functional/package evidence and no passed final cost qualification. No samples or thresholds were changed, and another run was not used to hunt a passing tail. The exact-scope change-quality receipt therefore records FAIL. The next performance step is bounded caller/startup/transport attribution and a stability control under the existing measurement contract, rather than a broader CLI framework rewrite.

CI was not queried or awaited under the configured review policy. Correctness, type, build and premerge passes do not authorize merging with the outstanding SQLite budget hold.

Additional CI hold: the Windows job reports two process-cleanup deadline assertions (0.10000000000002274 <= 0.1) in tests/extensions/test_process_runtime.py. That test file and loopx/extensions/process_runtime.py are identical to target main. The Windows result remains failed; this revision does not claim a Windows timing fix.

@songoow songoow 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 Astra Pro · OpenAI · self_reported

Exact head: 198ec1ced1b45b845873a26b24b978275bbe3353 · merge base: a40caa14fd93474fbb3f21515d4246f37f3b4efb

动机

发起委托并等待结果返回原对话的用户,会遇到本次涉及的发送、核验和重启恢复流程。

例如外部 provider 已接受结果后进程退出,系统应从已保存的消息标识继续核验,并且只把结果返回最初的对话。

这次把两套 Python 编排收敛到已有 TypeScript owner;普通回传及单次发送恢复已验证,但损坏目录隔离与失效原路由的终结出现回归。

范围是结果回传与回执恢复;不改变 Inbox 采纳、Todo/lease 权限或 provider 默认,也不认证真实 Lark 服务或完整迁移推广。

结论:REQUEST_CHANGES。有两处独立 base/head 反证确认的 P2 恢复回归:一个非法历史目录会中断整轮扫描;原 Session/Turn 已不存在的已接受回传会永久停留在待核验状态。 这两点都发生在现有正常回归测试通过的情况下,具体触发、落盘状态和修复范围见后文。

改动思路

复用现有 return_delivery、result_publication、goal_instance_lifecycle 和 conversation_scope,把回执状态决策收敛在 TypeScript,Python 仅保留实际 Chat/授权观察、Host fence 与 provider IO,方向和规模合理。

当前 PR 应交付一条可从原始请求恢复的完整回传链:保留现有授权与回执身份,修复逐条损坏隔离和 typed 路由失败消解;更广的 Inbox 采用、安装与性能资格沿用 R3/#3225。

沿用现有 Python 编排只修局部问题,能够降低短期变更量,却继续保留 exact/legacy 两套准入、重试和写回知识;仅增加 TypeScript 叶子 RPC 则无法完成已经接受的事务收敛目标。因此这次删除两套旧编排是有实际价值的。关键是把失败语义也一起迁移,不能只在正常路径维持相同的发送结果。

边界 当前职责与验证范围
Python Host 观察原 Chat/授权来源,持有原有 Host effect fence,追加幂等 transcript,调用真实 provider adapter
TypeScript 事务 扫描提示、重新检查来源、准入 token/revision、attempt 检查点、重试/核验消解与原子回执
外部发送 provider 接受后先持久化原 attempt;响应丢失后核验原消息,不派生第二次发送
公开读回 继续使用现有 reply_status、Chat snapshot 与 App HTTP 读回;投递完成不替代 receiver disposition/任务验收

具体改动

完整 diff 为 9 个文件,+932/-1066。生产 Python/TypeScript 共 +568/-979,净减少 411 行;测试 +326/-81;文档 +38/-6。新增的 native 合同覆盖了未知状态、UTF-8/BOM、历史 attempt、CAS、admission 和时钟表示;Python 测试增加真实 Node 进程退出恢复,并把 exact transcript 冲突用例从私有方法 stub 改为真实 registry/Chat 流程。英文和中文 RFC 新段落的范围一致,描述的是这一回传 family 的收敛,没有将其写成 Inbox 或默认采用已完成。

关键代码讲解

  • _deliver_return 从 prepare 指令进入原 transcript/provider 入口;record_attempt 等待 durable checkpoint 后才更新 revision,再交给 settle。Host 取消与 payload conflict 仍在这一 IO 边界处理。
  • scanReturns 将最多 128 个已有结果地址归约为候选提示,后续仍在写锁内重查。当前地址解码放在逐项异常隔离之外,是第一条回归的入口。
  • prepareReturn 组合原请求/route 身份、Goal 生命周期、前序结果投递与私有/外部路由;有已接受 attempt 时返回核验计划。未知 persisted status 保留原字节并拒绝效果,这一已声明修复在独立 base/head 对照中得到确认。
  • returnAuthorityBlocker 应把原对话不存在与权限不再有效交给既有 typed blocker 分类。现在缺失 Session/Turn 先抛解码错误,丢失了原路由不可用这一语义。
  • finishReturn 在写回前检查 state revision、exact admission token、原请求来源和生命周期,再原子写 attempt 或 settlement。原 accepted attempt 在 terminal refusal 中保留,provider receipt 不进入公开 locator 字段。

规范依据是 docs/architecture/rfcs/typescript-control-plane-migration-v0.md,spec_revision=a40caa14fd93474fbb3f21515d4246f37f3b4efb;评审使用本 PR 修改之前的 accepted 文本。

criterion_id 本轮处置
3.2 Payoff-phase decision implemented:事务决策复用既有 TS owner,两套 Python 规则编排及 normalize-attempt RPC 同 PR 退役;保留实际 Host/provider IO 的退出条件已说明
5 Payoff-phase PR contract deferred:独立核对了净生产行数和保留调用者;完整 recovery-path crossing/installed-profile 成本资格仍需与现有 R3/#3225 验收一并补齐,不从作者诊断数字推断正式性能通过
6 Correctness not_met:native 的 CAS、accepted-attempt 和 malformed-state 用例通过,但非法目录与缺失原路由两种失败组合的长期恢复不成立
6 Caller-observable semantic parity is a promotion gate not_met:相同不可变基线/当前 head、相同脚本、真实 Python→TS 入口下,完整异常与落盘状态发生未声明变化
6 Performance not_met(资格缺口):本轮未执行完整 cold/warm/CLI/default-profile p50/p95 与 daemon memory gate,不把源代码通过、测试数量或作者 stdio 诊断当作性能资格

对主干的风险

P2:把非法扫描地址隔离到单个候选,不能中断整轮回传

位置:return_delivery.ts:227–228。iter_result_paths 会枚举结果根目录下的子目录;只要存在一个诸如 replies/!orphan/conclusion.json 的损坏/遗留目录,request.candidates.map(...returnCommand...) 就在进入下面的逐项 try 之前抛出 request_id is invalid。异常从 _pending_return_paths 逸出 drain,后台服务只能再次扫描同一坏目录。

实际对照: 同一临时 fixture 同时包含上述坏目录和一个合法待返回结论。基线返回合法结论,合法状态为 delivered、原 transcript 新增 1 条;当前 head 抛 EffectRuntimeRejected,合法状态仍为 queued、新增 0 条。坏目录恰在第一批时,其他正常用户的结果也持续不能返回。这不是要求接受非法 request id,而是要求局部损坏不夺走无关请求的进度。

最小修复:把每个候选地址的解码纳入逐项隔离,或由既有目录扫描 owner 过滤不合法目录;保留顶层 schema/batch 限制,保留写锁内二次检查。补充真实 drain 回归:同批混合合法结果与非法目录,坏项保持无效果,合法结果仍只回传一次。

P2:原 Session/Turn 消失时保留 terminal 路由失败分类

位置:return_delivery.ts:350–352,关联 prepareReturn 的 catch 与 sourceFailure。对于 legacy verification_required 且已有合法 attempt 的记录,若原 Session 或 Turn 已删除,Host 会给出空来源;这里的 requireJsonObject 抛错后被归为未分类来源失败,sourceFailure 没有得到 original_route_unavailable,因此既不终结,也不设置新的退避。

实际对照: 先让受控 provider 接受一次发送并保存原 attempt,再分别移除原 Session 或 Turn。基线得到 explicit_unverified / original_route_unavailable,保留 attempt,下一次 pump 为 processed=0;当前 head 两种情况都维持 verification_required / provider_delivery_unverified,下一天再次 pump 仍为 processed=1。两边都没有重发,也没有调用 verifier;问题是当前 head 将已经无法恢复的原路由永久展示为待核验并不断计入每轮 20 条处理预算。积累这样的历史记录会进一步阻塞后续结果。

最小修复:在 typed source boundary 显式把缺失的原 Session/Turn 分类为既有 original_route_unavailable;保持短暂 IO/readback 错误可重试,并保留原 accepted attempt,不能因此重发或改投其他对话。该失败消解还应保持完整诊断:同一 exact verifier 抛普通 RuntimeError 时,基线是 provider_verification_unavailable,当前 head 在 deliveryOutcome 末尾变成 original_route_or_return_delivery_unavailable;这项较轻的漂移一并补充到失败分类回归即可。

本轮验证与证据边界

  • 普通生产入口:118 passed。 python -m pytest -q tests/test_manager_context_roundtrip.py tests/test_collaboration_goal_instance.py --tb=short --maxfail=5,包括正常本地 socket runtime、CLI 子进程、真实 App HTTP 读回、Goal 重建、并发、原请求身份及真实 Node 进程退出恢复。Python 3.12.14 / Node 24.19.0;载入的源码确认为本 exact head。
  • Native:23 passed。 node --no-warnings --experimental-sqlite --experimental-strip-types --test tests/control_plane_ts/manager_return_transaction.test.ts tests/control_plane_ts/manager_return_delivery.test.ts。新增 20 个事务 case 与原 3 个分类 case 均执行。
  • 独立反证: return_counterexamples.py 在 a40caa14fd93474fbb3f21515d4246f37f3b4efb 与 198ec1ced1b45b845873a26b24b978275bbe3353 调用相同 drain / Chat / registry / receipt 边界,使用真实 TS runtime 和临时文件;provider 是受控本地 adapter,没有发送真实消息。脚本 SHA-256 1d1c7dc378af9329ea01434f63f0e3c58f78372b1453e02ec6b7fac3b3154e00。上面已列出决定性的原始状态差异;正常私有回传两边均为首次 1、重启后 0、原 Turn 只有 1 条消息。
  • 作者声明的未知状态修复也被反证验证:基线在 unknown_future_status 下调用 provider 1 次并改写为 delivered;当前 head 为 0 次、保留原状态。不能因为这项修复成立就推断所有异常恢复都保持原契约。
  • Ruff、RFC 双语 diff gate 与 git diff --check 通过。最早默认沙箱运行被本地 socket 权限挡在 dispatch 前,临时 stdio 运行也不能覆盖 HTTP;随后通过授权隔离环境执行的上述完整普通入口已覆盖该环境缺口,早期失败没有被改写为通过。

语义与 CI 对齐

本 PR 复用已有 delivery status、attempt 与 typed blocker,不新建领域状态体系;本轮两处反证违反 accepted RFC 的逐项恢复和完整可观察语义要求。远程快照中主要 TS/静态、浏览器和真实 PostgreSQL job 为 success;6 个 Python shard 当时仍 pending。Windows job 117899336550 的三个长路径预算 case 报 heartbeat_prompt_brief/json 为 10522 字符、上限 10500。相关生成路径未在本 PR 修改,但没有相同 Windows 基线执行证据,归因保持未完成;另有一项 build cancelled。这些是单独的 CI/平台资格状态,两处 P2 的结论来自独立真实入口反证。重新 review 应先补以上两个负例并重跑两套源测试与 native 合同,不调整预算或放宽断言来取得通过。

我的整体评价

problem_context=not_yet_proven:迁移方向、现有 owner 复用和净生产体积都合理,原回执/Host/provider 兼容层确有活跃调用者,本轮不要求另建抽象或恢复旧 Python 语义副本。但当前 whole-PR 的 long_horizon=regression、user_experience=regression:单条历史损坏能阻断无关结果,失效原路由又会无限消耗扫描预算并给出误导性待核验状态,尚未达到完整回传恢复目标。

两处修复应保留现在已经验证的单次发送、原 attempt/Goal-instance 身份、receiver disposition、原 Turn 幂等和未知状态无效果特性。当前源入口的 runtime/HTTP 缺口已补齐;wheel/sdist 的独立普通入口、supported-platform 以及完整性能资格仍未由本轮认证。没有提交过旧的本账号审查可供继承,也未发现已有同类 discussion/inline comment;提交前仍需回读 unchanged head。此结论不授予 merge、provider 推广或发送真实消息权限。

English verdict: REQUEST_CHANGES at 198ec1c. Two reproduced recovery regressions block this head: a malformed candidate directory aborts unrelated returns, and missing original Sessions/Turns leave accepted legacy attempts permanently pending. The same base/head corpus isolates both changes; 118 ordinary Python entrypoint cases and 23 native TypeScript cases pass. Preserve the valid at-most-once and unknown-state fixes while repairing failure isolation and typed source-failure handling; installed/performance and unresolved platform CI qualification remain separate.

Comment on lines +227 to +228
const commands = request.candidates.map(candidate => returnCommand({ ...request,
...requireJsonObject(candidate, "return candidate"), phase: "prepare", facts: {} }));

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] 将地址解码纳入逐条候选的异常隔离

这里的整个 map(...returnCommand...) 在下面逐项 try 之外。结果目录中只要有一个遗留/损坏的 replies/!orphan/conclusion.json,request_id is invalid 就会直接中断 _pending_return_paths / drain,同一批合法结果没有机会回传。

已通过相同脚本、真实 Python→TS runtime 在 merge base 与此 head 对照:基线合法结果为 delivered、原对话新增 1 条;此 head 抛 EffectRuntimeRejected,合法结果仍 queued、新增 0 条。请将候选解码移入单项隔离或在现有扫描 owner 过滤非法目录,保留批量限制与写锁内重查,并加入坏目录与合法结果同批的真实 drain 回归。

Comment on lines +351 to +352
const session = requireJsonObject(command.facts.session, "source session");
requireJsonObject(command.facts.turn, "source turn");

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] 缺失的原 Session/Turn 需要保留 terminal 路由失败分类

对于已有 accepted attempt、状态为 verification_required 的 legacy 回传,原 Session 或 Turn 删除后,这两次 requireJsonObject 会先抛错。随后 sourceFailure 收到未分类 blocker,无法得到既有 original_route_unavailable,记录既不终结,也没有新的退避。

同一真实入口对照中,基线写为 explicit_unverified / original_route_unavailable 并保留 attempt,次轮 processed=0;此 head 两种缺失情形都维持 verification_required / provider_delivery_unverified,隔天仍 processed=1。没有重复发送,但会永久给出待核验状态并反复占用每轮处理预算。请在 typed source 边界显式区分原路由永久缺失与暂时 IO 失败,保留 accepted attempt、不重发、不改投;增加删除原 Session/Turn 后多轮恢复的回归。

@mergify

mergify Bot commented Oct 19, 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, @hhyykk.

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 the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 19, 2026
…y in TypeScript

Signed-off-by: aihop <4408344+hhyykk@users.noreply.github.com>
Signed-off-by: aihop <4408344+hhyykk@users.noreply.github.com>
@hhyykk
hhyykk force-pushed the codex/ts-return-delivery-20261019 branch from 198ec1c to 5899a4c Compare October 19, 2026 11:07
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 19, 2026
…very-6855-20261019

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

mergify Bot commented Oct 19, 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, @hhyykk.

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 the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 19, 2026
Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.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

Exact head: fdbbd91c2b27ca33945a95b8cc8d79d9b7ffc681 · merge base: 907ede6e1faff1fab0f2f765dde4358c69c7b7ff

动机

发起委托并等待结果回到原对话的用户,需要进程重启或外部响应丢失后仍能收到一次正确的回复。外部服务已经接受回复时,应核验原发送;无关历史目录损坏和原会话消失也必须有明确的恢复或终结结果,不能反复占用后续处理额度。

本次把两套 Python 回传编排收拢到已有 TypeScript owner。新 head 的局部损坏隔离、缺失原路由终结和普通回传已独立验证;完整安装入口与默认 SQLite 全路径成本资格仍缺。

范围限于结果回传及回执恢复,不包括整个 Inbox 迁移、Todo/租约权限、真实 Lark 发送或父路线完成。剩余资格沿用原 RFC/#3225,源码恢复修复可以单独核验,完整 cutover 仍受原验收门约束。

改动思路

保留现有事务 owner 与 Host/provider IO 的分工:TypeScript 统一准入、attempt 检查点和回执状态,Python 读取原 Chat/授权事实、持有 fence 并执行外部效果;不恢复第二份 Python 决策。

当前 PR 的边界是一个完整回传事务及旧编排退役;原始身份、单次发送和后续恢复必须通过真实调用方验证,安装与完整成本按原 RFC 补齐。

路径 当前责任
扫描 逐个解码地址,坏项仅增加 unavailable_count;合法项仍进入锁内复核
原路由 已完成查询返回 null 时分类为 original_route_unavailable;短暂 IO 错误保持可重试
provider 接受 先保存原 attempt,响应丢失后核验,不派生第二次发送
回执/展示 同一原子 writer 保存状态,既有 reply_status 与 Chat/HTTP 读回;投递不替代 receiver 采纳

这比继续维护 exact/legacy 两套 Python 规则更容易统一修复;再增加叶子 RPC 无法完成同一事务的知识退役。小范围的 returnAddress 提取复用了 prepare 和 scan 的身份解码,并把坏地址隔离到单项,属于有实际调用者的改进。结构表用于解释源码,不是运行证明。

具体改动

完整 9 文件 +1062/-1073:生产 +589/-986,净减 397 行;测试 +435/-81,文档 +38/-6。删除两套 Python 编排、private attempt-normalization RPC;保留真正外部的 Chat、授权、Host 和 provider 调用。不能把删除的 IO 行、较少 crossing 或测试数量直接换算成长期收益。

关键代码讲解

  • _deliver_return 根据 typed prepare 计划执行原 transcript/provider,等待 attempt 检查点后再 settle;保留取消与 payload conflict 的 Host 边界。
  • returnAddress 仅产生已验证的 request_id/result_key,候选字段不能覆盖事务根目录和 scope。scan 的地址异常现已逐项隔离。
  • returnAuthorityBlocker 在通用对象解码前识别已完成查询的 null Session/Turn;保留原 accepted attempt,并采用既有 terminal 原因。
  • finishReturn 在同一 mutation lock 中复核来源、revision、Goal lifetime 和 exact token,再原子保存 attempt 或 settlement。

依据是变更前接受的 TypeScript migration RFC,spec_revision=907ede6e1faff1fab0f2f765dde4358c69c7b7ff;新 checkpoint 文本不能代替独立资格。

criterion_id 当前处置
3.2 Payoff-phase decision implemented:复用既有事务 owner、同 PR 删除旧规则,实际外部 IO 留有退出条件
5 Payoff-phase PR contract deferred:核对当前 diff/owner/callers;完整公开 happy/recovery 路径成本未认证,作者诊断调用数不等于正式资格
6 Correctness implemented(本轮有界源码范围):原两项恢复反例、accepted-attempt、单次原路由和 native 负例通过;安装/其他平台另列
6 Caller-observable semantic parity is a promotion gate not_met(剩余资格):正常源码入口已补,但 fresh wheel/sdist 的普通真实入口及完整分支资格没有本轮可核的执行记录
6 Performance not_met:默认 SQLite cold/warm、完整事务/CLI p50/p95、idle/burst memory 未完成;保留原 5%/25ms 门

对主干的风险

两处旧源码阻断已修复。 本轮先在旧 head 5899a4c7 重现,提交前发现更新而停止旧评审发布,再对当前完整提案和新的 main 基线重验。相同物理路径、原始身份和不可变输入下:

  • 混合非法目录与合法结果:当前只处理合法项一次,原对话新增一条回复;坏项不写伪回执,后轮 processed=0。基线也能交付合法项,但会给坏项制造 retry 计数,因此总 processed 不逐字节相同。这一局部无效果修正符合隔离要求,应在 parity 记录中明确。
  • 原 Session 或 Turn 被删除:当前与当前基线均为 explicit_unverified / original_route_unavailable,原 attempt 保留,后轮为 0,零重发、零 verifier 调用。
  • 关闭会话、撤销授权、普通私有回传完整规范化观察相同。未知状态仍是已声明修复:基线发送一次,当前零发送并保留原状态。普通 verifier 异常两边都退避并保留 attempt,head 明确给出 provider_verification_unavailable;该诊断差异保留,不声称整个输出完全等价。

当前 REQUEST_CHANGES 的依据是剩余 cutover 资格,不是继续指控已修复缺陷。 accepted RFC 第 6 节要求 fresh wheel/sdist 执行深层普通生产入口,并报告默认 SQLite 的 cold/warm、完整事务和 CLI p50/p95、往返数、idle/burst memory。作者说明普通 socket/HTTP 环境受限;本轮源码正常 runtime 和真实 HTTP/Chat 测试补了部分缺口,仍没有独立的 installed normal-entry 与完整默认成本记录。stdio、源码单测或仅安装包内 handler 不能替代这些门。

最小补齐:在这份 repaired exact head 上,用同一有界语料运行普通 wheel/sdist 真实入口,记录完整字段、诊断、状态和副作用;再按原默认 SQLite profile 做匹配基线的完整成本测量。File-only 性能单列,不把它变成默认 SQLite 的额外阻断;不要求无关父 RFC 或付费模型试验。

本轮实际执行:相关 Python 123 passed、native 27 passed、TypeScript 编译通过;当前 base 的源 premerge 6 direct +19 selected 全部通过,含双语和语义检查。相同 8 类 fixture 在当前 base/head 使用正常 managed runtime、真实临时 Chat/文件和受控 provider;没有 live 消息。新增 main 的绑定对话 UI 为邻接调用方变化,已核 API/投影连接;本 PR 不改其布局,源码 HTTP 测试保留其真实 store 边界,Host 活跃状态仍有合成部分。

语义与 CI 对齐

继续复用已有 delivery status、attempt、Goal lifetime 和 typed resolution,没有新增 peer/任务权限。局部坏地址与 null 原路由的语义修复已由独立旧失败→新通过确认。剩余阻断映射到当前 RFC 的安装和性能资格,不能从 checkpoint 段落推导豁免。CI 按当前配置不查询、不轮询、不等待,未将作者 hosted 状态当作本轮证据。

我的整体评价

结构上保留当前 owner,规模合理,旧恢复问题修复已验证。当前 problem_context=not_yet_proven;源码范围的持续恢复已有改善,完整 cutover 的 long_horizon=not_yet_proven、user_experience=not_yet_proven,原因是默认成本与安装后普通任务旅程仍未资格化。结论为 REQUEST_CHANGES,补齐上述现有验收即可重新判定,无需恢复旧 Python 规则或再造设置、队列和审批流程。

English verdict: REQUEST_CHANGES at fdbbd91 for the remaining accepted cutover qualification. Both previous recovery regressions now pass the same normal-runtime counterexamples; 123 Python cases, 27 native cases, TypeScript compilation and current-base source premerge pass. Fresh installed normal-entry parity and complete default-SQLite performance evidence remain unverified. Preserve the verified repairs and single transaction owner while completing those existing gates.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>
@mergify mergify Bot removed the needs-rebase Mergify: the pull request has merge conflicts with its base branch label Oct 19, 2026

@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

动机

等待委托结果的用户及执行回传的 Agent。

结果已经被外部平台接受,但响应丢失后进程重启,回传必须核对原消息,不能再发一遍;坏目录也不能阻断同批合法结果。

当前版本已验证合法结果仍回到原会话一次,原记录缺失会明确停止已接受的尝试,typed 写前故障保留原因并可恢复。

本 PR 只替换现有结果回传事务,不交付完整接收者采用、2.0 原地升级、跨机器迁移或 live provider 验收。

默认 SQLite 的完整 CLI 成本资格尚未通过,最终主干组合只有功能及安装包证据。

改动思路

保留现有 TypeScript 事务 owner、Python 真实 IO 和来源 fence,删掉两条协调器,比新建回传或升级框架更符合现有边界。 当前 PR 只完成一组回传规则替换和恢复修复;完整成本未合格前不合并,接收者采用与原地升级不计作本次交付。

原来“按精确实例”和“兼容历史记录”的两条 Python 协调路径,都要安排扫描、准入、重试和回执落盘;现在把这些决策收回已有的 return_delivery.ts。Python 保留真正访问原会话、权限、文件和平台的 IO,TS 不替用户发消息,也不产生新的授权。这样后续修复同一条回传规则只改一个 owner。扫描只是提示,写锁内还要核对原始记录和版本,平台接受回调会先保存凭据,再进入核对或收尾。

这是默认路径替换,没有新增 opt-in 配置、队列、升级执行器或用户确认轮次。直接不改会保留重复协调规则;只修 Python 的两处 bug 虽然更小,却没有完成已接受的替换边界。更大的迁移框架也没有必要。本次仅复用现有 CLI request scope,避免同一命令重复检查可执行版本,不缓存业务状态或权限。

具体改动

本次重新判断整个目标分支到当前 head 的改动,并单独核对前次评审后的恢复修复。精确 head:d2f6aefde4c48e1c9d773c523a8faaaf1a2db680;已集成并核对实际目标 main:dc45c128d630cd8f043690a9a00251615d7d13b4。GitHub PR 的缓存 base SHA 不作为回退主干依据。

验收依据 docs/architecture/rfcs/typescript-control-plane-migration-v0.md,spec_revision=dc45c128d630cd8f043690a9a00251615d7d13b4,按已接受版本判断,PR 中新增的说明段落不充当自我验收标准。Correctness 已实现:原来源、Goal 实例、写锁、版本和尝试凭据约束保留;Caller-observable semantic parity 已执行完整字段对照,并披露坏地址零回执这一有意修正;Performance 尚未满足;Install, upgrade, and rollback 在本切口的 wheel/sdist 打包与运行边界已验证,不宣称现场升级完成。

关键代码讲解

  • scanReturns 把坏候选地址的拒绝限定在单个条目;共享 root/exact/时钟包络仍先验证。坏目录不会阻断同批合法结果,也不会给它补写错误的回执。原主干虽然能返回合法结果,却会写孤儿 retry 回执;新测试对此更严格,这项差异没有被抹掉。
  • _deliver_return 仍在真实 Host/source fence 下取得原会话和授权,再按 TS 计划写原 Chat、调用平台、checkpoint 和 settle。原平台已接受而响应丢失时,下一次依据保存的定位凭据核对原消息,不重新发送。事务与扫描桥共 40 行;删除的 Python 并非全部都是纯决策。
  • sourceFailure 区分“实际查不到原 Session/Turn”和 IO 暂时失败。已接受尝试遇到前者会明确终止、保留尝试;未发送前的 typed 原因保持 retry_pending,来源恢复后仍能继续原结果。
  • deliveryOutcome 保留 exact verifier 异常的 provider_verification_unavailable,复用原 verifier classifier,并接住已合入 #6873 的 typed 写前原因。普通异常即使文本同名也不会被当作撤权证据;平台已写但没有定位凭据的情况也不会悄悄变成可重发。

整个目标相对 diff 是 10 文件:运行代码 +595/−990,测试 +435/−81,文档 +38/−6。两条旧协调器和无独立消费者的 normalize RPC 删除;仍有实际调用者的 classify RPC、历史尝试与回执 codec 保留。主干已有的 UI 和测试没有重复混进 diff。

对主干的风险

最终源码 382 项 Python、32 项原生测试通过,类型检查、Ruff、双语 RFC 和标准 premerge 的 19 项检查通过。最终 wheel 和 sdist 分别在全新 Python 3.14.8 环境安装,4 个产品文件 hash 与 head 一致,每种安装均通过真实 CLI/SQLite 私有回传、模拟平台接受后响应丢失再恢复,以及 3 项恢复反例。模块来源也核在安装目录,未借源码 checkout 通过。Chat bundle 在集成主干后曾过期,刷新后两种包构建成功;这些是隔离构建验证,没有替换现场服务。

不可变当前主干和最终 head 的私有/外部路径,完整比较结果 JSON、delivery JSON、原 Chat 行、公开状态、CLI JSON 和 effect 计数,只归一化 ISO 时钟值,字段没有裁掉,结果一致。反证保留:修复前候选的 3 个 Python/4 个原生恢复案例失败;主干 #6873 原封不动的 14 个案例在集成前 11 失败/3 对照通过,适配后全部通过。原来的独立评审两处发现已修复,但没有 dismiss 别人的评审。

语义与 CI 对齐

当前仍有一个合并阻塞:默认 SQLite 完整 CLI 成本资格未通过。既有 Performance 约束要求 warm 非持久转换低于 2ms p95,完整 CLI 不应超过 5% 或无法解释的 25ms additive p95。本次是实际默认 SQLite 路径,不能套用“File-only 不阻塞”的例外。

固定 32 对交替测量 外部 CLI p95 结论
907ede6e1 → fdbbd91c2 761.92 → 828.13 ms,+66.21 ms / +8.69% 失败
907ede6e1 → 8af44c585,复用 request scope 后 630.76 → 771.72 ms,+140.96 ms / +22.35% 失败

第二次中位数和 API/drain 调用数改善(31→11),scope 内 warm p95 约 0.377ms,但这些不能抵消完整命令尾延迟。两组样本全部保留,未放宽门槛或丢弃慢样本。最终 d2f6aefde 主干集成只证明功能与打包,不能被写成最终性能已过。profile 指向共用 CLI 启动/指纹成本,尚未证明 Node/SQLite 的具体 CPU 回归原因。

最小下一步是在已有 owner 内区分 caller 启动、共享 transport 与 provider 成本,做有判别力的稳定性对照,再按原完整 workload 对最终版本重新资格;不要继续无改动重跑碰绿,也不要因此扩展出 CLI 框架重写。exact-scope CQR 如实为 FAIL。按本 Goal 的配置没有查询、轮询或等待 CI;这不是用远端 CI 缺席增加阻塞。

我的整体评价

REQUEST_CHANGES,保留不合并。 恢复缺陷和主干合入后的 typed 原因兼容已经实修,并由实际生产入口验证;没有再复现新的正确性缺陷。设计的机制与范围可以保留:单一既有 TS owner、Python 真实 IO、原回执兼容,净删运行代码,附带两行已存在 scope 复用;不要求另起框架或把全部 RFC 做完。

long_horizon 判断 preserved:原结果、尝试凭据与原会话跨重启保留,重复 drain 不再发,确定缺失的原记录有终止出口。user_experience 判断 not_yet_proven:用户没有新增必填信息、导航或确认轮次,但默认 SQLite 的完整延迟资格仍缺证据。只需修复或解释这个当前性能缺口后重新评审当前完整 head,而不是反复累加测试数量。

语义归属为扩展既有 return owner 的私有事务协议,复用现有状态/原因与历史 codec;diff advisory 没找到支持范围内的新载体,不等于没有新语义。正确性与包验证通过也不代表接收者独立采用、live provider 或模型使用效果已验收。这些边界以及更广泛的原地升级工作仍单独保留。

English verdict: REQUEST_CHANGES. Recovery findings and current-main typed prewrite semantics are fixed; final source, native and isolated wheel/sdist real-path checks pass. Keep the cohesive existing-owner cutover, but hold merge until the final default SQLite full-CLI cost is qualified under unchanged budgets. Both failed paired measurements remain evidence; fewer RPCs and passing correctness tests do not replace that qualification.

…ery-20261019

Signed-off-by: aihop <4408344+hhyykk@users.noreply.github.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

动机

等待委托结果的用户及执行回传的 Agent。

结果已经被外部平台接受,但响应丢失后进程重启,回传必须核对原消息,不能再发一遍;坏目录也不能阻断同批合法结果。

当前版本已验证合法结果仍回到原会话一次,原记录缺失会明确停止已接受的尝试,typed 写前故障保留原因并可恢复。

本 PR 只替换现有结果回传事务,不交付完整接收者采用、2.0 原地升级、跨机器迁移或 live provider 验收。

默认 SQLite 的完整 CLI 成本资格尚未通过,最终主干组合只有功能及安装包证据。

改动思路

保留现有 TypeScript 事务 owner、Python 真实 IO 和来源 fence,删掉两条协调器,比新建回传或升级框架更符合现有边界。 当前 PR 只完成一组回传规则替换和恢复修复;完整成本未合格前不合并,接收者采用与原地升级不计作本次交付。

原来“按精确实例”和“兼容历史记录”的两条 Python 协调路径,都要安排扫描、准入、重试和回执落盘;现在把这些决策收回已有的 return_delivery.ts。Python 保留真正访问原会话、权限、文件和平台的 IO,TS 不替用户发消息,也不产生新的授权。这样后续修复同一条回传规则只改一个 owner。扫描只是提示,写锁内还要核对原始记录和版本,平台接受回调会先保存凭据,再进入核对或收尾。

这是默认路径替换,没有新增 opt-in 配置、队列、升级执行器或用户确认轮次。直接不改会保留重复协调规则;只修 Python 的两处 bug 虽然更小,却没有完成已接受的替换边界。更大的迁移框架也没有必要。本次仅复用现有 CLI request scope,避免同一命令重复检查可执行版本,不缓存业务状态或权限。

具体改动

本次重新判断整个目标分支到当前 head 的改动,并单独核对前次评审后的恢复修复。精确 head:d03ba38a73d11e376e5638a52e9f48a861c6b2ab;实际目标 main:94e9f036f3b1d209cd04133ad87f710947fd512c。GitHub PR 的缓存 base SHA 不作为回退主干依据。

作者在前次评审发布后只合入了主干 #6861 的 DSH/pnpm 配置修复;我逐字核对新旧两个 base/head 的 10 个文件 blob 和整个目标相对 diff,均完全一致,共享 return/caller/transport 与构建输入没有变化。下面 382/32、打包、完整字段和成本证据仍明确来自实际执行的 d2f6aefde4c48e1c9d773c523a8faaaf1a2db680,经失效检查复用到当前 head,没有重命名旧实测或为无关主干配置重跑同一批检查。当前完整复审仍保留相同成本缺口。

验收依据 docs/architecture/rfcs/typescript-control-plane-migration-v0.md,spec_revision=dc45c128d630cd8f043690a9a00251615d7d13b4,按已接受版本判断,PR 中新增的说明段落不充当自我验收标准。Correctness 已实现:原来源、Goal 实例、写锁、版本和尝试凭据约束保留;Caller-observable semantic parity 已执行完整字段对照,并披露坏地址零回执这一有意修正;Performance 尚未满足;Install, upgrade, and rollback 在本切口的 wheel/sdist 打包与运行边界已验证,不宣称现场升级完成。

关键代码讲解

  • scanReturns 把坏候选地址的拒绝限定在单个条目;共享 root/exact/时钟包络仍先验证。坏目录不会阻断同批合法结果,也不会给它补写错误的回执。原主干虽然能返回合法结果,却会写孤儿 retry 回执;新测试对此更严格,这项差异没有被抹掉。
  • _deliver_return 仍在真实 Host/source fence 下取得原会话和授权,再按 TS 计划写原 Chat、调用平台、checkpoint 和 settle。原平台已接受而响应丢失时,下一次依据保存的定位凭据核对原消息,不重新发送。事务与扫描桥共 40 行;删除的 Python 并非全部都是纯决策。
  • sourceFailure 区分“实际查不到原 Session/Turn”和 IO 暂时失败。已接受尝试遇到前者会明确终止、保留尝试;未发送前的 typed 原因保持 retry_pending,来源恢复后仍能继续原结果。
  • deliveryOutcome 保留 exact verifier 异常的 provider_verification_unavailable,复用原 verifier classifier,并接住已合入 #6873 的 typed 写前原因。普通异常即使文本同名也不会被当作撤权证据;平台已写但没有定位凭据的情况也不会悄悄变成可重发。

整个目标相对 diff 是 10 文件:运行代码 +595/−990,测试 +435/−81,文档 +38/−6。两条旧协调器和无独立消费者的 normalize RPC 删除;仍有实际调用者的 classify RPC、历史尝试与回执 codec 保留。主干已有的 UI 和测试没有重复混进 diff。

对主干的风险

最终源码 382 项 Python、32 项原生测试通过,类型检查、Ruff、双语 RFC 和标准 premerge 的 19 项检查通过。最终 wheel 和 sdist 分别在全新 Python 3.14.8 环境安装,4 个产品文件 hash 与 head 一致,每种安装均通过真实 CLI/SQLite 私有回传、模拟平台接受后响应丢失再恢复,以及 3 项恢复反例。模块来源也核在安装目录,未借源码 checkout 通过。Chat bundle 在集成主干后曾过期,刷新后两种包构建成功;这些是隔离构建验证,没有替换现场服务。

不可变当前主干和最终 head 的私有/外部路径,完整比较结果 JSON、delivery JSON、原 Chat 行、公开状态、CLI JSON 和 effect 计数,只归一化 ISO 时钟值,字段没有裁掉,结果一致。反证保留:修复前候选的 3 个 Python/4 个原生恢复案例失败;主干 #6873 原封不动的 14 个案例在集成前 11 失败/3 对照通过,适配后全部通过。原来的独立评审两处发现已修复,但没有 dismiss 别人的评审。

语义与 CI 对齐

当前仍有一个合并阻塞:默认 SQLite 完整 CLI 成本资格未通过。既有 Performance 约束要求 warm 非持久转换低于 2ms p95,完整 CLI 不应超过 5% 或无法解释的 25ms additive p95。本次是实际默认 SQLite 路径,不能套用“File-only 不阻塞”的例外。

固定 32 对交替测量 外部 CLI p95 结论
907ede6e1 → fdbbd91c2 761.92 → 828.13 ms,+66.21 ms / +8.69% 失败
907ede6e1 → 8af44c585,复用 request scope 后 630.76 → 771.72 ms,+140.96 ms / +22.35% 失败

第二次中位数和 API/drain 调用数改善(31→11),scope 内 warm p95 约 0.377ms,但这些不能抵消完整命令尾延迟。两组样本全部保留,未放宽门槛或丢弃慢样本。最终 d2f6aefde 主干集成只证明功能与打包,不能被写成最终性能已过。profile 指向共用 CLI 启动/指纹成本,尚未证明 Node/SQLite 的具体 CPU 回归原因。

最小下一步是在已有 owner 内区分 caller 启动、共享 transport 与 provider 成本,做有判别力的稳定性对照,再按原完整 workload 对最终版本重新资格;不要继续无改动重跑碰绿,也不要因此扩展出 CLI 框架重写。exact-scope CQR 如实为 FAIL。按本 Goal 的配置没有查询、轮询或等待 CI;这不是用远端 CI 缺席增加阻塞。

我的整体评价

REQUEST_CHANGES,保留不合并。 恢复缺陷和主干合入后的 typed 原因兼容已经实修,并由实际生产入口验证;没有再复现新的正确性缺陷。设计的机制与范围可以保留:单一既有 TS owner、Python 真实 IO、原回执兼容,净删运行代码,附带两行已存在 scope 复用;不要求另起框架或把全部 RFC 做完。

long_horizon 判断 preserved:原结果、尝试凭据与原会话跨重启保留,重复 drain 不再发,确定缺失的原记录有终止出口。user_experience 判断 not_yet_proven:用户没有新增必填信息、导航或确认轮次,但默认 SQLite 的完整延迟资格仍缺证据。只需修复或解释这个当前性能缺口后重新评审当前完整 head,而不是反复累加测试数量。

语义归属为扩展既有 return owner 的私有事务协议,复用现有状态/原因与历史 codec;diff advisory 没找到支持范围内的新载体,不等于没有新语义。正确性与包验证通过也不代表接收者独立采用、live provider 或模型使用效果已验收。这些边界以及更广泛的原地升级工作仍单独保留。

English verdict: REQUEST_CHANGES. Recovery findings and current-main typed prewrite semantics are fixed; final source, native and isolated wheel/sdist real-path checks pass. Keep the cohesive existing-owner cutover, but hold merge until the final default SQLite full-CLI cost is qualified under unchanged budgets. Both failed paired measurements remain evidence; fewer RPCs and passing correctness tests do not replace that qualification.

…ation

Signed-off-by: aihop <4408344+hhyykk@users.noreply.github.com>
…ery-20261019

Signed-off-by: aihop <4408344+hhyykk@users.noreply.github.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

Exact head: 6855@7c20c6b00e91fd581aadfde1fb663a4cf67fc736 · actual merge base: 6e8688d8d90f1c5a99fadf81def8e4ca2e79c925.

动机

等待委托结论返回原对话的用户,以及负责可靠回传的 Agent。

外部平台已经接受回复但响应丢失后,下一轮应核验原消息;坏历史目录不能挡住合法结果,失效原会话也不能永远占用处理额度。

当前真实入口支持一次回传、缺失原路由终结及保留 accepted attempt;默认 SQLite 的完整命令性能资格仍未成立。

本片不完成整个 Inbox、接收者独立采用、跨机器迁移、真实平台发送或正式服务升级。

原两组完整 SQLite CLI p95 失败保留,当前整合头仍缺合格的最终成本证据。

改动思路

保留既有 TS 回传事务 owner 与 Python 真实 IO/fence,删除 exact/legacy 两套协调规则;不为成本缺口另造队列或 CLI 框架。 当前 PR 的边界是一次完整回传事务替换;既有默认 SQLite 成本资格未通过前仍不能视为完成 cutover。

原来 exact 和 legacy 两条 Python 协调路径分别安排扫描、准入、尝试记录、重试和回执。现在复用已有 return_delivery.ts 与 result/lifetime/verifier owner,Python 只读取真实原会话/授权、持有原 fence、追加原 transcript 和执行 provider IO。扫描是候选提示,锁内要重新核原始结果和版本;平台接受回调先等 durable attempt,再继续核验。投递成功不是接收者采用,更不会产生另一份权限。

维持两套 Python 规则虽能少改几行,却保留同一事务的重复知识;增加更多叶子 RPC 也没有完成已接受的收敛。当前机制可以保留,不需为了性能缺口重写 CLI。源码职责表比另画未渲染的流程图更直接;下面是源码边界说明,不是执行证明。

边界 当前职责
Python IO 原 Chat/授权事实、原来源 fence、幂等 transcript 和真实 provider
TS 事务 bounded scan、准入、revision/token、attempt checkpoint、失败消解和原子回执
后续恢复 已接受发送只核验原消息;缺失原路由明确终止并保留原 attempt
读回 原 reply_status/Chat;receiver 采纳和完整父路线仍独立

具体改动

依据变更前接受的 docs/architecture/rfcs/typescript-control-plane-migration-v0.md,spec_revision=6e8688d8d90f1c5a99fadf81def8e4ca2e79c925;新增 RFC checkpoint 不是自我验收依据。3.2 Payoff-phase decision 和 5. Payoff-phase PR contract 的既有 owner/规则退役方向成立;Correctness 与 Caller-observable semantic parity is a promotion gate 的本轮有界真实入口已执行,差异明确披露。Performance 未满足;Install, upgrade, and rollback 的旧安装记录仍按原执行版本保留,未冒称当前整合版本的安装执行。

  • _deliver_return 接收 prepare 计划,在原 source fence 下执行 transcript/provider。接受尝试的回调等待 TS 写盘,后续 settle 复查原来源,不把响应丢失当作重新发送许可。
  • scanReturns 单独解码候选地址;损坏目录只影响该项,顶层 schema、根路径和128项界限仍拒绝非法输入。prepare 在锁内重读,提示不能替代权威状态。
  • sourceFailure / returnAuthorityBlocker 把实际查不到 Session/Turn 与暂时 IO 区分。已接受尝试遇到前者进入原 terminal 状态,保留 attempt、零重发;普通异常的文字不能伪装成撤权。
  • finishReturn 复核 state revision、原结果/路由、Goal lifetime 与 exact token 后原子保存。locatorless write、过期含糊准入、corrupt receipt 和并发 stale settle 都保留无重复效果边界。

完整当前目标相对范围10文件 +1066/-1075:产品 +595/-990,测试 +435/-81,文档 +36/-4。两套旧协调器和无剩余消费者的 normalize RPC 删除;仍有实际调用方的 classifier、历史 attempt 和 receipt codec 保留。原 handler 与 CLI 共用已有 request scope;它只绑定代码版本,不缓存权限或业务状态。作者开头“only documentation and tests”不能代表真实范围,本次仍按整个运行切换审查。

与前次 d03 逐文件比对,核心 roundtrip、CLI、return transaction 和 native 测试 blob 相同;当前实际 main、共享 transport、Chat store、依赖和部分测试已有变化。故旧382/32、wheel/sdist、成本记录保持原版本;没有因核心源码相同就继承结论。本轮重新执行正常 managed runtime/原会话边界的134项 Python、27项 native,零 skip;TypeScript编译、6直接+19选中premerge全过,双语和公开边界通过。一次不存在的 npm typecheck 脚本调用是评审器命令错误,改用仓库实际 tsc 命令完成,原失败保留。

同一8类冻结输入在当前不可变 base 与本头执行真实 drain/Chat/文件及受控 provider,完整公开状态、原消息、attempt、错误和后续 pump 都保留,仅归一化生成的 wall-clock 元数据。普通私有返回与缺失 Session/Turn、关闭会话、撤权的观察一致;缺失原路由终止后下一轮0,零发送/核验。三项有意差异未被掩盖:坏目录不再补孤儿 retry 记录或重复计入 processed;未知状态由旧的发送改为保留原字节、零发送;普通 verifier 异常保留 provider_verification_unavailable 和原 backoff/attempt。这些改善不构成成本资格。

对主干的风险

[P2] 默认 SQLite 完整命令性能资格仍未通过。 位置是本 PR 替换的 roundtrip.drain/manager-inbox 默认回传路径,约束来自 accepted Performance;不是要求修复不相关的 CI。

已有固定32对交替测量 完整外部CLI p95 原结论
907ede6 → fdbbd91 761.92 → 828.13ms;+66.21ms/+8.69% 失败
907ede6 → 8af44c5,复用request scope后 630.76 → 771.72ms;+140.96ms/+22.35% 失败

两组都不满足原5%或无法解释25ms additive p95门。当前作者仍明确保留 hold,且无最终整合头的合格完整 CLI 记录。本轮未重跑无干预样本碰绿、未改门槛,也不将旧数字冒称当前6e→7c的因果测量。较少 crossing、warm0.377ms、净删代码和当前功能绿灯都不能替代完整默认路径。源码正常运行已补充;当前轮未重建/安装两种发布包,旧包通过记录不被悄悄移动到新版本。

最小补齐仍是原 owner 内有界区分 caller 启动、共享 transport 与 provider 成本,保留稳定性控制与每个失败,再按原完整 SQLite workload 对最终头资格化。若证据说明观测被环境/比较上下文混淆,应明确解释并给匹配控制,不能直接改写旧失败。File-only 性能不是这次 SQLite 默认门的替代,也不额外成为默认交付门。不要恢复重复 Python 规则、引入新的通用框架或要求收费模型实验。

原最早两处恢复缺陷和 verifier 诊断问题本轮真实反例已重验,不继续把它们说成当前错误;没有 dismiss 他人评审或 resolve 旧讨论。未读取、轮询、等待 CI;功能、打包、平台、成本和实际合并分别保留。

我的整体评价

REQUEST_CHANGES 当前精确头,保留成本资格 hold。 现有 owner 与净删除方向合理,没有新增已复现正确性阻塞;拒绝的依据仍是已接受但未达成的最终默认成本资格。保留既有 TS 回传事务 owner 与 Python 真实 IO/fence,删除 exact/legacy 两套协调规则;不为成本缺口另造队列或 CLI 框架。 当前 PR 的边界是一次完整回传事务替换;既有默认 SQLite 成本资格未通过前仍不能视为完成 cutover。

long_horizon 的原结果身份/attempt/后续恢复在当前有界路径 preserved;user_experience 仍 not_yet_proven,因为日常默认回传的完整尾延迟尚未资格化。原授权与信息不需重复索取,新增必需交互为0;这不能免去实际成本门。用当前 source/caller/依赖证据完成原缺口后再判定,不要求完成无关父 RFC,也不以测试或记录数量替代用户结果。

English verdict: REQUEST_CHANGES at 7c20c6b. The cohesive existing-owner cutover and previous recovery fixes survive current real-path validation: 134 Python cases, 27 native cases, full eight-input base/head observations, typecheck and 6+19 premerge checks. Preserve both failed fixed SQLite full-CLI measurements and the current final-cost qualification gap; fewer crossings and functional passes do not waive unchanged budgets. Current installed/live-provider qualification is not claimed.

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.

3 participants