2 Commits

Include renames

Author	SHA1	Message	Date
Shuery	42f02d0eca	refactor: 公共面补 BakNRet 前缀，产品名大小写全仓统一 ... 16 个没有前缀的公共函数补上 BakNRet（Write-Log → Write-BakNRetLog、Resolve-BackupEntry → Resolve-BakNRetBackupEntry、Find-ChildDirectoryByName → Find-BakNRetChildDirectoryByName 等）， 另外把全仓的 Baknret 统一成 BakNRet（47 个文件、940 处、65 个定义文件重命名）。 这不是审美问题：静态分析直接拓出一条实据 —— Write-Log 与本机某个已装模块导出的命令 **重名**（PSAvoidOverwritingBuiltInCmdlets），而重名的后果是导入两个模块时有一方的命令被 静默遮蔽。补前缀正是这条规则的解法，改名后它归零。 为什么敢做这个规模：PowerShell 的函数名解析大小写不敏感，所以 Baknret → BakNRet 在功能 上是零风险；真正要验证的是 16 个补前缀的调用点，而 276 个断言几乎覆盖了每个函数。另外 "名字与文件名一致"这条不变式有断言盯着（加载器点源的文件集合 vs 磁盘）。 踩到并记下的坑：Windows 文件系统大小写不敏感，所以**只改大小写**的重命名会被 Move-Item 当成同一个文件而静默跳过 —— 同一批里同时改了名字的那 16 个文件却成功了，于是"看起来能跑"。 最后用"先移到临时名、再移到目标名"的两步走解决，判断与替换全部改用显式大小写敏感的形式 （-creplace / -cmatch）。 顺带把名录指纹缓存从 MD5 换成 SHA256（PSAvoidUsingBrokenHashAlgorithms）：它只是缓存键， 没有兼容负担。 验收：test.ps1 9/9 全绿（7 与 5.1）、100 个文件两版解析零错、276 个断言全过、 构建工具仍能合回单文件（3300 行）。	2026-09-27 09:56:36 +08:00
Shuery	2ad7987ffe	refactor: Common.psm1 拆成 BakNRet/{Public,Private}，一函数一文件 + 薄加载器 ... 3152 行、66 个函数的单文件模块拆成： BakNRet\BakNRet.psd1 模块清单：FunctionsToExport 是显式白名单（62 个名字） BakNRet\BakNRet.psm1 加载器：点源顺序的唯一一处声明 BakNRet\Public\*.ps1 62 个对外函数，一函数一文件，文件名 = 函数名 BakNRet\Private\*.ps1 4 个内部函数 + State.ps1（模块级状态集中一处） 为什么是一函数一文件：这是社区里脚本模块的主流形态（调研实测：winutil 79 个、 Terminal-Icons 24 个、ModuleBuilder 23 个，全部如此）。收益是改动落在小文件里、diff 按职责 可读、模块级状态有唯一去处。 为什么这不算"打散"：模块内 dot-source 的文件共享同一个模块作用域（实测确认），所以 "按顺序点源 67 个文件"与"点源一个大文件"在语义上等价；顺序只在加载器里出现一次， tools\Build-BakNRetModule.ps1 从那里读出顺序就能拼回单文件 —— 本次产物 dist\BakNRet.psm1 3240 行、两个版本都解析零错。 新增一条断言把这条承诺钉住：加载器点源的文件集合必须与磁盘一致、导出名单必须与 Public\ 一一对应。漏一个文件或漏一个名字就是静默少一个函数 —— 而那种错在运行时只表现为 "找不到命令"。 引用更新：11 个文件里的 Common.psm1 改成 BakNRet\BakNRet.psd1（走清单导入， FunctionsToExport 才真的说了算）；Common.psm1 直接删除，不留转发垫片。 验收：test.ps1 9/9 全绿（7 与 5.1），98 个文件两版解析零错，276 个断言原样通过 —— 这次搬家没有改变任何可观察行为。	2026-09-27 09:34:10 +08:00