style(floating-ball): change input and bubble style

[Late-Smoke]

• Modify the style of the input box when it is in non focused and focused states
• Modify bubble color and delete button position, delete pin button
• Add bubble folding function
• Change the style when pasting

[fennoai]

Two regressions in the shell-ball interaction path need attention before this UI refresh is safe to ship.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[liche719]

@xgopilot idle 态下输入框的可见性与可交互性目前不一致，可能会造成误导性的交互体验。

从状态定义上看，shellBall.interaction.ts:76 已经将 idle 对应的 input mode 调整为 interactive，因此待机态下会直接展示输入框。这会向用户传达一个明确的信号：该输入框当前可以被直接点击并开始输入。

但在窗口交互层，shellBall.windowSync.ts:211 又在 idle + 无 draft + 未 hover + 未 focus 的场景下将 input window 标记为 clickThrough: true；而 useShellBallWindowMetrics.ts:626 会进一步将其转换为 ignoreCursorEvents: true 和 focusable: false。也就是说，这个输入框虽然可见，但在最常见的待机场景下实际上并不能直接接收鼠标事件或焦点。

最终效果是：用户会看到一个“看起来可以输入”的输入框，但实际仍需先激活 mascot / region，之后才能真正进入输入状态。这里的视觉语义与命中测试/焦点语义是冲突的。

建议这里统一设计意图：

• 如果目标是支持 idle 态直接输入，那么这条 clickThrough 逻辑需要同步调整；
• 如果目标只是待机态展示一个输入提示，那么当前控件不应呈现为可直接交互的输入框样式。

这个问题必要吗

[fennoai]

Findings

• Medium: apps/desktop/src/features/shell-ball/shellBall.interaction.ts:76 now maps idle to interactive, and apps/desktop/src/features/shell-ball/components/ShellBallInputBar.tsx:157 plus apps/desktop/src/features/shell-ball/components/ShellBallInputBar.tsx:428 render the idle bar as a visible collapsed input capsule with textarea and action buttons. But apps/desktop/src/features/shell-ball/shellBall.windowSync.ts:211 still forces the input helper to clickThrough: true for idle + !regionActive + !inputFocused + !inputHovered + !hasDraft, and apps/desktop/src/features/shell-ball/useShellBallWindowMetrics.ts:626 converts that into focusable: false and ignoreCursorEvents: true. That means the UI advertises direct text entry while the window layer discards the click. This is a behavioral inconsistency, not a cosmetic preference.

Answer

这个问题有必要提。

当前 PR 自己已经把这组矛盾固化进 contract：apps/desktop/src/features/shell-ball/shellBall.contract.test.ts:1455 断言 idle 时 input helper 可见，apps/desktop/src/features/shell-ball/shellBall.contract.test.ts:4728 又断言同一场景下 input helper 仍然是 clickThrough: true。所以这里不是“实现细节不同步”那么简单，而是代码和测试一起确认了一个对用户有误导性的交互语义。

建议二选一统一设计意图：

• 如果目标是 idle 态可直接输入，就去掉这条 idle click-through 分支，让窗口真正可点击、可聚焦。
• 如果目标只是待机态展示提示，就把 idle 视觉降级成明显的非交互提示，不要继续使用输入框外观和发送/附件控件语义。

View job run

[gdemonc]

@xgopilot After testing the latest PR, the idle-state input is actually directly clickable and interactive. The input bar is rendered inline in the main ShellBall window (ShellBallApp) when idle, and its visibility is controlled by snapshot.visibility.input, which is true for idle. Therefore, the input can be used without hover, and the previous concern about click-through blocking input does not apply to the current implementation.

[fennoai]

Findings

• Medium: apps/desktop/src/features/shell-ball/shellBall.contract.test.ts:8905 still hard-codes the old ShellBallInputBar source contract, but apps/desktop/src/features/shell-ball/components/ShellBallInputBar.tsx:38 no longer contains that implementation. The PR removed the resize-drag / pointer-capture path entirely and renamed restoreTextareaFocus to restoreInputFocus at apps/desktop/src/features/shell-ball/components/ShellBallInputBar.tsx:138, while the test still regex-matches onResizeStateChange(true/false), setPointerCapture, lostpointercapture, and the old helper name. If the contract suite runs, this change should fail immediately on those stale assertions.

Clarification

The earlier idle click-through concern does not apply to the inline idle input in the current implementation. The editable idle bar is rendered directly in apps/desktop/src/features/shell-ball/ShellBallApp.tsx:454, while the clickThrough branch in apps/desktop/src/features/shell-ball/shellBall.windowSync.ts:211 only affects helper-window interaction state.

Notes

I could not execute the desktop test suite here because pnpm is unavailable in the environment, so this review is based on diff and source inspection.

View job run

[Late-Smoke]

@xgopilot idle 态下输入框的可见性与可交互性目前不一致，可能会造成误导性的交互体验。

从状态定义上看，shellBall.interaction.ts:76 已经将 idle 对应的 input mode 调整为 interactive，因此待机态下会直接展示输入框。这会向用户传达一个明确的信号：该输入框当前可以被直接点击并开始输入。

但在窗口交互层，shellBall.windowSync.ts:211 又在 idle + 无 draft + 未 hover + 未 focus 的场景下将 input window 标记为 clickThrough: true；而 useShellBallWindowMetrics.ts:626 会进一步将其转换为 ignoreCursorEvents: true 和 focusable: false。也就是说，这个输入框虽然可见，但在最常见的待机场景下实际上并不能直接接收鼠标事件或焦点。

最终效果是：用户会看到一个“看起来可以输入”的输入框，但实际仍需先激活 mascot / region，之后才能真正进入输入状态。这里的视觉语义与命中测试/焦点语义是冲突的。

建议这里统一设计意图：

• 如果目标是支持 idle 态直接输入，那么这条 clickThrough 逻辑需要同步调整；
• 如果目标只是待机态展示一个输入提示，那么当前控件不应呈现为可直接交互的输入框样式。

这个问题必要吗

这个问题不影响实际使用，只是可能对阅读代码时产生歧义

[fennoai]

Findings

No blocking review issue here.

Answer

这个问题在当前实现里不算必要，之前那条 review concern 可以视为已澄清。

原因是 idle 态下真正可点击的输入框并不是 helper input window，而是主 ShellBallApp 里的内联输入栏：snapshot.visibility.input 先在 apps/desktop/src/features/shell-ball/ShellBallApp.tsx:454 决定是否渲染，再在 apps/desktop/src/features/shell-ball/ShellBallApp.tsx:1260 直接挂到主窗口底部，所以 idle 下用户实际点击的是主窗口内容，不受 helper window clickThrough 影响。

你提到的 clickThrough 分支仍然存在于 apps/desktop/src/features/shell-ball/shellBall.windowSync.ts:211，并且会在 apps/desktop/src/features/shell-ball/useShellBallWindowMetrics.ts:626 转成 helper input window 的 focusable/ignoreCursorEvents。但这层现在只是在约束 helper window，不是在阻止主窗口里的 idle 输入框。

从代码可读性看，这里确实有一点“同一个 visibility.input 同时驱动内联输入和 helper 输入可见性”的歧义；不过当前测试也已经明确把 idle helper 交互设为 click-through，见 apps/desktop/src/features/shell-ball/shellBall.contract.test.ts:4728。所以结论更接近“命名/分层语义有点绕”，而不是“实际交互行为有 bug”。如果后续还想降低阅读成本，建议单独补注释或把 inline/helper 的可见性语义拆开，但这不应作为当前 PR 的必改项。

View job run

[Late-Smoke]

上述两位reviewer提及的测试代码未更新问题，现已做修复 6e64901