toolname

Overview ¶

Package toolname 工具名 → 程序内可用的标识符：一条**单一真相**。

它为什么是一个独立包，而不是两处各写一份 ¶

工具名要在两处被规整成同一个字符串：

• 生产侧（tooldisclose）：从工具目录派生给模型看的调用形态， 形态里的函数名必须是**净化后**的名字——因为程序里真正挂上去的 就是净化后的那个（ptc 把绑定挂在 host.<净化名> 上）。
• 消费侧（ptc）：把绑定挂到 host 对象上，并校验形态串里的函数名 等于净化后的绑定名。

两侧必须**逐字一致**，否则就是「生产侧派得出、消费侧认不出」的夹缝： 生产侧返回 `get-logs(h)`，消费侧要的是 `get_logs(h)`，于是形态在装配期 被拒——而症状是「工具明明在目录里，程序就是调不通」，排查时极容易先 怀疑模型或宿主。

这条规则**曾经**在两个包里各写一份（规范名写成两份、净化规则又各写一份）， 于是两侧对「工具名长什么样」的假设漂移开：生产侧照抄目录里的原名， 消费侧按净化后的名字挂载，契约在文档里写着「直接可用」，代码里却拒。

抄一份规则省一个包，但那份规则有边界（数字开头补前缀、前导非法字符跳过、 撞名即拒），任何一边改了而另一边没改，契约就静默断掉——而断掉的形态 是「文档说好的，程序就是跑不通」。

规整规则 ¶

字母、数字、_ 、$        保留
数字出现在首位            前置 _（9lives → _9lives）
其他字符（- . 空格等）    已开始则记为 _；尚未开始则跳过（-x- → x_）
全部非法                  结果为空串（调用方必须处理，不能当合法名字用）

「前导非法字符跳过而不是记为 _」是刻意的：`-x-` 规整成 `x_` 而不是 `_x_`， 前者读起来像名字，后者像内部产物。

撞名是调用方的事，本包不拦 ¶

`get-logs` 与 `get_logs` 规整后同名。拦不拦、报什么错，取决于调用方 的语义（ptc 把它当装配期错误拒掉，因为顶替意味着副作用错位）。 本包只提供规则，不做集合级别的判定。