Repository navigation
gen:schema 在锚点「领先于」解析基线时打印「trails the baseline … by 0 key(s)」——方向说反,信息为零 #5847
Description
现象
packages/spec/scripts/build-schemas.ts(origin/main 77adf29)第 1313–1323 行,普通 gen:schema / 任何构建在锚点与解析基线不一致时打印:
ℹ️ authorable-surface.base.json trails the baseline at <rev> by <behind> key(s)
— expected, and not an error: …
behind 的算法是 anchor.keys.filter((k) = 不在 committed 锚点里 ).length(第 1317 行)。当已提交的锚点比本次解析出的基线更新时,解析基线的键是锚点键的子集,于是 behind === 0,输出变成:
ℹ️ authorable-surface.base.json trails the baseline at 9ce056a879ef by 0 key(s)
文件此刻并没有「trail」,它是领先的;而 by 0 key(s) 又把这句话的信息量清零。读者拿到的是一句方向说反、且自相矛盾的提示。
何时可达
正是 #5370 描述的那类状态,并不罕见:
- merge 停在未 commit 时的任意一次构建 ——
merge-base(HEAD, origin/main)落在分支的旧分叉点,而工作树里的锚点来自 main(os-regen 驱动把该路径解析为 OURS/THEIRS 后就是这个形状); - 分支分叉早于锚点推进,随后
git checkout origin/main -- packages/spec/authorable-surface.base.json或 rebase 带入较新锚点。
实测(#5370 的沙箱夹具,build-schemas-check-mode.test.ts 的 #5370 describe):锚点在 tip、HEAD 分叉于 older 时,gen:schema 退出码 0 并打印上述 by 0 key(s)。
影响与定性
纯提示文案,退出码不变、不写文件、无门禁后果 —— 所以按 observation-class 归档,不带 pm:queue。记录理由是:#5370 之后 --update-base 会在这个状态拒绝并解释方向,而同一状态下的普通构建仍在用一句反向措辞描述它,两者读起来会互相矛盾。
可能的修法(不预设)
在 else if (drifted) 分支里按方向分叉:锚点键 ⊇ 解析基线键时说「锚点比本次解析出的基线新(HEAD 的 merge base 落后于锚点)」,否则维持现有 trails 措辞;或直接复用 #5370 引入的 merge-base --is-ancestor 判定给出方向。
发现于 #5370 的实现过程(PR 里未修,范围外)。
Activity
os-zhuang commentedon Aug 6, 2026
发现分诊轮:晋级 —— 摘
finding,改pm:queue;domain:spec-tooling保持不变。理由(一行):这不是观察类,而是 SKILL step 0 里「scoped tooling/gate fix」那一条 —— 一个门禁自己的诊断输出把方向说反,落点单一(
gen:schema的锚点/基线比对信息)、修法机械、验收一句话说得清(锚点领先时打印的方向与数量正确),没有任何待裁决的语义。为什么不该继续持有
门禁的诊断文本是排障时唯一的一手读数。方向说反(领先说成
trails … by 0 key(s))比没有消息更糟:它把「基线该更新了」误导成「什么都没差」,而下一个撞上它的人会照着这句错话去查一个不存在的问题 —— SKILL Operational note 6「命令本身是否在回答你以为的那个问题」的同族形状,只不过这次说谎的是我们自己的工具。by 0 key(s)这个读数本身已经在自陈信息量为零。落点与车道
domain:spec-tooling是立单时就打对的(packages/spec/scripts/**/ 门禁类)⇒ 本轮不改,只补 pm-state。座位表记该座位在任(session_01559M8FVm6W6vDLABL3jvdW),本单直接进它的车道队列。查重与前提
三仓搜⚠️ #5358 刚落地并改动了锚点的生成方式 ⇒ 派发前请在当前
gen:schema/ 锚点基线 /trails the baseline:无重复单。同车道近邻各自不同题:#5371(gen:schema的rmSync抹掉gen:openapi产物)、#4723(check:docs第一步是gen:schema)、#5358(锚点重锚改显式gen:authorable-surface-base,已 MERGED)。origin/main上复核本单的信息文本与触发条件是否仍是正文描述的那一份,⛔ 不沿用立单时的读数。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
os-zhuang commentedon Aug 7, 2026
认领 / Claim
session_014wsZeReNTqiceBfLb5Pyf5(os-dev,由 PM 座位派发)claude/issue-5847-anchor-drift-directionobjectstack-ai/objectstack,lanedomain:spec-tooling范围严格限定为
packages/spec/scripts/build-schemas.ts的锚点漂移提示文案方向:退出码、写文件行为、门禁判定一律不变。若发现需要改变门禁「判定」本身,会停下来回报而不是顺手改。先做前提复核:立单时引用的
origin/main 77adf29第 1313–1323 行已因 PR #6200(#5371)与 PR #6256(#5898)两次改动而失效,会在当前origin/main上重新定位代码并回报前提是否仍成立。Generated by Claude Code
fix(spec): packages/spec/scripts/** 进入类型检查程序 —— 新增 tsconfig.scripts.j…
fix(spec): re-anchor the authorable-surface deletion gate when merge-…