feat(dashboard): explain scoped attention decisions and supersession - #4247
Conversation
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
Signed-off-by: song <liusongstep@gmail.com>
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
评审结论：REQUEST_CHANGES，等待最终 head 的必需 CI 证据。当前没有尚未修复的代码阻断发现。 本轮自审发现并修复了“来源读取失败但旧事项仍显示可决定”的问题，不能把本地验证通过等同于远端资格检查完成。
审查范围：完整 main...head，base 6c0a43c340fe4b58e8ba477d25d7250508ddd4f0，head bdd42213b9b358dfcfbdfb6e84d1c102606b3d76。这是作者自审，未将其描述为独立批准。
动机
原先“需要你”的详情主要展示文本、优先级及通用解释。Todo 来源已经包含 decision_scope、blocks_agent、unblocks_todo_id、证据及 superseded_by，但工作区映射没有把这些事实交给详情，用户仍要自行寻找“这件事影响谁、为什么需要我、旧事项是否仍有效”。同时，抽屉保存的是当时选中的对象，后续状态变化不会更新该对象。
这个问题不能仅靠增加几行说明文字解决：来源字段需要穿过现有映射，已经打开的详情还必须按稳定身份重新核对。PR 的合理范围是完成这一条现有用户路径，不是新建决策权威或宣称统一所有渠道。没有明确交互类型、原因、范围或替代记录时，应显示未知，避免给普通文字附加授权含义。
改动思路
数据路径沿用 parseStatusPayload / todoItemSchema、当前 Todo 投影和 PersonalGoalHome。新的只读模型保留来源事实，再由 ContextDrawer 中的详情组件呈现。todoItemSchema 本身允许透传这些现有字段，无需新增后端协议或重写 #4243 的作用域覆盖判断。真实浏览器分别覆盖了普通 user_todos 和 project_asset.user_todos 两个入口。
选中记录使用来源、Goal、Todo 三个身份一起匹配。superseded_by 只能指向同一来源、同一 Goal 中明确存在的记录，相同文案或相同 Todo ID 不足以跨来源关联。状态缺失表示无法确认，不表示工作完成；源数据中的旧 lifecycle flags 也不会覆盖明确的当前 Todo 状态。
本轮进一步检查了“数组中仍有记录，读取却已经失败”的反例。主页面会保留上一次成功 payload，同时把来源连接标为错误；原 PR 只判断数组成员，因此仍会显示旧决定按钮。修复通过现有连接状态与对应 Goal 的读取错误，给该来源的旧记录标注不可用，保留历史内容但停止提供决定预览。没有新增另一套错误缓存或权限存储，其他健康来源与 Goal 不会因为一个失败记录被改写。
具体改动
关键代码讲解
attention-details.ts:17的attentionDetails从已有字段生成展示信息。只有明确的user_gate标记为需要决定，其他类型保持未知；不会扫描“授权”“审批”等词。替代关系优先，明确deferred优先于旧的 checked/done 标记，避免把已推迟事项显示成已完成。缺少完整 scope 时不拼出虚构范围。- 同文件
sourceAttention:41消费当前来源可读状态及 Goal 读取结果。来源读取中或失败时，仍保留原说明与证据，但生命周期呈现为不可用；同时带入当前 Goal 显示名，避免刷新选中记录时丢失界面上下文。 refreshAttention:48更新已经打开的记录；找不到完全相同身份时保持历史内容并标记不可用。attentionSuccessor:56只查找明确的同源、同 Goal 后继，拒绝自身循环和不可用记录的跳转。canReviewAttention:63仅管理现有预览入口的可见性。明确关闭、推迟、被替代或不可用的记录不再发起旧预览；普通待处理事项和旧来源仍沿用既有受控预览。ContextDrawer.previewDecision还检查只读来源，实际授权、执行与 receipt 继续归原有 Core action 流程所有。
工作区保留当前来源提供的历史记录用于选中详情核对，首页活跃事项仍使用原来的 !done 过滤和相对顺序，不把这个 PR 变成新的队列策略。Goal 时间线优先复用真实 Todo 身份，避免构造一个与来源记录无法匹配的临时 ID。中英 RFC 同步说明已交付部分及未交付范围；打包资源来自合入 #4243、#4244、#4250 后的完整源码，最终入口引用 index-DclJg8hK.js 和现有 index-DYYo3B8I.css。
对主干的风险
最高价值的反例是 HTTP 503 后的旧记录。增加该浏览器用例时，修复前等待“来源未确认”提示失败，证实旧数据仍被呈现为当前可处理；修复后同一场景出现明确提示，决定按钮消失，随后成功刷新仍能恢复当前记录并继续查看替代关系。回归测试也验证跨来源、跨 Goal 的相同 ID 不会关联，缺少字段不推断授权，读取详情不会触发 action 写入。独立只读来源还检查了所有 API 非 GET 请求计数为零。
本轮通过了类型检查、开发与打包构建、schema/model smoke、专用开发及打包浏览器测试、完整工作区开发及打包浏览器 smoke，以及标准 premerge 的 12 项检查和差异检查。完整工作区用例包含主干 #4250 的活动 Goal/Turn 重载恢复修复；此前旧 head 的失败不能作为新 head 的结果。
这些浏览器场景使用真实应用和状态解析路径、合成 HTTP 数据，证明展示与调用边界，不宣称验证了真实远端 provider 执行。PR 未修改 authority store、quota、调度或后端 gate 规则，因此没有据此要求无关数据库迁移测试。新 head 的 GitHub 必需检查尚未全部完成，这是当前明确的验收缺口。
我的整体评价
完整差异为 14 个文件、501 行增加、13 行删除，其中包含生成的打包 JS；核心读模型为 67 行，详情组件为 29 行。代码量主要对应一条已经存在的用户入口、稳定身份和可复用回归，未增加无人调用的通用编译器或可写状态。与只加说明文案相比，保留源字段并更新当前选中对象是必要的完整交付范围。
本轮修复了真实的来源失效边界，剩余限制也已明确：这只是 Stage 2 的 Dashboard 切片，没有跨渠道自动去重、已读回执、授权分类或新的决策权威。当前未发现未解决的代码阻断；但最终 head 的 CI 仍有排队或执行中的项目，所以评审保持 REQUEST_CHANGES，等待必需资格检查完成后再确认，不将等待证据包装成代码缺陷，也不提前给出 APPROVE。
English verdict: REQUEST_CHANGES for exact head bdd42213b9b358dfcfbdfb6e84d1c102606b3d76 pending required CI qualification. No unresolved code blocker remains. This author-owned review found and fixed stale decision controls after a failed source read. Current-source identity, cross-Goal/source successor isolation, deferred-state precedence, and read-only zero-write behavior are covered. TypeScript/build, focused schema/model checks, dedicated development and packaged browser tests, full workspace browser tests in both modes, and all 12 selected premerge checks passed. Final-head GitHub checks are still queued or running; local success does not establish remote qualification. This remains a bounded Dashboard Stage 2 slice without new gate authority or cross-channel deduplication.
Signed-off-by: song <liusongstep@gmail.com> (cherry picked from commit b908830) Signed-off-by: song <liusongstep@gmail.com>
songoow
left a comment
songoow
left a comment
There was a problem hiding this comment.
Request changes conclusion (author-owned PR; GitHub blocks formal self-review)
评审结论：REQUEST_CHANGES，等待最终 head 的必需 CI 证据。当前没有尚未修复的代码阻断发现。 本轮自审发现并修复了“来源读取失败但旧事项仍显示可决定”的问题，不能把本地验证通过等同于远端资格检查完成。
审查范围：完整 main...head，base 6c0a43c340fe4b58e8ba477d25d7250508ddd4f0，head f6bc64b6f3aa920c826e42f8d39d80185b888f94。这是作者自审，未将其描述为独立批准。
动机
原先“需要你”的详情主要展示文本、优先级及通用解释。Todo 来源已经包含 decision_scope、blocks_agent、unblocks_todo_id、证据及 superseded_by，但工作区映射没有把这些事实交给详情，用户仍要自行寻找“这件事影响谁、为什么需要我、旧事项是否仍有效”。同时，抽屉保存的是当时选中的对象，后续状态变化不会更新该对象。
这个问题不能仅靠增加几行说明文字解决：来源字段需要穿过现有映射，已经打开的详情还必须按稳定身份重新核对。PR 的合理范围是完成这一条现有用户路径，不是新建决策权威或宣称统一所有渠道。没有明确交互类型、原因、范围或替代记录时，应显示未知，避免给普通文字附加授权含义。
改动思路
数据路径沿用 parseStatusPayload / todoItemSchema、当前 Todo 投影和 PersonalGoalHome。新的只读模型保留来源事实，再由 ContextDrawer 中的详情组件呈现。todoItemSchema 本身允许透传这些现有字段，无需新增后端协议或重写 #4243 的作用域覆盖判断。真实浏览器分别覆盖了普通 user_todos 和 project_asset.user_todos 两个入口。
选中记录使用来源、Goal、Todo 三个身份一起匹配。superseded_by 只能指向同一来源、同一 Goal 中明确存在的记录，相同文案或相同 Todo ID 不足以跨来源关联。状态缺失表示无法确认，不表示工作完成；源数据中的旧 lifecycle flags 也不会覆盖明确的当前 Todo 状态。
本轮进一步检查了“数组中仍有记录，读取却已经失败”的反例。主页面会保留上一次成功 payload，同时把来源连接标为错误；原 PR 只判断数组成员，因此仍会显示旧决定按钮。修复通过现有连接状态与对应 Goal 的读取错误，给该来源的旧记录标注不可用，保留历史内容但停止提供决定预览。没有新增另一套错误缓存或权限存储，其他健康来源与 Goal 不会因为一个失败记录被改写。
具体改动
关键代码讲解
attention-details.ts:17的attentionDetails从已有字段生成展示信息。只有明确的user_gate标记为需要决定，其他类型保持未知；不会扫描“授权”“审批”等词。替代关系优先，明确deferred优先于旧的 checked/done 标记，避免把已推迟事项显示成已完成。缺少完整 scope 时不拼出虚构范围。- 同文件
sourceAttention:41消费当前来源可读状态及 Goal 读取结果。来源读取中或失败时，仍保留原说明与证据，但生命周期呈现为不可用；同时带入当前 Goal 显示名，避免刷新选中记录时丢失界面上下文。 refreshAttention:48更新已经打开的记录；找不到完全相同身份时保持历史内容并标记不可用。attentionSuccessor:56只查找明确的同源、同 Goal 后继，拒绝自身循环和不可用记录的跳转。canReviewAttention:63仅管理现有预览入口的可见性。明确关闭、推迟、被替代或不可用的记录不再发起旧预览；普通待处理事项和旧来源仍沿用既有受控预览。ContextDrawer.previewDecision还检查只读来源，实际授权、执行与 receipt 继续归原有 Core action 流程所有。
工作区保留当前来源提供的历史记录用于选中详情核对，首页活跃事项仍使用原来的 !done 过滤和相对顺序，不把这个 PR 变成新的队列策略。Goal 时间线优先复用真实 Todo 身份，避免构造一个与来源记录无法匹配的临时 ID。中英 RFC 同步说明已交付部分及未交付范围；打包资源来自合入 #4243、#4244、#4250 后的完整源码，最终入口引用 index-DclJg8hK.js 和现有 index-DYYo3B8I.css。
对主干的风险
最高价值的反例是 HTTP 503 后的旧记录。增加该浏览器用例时，修复前等待“来源未确认”提示失败，证实旧数据仍被呈现为当前可处理；修复后同一场景出现明确提示，决定按钮消失，随后成功刷新仍能恢复当前记录并继续查看替代关系。回归测试也验证跨来源、跨 Goal 的相同 ID 不会关联，缺少字段不推断授权，读取详情不会触发 action 写入。独立只读来源还检查了所有 API 非 GET 请求计数为零。
类型检查、开发与打包构建、schema/model smoke、专用开发及打包浏览器测试、完整工作区开发及打包浏览器 smoke，实际执行于 bdd42213b9b358dfcfbdfb6e84d1c102606b3d76 并通过。最终 head 相比该版本只有共享 browser smoke 一行定位修改：getByText("正在整理…", { exact: true }) 区分真实待完成消息与 aria-live 状态，修复 CI 中的重复匹配；未删断言，生产源码、配置、文档及打包内容均无变化。因此保留旧验证收据的实际 revision，并沿用生产语义证据，不把旧执行重新标成最终 head 运行。
最终 f6bc64b6f3aa920c826e42f8d39d80185b888f94 已重新运行标准 premerge，12 项选中检查及差异检查全部通过。完整工作区用例保留主干 #4250 的活动 Goal/Turn 重载恢复修复；最终三个 PR 在同一主干上的组合打包浏览器也已通过，包括本次定位修复。最终 head 的 CI 也尚未完成，不能用此前本地成功代替。
这些浏览器场景使用真实应用和状态解析路径、合成 HTTP 数据，证明展示与调用边界，不宣称验证了真实远端 provider 执行。PR 未修改 authority store、quota、调度或后端 gate 规则，因此没有据此要求无关数据库迁移测试。新 head 的 GitHub 必需检查尚未全部完成，这是当前明确的验收缺口。
我的整体评价
完整差异为 15 个文件、502 行增加、14 行删除，其中包含生成的打包 JS；核心读模型为 67 行，详情组件为 29 行。代码量主要对应一条已经存在的用户入口、稳定身份和可复用回归，未增加无人调用的通用编译器或可写状态。与只加说明文案相比，保留源字段并更新当前选中对象是必要的完整交付范围。
本轮修复了真实的来源失效边界，剩余限制也已明确：这只是 Stage 2 的 Dashboard 切片，没有跨渠道自动去重、已读回执、授权分类或新的决策权威。当前未发现未解决的代码阻断；但最终 head 的 CI 仍有排队或执行中的项目，所以评审保持 REQUEST_CHANGES，等待必需资格检查完成后再确认，不将等待证据包装成代码缺陷，也不提前给出 APPROVE。
English verdict: REQUEST_CHANGES for exact head f6bc64b6f3aa920c826e42f8d39d80185b888f94 pending required CI qualification. The combined packaged workspace browser also passed after the locator fix. No unresolved production-code blocker remains. Final-head standard premerge passed all 12 selected checks. Prior type/build, focused, dedicated browser and full workspace browser passes retain their actual revision bdd42213b9b358dfcfbdfb6e84d1c102606b3d76. The final diff changes only one existing test locator to exact: true, distinguishing pending message text from aria-live status; production source and bundle are unchanged, so earlier production-semantics evidence remains applicable. This does not establish final-head CI success.
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
结论：REQUEST_CHANGES。当前 exact head 的功能设计和隔离验证没有发现新的产品代码阻断，但它与当前 main 的 Personal Workspace 浏览器 smoke 存在真实内容冲突，因而尚不能合并，也没有当前主干组合后的最终验证收据。
动机
这个 PR 解决的是一个真实的信任问题：用户打开“需要你”事项时，旧界面只给出通用原因和证据，无法直接看到已有 Todo 投影里的目标 Agent、被解锁 Todo、决策范围与替代关系；更重要的是，抽屉保存的是打开时的对象，来源读取失败或事项消失后仍可能保留旧的决定入口。
预期变化很清楚：详情应由当前来源的显式字段解释；读取失败、身份消失、关闭、推迟或被替代的事项只能作为历史查看，不能继续发起决定预览；缺失不等于完成。只加几行文案不足以解决选中对象过期的问题，因此在现有状态解析和抽屉之间增加一个小型派生模型是合理范围。它不应成为新的 gate 权威，也不应从文案推断授权。
改动思路
数据路径复用了现有边界：todoItemSchema 保留 Todo 字段，buildPersonalHomeModel 同时生成活跃列表与历史列表，sourceAttention 绑定当前状态来源和 Goal 可用性，refreshAttention 通过 sourceId + goalId + todoId 重新核对选中对象。抽屉只消费派生详情；真正的 gate.resolve 仍走原有预览、确认和 Core 校验路径。
正向路径上，显式 user_gate 会展示为需要决定，同源同 Goal 的 superseded_by 才能导航到后继事项。负向路径上，来源 503、Goal 局部读取失败、记录缺失或已终态都会让详情变成不可用/不可操作；另一个来源或 Goal 的同名、同 ID 记录不能恢复它。现有普通或旧格式事项保留原有受控预览兼容性，但详情不会把其文案误分类为授权请求。
这一方案没有复制 Todo 状态机或权限规则；新字段都是当前公开状态的 UI 派生值。未来向的小步也已经足够：继续让 Core 拥有合法动作，把 Dashboard 限定在当前事实、来源新鲜度和可见入口，不需要再抽象一套通用 lifecycle 框架。
具体改动
关键代码讲解
attentionDetails把显式task_class、status、done、superseded_by、关系、证据和完整三元 decision scope 转成有界展示模型。只有task_class=user_gate标记为决定；缺字段保持 unknown，且 superseded/deferred/closed 的优先级有对应反例。sourceAttention与refreshAttention负责新鲜度：当前来源或 Goal 不可读时保留历史说明但把生命周期降为 unavailable；重新读取时只有完全相同的来源、Goal、Todo 身份可以替换抽屉对象，找不到时不伪装成完成。canReviewAttention同时用于隐藏按钮和previewDecision内部守卫，避免仅靠视觉隐藏。它不会执行写入，实际动作仍由现有onPreviewAction和 Core 权限边界处理。buildPersonalHomeModel新增attentionHistory，让已终态记录可以用于抽屉核对而不重新进入首页活跃队列；Personal Workspace 再按当前来源 URL 和逐 Goal 加载错误标记可用性。
完整差异为 15 个文件、增加 502 行、删除 14 行，其中包含生成 bundle、57 行语义 smoke 和 113 行真实浏览器回归。核心派生 helper 67 行、详情组件 29 行，代码量与一条完整入口相称，没有无人调用的新状态或写入机制。
对主干的风险
当前阻断是可复现的主干集成问题，而不是推测。对 origin/main 84334f794126735a83a6cfb77882dd58ca8066d9 与此 head 执行 merge-tree，结果在 examples/personal-workspace-browser-smoke.mjs 产生内容冲突：此 PR 在旧的 reload/reconnect 段把“正在整理…”定位改为 exact: true，当前主干则已经把同一大型 smoke 重组为 scenario runner。GitHub 同样报告 mergeStateStatus=DIRTY。
因此最低修复不是删除定位或忽略 smoke，而是 rebase 到当前主干，在新的 scenario 结构中保留仍适用的精确 pending-message 断言，重新生成打包资源，并在新 exact head 上跑专用 attention-details 开发/打包浏览器测试和完整 Personal Workspace 开发/打包测试。
我在当前 exact head 上实际运行了 Dashboard typecheck、双构建和 smoke:attention-details，均通过；代码阅读也覆盖了 503、记录消失、跨来源/跨 Goal 后继、只读零写入等反例。远端 21 项检查成功，但 checks/pytest/merge-gate 的红灯来自此 PR 未修改的 decision_scope.py mypy 问题；这可以解释旧 head 的失败，却不能替代 rebase 后的最终资格检查。
我的整体评价
产品价值、边界归属和负向语义都成立：它把“解释当前事项”和“执行决定”分开，缺失不会被解释为完成，来源失败也不会留下可操作的旧按钮。未发现需要扩大架构或新增权威的代码问题。
但一个无法与当前主干组合、且完整共享浏览器契约尚未在新基线上验证的 head 不能批准。请先完成 rebase、解决唯一冲突、重建 bundle 并恢复 required checks；届时可按新 exact head 快速复审，重点确认新的 scenario runner 仍覆盖精确 pending locator 与 attention details 的来源失效路径。
English verdict: REQUEST_CHANGES at exact head f6bc64b. The attention-detail design, typed source/Goal/Todo refresh, stale-action fencing, typecheck, build, and focused smoke are sound, but the head has a real conflict with the current Personal Workspace browser scenario runner; rebase, preserve the exact pending-message assertion, rebuild assets, and restore required checks on the new exact head.
Signed-off-by: song <liusongstep@gmail.com>
|
已按维护者要求完成主干集成，当前 head 重新执行 Dashboard 类型检查及双构建，打包 JS 与现有资源字节一致；详情专用开发/打包浏览器、完整工作区三个场景开发/打包浏览器、schema/model smoke、39 项决策范围兼容及边界测试均通过。最终 head 标准 premerge 的 12 项选中检查及 3 项直接检查全部通过。首次在未提交 merge 状态运行的广范围 canary 有一个上游 heartbeat 体积预算失败，保留该记录，不将其改记为通过。 已复核 Dashboard「需要你 → Goal Tasks → 事项详情」的真实入口、来源 503 后旧数据反馈、成功刷新替代跳转、记录消失禁用操作、只读零 API 写入，以及中英桌面/移动视图。CLI、Lark、设置和能力编辑器无需新增配套入口：此变更仅展示已有 Todo 字段，未新增配置或改变既有 action preview / Core 决策权限。此处浏览器使用真实应用与合成 HTTP 数据，不等于真实远端执行验收。 本轮没有新增产品行为或扩大 RFC 范围。小步未来向审查保留既有只读 helper，未引入新 lifecycle/权限权威。当前无未修复产品代码发现；等待新 head 必需 CI 完成后复审，不提前声明 CI 通过或批准。 四个更新后的 PR 已在 main |
huangruiteng
left a comment
huangruiteng
left a comment
There was a problem hiding this comment.
本次复审绑定 exact head 59d6ad874cf9a16234c98d74e0c06d41a241f03f。结论：APPROVE。上一轮指出的 current-main 浏览器 smoke 内容冲突已经通过集成 84334f794126735a83a6cfb77882dd58ca8066d9 解决；我重新审查了完整 base-to-head，而不是只看冲突提交。
动机
此前 Personal Workspace 的「需要你」详情只显示有限的通用信息，已经打开的抽屉又保存旧对象。来源失败、事项被替代或当前投影已无该记录时，旧内容仍可能看起来可以继续决定。单纯补几行文案无法解决新鲜度问题；正确的最小范围是复用现有 Todo/status 投影，并在展示边界对选中记录做精确身份读回。
改动思路
PR 沿用现有 todoItemSchema、DashboardPage、PersonalHomeModel 和 ContextDrawer。Core Todo/gate 生命周期继续是权威；新增代码只把现有公开安全事实派生为展示模型。互动类型只认精确的 task_class=user_gate，不会从“批准”“授权”等文案推断。选中记录必须按来源、Goal、Todo 三个维度匹配；找不到或对应来源/Goal 读取失败时标为 unavailable，而不是擅自判定完成。
正向路径中，当前 open gate 显示原因、证据、目标 Agent/Todo、完整 decision scope，并仍走既有 gate.resolve preview。负向路径中，closed/deferred/superseded/unavailable 都隐藏决定入口；superseded_by 只有在同一来源、同一 Goal 找到明确目标时才允许跳转。读取详情本身不产生写入。
具体改动
关键代码讲解
attentionDetails()负责纯派生：明确生命周期优先级，缺字段保留 unknown，partial scope 不拼装伪造范围。sourceAttention()与refreshAttention()把来源/Goal 可用性以及 exact identity 绑定到当前抽屉选择；来源失效或记录消失会保留历史说明，但停止提供动作。attentionSuccessor()拒绝自身循环、跨来源和跨 Goal 的同名/同 ID 记录；canReviewAttention()同时供按钮展示和previewDecision()内部守卫使用，避免只做视觉隐藏。buildPersonalHomeModel()把 terminal rows 单独保留为attentionHistory，但仍从 active Needs You 列表和计数中排除；PersonalWorkspacePage在每次模型变化时重新核对抽屉对象。
完整差异为 14 个文件、+501/-13，其中约 130 行是生成 bundle、170 行是 focused/browser 验证、26 行是双语 RFC。新生产模块都有 DashboardPage、PersonalWorkspacePage 或 ContextDrawer 的真实调用，不是 coverage-only 结构，也没有新增持久化状态或后端协议。
对主干的风险
最强反例是：用户打开 gate 后，当前来源变成 503，但内存中仍保留旧 payload。专用真实浏览器测试会把同一个来源从正常切到 503、再恢复和移除 exact item；当前 head 会显示“来源尚未确认”、隐藏动作，恢复后只接受完全匹配的记录。跨来源、跨 Goal successor、partial scope、deferred legacy marker、read-only zero-write 也都有独立反例。
我在 exact head 上运行了 focused smoke:attention-details、Dashboard TypeScript typecheck 与开发/Chat 双构建、专用 attention details 开发及打包浏览器测试，以及完整 Personal Workspace 的 navigation-sorting、chat-recovery、typed-actions 开发/打包场景，全部通过。相同的共享开发场景也在 immutable base 84334f794 通过。远端 required checks（含 dashboard acceptance、4 个 test shard、pytest、merge-gate）全部为绿色。
这些测试使用真实 Dashboard/parser/React 路径和合成 HTTP 数据，证明的是展示消费者与零写边界，不宣称替代外部 provider 的真实性验证。当前未发现新的代码阻断；上一轮唯一的主干组合缺口已经消除。
我的整体评价
这次实现把“解释当前事实”与“决定是否合法”清楚分开：展示层只消费 public-safe projection 和来源新鲜度，Core 仍拥有 preview、authority 与 receipt。范围与问题相称，旧/缺字段保持兼容，历史记录不会重新污染 active queue。未来向检查也不需要再扩一套 lifecycle 框架；继续保持这条派生边界即可。
因此批准当前 exact head。合并前仍应以该 head 的 merge-readiness 结果为准；本 APPROVE 不等于合并授权。
English verdict: APPROVE exact head 59d6ad874cf9a16234c98d74e0c06d41a241f03f. The prior current-main browser conflict is resolved. Exact source/Goal/Todo refresh, stale-source fencing, successor isolation, zero-write detail reads, shared baseline/head scenarios, development and packaged browser suites, builds, and all required remote checks passed. No unresolved blocker remains.
2 participants
Behavior
Selected attention details show existing Todo facts: reason, evidence, related Todo/Agent, decision scope and replacement lineage. Selection refreshes from its current source. Closed, deferred, superseded or missing items cannot offer decision actions; successor navigation requires the same source and Goal and an exact Todo identity.
Failed reads retain historical content with unavailable feedback and disabled stale controls, while healthy sources remain independent. Ordinary live items retain their existing governed preview. Reading details performs zero action writes and grants no authority.
Validation
Scope and integration
Head
59d6ad874cf9a16234c98d74e0c06d41a241f03fincludes main84334f794. The integration conflict is resolved using main's modular scenario runner; its exact pending-message assertion and recovery coverage are preserved.The changed entry point is Dashboard Needs You / Goal Tasks / selected detail. Existing Todo projections and action APIs remain the owners, with no new configuration, CLI or Lark behavior. This is partial Stage 2 of the intelligent review RFC; acknowledgment, authorization classification, cross-channel deduplication and #4172 material receipts remain outside scope. The future-facing pass retains the bounded detail helper/component without introducing new lifecycle authority.
Hosted CI and maintainer review must qualify this head. Browser tests use synthetic HTTP fixtures with the real application, not live remote execution.