M006：锁住解析结果：mise.lock、平台与 strict mode
目标：从版本选择器生成可审阅的解析记录，并用严格安装验证 lockfile 的覆盖边界。
0–7 分钟：配置表达意图，lockfile 记录结果
node = "22" 的含义是“选择符合 22 的版本”，不是“永远使用某个补丁版本”。mise.lock 可以记录具体解析版本；backend 支持时，还会记录按平台区分的 URL、checksum、size 或 provenance。[S06]
把两者分工写成一句话：
mise.toml 适合人审阅“想要什么”；mise.lock 适合机器复用“上次解析成什么”。
lockfile 也有边界：不同 backend 能记录和验证的信息不同。缺少 checksum 时，应写“此 backend 只提供版本或部分工件信息”，而不是宣称供应链已被完整验证。[S06]
7–19 分钟：生成、阅读并验证 lockfile
继续使用 M005 的 /tmp/mise-task-lab。
步骤 1：确认配置仍是模糊选择器
cd /tmp/mise-task-lab
grep -A3 '^\[tools\]' mise.toml
mise exec -- python --version
记录选择器 3.12 与实际输出的具体版本。两者不同层级是正常的。
步骤 2：显式生成 lockfile
mise lock
ls -l mise.lock
如果当前 CLI 报参数变化，先运行 mise lock --help，按本机版本的官方帮助调整；不要手写一个看起来合理的 lockfile。
步骤 3：按字段审阅，而不是只确认文件存在
cat mise.lock
至少查找并记录：
- 工具名与原始 specifier；
- resolved version；
- backend；
- 当前或目标平台键；
- URL、checksum、size、provenance 中实际存在的字段。
用表格写结论：
| 工具 | specifier | resolved | backend | 平台 | 可验证字段 | 缺口 |
|---|---|---|---|---|---|---|
| python | 3.12 | 以文件为准 | 以文件为准 | 以文件为准 | 以文件为准 | 不存在的字段如实写 |
步骤 4：运行 locked install
mise install --locked
printf 'exit=%s\n' "$?"
预期观察：当前已锁定且 backend 支持的工具成功安装，退出码为 0。locked 模式的价值不是让命令看起来更严格，而是在缺少所需 lock 信息时尽早失败。[S06]
19–25 分钟：用负向测试证明 strict 真的在工作
步骤 1：备份配置和 lockfile
cp mise.toml /tmp/mise-task-lab.toml.good
cp mise.lock /tmp/mise-task-lab.lock.good
步骤 2：添加一个未进入 lockfile 的声明
cat >> mise.toml <<'EOF'
[tools.ripgrep]
version = "14"
EOF
不要运行 mise lock，直接执行：
mise install --locked
status=$?
printf 'locked_exit=%s\n' "$status"
预期观察：对 strict 能覆盖的 backend，命令因新声明没有相应 lock 信息而非零失败。若它仍成功，不要硬写“测试通过”：检查当前 mise 版本、配置语法和 backend 支持表。官方文档说明有些 backend 无法报告 URL，strict 检查会跳过这些能力不足的 backend；这本身就是需要记录的覆盖缺口。[S06]
步骤 3：恢复，再走正确更新路径
mv /tmp/mise-task-lab.toml.good mise.toml
mv /tmp/mise-task-lab.lock.good mise.lock
mise install --locked
真实升级时应修改配置或运行受审阅的 bump 命令，再由 mise lock 重新生成并审阅 diff；不要手改 resolved version 或 checksum 来“修绿”。
25–28 分钟：处理跨平台与 task tools
本机生成成功不自动证明 Linux CI 可用。按目标矩阵检查：
- 写出项目实际支持的平台，例如
macos-arm64与linux-x64。 - 在
mise.lock中检查每个 lockable 工具是否有对应平台信息。 - 缺少平台时，使用当前
mise lock --help支持的平台参数生成，再审阅新增 URL/checksum。 - 检查 task 是否声明了 task-specific tools；官方 lock 命令也会读取 task 定义并锁定这些工具。[S06]
- 在 CI 目标平台运行 locked install，不能用本机文件检查替代实际验证。[S09]
Worked review
看到下面情况时：
node: linux-x64 有 URL + checksum
python: 只有 resolved version
正确结论不是“两个工具都完整锁定”，而是：版本解析都被记录；Node 的 Linux 工件可按 lock 信息验证；Python 当前 backend 的工件校验信息不足，需要按 backend 能力和 CI 风险补充控制。
常见失败与下一步：
mise.lock没生成：检查 lockfile 设置和mise lock --help，显式运行生成命令。- diff 突然升级多个工具：停止合并，核对选择器、缓存和 bump 范围；一次更新应能解释每个变化。
- macOS 成功、Linux strict 失败：查看 Linux 平台条目是否缺 URL/checksum，而不是关闭 strict。
- checksum 变化但版本没变：视为需要调查的供应链变化，不能自动当作无害格式更新。
28–30 分钟：检索问题
问题：为什么有 mise.lock 仍不代表所有供应链风险已解决？
作答后查看参考答案
backend 对版本、URL、checksum 和 provenance 的支持不一致；lockfile 也不处理发布者账号安全、工具内部依赖链、项目配置代码执行、secret 管理或运行时隔离。
通过标准
- 能从选择器追溯到 resolved version、backend 和平台信息。
- locked install 有一次成功和一次可解释的负向测试。
- backend 跳过的校验能力被记录为限制，而不是伪装成通过。
- 更新与跨平台策略说明谁更新、审什么、在哪里验证、怎样回滚。