Pome Grow

---
name: pome-grow
description: 只能手动加载
disable-model-invocation: true
---

把 `.pome/nursery/blueprint.md` 落实为经过验证的代码。blueprint 是功能方案、关键决策和范围边界的事实来源；`.pome/nursery/plan.md` 提供阶段对设计节点的覆盖关系、阶段依赖、交付内容和验收条件。实现应完成 blueprint，而不是机械照搬可能已与代码库现实有偏差的局部细节。

按照 plan 列出的实施阶段执行，一次只完成一个阶段。阶段实现和验收完成后更新进度并暂停，等待用户提交；用户确认提交完成后，才开始下一个阶段。阶段内如何落地、何时测试以及怎样处理局部依赖，根据 blueprint 和当前代码库决定。

## 开工前检查

1. `.pome/nursery/blueprint.md` 不存在：告知用户先用 pome-seed 完成需求设计，到此为止
2. blueprint 带遗留问题：告知用户先用 pome-seed 收敛方案，到此为止
3. `.pome/nursery/plan.md` 不存在：告知用户先用 pome-plot 制定实施计划，到此为止
4. plan 的依据不是当前 blueprint：告知用户先用 pome-plot 更新计划，到此为止
5. plan 与 blueprint 的目标或范围冲突，或阶段结构无法覆盖 blueprint：停止实现，指出最小冲突单元，告知用户先用 pome-plot 修订计划
6. blueprint 内部矛盾或关键决策无法在当前代码库成立：停止实现，指出最小冲突单元，告知用户先用 pome-seed 修订方案

文件路径、调用点、阶段内步骤或验证命令由 pome-grow 根据当前代码库确定，局部差异不构成阻塞。不要在 pome-grow 中改变 blueprint 的功能方案，也不要自行改变 plan 的阶段覆盖、目标、依赖和先后关系。

## 建立执行上下文

完整读取 blueprint、plan 和适用于当前目录的仓库说明。计划涉及的代码按当前阶段逐步定位和读取，不把“建立上下文”理解为批量展开相关目录或整批文件。每次开始或恢复执行时重新获取当前工作区、相关实现和可用验证方式；这些信息容易过期，不写入 blueprint 或 plan。

- 核对 plan 标明的 blueprint 叶子节点覆盖关系，并建立这些节点、阶段交付和代码改动之间的对应关系
- 检查计划中的阶段目标和依赖关系仍然成立，并确定当前实际文件、调用点和验证方式
- 阅读实施范围内最接近的现有实现，识别命名、接口、错误处理、配置、依赖、测试和文档约定
- 区分已有改动与本次实现，保留用户或其他协作者的工作，不还原、不覆盖无关内容
- 从代码和验证结果判断既有交付与验收是否仍然成立，不仅依据复选框；已勾选项不再满足时恢复为 `[ ]` 并说明原因，仅局部落点或命令变化不重置

其余实现上下文仅围绕当前阶段获取：先定位直接相关的定义、调用方、测试和配置，现有信息不足以支持实现决策时再沿依赖关系扩展。避免批量读取、重复获取已有信息或保留与当前决策无关的工具输出。能够在不改变实施阶段的覆盖、目标、依赖和排列的前提下解决的实现差异直接处理；只有计划结构需要实质修改时返回 pome-plot，只有功能方案或关键决策需要修改时返回 pome-seed。除非用户要求或上层规则强制，`.pome/nursery/plan.md` 是实施阶段和持久化进度的唯一来源。

## 实施

按 plan 列出的实施阶段及其依赖推进，不提前实施尚被阻塞的后续阶段。阶段内以完成其覆盖的 blueprint 节点和端到端交付为准，可以根据真实依赖调整局部步骤，并补足正常验收所需的生产代码、测试、配置、文档和调用点适配。

- blueprint 已确定的行为、契约和范围直接遵守，不增加明确排除的能力，不为假设需求预留兼容代码
- plan 的阶段覆盖、目标、依赖关系和验收意图应保持；具体文件、局部实现方式和验证命令由当前代码库决定
- 实现形式沿用所属模块的现有约定，优先复用已有接口、辅助能力、基础设施和测试工具
- 选择完成当前任务的最小正确改动，不借机重构无关代码或建立平行体系
- 修改共享契约前检查调用方和被调用方，并同步处理计划范围内的受影响位置

执行中出现的信息按影响层级处理：实现细节和局部遗漏由 pome-grow 解决；阶段覆盖、目标、依赖或验收条件无法成立时返回 Plot；功能方案或关键决策无法成立时返回 Seed。不要因路径变化、命令变化或普通实现差异中断当前阶段。

## 验证与进度

根据改动风险、依赖关系和仓库惯例决定阶段内的验证时机。先完成一组内聚修改，再运行能尽早暴露该组问题的最小定向检查；不要把同一全量检查当作每次编辑后的反馈手段。交付级验证应直接证明阶段覆盖的 blueprint 节点成立；代码稳定后执行 plan 中该阶段的验收。最后一个阶段还要执行与整体改动相匹配的项目级检查。优先使用仓库已有脚本、CI 配置和文档中的命令，不臆造工具或技术栈。

验证应提供新的有效证据，而不是机械重复：覆盖代码没有相关变化时不重跑已经通过的检查；失败后先定位和修复问题，再验证受影响范围；阶段级检查在实现收敛后执行。减少无关日志不能以牺牲失败诊断或验收可信度为代价。

只有阶段覆盖的 blueprint 能力已经实现、交付内容成立、相关验收成功且没有已知缺口时，才将 plan 中对应的 `- [ ]` 更新为 `- [x]`。复选框是 plan 内唯一持久化进度，不向 plan 追加执行日志、失败历史或临时状态。实际文件或命令与最初判断不同但验收目标已满足时可以勾选，并在阶段报告中简要说明。验证失败时先修复本次实现造成的问题并重跑；若被环境、外部条件或既有缺陷阻塞，保持交付或验收未完成并报告可复现的阻塞信息。

## 阶段交接

当前阶段验收通过后，更新该阶段对应的交付和验收复选框，报告阶段产物及验证结果，然后停止执行并等待用户提交。不要提前实现下一阶段，也不要替用户创建提交。用户确认提交完成并要求继续后，重新读取 plan 和工作区，从下一个未完成阶段开始；无关的未提交改动不应阻塞继续执行。

交接前先通过差异摘要掌握改动，只在发现异常、需要审查高风险逻辑或摘要不足以判断时展开局部内容；避免为了复核而重新输出刚刚生成的大段改动。进度消息保持简短，只报告新的决策、结果或阻塞，不重复已有内容。

如果用户尚未提交，保持等待，不把下一阶段改动混入当前工作区。提交消息和提交操作由用户决定，不写入 plan，也不额外维护提交记录。不要执行推送、发布、生产迁移或破坏性操作，除非用户明确要求。

## 中断与完成

用户暂停、上下文受限或出现无法自行解决的阻塞时，尽量停在已验证的最小完成单元；只勾选已经成立的交付和验收项。阶段交接或最终回复报告已完成范围、关键文件或模块、实际运行的验证及结果、未完成项和阻塞，不另建状态文件或把执行过程写入 blueprint、plan。

全部交付和验收项完成后，逐一核对 blueprint 叶子节点均有实现、plan 阶段均满足验收、差异未引入越界能力。实现遗漏直接补齐并重新验证；只有遗漏暴露出阶段结构无法覆盖方案时才返回 pome-plot，只有方案本身需要改变时才返回 pome-seed。最终完成以 blueprint 已完整实现为准。