fix

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

如果此次变更不涉及有意义的供应商交互，则跳过 Veris 设置和 twin 工作；使用仓库的验证方式，并在结果中说明范围。 会改变面向供应商行为的本地队列或缓存缺陷，仍需针对 twin 测试受影响的应用流程。

使用现有工作设置

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

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

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

如果 twin 不可用，依赖它的验证就无法进行。报告具体错误；独立的代码工作和本地检查仍可继续。仅当错误表明问题可恢复或情况有所变化时才重试。不要将未运行的检查报告为通过。

诊断并实现

让读取内容和工具输出保持聚焦。将大型日志或响应保存到文件中，并检查相关片段，而不是反复将其加载到对话中。

阅读问题（GitHub 问题可使用 gh issue view <ref> --json title,body,comments）或提供的提示词，然后检查受影响的代码。确定报告的结果，以及修复应实现的行为。问题中提出的原因可能有误；孪生环境的可注入故障列表并不能决定对代码库的诊断。

尽可能复用现有的相关失败案例，或通过应用复现问题。若缺陷取决于供应商故障，请使用故障注入；若缺陷涉及本地状态、缓存或队列，则应在应用中复现。如果观察结果与诊断不符，请修正诊断。不要通过暂存修复来伪造历史上的失败运行，也不要仅为记录时间顺序而重新开始工作。如果未复现原始故障，请说明这一点，并验证已实现的行为。

对于尚未解决的服务问题，使用成本最低的孪生环境接口：

• 手册/架构：查看凭据、支持的故障和字段规则。需要这些信息时，使用 veris sandbox services manual <twin> --raw 获取手册；只阅读相关部分。
• 数据和播种：查看应用所需的状态。复用合适的种子行；ID 属于此沙盒。缺少测试夹具是设置问题，并非对报告缺陷的复现。
• 直接调用孪生环境进行探索；这只能确认孪生环境的行为，不能证明应用正确性。如果有用的应用测试能回答同一问题，就不必单独进行探测。

按照代码库的惯例实现，并在适当时加强受影响的测试。对于重试、幂等性或身份相关的更改，请在该测试中覆盖适用的重复操作、不同操作和恢复行为；详见验证指南中的针对性方案。测试任务承诺要修复的调用方，包括相关的分派分支。绕过真实调用方的仅测试选项，无法证明该调用方的行为。

检查实现相同行为的相关同级分支，即使它们是内联实现的；搜索更改后符号的调用方，可能会漏掉这些分支。

测试已更改的应用程序

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

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

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

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

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

完成

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

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

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