Return verified team reports to the manager conversation

[huangruiteng]

Problem and result

A manager-confirmed team assignment disappeared from the original conversation after closing its drawer or reloading. Even when a Goal Chat coordinator later adopted an accepted report, an unrelated ordinary Goal conversation could make that report appear unverifiable; more than eight ordinary sessions could hide it without any read failure.

The manager now keeps the applied assignment in the original conversation and links it to team work through the apply receipt's canonical Todo IDs. It discovers only sessions with a configured coordinator identity, checks every candidate inventory page, and displays a readable downstream report only when source acceptance, current adoption, consumer acceptance, and exact artifact versions match. An unreadable session or inventory page withholds the report. Refresh immediately withdraws stale content; the user can open the Goal conversation to inspect evidence and intervene.

Validation

• Final head 9b3a5ea6f: dashboard production build and packaged bundle smoke passed.
• Nine packaged personal-workspace browser scenarios passed. The focused team-plan scenario also passed after the final code edit: lost-response recovery without duplicate assignment, close/reload, wrong-Todo exclusion, current adoption, nine unrelated ordinary Goal sessions, an unreadable earlier inventory page, stale-result withdrawal, and desktop/mobile readback.
• Public boundary scans of changed source, fixtures, manifest, and generated script passed. Two unrelated registry projection warnings remain; no private runtime state is in the PR.
• Exact-head change-quality receipt cqr_12dfef5358aa54c75ba6 is valid for 14 changed files. Goal-scoped premerge passed three direct checks and five selected checks, with zero failures or manual holds. All commits carry DCO sign-off.

This changes the packaged dashboard's manager and Goal Chat journey. Lark and CLI retain their existing typed team-work APIs. The result readback covers Goal Chat delegation sessions; managed executions without that inventory still need a shared public-safe Goal result projection. Browser acceptance uses synthetic operations, so live mixed-model launch, independent review, adoption, scoped stop, and first-use qualification remain separate product acceptance work. Product code remains for maintainer review and merge.

[huangruiteng]

动机

manager 确认 team.plan 后，原分配结果应在关闭抽屉、重载之后留在原对话；后来被采用的下游报告也应能回到这张卡片。当前 head 完成了卡片留存和正常合成场景，但混合 Goal 会话下会丢失一个本已可核验的报告。

改动思路

应用回执里的 Todo ID 用于关联计划与团队操作；新 manager 组件读取 Goal Chat 会话、源操作、当前 adoption 和下游操作的产物版本后展示报告。真正的 Todo 写入仍只在 ChatActionService.apply。这里的问题不是版本校验本身，而是“扫描过的所有 Goal 会话都必须能读 team operations”被当作全局完整性条件。

具体改动

新增 manager 结果组件、时间线与重载恢复接线、刷新时撤下旧报告的状态、打包浏览器场景及前端资源。

关键代码讲解

• manager-team-result.tsx:10-16：readAdoptedResult 无差别列出这个 Goal 的全部聊天会话，并把总会话数超过 8 视为证据不完整。
• manager-team-result.tsx:21-73：对每个会话读 operations；任一个不相关会话读取失败也设置 incomplete，最后覆盖已经找到的有效 adopted 结果。
• manager-team-result.tsx:79-115：当前 head 在重新核验期间立即撤下旧报告，这部分逻辑与新增浏览器断言一致；原计划卡片由 manager 时间线重新挂载。

对主干的风险

P1 阻塞：不相关普通 Goal 会话会遮蔽有效团队报告。 真实 read_team 对未配置 coordinator identity 的会话返回 400；会话列表本身并不只包含团队会话。保持一份已验收源操作、当前采用关系和匹配的下游报告不变，只往同一 Goal 加一个普通聊天会话、让其 team operations 返回相同的 400：当前 head 的打包 team-plan 场景等待报告表格 30 秒后超时，界面进入“无法核验”。原始九个场景全通过，恰恰因为 fixture 对任意会话都能返回 team API。超过 8 个不相关会话同样会触发 incomplete。

最小修复是按回执 Todo ID 找权威的相关团队会话/公共安全 Goal 结果投影，并独立证明查询完整性；不要简单吞掉所有 400。请增加“有效采用结果 + 无团队配置的普通会话”和“有效结果 + 超过 8 个不相关会话”的打包负例，并重跑 npm run build --prefix apps/presentation/dashboard 与 npm run smoke:personal-workspace-packaged --prefix apps/presentation/dashboard。

我的整体评价

请求修改，当前 head d187367 暂不可合并。 正常路径、关闭/重载、刷新撤下旧报告与九个打包场景通过；但原任务要求把可核验结果可靠地返回 manager，混合会话反例推翻了这一点。无新增持久格式或权威；保留现有 typed API 即可，先修正结果发现/完整性边界再复审。真实多 Agent 验收仍在本 PR 宣称范围之外。

English verdict: REQUEST_CHANGES — an unrelated ordinary Goal session (or the eight-session cap) makes a valid adopted report disappear from the manager conversation; scope discovery and add mixed-session regressions before merge.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Exact head: d1873678f97df4eee4a133f13cdfdc79ddc38f3b

动机

manager 确认 team.plan 后，原分配结果应在关闭抽屉、重载之后留在原对话；后来被采用的下游报告也应能回到这张卡片。当前 head 完成了卡片留存和正常合成场景，但混合 Goal 会话下会丢失一个本已可核验的报告。

改动思路

应用回执里的 Todo ID 用于关联计划与团队操作；新 manager 组件读取 Goal Chat 会话、源操作、当前 adoption 和下游操作的产物版本后展示报告。真正的 Todo 写入仍只在 ChatActionService.apply。这里的问题不是版本校验本身，而是“扫描过的所有 Goal 会话都必须能读 team operations”被当作全局完整性条件。

具体改动

新增 manager 结果组件、时间线与重载恢复接线、刷新时撤下旧报告的状态、打包浏览器场景及前端资源。

关键代码讲解

• manager-team-result.tsx:10-16：readAdoptedResult 无差别列出这个 Goal 的全部聊天会话，并把总会话数超过 8 视为证据不完整。
• manager-team-result.tsx:21-73：对每个会话读 operations；任一个不相关会话读取失败也设置 incomplete，最后覆盖已经找到的有效 adopted 结果。
• manager-team-result.tsx:79-115：当前 head 在重新核验期间立即撤下旧报告，这部分逻辑与新增浏览器断言一致；原计划卡片由 manager 时间线重新挂载。

对主干的风险

P1 阻塞：不相关普通 Goal 会话会遮蔽有效团队报告。 真实 read_team 对未配置 coordinator identity 的会话返回 400；会话列表本身并不只包含团队会话。保持一份已验收源操作、当前采用关系和匹配的下游报告不变，只往同一 Goal 加一个普通聊天会话、让其 team operations 返回相同的 400：当前 head 的打包 team-plan 场景等待报告表格 30 秒后超时，界面进入“无法核验”。原始九个场景全通过，恰恰因为 fixture 对任意会话都能返回 team API。超过 8 个不相关会话同样会触发 incomplete。

最小修复是按回执 Todo ID 找权威的相关团队会话/公共安全 Goal 结果投影，并独立证明查询完整性；不要简单吞掉所有 400。请增加“有效采用结果 + 无团队配置的普通会话”和“有效结果 + 超过 8 个不相关会话”的打包负例，并重跑 npm run build --prefix apps/presentation/dashboard 与 npm run smoke:personal-workspace-packaged --prefix apps/presentation/dashboard。

我的整体评价

请求修改，当前 head d187367 暂不可合并。 正常路径、关闭/重载、刷新撤下旧报告与九个打包场景通过；但原任务要求把可核验结果可靠地返回 manager，混合会话反例推翻了这一点。无新增持久格式或权威；保留现有 typed API 即可，先修正结果发现/完整性边界再复审。真实多 Agent 验收仍在本 PR 宣称范围之外。

English verdict: REQUEST_CHANGES — an unrelated ordinary Goal session (or the eight-session cap) makes a valid adopted report disappear from the manager conversation; scope discovery and add mixed-session regressions before merge.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Exact head: f98ddf3b8128cdff150f4b7069ec02e8c3576c57

动机

manager 确认 team.plan 后，原分配卡片应在关闭抽屉或重载后留在原对话；被当前采用的下游验收报告也应返回同一处。当前 head 能完成正常合成场景，但在同一个 Goal 同时有普通聊天会话时，会撤下一个本来已经通过版本核验的报告，因而尚未达到可靠返回结果的目标。

改动思路

应用 receipt 的 Todo ID 串起 manager 计划和 Goal Chat 操作；新 manager reader 再核对源操作、当前 adoption、下游操作与 artifact 版本。真正创建 Todo 仍只走 ChatActionService.apply。卡片持久化、刷新时先撤旧报告和 Goal 证据导航方向正确；问题在于 reader 将“列出的所有 Goal 会话都可读 team operations”当成全局完整性条件，而现有 session list 并不只包含团队会话。

具体改动

新增 manager 结果组件、时间线挂载、已应用提案的关闭/重载恢复、receipt Todo ID 提取、样式与打包资源；浏览器场景覆盖正常采用、丢失 apply 响应后的幂等恢复、移动端和刷新撤下旧结果。当前 head 相对先前 review head d1873678 是重基：关键 manager-team-result.tsx 的 Git blob 完全相同，原发现没有被修掉。

关键代码讲解

• manager-team-result.tsx:10-21 对 Goal channel 的全部 session 最多取前 8 个；总数超过 8 或任意 session 的 team operations 读取失败都会使全局 incomplete 为真。
• manager-team-result.tsx:23-62 对匹配 receipt Todo 的已接受源操作、当前 adoption 与下游 artifact 做严谨版本匹配；这是该 UI 应保留的安全边界。
• manager-team-result.tsx:67-75 在循环结束后让不相关 session 的失败覆盖已找到的有效报告，转为 unavailable。
• personal-workspace-page.tsx:1103,1892 让 applied team.plan 卡片可恢复且关闭 drawer 后不被删除；ChannelTimeline 将只读结果放在原卡片下。

对主干的风险

P1 阻塞：不相关普通 Goal 会话会遮蔽有效采用结果。 后端 chat_loopx_mode.py:255-268 对未配置 coordinator identity 的会话明确拒绝 team readback。保持一个已验收源操作、当前 adoption、匹配的下游报告不变，只向同 Goal 增加一个普通会话并让其 team API 返回对应 400：当前 head 的打包浏览器页面在刷新后显示“团队结果或采用证据无法核验”，报告表格变为 0；临时场景只因原有断言要求唯一 503、现在另有注入的 400 才最终退出失败，报告消失的检查本身已通过。既有 9 个打包场景和构建全通过，因为 fixture 对任意 session 提供 team API。超过 8 个不相关 session 也会无条件触发 incomplete。

请按 receipt Todo ID 找权威的相关团队操作或完整的公共安全 Goal 结果投影，独立证明查询完整性；不要简单忽略所有 400，以免吞掉真正相关会话的错误。补入“有效结果 + 普通无团队配置会话”及“有效结果 + 超过 8 个不相关会话”两个打包回归，再跑 dashboard build 和 packaged browser smoke。当前 PR 每张卡片的 30 秒有界扫描也应在后续移到共享 Goal read model 或做可视区域订阅；这是具体的向前重构点，不要求为本阻塞另造一套状态。

我的整体评价

REQUEST_CHANGES，当前 exact head 暂不可合并。 正常路径、版本匹配、应用卡片持久化与刷新撤下旧报告都已验证，但混合会话反例推翻了最核心的返回结果承诺；既有 typed API 和写入权威可以保留，只需修正发现/完整性边界。真实多 Agent 验收仍在本 PR 声明范围之外。本轮按 Goal 配置未拉取或等待远端 CI。

English verdict: REQUEST_CHANGES - exact head f98ddf3b8128cdff150f4b7069ec02e8c3576c57; an unrelated ordinary Goal session or the eight-session cap hides a valid adopted report. Scope discovery to authoritative related operations and add mixed-session regressions before merge.

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Exact head: 9b3a5ea6f6a7165db9cef27457d79a7e77de2557.

动机

经理在管家会话中应用 team.plan 后，需要在原会话看到持久的计划卡和下游已采用、已验收的团队报告，而不必每次跳去 Goal 手工重建证据链。原先关闭/重新打开抽屉后卡片会消失，也没有经理侧的结果回流。

改动思路

PR 让已应用卡片随会话恢复，把 apply receipt 的 Todo IDs 交给只读 ManagerTeamResult；它从 Goal 会话、团队 operation、adoption、source/consumer artifact 的 ID 与哈希逐层核验，只在当前且已验收时渲染报告，读取失败则撤回旧结果。写 Todo 的权威仍在 ChatActionService.apply。新 head 还先用 fetchLoopXMode 区分普通会话与有 coordinator 身份的团队会话，修复了上一次 review 指出的普通会话 400 导致误判。

具体改动

channel-timeline.tsx 接入已应用计划的结果区域；personal-workspace-model.ts、personal-workspace-page.tsx、team-plan-preview.ts 传递并恢复 Todo 身份与 Goal 跳转；manager-team-result.tsx 实现只读发现、采用链核验、刷新及四种 readback 状态；CSS 与打包资产同步展示；fixture 和 team-plan packaged browser 场景覆盖持久卡、结果呈现、失效证据，以及新加的 9 个普通会话。未发现新增 CLI/Lark 入口或额外 Todo 写入。

对主干的风险

P1，仍会错误撤回有效报告。 manager-team-result.tsx:18-30,87 对整个 Goal 的所有会话逐一取 mode，随后只要 coordinator 会话超过 8 个就设置 incomplete，并仅扫描前 8 个；最后这个全局标记无条件覆盖已经核验的 adopted 结果。一个与此 team.plan 完全无关的 coordinator 会话数量变化，因此足以把同一份有效报告变成“无法核验”，相关会话靠后时还根本不会被扫描。当前的新回归只添加 9 个普通会话，所以未覆盖这个分支。

我在打包浏览器场景中保持原 source/adoption/consumer 和 receipt Todo IDs 不变，仅暂时把 9 个无关普通会话改为带其他 coordinator 身份、其他 operation 的会话；点击刷新后报告表格从可见变为 0，页面显示“团队结果或采用证据无法核验”。移除这些无关身份后，同一报告恢复。临时验证改动已撤销，工作树干净。建议把发现与完整性绑定到 receipt Todo IDs 对应的 operation，或由现有权威提供完整、按相关性索引的 Goal 结果 read model；至少加入“有效采用 + 超过 8 个无关 coordinator 会话仍可见”及“真正相关证据不可读则撤回”的回归。

另一个相关成本：每张已应用卡每 30 秒对 Goal 的所有会话发一次 mode GET，再扫描至多 8 个团队会话。这是按总会话数和卡片数增长的读取，不只是一次性核验；修复发现边界时也应界定/复用这批读取。未见权限扩大或新的持久状态，但当前全局 cap/轮询成本不宜直接进主干。

验证：dashboard build 与 9 个既有 packaged browser 场景通过；额外的上述 targeted packaged browser 反例复现了 P1。对照了上次 review 的 head 与当前 head、后端 list_sessions/read_team 路径；未按本 Goal 的 wait_for_ci=false 配置轮询远端 CI，也未验证真实多 Agent 执行。

我的整体评价

REQUEST_CHANGES。卡片持久化、类型化采用链核验和普通会话过滤是有价值且方向正确的改进；但目前相关结果仍被无关 coordinator 会话的全局数量左右，无法证明“已验收报告可靠回到经理会话”。请修复上述 P1 并补反例回归后重新按新 head 评审。相邻的有界重构应让相关 Todo/operation 的读取与完整性判定由同一权威负责，避免 UI 重复建立全局会话索引。

English verdict: REQUEST_CHANGES - exact head 9b3a5ea6f6a7165db9cef27457d79a7e77de2557; nine unrelated coordinator sessions hide an unchanged verified adopted report due to the global eight-session cap. Build and nine baseline packaged scenarios pass; targeted packaged counterexample reproduces the blocker.