[metadata-protocol] seed-loader:roll-up summary 重算耗尽重试后只记 warn 且不计数 —— 落盘的汇总值与事实不符,seed 仍报 success: true

[xuyushun441-sys]

发现于 #4729(seed-loader 的日志级别盘点)。本条不在 #4729 的判据(「计数为错、日志为 warn」)内 —— 它压根不计数 —— 所以只记录,不在那个 PR 里动。

现象

packages/metadata-protocol/src/seed-loader.ts 的 writeRecoveringSummary():

private async writeRecoveringSummary(fn: () => Promise<T>): Promise<T> {
  try {
    return await fn();
  } catch (e: any) {
    if (e?.code === 'ERR_SUMMARY_RECOMPUTE') {
      this.logger.warn(
        '[SeedLoader] roll-up summary recompute failed after retries; records were written (summary values may be stale)',
        { failures: Array.isArray(e.failures) ? e.failures.length : undefined },
      );
      return e.written as T;
    }
    throw e;
  }
}

行本身的判断是对的(framework#3147:记录确实写进去了,不能重写,否则重复)。有疑问的是后果的等级:roll-up summary 是一列已持久化的派生值,重算耗尽重试后,库里存着的汇总数与被汇总的明细不一致,而:

• 这次 seed 不计一条错(errored 不动、allErrors 不动),result.success 仍是 true;
• 控制台上唯一的痕迹是一行 warn。

判定问句(#4632 / AGENTS.md「Degradation log levels」)

降级之后系统对外是否仍然「正常」,而某个声称已持久化的东西实际不对?

我的读法是 是:一切看起来干净(success: true,行数全对),而一列已落盘的汇总值是错的,并且不会自己修 —— 直到下一次触发该 summary 重算的写入才可能纠正,而 seed 之后未必还有这种写入。这正是 #4420 的形态(那次是 in-flight approvals,这次是汇总列)。

反方也有分量,所以我不想擅自改:

1. 记录本身是真的落盘了,和 [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420「写入完全没发生」不同;
2. 提到 error 会让一次除汇总外全部成功的 seed 打出 error 行,可能属于 AGENTS.md 明确警告的「过度适用」(把人训练成跳过 error);
3. 也可以不动日志级别,而是把它计入结果(新增一个 summariesStale 计数或一条 ReferenceResolutionError),让结果对象诚实,日志维持 warn。

期望(需要维护者拍板)

在下面三条里选一条并落地 + 加测试:

• A 提到 error,文案说清后果(<object> 的 roll-up summary 列现在是陈旧值,明细与汇总不一致,而 seed 报告 success)与修复动作(修掉下面的重算错误后重跑 seed / 触发一次该对象的写入以重算);
• B 保持 warn,但计入结果对象(新增计数字段),让调用方能发现;
• C 判定其为「功能性降级」,维持现状,并在注释里写明为何不属于 [convention] best-effort 降级导致"看起来正常、实则不持久"时不应记 warn——把 #4460 的点状修复定成规则 #4632 的第二类,免得下一个人再翻一遍。

我的倾向是 A + B:后果确实是「已落盘的数据不对」,而且计数与日志级别应当一致(#4729 的同一条论点)。但这会改变一次成功 seed 的控制台输出,属于产品口径,不该由实现方顺手决定。

未认领。

[claude]

维护者已裁:A + B(2026-08-04,经主 backlog PM 呈报后照准)

• A:提到 error,文案带后果(该对象 roll-up summary 列为陈旧值、明细与汇总不一致而 seed 报 success)与修复动作;
• B:计入结果对象(如 summariesStale 计数),调用方可编程发现;success 语义是否翻转按 B 的实现证据定 —— 汇总列错数据不算「成功得干净」。

摘 needs-user-decision,回队,本轮即派。

---

Generated by Claude Code

[claude]

🔒 认领:PM 循环第 7 轮(维护者裁决落地批)
会话:session_01NrmBxj8rK2uGCnh9aipjwX(账号 xuyushun441-sys)
分支:claude/issue-4998-seed-summary-stale-loud
Worktree:objectstack-issue-4998
域:domain:engine
文件面:packages/metadata-protocol/src/seed-loader.ts(writeRecoveringSummary)及同目录测试

⛔ 硬约束:spec/** 及生成物零改动;protocol.ts 零改动;releases/ 零触碰。
全局在飞不相交已核:与 #5025(sys-metadata-repository.ts + 基线)、#4762(packages/lint)、本批其余两单文件面均不交。

---

Generated by Claude Code

[claude]

PM 中间处置:子问题即裁,B 半边的 spec 例外呈维护者

1. success 不翻转 —— 确认,按 dev 证据即裁(维护者原裁决明言此项交实现证据):三个消费方证据决定性 —— wire 返回结构上无法解释 false 的原因、boot banner 会打出「true and useless」行、marketplace install 会把「行全部落库」的一次安装判失败,直接违反 framework#3147 的「records WERE written」不变量。success 语义 = 行是否落库;新计数字段承载陈旧信号。
2. B 半边(机器可读计数)撞 spec 冻结:结果类型为 spec 定义(seed-loader.zod.ts),非包内。dev 的方案 A(为本单开一个窄例外:summariesStale + totalSummariesStale,逐字镜像 seed-loader: a dropped reference FIELD is invisible in the summary — totalErrored counts dropped records only, so the boot banner reads clean #3932 referencesDropped 先例,纯增量 + default(0),~10 行手写 + 两个生成物重生)已呈维护者拍板;方案 C(包内私加字段、契约分叉)按 PD#12 弃。
3. 拍板前本单 PARK;half A 的实施笔记(含 durability 门禁需先具名提取 fn() 才能真保护的关键发现)已在停工报告里,解锁即续。

---

Generated by Claude Code

[claude]

维护者已裁(2026-08-04):批准本单的 spec 窄例外,取 dev 方案 A

• summariesStale(SeedLoadResultSchema)+ totalSummariesStale(summary),逐字镜像 seed-loader: a dropped reference FIELD is invisible in the summary — totalErrored counts dropped records only, so the boot banner reads clean #3932 referencesDropped 先例,纯增量 + default(0),连同两个生成物重生 —— 本车道单次例外,随本 PR 关闭;
• success 不翻转(已按实现证据即裁);
• half A(error 级 + durability 门禁具名提取)同 PR 落地。

原 dev agent 带上下文续做。⚠️ 入队前按纪律 A 处理 spec 生成物(在飞 #5042/#5043/#5012 同在动 spec)。

---

Generated by Claude Code