build

实现所请求的功能。使用 twin 回答会影响此变更的问题，并测试应用。复用常规开发中的证据：所需行为得到覆盖并通过后，即可完成。只有在测试失败或存在尚未解答的具体要求时，才继续调查。

对于没有实质性供应商交互的变更，跳过 Veris 设置和 twin 工作；使用代码库的验证方式，并在结果中说明范围。 如果本地队列或缓存缺陷会改变面向供应商的行为，仍需使用 twin 测试受影响的应用流程。

使用现有工作设置

阅读 .veris/NOTES.md 中的相关发现，并复用仍适用的内容。按照 如何运行 中的说明进行准备、运行应用、收集证据和清理。设置流程负责选择连接和配置。 仅当缺少必要的交接步骤、连接中断，或变更导致连接配置失效（例如新增供应商服务或主机名）时，才运行 setup。 应用断言失败本身并不是重新运行设置的理由。

在由插件管理的会话中，按照 session.md 中的说明处理实时仓库与 twin 绑定以及提供商工具。复用本会话中已验证的绑定；重新连接或相关身份发生变化后，重新验证。仅有保存的元数据不代表存在实时绑定。保持插件拥有的资源运行。

仅在需要时使用已保存的启动／重新连接步骤，复用此任务的活动沙盒，并在长时间工作前检查其过期时间。通过已保存的准备步骤刷新即将过期的 URL 或凭据。

无法使用 twin 时，任何需要它的验证都无法进行。报告具体错误；可以继续独立的代码工作和本地检查。仅当错误表明情况可恢复或条件已有变化时才重试。不要将未运行的检查报告为通过。

理解并实现

保持读取内容和工具输出聚焦。将较大的日志或响应保存到文件，并检查相关摘录，避免反复将其加载到对话中。

阅读 issue（对于 GitHub，使用 gh issue view <ref> --json title,body,comments）或提供的提示词。确定所请求的行为、调用方及相关服务依赖项。在设计新流程前，先检查现有应用代码和测试。

对于会影响该设计且尚未解决的问题，使用成本最低的 twin 接口。twin.md 将问题对应到手册、架构、操作列表和数据。当需要了解凭据、API 版本或故障详情时，使用 veris sandbox services manual <twin> --raw 获取手册；阅读适用章节。直接探测 twin 有助于了解情况。通过应用进行测试也能回答同一问题，同时检查实现。对于相同条件下已确定的答案，直接复用。

使用 state.md 为功能准备所需状态。检查相关负责人和时间窗口，不要假定默认种子数据符合需求。例如，已全部预订的测试数据并不能否定预订其他日期的功能；不要为了适配种子数据而更改所请求的行为。

遵循仓库惯例进行实现，并扩展相关测试。当功能改变了故障处理方式时，使用 fault injection 测试相关条件。对于重试、幂等性或身份变更，在受影响的测试中加入适用的重复操作、不同操作和恢复场景；proof.md 提供了针对性方案。如果某项尚未解答的说法会影响决策，就进行调查；但不要等到列出所有可能的供应商问题后才开始修改源码。

测试任务承诺支持的调用方。对于可选功能，测试新增参数或标志，并保留现有必需行为。若相关的其他分派分支可能改变结果，也应覆盖这些分支。正常调用方永远不会走到的仅测试路径，不能证明该功能对这些调用方有效。检查实现相同行为的相关同级分支；搜索已更改符号的调用方可能会漏掉这些分支。

测试已更改的应用程序

使用 如何运行 中保存的执行和证据步骤，运行受影响应用程序的测试或流程。优先使用仓库现有的集成测试。按照文档选择受影响的测试或流程，同时保留已配置的环境和连接设置。

按照保存的源代码／构建配方，使用已编辑的源代码或由其生成的构建版本。挂载错误可能导致执行镜像中旧的预置代码。保留已配置的路由和 TLS 信任设置；不要为了让测试通过而更改生产环境中的供应商调用。

测试必须断言预期响应或持久化结果，其回执或可归因的跟踪记录必须显示相关应用程序流量已到达孪生体。读取结果的现有断言已足够；不要再用手动数据读取重复验证。如果结果不明确，请按照保存的证据流程，根据返回的 ID 检查相关行，或检查本次运行的跟踪记录。请参照该配置路径对应的说明解读回执／退出结果；如果任务包含回调，请使用 webhooks.md。

如果某次现有执行测试了最终相关代码／构建版本和条件，即可计入。一个测试套件可以覆盖多个要求；重试用例可以在一个测试中发起多次调用。无需再成功运行一次，也无需单独的验证阶段。遵守仓库要求的检查，并复用其证据；更改代码或检查失败后，重新运行受影响的检查。

如果断言失败，请更改实现，或修正已诊断出的设置问题。如果所需行为仍未经过测试，请报告这一缺口。进程成功退出或无关的孪生体流量本身，不能证明更改已得到验证。

完成

总结更改内容、测试／命令及其结果，并附上现有证据的引用，同时说明重要限制。evidence.md 展示了简短格式。如果调查发现影响解决方案的任务前提不成立，请注明。已知矛盾属于需要解决的缺陷，而非可接受的假设。

遵循仓库的 PR 约定；如果要求以草稿 PR 交接，请创建草稿。如果没有支持 PR 的远程仓库，请在本地保存描述，并说明未创建 PR。Git 历史、任务 ID 和可选的 审计辅助工具 都不是编写代码的前提。不要擅自初始化 Git 或添加远程仓库。如有助于调试，可使用现有的软件包／版本元数据；这不是单独的完成要求。

清理前保存所引用的脱敏证据，并遵守 .veris/setup.json 中现有的 artifact_policy。将新的可复用服务或 SDK 发现添加到 .veris/NOTES.md，并注明相关条件和现有脱敏证据的引用。修正过时条目，但不要重复任务报告。如果修复了 如何运行，请更新它。按照记录的生命周期负责人所对应的已保存清理或变更交接步骤操作；让插件拥有的资源保持运行。不要通过此命令执行推广。向新的位置发送仓库代码前，请先征求许可。