refactor(chat): remove manual view switching

[kangfenmao]

What this PR does

Before this PR:

Session/topic view switching and resource actions were spread across settings, sidebar behavior, and grouped menu surfaces. Agent and assistant resource controls also had inconsistent labels and nested edit-dialog tool tabs.

After this PR:

Session/topic display mode controls live with the relevant resource menus, legacy layout preferences are removed, resource list interactions are simplified, and Agent/Assistant edit tool tabs are shown directly. The related i18n strings, docs, preference schema, and tests are updated.

Fixes #N/A

Why we need it and why it was done in this way

The following tradeoffs were made:

The change keeps the behavior scoped to the existing chat and agent resource surfaces instead of adding another settings-level abstraction.

The following alternatives were considered:

Keeping the old settings switches was considered, but that would preserve duplicated layout controls and make the resource menu behavior harder to reason about.

Links to places where the discussion took place: N/A

Breaking changes

N/A

Special notes for your reviewer

This PR includes UI behavior changes in chat resource lists, AgentPage/HomePage display mode handling, and Agent/Assistant edit dialog tab presentation.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Branch: This PR targets the correct branch — main for active development, v1 for v1 maintenance fixes
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

Remove manual chat view switching and move session/topic display controls into the relevant resource menus.

[eeee0717]

This review was translated automatically.

Findings:

• Important: src/renderer/pages/agents/AgentPage.tsx:467 and src/renderer/pages/agents/AgentPage.tsx:894 can both create a new blank agent session without a single-flight guard. The picker path closes the dialog before awaiting, but the composer path remains clickable, and either path can be triggered again before the first POST /agent-sessions result is reflected in classicLayoutSessions. Because both code paths only call findReusableEmptySession against that stale list, rapid repeated actions can create duplicate empty sessions for the same agent/workspace. Home already guards the analogous classic topic paths with isCreatingTopicRef; please add the same protection for classic agent session creation and cover the rapid double-click/re-entry case.

Open questions:

• None.

Summary:
Requesting changes for the duplicate blank-session creation path in the new classic agent flow.

Verification:

• Reviewed PR #16739 at head 5e45378eeb71749758607bd8f7db2ce285427175 in /Users/cherryai004/Documents/Cherry_Studio_Dev/cherry-studio-pr-review/.codex-tmp/pr-review-sweep-16739-20260704T090238Z.
• Inspected the preference/display-mode migration, resource rail/menu changes, shell/pane/composer changes, edit dialog changes, docs, i18n, and related tests.
• Checked GitHub CI via gh; latest relevant checks were successful or skipped by change gating.
• Did not run local pnpm lint/test/format, per repository PR review instructions.

After fixing, please request eeee0717 for further review.

---

Original Content

Findings:

• Important: src/renderer/pages/agents/AgentPage.tsx:467 and src/renderer/pages/agents/AgentPage.tsx:894 can both create a new blank agent session without a single-flight guard. The picker path closes the dialog before awaiting, but the composer path remains clickable, and either path can be triggered again before the first POST /agent-sessions result is reflected in classicLayoutSessions. Because both code paths only call findReusableEmptySession against that stale list, rapid repeated actions can create duplicate empty sessions for the same agent/workspace. Home already guards the analogous classic topic paths with isCreatingTopicRef; please add the same protection for classic agent session creation and cover the rapid double-click/re-entry case.

Open questions:

• None.

Summary:
Requesting changes for the duplicate blank-session creation path in the new classic agent flow.

Verification:

• Reviewed PR #16739 at head 5e45378eeb71749758607bd8f7db2ce285427175 in /Users/cherryai004/Documents/Cherry_Studio_Dev/cherry-studio-pr-review/.codex-tmp/pr-review-sweep-16739-20260704T090238Z.
• Inspected the preference/display-mode migration, resource rail/menu changes, shell/pane/composer changes, edit dialog changes, docs, i18n, and related tests.
• Checked GitHub CI via gh; latest relevant checks were successful or skipped by change gating.
• Did not run local pnpm lint/test/format, per repository PR review instructions.

修复后请 request eeee0717 再进行后续 review。

[AtomsH4]

Reviewed the resource menu/layout preference refactor. The preference/source-of-truth migration is mostly consistent, but I left two warnings: one real deletion-guard race in the new classic rail clear-topics path, and one missing v2 breaking-changes entry for the user-visible layout behavior change.

[zhangjiadi225]

Findings:

1. Blocking: src/renderer/pages/agents/AgentPage.tsx:90 / src/renderer/pages/home/HomePage.tsx:128 — Agent session pane position is stored in topic.tab.position. Moving the session list in Agent therefore also changes the Home topic pane position, and sessionItemActions.tsx:116 also reuses settings.topic.position.* copy for the session menu. This mixes two product surfaces behind a topic-scoped preference. Please either split this into an Agent-specific key such as agent.session.position, or rename/migrate it to a genuinely shared resource pane position key and update the type/i18n/migration naming accordingly.

2. Blocking: src/renderer/components/chat/resourceList/ResourceEntityRail.tsx:141 — tag grouping enables drag reorder while persistence still writes the global assistant orderKey. AssistantResourceList.tsx:437 passes groupByTag, and the rail only restricts drops to the same rendered tag group, but useResourceEntityRail still builds a global id order and PATCHes /assistants/:id/order. Reordering within one tag can therefore move the assistant across unrelated tags in the global order when switching back to list view or when sections are recomputed. Please keep reorder disabled while groupByTag is active unless there is a tag-scoped ordering model.

3. Blocking: src/renderer/pages/home/Tabs/components/Topics.tsx:804 — the new assistant-group delete path calls dataApiService.delete('/assistants/:id') directly instead of using useAssistantMutations().deleteAssistant(). The shared hook refreshes /pins and /topics for deleteTopics: true; this path manually refreshes assistants/topics only, which can leave stale assistant/topic pins in pin-aware UI and duplicates the assistant deletion workflow in a topic component. Please reuse deleteAssistant(assistantId, { deleteTopics: true }) here.

4. Follow-up: src/renderer/components/chat/resourceList/ResourceEntityRail.tsx:147 — selectedClickId/onSelectedClick only runs through row click. Keyboard Enter/Space goes through ResourceListVirtual.tsx:372 -> actions.selectItem(activeId), so keyboard users cannot trigger the new “select the already selected entity to open/toggle the pane” behavior. Please wire ResourceList.Provider.onSelectItem to find the item and reuse handleItemClick(item).

5. Follow-up: src/renderer/components/chat/resourceList/AgentResourceList.tsx:67 / src/renderer/pages/agents/components/Sessions.tsx:282 — Agent icon display uses an Agent-labeled menu but still reads/writes assistant.icon_type, with option labels coming from settings.assistant.icon.type.*. If this is intended to be shared, the preference should be migrated/renamed to a neutral resource icon key; otherwise Agent needs its own agent.icon_type.

Verification:

• Reviewed PR #16739 at head 6569aba82902c70dd1a0e5b98b8707ec9df6e6f2.
• Checked GitHub CI via gh; current checks are green.
• Did not run local pnpm lint/test/format, per repository PR review rules.

[zhangjiadi225]

Additional finding:

Follow-up: src/renderer/pages/home/Tabs/components/Topics.tsx:509 / src/renderer/pages/agents/components/Sessions.tsx:590 / src/renderer/pages/agents/components/Sessions.tsx:634 — the fallback selection after deleting the active topic/session is not aligned between Assistant and Agent, and it also does not consistently match the current display grouping. Initial classic entry selects the globally latest topic/session (findLatestUpdated), and clicking an assistant/agent rail entity enters that entity's first resource by pinned/time order. But deleting the active row uses a different set of rules: the topic right panel picks the neighbouring topic scoped to the current assistant, while the session right panel does the same for the current agent; the session sidebar then falls back to sessionItems.find((s) => s.id !== id), which is the raw API/orderKey order rather than the visible group order or latest updated session.

Please extract/centralize this selection policy and make it explicit: either always choose the next visible row according to the current display list, or choose the latest remaining row within the relevant assistant/agent/workdir scope. As written, deleting a session from the Agent sidebar can jump to an unexpected session that is neither the nearest visible item nor the latest item.

Verification:

• Rechecked this behavior on PR #16739 head 6569aba82902c70dd1a0e5b98b8707ec9df6e6f2.
• Did not run local pnpm lint/test/format, per repository PR review rules.

[eeee0717]

This review was translated automatically.

Findings:

• Important: src/renderer/utils/sidebar.ts:270 / src/shared/data/preference/preferenceSchemas.ts:482 change ui.sidebar.favorites from a bare app-id array to tagged SidebarFavoriteItem[], but existing preference DB rows are loaded as-is and the seeder only inserts missing rows. A saved value like ['assistants','agents','translate','mini_app'] now reaches normalizeSidebarFavoriteItem, has no type, is dropped, and the sidebar falls back to only the required assistants item. Please add a one-time preference data migration or storage-boundary normalization that rewrites legacy strings to { type: 'app', id }, and cover this existing-row case in tests.

• Important: src/renderer/components/chat/resourceList/AssistantResourceList.tsx:440 and src/renderer/components/chat/resourceList/AgentResourceList.tsx:276 consume resourceMenuItems for the new options menu but no longer pass them through to ResourceEntityRail. ResourceEntityRail still relies on active resourceMenuItems to clear row selection and disable the selected-row repeat-click path (ResourceEntityRail.tsx:144). In classic layout, opening the Assistant/Agent/Skill resource catalog leaves the current rail entity visually selected, and clicking that selected row runs onSelected*Click instead of normal selection, so it toggles the right resource pane rather than closing the catalog and returning to the conversation. Please forward the menu state, or otherwise give the rail the same active-resource-view signal, so active catalog views suppress entity selection/repeat-click behavior.

• Important: src/renderer/pages/home/HomePage.tsx:523 can fall back into a draft for the assistant that was just deleted. Topics.tsx:804 calls deleteAssistant(assistantId, { deleteTopics: true }), then invokes onActiveAssistantDeleted before refreshing assistants/topics. When there is no remaining topic to select, handleActiveAssistantDeleted calls startDraftAssistantSelection() with no payload; resolveDraftAssistantTarget still sees the stale assistant list and stale lastUsedAssistantId, so it can resolve back to deletedAssistantId. The UI can then show a draft bound to a non-existent assistant, and creating/sending from it can fail. Please make this fallback exclude the deleted assistant or refresh/update the assistant source before starting the fallback draft, and cover the "delete active assistant with no remaining topics" case.

• Important: src/renderer/pages/agents/AgentPage.tsx:126 auto-opens the classic Agent session pane on every fresh mount when the stored display mode is agent and the session position is right. The effect always calls setSessionPaneOpen(true) after remount, so a user who manually closes the right session pane has ui.agent.right_pane_open=false overwritten the next time the Agent page/app is re-entered. Please preserve explicit stored false values and only default-open when the setting is genuinely unset/being initialized; add a remount/restart-style test for the manual-close case.

• Important: src/renderer/i18n/locales/en-us.json:1099 and the matching zh-cn / zh-tw entries regress the assistant clear flow back to "topics" while the surrounding UI labels it as conversations. The dialog title remains "Clear conversations", but the content/menu/success copy now says "topics", producing mixed user-visible terminology for the same action. Please keep these strings consistent with the conversation wording, e.g. "Clear conversations", "Clearing conversations will delete…", and "Cleared {{count}} conversations" with matching Chinese translations.

Manual intervention:

• Required: Preference/data migration and chat/agent UI runtime behavior changed; please manually verify upgraded sidebar favorites, classic resource rail/catalog switching, active-assistant deletion fallback, and right-position Agent session pane close persistence.

Verification:

• Reviewed PR #16739 at head 98d4935806c6a355bdfa2162cc7e93fb7024ce48 in the pinned worktree.
• Checked existing reviews/comments and did not repeat previously addressed feedback.
• Checked GitHub CI via gh; current checks are passing or skipped.
• Did not run local pnpm lint/test/format, per repository PR review rules.

After the fix, please request eeee0717 for further review.

---

Original Content

Findings:

• Important: src/renderer/utils/sidebar.ts:270 / src/shared/data/preference/preferenceSchemas.ts:482 change ui.sidebar.favorites from a bare app-id array to tagged SidebarFavoriteItem[], but existing preference DB rows are loaded as-is and the seeder only inserts missing rows. A saved value like ['assistants','agents','translate','mini_app'] now reaches normalizeSidebarFavoriteItem, has no type, is dropped, and the sidebar falls back to only the required assistants item. Please add a one-time preference data migration or storage-boundary normalization that rewrites legacy strings to { type: 'app', id }, and cover this existing-row case in tests.

• Important: src/renderer/components/chat/resourceList/AssistantResourceList.tsx:440 and src/renderer/components/chat/resourceList/AgentResourceList.tsx:276 consume resourceMenuItems for the new options menu but no longer pass them through to ResourceEntityRail. ResourceEntityRail still relies on active resourceMenuItems to clear row selection and disable the selected-row repeat-click path (ResourceEntityRail.tsx:144). In classic layout, opening the Assistant/Agent/Skill resource catalog leaves the current rail entity visually selected, and clicking that selected row runs onSelected*Click instead of normal selection, so it toggles the right resource pane rather than closing the catalog and returning to the conversation. Please forward the menu state, or otherwise give the rail the same active-resource-view signal, so active catalog views suppress entity selection/repeat-click behavior.

• Important: src/renderer/pages/home/HomePage.tsx:523 can fall back into a draft for the assistant that was just deleted. Topics.tsx:804 calls deleteAssistant(assistantId, { deleteTopics: true }), then invokes onActiveAssistantDeleted before refreshing assistants/topics. When there is no remaining topic to select, handleActiveAssistantDeleted calls startDraftAssistantSelection() with no payload; resolveDraftAssistantTarget still sees the stale assistant list and stale lastUsedAssistantId, so it can resolve back to deletedAssistantId. The UI can then show a draft bound to a non-existent assistant, and creating/sending from it can fail. Please make this fallback exclude the deleted assistant or refresh/update the assistant source before starting the fallback draft, and cover the "delete active assistant with no remaining topics" case.

• Important: src/renderer/pages/agents/AgentPage.tsx:126 auto-opens the classic Agent session pane on every fresh mount when the stored display mode is agent and the session position is right. The effect always calls setSessionPaneOpen(true) after remount, so a user who manually closes the right session pane has ui.agent.right_pane_open=false overwritten the next time the Agent page/app is re-entered. Please preserve explicit stored false values and only default-open when the setting is genuinely unset/being initialized; add a remount/restart-style test for the manual-close case.

• Important: src/renderer/i18n/locales/en-us.json:1099 and the matching zh-cn / zh-tw entries regress the assistant clear flow back to "topics" while the surrounding UI labels it as conversations. The dialog title remains "Clear conversations", but the content/menu/success copy now says "topics", producing mixed user-visible terminology for the same action. Please keep these strings consistent with the conversation wording, e.g. "Clear conversations", "Clearing conversations will delete…", and "Cleared {{count}} conversations" with matching Chinese translations.

Manual intervention:

• 需要：Preference/data migration and chat/agent UI runtime behavior changed; please manually verify upgraded sidebar favorites, classic resource rail/catalog switching, active-assistant deletion fallback, and right-position Agent session pane close persistence.

Verification:

• Reviewed PR #16739 at head 98d4935806c6a355bdfa2162cc7e93fb7024ce48 in the pinned worktree.
• Checked existing reviews/comments and did not repeat previously addressed feedback.
• Checked GitHub CI via gh; current checks are passing or skipped.
• Did not run local pnpm lint/test/format, per repository PR review rules.

修复后请 request eeee0717 再进行后续 review。

[kangfenmao]

This comment was translated automatically.

@eeee0717 has re-checked and handled these items:

1. ui.sidebar.favorites old string array compatibility issue: confirmed it still exists, will add storage-boundary normalization / migration coverage later.
2. ResourceEntityRail not receiving resourceMenuItems: fixed, Assistant / Agent resource list now both pass through.
3. After deleting current assistant, fallback goes to deleted assistant: fixed, fallback will exclude deleted assistant and clean up stale last-used assistant.
4. Agent right session pane manually closed then remount opens again: fixed, and already has remount/manual close test coverage.
5. Mixed use of topic/conversation in clear assistant copy: ignoring for now, not in this round.

Synced with latest main and pushed, current head is 4ce34ffc0cb451d76112caa03c697325be5715f7. Please review again.

---

Original Content

@eeee0717 已对这几项重新检查并处理：

1. ui.sidebar.favorites 旧字符串数组兼容问题：确认仍存在，后续会补 storage-boundary normalization / 迁移覆盖。
2. ResourceEntityRail 未收到 resourceMenuItems：已修复，Assistant / Agent resource list 现在都会透传。
3. 删除当前助手后 fallback 回被删除助手：已修复，fallback 会排除 deleted assistant，并清理 stale last-used assistant。
4. Agent 右侧 session pane 手动关闭后 remount 又打开：已修复，并已有 remount/手动关闭测试覆盖。
5. clear assistant 文案里的 topic / conversation 混用：这个先忽略，不在本轮处理。

已同步最新 main 并推送，当前 head 是 4ce34ffc0cb451d76112caa03c697325be5715f7。麻烦再 review 一下。

[DeJeune]

LGTM