07.手动研发：选择PR待审或完整交付

1.先决定这次结束在哪里

HiveFlow的手动研发有两种明确终点：PR待审和完整交付。它们帮助负责人一次说清预期结果，避免工具做完代码就停下，也避免只请求审阅却继续合并部署。

本章说明Issue交接到MacMini之后，Director手动发起本地Codex任务的做法。第9章的本机原生定时任务也使用相同两种终点；“手动／定时”与“PR待审／完整交付”是两组独立选择，不能把手动等同于PR、把定时等同于完整交付。

选择	适合的情况	结束时交付什么
PR待审	负责人希望先看实现，再决定后续	已检查的候选、真实PR、影响与剩余项
完整交付	目标、环境、风险和验收已明确，希望连续推进	真实审阅、合并、约定环境交付与验收、必要记录和通知结果

未指定模式时，沿用这次实际批准范围，不能把“处理这个Issue”自行扩成全链路授权。

实施者先核验规范版本、项目根规则、真实仓库、完整提交、分支和工作区差异，再看相关Issue、PR和已有任务。

工作区有他人改动时，先区分来源和文件范围，按需要使用隔离工作树。worktree是同一Git仓库的独立工作目录，可以减少文件互相覆盖，但不会自动防止两个任务处理同一Issue。

别人可能已经完成一部分工作，或者通过另一个Codex会话实施。可见记录不足时，先查实际提交、检查、部署与验收证据；不因为缺少dots记录就重建同范围任务。

HiveFlow说明事项怎样进入研发，具体实现仍遵守目标仓库的工程规则。已有设计明确的缺陷就修实现；重要产品变化需要必要需求与设计；低风险维护不为套流程补造对象。

是否需要独立评审、专门实施记录、PR或数据库验证，依据仓库规则和实际风险判断。本章的两种模式只规定已选择任务的终点，不能降低这些要求。

先运行离修改最近的检查，再按实际差异进行必要的统一验证。测试失败要诊断和修复，不能临时删有效断言或降低门槛使候选通过。

在授权内完成实现、相关检查、提交推送和创建PR后，报告“PR待审”。报告应能让负责人判断改了什么、检查了什么、还没有完成哪些交付阶段。

例如：

导出范围判断已修正，相关回归与规定检查通过。PR已建立，候选提交和检查证据已关联；当前等待审阅，尚未合并或部署。

这时不生成最终完成记录，也不发“已经可用”的原群回执。后续合并、部署或正式收尾，要有仍适用的实际授权，不能为凑成完整交付自行追加。

因此，手动PR待审通常需要Director在本地作两次决定：第一次发起任务，第二次在PR完成后决定并推进合并、部署。第二次可以由本人操作，也可以在可信本地会话明确授权继续；不需要把任务转回云端dots。

当负责人已经明确完整范围，实施者连续推进：

这些步骤属于同一项已经明确的任务，不在每一步重新申请相同许可。检查失败、必需评审不可用、部署入口拒绝或风险变化时，仍停止相应后续阶段。

正常路径中，Director在MacMini启动时给出一次完整授权，之后接收结果即可；规定审阅和验收由获准执行者真实完成。约定需要Director亲自验收，或出现必须由本人决定的新影响时，再处理对应事项。这与PR待审之后固定等待本人决定后续不同。

修正不能只刷新PR里的说明。影响了代码或测试，就运行受影响检查，确保最终证据对应真实候选。

目标分支在任务期间变化时，比较相关文件、依赖、构建、部署、规则和验收影响。证据表明无影响，可以记录新旧基准继续；有实质影响或无法判断的部分，先核对再推进。

不能仅凭提交标题写着“文档”就认定无影响，也不因出现任何新提交就一概推翻原授权。判断对象是具体差异及其实际影响。

部署前核对准确目标、当前版本、兼容性、必要备份及恢复方案。环境简称需要从可信环境文档定位，不能从事项正文里的地址猜目标。

部署后，进程健康和HTTP响应只是检查的一部分。约定的导出验收还应核对原操作、预期结果、指定版本和测试范围。证据分别记录，失败或缺失时保留真实待办。

恢复也只沿已批准且安全的方案进行，保护部署后的新增数据。不要因为检查失败就拿旧快照盲目覆盖现场。

结果先说明达到的终点，再给必要依据：

Issue满足条件可以结束，并不使关联REQ自动满足正式版本和Git标签的结束条件。通知失败也不会否定已完成的业务交付。把这些事实分开，下一次接续才有明确起点。