用途：在使用 Cursor 开发功能时，强制走“构建→审查→测试→修复”的纪律化循环，避免仅凭“能编译”就交付。
工作来源：若仓库存在计划文件（如路线图、重构计划或带 - [ ] 复选框的任务列表），先做第一个未勾选任务；在 ProductOS 仓库中计划文件为 docs/ROADMAP.md、docs/REFACTOR.md，以及用户要求安全修复时的 docs/SECURITY-AUDIT.md 中的 Fix plan；docs/PLAN.md 与 productos/*-CHECKLIST.md 不是构建计划，应忽略。任务顺序有意安排，不得跳过；计划引用规格文档时只读当前任务相关章节。若无计划或请求超出计划，则依据用户提示构建，先用一条消息把请求复述为可验证目标并给出 2–4 条成功标准、确认范围。
循环步骤：构建时严格按任务实现，采用满足需求的最简实现、外科手术式改动、不做投机性扩展，并遵循项目既有约定。审查时对改动运行 Cursor 的 /review；若涉及认证、支付、用户输入或数据访问，再跑一次聚焦安全的审查（检查注入、授权缺口、密钥泄露、不安全输入处理），或让已配置的 Bugbot 审查 PR；修复范围内所有发现，若项目有设计系统规范（设计令牌文件、DESIGN.md、主题配置），UI 改动需对照检查，不得硬编码颜色、字体或间距绕过令牌；未触及代码中的既有问题记录到报告而非静默修复；重复 /review 直到干净；若发现与任务或规格冲突，以规格为准并标记分歧。端到端测试时运行任务的验证步骤或成功标准，跑完整测试套件确保此前通过项仍通过，为新逻辑补测试，并像用户一样实际运行应用走真实流程，覆盖空、加载与错误状态。修复时任何测试发现都回到循环：修复→/review→重测；不得把失败任务标记完成，也不得在应用损坏时开始下一任务。继续时勾选任务 - [x]、更新计划中的进度/状态行，循环至请求范围完成。报告时说明构建内容与计划进度、已修复与延期的审查发现、验证方式（测试与流程走查）以及需用户关注的事项，对不稳定或仅部分验证的内容如实说明。
规则：跳过审查或未测试的工作等于未完成；不要重新争论计划决策，若任务看似有误，提一个具体问题而非猜测；发现无任务覆盖的工作应提出并建议新任务，不得静默扩大范围。