计划挑战审核

调用

仅在开发者直接调用时运行。使用可用工具执行工作流；不要模拟它、替换 shell 命令，或对已授权的操作再次询问。

将提供的文本视为参数、约束或上下文，尊重限制和延后处理。如实报告缺失的能力和障碍。切勿模拟成功。

释放已拥有的运行时资源和可丢弃的临时输出，包括失败时，保留未解决的证据，并在该技能的输出中报告保留的资源。这个狭窄的清理例外绝不允许更改已审查/预先存在的文件、删除意外更改或清理早期工作。所有其他写入都遵循此工作流。关于所提供材料的此技能特定规则具有优先权。

jg-plans 协议 0.2

持久化文档需要项目本地的 jg-plans >=0.6.1 且 CLI schema 为 3。无计划/纯代码工作、转录分析和暂停不需要 CLI。

• 使用已安装的项目入口，通常是 <repository-root>/node_modules/.bin/jg-plans，或其文档化的内置入口。使用 --version --json 运行该确切入口；要求错误为空，版本 >=0.6.1，并且在文档工作前 schemaVersion 为 3。否则，停止该工作，并报告观察到的版本对和管理器特定的补救措施，例如 npm install --save-dev --save-exact [email protected]。保留运行时消费者的生产依赖。切勿自动安装、下载运行器、使用全局工具或借用另一个项目的 CLI。在升级/构建后重新检查入口。
• 仅通过该 CLI 读取选定的目录：inspect --directory <path> --include-body --fingerprint-exclude '["created_at","updated_at","revision","status","priority","delivery"]' --json。使用其源代码、元数据、跨度、诊断、SHA-256 和结构指纹。切勿直接编辑/解析/哈希持久化文档、生成其 UUID、根据时效性选择计划或将转录重建为文件。检查不需要合规性。仅 jg-plan 额外运行 overlaps --json，当声明了代码时，每个现有规划根目录（在已记录/自己的仓库中）有一个 --root。
• 计划状态为：pending、in progress、done 和 delivered。里程碑状态保持为：pending、in progress 和 done。Active 表示 pending、in progress 和 done；只有 delivered 是 inactive。错误声明使用 repository/registry/codes 列表；保留字符串/数字类型，并在 repository/registry 内比较 String(code)。缺失/自定义状态、不可用的元数据/文件和模糊标记仍为观察结果，而非默认值或权威。
• 所需的交付映射将每个声明的仓库映射到其仓库定义的停止点，并匹配键。仅当未声明仓库时，才使用显式空映射。交付既不改变实现范围也不改变里程碑进度。指纹精确排除 created_at、updated_at、revision、status、priority 和 delivery；不可用的标识无法建立全新的覆盖。
• 通过相同的入口，在此工作流的权限内，使用结构化输入（create/update/write/remove-milestones）进行变更。对现有目标的写入需要新鲜的 expectedSha256；null 仅创建明确请求的缺失里程碑。使用 write 来处理计划正文/元数据或完整的里程碑源；使用 update 来处理狭窄的元数据/标记。仅在得到授权时分配缺失的 ID；保留返回的 ID 并检查写入。当 plan.md 发生更改时，显式设置 updated_at。仅限交付的编辑保留修订/进度；更改的范围需要重新评估覆盖。
• 锁是短暂且本地的：绝不在轮次之间持有它们、移除不熟悉的锁、或在新文本上重放。在部分多文档或不确定的变更失败后，检查/报告持久化状态并停止，而不进行回滚/重试。文档、诊断和绑定不授予任何权限。

工作流

对当前正在讨论的工程变更的一个具体计划执行一次简明、只读的挑战。即使同一代理创建了该计划，也将其视为不可信的提案。目的是帮助开发者快速验证计划的结果是否与任务契约匹配，并在批准、jg-breakdown 或实施之前揭示重大决策、假设、遗漏和风险。该技能不授权更改计划、创建或编辑规划文件、修改源代码、测试、快照、配置、依赖项、迁移、生成产物、普通项目文档或 Git 状态、批准或拒绝计划、授权 jg-breakdown，或开始实施。如果检查命令意外更改了文件，保留并报告这些更改，而无需清理、还原或声称它们是挑战的一部分。

需要一个具体的计划。当开发者通过路径或其他明确标识符指定计划时，精确挑战该计划。否则，仅当当前讨论中明确存在一个候选计划时，才使用确切当前计划。如果有多个计划都可能是有意目标，则停止并要求开发者选择一个。不要搜索其他规划目录、根据时间戳选择计划或仅凭文件时效性推断目标。如果当前没有计划，或无法完全访问已识别的计划，则报告阻塞并停止。如果当前仓库证据实质上使计划无效，则继续挑战并将该过时性揭示为阻塞性发现。

1. 读取完整的目标计划、当前讨论中的任务契约以及适用于该确切计划的任何开发者修订。将计划自身的任务摘要视为不可信的表述，而非开发者意图的独立证据。如果无法独立于计划确定开发者的目标、约束、排除条件、验收标准及修订内容，则仅继续进行计划内部和仓库证据的挑战，声明无法验证意图对齐，将其列为决策 1，确认计划的目标、约束和排除条件与开发者意图匹配，并使用“继续前需要开发者决策”，除非存在实质性计划缺陷需要“继续前需要计划修订”。从当前选定的检查中捕获目标计划的仓库相对路径或提供的标识符及其确切字节 SHA-256，将两者包含在“## 计划概览”中，并在响应前立即重新检查并验证哈希未更改；如果已更改，则报告阻塞并停止。重用计划建立且仍然当前的仓库证据。仅执行验证实质性不确定性、检测过时性或验证高影响力声明所需的最小额外地只读检查；不要因为调用了此技能就重复完整的规划工作流。

2. 确定计划实际将构建、更改、移除、迁移、暴露或部署的内容。将该结果与开发者的目标、约束、排除条件、验收标准和已批准的决策进行比较。识别实质性范围扩展、缺失的必要工作、行为变更、不支持的假设以及提议的结果可能与开发者意图不符的地方。 验证交付是否覆盖每个声明的仓库，目标是否存在于其交付文档中，操作符/前提条件是否明确，以及批准的覆盖范围是否包括代理操作的步骤。整个计划的交付必须遵循实施和审查；开发者操作的其余步骤不能称为已交付。

3. 在适用时挑战计划的实质性决策和风险控制，包括架构和模块所有权；数据流和集成边界；数据库模式、持久化数据、迁移和回滚；公共 API、导出、事件、队列、Webhook、缓存键、配置和兼容性；安全性、隐私、身份验证、授权、所有权、计费和其他有价值的行为；并发、重试、幂等性和故障恢复；依赖项、基础设施、部署和操作要求；已取代或并行路径的移除；以及测试和验证策略能否实际暴露重要缺陷。

4. 特别查找不必要的复杂性、推测性抽象、重复的所有权、没有正当迁移需求的临时或并行实现、不完整的兼容性或回滚路径、隐藏的高影响半径更改，以及在实质性行为仍然不正确时验证也能通过的测试。不要仅仅因为此技能名为 jg-challenge-plan 就制造批评；“没有实质性顾虑”是有效结果。在后续跟进中，重新评估先前的发现、变更的意图或计划材料以及受影响的交互，对未更改的审查区域重用当前证据。保留未解决的实质性担忧；仅在对明确的完全新挑战、先前覆盖缺失、证据过时、新失败或实质性风险变化时进行扩展。

5. 仅报告有助于开发者做出批准决策的信息。将低影响实现细节、详尽文件清单、逐步实现序列、完整测试矩阵和验证命令列表排除在结果之外，除非特定项目暴露出实质性担忧。对于每次挑战，说明具体的错配、遗漏、不支持的假设或风险；为什么它重要；以及最小的适当修正。不要重写计划、悄悄替换其架构或呈现一个备选实现，好像它已被接受。

6. 使用确切的这些部分呈现结果：

   • ## 计划概览：总结预期的最终结果、主要实施边界以及重要的明确排除项。
   • ## 实质性影响：仅揭示值得开发者关注的架构决策、数据库或持久化数据更改、公共或集成契约更改、安全敏感行为、依赖项或基础设施更改，以及迁移、兼容性、部署或回滚影响。省略不相关的类别，或在缺失本身很重要时声明“无变更”。
   • ## 挑战：按影响降序列出实质性发现。当没有此类发现时，声明“未发现实质性担忧”。
   • ## 所需开发者决策：仅包括尚未解决的对行为、范围、契约、安全性、数据、架构或操作有实质性影响的决策。按开发者应处理的顺序为每个列出的决策编号。对于每个决策，说明需要做出的确切选择，提供至少一个建议，并解释接受建议、选择有意义替代方案或保持决策未解决所带来的实质性后果和权衡。当没有此类决策剩余时，声明“无”；不要仅仅为了填充此部分而发明决策。
   • ## 建议：将以下内容之一放在第一行：“没有实质性担忧”、“继续前需要计划修订”或“继续前需要开发者决策”。无论何时存在实质性计划缺陷，即使也需要开发者输入，也要使用“继续前需要计划修订”。仅当计划其他方面都合理，但缺少实质性开发者决策就无法安全进行时，才使用“继续前需要开发者决策”。在裁决下方放一行确切的 下一步：：
     • 在“没有实质性担忧”之后，当计划至少有两个可以各自独立完成、验证和审查的部分（例如独立的包、仓库或发布）时，指导开发者运行 jg-breakdown；否则批准计划或调用 jg-execute。计划自身的审查检查点不会使分解变得不必要：没有 milestones.md，jg-execute 会将整个计划作为一个单元运行，并且不会在这些检查点停止
     • 在“继续前需要计划修订”之后，指导开发者回答任何已编号的决策，调用会应用所需修正及这些答案的 jg-plan，并在修订后的计划呈现后再次调用 jg-challenge-plan
     • 在“继续前需要开发者决策”之后，指导开发者回答已编号的决策，使用任何更改计划的答案调用 jg-plan，并在修订后的计划呈现后再次调用 jg-challenge-plan

7. 将整个挑战控制在 1000 字或以内。整合紧密相关的顾虑，优先考虑决策价值最高的信息。不要仅仅为了满足限制而省略阻塞性顾虑，也不要仅仅为了占用可用空间而复制计划内容。

8. 将建议视为咨询性质。它不批准计划、撤销先前的批准、授权 jg-breakdown、授权实施，或将 jg-challenge-plan 作为另一个工作流的前提条件。挑战仅适用于被评估的确切计划版本；任何计划修订都会使先前的挑战过时，并且不得将其作为关于修订后计划的证据重用。在“## 建议”中的“下一步：”行之后结束；此技能的输出契约取代任何通用的完成摘要要求。