带证据交付并让下一会话接得上
“代码改完了”不是 DevCodex 的完成定义。这个教程把验证、剩余风险、报告和续接状态一起交付。
你将完成什么
- 让每个强结论都能回到新鲜证据。
- 区分已验证、未验证和不适用。
- 留下下一会话可以恢复的任务状态。
前置条件
任务已有确认过的验收条件和实际修改。列出本次允许执行的测试、无法访问的外部环境，以及是否需要人工发布授权。
发送这条请求
预期工作流
DevCodex 会对照原需求、技术方案和实际 diff，选择与风险匹配的测试路线，检查关联文档与消费者，并执行 ECR。需要跨会话时进入 resume，读取有界记忆和报告锚点，而不是重做全量分析。
写入边界与确认
测试和报告不能替代发布授权。commit、push、PR、部署或生产写入仍按任务授权执行；文件、删除与命令权限由宿主及其用户配置决定，DevCodex 不签发第二套操作批准令牌。无法直接验证的宿主或外部系统必须保留为 UNVERIFIED。
可见结果
完成卡应至少说明：
- 实际修改与未修改内容；
- 验收项和对应证据；
- 运行命令、退出码与失败项；
- 剩余风险、回滚和人工步骤；
- 报告、记忆与下一步任务锚点；
- 与交付文件分开的条件式下一步：没有真实差额时不制造建议，有差额时最多给出一个主动作和两个条件动作。
接口文档、.http 验证、commit、切换目标分支、按 commit ID cherry-pick 和 push 都可能成为下一步，但只能由验收差额、Profile 与当前授权边界共同决定。接口文档或 .http 若已是本次验收要求，就属于当前必做项，不能挪到完成后的建议；commit、cherry-pick 与 push 仍分别授权。
如果下一会话仍然丢上下文
- 检查任务是否写入了报告和绑定会话记忆，而不只是聊天摘要。
- 使用明确的任务名或续接入口，不要依赖模型猜测“上次那个任务”。
- 若 Profile 或 memory 状态冲突，先按故障排查恢复，再继续写入。
下一步
了解证据与完成和 resume 工作流。