这份路线图只盯着 Features.md 里「## 🌱 可扩展方向」那一串点子，把它们按投入产出比、依赖关系、风险，重新排成一条能一直走下去的开发主线。
目标不变：把 "我这台机器上到底有哪些 repo / workspace" 这事，从文件管理器地狱里拎出来，做成一个安静、耐久的总控台。
- 边界：不做 Git 客户端（commit/diff/branch/status 面板都不做），不做 repo 内文件浏览。
- 约束：TypeScript + Extension Host；unbundled；UI 以 TreeView + 虚拟文档预览为主；依赖克制。
- 体验原则：少弹窗、少打断；能失败但别崩；遇到坏数据要容错。
这些在 Features.md 里标了 done，就当作当前基线：
- 乐观刷新：先展示缓存，后台扫描更新（done）
- Workspace 预览：md 高亮；允许在主窗口打开而不是右侧分半屏（done）
- 刷新按钮更直观（done）
下面每个阶段都尽量做到：做完就能用，而且不会把后面路堵死。
把 "每天都会碰到的小烦" 先清掉。
-
预览文件改为预览模式（Preview tab）
- 目标：预览不占 tab，不污染工作区；用户点开第二个预览会自动替换。
-
单击/双击打开行为可配置
- 目标：让操作手感贴合个人习惯（有的人就爱单击，有的人怕误触）。
-
最近打开的 repo/workspace
- 目标：不用再翻目录，1-2 次点击回到刚才的项目。
-
新窗口打开/当前窗口打开可配置
- 目标：自定义行为，可修饰键切换
- 结果：VSCode 不支持修饰键，回退为右键菜单 验收标准（DoD）：
-
不改任何用户项目文件（只存扩展自己的状态）
-
不需要用户理解新概念，开箱就会用
-
最常用动作（打开、切换、预览）点击数明显下降
把 "能配" 变成 "想配就能配"。
- 友善的路径配置页
- 在VSCode设置页支持唤起原生文件夹选择器（Explorer/Picker）
- 也支持手动输入路径（键盘党别被劝退）
- 多语言支持（i18n）
- 优先把用户可见文案收拢到一处，后续再接真正的翻译
验收标准（DoD）：
- 路径相关配置不需要记 key 名，不需要手写 JSON
- 配置变更立即生效（刷新即可见）
这个阶段不追求炫技，追求 "用一年不烦"。
- DEBUG 日志与错误处理
- 输出到 OutputChannel：扫描开始/结束、耗时、命中数量、错误摘要
- 失败策略：记录 + 轻提示；不让扩展功能全体失效
- 常态输出增加：
- 总感觉现在有点少？或者实际上也足够了？
- 扫描错误时警告弹窗
- 扫描性能守门
- 目录大也不能卡死 UI；能取消/节流就做（别让用户感觉 VS Code 卡了）
验收标准（DoD）：
- 扫描异常不会导致 TreeView 空白到需要重启
- 用户能用日志定位问题（至少能知道是哪个目录/哪个 workspace 文件坏了）
这阶段开始引入复杂功能，但仍然保持不侵入。
- 搜索功能
- 最快速，不必多言
- TreeView 展开状态缓存
- 目标：记忆用户的展开状态，避免都使用这个扩展了却只是换一个地方继续点点点
- Repo metadata
- 用各个语言的图标显示 Repo，供用户快速确认项目类型
- Repo <-> Workspace 关联提示
- 考虑在 Workspace 预览中提示
- 例如：某个 repo 出现在哪些 workspace 里；某个 workspace 里哪些 folder 是 repo
验收标准（DoD）：
- 编辑行为可撤销/可预览（别一按钮把 workspace 写坏）
- 关联提示不要求 100% 准确，但要稳定、可解释
- Phase 1 先做：纯体验提升，风险低，回报立刻可见。
- Phase 2 再做：配置友好化会带来更多边界输入（路径乱、权限问题），需要 Phase 3 的日志兜底。
- Phase 3 放中间：可观测性越早越好，但做太早又容易过度工程，所以卡在 "功能稳定后" 刚刚好。
- Phase 4 最后：编辑/关联属于高价值但也更容易踩坑（数据一致性、容错、性能），放到基础稳了再做。
- v0.x.1：Phase 1（预览模式 + 单双击配置 + 最近打开）
- v0.x.2：Phase 2（配置页 + 可选初始化引导 + 文案收拢/i18n 基建）
- v0.x.3：Phase 3（日志 + 错误处理 + 扫描可取消/节流）
- v0.x.4：Phase 4（workspace 轻编辑 + metadata + 关联提示）