development-implementation

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

Development Implementation

目标

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

实现前检查

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

1. 能否删除、复用或收敛已有路径？
2. 事实、状态和生命周期的 owner 是否正确？
3. 是否新增无语义 wrapper、adapter、factory、proxy、参数搬运或第二入口？
4. fallback、兼容和恢复是否位于真实边界，并有可观察信号和退出条件？
5. 是否新增、移动、重命名文件或改变目录角色？命中时加载 file-organization-governance 并在编辑前运行 planned-path preflight。

实现合同

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

条件方法

• 当前决策确实涉及前端状态、React 生命周期、交互、样式、兼容策略或外部 runtime 时，只选择对应的一个专项 skill。
• 只有用户明确讨论简单性、拆分收益、过度防卫、过度抽象或代码审美，且需要裁决保留、拆分还是抽象时，才读取实现工艺。
• 只有 node/pnpm/npx/corepack 无法从 PATH 解析时，才读取Node/pnpm 环境恢复。

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

执行节奏

• 触达用户或其它任务的既有改动前先做双向范围审计，避免覆盖、revert、格式化或混入无关内容。
• 每个编辑批次只解决当前责任域；新事实改变方案时返回设计，不用局部补丁堆第二模型。
• 迭代中只运行能指导下一步的最快定向检查；完整证明留给验证阶段。
• 未经用户授权，不重启宿主、服务、桌面应用或运行实例；优先热更新、刷新或隔离验证。

输出

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