development-task-understanding

name	development-task-understanding
description	通用开发生命周期的「任务理解与现状调查」阶段 owner；当需要理解用户输入、明确目标、成功条件、影响面、当前链路或根因时使用，负责形成可决策证据，不负责主动发现新需求、冻结方案或修改实现。

Development Task Understanding

目标

回答“用户当前要解决什么问题，系统实际是什么状态”。从用户输入和指出的入口沿相关事实找到足够完整的证据，避免按文件名、单个调用点或局部截图外推系统结论。

本阶段理解和校准已经进入任务上下文的输入，不主动从产品愿景、使用信号或市场信息中发明新的需求。调查中发现的相邻机会只记录为范围外信息，不扩张当前任务。

进入

标准开发任务开始时轻量进入；用户明确要求研究代码、查清现状、追完整链路、调试复杂故障、分析根因，或局部证据不足以支持下一步时正式展开。

先冻结：

• 用户或系统可观察问题；
• 期望行为和成功条件；
• 范围、非目标和约束；
• 当前已知事实、假设和未知项；
• 最近 owner、影响面和 L0-L4 风险。

调查顺序

1. 明确判断对象和会改变的下一步决策。
2. 读取对象本体，记录它实际产生、保存、转换或消费的事实。
3. 用 rg 查调用方、被调用方、同类入口和规范事实源。
4. 沿最近完整链路核对 producer -> owner/state -> boundary -> consumer。
5. 扫同 owner 或责任链的同类问题，但不无界扩张到全仓库。
6. 区分已确认事实、合理假设和仍需验证的未知项。
7. 判断路径是否显然，还是存在会改变用户体验、owner、复杂度或验证方式的真实设计空间。

每次新增调查必须改变一个设计、实现或验证决策；已确认且未变化的长文件、日志和命令输出不得重读。

外部协议按具体端点和操作逐项取证，不能用一个成功端点或“兼容”宣称外推其它能力。有状态机制要分别核对触发、输入、状态替换、持久化/恢复、失败重试和测试证据；registry/catalog 投影要对照 canonical 来源核对覆盖面。

条件方法

• 跨多 hop、runtime、transport、异步边界，或真实复现昂贵时，读取链路切片。
• 用户要求系统根因、事故复盘或机制沉淀，且已有足够直接证据时，读取根因分层。

普通任务理解不读取这些参考；一次只选择当前需要的一种方法。

输出

• 需求、范围、成功条件和风险；
• 已查 producer、owner、boundary、consumer 范围；
• 已确认事实、仍待验证假设和证据缺口；
• 路径是否显然、是否需要正式设计；
• 推荐下一阶段、继续调查或不改，以及原因。

本阶段不冻结实现方案、不编辑产物、不执行最终验证，也不枚举并加载所有可能的专项 skill。