设了 LOOM_MAX_PERMUTATIONS / LOOM_MAX_DURATION，模型照样跑满

主线位置：主线 1 里 Builder::check 的主循环。两个上限和写 checkpoint 放在同一个 if 里（model 与 Builder）。

flowchart LR
  i["第 i 轮开始"] --> c{"i % checkpoint_interval == 0"}
  c -->|否，默认 19 999 / 20 000 的轮次| run["直接跑这一轮"]
  c -->|是| chk["写 checkpoint；i >= max_permutations？超时？→ return"]
  chk --> run

现象

CI 里想给 loom 测试设个上限，LOOM_MAX_PERMUTATIONS=1000 或 LOOM_MAX_DURATION=60，结果小模型照样把所有交错跑完，大模型远超 60 秒才停。没有任何报错或提示。

最小复现

E4（model 与 Builder，exp-loom/runtime/tests/builder.rs）：3 个线程各对同一个原子做两次 fetch_add，上限 3，共 720 个交错。

第三行是反向验证：上限本身是生效的，只是检查得太少。停在 99 而不是 10，是因为第一次检查在 i = 100 这一轮开始前。

源码出处

model.rs:164-189：max_permutations 与 max_duration 都在 if i % self.checkpoint_interval == 0 里面，默认 checkpoint_interval 是 20 000。字段文档只说「Maximum number of permutations to explore」，没有提这个粒度。

另外两点：上限到了是 return，模型算通过，不是失败；时间上限的单位是整数秒（Duration::from_secs），写 0.5 会在 Builder::new 里解析失败直接 panic。

怎么改

• 要让上限生效，同时把 LOOM_CHECKPOINT_INTERVAL 调小：例如 LOOM_MAX_PERMUTATIONS=5000 LOOM_CHECKPOINT_INTERVAL=100，最多多跑 99 轮。没开 checkpoint feature 时，间隔只用来决定检查时机，不写文件（设了 LOOM_CHECKPOINT_FILE 才写）。
• 想控制 CI 时间，更直接的办法是 LOOM_MAX_PREEMPTIONS=2：它缩小的是探索范围本身，交错数可以预先测出来（抢占上限与剪枝）。
• 记住上限到了会「通过」：用 LOOM_MAX_PERMUTATIONS 截断的运行，不能当作完整的一次检查来报告。

小结

• 两个提前结束的上限只在 i % checkpoint_interval == 0 时检查，默认每 20 000 轮一次。
• E4：上限 10 在默认间隔下跑满 720 个交错；间隔 100 时停在第 99 个；0 秒的时间上限在间隔 1 000 下也跑满。
• 上限触发时模型算通过；时间上限只接受整数秒。
• 改法：一起调小 LOOM_CHECKPOINT_INTERVAL；控制时间优先用抢占上限。