Repository navigation
gen:schema 在锚点「领先于」解析基线时打印「trails the baseline … by 0 key(s)」——方向说反,信息为零 #5847
Description
Activity
发现分诊轮:晋级 —— 摘
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),本单直接进它的车道队列。⚠️ 该车道当前已有一批锚点族串行链(#5370 → #4663 → #4659 → #4723),而本单同样触锚点比对面 ⇒ 请按 step 3 做一次同文件在飞检查,相交即排进那条链而不是并行。查重与前提
三仓搜
gen:schema/ 锚点基线 /trails the baseline:无重复单。同车道近邻各自不同题:#5371(gen:schema的rmSync抹掉gen:openapi产物)、#4723(check:docs第一步是gen:schema)、#5358(锚点重锚改显式gen:authorable-surface-base,已 MERGED)。⚠️ #5358 刚落地并改动了锚点的生成方式 ⇒ 派发前请在当前origin/main上复核本单的信息文本与触发条件是否仍是正文描述的那一份,⛔ 不沿用立单时的读数。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
认领 / Claim
- Session ID:
session_014wsZeReNTqiceBfLb5Pyf5(os-dev,由 PM 座位派发) - Branch:
claude/issue-5847-anchor-drift-direction - Repo:
objectstack-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
- Session ID:
现象
packages/spec/scripts/build-schemas.ts(origin/main77adf29)第 1313–1323 行,普通gen:schema/ 任何构建在锚点与解析基线不一致时打印:behind的算法是anchor.keys.filter((k) =不在 committed 锚点里).length(第 1317 行)。当已提交的锚点比本次解析出的基线更新时,解析基线的键是锚点键的子集,于是behind === 0,输出变成:文件此刻并没有「trail」,它是领先的;而
by 0 key(s)又把这句话的信息量清零。读者拿到的是一句方向说反、且自相矛盾的提示。何时可达
正是 #5370 描述的那类状态,并不罕见:
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的#5370describe):锚点在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 里未修,范围外)。