ship

Ship

目标

将变更放入干净、经过审查且可合并的 PR。由用户合并。

变更可以是工作树中已有的本地修改、Linear 工单，也可以是对要构建内容的描述。

步骤

1. 如有必要，实现变更。 如果工作树中已经有这些修改，请转到第 2 步。如果之前已经商定了方案，就按商定的方案实现。在基于 main 的全新工作树中工作。如果你已经在这样的工作树中，就继续使用它；否则，创建一个。将完整变更作为一个整体在本地实现。暂时不要考虑 PR。确保完整变更能够正常工作。
   • 如果工作树中有来自 probe 技能的存根，它们就是已商定的架构。在此基础上实现细节。不要更改其结构。如果实现要求更改结构，请告知用户。
2. 将变更拆分为一组 PR。 只有在完整变更正常工作后才进行此操作。首先，如果已安装 deslop 技能，请在工作树上使用它。它会移除 AI 生成代码的模式，让审查者看到整洁的代码。每个 PR 都只做一件明确的事。如果拆分简单明了，告知用户拆分方式后继续。如果变更复杂，或有多种拆分方式，请等待用户批准拆分方案。如不确定，请等待。使用下方的堆叠拆分指南。
3. 打开 PR。 附上变更前后的证据。如果有来自 reproduce 技能的证据，请附上，因为它能展示更多内容。否则，附上可见变更的截图。
4. 进行审查循环。 只使用 Codex 和 Devin 的审查结果。根据下方的审查分类处理每项发现。将每项忽略的发现记录在 PR 上。按约每 10 分钟一次的定时检查，重新检查 PR。不要等用户来提醒。CI 通过且最新发现都属于忽略项时，停止循环。不要只为获得审查者的干净结果而推送小改动。循环停止后，移除定时检查。
5. 报告。 审查循环完成后，向用户提交最终报告。

堆叠拆分

• 按功能拆分，而不是按代码结构拆分。
• 将辅助函数放在第一个调用它的 PR 中。不要创建只添加脚手架代码的 PR。
• 拆分前，保存完整变更的快照。然后从该快照开始，逐个创建分支。
• 每个 PR 都必须在其父级基础上通过检查。
• 完成后，将整个 PR 堆栈的差异与快照比较。两者必须完全一致。
• 使用带有 gh stack 扩展的 GitHub 堆叠 PR。如果未安装该扩展，请安装。如果此代码库不支持堆叠 PR，使用一个 PR 即可。

审查者信号

• 每次推送后都会自动开始审查。不要请求审查。
• Codex 在审查进行中时，会在 PR 描述中添加 👀。
• Codex 发现问题时，会发布审查评论。
• Codex 未发现问题时，会在 PR 描述中添加 👍。有时它也会发布评论，说明未发现问题。
• Devin 会通过审查评论发布其发现。
• 如果推送后没有开始新的审查，说明变更太小，不值得审查。上一次的结果仍然有效。

审查分类

这些产品大多处于 MVP 阶段。审查者会把每个产品都当作大型成熟系统。

• 修复真实错误、数据丢失问题，以及攻击者可利用的安全漏洞。始终保护资金和敏感数据。
• 忽略不切实际的情况、过度防御性的修改和无障碍问题。例如，忽略同一用户在不同标签页或设备间的竞争情况、产品当前并未达到的规模、对不存在的数据或调用方的兼容性、可选的安全强化以及小问题。
• 暂缓需要大规模重新设计才能修复的真实错误。不要自行修复。

最终报告

使用 ASD-STE100 撰写报告。

1. 暂缓处理，等待你决策。 对于每项暂缓处理的发现，说明问题、问题发生的可能性，以及修复范围。
2. PR。 提供每个 PR 的链接和状态。
3. 已修复。 对于每项已修复的发现，说明问题和提交。
4. 已忽略。 对于每项已忽略的发现，说明问题和原因。

规则

• 不要打开草稿。
• 每项修复都要作为新的提交。不要修改已有提交。只有通过堆栈变基才能强制推送。
• 不要合并。
• 除非用户告知，否则不要更改 Linear 工单的状态或评论。