[ci] complete agent-network unit domain still has no aggregate CI signal (OpenCode pair itself fixed)

[vansin]

事实

agent-network/src/opencode-agent-node-pair.ts 的 RFC-029 配对 pin 与已发布版本失同步:

pin 里:  OPENCODE_AGENT_NETWORK_VERSION = "2.3.0-preview.34"
         OPENCODE_AGENT_NODE_VERSION    = "2.5.0-preview.28"
npm 上:  @sleep2agi/agent-network@preview = 2.3.0-preview.39
         @sleep2agi/agent-node@preview    = 2.5.0-preview.31

后果:opencodeExactPairInstallCommand() 给用户的安装命令仍指向 .34/.28,
落后已发布的 preview 三个版本。

绊线是有的,而且正在响 —— 只是没人听见

源码注释写得很明确:

Keep this exact pair in lockstep with the two preview package versions;
the unit test intentionally fails when either package is bumped independently.

对应测试 OpenCode agent-node release pairing > pins the exact versions being released together
当前就是红的:

Expected: "2.3.0-preview.39"
Received: "2.3.0-preview.34"

设计完全正确 —— 它就是为了在有人只 bump 包、不动 pin 时报红。它做到了。
问题是没有任何门在跑 agent-network 的单测,所以这条红从发版那天起一直无人看见。

两条更一般的缺口

① 未被门覆盖的范围比 #725 说的更大。
#725 讲的是 agent-node 单测没有门;agent-network 的单测同样没有门。
证据:本机跑 bun test src/(agent-network)得到 433 pass / 3 fail,
三条红都是 main 上既有的,没有任何 CI 报告它们。

② 我给 RELEASE-SOP 加的 Step 10 不完整。
#734 我给发版流程加了「取远端核」,核的是三个包的版本号 + PINNED_SERVER_VERSION。
漏了这第二条 pin。 这次就是这么漏过去的 —— 发版时我知道这个 pin 存在、
也知道它「本次未动」,但 SOP 的检查清单里没有它,于是没有任何机制拦住。
Step 10 应当补上这一条。

我没有做的事

没有把 pin 改成 .39/.31。 这个 pin 的语义是「经过验证的精确配对」,
把它指向 .39/.31 等于声称那一对已被验证可用于 opencode 共存 —— 我没有验过
(我只在容器里验了 agent-network@preview + opencode-ai@1.18.1 能跑通 smoke,
没有验 agent-node@2.5.0-preview.31 那一半)。

所以这里有两条路,归 owner 定:

1. 验证后同步 pin —— 跑一次 .39/.31 的 opencode 共存 smoke,过了再改 pin;
2. 接受 pin 落后 —— 但那样这条测试会一直红,等于长期有一条噪音红,
   而且会掩盖下一次真正的漂移。

无论选哪条,先给 agent-network 单测加门,否则下次同样看不见。

[vansin]

Draft PR #757 is now the frozen implementation for the exact OpenCode package pair and release synchronization. Coordinates: source 03fa958a3261d2ae59a34883670a69e083af4e14, report-only head cddde57a66fc5d54ebde95127824f0bd4a5d7b58. Docker evidence includes test384 normal+slow lifecycle PASS, test386 exact selection PASS, and test621 witnessed-red PASS. It also fixes the independently reproduced #457 private-root rename failure. This does not close #745: a mandatory CI gate for the complete agent-network unit-test domain remains NOT COVERED and stays as the governance tail. PR remains Draft pending CI and independent adversarial review; no release or deployment.

[vansin]

升级这条 issue 的定性:不是「pin 陈旧」,是当前发布线上 opencode-cli 起不来

我去验了「.39/.31 这一对到底能不能用」——本来是想给「要不要同步 pin」提供证据,
结果发现问题比原描述严重。

1. 这一对包本身是好的

干净容器,三方钉死安装:

npm i -g opencode-ai@1.18.1 @sleep2agi/agent-network@2.3.0-preview.39 @sleep2agi/agent-node@2.5.0-preview.31

anet:       anet v2.3.0-preview.39
agent-node: agent-node v2.5.0-preview.31
opencode:   1.18.1

agent-node --help 声明的运行时: claude-agent-sdk grok-build-acp opencode-cli

agent-node@.31 确实声明了 opencode-cli —— 也就是配对校验
agentNodeHelpSupportsOpencode() 要的那个能力是有的。

2. 但 pin 的用法是严格版本相等,不是"下限"

agent-network/src/opencode-agent-node-pair.ts:

|| (expectedVersion ? pkg.version !== expectedVersion : !pkg.version.includes("-preview."))
   → throw new Error(`resolved agent-node package is not exact version ${expectedVersion}`)

而 cli.ts:2178 用 OPENCODE_AGENT_NODE_VERSION(= 2.5.0-preview.28)去解析入口,
失败时抛:

No exact trusted global @sleep2agi/agent-node@2.5.0-preview.28 is available
(resolved agent-node package is not exact version 2.5.0-preview.28);
automatic npx execution is disabled for opencode-cli

所以任何按当前 preview 线安装的人(.39 + .31),opencode-cli 节点都会在启动时被拒。
.28 早已不是 preview tag 指向的版本,普通安装拿不到它。

🔴 我没能在运行时复现,如实标注

我两次尝试在容器里触发这条路径,都被更早的守卫挡下:

anet opencode auth-login <node>   → 先撞 "node not found"(需要节点配置)
补上节点配置后                     → 撞 opencode profile 的 /tmp 权限校验,
                                     那条路径只走 opencode 二进制,不走 agent-node 解析

要真正复现需要容器里起一个 hub(需装 bun)+ 真建节点。所以上面的结论是源码级确凿、
运行时未复现,我不把它说成已实测。谁要在此基础上做决定,建议先补那一次端到端复现。

对原 issue 里那两条路的影响

• 「接受 pin 落后」这条现在不成立了 —— 代价不是"一条噪音红",而是这个运行时对新装用户不可用;
• 「验证后同步 pin」是唯一合理方向。上面第 1 节已经把"这一对包本身可用"验掉了一半
  (help 声明 + 三方版本共存无冲突),仍缺的是一次真实的 opencode-cli 节点端到端 smoke。

另外提一句:.28 与 .31 之间的 agent-node 变更是否影响共存语义,我没有逐条比对,
这属于 owner 在同步 pin 前应当确认的部分。

[vansin]

运行时复现:仍未达成,三次尝试都被更早的门挡下 —— 而挡我的东西本身是个发现

上一条我把结论标为「源码级确凿、运行时未复现」,并说该有人补那次端到端复现。
我去补了,没补成,如实记录过程,免得下一个人重走。

环境:干净容器,bun 1.3.14(两阶段下载 + SHA256 校验,不用裸管道)+
opencode-ai@1.18.1 + agent-network@2.3.0-preview.39 + agent-node@2.5.0-preview.31,
容器内起 hub、非 root 用户运行。

① anet hub start          → OK(登录成功可证)
② anet node create oc1 --runtime opencode-cli --batch
   → [anet] ⚠ Vendor selector unavailable: User force closed the prompt with 0 null
     [anet] vendor selector 不可用(非交互终端?用 --preset <model-id> 指定)
③ 改用 --batch --preset __custom__ + stdin
   → 它的 runtime 列表只有 claude-agent-sdk / codex-sdk / claude-code-cli
     没有 opencode-cli,随后开始问 ANTHROPIC_BASE_URL
④ 节点没建出来 → anet node start oc1 报 "Node not found"

所以根本走不到那个配对守卫。

🔴 顺带发现:opencode-cli 节点在非交互终端下建不出来

--runtime opencode-cli --batch 仍然会去拉 vendor selector,而 selector 在非 TTY 下必然失败;
提示给的出路是 --preset <model-id>,但 __custom__ 的 runtime 列表里没有 opencode-cli。

我没有找到一条非交互创建 opencode-cli 节点的路径。这意味着:

• 自动化/CI 覆盖不了这个运行时的创建路径 —— 这大概也是这个 pin 漂移一直没被测试抓到的原因之一;
• 任何脚本化部署 opencode-cli 节点的尝试都会卡在这里。

这条我按现状描述,没有断言它是缺陷 —— 也可能存在我没找到的 preset 或 flag。
如果确实没有,它值得单开一条。

#745 本身的结论不变

配对校验是严格版本相等(pkg.version !== expectedVersion → throw),
OPENCODE_AGENT_NODE_VERSION = "2.5.0-preview.28" 而 preview 线已到 .31。
源码级确凿,运行时仍未复现 —— 我没有把它升级成「已实测」。

[vansin]

更正:我之前说「#745 的端到端验证被 #765 挡着」——这个说法收回。

anet node create <name> --runtime opencode-cli(不加 --batch)走的是单节点路径,
是可用的;我上次容器测试同时传了 --runtime 和 --batch,后者赢了,
于是我把「参数用错」误判成了「路径不存在」(详见 #765 的更正)。

所以这次端到端 smoke 是可以做的。#745 仍然只剩「验证后同步 pin」这一条路,
但它不再被别的问题阻塞 —— 阻塞过的是我用错的参数。

[vansin]

Current-main status after #757

The product/release-pair defect in the original issue is resolved on main 1112a859:

OPENCODE_AGENT_NETWORK_VERSION = 2.3.0-preview.39
OPENCODE_AGENT_NODE_VERSION    = 2.5.0-preview.31

#757 supplied the missing real path evidence rather than merely editing constants: exact local tarballs, the real runtime picker, a replied OpenCode task, private-path safety and rename/delete lifecycle, plus the test386 exact-agent-node gate and test621 witnessed-red layer. Its final current-head CI batch passed L0/L1, the complete agent-node unit domain, full Docker E2E, rename-ghost and the safety lints. Issue #457 closed with that merge.

The residual issue is narrower and remains real: there is still no aggregate CI job that runs the complete agent-network/src/**/*.test.ts domain. #730 added that signal for agent-node, not agent-network. Repository branch protection is also still absent and is tracked separately by #725.

Accordingly this issue remains open, but its title is narrowed to the remaining agent-network test-domain visibility gap. It must no longer be cited as evidence that the .39/.31 pin itself is stale or unverified.

No release, deployment, repository setting, or production state was changed by this status correction.

[vansin]

✅ 运行时复现成功 —— 之前标注的「源码级确凿、运行时未复现」现在可以去掉了

完整环境(干净容器,非 root 用户,容器内自建 hub):

bun 1.3.14(release zip + SHA256 校验 + bunx 软链)
opencode-ai@1.18.1
@sleep2agi/agent-network@2.3.0-preview.39     ← preview tag 当前指向
@sleep2agi/agent-node@2.5.0-preview.31        ← preview tag 当前指向
install -d -m 0700 /run/user/<uid>            ← 见下方「顺带发现」

步骤:anet hub start → /health 返回 {"ok":true,"version":"0.9.0-preview.29"}
→ anet register(首用户自动 admin,config 里确认拿到 token)
→ anet node create oc1 --runtime opencode-cli(不加 --batch,在 HOME 的子目录里)
→ anet node start oc1

结果:

[anet] Incompatible agent-node for opencode-cli.
[anet] No exact trusted global @sleep2agi/agent-node@2.5.0-preview.28 is available
       (resolved agent-node package is not exact version 2.5.0-preview.28);
       automatic npx execution is disabled for opencode-cli
Install the exact vetted pair:
  npm install -g @sleep2agi/agent-network@2.3.0-preview.34 @sleep2agi/agent-node@2.5.0-preview.28
[anet] Refusing to start: an unsupported agent-node could silently select another runtime.

按当前 preview 线正常安装的用户,opencode-cli 节点起不来。 这不再是推断。

而且它给出的补救是降级到 .34/.28 —— 那两个版本已经不是 @preview 指向的版本了。

顺带发现三条(都在这次复现路上真撞到的)

① 在 $HOME 里直接创建会 FATAL + 裸栈

$ cd ~ && anet node create oc1 --runtime opencode-cli
[anet] FATAL: Error: OpenCode runtime binding root must not overlap the canonical project root
    at wC (…/dist/bin/cli.js:2:928354)
    …7 行栈…

换到 ~/proj 子目录就正常。守卫本身合理,但从 HOME 跑是很自然的动作,
而给用户的是一条 FATAL 加压缩后的栈,没有任何「换个目录」的指引。

② /run/user 缺失时的报错归因错了

[anet] Incompatible opencode-ai runtime.
[anet] Expected trusted opencode-ai@1.18.1; … OpenCode safe runtime base /run/user is missing;
       create it with mode 0700 or set ANET_OPENCODE_SAFE_BASE
    → Install/reinstall exact: npm install -g opencode-ai@1.18.1

标题说「Incompatible opencode-ai runtime」、建议「重装 opencode-ai」——
而真因是目录不存在,重装 opencode 不会创建 /run/user。
好在括号里说了真话;但标题和建议会把人引向重装。这与 #766 是同一类
(前置/需求不一致导致的错误归因)。

③ 首次 anet login 在全新 hub 上必然失败

全新容器里 hub 日志不打印任何 bootstrap 凭据,admin 也不存在,
必须先 anet register。我一开始按 login 走,配合 #716(login 失败仍 exit 0)
白跑了两轮。

对本 issue 的结论

之前那两条路里,「接受 pin 落后」已经排除;现在**「验证后同步 pin」的验证部分做完了一半**:
这一对包(.39/.31 + opencode-ai@1.18.1)能建节点、能进到启动阶段,
唯一挡住它的就是 pin 本身。

仍缺的是同步 pin 之后再跑一次同样的 smoke(证明改完就能起)。
那需要先决定把 pin 指向 .39/.31,属于 owner 的决定,我不擅自改常量。

[vansin]

补一条版本口径:main 已修,但已发布的 preview 包里还是旧 pin

标题现在写「OpenCode pair itself fixed」——这对 main 成立,对用户能装到的包不成立。

main 上确实修好了(我核过)

agent-network/src/opencode-agent-node-pair.ts
  OPENCODE_AGENT_NETWORK_VERSION = "2.3.0-preview.39"
  OPENCODE_AGENT_NODE_VERSION    = "2.5.0-preview.31"

npm  @sleep2agi/agent-network@preview = 2.3.0-preview.39
     @sleep2agi/agent-node@preview    = 2.5.0-preview.31
                                        ↑ 完全一致

绊线测试 opencode-agent-node-pair.test.ts → 4 pass / 0 fail

但 npm pack @sleep2agi/agent-network@preview 拆开看

package/package.json                     version = 2.3.0-preview.39
package/dist/src/opencode-agent-node-pair.d.ts
    agent-node@2.5.0-preview.28          ← 旧 pin
dist 里同时命中 "2.5.0-preview.28" ×2、"2.3.0-preview.34" ×1
     未命中     "2.5.0-preview.31"、"2.3.0-preview.39"

preview.39 是在 pin 修复之前发布的,所以已发布产物携带的仍是 .34/.28。
今天装 @preview 的人,仍会撞上我上面复现的那个失败:

[anet] No exact trusted global @sleep2agi/agent-node@2.5.0-preview.28 is available
[anet] Refusing to start

方法说明(我先踩了一次)

我用 grep 查已发布 dist,先拿 PINNED_SERVER_VERSION 做对照验证方法 ——
对照命中 0,说明「找不到」在这个产物上不可信(minified cli.js 不保留可读字符串)。
所以我只采信阳性命中,并最终定位到 .d.ts 声明文件 —— 那里字符串是完整保留的。

阴性结论我没用。

所以还差一步

不是代码问题,是发版:要么发一个新的 preview 让 pin 生效,要么在本 issue 里
把「fixed」限定为「fixed on main, not yet published」。

我不推动发版(按 RELEASE-SOP 需要 owner ACK),只把版本口径说清 ——
否则关掉这条时,用户侧的失败仍然存在。