[LIHUA919]

Related to #5198. The current head combines Goal-ID scoped local room claim and private reconnect context. The latest exact-head review requests a scope revision: keep steward-led automatic delegation as the default, support optional Agent self-claim through existing work selection, and defer the new frontend. That revision remains open. This head still includes the Room work UI and does not establish autonomous discovery → governed execution → return to the original requester.

Private work resume keeps the persisted native Todo/Turn binding through discovery, upgrade and replay, then rechecks current capability scope. Recalled context stays private and grants no execution authority. Preview performs no recall, claim, admission, quota spend or room send. The room projection uses the shared envelope owner for real source-read facts; unknown, stale, unreadable or incomplete readback blocks new claims and hides current counts/ownership. Replaying a claim rereads current facts without renewing historical acceptance.

Current repair and qualification

Author head: a8dac55dffc8d2e428c5d0206587d839765bd872. Append-only integration 52685b03d incorporates official main 55d633748; the actual PR target remains official main. All 70 PR commits have DCO sign-offs. Later main changes were checked for expiry-owner overlap and a clean merge preview; the qualified local baseline is 55d633748.

The prior review's expiry counterexample has an author-validated repair at the existing typed Todo owner; the new review has not independently requalified it. An offer can expire during member/card reads or a subsequent delivery preflight. Its original expires_at now travels as admit_before in claim request v3, retaining the broker/source guards. The owner checks its current clock after reads, immediately before dispatching a new claim CAS; equality is expired. Persistence may finish later. Expired admission changes neither ownership, revision, operation receipt, offer nor room message. Native historical receipts retain their intent and replay behavior; the callback still checks current offer admission. Untimed direct claims retain their existing wire/behavior. Old receivers reject v3, and v0/v1/v2 reject the new field rather than ignore it.

This extends the existing claim protocol and failure vocabulary (claim_expired); it adds no capability, provider, setting or execution lease. Python adapts the original offer and transport; TypeScript owns the final decision. The bounded private adapter seam carries the deadline without exposing it through legacy wires. The semantic advisory found zero supported carriers; that is not a claim that no semantics changed.

Validation	Result and boundary
Original expiry regression	Four real-clock File/SQLite counterexamples accepted after expiry on b3. Six current source probes pass, covering card read, subsequent preflight and delayed native handoff; refused cases preserve full canonical state and exact receipt/message state.
Python integration	289 related cases pass, including the 44 callback cases.
Native suite	4,979 pass, two fail, 73 skip. Both failures reproduce on immutable main 55d633748 and candidate: the content-digest consumer pin and receipt-bound replan expectation. Paired modules each report 37 pass/two fail. The updated authority-source suite separately passes all 11 cases. This is not a green full-suite claim.
Type/lint	Both frontend/control-plane typechecks, configured Mypy and changed-Python Ruff pass. Configured full CI Ruff has one unchanged test_checkpoint_retention.py unused import; its complete output is identical on main/candidate.
Standard premerge	Six direct checks and 18 of 19 selected checks pass. The synthetic human-gate delivery smoke fails with steward_notice_unavailable on both immutable main and candidate; the gate remains failed. Bilingual committed/staged checks and public-boundary checks pass.
Normal distributions	Chat, noneditable wheel and sdist build; all five changed runtime files match wheel bytes. Twelve isolated installed-package CLI/callback cases pass, including the six real-clock probes. No shared installation was updated.
Packaged owning journey	The normal wheel serves the actual File/HTTP room backend; duplicate click, uncertain send, reload/same-key recovery, one canonical transition/card, independent CLI readback, keyboard, bilingual and 390px behavior pass. Discovery and IM transport remain synthetic.
Mixed browser sequence	Complete corrected source catalog: 71/71 passed. The complete normal-wheel catalog stopped at conversation-image-request (32 passed / one failed / 38 unrun, reply viewport assertion). That unchanged scenario passes twice in isolated wheel runs and once in the exact-main packaged control; these do not establish whole-sequence attribution. A later diagnostic recheck stopped earlier at navigation-sorting (seven passed / one failed / 63 unrun), before reaching the modified observation. Its uncommitted observation-only probe was saved privately and removed; the published assertions remain unchanged. The first source attempt used an incorrect base interpreter and stopped at fixture import; that environment failure is retained separately.
Further matched wheel diagnosis	Twenty isolated image trials per tree retained the original assertion: baseline 19 pass/one startup resource reset; candidate 20 pass. A clock-continuous run of the same first 33 catalog entries stopped at baseline 14 pass/one failure/18 unrun and candidate 18 pass/one failure/14 unrun. Both failing journeys recorded static JavaScript ERR_CONNECTION_RESET; the image scenario was not reached. Scenario/context/fixture, dependency lock, conversation CSS and static-serving owner are identical across the two source trees. This establishes a baseline counterexample for that transport failure family, without attributing the earlier image-viewport failure, proving a transport root cause or qualifying the whole catalog. An earlier clock-disrupted pair is retained but excluded from this comparison.
Real PostgreSQL	PR-head run store/service job passed both required steps without a skipped suite. It tests PR merge-result 2837c199, containing author head a8 and target 933162039; all five changed runtime blobs match the author head. This does not qualify the entire room journey on PostgreSQL.

Remaining limits

Full hosted CI, the complete wheel mixed sequence, the static-resource reset root cause, the original image-viewport failure and sustained S10/S12 acceptance remain unqualified. Historical failures and unrun cases are preserved. The old 745 macOS DMG failure still lacks inner-cause attribution; b3's later macOS success does not rewrite it, and current-head platform CI has its own result.

Earlier approvals belong to historical heads. The current a8 head has changes requested for product direction/scope; its technical expiry repair still needs independent qualification. A revised complete head requires fresh review and maintainer merge authority. Installed App/shared CLI adoption, native room/callback rendering, independently authenticated hosts, daemon recovery and live scoped OpenViking remain separate. This source proposal does not close overall issue/RFC acceptance.

Visual evidence

Current normal-wheel room journey: synthetic account/discovery/IM transport, real disposable File/HTTP ownership and independent CLI readback. All three full viewports were inspected again against the current runtime tree; their bytes are unchanged from the existing images. These are packaged browser captures, with no private messages, local paths or host operating context.

Before claim · 1512×982:

Lost response → reload → exact recovery · 1512×982:

Same recovered result · 390×844:

中文：当前 head 仍包含本地 Room work 前端及私有续接。最新评审要求保留管家自动委派为默认、补齐可选 Agent 自主认领并暂缓新增前端；这项范围修订尚未完成，自主发现、受控执行和结果返回也尚未验收。新头修复了 offer 在远端读取或后续预检期间过期仍被领取的问题：原期限由 v3 带到原生 Todo owner，在新领取 CAS 派发前用当前时钟拒绝过期；拒绝保持状态、回执、offer 和消息不变。无期限 CLI 与历史回执语义保留。289 项相关 Python、源码完整 71 场景、12 项普通安装包用例和当前 PR 合并结果的真实 PostgreSQL 已通过；整套原生与 premerge 的已复现主干失败仍保留；完整 wheel 序列在图片回复视口处停止，后续诊断又在更早的导航处停止，不能以独立场景通过代替整体验收。未提交的观察同步诊断已保存并撤回，公开断言未放宽。期限修复已完成作者侧验证，尚需独立评审；维护者合并、安装生效、原生房间/独立宿主、daemon 与 live OV 仍未关闭。

补充对照：在连续计时窗口，同一前 33 场景的普通主干包为 14 通过/1 失败/18 未运行，PR 包为 18 通过/1 失败/14 未运行；失败均伴随静态 JavaScript 连接重置，尚未运行到图片场景。它证明该连接重置有主干反例，但不证明图片视口失败已归因或完整目录已通过。原断言与失败记录均保留，未选择积压队列、超时或运行时修改。

[mergify]

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

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]

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

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; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max

Exact head: 5248@747d4c902520ae6f453a800b2b1a818de82c9415；base: a4483aaece5bc74ec3f969fd067229487022401b。

REQUEST_CHANGES · [P2] 原生多待办 upgraded/replayed 绑定在当前私有重连仍被误拒。 当前源码与新安装 CLI 的真实两存储反例均复现，完整提案和修复要求如下。

动机

已经连接工作群的用户需要直接查看并领取可执行待办，并在连接重建后继续原来的私有工作。

原来需要离开连接页手工拼接领取命令；当前页面能一次领取并显示当前归属，但多个待办场景中的合法重连仍被误拒，用户无法继续原 Turn 的私有上下文。

已安装页面的领取、发送响应丢失后重载恢复和当前归属读回通过；原生调度回执进入私有重连时，两种本地存储均稳定失败。

本次评审限定已接受的本地组合阶段，不把跨宿主服务、真实群聊长跑或记忆后端推广当成本 PR 的既有交付。

完整本地阶段应同时交付领取、丢回复后的原请求恢复和同 Turn 私有继续。旧 P2 已在当前新头重新执行，仍然存在；新的主干整合、前端正常结果和绿测试不能代替这条接续路径。

改动思路

既有 Todo 保持唯一状态和回执权威，provider IO 与原生来源锁分工清楚，页面只保存原请求意图；当前边界足以交付本地组合，但同 Turn 私有重连必须复用完整原生回执与绑定观测。

本 PR 是现有连接下的本地领取、通知恢复和私有重连；修复原生 quota 衔接属于当前阶段，真实群聊、独立宿主与 live provider 继续由已有后续负责。

现有连接已知道 Goal、actor 和房间，正常领取只需一次明确操作，失败恢复沿原 key 继续，不重填已知信息。TS Todo/CAS 与回执仍是唯一工作权威；Python 管连接、provider IO，原生来源 guard 负责跨异步 commit 的序列化。offer principal/revision/expiry 是显式请求意图；浏览器保存的 tuple 只承诺原请求，不等于授权。历史接受、当前 owner、消息送达和执行资格分别回读。

触发	当前实测结果
浏览器存储不可用	领取前拒绝，零 POST
连击、消息响应丢失、刷新后恢复	同一请求，只领取一次、发一张合成房间卡；安装包 CLI 读回当前 owner
provider IO 中绑定/来源漂移	原见证保留到原生效果点；当前回归通过
原生多待办同 Turn 重连	upgraded 被误拒；改用 replayed 仍与无绑定 fresh observation 不匹配

保留现有 owner 的组合比第二任务板或新权限框架更小；只留下 CLI 又会缺页面旅程。前瞻性修复应复用原生回执/选择 owner，不能再维护一个不完整状态白名单或用新 Turn 绕过。

具体改动

独立规范为#5198 及当前不可变基线的已接受 RFC，没有把候选新增 checkpoint 当作自己的验收。

• Projection Contract — implemented：最小 actor-scoped 投影不复制任务正文；实际 HTTP 与卡片/页面分开展示归属和接受。
• Controlled Command Contract — implemented：原 revision/key、canonical claim/CAS、竞争和原回执重试已验证。
• Identity And Authority — implemented，限本地边界：原绑定/来源保留到效果点；当前新测试也证未 promoted 请求零 provider open、零 receipt，不能恢复退休写路径。
• Reconnect And Replay — not_met：下述真实原生 upgraded/replayed 输入仍误拒；不能把合法输入错判 scope failure。
• Failure Semantics — implemented，限已测领取/投递恢复：当前安装页面同 tuple 重试只有一次领取与一张卡，不冒充私有重连通过。
• Smallest Useful Slice — deferred：真实房间、独立 hosts、daemon、live OV 和 source-session 由既有 #5198/#3245/#4339/#3964 接续，不因源码/fixture关闭整个 RFC。

关键代码讲解

1. run_goal_channel_work 从当前连接取得 actor，传原 revision/key 和 source witnesses；原 native guard 在 CAS/receipt 完成前持锁。当前主干的 canonical-only admission 保留，legacy 仅指 Goal 身份兼容，不代表迁移策略或提供执行 lease。
2. handle_room_claim_callback 保留原 offer 的 binding 与 broker/source bytes，经过成员/原卡片读取再进入同一效果边界；撤销、改绑、换源和错误 principal 都不能从成员资格或消息推导领取权。
3. RoomWorkPanel 在效果前保存请求，in-flight ref 拦连击，未知响应保留原 tuple；实际 HTTP adapter 从连接派生 actor，保留 Host/Origin 与 scope checks。页面无私有 recall，状态和焦点恢复均实测。
4. validateRoomResumeInput 当前第29–30行仍只接受 committed/replayed，复制了不完整的原生回执集合；而resume fresh reader 未携带原 Todo/Turn 绑定，导致第二层错误拒绝。

整份提案51路径、+3417/-57。相对上次543头，32个 base/head blob 对完全不变，19个当前完整净 diff 已重读；包括 canonical admission 整合、budget 146→145 与浏览器伴随测试对现有 Overview 默认/焦点效果的适配。该缩紧预算不抬上限；测试仍保留原副作用、权限和精确读取断言。没有继承旧批准或旧整树测试资格。

对主干的风险

[P2] 原生合法的多待办选择回执仍无法进入私有重连。 在两个普通 Todo 的隔离 File/SQLite Goal 中，真实 quota should-run 先发现候选再绑定原 Todo/Turn，得到 delivery_allowed=true 的 upgraded 回执；work resume preview 返回 resume_scope_unavailable。重读同一绑定得到 replayed 后仍返回 quota_observation_changed；fresh reader 没有原 Todo/Turn 选择，比较中的 delivery_allowed 从 true 变成 false。当前源码与新安装 wheel 各两例均复现，零消息、零 provider execution。

这不是手填回执，也不是 live provider 故障。两个真实待办先 discovery，再用原 --todo-id 绑定相同 Turn；原生返回 should_run=true、delivery_allowed=true。把原包直接送 work resume --quota-decision-json 的 preview 即可复现。复用既有 typed quota/receipt owner 接受真实 upgraded 绑定，并在原 Todo、Turn 和当前能力范围内读取新鲜观测；保留撤销、错 actor、revision、scope 的拒绝。仅补一个状态字符串或放宽比较都不足，也不能新造 Turn 绕过。 最小回归是在现有 room_resume 集成测试用真实 producer 生成 upgraded→replayed，两种存储及安装入口都应 planned，同时保留既有 scope/revocation 负例。

本轮当前独立六文件 215 Python passed/0skip，五组聚焦 20 TS passed/0skip。隔离真实 PostgreSQL16.2 分数据库运行 store/service/team-plan/lease-inspection，共 398 passed/0skip，服务已关闭；control-plane typecheck、正常 Chat build/源码校验、新 wheel 构建和隔离安装通过。两个 source case 与两个 -I installed case 的上述 oracle 全失败，原记录保留。误展开的全量TS运行已取消，不计资格；20项是随后正确直接调用的独立结果。

当前新 wheel 的真实 HTTP/File/native backend 经 Ego 走现有设置连接入口：存储拒绝0POST，连击1POST，消息响应丢失后重载与核对使用完全相同 tuple，最终一次 revision 变化、一张卡，独立安装 CLI 读回 agent-a。当前归属另行 refresh；桌面/390px、中英、Tab/Shift+Tab与Escape返回原按钮已检查。连接发现/Lark传输为合成；背景私聊 fixture 的旧 schema alert 保留，不能称整个 Lark 设置验收通过，更不能称 installed App/真实飞书已采用。

完整 canary 5 direct通过、19 selected完成，有1项 catalog fixture 失败、1项 DSH advisory，0manual hold。相同两条原命令在不可变a448与747头均重现：前者合成仓库缺选中的 maintainability脚本，后者同一 _run_dsh_operation_host 大函数身份；因果owner不在本PR变化中。保留失败，不修改上限、断言或扫描范围；advisory先于完整semantic检查。作者披露的混合序列静态请求 reset 仍未资格化，本轮单条成功旅程不证明整catalog稳定或其根因。未查、触发或等待 GitHub CI。

语义与 CI 对齐

原生 upgraded 是合法选择结果；本地白名单误拒和无绑定 fresh reader 违反当前 Reconnect And Replay。共享 direct claim 的 foreign-bound 与显式未资格 GoalRef 拒绝已经披露，普通未提供字段的路径、普通 recall默认和默认关闭 collector 未自动扩大。v2扩展现有 request family以承载原source guard，不是新Agent生命周期。私有recall仍只读、跳过ingest，所有房间结果 execution_authority_granted=false；绿语义扫描不能替代当前真实producer/consumer反例。

我的整体评价

REQUEST_CHANGES。 当前本地组合的机制与问题规模相称，既有 owner 的复用及有界来源锁整理合理；long_horizon=not_yet_proven、user_experience=not_yet_proven，原因是合法同 Turn 私有继续仍稳定被拒，反复尝试不能恢复原工作。修复原生回执和绑定观测衔接属于同一交付阶段，不需要扩大为另一套控制面，也不应拆掉现有有用领取/恢复旅程。

旧IO授权阻塞已在当前回归通过，当前P2保持独立。代码量、测试数和主干整合均不替代完整用户结果；真实房间、多宿主、App、daemon、live provider、source-session及长期净益继续开放。本评审不授合并、部署、升级或dismiss权限。

English verdict: REQUEST_CHANGES — 747d4c9. The native multi-Todo upgraded→replayed producer/consumer failure still reproduces through source and newly installed CLIs on both File and SQLite. Installed room recovery preserves one exact request, one claim and one synthetic message;215 Python,20 focused TS and398 real PostgreSQL checks pass. Repair native receipt/bound-observation reuse; inherited canary failures and mixed-sequence/live qualification remain separate. CI was not consulted.

[loopx-agent]

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

REQUEST_CHANGES：两项 P2。合法原生回执仍不能私有重连；新增房间读模型未接入已接受的新鲜度封套。

动机

已经连接工作群的用户需要直接查看并领取可执行待办，并在连接重建后继续原来的私有工作。

原来需要离开连接页手工拼接领取命令；当前页面能一次领取并显示当前归属，但多个待办场景中的合法重连仍被误拒，用户无法继续原 Turn 的私有上下文。

当前源码与正常 wheel 安装版的 File/SQLite 原生重连仍误拒合法回执；安装页面的单次领取和丢回复后原请求恢复通过，新房间读模型还缺规定的新鲜度封套。

本次评审限定已接受的本地组合阶段，不把跨宿主服务、真实群聊长跑或记忆后端推广当成本 PR 的既有交付。

本地阶段还需修复原生回执与原绑定观测衔接，并在新房间读模型接入既有封套；真实群聊、多宿主和长期 provider 净益继续由既有 owner 接续。

改动思路

既有 Todo 保持唯一状态和回执权威，provider IO 与原生来源锁分工清楚，页面只保存原请求意图；当前本地组合边界合理，必须接通同 Turn 私有继续及新读模型封套。 本 PR 应交付现有连接下的本地领取、原请求通知恢复与私有重连；修复原生 quota 衔接及新房间封套属于本阶段，真实群聊、独立宿主与 live provider 仍由已有后续负责。

现有连接已经知道 Goal、actor 和房间，普通领取只需一次明确操作，恢复不重填已知信息。TS Todo/CAS 继续拥有准入与回执；Python 负责连接和 provider IO，原生来源 guard 持有原 broker/source 见证直到 commit。页面只保留原请求 tuple；历史接受、当前归属、消息送达和执行资格分别读回。比新任务板或新权限框架更小的现有 owner 组合是合理方向，关键是不能在 resume 另造不完整的原生状态集合，也不能遗漏已有投影封套。

实际触发	当前结果
浏览器会话存储拒绝	效果前拒绝，0 POST
连击、消息响应丢失、刷新后核对	同一 tuple/key、一次领取、一张合成卡；独立安装 CLI 读回当前 owner
同 Turn 原生多 Todo 选择	upgraded 被误拒，replayed 又与丢失绑定的新鲜观测不匹配
新房间 HTTP 投影	缺 projection_envelope，无法表达来源读取新鲜度和覆盖完整性

具体改动

exact head 9eddf0f4ee4e1219bb6013ce3a916b3278c0aa08；实际 merge base f6cf9583794eb8c4cca41fa832a1c2f150059583。spec_ref: docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md；spec_revision: f6cf9583794eb8c4cca41fa832a1c2f150059583。独立验收来自该基线已接受 RFC、#5198及已接受 TS RFC §2.6/§6，不使用候选新增 checkpoint 自证验收。

规范原条款	当前判断
Projection Contract	implemented：最小 actor-scoped 内容不复制私有任务正文；新鲜度封套另列当前必需项。
Controlled Command Contract	implemented：原 revision/key、canonical CAS、竞争与原回执恢复通过。
Identity And Authority	implemented，限本地组合；原绑定/来源保留到效果点，未 promoted 请求零 provider open/receipt。
Reconnect And Replay	not_met：真实 upgraded/replayed 进入 resume 仍失败。
Failure Semantics	implemented，限已测领取/投递恢复；不代表私有继续通过。
Smallest Useful Slice	deferred：真实房间、独立 hosts、daemon、live OV/source-session 仍由现有 #5198/#3245/#4339/#3964 接续。
§2.6	not_met：新增 TS 房间读模型必须在同 PR 发出既有 projection_envelope。
§6	not_met：正常包已核；封套 producer 尚缺，四态验收未成立。

关键代码讲解

1. run_goal_channel_work 复用 canonical Todo owner、原 revision/key 与 source guards。claim v2 承载原来源见证，普通 v0/v1 不静默丢弃该字段；并未授予 lease、quota spend 或执行权。
2. handle_room_claim_callback 在 provider 成员/原卡片读取后仍检查原 offer/绑定/源；回调 ACK、群成员或卡片不是工作权威。撤销、到期、改绑、换源均有拒绝测试。
3. RoomWorkPanel 在效果前保存原意图，用同步 in-flight ref 拦连击，未知结果保留原 key。当前正常安装资产经真实 HTTP/File/native authority 走完整恢复，桌面与390px布局、Escape焦点回返已检查；连接发现和 Lark transport 为合成。
4. validateRoomResumeInput 只接受 committed/replayed；CLI fresh reader 又未带原 Todo/Turn/能力绑定。两处组合导致下述真实反例，不能用新 Turn 绕过。
5. projectRoomWork 是新 operator-facing TS 读模型，实际返回和前端 schema 均无 envelope。既有 projection.envelope.seal 才是来源、陈旧和覆盖判定 owner。

完整当前提案48路径 +3375/-39。与上次747d的实际 base/head blob 对比中，9组发生整合变化，后端领取/重连因果路径未变，已重读当前净 diff 与共享消费者。上游已吸收的浏览器适配不再算成本 PR 新改动；budget146→145是缩紧而非抬上限。62个当前分支提交均有 DCO trailer。没有继承旧批准或旧整树测试资格。

对主干的风险

[P2] 真实原生多 Todo 同 Turn 回执不能进入私有重连。 两个普通 canonical Todo 的隔离 File/SQLite Goal，真实 quota should-run 先发现候选，再绑定原 Todo/Turn，得到 should_run=true、delivery_allowed=true、status=upgraded。直接传原包给 work resume preview，返回 resume_scope_unavailable；同一绑定重读为 replayed，仍返回 quota_observation_changed，因为 fresh reader 丢掉选择，delivery_allowed 变为 false。当前源码2例和全新正常 wheel 的 -I CLI2例均复现，零消息、零 provider execution。这是语义失败，不是手填回执、启动失败或 live provider 故障。复用原生 quota/receipt owner 的合法状态，在原 Todo、Turn 和当前能力范围内重读新鲜观测；不能只补字符串、放宽比较或新造 Turn。回归需真实 producer 的 upgraded→replayed 都能 planned，并保留撤销/错scope负例。

[P2] 新 TS 房间读模型未满足现行封套晋升门。 正常 wheel 的真实 room-work HTTP 返回 ok=true，projection 仅有 generated_at/source_revision，外层和实际 RoomWork schema 同样没有 projection_envelope。组装时钟和 provider revision 不能代替来源读取时间、覆盖遗漏与 replay served time。复用 projection.envelope.seal，携带真实来源读取与覆盖事实，并接通既有页面/CLI 消费者；增加 stale、unreadable、incomplete scope、replay 四种 producer 用例。此要求来自本 PR 之前已接受的 §2.6/§6，只约束当前新增读模型，不要求顺带迁移全部旧投影。

当前独立验证：215 Python、20 TS，均0skip；control-plane typecheck、完整 semantic smoke、Chat生产构建、正常 wheel/sdist与两个全新安装通过。19个产品文件及37个Chat资产在源码/归档/安装中逐字节相同。native source/installed反例四例仍失败，不能被绿单测覆盖。旧747d的真实 PostgreSQL16.2四组398passed/0skip，仅在核对131个 provider/transaction/decoder/test/dependency因果文件完全相同后复用，原server/关闭回执已重读；本轮没有重跑 PostgreSQL。

安装房间旅程证实存储拒绝0POST、连击1POST，丢回复后刷新使用相同 tuple，最终一次 revision变化、一张合成卡，独立安装 CLI 读回 agent-a；公开 room API不含私有正文，所有 execution_authority_granted=false。背景私聊 fixture 的旧 schema alert 仍在，不能宣称整个 Lark 设置或真实飞书/App已验收。浏览器私有验证曾误选CSS类及把私有fixture introspection混入API隐私断言，已观察真实状态后修正核验边界，未放宽产品断言或重做领取。

语义与 CI 对齐

advisory先于完整semantic检查；支持语法内未发现新carrier不等于语义成立。native premerge5direct通过、19selected执行：18通过，DSH大函数为advisory；整体仍因quality_receipt_missing失败。相同原 maintainability 命令在f6cf与9edd均为同一 _run_dsh_operation_host 身份和细节、0magnitude growth，因果文件未变，独立归为既存无关问题。没有生成质量回执、修改预算或豁免；未查询、触发或等待GitHub CI。作者仍披露的完整混合序列资格不由这条成功房间旅程替代。

共享foreign-bound claim及显式未资格GoalRef拒绝已披露为通用不变量修复；普通未提供字段、普通recall默认与默认关闭collector没有被安装或discovery自动激活。v2扩展同一请求族，不是新Agent生命周期；私有recall跳过ingest，记忆不授当前授权。封套和合法回执仍须由既有 typed owner 统一，不能靠prose白名单或绿色扫描代替。

我的整体评价

REQUEST_CHANGES。 本 PR 应交付现有连接下的本地领取、原请求通知恢复与私有重连；修复原生 quota 衔接及新房间封套属于本阶段，真实群聊、独立宿主与 live provider 仍由已有后续负责。 本地组合的成本与问题规模相称，既有owner复用和持原见证直到commit的整理合理；当前仍需修复两个有界缺口。long_horizon=not_yet_proven、user_experience=not_yet_proven是因为合法原Turn继续稳定被拒，不是要求无限长跑或全部父RFC完工。前瞻性检查落在复用原生回执/绑定及封套的现有owner seam，无须另建机制。新head需完整复核成功恢复、撤销负例、封套四态与正常安装。真实房间、多宿主、App、daemon、live provider、source-session及长期净益继续开放，本评审不授合并、升级或dismiss权限。

English verdict: REQUEST_CHANGES — 9eddf0f. Real native upgraded→replayed resume still fails through source and fresh installed CLIs on File/SQLite. The newly added room projection also lacks the envelope required by accepted RFC §2.6/§6. Installed same-request room recovery and215Python/20TS checks pass;398older real PostgreSQL checks are explicitly scoped reuse, not rerun. Complete both bounded owner integrations; full mixed-sequence/live qualification remains open. CI was not consulted.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; declaration_source=runtime_reported; reasoning_effort=max

APPROVE：完整复核当前 head，未发现未解决的阻断项。 Exact head: 5248@74501b79942510b69d9f341a8b91ee3ea29091ef；base: 0c5d70b71c3b86d02df918b1786a4701eaf126cd。

动机

已经连接工作群的用户，需要查看可领取工作，确认一次任务归属，并在丢回复、刷新或重连后恢复原请求。

原先消息、领取和私有上下文各自可用；人工拼接容易把历史接受、当前归属和消息送达混在一起，旧重连还会误拒合法的多待办原生回执。

当前正常打包页面可以一次领取、独立读回归属，并用相同请求恢复丢失的响应；合法 upgraded/replayed 回执能继续私有重连，异常来源不会伪装成零任务。

本 PR 完成本地组合阶段；不授予执行租约，不开放 source-session 精确实例领取，也不宣称真实群聊、多主机、daemon reconnect 或 OpenViking 长期效果已验收。

真实群聊、跨主机恢复和记忆后端联调仍由既有 #5198、#3245、#4339、#3964 与精确 GoalRef 迁移入口承担。

改动思路

保留同一 canonical 领取 owner，把来源锁、可读投影、用户授权和外部消息分别放在既有控制面、页面与 Lark 适配边界；取消其中任何一环都会留下本地阶段的真实断点。

当前 PR 边界是从现有连接完成一次有授权的领取与原请求恢复，并让私有重连消费同一 Turn 的当前准入；不扩展远端生命周期或授予执行权。

最短正常旅程沿用设置里的 Lark 连接：连接本身提供 Goal 与 Agent，用户查看当前工作后确认一次领取，不需要复制已知标识或额外确认权限。领取意图先可靠保存在本地；存储失败不发请求，重复点击只发一次，丢回复后重载使用原 Agent/Todo/revision/key。页面分别展示历史接受、当前归属与消息读回，重连不能把其中一个当成另外两个。

核心领取规则仍在 TypeScript canonical 事务中，File/SQLite 只是存储适配。来源凭据在外部读取之前取得，在真正提交期间持有原 registry guards；权限或路由变动会在写领取与回执之前拒绝。一次性的 IM offer 记录不可推导的同意范围和有效期，其他房间视图、当前 owner 和可领取数从已有权威派生，不另造任务账本。私有 recall 只在当前准入、连接与来源仍一致时携带有限引用，检索失败降低上下文，不扩散权限。

触发	当前决定与结果
一次合法领取	canonical CAS 接受，再独立投递与读回消息
回复不明后重试	相同意图恢复历史结果，再读当前 owner，不重复领取
连接、来源或身份变动	在效果点拒绝；重新读取当前授权后再操作
来源过期、缺失或不可读	隐藏误导计数与新领取操作，保留有明确意图的恢复路径

该表说明 74501b79942510b69d9f341a8b91ee3ea29091ef 的源码分支，不替代下面的运行证据；未核验 Mermaid 渲染，使用表格表达边界。

具体改动

47 个变更路径包含 20 个核心/适配源码或能力说明路径、页面与 HTTP 入口、正常打包浏览器覆盖、回归测试及使用说明；不是纯 UI 或只增加命令。审阅了全部生产差异及相邻调用者。新增 Python 文件属于 Lark IO/私有检索适配，领取决定、恢复准入与投影封套复用已有 TypeScript owner。

关键代码讲解

1. run_goal_channel_work 从现有连接派生作用域，在 provider IO 前捕获来源，交给 canonical claim；接受事实与发送失败分别返回，失败不回退 Markdown authority。
2. handle_room_claim_callback 校验 principal、offer、当前 Bot、卡片与原来源，领取提交仍受相同来源约束；消息恢复不是第二次领取授权。
3. projectRoomWork 使用实际来源时间与 projection envelope，来源不完整不能解释为没有任务；不是在消费端补一个永远 fresh 的标签。
4. validateRoomResumeInput 复用同一 Turn 的 committed receipt 认定与当前任务准入；历史回执不等于当前 quota、身份或执行权。
5. RoomWorkPanel 把意图持久化、同步防重与失效视图放在真实连接入口，恢复与新领取分别处理；窄屏、键盘和中英文均经当前正常打包页面验证。

规范基准为 docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md，spec_revision=0c5d70b71c3b86d02df918b1786a4701eaf126cd（固定版本），并对照已接受的 TypeScript migration RFC §2.6/§6 与 #5198。没有把本 PR 新增的 checkpoint 当成原规范：

• Projection Contract：implemented，真实 registry/connection/canonical Todo producer 加封套，消费者处理 stale/unknown/unreadable/incomplete。
• Controlled Command Contract：implemented，一次 revision-bound 意图、canonical CAS、相同 key 恢复及明确当前 owner；拒绝其他 Agent 的绑定任务。
• Identity And Authority：implemented，作用域、Bot/principal 与原来源在效果点核验；卡片、群成员或记忆不能授予执行权。
• Reconnect And Replay：implemented，消费当前 native committed/upgraded/replayed Turn，并复核能力、来源、绑定及 canonical revision；检索中变化即丢弃上下文。
• Failure Semantics：implemented，领取接受与消息失败分离，未知发送不被宣称无效果，provider 不可用不回退旧 authority。
• Smallest Useful Slice：本 PR 的本地组合 implemented；真实房间、多主机及记忆联调 deferred 到上述既有 owner，并非三方完整验收。

对主干的风险

最强反例是外部成员、卡片或身份查询期间发生 route/注册信息变更，而最后仍写入旧来源。当前原生 v2 事务把原 broker/source guard 持有到提交；File/SQLite 的真实并发、Python writer 竞争与回调中 retarget 用例验证拒绝且无领取效果。旧 v0/v1 不接受 v2 专有守卫字段；显式 GoalRef 不能悄悄走未限定实例的旧 claim wire。后一条与 bound-Agent 校验是全局 invariant 修复，文档明确影响直接 promoted claim，不能误称所有旧非法输入逐字节兼容。

当前独立执行：225 个 Python 用例、21 个 TypeScript 用例、类型检查、正常 chat build、风险选择的 premerge（6 direct＋19 selected）均通过。正常打包 room-work、automation-cadence、steward-model-settings 三个浏览器场景通过；实际检查了填充页面与 390px 视口。消费端异常封套由真实 HTTP 响应副本注入，producer 的来源时钟/不可读路径另由真实后端测试覆盖，截图不能证明 producer 生产排序或长期稳定。

正常 wheel 与 sdist 内容/安装文件核对一致；同一兼容参数探针在旧 9eddf0f4ee4e1219bb6013ce3a916b3278c0aa08 的 File/SQLite 都误拒 resume_scope_unavailable，当前源码两项通过；首次原样调用旧命令因旧版没有新增 capability 参数而被 parser 拒绝，保留该诊断，匹配比较时两端均省略该参数。两种安装包都通过隔离原生 CLI 的 File/SQLite 多待办 upgraded/replayed 恢复及能力撤销负例。共享 canonical authority 的隔离真实 PostgreSQL 16.2 验证 398 项通过，服务器已停止。Lark/OV transport 和模型边界是合成的，没有把它们当成真实外部联调。

语义与 CI 对齐

默认不自动发卡、不启动 collector、不新增 quota spend；原自动 recall 保留原默认行为，私有恢复显式禁止 ingestion。现有执行 lease、scope 和 quota 规则仍是机器约束，不是可忽略提示。投影 freshness 使用既有注册词汇；offer/grant 是局部受限操作，不伪装成远端 Agent 生命周期。advisory diff 扫描和完整语义检查通过，动态构造仍经人工路径核对。按当前评审契约仅使用仓库本地验证，未查询或等待 GitHub CI。

我的整体评价

这是 justified_increment：本地正常用户任务已形成可用闭环，剩余外部联调有既有 owner 与明确边界。long_horizon=improved：重复点击、丢回复、撤销与重连都有有界恢复，不制造第二份领取事实。user_experience=improved：沿用已知连接和一次授权，失效信息可见，历史/当前/消息三种事实不再混淆。

保留现有 owner 与持久回执兼容是合理的；已合入当前提案的有界整理包括共享 committed-heartbeat 认定、来源提交锁与原投影封套。继续扩展精确实例或远端工作前应复用各自既有 owner，不在本 PR 增加第二套状态机。没有当前阻断发现；最强未验收项仍是真实第三方重连与长期记忆价值，不能因本地测试通过而宣布完成。批准只针对此 exact head，不表示允许合并或扩大运行权限。

English verdict: APPROVE at 74501b79942510b69d9f341a8b91ee3ea29091ef. The local room-work journey and private native receipt recovery are verified through real canonical backends and normal distributions. Live Lark/OV, cross-host continuation and exact-instance claim support remain explicitly outside this bounded delivery.

[loopx-agent]

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

动机

在已有飞书 Goal 连接中查看可领取工作、确认归属，并在响应不确定或重新连接后继续处理原请求的注册 Agent 与维护者。 此前需要拼接多个命令和回执；较早实现还会拒绝同一 Turn 的合法升级回执，并把缺乏新鲜度信息的房间读数当作可行动状态。现在界面沿用已有连接和身份，一次明确领取后可用原请求恢复，过时或不完整的读数不能启用新领取。 已验证领取、消息结果不确定、页面重载、同键恢复和独立 CLI 归属回读；同一 Turn 的 upgraded/replayed 回执在当前能力约束下可以只读恢复，来源或权限变化仍拒绝。 本次仅交付 Goal-id 范围的本地组合，不启用 collector、执行权限、付费模型或真实飞书写入，也不声称 source-session、独立主机和 live OpenViking 已合格。 真实房间与原生回调、独立认证主机、daemon 重连、live OpenViking 及生命周期绑定的共享权威仍由 #5198 和现有相应 owner 继续验收。

改动思路

房间入口保留现有连接、Todo 事务、回执和配额 owner；TypeScript 只扩展必要的来源见证与读模型，Python 适配远端 IO，浏览器只保存结果不确定时的原始请求意图。 本次把本地预览、领取、回调、私有只读恢复与界面回读交付成可用闭环；不复制配置或执行 owner，也不将真实房间、独立主机和 source-session 的后续验收变成本地组合的无关前置条件。 用户想做的是领取已有工作并在断线后继续，已知 Goal、连接、Agent 和 revision 应由现有状态准备；界面无需用户补填。普通路径只有一次明确领取操作，重载后的核对不增加确认或重建请求。可选 CLI 仍供已有授权的 Agent 使用。

观察	权威与后续效果
历史领取已接受	只证明原事务接受，当前 owner 要重新读取
消息结果不确定	保留原 tuple/key；恢复不再领取一次
旧、未知或不完整读数	显示告警，隐藏当前计数/归属并禁止新领取
私有恢复上下文	重新核对当前身份、来源、能力和原 Turn；不授予执行或目标访问

具体改动

依据 docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md 的接受版本 0c5d70b71c3b86d02df918b1786a4701eaf126cd，并对照同版本 projection-envelope contract、TypeScript migration §2.6 以及 #5198 的本地阶段范围。Controlled Command Contract、Projection Contract、Reconnect And Replay 已在本地组合中实现；Validation 中真实房间、独立主机及 live memory 的部分明确 deferred，由已有任务继续，不用本次新增 checkpoint 自证验收。

关键代码讲解

• run_goal_channel_work 复用 canonical claim、原连接和消息读回；只输出安全投影，历史接受、当前归属与发送结果分开。
• withRegistryAuthoritySources 在 native commit 内保留原 broker/source 见证，按既有非等待规则获取锁；远端读取后切换来源不能落入旧权威提交。
• committedHeartbeatReceiptForTodo 识别实际生产的 committed/upgraded/replayed，检查同一 event 和精确 Goal/Agent/Todo/Turn/effect；当前 quota reader 恢复原绑定并重新检查宿主能力。
• projectRoomWork 使用既有 kernel envelope 汇合实际 registry、connection、canonical 读取事实；读取延迟不能被组装时间洗成新鲜。
• RoomWorkPanel 复用连接身份，先持久化不确定请求再发效果；存储失败不提交，同键重载恢复，并保持键盘返回。

对主干的风险

未发现当前阻断。完整复审 47 个路径，重新评估整包比例与维护成本；它交付实际预览、领取、回调、只读重连和界面恢复，拆成空 schema 或仅 CLI 会再次遗漏用户闭环。已有连接/事务/配置/回执 owner 均被复用，没有新增 room-owned Todo 或权限 owner。bound_agent 拒绝和显式未合格 GoalRef 拒绝是共享 direct-claim 行为修复，已在 guide 明确披露；其余可选操作没有自动启用 collector、Recall 或外部发送。

225 项 Python、21 项 TS 聚焦测试通过，覆盖 File/SQLite 并发领取、原回执恢复、绑定与 source 在 provider 读取/原生交接期间变化、错误 actor/principal、过期撤销、权限和 provider 失败。真实 native CLI 的 discovery→upgraded→replayed→resume 在源码、正常 wheel 和正常 sdist 新安装中通过；当前能力撤销后均在 recall 前拒绝。原两类 quota/freshness 阻断据这些当前路径核验，未依据旧 commit 或 outdated 标记撤销。

独立 base/head public CLI 比较证明 unbound/self-bound 的合法结果和禁用 Recall 行为相同，foreign-bound 在 base 的错误接受于当前变为无写入拒绝。真实 PostgreSQL 16.2 在两个独立数据库上通过 365 项 store 和 2 项 service 测试并关闭自建服务；最初同库固定 incarnation 冲突保留在证据中，未改断言或产品规则。

安装包界面经 Ego 实际走完四类读数告警、存储失败、双击隔离、消息响应不确定、重载和同 tuple/key 恢复；只有一次 canonical transition 和一张消息，独立 CLI 回读 owner=agent-a。中文桌面、390px 窄屏、英文与键盘焦点均检查。连接发现及 Lark transport 为合成，HTTP、File 权威、产品资源和独立 CLI 来自正常安装包。周边私聊 fixture 的缺失字段告警保留在截图中，未将该未改动面计为本次已验证产品结果。PR 描述已有直接视觉证据；未发布本地原始日志或路径。

语义与 CI 对齐

新 room 协议限定为操作与投影，复用现有 native 状态和 envelope 词汇；source guard v2 不允许旧 wire 静默忽略义务。普通 Recall 的 reconcile 默认 true 保留，只有显式只读恢复跳过 ingest。源码 bundle、正常 wheel/sdist 构建和标准 premerge 通过：6 项直接检查、19 项选择检查，含公开边界；该 RFC 是已有英文单文件，bilingual checker 通过。未查询或等待远端 CI。

我的整体评价

APPROVE，精确头 74501b79942510b69d9f341a8b91ee3ea29091ef，交付判定为 justified_increment。长程继续工作改善由原请求、历史回执、重载后的当前状态及多次只读恢复证明；不以消息量、测试数量或协议存在替代可用结果。用户无需重填已有身份或因结果不确定而再造请求，剩余导航属于可选入口，实际效果仍有一次明确授权。共享 receipt helper 与 envelope owner 复用是已应用的同域简化；未来卡片布局合并可另按具体改动处理，当前不需要新框架。真实房间与原生回调、独立认证主机、daemon 重连、live OpenViking 及生命周期绑定的共享权威仍由 #5198 和现有相应 owner 继续验收。 本次没有合并、安装到正式 App、live provider 写入或 bypass 授权。

English verdict: APPROVE the exact head as the accepted local Goal-id composition stage. Canonical claims, original native receipt recovery and truthful freshness are verified through real local owners and normal installed distributions. The UI recovers the identical request after a lost result. Live rooms, independent hosts, daemon/GoalRef activation and live OpenViking remain unqualified; no merge authority is implied.

[loopx-agent]

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

APPROVE：完整复核当前 head，没有发现本地组合阶段的未解决代码阻断项。 Exact head: 5248@b3e7097f5fec7067d6eb5b28947028f88b7b3937；实际 merge base: b5a331d0b9cc8956a109ab45880a492c6bafba4a。旧 head 的结论没有直接沿用，当前质量凭据限制另列。

动机

已经连接工作群的用户，需要查看可领取工作，确认一次任务归属，并在丢回复、刷新或重连后恢复原请求。

原先消息、领取和私有上下文各自可用；人工拼接容易把历史接受、当前归属和消息送达混在一起，旧重连还会误拒合法的多待办原生回执。

当前正常打包页面可以一次领取、独立读回归属，并用相同请求恢复丢失的响应；合法 upgraded/replayed 回执能继续私有重连，异常来源不会伪装成零任务。

本 PR 完成本地组合阶段；不授予执行租约，不开放 source-session 精确实例领取，也不宣称真实群聊、多主机、daemon reconnect 或 OpenViking 长期效果已验收。

真实群聊、跨主机恢复和记忆后端联调仍由既有 #5198、#3245、#4339、#3964 与精确 GoalRef 迁移入口承担。

改动思路

保留同一 canonical 领取 owner，把来源锁、可读投影、用户授权和外部消息分别放在既有控制面、页面与 Lark 适配边界；取消其中任何一环都会留下本地阶段的真实断点。

当前 PR 边界是从现有连接完成一次有授权的领取与原请求恢复，并让私有重连消费同一 Turn 的当前准入；不扩展远端生命周期或授予执行权。

最短旅程沿用“设置 → Lark → 已有连接 → 房间工作”。Goal 与 Agent 已由连接提供，用户查看任务后只需确认一次领取；无需重填已知标识，也没有第二次授权轮次。意图先存储再请求；存储失败零 POST，同步重复点击一个 POST。丢回复后重载恢复相同作用域、Todo、revision 和 key，不把“再点一次”解释成新领取。

触发	决定与可读结果
当前来源与身份有效，明确领取	canonical CAS 接受，再独立投递凭据
接受后消息结果未知	保留历史接受；当前归属和送达另读回
刷新或重试	恢复原始意图，不能更换 key 制造第二次领取
来源过期、不可读或不完整	隐藏误导计数，禁止新领取；授权恢复另处理
权限、连接或路由在 IO 期间变化	在提交/私有上下文使用前拒绝或丢弃结果

这是绑定 b3e7097f5fec7067d6eb5b28947028f88b7b3937 的源码说明表，不是运行证据；未核验 Mermaid 渲染，使用表格。领取、执行、消息与记忆四种权限分别受既有 owner 约束，连接或卡片存在不能授予执行租约。

具体改动

以真实 merge-base 计算的完整提案为 50 个路径、3676 行增加与 36 行删除，含 20 个运行时路径、页面/HTTP、五张说明截图、正常打包场景和回归覆盖。GitHub 的旧文件清单包含集成历史，未用其前一页代替完整差异。对前次 74501b79942510b69d9f341a8b91ee3ea29091ef 做了失效检查：40 个提案路径字节相同；10 个变化路径逐个核对；另查 236 个相邻因果路径，读完其中 5 个 quota/checkpoint 变化，并重跑当前原生恢复、配额与 PostgreSQL 相关路径。

关键代码讲解

1. run_goal_channel_work 从现有连接取得作用域，在外部 IO 前捕获来源，最后仍调用 canonical 领取；接受与投递失败分别返回，失效来源不回退旧权威。
2. handle_room_claim_callback 把 principal、offer、当前 Bot 与原来源约束带到真正提交点。同意范围和有效期是不可推导的用户意图，群成员身份不能替代它们。
3. projectRoomWork 复用既有 projection envelope；producer 使用实际来源时钟，缺失、不完整或不可读不被解释成零任务，UI 相应禁止新领取。
4. validateRoomResumeInput 复用同一 Turn 的原生 committed/upgraded/replayed 回执，仍重新检查当前任务准入与能力。私有检索前后来源、revision 或 quota 变化会丢弃上下文，历史接受不等于现在能执行。
5. RoomWorkPanel 在既有连接入口完成持久意图、防重、原请求恢复和分离读回；刷新后的当前 owner、历史接受和投递凭据不会相互冒充。

读实现前采用的规范是 docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md，spec_revision=b5a331d0b9cc8956a109ab45880a492c6bafba4a（固定版本），同时核对既有 TypeScript migration RFC §2.6/§6 与 #5198：

• Projection Contract：implemented，实际来源与封套加消费者失效状态，未另造 owner/count 账本。
• Controlled Command Contract：implemented，一次有范围的意图、原生 CAS 与相同 key 重放。
• Identity And Authority：implemented，原来源 guards 持有到真正提交，身份变化无领取效果。
• Reconnect And Replay：implemented，合法原生 Turn 回执恢复加当前能力/来源/配额复核。
• Failure Semantics：implemented，接受、当前归属和外部投递独立；未知发送不谎称无效果。
• Smallest Useful Slice：本地组合可用；真实房间、多主机和记忆联调 deferred，仍由既有 #5198/#3245/#4339/#3964 及精确 GoalRef owner 承担。
• Validation：implemented 于本地阶段，真实后端与正常打包页面包含失败恢复；没有把合成 transport 说成真实 Lark/OV 验收。

对主干的风险

最强风险是外部身份、卡片或成员读取期间切换路由，旧来源却在最后写入领取。现有 v2 原生事务持续持有原 registry source guards，回调、并发 writer 与来源变动负例验证无 canonical 效果。旧 v0/v1 不能接受 v2 专有字段，显式不受支持 GoalRef 不偷偷进入未限定实例的旧 claim。bound-Agent 校验与后者影响直接 promoted claim，属于明确披露的全局不变量收紧；不能借“房间功能默认关闭”宣称这些非法输入仍兼容。普通省略字段的旧直接领取、自动 recall 默认 ingestion 与 collector-off 路径保留；只有显式私有恢复禁用 ingestion。

当前独立执行：225 个 Python、21 个 TypeScript 用例，正常 Chat build/source verify，以及 6 个直接检查和 19 个风险选择的 premerge 检查通过。真实隔离 PostgreSQL 16.2 的 authority-store/service/team-plan/task-lease 共 398 项通过、零跳过，临时服务器已停止。正常 wheel 的 20 个运行时文件与源文件字节一致；隔离安装环境用原生 CLI 在 File/SQLite 完成两项多待办 upgraded/replayed 恢复及能力撤销负例。前次旧 9eddf0f4ee4e1219bb6013ce3a916b3278c0aa08 两项误拒 resume_scope_unavailable、前次 74501b7 两项通过的匹配反例保留原版本；本轮追加当前 wheel 结果，没有将历史 sdist 测试重标为新 head。本轮未重新构建 sdist。

当前正常打包资源在 Ego Lite 完成房间旅程，room API 使用真实 HTTP/File 后端，外部卡片传输为合成边界。unknown/stale/unreadable/incomplete 四种封套均隐藏计数和新领取；存储失败零请求；重复点击一个请求；模拟丢回复后刷新，以同一 tuple/key 读回一次 canonical revision 转换和一张卡片。独立查 owner，确认无私有任务内容及执行权；检查 Escape 焦点返回、中文桌面/390px 和英文窄屏。实际检查了填充视口。私有代理初期静态挂载与重载路径故障保留为 harness 诊断，修正后沿用原领取意图，没有靠新 key 重做成功样本。

此前作者混合目录运行的 packaged 11 pass/1 fail/58 unrun（attached-host）、source 43/1/26（private-steward）及 main 7/1/61（navigation-sorting）仍按原范围保留；它们不是相同负载，不能据此宣称“无 PR 独有失败”或“全目录已健康”。本轮独立覆盖当前受影响房间闭环，没有重跑整个混合目录。托管 premerge 的总体结果仍为 false，唯一剩余项是 stale quality receipt；本地实际检查没有失败，质量流程需按当前范围重新资格确认。没有查询、等待或触发 GitHub CI。

我的整体评价

这是 justified_increment：当前已完成可用的本地组合，完整三方和远端生命周期仍有明确既有 owner。long_horizon=improved：重复点击、未知回复、重载和原生 Turn 恢复都有有界出口；user_experience=improved：现有连接提供上下文，一次授权可得到独立可信读回，失效与恢复不要求重新制造领取意图。前端、CLI、HTTP 和 Lark 适配器的范围已一并评审，真实外部联调与长期记忆收益仍未验收。

未来可维护性检查保留并验证了已采用的有界整理：共享 committed-heartbeat 判定、TypeScript 原来源提交 guards、既有 projection envelope；Python 负责 IO，未增加第二个领取决策 owner。继续实现远端或精确实例前沿用既有边界，不在本 PR 填入推测框架。没有当前代码阻断发现；过期质量凭据、既有外部联调边界和维护者合并授权均未被本次批准代替。

English verdict: APPROVE at b3e7097f5fec7067d6eb5b28947028f88b7b3937 for the verified local room-work and native private-resume stage. Current packaged recovery, installed CLI and real PostgreSQL coverage pass. Live providers, remote continuation and whole-catalog health remain unqualified; stale exact-scope quality qualification is a separate merge hold.

The merge-base changed after approval.

[loopx-agent]

Reviewer: model_agent · gpt-6.1-sol · OpenAI · runtime_reported · effort=max

REQUEST_CHANGES · b3e7097。一个阻塞项：[P2] offer 在 provider 读取期间过期后，仍能产生 canonical 领取及接受凭据。下面覆盖整个当前变更及验证边界。

动机

已有飞书连接中的 Agent 和协作人，需要看当前可领任务、领取一次，并在丢回复或重连后知道原操作是否已经完成。例如同一任务的领取回复丢失，操作者不能靠卡片文字判断是否成功，再建一个请求还可能重复交办；本变更把领取结果和当前归属分别读回，并沿用原请求恢复。已验证本地打包界面经真实任务存储完成领取、刷新和同键恢复；但回调在远端读取期间过期仍会领取，当前不能按完整范围批准。

不改动时，已有直接 CLI 能领取，但房间展示、消息确认和重连续接仍需操作者手工对账。新增设置页不是必须的人工作业：Agent 可复用已有 Goal、身份、连接和授权直接调用 CLI；在已有领取意图下，不需要增加一轮用户澄清。UI 是人工检查和显式领取的伴随入口，不能代替执行授权。独立认证的多主机、真实飞书回调、live OpenViking 及已安装 App 尚未由本轮验证；它们与这个有用的本地组合阶段分开。

不新建调度器、任务数据库、消息消费者或远端身份体系；领取不授予执行权，也不证明已安装 App 或完整父级集成已通过。

改动思路

保留现有分工是合理的：原生 Todo 事务决定归属和幂等，Python 适配飞书与文件 IO，TypeScript 负责准入和投影，界面只保存恢复请求。当前 PR 的边界是既有本地 File/SQLite authority 上可实际使用的房间领取与私有续接，不承担全套多主机部署。不需要新建可独立推进的任务看板、消费者或记忆权限。纯 CLI 是更小的合法替代方案，但不能提供房间内的独立送达确认和浏览器丢响应恢复；因此这个有界切片有实际增量。

正常路径为既有连接解析身份 → 当前来源与 Todo 读取 → 显式 revision 领取 → 原生事务凭据 → 当前归属和飞书消息分别读回。浏览器的 sessionStorage 只保留原 tuple/key，无法可靠保存时不发请求。私有 resume 另外复用已有 Turn Recall 和当前 quota，检索后再核身份、来源、状态；回忆不发到房间，也不授予执行权。异常应在各自 owner 收敛：来源漂移拒绝领取，未知消息结果沿原 key 核对，记忆不可用则减少上下文。过期检查目前没有贯穿这条领取路径，这是下面的阻塞点。

具体改动

以实时远端 main 860e42d4b63b45c4798ee7f08622a27c146a2610 的共同基线 b5a331d0b9cc8956a109ab45880a492c6bafba4a 对照 head，净新增范围为 50 paths，+3676/-36。原始 GitHub/native 包保留的 base 为 0c5d70b71c3b86d02df918b1786a4701eaf126cd，其 253-path 统计包含 203 个在共同基线已存在且 head 原样继承的路径。已用远端 ref、git ls-remote、merge-base 和逐路径 blob 核对，没有把这部分共有历史归给本 PR。gh pr diff 的传输失败保留，完整源码差异来自已验证不可变 Git 对象。

范围包括：五个 workspace UI/data/i18n/CSS 文件；房间工作、offer/callback、resume 及 HTTP/CLI 适配；原生 claim v2 来源守卫、GoalRef 拒绝与 bound-agent 规则；已有 recall 的只读选项和 receipt identity 复用；Python/TS/浏览器回归；RFC、参考文档与五张合成数据截图。两个既有浏览器场景分别统一解释器来源和等待真实焦点恢复，没有改产品断言来隐藏失败。

规范依据是变更前已接受的 docs/architecture/rfcs/agent-im-openviking-collaboration-v0.md，固定版本 b5a331d0b9cc8956a109ab45880a492c6bafba4a：原规范。以下是本评审的映射标签，原 RFC 没有这些编号：

• C1 implemented：单一 LoopX authority、并发只接受一次、同键恢复；真实 File/SQLite 的独立 CLI 和 receipt/readback 回归覆盖。
• C2 not_met：接受操作时仍满足当前身份与有界命令约束。新增 offer 的有效期在慢 provider 读取后失效，但仍领取；见下面反例。
• C3 implemented：私有 recall 不变成公开正文或权限；续接不发房间、不 ingest、不 spend，检索期间变化丢弃上下文。
• C4 implemented：直接 CLI 路径仍可用，意图清晰的收紧单独披露；base/head 的 File/SQLite 实际 CLI 对照见下文。
• C5 deferred：独立认证主机、daemon/live provider 及完整三平面验收仍是后续集成资格；本地切片不宣称关闭这些父级要求。新增的 checkpoint 说明也按此边界审查，不能用它重写变更前规范。

关键代码讲解

1. claimLocalCoordinationTodo：v2 把原 broker/source witness 交给现有跨运行时文件 guard；最终 canonical 写仍由原 Todo owner 执行。来源争用和漂移不退回无见证路径，旧 wire 不能偷偷携带新字段。
2. handle_room_claim_callback：核对已持久化 offer、principal、Bot/profile、消息及完整卡片，然后调用相同 claim owner。当前唯一 expiry admission 在远端成员和卡片读取之前；后续领取没有重新核对这个 deadline。
3. RoomWorkPanel：先持久化原请求再写，双击只发一次；reload 后重用原 key。旧、不完整或未经验证的 envelope 隐藏当前归属并禁新领取。已实际检查 1512px 和 390px 整屏及双语、焦点、Escape 恢复。
4. run_room_resume：从原持久化 Todo/Turn receipt 取续接身份，用当前能力和 quota 观察，检索后重新检查 scope、revision 和 gate；显式跳过 ingest。结果只能是私有上下文，不能作为接受新工作或执行租约。

对主干的风险

[P2] 过期的 offer 仍可领取，位置为 room_claim.py:265。先在 expiry 前进入回调，随后正常成员/卡片查询延迟到 deadline 之后。241–244 行的允许结果被保留，265 行进入 canonical claim 时不再检查 offer 的有效期；同一路径里的再次 provider preflight 也会延长这段间隔。

我用已有 offered 合成飞书 fixture 和真实墙钟重现，没有改断言或伪造存储结果：offer 有效三秒，read_callback_card_content 完成时等到 deadline 后 150ms，再继续原处理器。File 与 SQLite 均返回 claim_status=applied、canonical_claim_accepted=true，provider revision 从 1 到 2，独立存储读回 owner=agent-a，operation receipt 从 missing 变 found，原消息也被更新。可用 offer 的两个对照均正常接受；只在测试侧加入提交前有效期复核的两个反事实对照均拒绝，完整 snapshot 不变且 receipt 仍 missing。六例为 4 passed / 2 failed。先前模拟 admission 时钟的失败也保留，但结论以这个真实墙钟反例为准。

在所有可能阻塞的 provider 读取之后，让原 offer 的当前有效性参与最终领取准入，明确与 canonical 接受点的时序边界；不要沿用早先允许结果。增加真实过期跨越用例，并保留未过期成功、同键重放、来源撤销及零副作用拒绝。可直接扩展 tests/control_plane/test_room_claim_callback.py 的已有 offered fixture，在卡片读取后跨越一个短 expiry，并断言完整 state、revision、receipt 和消息不变；同时覆盖后续 preflight 延迟。这里需要的是已声明期限的真实效果边界，不是新增审批、调度器或权限体系。

本轮实际通过：六个相关 Python 模块 225 passed；五个 TypeScript 文件 21 passed；control-plane 与 dashboard typecheck；Chat bundle 构建；打包 room-work 浏览器旅程。浏览器覆盖陈旧/缺失/不完整读数、存储拒绝、双击、未知送达、reload/同键恢复和独立 CLI 当前归属。provider/连接发现为合成边界，不能外推已安装 App 或 live Lark。

另用相同输入、解释器和真实 CLI 在不可变 base/head 上比较两种存储共 16 次：普通 unbound 领取成功；done 和未知 actor 的完整拒绝正文与无写入保持；绑定给另一个 Agent 的任务由 base 接受改为 head 明确 bound_agent_mismatch 且不写。这是有意的共享 claim 行为变化，并非“关闭房间功能后一切完全相同”。显式 goal_ref（含 null）在旧 wire 先于 provider/历史 receipt 被拒绝，也是已披露收紧。剩余全部投影排序/大样本反事实和完整禁用路径配对未在本轮逐项执行，保留为未核验，不以绿色子集补全。

语义与 CI 对齐

新 claim_request、room projection、resume 和 guarded claim wire 延伸现有有界操作词汇；offer 意图不是第二套 Todo authority，历史 receipt 也不续约。核心 Todo 归属与来源状态仍由 TypeScript 原 owner 决定；Python 的当前有效期观察须在最终准入重新应用。C2 失败是命令有效期约束未落实，而非通过文档改名可解决。本轮 policy 为 wait_for_ci=false，未查询、轮询或等待 CI；没有以远端 CI 状态作为评审阻塞。

我的整体评价

这是一项有用的本地组合增量：长期工作可通过原 key 和持久化 receipt 恢复，人工可在既有连接查看真实归属，导航是可选检查，不增加已授权 Agent 的必经确认轮次。就当前整项交付，长程正确性仍因过期授权被接受而未达成；本地用户恢复体验已有独立运行证据。维护成本集中在 IO 适配、限定 wire、最小 UI 和测试，沿用现有 authority/recall/envelope owner 是合理的；本次范围不需要扩成完整多主机系统。

结论为 REQUEST_CHANGES。修复并验证 expiry 跨越，按当时完整 exact head 重核其余兼容/投影证据后再评审；既往被撤回的批准没有沿用。未做合并、安装、重启或真实房间写入；独立主机、live OV 和真实模型收益不在本轮通过范围。

English verdict: REQUEST_CHANGES — head b3e7097. A claim offer can expire during provider reads and still commit canonical ownership and a receipt. Real-clock tests reproduce this on both File and SQLite (2 failures, 4 valid/repair controls passing). The 225 Python tests, 21 TypeScript tests, both typechecks, Chat build and packaged recovery journey pass; none covers that deadline crossing. Revalidate the bounded offer at the final claim admission after blocking IO. Direct-claim tightening is intentional and disclosed. This is a useful local composition stage; independent live hosts/providers and installed-App acceptance remain unqualified. CI was not consulted.

[loopx-agent]

[P2] Revalidate the offer after blocking provider reads

The sole expiry admission is at lines 241–244, before membership/card reads and the later Goal Channel preflight. An offer valid on entry can therefore expire before this call still commits ownership. Using the existing offered fixture, a real three-second deadline and a card-read delay until deadline +150ms reproduced applied/owner=agent-a/revision1→2/receipt found on both real File and SQLite stores. Valid controls pass; a test-side final recheck rejects without changing the full snapshot or creating a receipt. Carry current offer validity to the final claim admission after blocking IO, with an explicit acceptance boundary; add delayed-read and later-preflight expiry regressions while preserving valid/replay controls. 过期跨越不是消息送达失败，不能沿用先前的允许结果。

[loopx-agent]

Reviewer: model_agent · GPT-6 · OpenAI · self_reported

REQUEST_CHANGES · a8dac55 — 产品方向与交付范围调整

这条评审传达最新确认的产品方向：默认保留管家自动委派；允许补充“管家发布任务、Agent 自主认领”；本轮先不增加前端。这是对当前范围的明确修订，不是声称原规范禁止人工入口，也不是对既有全 PR 技术评审的替代。

动机

用户向管家提出工作后，应由管家和 Agent 在已有授权内完成分工、执行和结果返回。管家路线的价值是减少用户持续协调：用户不应因为多了一个领取入口，就又需要找任务、挑执行者、点击领取、核对回执和催交付。

当前文档确实已经说明 Agent 可以直接调用 CLI，Room work UI 是可选入口。我们并不把它误读为“所有 Agent 都必须等人点击”。问题在于，本 PR 把相当一部分交付和验证投入到了人工领取及浏览器恢复，而这个入口尚不能证明 Agent 会自主发现和承接工作。把它标成可选，也不足以说明为什么现在需要增加这套前端。

希望得到的增量是：管家已经说明任务和边界后，合适的 Agent 能自己把工作接起来，并把结果送回原请求。人工领取界面的收益可以以后单独验证。本轮不要求完成全部多主机、真实 Lark 或 OpenViking 集成，也不新增调度系统。

改动思路

保留两条共享同一任务权威的路径：

路径	预期链路	适用情况
默认自动委派	用户提出需求 → 管家选择合适 Agent → Agent 承接并执行 → 结果返回原对话	已知责任人、明确指定执行者，或适合直接分配的工作
可选自主认领	管家通过既有授权入口发布可认领任务 → 合格 Agent 在正常工作选择中发现并认领 → 执行 → 管家汇总并返回原对话	无需预先指定某个 Agent、存在多个合适执行者的工作

这里的“发布”是进入既有 canonical Todo authority 中有明确权限和目的的可领范围；不是必须发一张飞书卡片，也不是另建任务池数据库。图中的人只负责原始需求，以及实际缺少的重大选择或必要授权。普通认领不再追加一次人工确认；受保护操作仍走原有授权边界。

关键增强点应在现有 Agent 工作选择流程。Agent 应同时考虑已有承诺、优先级、Goal 相关性、能力、当前容量和预算，在合适时主动承接授权范围内的 unclaimed tasks。已有归属或明确指定给其他 Agent 的任务不能被抢走。也不应为了“主动”无限检查候选、挤占已有高优先级工作，或把所有无人认领事项转成用户审批。

本 PR 的建议边界：先收缩为支持 Agent 路径的最小后端/CLI 组合，复用现有领取、工作选择、唤醒和结果返回。暂缓新增 Room work 前端；若自主发现需要现有工作选择 owner 补齐，明确这项依赖及可观察的验收，不用人工页面冒充自动协作已完成。 不把全部远端路线压到这一项修改中。

具体改动

请据此调整当前提案：

1. 撤回或拆出本次新增的 Room work 页面入口、人工领取组件及其专用展示、文案、截图和浏览器场景。本轮先不新增前端。仅为这套 UI 服务的 API/状态也按实际调用需要收缩；不要机械删除仍保护已有 CLI 的共享约束。
2. 保留有实际 Agent 调用价值的 canonical claim、幂等回执、当前归属读回和私有续接能力。明确它们分别解决“谁接了”“失败后如何恢复”“怎样恢复私有上下文”，不把领取成功等同于执行启动或任务完成。
3. 说明并验证 Agent 从正常工作入口发现可领任务、判断能否承接、认领后进入既有执行及返回流程。现有选择流程若已有部分能力，优先复用并验证；尚缺的行为在原 owner 处补齐，不能只靠说明文字要求“更主动”。
4. 无人合适、预算不足或暂无执行机会时，保留可读的真实状态，交由管家现有协调机制处理。不要静默遗忘，也不要新增高频后台轮询或第二套调度账本。

关键代码讲解

• RoomWorkPanel 是当前新增人工领取与浏览器恢复的主要入口。这次要求延后的是这个产品表面及其专用配套，而不是用删除界面来放松权限检查。
• run_goal_channel_work 提供 project/claim 的 Agent CLI 组合，仍调用既有 canonical 领取 owner。应围绕真实 Agent 调用链解释和验证价值；候选 ID、一次成功命令或发送回执都不证明自主承接闭环。
• run_room_resume 恢复的是当前允许范围内的私有上下文。它不能提供新的执行权，也不应因本次调整被改成公开任务正文或房间记忆。

当前实现边界参见 room-work 文档。规范依据仍保留 Agent IM / LoopX / OpenViking RFC 的变更前版本，spec_revision=b5a331d0b9cc8956a109ab45880a492c6bafba4a。本次新增要求来自上述最新产品方向；不将它伪装成旧 RFC 已经写明的验收条目。

对主干的风险

[P1] 当前交付重心需要按最新方向收缩。 触发场景是用户已把任务交给管家，但新增领取页面仍被作为主要价值和验证对象，Agent 自主承接这一有用结果没有被建立。最低修改是暂缓新增前端，明确默认自动委派与可选自主认领的分工，并把支持认领主动性的最小行为接回现有 owner。

修订后的验证应直接覆盖：一个正常可领任务能被合格 Agent 在正常工作回合内发现、独占认领并沿原链路返回结果；多个 Agent 竞争仅一个成功；已绑定或已领取任务、错误身份、错 Goal/来源及越权范围均拒绝；过期、撤销、陈旧 revision 不产生新效果；丢回复和重连使用同一请求恢复且不重复执行；无关/关闭路径保留现有行为。公开回执不得泄露私有任务正文或 recalled context，claim 也不能替代 quota、gate 或必要 lease。

此前 offer 在 provider IO 期间过期仍能领取的独立技术发现 保留为历史证据。提交本评审前 head 更新至当前版本，已加入将原期限经 claim v3 的 admit_before 传入 canonical owner 的修复代码和回归用例。本轮读到了这项变化，但没有重跑其验证，因此不把旧 head 的复现直接说成当前仍存在的缺陷，也不宣称已独立验收修复。如果该路径继续保留，仍应按新 head 验证最终接受处的有效期；这与本条产品方向修改要求分开。

维护上先复用现有 Turn、候选读取和唤醒机制，避免为了认领增加常驻轮询、第二个 scheduler 或依赖人工同步的状态。响应延迟取决于实际唤醒和工作选择时机；请记录发布到认领、执行到返回的耗时及额外命令/模型成本。当前没有可比基线，不承诺即时响应或量化节省。

我的整体评价

当前 head 的领取与恢复基础可以为自主认领提供有用组件，但我们选择的主线仍是管家自动委派。新增人工入口目前不是必要交付，所以请求先调整范围，再围绕 Agent 主动承接的实际价值验证。人工交互可作为以后有明确需求时的伴随能力，不能反过来成为管家工作的常规前提。

本次核对了当前版本文档、未变化的 RoomWorkPanel/私有续接入口、CLI 的期限传递变化及最新远端 head，发布产品方向与范围的变更要求；没有重新执行全量差异审计、测试、浏览器旅程或 CI 归因，也不沿用历史批准。自动认领的长程收益及用户介入减少仍待真实链路验证；既有领取安全不变量和原技术发现继续保留。完成修订后，应以新的完整 exact head 重新评审相应实现与兼容性。

English verdict: REQUEST_CHANGES at a8dac55dffc8d2e428c5d0206587d839765bd872 for the updated product direction and scope. Keep steward-led automatic delegation as the default; add an optional steward-published, Agent-self-claimed route through existing task authority and work selection. Defer the new frontend. Demonstrate discovery, exclusive claim, governed execution and return to the original requester without unnecessary human steps. Preserve authority, privacy and recovery safeguards. This is scoped design feedback, not a fresh full technical qualification; the latest head adds a proposed offer-deadline fix whose correctness has not been requalified here, and that is separate from this design finding.

[huangruiteng]

重新review comment了一下，主要是期望这里和管家自动委派的体系结合着来改善~

[mergify]

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

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