feat(lark): automate private steward owner-task notifications

[loopx-agent]

New owner decisions currently reach private Chat only when an agent discovers and forwards them. Add an opt-in automatic notification setting to the existing private steward connection. The existing service reads all authorized native Goal Todos, discovers new or materially changed owner tasks, sends to the original owner Chat, and verifies the exact outbound message independently.

A fenced durable outbox retains source generations and frozen intents across restarts. Withdrawn tasks cancel unsent notices; only a proven pre-spawn failure can retry a create. Ambiguous sends remain unconfirmed, and returned message locators recover through readback without resending. First enable baselines existing tasks without a historical burst. Disabling pauses delivery and preserves receipts.

This uses the existing four-worker outbound pool and native audience grants. It creates no model Turn, hidden Goal, additional event consumer, execution permission, or Todo completion. Settings expose the persisted toggle and pending/unconfirmed/failure health.

Validation:

• Native-source/provider integration tests cover automatic background discovery, complete text, File and SQLite authority, settings HTTP/CAS, revocation, disablement, withdrawal, create ambiguity, restart recovery and wrong-App/chat/text readbacks.
• TypeScript planner tests and control-plane typecheck; full control-plane suite: 4,778 passed, 51 skipped. Existing private-conversation/status regression suite: 172 passed.
• Packaged frontend build and real backend browser journey at desktop and 390px: enable setting, add a native Todo, observe background delivery/readback, retain the setting after refresh. Provider IO is a synthetic boundary in this isolated journey; installed-service adoption remains a separate operational check.
• Mypy, focused lint, public-boundary scan and selected premerge checks passed.

[loopx-agent]

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

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

Reviewed exact head 5e369c3e0f2ea9d333674d6ea6f1f3860ef25c97. No blocking finding after the disabled-path correction.

动机

跨项目使用私人管家的本人，需要及时收到新增的用户待办。 过去，新预览需要本人确认时，要等待代理发现待办再手动转发；现在，已启用的原管家服务会自动发现并发送到原私聊。 已验证原生新待办能经后台工作池自动发送并独立读回，无需启动模型或手工发送。 本变更不替本人批准事项，不完成待办，也不启动接收 Agent 或扩大原授权。 共享安装与原服务的实际采用仍需在合并后单独核验，不能用合成提供方的成功替代。

改动思路

复用原有待办判定和外发工作池；只有发送意图与回执需要独立持久化，不能用新模型、第二消费者或伪造原请求替代。 本 PR 交付可运行的通知、设置与恢复链路；实际共享安装和原服务采用由同一维护任务在合并后完成。 现有 Goal Channel 通知有自己的配置目标，已有回复与委托返回又必须对应真实原请求；复用其调度与传输工具，比伪造一条入站消息或再建心跳代理更合适。开启选择是不可推导的本人意图；待办资格和正文来自原生数据，不能成为另一本人工维护的工作账本。首次开启建立基线，后续完整读取失败时保留旧记录，未发送的撤回事项停止发送。

当前路径	可观察结果
未开启	保留四个原回复槽位，不扫描通知待办、不产生外发
已开启且出现新用户待办	原工作池发现、冻结意图、发送、独立读回
创建结果不明	保留未确认状态，不用新请求盲目补发
已有消息定位符	重启后只读取原消息，核对后才确认送达

具体改动

规范依据是 docs/reference/project-coordination.md，固定版本 0ab7feb223f35b4a74175b5aee2909fd55aebd4a。original-return-route 由原私聊来源冻结和独立读回落实；independent-scope 由现有绑定、当前 Goal 范围与本人身份核验落实；delivery-not-execution 由通知路径不创建模型会话、不修改原生待办或接收者执行状态落实。该规范未被修改来迎合实现，通知选择与失败行为在现有说明文档中明确披露。

关键代码讲解

• planOwnerAttention 复用已有 attention owner 的资格判断，按 Goal、待办和实质正文建立稳定通知身份。单条资格投影不会引入整个队列的展示上限，实际正文仍从原生精确读取恢复；更改时间戳不能制造新通知。
• LarkOwnerAttention._snapshot 读取授权范围内的原生列表，并只对当前有效用户事项恢复完整正文，避免每轮反复精读已完成的历史任务。File 与 SQLite 路径仍使用相同的原生读取权威。
• LarkOwnerAttention.reconcile 在同一外发工作池执行；每个绑定有独占日志锁，发送前重新核对来源和范围。意图先落盘，定位符再落盘，最后核对确切消息、App、私聊与完整文本。冷回执保留历史证据，热状态只保留继续判定所需的数据。
• LarkOwnerAttention.configure 只接受现有绑定及设置版本，不接受另一个收件目标。现有设置页提供开关、待发和失败状态；开启需要完整基线，关闭不依赖 App 网络登录。

对主干的风险

最需要防止的是提供方已经发出消息，但进程丢失返回后再次创建。超时、创建后崩溃及重启测试都验证保留未确认记录；有定位符时只读回原消息。错误 App、本人、来源、收件会话或正文不能获得送达结论，撤销范围和伪造设置请求不能外发。最初的可选任务曾在关闭时占用一个回复槽位，已修正；同一个确定性扫描边界反例在旧实现失败、当前实现通过。

开启行为是有意的新能力，默认关闭的旧 HTTP 字段和无外发结果在固定基线与当前头上有相同指纹。新增字段是可选的设置可用性信息，不能激活通知或给模型增加指令。旧提供方、原私聊回复和原委托回传日志没有被替换。构建后的桌面和 390px 页面验证了可识别的开关及持久读回；提供方 IO 在这个隔离验收中是合成边界，不能据此宣称已完成生产采用。另用真实原私聊既有消息只读验证了实际 CLI 解码和全文匹配，没有新增外发。

语义与 CI 对齐

新增状态只属于本地通知日志，不是新的原生待办、Run 或执行权限词汇；现有资格判定继续复用。类型检查、19 项原生与提供方测试、共享 attention/planner 测试、私聊既有回归、mypy、定向 lint、公开边界扫描和选中 premerge 均通过。基线/当前头的真实 HTTP 与后台工作池对照也分别验证关闭与开启分支。按本 Goal 策略未查询或等待远端 CI；条件外部集成的跳过和实际生产采用不是这些本地检查的通过结论。

我的整体评价

这是一个有价值且范围相称的 justified_increment：long_horizon 改善了重启恢复、重复效果防护和默认关闭时的资源隔离，user_experience 则把每次手动转发收敛到既有授权下的自动送达。复用原有待办判定和外发工作池；只有发送意图与回执需要独立持久化，不能用新模型、第二消费者或伪造原请求替代。 本 PR 交付可运行的通知、设置与恢复链路；实际共享安装和原服务采用由同一维护任务在合并后完成。 不需要新代理、额外消费者或平行工作权威。残余边界是无定位符的未知创建需要独立核对，以及周期状态读取会合并短暂变化；这些都未被包装成成功。最终安装、原服务身份及首条真实新通知仍由原维护任务继续核验。

English verdict: APPROVE - 5e369c3; automatic native owner-task discovery/delivery is connected to the existing private steward service, with durable no-blind-resend recovery and default-off reply-capacity isolation. Native/provider, immutable HTTP, typed-owner, packaged UI and risk-selected local validation support this bounded code approval; production adoption remains separate.