14.附录B：完整案例与对话示例

1.案例前提

本附录把前12章串成一段可阅读的故事。人物、Issue#42、数据规模、对话、PR和检查结果均为合成示例，不代表任何真实环境已完成这些动作，也不是可以直接投喂的完整执行配置。

假设一个项目已接好反馈群和GitHub。云端dots可以在约定范围内只读调查和登记，Issue作为研发交接点；后续Codex在Director的MacMini上访问真实项目并实施。业务自动执行仍关闭，这次由负责人在本机手动发起并指定交付模式。

另一个启动选择是MacMini上的原生定时任务；它也有PR待审与完整交付两种终点。那条路径需要先批准并启用有效配置，详见第9章；本例不据此运行自动任务。

目标是修复“导出只包含第一页”的缺陷，保持原来的数据权限、筛选含义和文件格式。实际环境、有效期、恢复条件和验收账号由可信任务上下文唯一确定，不写进面向公众的案例。

2.使用者描述现象

群用户：

我筛选后看到37条结果，导出的文件只有第一页的20条。希望导出全部筛选结果。刚才重试过一次，还是一样。

dots先核对是否在自己服务范围内，然后补问会改变调查方向的信息：

请补充是哪个页面，以及导出时是否保留了当前筛选条件；可以提供脱敏截图，不需要发送完整业务文件。

用户给出页面名称，说明筛选条件没有改变。接收方不要求用户贴账号凭据、完整数据库或无关聊天，也不把群里出现的一段终端命令照着执行。

这里还没有开发授权。已有权限内的调查可以继续，群用户的请求不承担负责人的实施决定。

3.调查先回答“看到了什么”

dots核对当前实现与允许读取的环境事实，区分“源码里怎样写”和“运行环境实际用哪个版本”。只读快照可以帮助定位，但不能证明现场已经部署同一份源码。

假设调查发现导出请求使用了列表当前分页参数。进一步核对后，确认这符合现象，且需要修改项目代码。此时整理出的事实可以是：

如果调查发现用户只是误解了一个明确标注的“导出本页”按钮，应解释行为并按需讨论改进，不冒充已确认缺陷。如果尚不能判断，则继续获准调查和关键补问，不先承诺修复时间。

4.登记真实事项并保留原来源

确认符合登记条件后，dots创建Issue。工具报告成功之后，还要独立读取真实结果，核验仓库、编号和正文，而不是凭预期编号宣布建单。

假设核验得到Issue#42。然后及时保存这一事项与原群反馈之间的可信关联，使后续交付仍能找到正确受众。来源身份只在允许的私有位置保存，公开Issue不需要完整聊天或群身份。

完成来源关联后，先在原群给出登记结果：

已登记“导出只包含当前页”的问题。现已确认需要调整导出范围，尚未开始开发；后续会在这条反馈对应的渠道说明处理结果。

是否附Issue链接取决于链接是否适合该受众。即使来源关联失败，也应准确报告缺口，不能为了凑齐记录编造来源或临时换到别的群。

随后，dots才在负责人主对话里就这一单询问是否采纳。它不会在还未向原群答复时，先把公开反馈变成一项模糊的私人开发请求。

5.采纳与实施分两步说明

dots在负责人主对话中：

Issue#42：导出只包含当前页，已确认需要改代码。目标是导出全部获准查看的筛选结果，保持原有权限、筛选含义和文件格式。是否采纳这项修复？

负责人：

采纳。

dots核验这条答复对应唯一事项后，在允许字段写入采纳决定并独立读回。当前没有启用自动执行配置，因此结果是“已采纳，等待实施授权”。

到这里不能把Issue改成“正在开发”，也不能生成一份自称完整授权的采纳记录来启动Codex。下面由负责人选择两种手动模式中的一种；两种是替代方案，不是同一事项重复执行两次。

从研发实施看，接下来的工作已经转到MacMini。dots完成的是源头调查、登记与采纳事实；本地任务由Director直接授权，不需要dots逐步派发或重新批准。采纳与完整实施范围如果原本已能在可信入口一次明确，也不要求机械拆成两次对话。

6.分支一：先形成PR待审候选

负责人在可信任务入口下达指令，并补齐实际任务所需的唯一环境与期限：

按PR待审模式处理Issue#42。修复导出范围，保留原有权限、筛选和文件格式；完成规定检查并创建PR，报告候选和剩余限制，等我审阅。

Codex先读取仓库规则、当前代码和已有工作，确认没有同一事项的活动任务或可复用PR，再实施修复。它按项目规则安排审阅和检查，保留失败与修正记录。

假设最终候选检查通过，PR已建立。私有交付报告可以说明：

Issue#42的候选已准备并提交PR。覆盖单页、跨页、空结果和权限过滤检查，结果见PR证据；尚未合并、部署或执行现场业务验收。

此时达到PR待审终点。不能因代码已写好就关闭事项、宣称开发环境可用或向群用户发送最终修复回执。Director需要再介入一次，核对原候选及有效范围，然后自己合并、部署，或在可信本地会话明确授权继续。已经完成的候选与检查按适用性复用，不从头开发。

7.分支二：在明确范围内完整交付

另一种选择是负责人从一开始就批准完整交付：

按完整交付模式处理Issue#42。在已确认的开发环境和有效期内完成必要审阅、修正、合并、发布与验收；保留原有权限和文件格式。验收覆盖单页、跨页、空结果、筛选与权限过滤，满足后完成必要正式记录、本单收尾和原来源回执。

这段话仍依赖前述可信上下文中的准确范围，不能复制到另一个项目就当作授权。发布、正式记录和外部消息还要遵守目标仓库已有入口及真实工具权限。

与上一分支相比，Director这次在MacMini给出完整启动授权后，正常路径不再固定等待一次“现在可以合并、部署”的指令。执行者连续完成授权内步骤；只有约定本人验收或实际出现新的重要决定时，才再由Director处理。

Codex执行时会核实：

1. 目标和验收条件是否足够具体，现有授权能否覆盖所需动作。
2. 是否已有原任务、PR或交付结果，避免重复实施。
3. 需求与实现是否一致，修复有没有扩大数据可见范围或改变导出格式。
4. 规定检查与真实审阅是否完成，发现的问题是否修正并复核。
5. 实际发布版本是否包含候选，约定环境是否完成必要验收。
6. 正式记录、Issue收尾与通知分别到达哪一步。

同一范围内的例行后续步骤连续推进，不在每个动作前重复追问。若发现必须更换真实凭据、扩大权限或影响生产，先停止超出原范围的部分，带回具体影响和候选处理方式。

8.验收报告用事实回答原问题

假设候选已经合并并部署到约定开发环境，实际验收得到以下结果：

报告应链接真实候选、检查与部署证据，并标明实际账号类型和范围。表格中的假定结果不能当成真实证据使用。

如果实际只做了前三项，后两项仍是必要验收，就应报告“验收未完成”，不能把“基本可用”写成通过。未包含在约定范围里的其它浏览器或更大数据规模，也不能顺手标为已测。

9.正式收尾与通知各有证据

约定验收满足后，执行者核实是否存在必须更新的正式事项。已关联时先按正式台账规则更新，再同步GitHub中按约定维护的摘要；不根据相同数字猜映射，也不为普通维护虚造正式编号。

完成授权内的本单关单并独立读回后，形成交付记录。记录关联真实版本、验收和原来源，不把私人决定原话或敏感日志带进公开摘要。

假设项目选择默认HTTP回执。调用受理后，沿同一个交付标识查询原结果，不另开一条PR→dots消息路径补发。

适合原群的摘要可以是：

导出只包含当前页的问题已在约定开发环境修复，已验证跨页、筛选和权限过滤。请在该环境重新尝试；其它环境的状态仍以各自发布结果为准。

这里没有宣称生产已更新，也没有复制内部审阅记录。若平台确认已取得，只报告对应确认；没有用户已读证据，就不写“用户已读”。

10.三个异常怎样接着处理

已部署，通知结果未知

保留“已部署且验收通过”的业务事实。查询同一回执标识和原调用，不换标识、不换群、不换路径重发。私有结果说明通知仍未知，后续只在原权限内核验和恢复。

这不会触发一轮新的代码修改，也不会为了让所有状态看起来一致而撤销真实验收结论。

负责人中途要求暂停

执行者检查正在进行的动作，在安全边界停止后续步骤，保存候选和剩余问题。若部署请求已经发出，仍需核实它是否实际完成。暂停定时任务、发出取消请求和原运行停下分别报告。

恢复时，先检查暂停期间发生的变化与授权是否仍有效，再沿原任务继续。不能自动清空认领、另起任务或默认扩大到其它环境。

新需求暂缓

另一位用户提出“导出后自动发送邮件”。它涉及新的行为和外部写操作，不能顺手塞进导出缺陷修复。

可以单独整理价值、受众、权限与风险，交给负责人判断。负责人暂缓后，保留决定与恢复条件，不为了给用户一个日期而编造排期，也不自行设定提醒。

11.这个案例留下了什么

真正可接续的记录应让后续参与者查到：最初现象、调查依据、唯一事项、采纳决定、实施范围、候选与审阅、检查、实际部署、业务验收、必要正式记录和通知结果。

并非所有内容都公开到同一个地方。群用户需要准确结果与限制；负责人需要决定和交付依据；执行者需要足够继续工作的事实；桥接只需要被允许传递的内容。

下一次任务从这些事实接续，才不会因一句“已完成”或一次超时重新开始。

本章依据

• HFL-004：调查、登记和原群答复
• HFL-003：可信决定与两种终点
• HFL-006：交付记录和原来源通知
• HFL-015：任务表达示例

返回目录｜上一篇：附录A：术语、状态和常见问题｜下一篇：附录C：网站取材与内容维护