提交前确认 / Pre-submit checklist
运行环境 / Environment
DSH Web（浏览器访问）/ DSH Web (browser access)
类别 / Category
✨ 功能请求（新功能 / Feature request）
描述 / Description
首先感谢你们开发和持续维护 DSH Better Sidebar。
这个项目的侧边栏 UI、Tab 管理、布局持久化，以及 ctx.betterSidebar.registerTab() / registerFileViewer() 扩展机制都做得非常优秀。特别是内置功能与第三方插件使用同一套注册 API，让它很有潜力成为 DSH 通用的侧边栏基础设施。
想请问，项目是否考虑将这部分基础能力拆分为一个独立、纯净的 Core 包，例如：
Core 只包含：
- Sidebar / Tab UI Shell；
ctx.betterSidebar 扩展服务；- Tab 和 Viewer 注册表；
- 布局、状态持久化与生命周期；
- 必要的 DSH UI 集成。
当前的 dsh-better-sidebar 则依赖 Core，并在其上组合文件、Git、终端、浏览器、Subagent、Side Chat 和文件预览等完整功能。更贴近具体使用场景的能力，也可以作为上层封装或独立插件依赖 Core。
期望的依赖关系大致是：
dsh-better-sidebar-core
├── dsh-better-sidebar（完整工作台）
├── 其他功能插件
└── 用户自己的业务插件
这样，需要完整工作台的用户仍然可以直接安装当前包；只需要侧边栏容器的用户，则可以单独依赖 Core，并按需选择功能插件。依赖关系会更干净，插件组合也会更加灵活。
提出这个需求，正是因为 Better Sidebar 的 UI 与扩展机制非常优秀。希望它可以进一步成为一个独立、通用、可组合的 DSH 侧边栏基础设施。
请问维护者是否认可或已经考虑过这个拆分方向？如果方向合适，是否欢迎社区参与设计或提交 PR？
再次感谢这个优秀的项目！
Thank you for building and continuously maintaining DSH Better Sidebar.
Its sidebar UI, tab management, layout persistence, and the ctx.betterSidebar.registerTab() / registerFileViewer() extension APIs are especially well designed. Since built-in features and third-party plugins already use the same registration mechanism, Better Sidebar has strong potential to become a general-purpose sidebar foundation for DSH.
Would you consider extracting these foundational capabilities into a clean standalone Core package, for example:
The Core package would contain only the UI shell, extension service and registries, layout/state persistence, lifecycle management, and necessary DSH UI integration. The current dsh-better-sidebar package would depend on Core and compose the complete workspace features on top of it. Other feature-oriented or business-specific plugins could depend on Core directly as well.
This would preserve the current package's out-of-the-box experience while allowing users who only need the sidebar foundation to install a cleaner dependency set and compose features as needed.
Is this separation already being considered? If the direction fits the project, would community design work or a PR be welcome?
提交前确认 / Pre-submit checklist
运行环境 / Environment
DSH Web（浏览器访问）/ DSH Web (browser access)
类别 / Category
✨ 功能请求（新功能 / Feature request）
描述 / Description
首先感谢你们开发和持续维护 DSH Better Sidebar。
这个项目的侧边栏 UI、Tab 管理、布局持久化，以及
ctx.betterSidebar.registerTab()/registerFileViewer()扩展机制都做得非常优秀。特别是内置功能与第三方插件使用同一套注册 API，让它很有潜力成为 DSH 通用的侧边栏基础设施。想请问，项目是否考虑将这部分基础能力拆分为一个独立、纯净的 Core 包，例如：
Core 只包含：
ctx.betterSidebar扩展服务；当前的
dsh-better-sidebar则依赖 Core，并在其上组合文件、Git、终端、浏览器、Subagent、Side Chat 和文件预览等完整功能。更贴近具体使用场景的能力，也可以作为上层封装或独立插件依赖 Core。期望的依赖关系大致是：
这样，需要完整工作台的用户仍然可以直接安装当前包；只需要侧边栏容器的用户，则可以单独依赖 Core，并按需选择功能插件。依赖关系会更干净，插件组合也会更加灵活。
提出这个需求，正是因为 Better Sidebar 的 UI 与扩展机制非常优秀。希望它可以进一步成为一个独立、通用、可组合的 DSH 侧边栏基础设施。
请问维护者是否认可或已经考虑过这个拆分方向？如果方向合适，是否欢迎社区参与设计或提交 PR？
再次感谢这个优秀的项目！
Thank you for building and continuously maintaining DSH Better Sidebar.
Its sidebar UI, tab management, layout persistence, and the
ctx.betterSidebar.registerTab()/registerFileViewer()extension APIs are especially well designed. Since built-in features and third-party plugins already use the same registration mechanism, Better Sidebar has strong potential to become a general-purpose sidebar foundation for DSH.Would you consider extracting these foundational capabilities into a clean standalone Core package, for example:
The Core package would contain only the UI shell, extension service and registries, layout/state persistence, lifecycle management, and necessary DSH UI integration. The current
dsh-better-sidebarpackage would depend on Core and compose the complete workspace features on top of it. Other feature-oriented or business-specific plugins could depend on Core directly as well.This would preserve the current package's out-of-the-box experience while allowing users who only need the sidebar foundation to install a cleaner dependency set and compose features as needed.
Is this separation already being considered? If the direction fits the project, would community design work or a PR be welcome?