---
name: development-implementation
description: 通用开发生命周期的「开发实现」阶段 owner；当目标、证据和适用设计已经明确且需要修改产物时使用，负责以单一路径完成实现和迭代检查，不负责最终验证、Review 或交付发布。
---

# Development Implementation

## 目标

回答“如何按照已确认目标和设计，以最小、清晰、单一的路径落地”。进入时必须已有可观察结果、最近 owner、影响面、风险和最小验证标准；证据或设计不足时返回相应返工阶段。

standard 或正式 bugfix 设计还须有 design-review: passed 及预定验收标准；trivial/内联修复须有明确跳过依据与判定条件。不把设计自审或实现后的测试当作方案 Review。

## 实现前检查

首次实质编辑前直接回答：

1. 能否删除、复用或收敛已有路径？
2. 事实、状态和生命周期的 owner 是否正确？
3. 是否新增无当前调用者、只服务未来可能性的 type、interface、方法、配置字段，或无语义 wrapper、adapter、factory、proxy、参数搬运和第二入口？命中时不得边写边扩张，返回设计收窄范围。
4. fallback、兼容和恢复是否位于真实边界，并有可观察信号和退出条件？
5. 是否新增、移动、重命名文件或改变目录角色？命中时先检查项目文件组织规则，并在编辑前运行项目已有的 planned-path preflight；没有该入口时至少核对目标路径和职责边界。

每开始一块工作，核对适用设计与 Review 是否覆盖当前部分；无 plan 也适用。大型交付有独立结果或设计决策的部分，必须定位书面方案具体段落、原始输入对齐和适用 Review 结论；缺一返回对应 owner，不能以“总体已设计”或聊天承诺放行。原先留白、尚未细化或新决策返回 Design，不边编码边补未冻结设计。已有 plan 时同时执行其设计策略；既定方案内惯例细节不新建方案。探索限定问题与判定，未完成适用设计/Review 前不作为正式交付。

## 实现合同

- 保持单一路径、稳定合同和可见主流程；必要、安全、清晰的最小增长允许存在。
- 同一事实、事件、状态变化或传输语义只有一个 owner 和一条标准链路。
- 新 wrapper、adapter、factory、service、manager 必须减少真实复杂度或隔离真实变化点。
- 删除或复用旧实现；不得为抵消行数扩大无关范围或损害可读性、类型和协议安全。
- 业务层传递 owner 或本次调用的数据快照，不把稳定 owner 拆成多层 proxy 和同名转发。
- 跨 workspace package 只使用公共入口或 `exports`。
- 前端业务状态与编排归 manager/store/presenter；组件和 hook 主要连接、展示与同步外部系统。
- 实现与已冻结设计不一致时，先区分模型缺口还是实现偏差，不边写边悄悄改变设计。

## 条件方法

- 当前决策涉及项目专项前端、兼容或 runtime 方法时，由已冻结设计或项目入口选择当前需要的一项，不在实现阶段重新选型。
- 只有用户明确讨论简单性、拆分收益、过度防卫、过度抽象或代码审美，且需要裁决保留、拆分还是抽象时，才读取[实现工艺](references/implementation-craft.md)。
- 工具链无法运行时先核对项目固定的版本与恢复入口；不要用全局工具静默替代项目工具链。

普通实现不预读这些条件材料。

## 执行节奏

- 触达用户或其它任务的既有改动前先做双向范围审计，避免覆盖、revert、格式化或混入无关内容。
- 每个编辑批次只解决当前责任域；新事实改变方案时返回设计，不用局部补丁堆第二模型。
- 迭代中只运行能指导下一步的最快定向检查；完整证明留给验证阶段。
- 重启现有实例遵循 AGENTS.md 的任务内自主重启规则，不重复请求许可。

## 输出

返回实际实现、删除或收敛点、迭代证据、与设计的偏差以及仍需验证的风险。本阶段不能用 lint、tsc 或局部测试宣称功能已经完整验证，也不执行最终 Review、commit、push、release 或 deploy。