hermes - 💡(How to fix) Fix AION Kanban 总控失效修复 / AION Kanban control-issue guardrail

问题 / Problem

我们现在最大的失败点不是“不会做任务”，而是任务做着做着就漂移：

• 聊天里说过的共识，没有落到 GitHub 里
• 总控任务没有变成唯一主状态源
• 每个任务缺少明确的目标 / 阶段 / 证据 / 下一门槛
• 任务结束后没有 AAR 和下一步收口，导致下一轮重新发散

这会直接造成：做了几个任务以后，没人知道当前到底做到哪里、下一步该接什么、哪些边界不能碰。

解决方案 / Solution

把 GitHub issue 作为 AION / Kanban 的唯一可追溯控制面，聊天只做沟通，不做最终存档。

1) 每个任务必须先有“总控 issue”

总控 issue 必须明确写出：

• 目标 / objective
• 当前阶段 / stage
• 负责角色 / owner
• 允许范围 / allowed scope
• 禁止范围 / forbidden scope
• 验收标准 / acceptance
• 证据要求 / evidence required
• 下一门槛 / next gate
• 停止条件 / stop conditions

2) 所有“我们已经同意的内容”都要写回 GitHub

规则：

• 只要你明确同意了方案，我就把它写成 GitHub issue / 子 issue / 复盘 issue
• 聊天里的结论不能算最终记录
• 后续执行必须以 GitHub issue 链为准，不以聊天记忆为准

3) 总控任务不再是“抽象任务”，而是“任务账本”

总控 issue 要承担这几个功能：

• 记录当前主线
• 记录每个子任务的阶段和边界
• 记录谁负责、谁审、谁卡门
• 记录每一轮完成证据
• 记录下一步只做什么、不做什么

4) 每个任务收口必须带 AAR

每次任务结束，必须强制补齐：

• 做了什么
• 没做什么
• 为什么
• 证据是什么
• 下一步选项是什么
• 哪些地方可能再次漂移

5) 任何“新任务开始”前，先回到总控 issue

新任务开始前必须检查：

• 当前总控 issue 是否还有效
• 当前阶段是否已变
• 之前的结论是否被新事实推翻
• 这次任务是否只是旧任务的下一阶段

最小落地规则 / Minimum operating rule

以后所有已同意的重要结论，默认进入 GitHub issue。

如果没有 issue，就说明还没真正进入工厂； 如果有 issue 但没有阶段 / 证据 / 下一门槛，就说明还没真正可执行； 如果没有 AAR，就说明这次任务没有闭环。

验收标准 / Acceptance

• 每个重要任务有 GitHub issue 作为唯一主记录
• issue 中明确目标、阶段、边界、证据、下一门槛
• 聊天里的共识会同步进 issue
• 每次任务收口都有 AAR
• 不再出现“做了几个任务就不知道做到哪里”的漂移

Why this fixes the drift

Because the real problem is not execution speed; it is state loss.

GitHub issue chain gives us:

• persistent state
• stage tracking
• evidence trail
• handoff boundaries
• auditability

Without that, every new task starts from memory, and memory is exactly where drift happens.

Next step

If you agree, the next action is to define the 总控 issue template and make it mandatory for AION / Kanban tasks.