一、复述

xwtools 的 #83（无网 cargo 校验把网络错误判成编译错误）与 #86（编辑后自动 cargo check 应默认关闭）
已于 2026-11-03 合入 master（PR !14 / 合并笔 54203fb），但从未打新 tag。
xwcode v1.10.17 钉的仍是 v0.1.35（2026-11-02 12:38），早于修复一天。
⇒ 两个已关单的 P0 修复，在发布面与评测面结构性不可达，且无任何告警。

二、一手判据（可复跑）

$ git -C xwtools describe --tags origin/master
v0.1.35-6-g54203fb                     # 领先最新 tag 6 个 commit

$ git -C xwtools merge-base --is-ancestor 54203fb v0.1.35; echo $?
1                                      # 合并笔不在 v0.1.35 内

$ git -C xwtools log -1 --format="%ci" v0.1.35
2026-11-02 12:38:24 +0800              # tag 早于合并笔（11-03 18:37）

$ git -C xwtools grep -n -i "offline" v0.1.35 -- crates/xw-tools/src/
v0.1.35:crates/xw-tools/src/registry_gate.rs:87: fn search_replace_offline_unreachable()
                                       # 唯一命中是无关测试，无离线重试实现

$ git -C xwcode show origin/master:Cargo.lock | grep -A2 '^name = "xw-tools"'
version = "0.1.35"
source  = "...?tag=v0.1.35#2fe29aaa..."

三、影响面（v1.10.17 两轮实测）

失败体统一为：

{"success":false,"errors_count":1,"warnings_count":177,"exit_code":101,
 "stderr":"Downloading crates ... warning: spurious network error (3 tries remaining):
           [56] ... CONNECT tunnel failed, response 403"}

#83 提出的修法（网络类错误 → --offline 重试一次 → 仍失败则 skipped:"network_unavailable"、不计 errors_count）
正是这条的对症药，但评测里一次都没生效。R8 到 R9 之间这个数字从 21 涨到 39，唯一原因是编辑次数变多。

四、为什么「已关闭」与「零效果」能同时成立

#83 的关闭凭据是「代码在 master」（git grep -c resolve_cargo_check_enabled origin/master），
这在代码面成立。缺的是发布面判据：没有任何一步检查「最新 tag 是否包含该合并笔」。
主仓升钉只认 tag、不认 master ⇒ 修复被静默滞留，issue 已关，评测读数不变。

★ 与 #167（install.sh 缺 .18 tag 时装出 .17 且全程绿灯）是同一族缺陷的两端：
一个在取数端把旧 tag 当新版，一个在发布端根本没打 tag。两者都会让「已修」不可验证。

五、修法

1. 立即：xwtools 在 54203fb 打 v0.1.36（annotated，带 deref 注），主仓升钉 v0.1.36，
   重跑 rust5（v1117_rust5 同配置）复验。
2. 门禁（根治）：升钉前加一条判据 —— 「所钉 tag 必须是该仓 origin/master 的祖先，且 tag..origin/master 无未发布 commit」，
   否则报「存在未发布的修复」。可挂进现有 pin-gate（参见 #76），不需要新构件。
3. 口径：涉及卫星仓的 issue 关闭时，凭据须附已打 tag 名与 tag 时间，不能只有合并笔 sha。

六、验收

• git -C xwtools describe --tags origin/master 返回纯 tag（无 -N-g 后缀）
• 升钉后同题重跑：verification 不再出现 success:false + errors_count:1；
  依赖缺失时出现 skipped:"network_unavailable" 且不进 errors_count
• 有网环境行为不变（不因回退多跑一次，沿用 #83 原验收项）

七、边界说明

单靠 #83 的 --offline 重试不保证成功：--all-targets 会命中 tests/，
需要 dev-dependencies，而镜像只预热 build 闭包。此时必须落到本单第五步第 2 条那种
「显式 skipped、不计数」的降级路径，否则仍会被读成编译错。
R9 的 warnings_count:177 说明编译已深入到解析阶段才撞网 —— 代码本身大概率是对的。

诊断依据：audit/deepswe-bench-eval-2026-11-08/ROOT_CAUSE_ANALYSIS.md（commit 90e6e95b3）§2