🔵 Low Priority

改动行（scripts/tests/test_release_metadata.py:109）在测试方法内直接调用 self.setUp() 以获得一个干净的临时仓库：

for final_newline in (True, False):
with self.subTest(final_newline=final_newline):
self.setUp() # 每个子用例使用独立仓库

问题：setUp() 不是可重入的初始化函数，每次调用都会 self.addCleanup(self.temp.cleanup)、重新 os.environ.copy() 并重建 self.repo/self.env。症状是：一次测试内注册 2-3 份 cleanup、残留多个临时目录直到 teardown；后续若在 setUp 中增加断言、类级状态或不可重入资源（共享 fixture、端口、全局缓存），本用例会以难以定位的方式失败而其它用例正常。

建议：将 setUp 中的仓库初始化抽成可重复调用的 _init_repository() 辅助方法，测试内调用它而不是 self.setUp()，避免重复注册 addCleanup 与重复复制环境变量；如需立即清理旧临时目录，可在重置前调用 self.doCleanups()。

🔵 Low Priority

改动行（scripts/release_metadata.py:273-275）用 os.O_CREAT | os.O_EXCL 在 .git/release-metadata.lock 建锁，异常路径下才由 finally: lock_path.unlink() 释放。

触发条件：prepare --write 在持锁期间被 SIGKILL、断电、或容器被强制回收（finally 不执行），锁文件残留。

失败模式：此后每次 prepare --write 都在 except FileExistsError 处直接报“已有本地定版进程或遗留锁；先核实其状态”并 exit 1，即定版/发布流程被永久阻塞，直到有人手工删除 .git/release-metadata.lock。错误信息只提示“核实状态”，工具本身没有任何手段区分“另一个进程正在运行”与“僵尸锁”，也没有 PID/时间戳可判断，运维人员可能误删正在运行进程的锁。

建议：建议在锁文件内写入 PID 与创建时间；捕获 FileExistsError 时读取并校验 PID 是否存活，对僵尸锁允许接管（或提供显式 --force-unlock 参数），避免异常退出后发布流程被永久阻塞。

🔵 Low Priority

变更行（test_csr_identity.py:54-57）：先用正则 \A[0-9a-fA-F]{8}_[0-9a-fA-F]{8}\Z 校验 DDS 的 ID，该正则显式允许大写十六进制；紧接着 assertEqual(identity, path.stem.split("_", 1)[1], "DDS ID 必须与文件名一致") 做的是大小写敏感的字符串相等比较。

问题链路：同一函数内两处校验对"同一字段的合法形态"给出了互相矛盾的口径。SR/DDS 文件名按现有约定为小写（如 14140130_10de26b1_10de16a1），一旦新增/修改的配对被写成大写（如 DDS 内 "ID": "10DE26B1_10DE16A1"），第一处正则通过（身份四元组完全正确），第二处却直接失败。

失败模式：语义完全等价、身份正确的配置被判为不合格，测试报错信息为"DDS ID 必须与文件名一致"，指向的是大小写差异而非真实的身份错误，误导排查方向；同时该测试是本次修复的核心回归，误报会削弱其作为门禁的可信度。属于测试契约内部不一致，不是既有代码问题（本文件为新增文件）。

建议：统一 DDS ID 的合法形态口径：将比较改为大小写不敏感，或把正则收紧为只接受小写十六进制，避免"格式校验通过但一致性校验失败"的自相矛盾。

🔵 Low Priority

改动行（tests/meson.build:3-9，以及 tests/drivers/pcie_gpu_card/nvidia/meson.build:4-10）把两个 Python 单测以 find_program('python3') 作为可执行程序注册进 Meson 套件：

test(
'test_release_metadata',
find_program('python3'),
args: files('../scripts/tests/test_release_metadata.py'),
...
)

问题：find_program 默认 required: true，找不到名为 python3 的可执行文件时是配置期硬错误，会使 meson setup 整体失败，而不仅仅是跳过该测试。此前该测试目录只有 C++ 测试入口，不依赖 python 可执行名。

触发条件/失败模式：在只有 python（无 python3 软链）或仅通过虚拟环境/pipx 提供 meson、PATH 中没有 python3 的环境里，meson setup 直接以 “Program 'python3' not found or not executable” 中断，整个构建无法配置——即使使用者并不打算跑这两个脚本测试。

这是可选的健壮性改进：改为 python3 = find_program('python3', required: false) 并在 python3.found() 时才注册 test()，与仓库其它可选依赖（如 dependency('gtest', required: false)）的既有风格保持一致。

建议：把 find_program('python3') 改为 required: false 并保存到变量，仅在 found() 为真时注册 test()（两份 meson.build 同步处理），避免缺少 python3 时 meson setup 直接失败。