这次 v0.4.0，本来不在计划里。

blf remove 其实 7 月底就做完了。我不是刻意等着攒一个版本，而是把 release 这件事忘了。直到这次 Windows 10 真机测试跑完，回头整理改动时才发现：一个月前加的功能，居然还没有发出去。

既然如此，就一起发了。

symlink 突然成了问题

后来 Kiro 1.0 的改动，把 Windows 测试这件事推到了眼前。

我有不少开发期的内容不想提交到 Git，会把它们放在项目外，再通过 symlink 挂进来。这也是 blf 最早想解决的场景：文件可以留在它该在的地方，多个项目照样能用，不必为了同步而改变自己的 Git 工作流。

但 Kiro 1.0 开始拒绝读取指向 workspace 外的 symlink。我照着权限文档，workspace permission、全局 permission 都配过，fs_read、fs_write、filesystem 也挨个试了，没有一个能用。最后只能退回 1.0 前的 0.12.333；后来自动升级到 1.0.337，这套工作流彻底断掉，我也把订阅降回了 Free。

这段经历我写在了 Kiro 的 issue 里：Allow explicit trust for symlinks resolving outside workspace

https://github.com/kirodotdev/Kiro/issues/9912

我能理解它的安全考虑。问题是，symlink-first 这条路的边界一下子变得很清楚：只要上游工具不认，用户自己明明知道目标目录是什么，也还是过不去。

那是不是该支持全量 copy？我觉得应该认真考虑，但这不是改个 option 就完事的事情。既然要动这么大一块，在此之前先把现有行为在 Windows 上验证清楚，反而更合适。至少下一步往哪里走，得站在一个自己心里有数的基础上。

这件拖了很久的事，终于做了

趁着休假，我腾出大半天，把 Windows 10 上的环境、Developer Mode 和测试都走了一遍。

过程当然不是一遍过。Windows 总有自己的一套规矩，平时在 macOS 和 Linux 上没碰到的地方，到了这里都会冒出来。好在问题都还在 blf 的边界内，修完之后，完整的 uv run pytest 终于在真机上跑通了。

这就是 v0.4.0 对我最重要的意义。它不是说从此 Windows 再也不会出问题，也不是给自己贴一个多漂亮的“跨平台”标签。只是从现在开始，blf 至少在 macOS、Linux 和我这台 Windows 10 上，都真的跑过了。

有些事就是这样。没做之前，心里总留着一根刺；做完之后，看 changelog 可能只有几行，自己知道它不是几行代码那么简单。

remove 这件小事，也该有个收场

再说回 blf remove。

这个命令在 7 月 31 日就已经完成，早于这次 Windows 测试。我把它写进这篇文章，只是因为它同样来自我每天用 blf 时遇到的那点麻烦。

blf revlink create 会把一个文件接进这套同步关系：managed project 里有副本，target project 里有 symlink 或 copy，Git exclude 里可能多了一条记录；如果是 selective sync，配置里也会留下相应的 subpath。

要反过来把它彻底移除，原来只能自己一个个删。target 多了之后，很难保证没漏：忘了删 exclude，或者配置里还留着 subpath，下次 link sync 又会把东西带回来。

所以才有了 blf remove。它会先确认你给出的路径确实属于 blf 管理，确认每个 target 上的投影也没有被别的东西替换；检查都通过，才去清理投影、Git exclude、managed copy 和 selective-sync 配置。担心手滑的话，先加 --dry-run 看一遍就行。

这不是一个多大的功能，但它补上了一个很实际的缺口：创建之后，也该能好好地撤掉。工具总不能只管把东西接进来，等不需要了就让人自己收拾残局。

下一步：full copy

Kiro 的限制让我不得不重新看 symlink-first 的设计。下一步，我想认真做的就是 full copy。

它不一定要取代 symlink，但至少应该给那些不能、或者不想依赖 symlink 的场景一个可用的选择。Windows 真机测试既然已经补上，接下来就可以更踏实地把这件事想清楚、做出来。

v0.4.0 先到这里。下一次 blf 发版本，希望能带着 full copy 再来。