用途：在存在明确正确性边界、且有一个可测量成本需要最小化的场景下迭代改进产物。典型是重构有测试套件的代码模块以降低复杂度，或调优结果集固定的 SQL 查询以降低延迟。不适用于加功能或修 bug，因为那会改变行为，而该循环正是要禁止行为变化。
主要能力：采用评估器-优化器循环，反馈信号分两部分——必须通过的门禁（行为/结果不变）与必须下降的度量。每次只做一处聚焦改动，检查门禁、测量指标，仅当门禁通过且指标改善才保留，否则回滚。内置两种绑定（均随附、仅用标准库）：code 模式门禁为 <gate_cmd>（测试套件）退出码 0，指标由 tools/metrics.py 输出 complexity（主）、max_nesting、loc（字典序决胜），越低越好；sql 模式门禁为 tools/bench.py 的结果集哈希与基线一致，指标为同一工具的 median_ms，越低越好。
使用方式：先解析绑定。若工作目录存在 loop.run.yaml 则加载并一行确认后进入循环；否则先选 <mode>，再推断各绑定值并确认，写入 loop.run.yaml 后再创建其他文件。关键绑定包括 <mode>、<editable_files>、<gate_cmd>、<metric_cmd>、<sandbox_root>（默认 ./sandbox）、<budget>（默认 8）、<patience>（默认 3）。循环步骤：迭代 0 跑基线并记录；快照可编辑文件；做一处改动；检查门禁；失败则回滚；测量指标并与最佳比较；保留或回滚；追加台账行；停滞或达预算即停。停止时把工作文件恢复到最佳迭代并报告基线对比、轨迹与获胜改动集。
限制：只能编辑 <editable_files>，门禁的基准（测试与 tools/metrics.py、数据库与 tools/bench.py）只读，改动度量工具会使运行失效。门禁不可协商，失败即回滚。每轮只改一处以便归因。保持现有依赖集，不新增项目没有的导入（标准库可以）。沙箱自包含，不得越出 <sandbox_root>。循环开始后不暂停询问是否继续。sql 模式哈希基于行多重集，不检测行序变化，若 ORDER BY 属于契约需人工确认。