principle-build-the-lever

用途：这条原则适用于任何非琐碎工作，包括编辑、迁移、分析和检查。核心做法是：不要纯手工完成工作，而应构建能完成或证明这项工作的工具，例如 codemod、脚本或生成器。\n\n主要能力与做法：先手工完成第一个单元，从中总结出可复用的做法（recipe）；然后构建工具，再用该工具重跑这个单元，并与手工版本逐项比较差异（diff）来验证工具正确性。工具应能安全地重复运行。编辑用 codemod 或脚本，重复文件用生成器，分析可用 dump-to-sqlite 查询，验证用可重复运行的检查。\n\n确定性与分工：确定性工具优于把工作分派给多个子代理。如果工具能一次处理所有单元，就应直接运行它，不要分派子代理逐个手工套用脚本能完成的事。若确实要把工作分派给子代理，应把工具写成它们共同读取的技能文件，其中包含做法、验证约定和禁止修改的边界（do-not-touch fences），并放在子代理的写入范围之外，防止它们悄悄修改约定。\n\n判定标准：应用该原则应产出一个文件。如果引用了该原则，但改动（diff）中没有 codemod、脚本、生成器或子代理技能文件，就说明没有真正应用。只有当任务琐碎、只需几个一眼可见的明显编辑时才跳过。判断门槛是“是否琐碎”，不是“是否重复”；即使一次性任务，只要工具能让工作可检查，也值得构建。按 Laziness Protocol，应构建能完成或证明工作的最小脚本，而不是框架。\n\n适用场景与限制：适用于编辑、迁移、分析、验证等需要可重复、可审查的工作。原则本身强调：手工修改只能靠重做来再次验证，而确定性脚本能把“信任我”变成“运行这个”。它区别于“Encode Lessons in Structure”（把反复出现的指令变成持久护栏），重点在于当前工作的吞吐量和可审查性。若工作会延续到会话之后，应提交该工具（lever）。具体实现细节和编码方式暂未提供。