功能开发容易过度构建时：按架构优先交付端到端窄结果并明确停止…

适用于新增行为、产品切片或集成，且需要复用仓库、严格控制范围并用可观察验收决定何时停止的功能开发。

适用场景

解决思路

1. 以 Native Core 的架构优先简单性为强制约束，把功能转化为一个完整但狭窄、贴合现有系统的交付结果。
2. 从请求和代码仓库中推导可观察的验收标准，并明确写出非目标。
3. 沿着入口点追踪到各层，识别谁拥有不变量与核心约束。
4. 在相关责任层之间交付连贯的端到端路径；不要强行把工作塞进一个文件、直接表达式或局部补丁。
5. 复用合适的接缝或边界；当补丁会重复行为、削弱所有权或掩盖根因时，进行重构。
6. 除非验收需要，否则省略模式、供应商、配置、扩展性和打磨。
7. 仅因生命周期设计或验收需要，才增加接口面、依赖、服务、配置或迁移，并说明实质性权衡。
8. 保持工作可运行；保留 Core 安全约束。
9. 实际走一遍路径，运行聚焦的证明或验证；当验收通过时停止。只报告实质性遗漏和触发条件。

适用边界 · 注意事项

• 需求尚不明确、需要先做探索性原型或技术 spike，无法提前定义可观察验收和非目标时。
• 任务本身就以引入大量模式、供应商、配置、扩展点或打磨为目标，且这些不能被验收标准省略时。
• 变更无法保持可运行，或需要破坏 Core 安全约束才能完成时。