build-loop-codex

Codex 构建循环

质量门控的功能工作：没有什么是“能编译”就交付的——每一个增量都经过构建、审查、端到端测试和修复，然后用户才会听到“完成”。

工作来源

存在计划文件（路线图、重构计划或带有 - [ ] 复选框的任务列表——搜索仓库）：处理第一个未勾选的任务。任务是有意排序的——绝不跳过。如果计划引用了规范文档，只阅读与当前任务相关的部分。
没有计划（或请求超出计划范围）： 根据用户的提示构建。将其重述为可验证的目标，包含 2-4 个成功标准，并在构建前用一条消息确认范围。

循环

每个任务（或每个提示的功能）运行。在每一步通过之前不要前进。

构建。 精确实现任务指定的内容。满足它的最简单实现，外科手术式更改，没有投机性范围。匹配现有项目约定。
审查。 运行 /review 并选择 “审查未提交的更改”。如果更改涉及认证、支付、用户输入或数据访问，通过 “自定义审查说明” 进行第二次检查（例如“关注安全漏洞和未验证的输入”）。修复所有范围内的发现——错误、安全问题、边缘情况、性能、你修改的文件中的样式。如果项目有设计系统规范（设计令牌文件、DESIGN.md、主题配置），检查 UI 更改是否符合它——没有绕过令牌的硬编码颜色、字体或间距。注意未修改代码中的既有问题，在报告中说明，而不是静默修复。重新运行 /review 直到干净。如果发现与任务或规范矛盾，规范优先——标记分歧。
端到端测试。 运行任务的验证步骤（或成功标准）。运行完整的测试套件——之前通过的所有测试必须仍然通过。为新逻辑添加测试。然后像用户一样使用功能：运行应用，走真实流程，包括空状态、加载状态和错误状态。
修复。 测试发现的任何问题都回到循环中：修复 → /review → 重新测试。永远不要将失败的任务标记为完成；永远不要在应用损坏的情况下开始下一个任务。
继续。 将任务标记为 - [x]，更新计划中的任何进度/状态行，并循环到下一个任务，直到请求的范围完成。
报告。 完成后，告诉用户：构建了什么以及计划进度，修复的审查发现以及任何推迟的内容，如何验证（测试 + 走过的流程），以及接下来需要他们注意什么。对任何不稳定或部分验证的内容要诚实。