spec-executor

Spec Executor

在隔离的执行对话中实现一个已批准的工作单元。将其已批准的来源视为权威依据，将实现细节保留在此处，并返回一份精简回执，以便粘贴回原对话。

确定执行约定

1. 从继承的对话历史或用户的明确引用中确定一个已批准的来源。用户后续的更正优先于较早的冲突要求。
2. 阅读完整来源，包括直接链接的决策。不要重新构建一份冗长的目标说明。
3. 确认工作范围足以适配当前实现环境，且不存在尚未解决的产品决策。如果不满足，请停止并建议拆分或澄清，无需强制要求采用特定的上游工作流。
4. 提取并保留以下信息：
   • 仓库和起始基线；
   • 面向用户的结果和验收标准；
   • 约定的验证切入点；
   • 明确的非目标和工作区边界；
   • 对提交、推送、发起评审请求、部署、修改跟踪器、数据变更及其他外部操作的授权。

不要重新讨论已确定的产品问题。仅当已批准的来源自相矛盾、与仓库存在重大冲突、缺少必要的外部约定或需要新的授权时才暂停。

编辑前锁定范围

检查仓库指令、分支、HEAD、工作区状态、近期相关历史记录，以及约定切入点处的当前实现。将实际的实施前 HEAD 记录为评审固定点。

开始实质性编辑前，发送一条简短的执行锁定消息：

Executing: <one-sentence outcome>
Source: <approved conversation, issue, file, or spec>
In scope: <compact list>
Out of scope: <compact list>
Validation: <primary seam and required gates>
External authority: <what is and is not authorized>

必要时创建或切换到合适的本地分支。绝不丢弃、覆盖或纳入无关的已修改或未跟踪工作。如果请求的基线已发生偏移，判断规范是否仍适用，并记录当前固定点；如果偏移改变了产品行为或验收标准，则停止。

实现规范

1. 将每项验收标准追溯到现有行为、能够满足它的最小代码切入点，以及可观察的证据。
2. 选择适合仓库、风险和约定切入点的实现与测试方法。优先采用行为证据，而非针对实现细节的断言。
3. 实现范围最窄但完整的纵向路径。不要纳入下游任务、顺手重构或新的产品行为。
4. 开发期间运行最小范围的相关检查，然后根据风险按比例运行仓库要求的完整验证门槛。
5. 将最终差异与每项验收标准逐一对照，并依据记录的基线进行审查。若适用，可使用专业审查技能或工具，但并非必须。修复范围内的严重问题，并解决其余问题或明确报告。
6. 检查最终工作区，并将本次执行的更改与任何既有更改区分开来。

调用此技能即授权在范围内进行本地实现和验证。但这本身并不授权提交、推送、发起或合并评审、修改跟踪器状态、部署、写入生产数据、调用高成本的真实服务或向他人发送消息。只有在已批准的来源或用户后续消息明确授权时，才能执行这些操作。绝不可将一项授权扩大为另一项授权。

处理阻塞和上下文溢出

遇到阻塞时，先穷尽安全的只读调查和本地验证。然后提供证据并停止，说明需要规划对话作出的最小决策或授权。

如果工作量过大，无法在单个实现上下文中可靠完成，不要默默丢弃历史而继续。返回部分回执，保留工作区，并建议拆分工作，或将剩余部分整理成可移植的目标。

返回回执

除非有人要求，否则不要编写交接文件。最后以一个可直接复制粘贴的区块结束：

SPEC EXECUTION RECEIPT

- Conclusion: completed / partially completed / blocked
- Spec source:
- Review fixed point:
- Acceptance criteria: <each criterion with pass/fail and evidence>
- Main changes:
- Changed files:
- Branch / commit / review:
- Validation results:
- Review findings:
- Not validated or not executed:
- Risks and remaining work:
- Planning-thread decision needed:
- Final worktree state:
- External effects: <push, deploy, tracker, data, real services, messages>
- Goal / spec quality: <optional: accurate / criteria-too-vague / criteria-wrong / missing-constraint / over-scoped — plus one sentence>

回执应简洁，但要包含证据。适当提供能证明已完成的确切命令、数量、标识符和链接。切勿声称完成了未经验证的真实环境操作、部署或外部操作。 回执离开执行线程前，请删去凭据、令牌、Cookie、个人数据和敏感环境标识符。

目标 / 规范质量为可选项，不是完成条件。执行 Agent 可以留空。规划线程或用户在将回执与实际差异对比后填写。