plan-acceptance

委派式续接

当上层工作流通过选定的常设授权委派规划时，应解决授权范围内的问题，并应用保留来源的建议，无需再次询问。保留承诺、排除项、约束、链接和 ID。采纳需要新修订版本、保留先前字节、独立审计和记录授权归属。在控制器规划会话中，按要求的架构返回拟议文本；存储和采纳由控制器负责。授权范围之外的产品变更仍须指出缺失的决策权限。

将来源中的承诺转化为与候选方案无关的验收契约。此技能负责规划验收，不负责实现或验证。直接调用议题时，也会根据协议的独立规划规则发布规划交接内容。

开始规划前，请阅读验收契约协议。 该协议定义了规范封装、修订规则、证据术语和交接内容。

构建契约

1. 接受受支持的跟踪器议题、直接确认的文本，或来自任意仓库路径（包括 specs/ 和 work/）的项目编写源文件。推导工作项 slug，并将生成的契约保存到 .p2p/work/<slug>/contract.md；写入前检查是否存在冲突。 对于议题输入，先阅读已配置的跟踪器说明，以及议题正文、评论、现有规划交接内容、审批和修订。 独立的本地工作项无需规范或跟踪器。 将最简验收要点规范化为生成契约中的矩阵；保留现有 ID 和承诺。按要求将外部源承诺导入本地；跟踪器仍是可选的来源或镜像。将导入的约束性文本保留在工作项或链接的本地源文件中，并附上其外部 URL 和检索身份信息以标明出处。仅有外部 URL 不构成可进行实时哈希校验的约束性输入。 阅读源文件、现有契约、待处理修订，以及适用的上级契约。如果无法确认源文件，报告缺口并停止。 对于切片子项，按照协议的父子规则获取其分解内容、精确贡献、先决条件和准确的父项快照。规划前比较当前父项和待处理修订；解决实质性差异，不得悄然采用已变更的父项。 如果存在，请阅读项目的建议性经验登记册（默认为 docs/retrospective-learnings.md）。考虑相关且状态为 active 的已采纳经验；记录所使用经验的 ID 和评估参考，以及其他经验不适用的原因。已被取代的建议和缺失的登记册均不构成规划阻碍。经验仅供参考，不能作为依据，擅自添加要求、排除项、标准或修订；这些内容必须得到当前源文件和其审批流程的支持。
2. 将现有验收标准（包括 GitHub 复选框）与契约协调一致。提取每项实质性承诺和必要不变量。保留源引用，确保每项标准都映射到相应要求且不重复。 通过 Source 将子项各行映射到明确限定的父项义务。保留适用的继承边界和排除项，但只要求子项自身的结果和贡献，不要求无关的同级功能。
3. 每项可独立证伪的承诺各占一行。拆分复合标准、合并重复主张，并在重构现有行时记录 ID 映射。重复运行时保留现有 ID，并为新增行分配未使用的 ID。
4. 记录源文件支持或实现预期结果所需的边界：在适用时包括空输入、重试、重启、授权、并发或部分失败。将推测性行为排除在契约之外。
5. 检查已确认的规范和 TDD 接口、公共接口、现有测试、约束及已配置的命令。复用这些接口，并为每行指定独立的判定依据和具体证据路径。将缺少可信路径的项目标记为 gap，并说明缺少什么。
6. 遵循协议的修订规则。记录经授权的实质性变更，并保留先前修订。将未解决的变更作为问题提出，不得悄然更改约定。
7. 提交提案前，审查源文件及相关项目上下文，检查适用的歧义、矛盾、成功或失败行为缺失、重要的隐含边界或不变量、回归约束、范围不明确、承诺无法验证、证据或权限不可用，以及对环境、数据、时序、顺序、权限、兼容性或外部系统的假设。对每项实质性发现，记录已确认的结果或边界、明确指出的证据缺口，或待解决问题。只应用相关类别；不要臆造要求，也不要强行将每个类别纳入每份契约。审查应简洁，并与风险相称。
8. 每项已接受的要求都必须以可观察的预期结果、已确认的可信接口、独立的判定依据和具体证据路径为门槛；若其中任何一项不可用，请指出缺少的接口、判定依据或证据。将证据缺口与未解决的产品决策区分开来。只有当不确定性可能影响正确性或范围时，才询问请求方并阻止实现；不得猜测。只要仍有此类问题未解决，就不得交接为已就绪状态。
9. 对已批准的契约重新运行规划时，核实并保留其准确的已批准字节内容、修订版本、要求 ID 和审批绑定。若内容未变或仅证据发生变化，则保持这些标识不变。只有通过常规且明确授权的修订流程，实质性变更才能替换规范契约；记录授权、旧约定和拟议约定，以及任何 ID 映射，并保留先前的准确字节内容。未经此类授权，保持已批准契约不变，并将拟议变更作为待解决问题提出。

评估并确定交付方式

在承诺的结果和验收条目明确后，询问整个工作项是否适合在一次有界交付中完成实现、独立审查并验证。建议一条咨询性路线：

• Direct delivery：当结果明确、一致且可在一个交付周期内妥善完成时。
• Sizing inspection：当结果明显范围较广，或边界存在不确定性，实质影响可靠实现、独立审查或验证时。
• Deferred：仅当尚未解决的产品结果导致无法达成协议时。通过验收规划解决该结果；不要用拆分来决定它。

不要因验收条目较多、普通实现不确定性、不熟悉、算法困难、缺少历史测量数据，或文件、行数、字数、测试、时间、令牌、故事点、组件或子项数量而触发规模评估。这些内容可以作为观察记录，但绝不能作为阈值。

遵循现有的本地 P2P 存储和历史记录规则，保存并回读 .p2p/work/<slug>/delivery-shape.md。将其绑定到确切的规范合同路径、修订版本和 SHA-256，以及所有适用的来源、规范、父项和已批准计划标识。包含路线、简明且基于证据的理由、带可检索路径/修订版本的检查上下文、假设、适用的拆分结果（none、准确的 NO SPLIT 或已批准的计划标识）、一个最早的后续操作，以及尚待解决的关卡。理由应简洁；不要存储隐藏推理。回读后重新计算哈希。合同或绑定输入发生变化时，建议即告过期，必须重新评估；保留以往记录。

只能指定一个立即后续操作：解决未明确的结果、获得所需批准、解决实质性证据缺口或前置条件、修复存储、运行 /deliver-issue <contract> 进行直接交付，或运行 /slice-contract <contract> 进行规模评估。当有待通过的关卡时，单独记录建议的后续路线，但将该关卡作为唯一的后续操作。直接交付仅供建议：它既不改变协议，也不改变就绪/准入状态，且不授权任何外部操作。

审核并交接

核对每一项源承诺，并根据所需结果说明每一项新增不变量的理由。追踪工作流直至完成，包括必要状态、持久化和失败行为。检查内容是否缺失，以及是否包含未请求的范围。不要将实现偏好写成需求。

按下方结构返回契约。计划状态只能使用 planned 或 gap。将任何旧版证明判定移至单独标识的证明报告，并保留其原始候选项和上下文；若缺少来源信息，则标记为差距。

交接前，将契约保存并重新读取 .p2p/work/<slug>/contract.md。在 specs/ 中保留一份长期有效的可选规格，并用 Source 链接。用 Parent 链接父工作项，并保留其准确快照及贡献映射。根据协议的历史规则保留先前修订版本。如果此上下文无法写入，请将要保存的准确文本返回给外层工作流，以便其保存并重新读取；在确认已取回之前，报告存储待处理。 保存本地文件并不代表授权暂存、提交或发布到跟踪器。

保存提案、批准回执或已批准修订后，并在交接前刷新可移植检查点：python3 <skill-dir>/scripts/p2p_filesystem.py --repo <root> checkpoint .p2p/work/<slug>/contract.md。默认的 p2p-state/<slug>.json 适合 Git；根据协议的可移植检查点规则，也可选择明确指定的问题项。保留准确的批准关联历史记录和绑定输入。分别报告其路径、字节数，以及 LOCAL_ONLY/COMMITTED/PORTABLE 保存状态，不要与批准状态混为一谈。未经验证的共享回读，不要将本地文件称为可丢弃。

对于用户直接在问题项上发起的调用，按照协议的独立规划规则发布并验证共享规划交接。本地专用或仅草稿请求不执行该写入。在交付流程内部的调用，则依据外层工作流授权留在本地。返回评论 URL 和需要批准的准确提案；发布不代表批准。如果发布或回读失败，保留本地提案，并报告问题项交接未完成。

对于已跟踪的子项，将就绪状态协调交由发起调用的工作流处理。在保存并重新读取契约后，该工作流会检查已配置的分流含义、所需批准、未解决的决策，以及前置结果是否可用。若有标签编辑权限，则仅当子项已就绪、可进行无人值守实现时应用 ready-for-agent，并保留其他无关标签。否则，报告剩余阻碍或待处理的标签更新。前置条件可用后重新检查；仅创建契约并不意味着已就绪。

输出

# Acceptance contract: <source>

Contract revision: v1
Source: <relative Markdown link to binding local spec/source text; omit for a standalone work item>
Source attribution: <external issue/spec URL and retrieval identity, if imported>
Parent: <relative Markdown link to parent work item and revision, or None>
Parent snapshot: <immutable reference or retrievable captured text and digest; omit if none>
Contribution: <decomposition reference, qualified parent obligations and precise contribution; omit if none>
Prerequisites: <references and required outcomes, or None>

Intended outcome: <observable user or operator outcome>

Advisory learnings: <active IDs considered and why used or inapplicable; None if no register>

## Acceptance matrix

| ID | Source | Requirement | Boundaries / counterexamples | Seam | Oracle | Planned evidence | Plan state |
|---|---|---|---|---|---|---|---|
| R1 | <criterion> | <one observable promise> | <what would falsify it> | <agreed public interface> | <independent expected result> | <named case and assertion, invariant check, or exact command> | planned |

## Unresolved gaps

- <missing evidence path, seam, or oracle, or None>

## Open questions

- <unresolved product or design decision, or None>

## Out of scope

- <excluded nearby concern, or None>

## Change notes

- <revision, affected IDs, old/new agreement and authorization; ID mappings, or Initial contract>

## Implementation handoff

For `Direct delivery`, hand off through `/deliver-issue`; its existing #60
admission must pass before it invokes implementation. For `Sizing inspection`,
hand off to `/slice-contract` before implementation. Implement the smallest
complete solution inside the spec envelope, preserve requirement IDs and
promised outcomes, and capture the candidate for separate
/review-implementation and /prove phases.

## Proof handoff

Evaluate every requirement against this contract revision and one fixed candidate.
Record actual evidence and verdicts in a separate proof report.

契约之后，以 Next steps: 结尾，并附上按顺序排列的编号列表（1.、2. 等），使每项操作都可按编号引用。唯一的即时操作应遵循已保存的交付形态记录：Direct delivery 使用 /deliver-issue <contract>，Sizing inspection 使用 /slice-contract <contract>。如果批准、未完成的结果、证据差距、存储失败或前置条件仍待处理，则将该门槛列为唯一的下一步操作，并保留条件式路由。可选审核命令为 /audit-acceptance <proposed contract> against <source>。不得绕过直接路由或 #60 准入流程，直接交给 /implement-contract。不要调用下一项技能。