[loopx-agent]

When an authorized Goal lacks native Todo authority, the notification settings currently show only a missing-source count. Expand View unavailable Goals to see the Goal and whether its maintainer must back up and migrate its Todo source, or retry an unavailable source.

The existing reader preserves the typed authority rejection; the existing planner and health response retain only the Goal identity and an allowlisted code. Legacy or stale optional diagnostics cannot invalidate a valid receipt journal. Notification discovery, source isolation and original delivery identities keep their current owners. The packaged browser fixture now reuses pytest's default-route and Effect-process isolation when invoked directly.

Validation covers File/SQLite source outages and recovery, healthy-source delivery, private error redaction, old-writer compatibility, the real HTTP/outbound-worker fixture and the packaged UI at desktop and 390px widths. Provider/model transport is synthetic; the fixture made zero model calls. Targeted Python and TypeScript tests, frontend build/type checks and repository premerge checks are recorded separately. This change diagnoses missing authority; migration remains the affected project's maintenance action.

[loopx-agent]

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

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

动机 / Motivation

启用新用户待办通知的个人管家用户，在一个已授权 Goal 无法读取时需要知道具体是哪项来源出了问题。此前设置页只显示缺失数量，维护者需要另查日志；现在展开同一设置即可看到 Goal 和待办迁移或暂不可读的原因。真实 HTTP 与原后台 worker 的合成账号验收显示：健康来源照常投递，缺失来源恢复后清除诊断，已投递通知不会重发。本 PR 不迁移其他项目、不授予新权限、不新增消费者，也不宣称完成通用周期报告或真实账号验收。

这是对既有错误可见性的有用增量。受影响项目的原维护者仍需依原权限完成原生待办迁移；完整报告与自然语言业务旅程继续由各自现有任务负责。不改动的方案会继续把具体来源故障压成数量；只补日志虽然代码更少，却仍要求用户离开设置页找原因。现有读取器已经拿到原生异常，因此不需要新的查询入口。

改动思路 / Approach

来源错误由现有 Python provider 读取，诊断校验和投影由现有 TypeScript owner 负责，页面只展示结果；不另建状态机、轮询器或业务规则副本。本次边界是将真实来源错误送到现有通知设置页，同时保留既有队列、回执和授权语义。新增 source_failures 是当前完整授权读取的派生诊断，不是待办、执行或通知生命周期的新 authority。每次发现都会更新或清除它，旧回执中缺失、损坏或过期的可选诊断不会阻止下一次读取。实时 provider 输入仍严格要求诊断与不可读来源一一对应。

原有流程仍是“原管家 worker → 授权范围内逐 Goal 原生读取 → 原通知 planner → 原队列及 provider 回执 → 设置页”。迁移错误显示维护者备份、迁移的要求；普通读取失败仅显示暂不可读并等待原 worker 自动重查。诊断本身不执行恢复动作。表述足以说明这条短链路，本次未另附流程图。

具体改动 / Changes

审查精确版本 2b7c59cdfd98b69c196b5263f3c643d327e6b549。书面依据是 既有通知来源故障契约；spec_ref: https://github.com/loopx-project/loopx/blob/0a9a3a3884490e7af2c2f27c2f2136ae738460db/docs/product/periodic-reports.md#owner-todo-notifications-during-a-source-outage；spec_revision: 0a9a3a3884490e7af2c2f27c2f2136ae738460db。这些要求在本 PR 修改文档前已成立，新增段落仅说明原因展示，不能用来反向证明原有约束。

验收项	本版本落点
ON-1 原 worker、无新模型回合或消费者	implemented：现有 service 调度入口与 disabled-slot 回归；浏览器 fixture 0 次模型调用
ON-2 完整授权范围及缺失来源隔离	implemented：原生 File/SQLite 读取失败仍保留来源，健康 Goal 继续发送
ON-3 原代次、意图和独立回执	implemented：原回执测试及二次恢复后 provider 写入数保持 3
ON-4 首次启用基线和后续发现	implemented：既有 first-enable/new-Goal 测试继续通过
ON-5 真实部分覆盖与错误可达	implemented：同一设置页展开具体来源；恢复后原因消失，原未知回执提示保留

关键代码讲解

1. LarkOwnerAttention._snapshot 继续逐项读取现有授权范围，将既有 CanonicalAuthorityRequired 类映射成已知错误代码，其余失败归为 source_unavailable。不复制异常正文，避免把私有路径和源内容传到页面。
2. sourceFailures / storedSourceFailures 对当前快照要求唯一 Goal、两种代码白名单及完整缺失集合匹配。持久化回执中的这个可选字段则可被忽略；原始回执状态、来源覆盖和队列校验仍严格执行。候选初稿会因旧 writer 留下的诊断数量不一致而阻断健康读取，最终版本已收回该过强前置条件。
3. ownerAttentionHealth / planOwnerAttention 在原健康响应和原发现周期中传递诊断，通知资格、代次和冻结意图不依赖它。没有另建恢复队列。
4. PrivateConversationPanel 在已启用通知的原设置中增加可展开列表，明确区分维护者迁移与暂不可读；关闭时不增加操作步骤。数据 schema 将新字段设为可选，以保留旧服务响应兼容性。

8 个文件共 +133/-5：生产代码 +49/-4，既有测试及 fixture +73/-1，文档 +11。直接运行的浏览器 fixture 现在复用 pytest 已有的默认路径及 Effect 进程隔离，避免读到本机个人配置；这不是新的生产运行器。

对主干的风险 / Risks

没有发现阻塞项。最强反例是“新增可选解释字段反而让历史回执不可读”，而不仅是当前输入坏了。最终 TypeScript 回归实际运行旧 writer、缺字段、损坏代码及数量冲突，再经下一轮快照验证队列身份与数量不变；初稿同一测试为 12 PASS / 1 FAIL，最终为 13 PASS / 0 FAIL。实时输入的 foreign、重复 Goal 和未知错误代码仍被拒绝，拒绝不会扩大授权范围。

PASS：Python 34 项，覆盖原生 File/SQLite、授权和受众拒绝、关闭通知仍保留四个投递位置、重启及冻结回执恢复。相同新回归在不可变基线执行为预期 10 FAIL，基线其余健康控制 24 PASS。PASS：控制面类型检查、前端构建，以及 6 项直接和 16 项选定 premerge 检查。构建只有既有大 bundle 提示，没有编译失败。未读取或等待 GitHub CI。

PASS：真实 HTTP、原 outbound worker 和原生 File fixture；provider/model transport 为合成边界。先产生迁移错误，恢复后 2/2 来源健康；再触发普通 OSError 并恢复，写入数保持 3、模型调用保持 0。桌面 1440×1000 与 390×844 视口均查看了展开区域，后者没有横向溢出。移动视口不等于实体手机验收。现场其他项目的迁移仍由其维护者负责，本 PR 不能把诊断清晰误称为来源已经恢复。

语义与 CI 对齐

新增字段是局部 provider 健康诊断，复用原生 authority 错误类型；没有新增 Core Todo、Run 或 canonical status。自动检查默认、原消息受众、未知发送只补读不重发、首次启用基线和失败停止条件均保留。迁移提示说明原项目 owner 的恢复责任，不授权当前 Agent 迁移。当前 Goal 采用本地验证，不以远端 CI 作为 review 证据。

我的整体评价 / Verdict

交付判断为 justified_increment：原因可从真实生产 API 到达现有页面，边界独立可用且可回退。long_horizon 为 preserved：重复发现、历史回执与故障恢复继续由原 owner 管理；user_experience 为 improved：用户无需查日志即可定位缺失来源，不增加强制澄清或确认回合。已检查桌面及 390px 窄屏的默认设置页、展开后的迁移与暂不可读原因，以及恢复后的同一区域；原因可就地找到，原因正文能够换行。真实 Lark 账号和实体手机未在本次浏览器 fixture 中验证；消息核对徽标使用合成 transport，其状态不是本 PR 的验收对象。

兼容性选择是保留既有持久化回执，并将新解释字段作为可忽略投影，避免版本交错把通知关闭。来源错误由现有 Python provider 读取，诊断校验和投影由现有 TypeScript owner 负责，页面只展示结果；不另建状态机、轮询器或业务规则副本。范围和维护成本与已复现问题相称；更小的仅日志改动不能提供同样的用户路径。受影响项目的原维护者仍需依原权限完成原生待办迁移；完整报告与自然语言业务旅程继续由各自现有任务负责。本次属于同账号作者自审，不是独立审查，也不是 GitHub 正式 approval；合并仍需另行通过当前精确 head readiness。

English verdict: APPROVE the exact-head diagnostic increment; migration and live-account acceptance remain outside this PR.