[docs] 相对链接失效 36→16：已修 20 条深度错；另发现 2026-W19.md 有损坏的 UTF-8 字节

[vansin]

已修:20 条,同一个成因(相对深度少一级)

docs/qa/weekly/2026-W19.md 里的链接写成 ](../../scripts/qa-status.sh)。
文件在 docs/qa/weekly/,../.. 只到 docs/,所以解析成 docs/scripts/qa-status.sh。
到仓库根需要三级。已按精确判据批量修:

只改「docs/<rel> 不存在 且 <rel> 存在」的那些 → 修 20 条，跳过 0 条
DOCLINKS: 36/283 → 16/283 失效

🔴 顺带发现:这个文件本身有一处损坏的 UTF-8

file(1): Non-ISO extended-ASCII text, with LF, NEL line terminators
字节 2467 附近: b' \xe6\x8b\xbf\xef\xbc\x8c\xe4\xb8_\n'
                                        ^^^^^^^^^^

\xe4\xb8 后面本该是第三个续字节(例如 \x80 = 「一」),实际是 _(0x5f)。
任何按 UTF-8 读这个文件的工具都会抛 UnicodeDecodeError —— 我的修复脚本第一版就是这么崩的,
最后改成按字节替换才绕过去(链接路径是 ASCII,不受影响;损坏字节我没有动)。

我不猜它原本是哪个字。 需要作者或从更早的版本恢复。

剩余 16 条:需要归属知识,不该由我猜

文件	条数	性质
docs/qa/weekly/2026-W19.md	6	指向 docs/qa/qa-hub-06-token-revoke/ 等运行目录,这些目录不存在 —— 是产物没提交,还是被清理了?
docs/rfcs/RFC-029-…-draft.md	2	引用 RFC-030-codex-tui-bridge.md,而它实际在 docs/analysis/ 不在 docs/rfcs/
docs/rfcs/RFC-009-…	2	../issues/72 —— 把 GitHub issue 写成了相对路径,类别错误,不是文件移动
其余 5 个文件	各 1	逐条不同

🔴 RFC-029 draft 与 docs/analysis/rfc030-… 都是工作树里未提交的 draft,
动它们要先弄清归属 —— 我没有动。

建议

1. 把本条的 20 条修复合入(纯路径,无语义变化);
2. 2026-W19.md 的 UTF-8 损坏单独处理 —— 它会让任何 UTF-8 工具在这个文件上崩;
3. 那 6 条指向 QA 运行目录的链接,需要决定:补产物 / 改成 issue 链接 / 删除;
4. 考虑把 check-doc-relative-links.py 接进自动面 —— 这 36 条能积到今天,
   说明没有任何东西在盯它(与 [test][grok-copresence] 项目根往上走会撞到上层 .anet，集成测试大面积假红且报错指错方向 #884 同类:没人跑的门等于没有门)。

[vansin]

🔴 更正:上面那 20 条我修在了错的基底上

我的工作检出落后 origin/main 801 个 commit。上面报的 36 → 16 是在那棵陈旧树上量的。

在 origin/main 上重跑,数字不一样:

origin/main 基线      38/288 条失效，涉及 8 个文件
（我那棵陈旧树        36/283 条失效，涉及 9 个文件）

同一个修法在正确基底上重做:

在 origin/main 基底上修 20 条，跳过 0 条
→ 18/288 条失效

成因和修法都不变(docs/qa/weekly/ 里写 ../../ 只到 docs/,到仓库根要三级),
只是必须改在 main 上,不是改在我的分支上。

同一轮量到的另外两道门(都对 origin/main)

GUARDS:   RED   已接自动面 0/3   失联 3   判不了 0
L1PATHS:  RED   6 处未覆盖；3 个套件 × 2 个 paths 列表
                test686-rest-shape-golden / test765-batch-runtime-gate / test766-bunx-preflight
                —— 改这些套件不会触发跑它们自己的测试
DOCLINKS: RED   38/288（修 20 条后 18/288）

🔴 三道门在 main 上全红,而且没有任何一道接在自动执行面上。
GUARDS 那条尤其直接:三个发版守卫脚本(sync-pinned-versions.sh /
verify-release-tag.sh / verify-published-pins.sh)都存在,但都没被任何 workflow 调用 ——
它们只在文档里被提到。

方法上的自我更正(这是本轮真正的收获)

我先拿自己的工作检出跑门,得到:

🔴 EXPECTED-SCRIPT-MISSING verify-release-tag.sh —— 名单里有，仓库里没有(名单过期?)

差点据此写成"名单过期了"。实际是那两个脚本在 main 上都在,只是我的检出落后 801 个 commit。

门的行为是对的 —— 它报的是 判不了(UNKNOWN)而不是 RED,三分制救了我一次。
错的是我拿一棵陈旧检出去跑仓库级的门。

⇒ 仓库级的门必须对 origin/main(或明确声明的目标 ref)跑,不能对手边的工作检出跑。
这条我记忆里有(「诊断先读 origin/main」),今天已经在四个不同场景踩到:
生产 dist 比对、RFC review、发版守卫、以及这次的文档链接。

[vansin]

更正:那个 UTF-8 损坏不是"字节被替换",是整行在汉字中间被截断

我上一条写的是「\xe4\xb8 后面本该是第三个续字节,实际是 _(0x5f)」。描述不准,重新定位:

真实坏点: start=2506 end=2508  reason=invalid continuation byte
该处字节: b'\xbf \xef\xbc\x8c \xe4\xb8 _ \n- '
                    ↑ ，(U+FF0C)  ↑ 只剩前两字节  ↑ 这是 markdown 斜体收尾，不是替换进来的

整行: _这个测试 pin 关键契约：「断开期间的任务不能丢」—— 通过 getinbox 拿，◆_

整行以 _ 开头,所以结尾那个 _ 是斜体闭合标记,不是覆盖了第三字节的东西。
真实情况是:这一行在一个汉字中间被切断,句子本身也明显没写完(「通过 getinbox 拿,」)。

⇒ 修法不是猜一个字符,是补回被截掉的尾巴。 这两者对修复者是完全不同的动作。

git 历史救不回来 —— 这条我查了

该文件的提交历史:
  be6c3dee  test(qa): R22 — Plan B (CI badge + CONTRIBUTING) + Plan E (qa-status.sh 周报脚手架)

每个版本的 UTF-8 可解码性:
  🔴 be6c3dee  位置 2506 坏  5220 字节

只有一次提交,而且创建时就已经是坏的。 没有更早的完好版本可回滚。
⇒ 只能由作者补,或者按上下文重写那一行。

顺带:这行内容本身有价值,别直接删

它记录的是一条契约:「断开期间的任务不能丢 —— 通过 getinbox 拿…」。
删掉整行会丢掉这条信息。建议补全而不是移除。

[vansin]

又推进一批:18 → 15,而且有一条我查完之后决定不修

全部量在 origin/main@034f0064 的 fresh worktree 上。

修掉的三条(判据都很窄)

文件	问题	判据
docs/tests/p-grok-demos-qa/report.md	../../docs/tests/… 解析成 docs/docs/tests/…	深度少一级:docs/<rel> 不存在而 <rel> 存在
docs/release/v2.3.0/RELEASE-NOTES.md	同上	同上
docs/rfcs/RFC-006-…md:391	链接文字和目标写反了	见下

RFC-006 那条原文:

per [/tmp/codex-schema/ServerNotification.json](实测 dump) 63 events, …

路径被写成了链接文字,而说明文字「实测 dump」被写成了目标。
它从来就不是一个能指向任何东西的链接。改成:

per `/tmp/codex-schema/ServerNotification.json`（实测 dump） 63 events, …

信息一条不丢,只是不再伪装成链接。

🔴 查完之后决定不修的一条:RFC-009

| **关联 demo** | [#72 opinion-spread](../issues/72) · [#74 信息瀑布](../issues/74) |

../issues/72 是把 GitHub issue 写成了相对路径 —— 看起来只要换成 URL 就行。
但我先去核了这两个 issue 实际是什么:

#72 → OPEN    [umbrella][P1] 社会学实验 Demo 准备          ✅ 与 "opinion-spread" 对得上
#74 → CLOSED  [bug][P1] 节点删除后 ， dash 里面还展示      🔴 与 "信息瀑布" 完全无关

⇒ #74 指的不是本仓库的 issue 74。 可能是别的仓库、可能是编号漂移、也可能"#74"是 demo 编号不是 issue 号。

所以我一条都没改:

• 只把 [umbrella][P1] 社会学实验 Demo 准备 #72 转成 URL,会让同一个表格单元格一半是链接一半是坏路径,自相矛盾;
• 把 [bug][P1] 节点删除后 ， dash 里面还展示 #74 转成 …/issues/74,会指向一个不相干的 bug 报告 —— 比断链更糟,
  因为断链会被工具发现,而指错的链接看起来完全正常。

这一条需要作者确认 #74 到底指什么。

剩余 15 条,按"能不能自动判"分类

docs/qa/weekly/2026-W19.md          6 条  指向不存在的 QA 运行目录 —— 产物没提交还是被清理？需决定
docs/tests/release-gate-playbook.md 5 条  report-test-v092-preview5/6.md 不存在；../../memory 指向仓库根的 memory（不存在）
docs/rfcs/RFC-009-…                 2 条  见上，需作者确认 #74
docs/rfcs/RFC-022-…                 1 条  指向 RFC-017-dashboard-org-chart-view.md —— 那是**未提交的 draft**
docs/tests/p-grok-028-…/report.md   1 条  tests/p-grok-x-reaudit 不存在

这 15 条没有一条能靠机械判据修 —— 每条都要有人回答"这个目标该是什么"。
能自动修的那一类(深度错)已经全部修完:本轮 3 条 + 上轮 20 条 = 23 条。

[vansin]

15 → 9,而且剩下 9 条不再需要"查"了,只需要一个决定

我上一轮的分类错了一格

周报那 6 条我归成「产物没提交还是被清理？需决定」。
实际去核 git ls-files 之后:4 个目标目录原样躺在 tests/ 下,
链接只是写成了 docs/qa/ 的相对路径;另外 2 条的链接文字本身就写着
docs/qa/v0-summary.md,和它自己的目标不一致。

判据(可复跑):目标 basename 在 git ls-files 里唯一命中一个目录/文件。

qa-hub-06-token-revoke           → tests/qa-hub-06-token-revoke
qa-hub-06b-cross-user-isolation  → tests/qa-hub-06b-cross-user-isolation
qa-node-02-success-reply         → tests/qa-node-02-success-reply
test30-v0.8-auth-deprecation     → tests/test30-v0.8-auth-deprecation

已修(6 行改动),改后在该文件上逐条解析:剩余断链 = 0。

🔴 顺带记一个我差点犯的错:我先拿 origin/main 当基准重量了一遍,
得到「25 条」,和上一轮的「6 条」对不上。差额不是数错,
是这条分支已经修掉的那批 —— 我拿一棵已经修过的树的补丁去量原树。
量之前先说清楚量的是哪棵树。

剩下 9 条:问题从"目标该是什么"变成"要不要补产物"

对每个目标跑了 git log --all --diff-filter=A -- <path>(全历史新增次数):

目标	全历史新增	结论
report-test-v092-preview5/6/7.md	0	从没提交过
v010-chain-test-baseline.md	0	从没提交过
p-grok-x-reaudit	0	从没提交过
RFC-017-dashboard-org-chart-view.md	0	从没提交过;本地有 9320 字节未跟踪草稿
../../memory(仓库根 memory)	0	从没提交过 —— 指的多半是仓库外的东西
RFC-009 的 ../issues/74	—	见上一条:#74 是不相干的 bug,仍需作者确认

⇒ 没有一条是"被清理掉的产物"。 全部是「引用了一份从未落地的文件」。
所以决定只有两种,不需要再查:补产物,或删链接改成纯文字说明。

我不替作者做这个决定 —— 删链接会丢掉「这里本来该有一份证据」这条信息,
而那条信息恰恰是最值钱的部分。

[vansin]

15 → 9 → 4:playbook 那 5 条修掉了(94379fb6)

这 5 条不是"链接写错了",是目标从来没有被提交过。
git log --all --diff-filter=A -- <path> 对每一个都返回 0 次新增:

report-test-v092-preview5.md   从未提交
report-test-v092-preview6.md   从未提交
report-test-v092-preview7.md   从未提交
v010-chain-test-baseline.md    从未提交
../../memory                   从未提交（那是仓库之外的东西，也不会进来）

所以修法不是"找正确路径",而是别再伪装成可点的链接;
同时把"这里本该有一份证据"这条信息一个字不丢地留下:

改前：[R9 preview.6 catch](report-test-v092-preview6.md)
改后：R9 preview.6 catch（`report-test-v092-preview6.md` **从未提交到本仓**）

🔴 直接删链接会把那条信息一起删掉,而那恰恰是最值钱的部分 ——
它记录的是"某一轮确实抓到过这个坑,但报告没落地"。
补产物是另一件事,需要有人认领;这次只让文档不再撒谎。

../../memory 那条另有一层

它的链接文字是一个内部 memory slug(feedback_pane_vs_commhub_truth)。
本文件在 slug 门的 ALLOWLIST_PATH_PREFIXES(docs/tests/)之内,政策上是允许的,
所以这次只改链接形态、不动 slug 本身 —— 那属于 #772 的口径决定,不该在这里顺手改掉。

剩余

RFC-009 的 ../issues/74     需作者确认 #74 指什么（本仓 #74 是不相干的 bug，改成 URL 比断链更糟）
RFC-022 → RFC-017 draft     目标是未提交的本地草稿
p-grok-028 → p-grok-x-reaudit  从未提交
（原 9 条中的 5 条本次修掉）

验证:该文件相对链接剩余断链 0。

[vansin]

🔴 这条和 #872 在同一个文件上重叠了,而且两边都需要,但顺序有讲究

我在把手上 14 条本地分支依次往 origin/main 上试合的时候撞出来的:
fix/887-doc-relative-links 和 fix/872-qa-weekly-links 在
docs/qa/weekly/2026-W19.md 上冲突(同样那 26 行)。

逐棵树量了一遍(用 python 解析,不用 grep —— 原因见下):

树	UTF-8	相对链接	解析不到
origin/main	🔴 坏 @2467	24	24
fix/887-doc-relative-links	🔴 仍然坏 @2518	26	1
fix/872-qa-weekly-links	✅ 干净	24	0

⇒ 本条把深度错修掉了(24 → 1),但没有修那 4 个坏字节,也没动生成器
scripts/qa-status.sh(它才是每周把坏字节写进去的那一手)。

🔴 为什么这件事容易被漏掉:坏编码会让 grep 在这份文件上返回零

$ grep -c '\.\./\.\./\.\.' <(git show fix/887-doc-relative-links:docs/qa/weekly/2026-W19.md)
（空）

不是"没有三级前缀",是这份文件解码失败,grep 什么都不给你。
我第一次量的时候就拿到了这个空值 —— 换成 python 逐条对文件系统解析才拿到真数字。
⇒ 在这份文件上验链接,不能用 grep。

建议的落地顺序

fix/872 那一份 2026-W19.md 是本条那一份的超集(链接 0 坏 vs 1 坏,外加编码修好)。
所以合并时:

• docs/qa/weekly/2026-W19.md → 取 fix/872 的版本;
• 本条其余三个文件(docs/release/v2.3.0/RELEASE-NOTES.md、docs/rfcs/RFC-006-…、
  docs/tests/p-grok-demos-qa/report.md)与 fix/872 无重叠,照常合。

另外那 1 条在本条上仍解析不到的链接,在 fix/872 里已经修掉了 ——
它是手写的 ](../qa-…),需要的是 ](../../../tests/qa-…),和生成器产出的那批修法不同。

[vansin]

顺手把 docs/ 的相对链接整棵扫了一遍:只剩 5 条,但其中 2 条指向本机私有目录

在 2026-08-16 的集成树上跑(197 个 .md,243 条相对链接):

解析不到 5 条，涉及 4 个文件
  2  docs/rfcs/RFC-009-social-experiment-framework.md   → ../issues/72 、 ../issues/74
  1  docs/rfcs/RFC-029-opencode-runtime-integration.md  → ../../.claude/memory/
  1  docs/research/intern-tool-calling-code-trace.md    → ../../agent-orchestra/memory/feedback_vendor_verify_before_hardcode.md
  1  docs/tests/p-grok-028-xsearch-acp-probe/report.md  → ../../../tests/p-grok-x-reaudit

🔴 后两条不是"链接坏了",是本机路径写进了公开仓

origin/main:docs/rfcs/RFC-029-…:9
  | **关联 RFC** | … [RFC-006 (project memory)](../../.claude/memory/) … |

origin/main:docs/research/intern-tool-calling-code-trace.md:183
  - The vendor table source of truth …: [`feedback_vendor_verify_before_hardcode`](../../agent-orchestra/memory/feedback_vendor_verify_before_hardcode.md)

.claude/memory/ 和 agent-orchestra/memory/ 是某个人机器上的私有笔记目录,不在这个仓里,
也不该在 —— 对任何 clone 这个仓的人来说,这两个链接永远解析不到,
而且第二条还把一个私有笔记的 slug 名写进了公开文档。

两条都在 origin/main 上,不是这一叠引入的。

建议(没替 owner 改)

• ../issues/72 / 74:GitHub issue 不该用相对路径,应写成完整 URL;
• ../../.claude/memory/ 与 ../../agent-orchestra/memory/…:去掉链接,保留文字即可 ——
  正文已经说清了它指的是什么(RFC-006 / vendor 校验 SOP),
  链接本身对读者是死的,只对写它的那台机器有意义;
• ../../../tests/p-grok-x-reaudit:目录不存在,要么补上要么去链接。

🔴 我没有改:这四个文件分属 RFC、research、tests 三类,各有各的 owner,
而且第二条涉及"要不要把那条私有笔记的内容搬进仓里"——那是内容决定,不是链接修复。

[vansin]

两条新事实:一条会让「修好」比「坏着」更糟,一条是守卫的形状漏洞

接 03:27 那条(5 条里 2 条指向本机私有目录)。今天继续查,得到两条上面几条都没提到的:

1. ../issues/74 的号码本身是错的 —— 修成 GitHub 链接会得到一个自信的错链

RFC-009 第 11 行写的是 [#72 opinion-spread](../issues/72) · [#74 信息瀑布](../issues/74)。
前面几条把它归为「类别错误:把 GitHub issue 写成了相对路径」,那是对的 ——
但照着号码改成 GitHub 链接,#74 会指错地方:

gh issue view 72  → [umbrella][P1] 社会学实验 Demo 准备        ✅ 与 "opinion-spread" 对得上
gh issue view 74  → [bug][P1] 节点删除后 ， dash 里面还展示    🔴 与 "信息瀑布" 毫无关系
gh issue list --search 信息瀑布
                  → #76 [demo] 信息瀑布 (Information Cascade) — 社会学实验 Phase 2   ← 真正的那个

🔴 这类修复有个不对称的风险:链接坏着的时候,点的人立刻知道它坏了;
把它改成一个能打开、但打开的是别的东西的链接,读者会当成事实接受。
「修好」在这里可以比「坏着」更糟,而且不会有任何门报出来 —— 两个号码都是合法 issue。

⇒ 所以这两条我没有批量改。#72 已核对得上;#74 应改为 #76,但那需要作者确认是不是 Phase 2 那个 demo。

2. no-memory-slugs 那道门,对这几条私有目录引用一处都没命中

那 2 条指向本机私有目录的链接(../../.claude/memory/、../../agent-orchestra/memory/…)
本该正是 no-memory-slugs 要挡的东西。跑了一下:门是绿的。

原因是判据按形状写:\[\[(feedback|project|reference|user)_…\]\]。
那几处不是 [[slug]],是 markdown 链接和反引号路径,同一件事换个语法就穿过去了。

全仓共 4 处这类引用,其中 3 处在 ALLOWLIST_PATH_PREFIXES 里(有意的历史豁免),
第 4 处不在 —— docs/team-collab-playbook.md:368,带完整绝对路径和用户名。
同一行两套判据对拍:

origin/main 的判据                    → rc=0（绿）
扩到路径形态之后                      → rc=1，指名 :368
去掉那行绝对路径后                    → rc=0

已扩(local 2b612140,尚未推)。顺带修了那道门自己的一处自伤:
它的 FAIL 输出原样打印命中段,而公开仓的 Actions 日志是公开的 ——
一道防泄漏的门会把命中内容印进公开日志。脱敏改到入 findings 列表之前
(不是打印前:只要原值进过列表,后面任何一处打印都可能漏掉那层)。

关于严重性,先按住不夸大

那处绝对路径里的是机器用户名,不是凭据:它在 origin/main 上从 2026-05-15 起就在,
且同一个用户名在 52 个文件里出现。没有可轮换的东西,也不需要紧急处置。
这条的价值在门的形状漏洞,不在那一行本身。

一条方法上的账

上面几条里的 36 → 16 → 15 → 9 → 4 → 5 这串数,是用一个不在仓里的脚本量出来的
(check-doc-relative-links.py 至今没有被提交,git log --all 查不到)。
⇒ 现在没有人能复算这串数,也没有任何自动面在跑它。
这正是那 36 条能积到今天的同一个原因 —— 建议把「接进自动面」从第 4 条建议提到第 1 条。

[vansin]

收口:那串数现在可复算了,剩 4 条

本条开头那串 36 → 16 → 15 → 9 → 4 → 5 每一步都写了证据,
但我在 15:44 那条评论里指出过一个更基本的问题:量它们的脚本从来没有进过仓
(git log --all 查不到 check-doc-relative-links.py)。
⇒ 没有人能复算那串数,也没有任何自动面在跑它。

现在判据落进仓了。今天(2026-08-16 13:36)的数:

DOCLINKS: OK（170 个 .md，282 条相对链接，解析不到 4 条；
             其中已知待归属 4 条，新增 0 条，基线过期 0 条）
🔴 注意:「OK」在这里的含义是「没有新增坏链」，不是「没有坏链」。

判据是双向的,第二条才是命门

1. 出现 KNOWN 之外的新坏链 → 红;
2. KNOWN 里某条已经不坏了 → 也红。

只判第 1 条的基线门会慢慢变墙纸:坏链修好没人删基线,基线越留越长,
直到覆盖住下一个真问题。让基线过期本身成为失败,它才不会烂。

⇒ 这一支今天在真实数据上生效了两次:两次都是我改完文档忘了同步基线,
门当场顶出「请从 KNOWN 里删掉这条」。

剩下的 4 条,逐条写了「为什么不能由我猜」

文件	目标	为什么不动
RFC-009	../issues/72	类别错误(GitHub issue 写成相对路径)。#72 与 opinion-spread 对得上,可改 URL
RFC-009	../issues/74	🔴 号码本身错了:#74 是「节点删除后 dash 还展示」,信息瀑布是 #76。照号码改会得到一个能打开、但打开的是别的东西的链接 —— 待作者确认
RFC-022	RFC-017-dashboard-org-chart-view.md	该 RFC 在任何分支上都没有被提交过(git log --all --diff-filter=A 无记录),只作为未跟踪文件存在于某个工作树 —— 是文档没落地,不是链接写错
p-grok-028…/report.md	../../../tests/p-grok-x-reaudit	指向一个从未提交的会话产物目录;测试记录里的证据缺失,不该由我改路径掩盖

另外两件本条提过、今天有进展的

• 2026-W19.md 的 UTF-8 损坏:逐 ref 核过 ——
  origin/main 🔴 坏 @2467;HEAD(集成树)✅ 合法,修在 190032e9([docs][qa] docs/qa/weekly/2026-W19.md 的 26 条相对链接全部失效:目录深度算错一级(../../ 应为 ../../../),且仓内无任何文档链接检查 #872)。
  ⇒ 不是「已修」,是「已修但没落地」;main 现在仍然坏着。
• 「接进自动面」(本条建议第 4 点):已挂进 scripts/qa.sh --l0。
  ⚠️ 但光挂进 L0 还不够 —— qa.yml 的 paths: 里没有 docs/**,
  只改 docs/ 的 PR 根本不会启动那个 workflow。为此单开了 doc-gates.yml
  (只跑几个 python 脚本,零依赖),详见 [ci][meta] 一晚上四个门因外部网络/registry 翻红,零次是代码问题 —— 门既拦不住真问题也制造假问题 #731 的评论。

(以上改动都在一条尚未推送的分支上。)

[vansin]

在 origin/main 上做了一次全 docs/ 的扫描并分类,因为一个总数(「36→16」)不足以决定下一步 —— 这 18 条里有几类根本不该被当成死链修。

扫描口径

168 个 .md,296 条仓内相对链接,18 条解析不到文件。分类:

类	数	处置
🔴 真死链	11	见下
指向仓外(私有 memory / 上级目录)	2	不该是相对链接
把 GitHub issue 写成相对路径 (../issues/72)	2	应写成完整 URL
站点绝对路由(/guide/feishu)	2	✅ 不是死链 —— 由 docs 站路由解析,不是文件系统
占位符 ...	1	✅ 不是链接

后两类(3 条)判成死链是量具的错,不是文档的错。 任何做这个扫描的人都要先把它们排掉,否则报出来的数字里有 17% 是噪声。

那 11 条真死链,再分三类 —— 只有一类能确定性修好

A. 目标存在、路径写错(2 条)—— 已修,PR #913

docs/release/v2.3.0/RELEASE-NOTES.md      ../../docs-site/…  少一级
docs/tests/p-grok-demos-qa/report.md      ../../docs/tests/… 多绕一层

B. 已在 #911 修掉(2 条) —— docs/qa/weekly/2026-W19.md 的两条 v0-summary.md#…。

🔴 顺带:这两条一直在 docs-integrity 门的作用域(docs/qa/)里,门却一直是绿的。 门的链接正则只认 ./ 和 ../ 开头,看不见裸文件名 —— 盲区在「怎么收集」不在「判什么」,而它宣称的分母(80)比真实的(96)少 16 条,两条坏链正好都在那 16 条里。详见 #911。

C. 目标确实不存在(7 条)—— 改路径解决不了,要逐条决定

文件	链到	情况
docs/rfcs/RFC-022-…client-app.md	RFC-017-dashboard-org-chart-view.md	🔴 RFC-017 不在 main。它只存在于一台机器的工作树里(未提交,Jun 12)。一份已提交的 RFC,引用了一份别人克隆后拿不到的文档。
docs/tests/release-gate-playbook.md	report-test-v092-preview5/6/7.md、v010-chain-test-baseline.md	4 份测试报告全不在仓里
docs/tests/release-gate-playbook.md	../../memory	指向仓外
docs/tests/p-grok-028-…/report.md	../../../tests/p-grok-x-reaudit	目录不存在

C 类每条都是一个决定(补文件 / 删链接 / 改成说明性文字),不是路径修正。尤其 RFC-017 那条:要么把它提交进来,要么 RFC-022 里不该指向它 —— 现在的状态是仓库单独不能复现它自己描述的东西。

关于把 docs-integrity 的作用域从 docs/qa/ 扩到整个 docs/

先别扩。 现在扩,门会因为上面 C 类那 7 条立刻变红,而那 7 条要人做决定、不是 CI 能推动的事 —— 结果就是一道只因积压而红的门,等积压清完它就再也不会红,没人知道它还有没有效。

顺序应该是:C 类逐条决定完 → 再扩作用域 → 那时它的红才代表「新引入了死链」。

另:本条标题里 W19 的 UTF-8 损坏已由 #899 修好,我核过 —— 现在整个文件是合法 UTF-8。