开发新功能

明确要做什么

把需求落成“什么人在什么条件下做什么动作，应观察到什么结果”。有现成失败、截图或参考实现时读取它；明确目标项目与参考材料的身份，防止把参考仓库改了。

读取项目规范、README 和相关脚本，确认修改范围，再从实际入口找现有链路和可复用模块；复用前检查其真实契约，不凭命名推断。需求不明确时先推进不依赖该信息的调查，再询问影响结果的关键差异。无须为每次小改写一份规格。

实现一条完整流程

优先打通一条完整用户路径：输入 → 状态/业务执行 → 实际输出，而非铺满所有抽象层再做演示。沿用现有栈和结构。记录必要行为与本次不涵盖的需求，不擅自扩展成平台重建。

对比可获得的参考实现时给出设计前提、值得复用的部分与应保留的现有能力；没有源码就只对可观察行为做判断。参考代码是证据，不意味着自动迁移其技术栈。

修改涉及配置、事件、provider、存储或进程边界时，从实际生产者跟到消费者，检查来源、优先级、缺失状态、错误传播和恢复行为，并用对应负向场景验证。触及支持语言、主题或平台时覆盖相应变化；项目不支持的能力不因本流程变成新需求。

验证用户结果

从项目真实入口执行最小用户任务，检查实际输出或持久化状态。按改动加入关键失败或边界场景，运行现有相关检查。开始时已失败的检查记录为基线，不能把它们静默忽略或归因于本次代码。