上下文核对与复用
用于定位改动、核对当前行为的实现条件并安排验证。沿用已有决定与证据，识别缺口后只暂停依赖它的工作，不以文档数量判断是否可以开工。
找到会改变实现的信息
从任务对话与共同记录核对：当前行为的目的、触发与完成结果是否明确，关键状态和副作用是否有人负责，失败后能否处置。只展开本次调用链涉及的条件；明确的简单改动可以直接实施。旧设计和测试也可能有错，核对决定与代码现状是否冲突。
缺少函数位置、版本或配置主动查；缺少会改变业务行为的决定，用 product-design 梳理后向用户澄清；跨组件机制或恢复条件缺少依据，用 engineering-design 解决或安排受控探查。将未决项的影响与下一步写回共同记录，不在代码默认值或测试断言里替用户作决定。
读取相关上下文
沿相关调用链查看入口、规则、数据与外部依赖，按任务选择材料：
- 接口修改：现有路由、DTO（传输数据结构）、响应与错误约定、调用方和契约测试。
- 持久化修改：实际模型、迁移、索引约束、事务用法与代表性数据。
- 公共能力修改：检索现有日期、鉴权、日志和工具函数，确认语义匹配后复用，不仅凭同名复用。
- 依赖或构建调整：锁文件、运行时版本、脚本和 CI 配置，不凭记忆猜 API。
不要求每次通读所有 Entity 或 Utils。保留他人未提交改动；编辑共享文件前核查当前内容。
按风险安排改动
按依赖与失败代价安排切片和反馈。跨模块或迁移风险较高时，先简述需要验证的假设、关键异常及进入真实环境前要取得的证据；正常路径与恢复责任一起考虑。局部问题在最小影响面内验证，不要求固定四步或逐文件排期。
需要真实凭证、计费、生产数据或重启用户服务的验证先核查授权，优先使用隔离环境，不为补上下文越过权限。