工程实践

把任务做成可检查的代码改动，依据影响范围选择实现、调试和验证方法。开工先核对当前行为所依赖的产品决定与技术条件；已有依据直接复用，缺口先补判断或探查，不以用户说“实现吧”替代这些条件。

边界与协作

共同原则使用 software-lifecycle-principles；这里聚焦上下文复用、编码、诊断和验证。

• 读取与改动相关的实现、约定、依赖和测试，复用已有能力。行为目的或关键政策缺失时用 product-design；机制、状态责任或恢复条件缺失时用 engineering-design。能查到的信息主动查，只澄清会改变做法的缺口。
• 各角色直接在任务指定的共同位置维护决定、变更依据和证据，不另写独立交接文档。优先复用已有任务位置；简单任务可在对话中记录，确需持久记录且位置不明时再明确位置，不为记录另设开工门禁。
• 下游可以质疑和纠正需求、设计及测试中的错误。范围内自主选择实现细节、局部重构和验证方法，更新共同记录，不为每次修改向上游报批。
• 技术疑点影响边界或正确性时使用 engineering-design 的相关方法，不要求整套重新设计。涉及目标、重要范围、业务承诺、安全边界或不可逆操作的变化，先请用户确认，期间只暂停依赖该决定的部分。

按当前问题选择

当前需要	方法
找到修改位置、复用代码、检查信息是否足够	上下文核对与复用
实现或重构代码，划分职责并选择验证方式	断言先行与小步构建
运行失败、依赖不通或实现推翻原假设	调试取证与现实冲突
判断改动是否可交付、检查证据与剩余风险	验证与交付

方法按风险组合，不要求依文件编号执行。交付代码与必要验证结果，如实说明未运行的检查、未知行为和阻碍。可从实现与验证片段示例摘取到共同记录，不要求填完清单或另建报告。