| name | aim-verify-task-spec |
| description | Use when validating whether an AIM Task Spec is still actionable against the latest baseline and the agent must distinguish waiting assumptions from true spec failure. |
aim-verify-task-spec
概述
这个 skill 用于判断一份 AIM Task Spec 在最新基线上是否还能继续推进。
核心原则只有两步：先看 Task Spec 的五段结构是否完整且充分，再看最新基线是否满足 Assumptions。结论只能收敛为 pass、waiting_assumptions、failed。
何时使用
- 需要判断某个 Task 在最新基线上能否继续推进时。
- 需要区分“现在还不满足前提，先等待”与“Spec 已失效 / 有重大歧义，应失败上报”时。
- 需要复查一份旧 Task Spec 是否仍然适用，但不能依赖
spec_commit / base_commit 时。
不何时使用
- 不负责生成或改写 Task Spec。
- 不负责写 implementation plan。
- 不负责改代码、跑实现、跟进 PR。
- 不负责给 Task 排序或替代调度器决定优先级。
输入
- 一份待验证的 Task Spec 原文。
- 最新基线的只读事实：当前文档、代码、配置、测试、接口、PR 合并后基线状态等。
- 若可得，当前任务已知上下文：为什么触发本次复查、最近哪些基线增量可能相关。
校验流程
- 先做结构校验，只看 Spec 自身是否足够执行。
- 只有结构校验通过后，才做基线验证。
- 基线验证只问一个问题：最新基线是否满足
Assumptions。
- 输出时只能使用
pass、waiting_assumptions、failed 三类结论。
第一步：结构校验
必须逐段检查以下五段是否都存在，且内容足以支撑后续执行。
1. Title
- 必须是一个明确的基线增量目标。
- 应能自然映射为一个 PR 标题。
- 只是主题词、方向词、泛泛愿景都不够。
2. Assumptions
- 必须写成可验证的当前事实，不是背景故事。
- 尽量能被只读检查确认。
- 应聚焦外部可观测事实，而不是容易漂移的实现猜测。
3. Goal vs Non-Goal
- 目标和非目标都要具体。
- 非目标必须能真实约束 scope，而不是礼貌性补一句“不做太多额外工作”。
- 如果缺少非目标、或非目标无法限制蔓延，结构仍不充分。
4. Core Path
- 必须解释从当前概念格局到目标概念变化的主路径。
- 应说明为什么选这条路径，以及备选路径为什么不选。
- 只列文件改动、函数改动、机械步骤，不算合格的 Core Path。
5. Value Alignment
- 必须给出冲突场景下的价值排序。
- 只写抽象口号，不足以给执行层自由裁量依据。
- 如果真实分歧出现时无法据此裁决，结构仍不充分。
结构判定
- 五段有缺失，或任一段只有标题没有可执行内容：
failed。
- 五段都在，但 Goal/Non-Goal、Core Path、Value Alignment 无法约束执行：
failed。
- 只有在五段都完整且充分时，才能进入基线验证。
第二步：基线验证
只在结构通过后执行。
- 提取
Assumptions 中每一条可验证事实。
- 用最新基线做只读核对。
- 对每条不成立的 assumption，继续判断它属于哪一类：
- 暂时不成立，但随着后续基线推进仍可能自然成立。
- 已暴露出 Spec 重大歧义、方向冲突，或 assumption 本身已经不再描述当前问题。
判定矩阵
| 条件 | 结论 | 含义 | 下一步 |
|---|
五段结构完整且充分，Assumptions 当前成立 | pass | Spec 可继续推进 | 进入后续执行流程 |
结构完整且充分，但部分 Assumptions 当前不成立，且仍可能被后续基线推进自然满足 | waiting_assumptions | 先等待，不是失败 | 记录当前卡住的 assumption，并允许后续重验 |
| 五段结构不完整或不充分 | failed | Spec 自身不可执行 | 失败上报给上层重新规划或重写 Spec |
Assumptions 不成立，且已表明 Spec 与当前基线方向冲突、前提失效、或存在重大歧义 | failed | 不是等一等就会恢复 | 失败上报给上层重新规划 |
waiting_assumptions 与 failed 的分界
判成 waiting_assumptions，通常意味着：
- Spec 的推理链路仍然成立，只是依赖的基线事实尚未出现。
- 可以清楚说出“还差哪个事实成立”。
- 一旦该事实由其他 Task 推进出来，这个 Spec 仍然有意义。
判成 failed，通常意味着：
- 当前 Spec 缺少关键约束，执行层无法稳定判断怎么做。
- Assumption 描述的现状已经不是当前问题，继续等待也不会自然恢复。
- 最新基线已经沿着别的方向收敛，原 Spec 的目标或路径失去意义。
- 出现重大歧义，且无法从 Value Alignment 中得到稳定裁决。
明确禁止
- 不得用
spec_commit 判定 Spec 是否过期。
- 不得用
base_commit 判定 Spec 是否过期。
- 不得因为“assumption 现在不成立”就直接判
failed。
- 不得因为五段标题齐全，就跳过“是否充分”的判断。
- 不得把本 skill 扩展成写 Spec、写 implementation plan、改代码、PR 跟进或调度排序。
常见误判与红旗
| 误判 | 正确处理 |
|---|
Assumptions 还没成立，所以 Spec 失败了 | 先问“后续基线推进后是否可能自然成立”；若可能，应为 waiting_assumptions |
| Spec 有五个标题，所以结构没问题 | 还要检查每段是否足以约束执行；空洞内容仍是 failed |
| 旧 Spec 对应的 commit 已落后，所以 Spec 过期 | commit 不是判据；只看最新基线下 assumptions 是否成立、Spec 是否仍清晰有效 |
| Core Path 写了几个文件和步骤，已经够了 | Core Path 必须交代概念变化、主路径和备选路径取舍 |
| Value Alignment 写“尽量简单”就够了 | 需要冲突场景下的价值排序，否则无法支撑无人值守裁决 |
出现以下红旗时，应优先考虑 failed 而不是硬做：
- 无法把缺失点定位到具体哪条 assumption。
- 需要人工澄清才能知道 Goal 与 Non-Goal 的边界。
- Core Path 只有文件清单，没有概念推理链路。
- Value Alignment 无法解决真实冲突。
快速参考
- 先结构，后基线；顺序不要反。
- 结构不够：直接
failed。
- 结构够了但 assumptions 暂未满足：优先判断
waiting_assumptions。
- 只有在“等下去也不会自然恢复”时，才把 assumption 问题判成
failed。
- 过期判断只看最新基线与 assumptions，不看 commit。
简短示例
示例 1：等待，不是失败
- Spec 假设“
tasks 已有 dependencies 字段，执行层可重写它”。
- 最新基线里该字段还不存在，但上游 Task 正在推进该数据模型改动。
- 五段结构本身完整，Core Path 与 Value Alignment 都清楚。
结论：waiting_assumptions。
示例 2：真正失败
- Spec 说“基于
spec_commit 判断是否过期，再决定是否继续执行”。
- 这与当前 Task 模型文档明确冲突，且核心判断机制本身错误。
结论：failed。
示例 3：形式完整但内容空洞
- 五段标题都在。
- 但 Core Path 只有“修改 A 文件、补 B 测试”，Value Alignment 只有“优先保持简单”。
结论：failed。
