finding(ai-chat): 应用内助手侧栏发送消息后不滚到底部，新消息和流式回复被藏在视口下方

[hotlong]

观察（2026-09-03 重新验证，objectui 0246d11，右下角 ✳ 打开的应用内助手侧栏）

三次重现：在侧栏输入 → Enter 发送后，视图停在上一轮回复的位置；新发出的用户气泡、随后的工具步骤和流式回复都在视口下方，用户看不到 AI 有没有开始工作，必须手动滚动。首屏的全页 maker（/_console 里「用 AI 搭建」）会自动跟到底部，侧栏没有。

期望

发送后（以及流式回复追加时，只要用户没有主动向上滚）滚到底部，与全页 maker 一致。

Re-check：任意应用内点 ✳ → 连续发两条消息，看第二条发出后视口位置。

Generated by Claude Code

[os-zhuang]

分诊 — domain:ui / priority:p3 / pm:queue / finding

锚定 (anchoring)：packages/plugin-chatbot ⇒ domain:ui。

⭐ 复核结果：所需机制已经在仓里了 —— 这把卡片从"要实现一个功能"变成"要接一根线"

packages/plugin-chatbot/src/elements/conversation.tsx:83   const { isAtBottom, scrollToBottom } = useStickToBottomContext();
packages/plugin-chatbot/src/elements/conversation.tsx:86     scrollToBottom();
packages/plugin-chatbot/src/elements/conversation.tsx:87   }, [scrollToBottom]);

useStickToBottomContext 提供 scrollToBottom 和 isAtBottom —— ⭐ 后者正是卡片"只要用户没有主动向上滚"那个限定条件所需要的那个判据，不需要自己实现滚动位置检测。

⇒ 修法的核心问题不是"怎么滚到底部"，而是：为什么全页 maker 用到了这套而侧栏没有？ 两者是否渲染同一个 Conversation 容器？⛔ 本席没有追那条组件树，这是接手者的第一步。

⚠️ 另记一处可能相关的既有滚动逻辑，动手前要读懂它，别与新逻辑打架：

packages/plugin-chatbot/src/ChatbotEnhanced.tsx:1861   textarea.scrollIntoView({ block: 'nearest' });

这是把输入框滚进视口（block: 'nearest'），与"把消息列表滚到底部"是两件事，但它们会争夺同一次滚动。

定级理由

priority:p3：

• 无功能缺陷：消息发出去了、AI 也在工作，只是用户看不见。
• 但卡片指出的体验代价是真的："用户看不到 AI 有没有开始工作" —— 在一个流式回复的界面里，看不见进度约等于以为卡住了。
• ⭐ 有同产品内的对照：全页 maker（/_console 的「用 AI 搭建」）会自动跟到底部。同一个产品里两个助手入口行为不一致，用户会以为侧栏坏了。
• 不上 p2：可手动滚动，无数据面，无错误信息。

定型：Bug，不踩 manual floor

接上一个已有的滚动行为 ⇒ 不加宽授权面、不改协议。

⛔ 给执行席的边界

1. 第一步是对比两条路径（侧栏 vs 全页 maker）挂载的是不是同一个 Conversation。⭐ 若是同一个，那么差异在外层容器的滚动祖先（侧栏是固定面板，可能有自己的 overflow 容器夺走了滚动）—— 那是完全不同的修法，且不在 chatbot 组件里。⛔ 不做这一步就直接加 scrollToBottom() 调用，很可能滚的是错的那个容器。
2. 必须用 isAtBottom 做守卫，照卡片的限定："只要用户没有主动向上滚"。⛔ 无条件滚到底部会在用户回看历史时把他弹走 —— 那比现在更糟。
3. 两个时机都要覆盖（卡片写了）：发送后，以及流式回复追加时。⛔ 只做第一个，用户仍会在长回复中途失去跟随。
4. ⚠️ 与 ChatbotEnhanced.tsx:1861 的 scrollIntoView 协调（见上），⛔ 别让两处滚动互相抢。
5. 复现照卡片给的：任意应用内点 ✳ → 连续发两条消息，看第二条发出后视口位置。（第二条是关键 —— 第一条时列表可能本来就在底部。）

⛔ 分诊席不认领、不派单、不写码。

---

Generated by Claude Code

[hotlong]

Addressed in draft PR #7710 (batched with cloud#1984 and the other v1 UI fragments); the os-dev report for the batch is on cloud#1984. Note: cloud needs a .objectui-sha bump before this reaches the cloud product.