Skip to content

Make long Chat answers readable as saved records - #5036

Merged
huangruiteng merged 3 commits into
mainfrom
codex/steward-answer-artifact
Sep 25, 2026
Merged

huangruiteng merged 3 commits into
mainfrom
codex/steward-answer-artifact

Conversation

@huangruiteng

@huangruiteng huangruiteng commented Sep 25, 2026 •

Copy link
Copy Markdown
Collaborator

Problem and result

Long answers in Steward and Goal Chat remain inside the conversation, making evidence and conclusions harder to read or revisit. Completed substantive answers now offer Read full answer separately. The reader loads the saved Session message by ID, presents the same safe Markdown in a focused layout, follows the workspace language preference, and leaves the original conversation open. The reader can also return to the Steward conversation. Opening, reloading, or returning never starts another Agent turn. Short answers stay inline.

This is a local Chat reading surface. It does not yet create a separately governed report artifact or change Lark delivery.

Validation

  • npm run build:chat — TypeScript and packaged chat bundle passed.
  • Packaged answer-presentation browser smoke — fresh and restored Steward answers, short Goal answer, safe Markdown, separate reader, return to Steward conversation, explicit locale, mobile layout, missing-link state, and no turn replay passed.
  • loopx canary premerge --from-git-diff --goal-id loopx-meta — 16/16 selected checks passed, with final-head quality receipt cqr_4b8a0e76d7630d9f23c3 valid.
  • Public-boundary scan — Public RFC and browser smoke scanned with zero errors; two unrelated existing Goal-state warnings were reported.

The link currently needs one asynchronous saved-Session read after a substantive answer to resolve its message ID. It does not delay completion handling, though very long Sessions may incur extra read cost. No adjacent behavior-preserving refactor beyond shared answer normalization and locale reuse was needed.

@huangruiteng
huangruiteng force-pushed the codex/steward-answer-artifact branch from 18ecef1 to 65c8502 Compare September 25, 2026 08:32

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

动机

管家和 Goal Chat 的长答复过去只能留在聊天流里,重读表格、证据与结论需要在消息间寻找。这个 PR 让已保存的长答复能单独阅读,并保持原对话可继续;它完成的是阅读与回看这一产品切片,尚未把答复升级为独立治理的报告工件,也没有改变 Lark 回传。

改动思路

继续以既有 Chat Session 的已保存消息为唯一正文来源:对话卡片只在完成且有来源 ID 的长答复上提供链接;独立页面按 Session 与消息 ID 读取,用现有安全 Markdown 渲染器显示,不再发起 Turn。URL 保留回到对话所需的视图状态,短答复仍直接显示。比另建报告存储或把整段正文复制进链接更符合现有权威边界。

具体改动

  • 对话合并结果携带客户端来源 Session ID;完成回合再从保存记录取消息 ID,读取失败仍保留原回答。160 字以下的短答复不额外显示阅读入口。
  • 新阅读页提供正文、复制 Markdown、原问题与消息来源;缺失和读取失败分别提示。路由校验两个不透明 ID,不从链接内接受正文,也不会重跑 Agent。
  • 自审修正了返回管家对话时误落到总览的问题:链接携带 conversation 视图,工作区据此打开管家对话。打包浏览器验收同时覆盖桌面、窄屏、重载、英文、恶意 HTML 文本、缺失记录和无回合重放。

关键代码讲解

AnswerReportPage 以现有 fetchChatSession 按消息 ID 定位已保存的 Agent 答复,使用现有 MarkdownText 安全呈现;ChannelTimeline 只给有持久化来源的完成长答复生成内部链接;PersonalGoalHome 在回合完成后补全该来源,保持聊天正文即时可读;PersonalWorkspacePage 读取一次性入口视图以返回管家对话。这些位置没有新增服务端写入或权限授予。

对主干的风险

最重要的反例是链接打开错误消息、执行模型 HTML、重载触发第二个 Turn,或返回时把用户丢到总览。打包浏览器验收覆盖上述路径,也验证缺失记录和 390px 表格横向滚动。npm run build:chat、最终提交质量凭据、16/16 风险检查通过,公开边界扫描无错误。长答复完成后需要额外一次保存 Session 读取;如果该读取失败,原消息仍完整可读,但链接可能要等刷新后出现。未验证 Lark 阅读入口或跨设备访问,本 PR 也未声称支持它们。

我的整体评价

从“在聊天流里翻找”变为“保存记录可独立阅读并返回对话”,用户体验与后续持续工作都有可见增量;正常聊天、短答复和作用域权限未变。新增页面与路由比新工件系统更轻,也复用了现有内容和渲染规则。我同意合入此精确提交;后续若要治理报告生命周期或做跨渠道回传,应另按其权威与采用标准验收。

English verdict: APPROVE - exact head 65c850232e1ee4eedf0174e6784671e125201a26; saved-answer reading and return preserve the original Chat record, packaged browser acceptance and 16/16 premerge checks passed.

Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
Signed-off-by: huangruiteng <14976749+huangruiteng@users.noreply.github.com>
@huangruiteng
huangruiteng force-pushed the codex/steward-answer-artifact branch from 65c8502 to cbe34b9 Compare September 25, 2026 08:42

@huangruiteng huangruiteng left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

动机

管家和 Goal Chat 的长答复过去只能留在聊天流里,重读表格、证据与结论需要在消息间寻找。这个 PR 让已保存的长答复能单独阅读,并保持原对话可继续;它完成的是阅读与回看这一产品切片,尚未把答复升级为独立治理的报告工件,也没有改变 Lark 回传。

改动思路

继续以既有 Chat Session 的已保存消息为唯一正文来源:对话卡片只在完成且有来源 ID 的长答复上提供链接;独立页面按 Session 与消息 ID 读取,用现有安全 Markdown 渲染器显示,不再发起 Turn。URL 保留回到对话所需的视图状态,短答复仍直接显示。比另建报告存储或把整段正文复制进链接更符合现有权威边界。

具体改动

  • 对话合并结果携带客户端来源 Session ID;完成回合再从保存记录取消息 ID,读取失败仍保留原回答。160 字以下的短答复不额外显示阅读入口。
  • 新阅读页提供正文、复制 Markdown、原问题与消息来源;缺失和读取失败分别提示。路由校验两个不透明 ID,不从链接内接受正文,也不会重跑 Agent。
  • 自审修正了返回管家对话时误落到总览的问题:链接携带 conversation 视图,工作区据此打开管家对话。打包浏览器验收同时覆盖桌面、窄屏、重载、英文、恶意 HTML 文本、缺失记录和无回合重放。

关键代码讲解

AnswerReportPage 以现有 fetchChatSession 按消息 ID 定位已保存的 Agent 答复,使用现有 MarkdownText 安全呈现;ChannelTimeline 只给有持久化来源的完成长答复生成内部链接;PersonalGoalHome 在回合完成后补全该来源,保持聊天正文即时可读;PersonalWorkspacePage 读取一次性入口视图以返回管家对话。这些位置没有新增服务端写入或权限授予。

对主干的风险

最重要的反例是链接打开错误消息、执行模型 HTML、重载触发第二个 Turn,或返回时把用户丢到总览。打包浏览器验收覆盖上述路径,也验证缺失记录和 390px 表格横向滚动。npm run build:chat、最终提交质量凭据、新基线 16/16 风险检查通过,公开边界扫描无错误。长答复完成后需要额外一次保存 Session 读取;如果该读取失败,原消息仍完整可读,但链接可能要等刷新后出现。未验证 Lark 阅读入口或跨设备访问,本 PR 也未声称支持它们。

我的整体评价

从“在聊天流里翻找”变为“保存记录可独立阅读并返回对话”,用户体验与后续持续工作都有可见增量;正常聊天、短答复和作用域权限未变。新增页面与路由比新工件系统更轻,也复用了现有内容和渲染规则。我同意合入此精确提交;后续若要治理报告生命周期或做跨渠道回传,应另按其权威与采用标准验收。

English verdict: APPROVE - exact head cbe34b942298853318ba482ac8d50ca037a7a8cd; saved-answer reading and return preserve the original Chat record, packaged browser acceptance and 16/16 premerge checks passed.

@huangruiteng
huangruiteng merged commit 7ada6f3 into main Sep 25, 2026
5 of 7 checks passed
@huangruiteng
huangruiteng deleted the codex/steward-answer-artifact branch September 25, 2026 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant