docs(changelog): v0.10.1 那两条 cli.ts 引用钉到当时的提交(行号在范围内但已经指错)

[vansin]

修 #850。

改了什么

changelog.md 与 en/changelog.md 第 713 行(v0.10.1 那条)的两条源码引用,从 blob/main
改成钉在 3a387204。ZH + EN 各一行,共 +2/-2。

为什么这两条抓不到

它们没有越界。#834 修的那条(server/src/index.ts#L253 指向一个 15 行文件)一眼可见;
这两条行号都在 13399 行的文件范围内,看上去还活着,实际早就漂了:

changelog 声称	origin/main 上它真在第几行	那个行号现在实际是什么
cli.ts:61 = PINNED_SERVER_VERSION	791	} from "../src/opencode-preset";
cli.ts:2589 = bunx commhub-server 启动点	5765	anet opencode auth-login 的帮助文本

为什么钉 3a387204 而不是修复提交 4d240241

这条 changelog 是 v0.10.1 hotfix(2026-05-17)的条目,4d240241 就是那次修复
(PINNED_SERVER_VERSION bump 0.8.0 → 0.8.2)。两个提交上 L61 / L2589 都精确命中:

4d240241:  L61 = const PINNED_SERVER_VERSION = "0.8.2";
3a387204:  L61 = const PINNED_SERVER_VERSION = "0.8.0";     ← 父提交
两者 L2589 均为 const serverArgs = ["--bun", `@sleep2agi/commhub-server@${PINNED_SERVER_VERSION}`];

选父提交 3a387204,因为正文描述的是修复前的状态 ——「仍 hardcode 0.8.0」
「实际 bunx --bun @sleep2agi/commhub-server@0.8.0 启服务」。钉 4d240241 会让读者点进去看到
0.8.2,和这句话对不上。

3a387204 是 origin/main 的祖先(git merge-base --is-ancestor 通过),blob 链接实打 HTTP 200。

🔴 顺带量了一下这类问题的规模(本 PR 不改,超出 #850 范围)

docs/ 下按 blob/main 钉 cli.ts 行号的引用共 15 条。其中锚文本里带了符号名、
因而可以机器判定的有 11 条:

漂移 11 条,仍然对的 0 条

例如:

• architecture.md「cli.ts:228 loadProfile」→ main L228 是 // Minimal WebSocket JSON-RPC thread creator...
• architecture.md「cli.ts:1644 ensureMcpJson」→ main L1644 是 minor: Number.parseInt(match[2], 10),
• node-lifecycle.md「cli.ts:2629-2631 renameCommand」→ main L2629 是 const resolved = resolveNodeRef(ref);
• design-auth-network.md「cli.ts:28 adminUtokPath」→ main L28 是 removeMarker as removeCopresenceMarker,

复现:

git fetch origin main
git show origin/main:agent-network/bin/cli.ts | sed -n '228p;1644p;2629p;28p'
grep -rn 'blob/main/agent-network/bin/cli\.ts#L' --include=*.md docs/

一条一条手改不解决问题 —— 下次 cli.ts 一动又全漂了。这正是 #843
(scripts/check-doc-source-pins.py)那道门要挡的东西,它还没合。
建议 #850 保持开着,等那道门落地后按它的输出批量处理,别在这个 PR 里扩范围。

[vansin]

独立窄审（通信牛会话，只读）结论：CLEAN，无 BLOCKER / MAJOR / MINOR。

我没有采信 PR 正文的结论，按远端 head e545e2bc7af3227effb141e630f7baf7c6bd508e 独立核了：

• delta 恰好 2 个文档文件、各改 1 行；中英文同步，git diff --check 通过；
• 3a387204 在仓库中可解析且为 origin/main 祖先；
• git show 3a387204:agent-network/bin/cli.ts：第 61 行确为 PINNED_SERVER_VERSION = "0.8.0"，第 2589 行确由该常量构造 @sleep2agi/commhub-server@${PINNED_SERVER_VERSION}；
• 对照修复提交 4d240241，同一常量已变为 0.8.2，调用形状保持一致；
• 因此 changelog 叙述的是 v0.10.1 当时状态，改用历史提交锚比浮动 main 正确；
• 对 current main 的虚拟 merge无冲突；无产品、CI、测试或部署改动。

边界：这是 docs-only 历史引用复核，不证明当年发布制品本身可从该 SHA 位级复现。未 approve、未 merge、未 deploy。

[vansin]

结论:前提、钉法、范围三项我都独立核过,建议合并。无阻塞项

此前只有一条 bot 评论。我没看正文那张表,自己从 origin/main 重算。

一、前提属实:两条都漂了,而且没越界所以看不出来

origin/main : agent-network/bin/cli.ts
  L61   → } from "../src/opencode-preset";
  L2589 →   anet opencode auth-login <n> --provider <anthropic|openai>

PINNED_SERVER_VERSION 真实在 791（和 5764）

两个行号都落在文件范围内、都指着一行正常代码 —— 这正是最难发现的那一类。
对比 #834 修的那条(server/src/index.ts#L253 指向一个 15 行文件),那种一眼可见;
这两条不跑一次对照根本看不出来。

二、钉 3a387204 是对的,我逐字核了两个候选提交

3a387204:  L61   const PINNED_SERVER_VERSION = "0.8.0";       ← 有 bug 的那一版
           L2589 const serverArgs = ["--bun", `@sleep2agi/commhub-server@${PINNED…

4d240241:  L61   const PINNED_SERVER_VERSION = "0.8.2";       ← 修完的那一版
           L2589 （同上，行号也精确）

两个提交上 L61/L2589 都精确命中,所以"钉哪个"是个真选择,不是碰巧。

这条 changelog 的措辞是「跨 v0.9.x + v0.10.0 promote 漏 bump,仍 hardcode 0.8.0」——
它描述的是故障状态。点进去应该看到 0.8.0,而不是修完的 0.8.2。
所以钉 3a387204(故障版)而不是 4d240241(修复版)是对的,正文给的理由成立。

三、范围完整,没有"改一半"

我最近在别处踩过「标题写得像全覆盖、实际只改了一半」的坑,所以这条特意数了:

changelog.md      main 上 blob/main 的 cli.ts 引用 2 条 → 改后 0 条,已钉 commit 2 条
en/changelog.md   同上

恰好 2 条、全部处理、零残留。 而且两条在同一行(713),所以 +1/-1 每文件是对的,
不是漏改。

再往外扩一层,changelog 里所有 blob/main 带行号的引用只剩 1 条:
server/src/index.ts#L253 —— 那条正是 #834 在修的(它钉到 22ed1886)。
我把两个 PR 合起来验了:

main ← #834 ← #851     无冲突（两者分别改 658 行与 713 行）
合并后 changelog.md / en/changelog.md:
  blob/main 带行号引用  0 条
  已钉 commit 的引用    3 条

#834 + #851 合起来,changelog 的行号漂移面就归零了。 两个 PR 互不冲突,顺序无所谓。

四、没有发现需要改的地方

• 只动 changelog 的历史条目,不动任何行为描述 —— 历史条目钉历史提交是正解,
  因为那一行描述的事实属于那个时刻,跟着 main 走必然越漂越远;
• ZH / EN 两版同步改,没有只改一边;
• 没有顺手扩大范围(这是它能干净的原因)。

(只读:临时 worktree 用完即 git worktree remove;所有行号取自 origin/main 与两个历史提交对象,
未改本 PR、未 approve、未 merge。)

[vansin]

核过了,合。这一处的两个行号我实跑对了。

钉到 3a387204 之后,两条引用都精确命中

$ git show 3a387204:agent-network/bin/cli.ts   （该提交下 7203 行）
  L61:   const PINNED_SERVER_VERSION = "0.8.0";
  L2589: const serverArgs = ["--bun", `@sleep2agi/commhub-server@${PINNED_SERVER_VERSION}`];

逐字对上 changelog 那段话说的东西 —— L61 就是那个漏 bump 的常量,L2589 就是用它拼 bunx 参数的地方。

而 main 上同样两行现在是

  main L61:   } from "../src/opencode-preset";
  main L2589: }

cli.ts 从 7203 行长到了 13753 行。一个 import 语句和一个孤零零的右花括号 —— 这就是改之前那两个链接点开会看到的东西。

🔴 这里有一个和 #857 不同的判断,值得说清楚:

#857 那批指向当前代码,所以正确的修法是换成符号锚点(跟着代码走)。
本 PR 这两条在 changelog 里,描述的是 v0.10.1 当时的状态 —— 那段话本身是历史记录,不该跟着 main 漂。钉提交是对的,换符号锚点反而错:PINNED_SERVER_VERSION = "0.8.0" 这个事实只在那个提交上成立,今天的 cli.ts 里它已经不是 0.8.0 了。

同一类症状(行号 pin 失效),两种正确修法,取决于那句话说的是「现在」还是「当时」。

一个附带确认

3a387204 在仓里存在(2026-05-17 的一次 docs 提交),不是一个编出来的 SHA。