[Bug] update_goal 反复报 stale 错：模型拿着过期 revision 无限重试，不自愈

[a1980881039]

现象

正常会话里（工具链完整、没切模型、没丢工具、非极简 preset），update_goal 100% 失败，只会一直撞同一条：

Error: stale goal ref "goal-967e3963-081b-4371-aa04-4e9699961b54" revision 1;
       current is "goal-967e3963-081b-4371-aa04-4e9699961b54" revision 2

revision 是 CAS 乐观锁，每次成功的 create/edit/pause/resume/complete/block 都 +1。模型攥着会话早期读到的旧值重发，就永远撞同一面墙 —— 这正是「目标更新一直报错、一直报错」的真实形态。而且它倾向于认为「是参数格式不对」，于是反复换格式重试，而不去读错误里那半个答案。

自愈路径其实是有的：照抄报错里的 current is "<id>" revision <N> 原样重发，一次就通。

最小复现

1. create_goal(objective="x")                                     → revision 1
2. update_goal(goal_id=<id>, revision=1, action="edit", objective="v2")
                                                                  → 成功，revision 2
3. 仍然用 revision=1 发同一条 update_goal                          → stale
4. 反复执行第 3 步                                                 → 每次都同样报错，永不成功

三个我认为值得改的点

① goal_id 写错与 revision 过期返回同一条错误。
传一个根本不存在的 id，回来的还是 stale goal ref ... current is "<真实id>" revision N。调用方无法区分「抄错 id」和「版本旧了」，而这两种情况的正确动作不同。

② max_goal_rounds: 0 被静默当成「没传」。
工具层 hasRoundCap(value) { return value !== void 0 && value !== 0; }，于是 0 既不报「值非法」也不改上限，而是掉进 goal edit requires objective and/or maxGoalRounds —— 错误信息指向了一个完全无关的原因。

③ 失败反馈没有把模型推向自愈。
stale 报错里其实已经带着正确答案，但它是夹在长句里的自然语言。建议直接返回结构化的当前 ref（{ current: { id, revision } }），或给出可直接复制的重试参数。

建议

• stale 错误返回结构化 current ref / 可复制的重试参数
• 区分 not-found 与 stale revision，给出不同错误码
• max_goal_rounds 为 0 或负数时显式报非法值，不要退化成「未提供」
• 文档侧把「先 get_goal 再 update_goal，复制精确 id+revision」写成硬规则（README 提过，但实测不足以让模型照做）

与已有讨论的区别

#8331（goal 工具中途全部变 unknown tool）、#2027（极简 preset 缺 update_goal 导致跑满 maxGoalRounds）讲的都是工具不在。本贴是工具都在、人类正常对话，update_goal 仍然 100% 失败。

环境：DSH 0.2.0-rc.2 / Windows / profile desktop。

想确认一下：是否有人在没有模型切换、没有工具丢失的会话里也复现过同样的持续 stale？这能把「设计如此」和真 bug 区分开。

[luoyukun3-oss]

源码级核对（本机 dsh-goal / dsh-tool-goal 都是 0.1.7-rc.2，与你 0.2.0-rc.2 同代，行为可比）：

① max_goal_rounds: 0 —— 属实，而且是有意的
dsh-tool-goal/lib/index.js:209

function hasRoundCap(value) { return value !== void 0 && value !== 0; }

注释原文是 "rather than a strict-schema zero filler" ⇒ 0 被有意当成"严格 schema 的占位零"。
所以你说的"错误信息指向无关原因"（goal edit requires objective and/or maxGoalRounds）成立，
但更可能的修法是给 0 一条专门的非法值报错，而不是把 0 当成合法上限。

② 「传错 id」与「revision 过期」共用一条 —— 属实，机制在这里
dsh-goal/lib/index.js:759 的 expectCurrent()：

if (state === null) throw new GoalError("no current goal", "GOAL_NOT_FOUND");
if (ref.id !== current.id || ref.revision !== current.revision) throw new GoalError(`stale goal ref …`, "GOAL_STALE_REVISION");

它是对比而不是查找 ⇒ id 写错时同样落进第二条。

③ 但「给不同错误码」这条已经部分实现：错误带 code（GOAL_NOT_FOUND / GOAL_STALE_REVISION），
只是 id 不匹配被归进了后者 ⇒ 真正要改的是把 id 不匹配归到 not-found（或新增一个码）。
一个可复核实测：没有 goal 时 get_goal 返回 {"goal":null}，此时 update_goal 会走 not-found 分支。

---

怎么解决（按代价从低到高）

A. 调用侧硬规则（零改动，今天就能生效）
每次 update_goal 之前先 get_goal，复制精确的 id + revision。README 提过但实测不够 ——
要让它真生效，得写进项目级硬规则（AGENTS.md / 开场注入的"硬要求"节），而不是工具描述里：
实测模型对工具描述里的一行提示基本不照做，对每轮注入的硬规则明显更服从。
另外 max_goal_rounds 干脆别传 0（省略即可），能绕开那个 zero-filler 分支。

B. 自愈中间件（能根治"反复撞墙"，附一个已离线验证的原型）
tools/post-execute 拿得到 exec 与 result。注意两条硬约束（源码）：
① 失败的 result 不允许替换 value（dsh-tools/lib/index.js:3518）⇒ 不能"改成成功"；
② 官方注释写明 accept 是"保持成功、可替换 content"，而 block 会把调用变成 isError、内容用 feedback。
所以正确做法不是替它重试，而是把这条错误本身改写成"下一步动作"：

export const name = 'goal-stale-heal';

const STALE_RE = /stale goal ref "([^"]+)" revision (\d+); current is "([^"]+)" revision (\d+)/;

export function apply(ctx) {
  ctx.on('tools/post-execute', async (exec, result, next) => {
    const decision = await next();
    if (!result || !result.isError) return decision;
    const text = String(result.content ?? result.value ?? '');
    const m = STALE_RE.exec(text);
    if (!m) return decision;
    const [, sentId, sentRev, curId, curRev] = m;
    return {
      kind: 'block',
      feedback: [
        '目标引用已过期（goal revision 是 CAS 乐观锁，每次成功操作 +1）。',
        `请原样重发刚才那次调用，只把两个参数换成报错给的当前值：`,
        `  goal_id = "${curId}"`,
        `  revision = ${curRev}`,
        `（你刚才发的是 goal_id="${sentId}" revision=${sentRev}；其余参数不变。）`,
        '已经过期的那份参数别再试第二种格式 —— 换格式不会让它变新。',
      ].join('\n'),
    };
  });
}

本机离线验证过 6 个用例（stale 改写 ✓ / 无关错误透传 ✓ / 成功结果透传 ✓ / 尊重 next() 的决定 ✓ /
id 写错形态也给出真实 id ✓ / 语法检查 ✓），未在真正装载的环境里跑过（只是 API 与逻辑核对）。
装配方式与其它 Cordis 插件相同；按本机先例，改插件通常不必重启。
想更主动还可以用 post-execute 的 deny/steer（Stop hook 就是靠 deny 让 agent 续跑）。

C. 工具侧（要改内核，才算真修）
expectCurrent() 改成先按 id 查找：找不到 ⇒ GOAL_NOT_FOUND；找到但 revision 旧 ⇒ GOAL_STALE_REVISION。
这一改同时解决你 ① 与 ③（两类可分、语义正确）。

---

至于你问的复现范围：我这边答不了（本会话没建过 goal，不便改动会话状态来造）。
但从上面的分支看，持续 stale 与模型切换、工具丢失都无关 —— 只要某次成功后 revision 递增，
而调用方仍攥着旧值，就会 100% 撞同一面墙；自愈路径确实就是照抄报错里的 current 原样重发。

[PerryLink]

你的诊断结构上成立——而错误信息里已经把答案给出来了，这正是可修之处

1. revision 确实是持久字段（核实）

packages/goal/goal/src/domain.ts:50    readonly revision: number
packages/goal/goal/src/fold.ts:102-103 折叠字段集含 revision
                        :109           revision 由 positiveInteger 校验
                        :119-120      clear 墓碑必须**恰好**含 id 与 revision

⇒ 也就是说：revision 是目标领域里的一等字段，语义与你说的一致（CAS 乐观锁）——每次成功变更 +1，过期值必然被拒。

2. ⭐ 但真正该修的一点是：错误里已经带着"当前 revision"

你贴的报错长这样：

stale goal ref "goal-…" revision 1;       current is "goal-…" revision 2

⇒ 正确答案就在这句话里（current is … revision 2）。⇒ 而模型却去改参数格式。⇒ 这说明缺陷不在"锁太严"，而在接口要求调用方自己维护一个它无法可靠维护的状态。

建议诉求（两条，第二条是根治）：

1. 自愈：收到 stale 时工具侧自动重读当前 revision 并重试一次（而不是把这事推回给模型）；
2. 取消对调用方的 revision 要求：既然服务端自己知道当前值，就让工具内部完成 compare-and-set（例如以 id 定位、服务端读当前 revision），把 revision 从入参降级为只读输出。

第 2 条的价值：模型无法可靠地记住会话早期读到的值（这正是你观察到的"攥着旧值重发"）⇒ 把不可靠的负担从模型移走，比"多加一次重试"更彻底。

3. 你观察到的"改格式而不读错误"值得单列

你写：它倾向于认为"是参数格式不对"，于是反复换格式重试，而不去读错误里那半个答案。⇒ 这是可操作的证据：它说明当前错误信息的形态没有把"下一步该做什么"变成可执行的动作。⇒ 建议诉求里加一句：

stale 报错应当包含可直接采用的下一步（例如"请以 revision N 重发"），或由工具自动修正。

4. 请补三样

1. 是否 100% 必现（你写"100% 失败"⇒ 请说明是"任何 update_goal 调用"还是"某类变更"）；
2. create 之后的第一次 update_goal 是否也失败（若是 ⇒ 说明 revision 在创建时就已被写入并 +1，模型从第一次就读到旧值）；
3. 版本（当前最新 0.2.1-alpha.1）。

[mcmichealkaluna-debug]

复现（DSH，2026-10-23 本机会话）：

1. get_goal 返回 revision=1；
2. 紧接 update_goal action=edit（同一 revision）报 stale goal ref "…" revision 1; current is "…" revision 2——期间系统把 goal 置 blocked 并 +1 revision；
3. 第二次 edit（rev=2）返回成功，但同一响应里报 stale … revision 2; current is 3；
4. 再 resume 又因 round-limit 被拒（与 目标轮次上限调高后，round-limit 封堵不重算：phase 停在 blocked、blockedReason 仍写旧上限 #7711 同因）。

建议：

• 报错里直接回显当前 phase / blockedReason / revision，少一次往返；
• 允许“强制更新（忽略 revision）”或自动重试一次；
• 与 目标轮次上限调高后，round-limit 封堵不重算：phase 停在 blocked、blockedReason 仍写旧上限 #7711 联动：edit 提 max 时同步清 round-limit。