修 #3570 (PR 见该单)时在同一节 读到的第三处过期陈述。#3570 的文件面被 PM 明确限定为「Documentation 节的那两处 + 一句提示」,本处不在其中,按 Prime Directive #10 未在那个 PR 里改,另立本单。
现文(CONTRIBUTING.md:412-414,### Writing Documentation)
We use fumadocs for documentation. All docs are in docs/.
与现状对不上
站点(fumadocs)的文档源根本不是 docs/。apps/site/source.config.ts:6 写的是 dir: '../../content/docs' —— 已发布的 183 篇文档全在 content/docs/**;
仓库根的 docs/ 是内部材料树 (adr/、audits/、ARCHITECTURE.md、screenshots/),不进站点、没有 /docs/... 路由;
这个区分在别处是被当作前提写死的:.github/workflows/check-links.yml 的头注释专门记了 check-links.yml(Lychee)扫的是 docs/**(15 个文件),不是站点文档 content/docs/**(183 个文件) #3449 的教训 —— lychee 的扫描面曾经只指向仓库根 docs/**,「had therefore never scanned a single published page」;scripts/check-doc-links.mjs 的 SCAN_ROOTS 也是把 content/docs(docs 路由语义)和其余磁盘路径分开的。
也就是说:唯独 CONTRIBUTING.md 这句还停在搬迁前 ,而它恰好是新贡献者「文档该写在哪」的第一落点。照它做的人会把新页面放进 docs/,站点上永远不出现,链接门禁也不看那棵树(SCAN_ROOTS 里没有它)。
为什么门禁抓不到
这是散文里的一句目录名断言 ,不是链接 —— check-doc-links.mjs 只解析 markdown 链接,docs/ 写在反引号里(反而会被 stripCode() 抹掉)。没有任何检查会因为这句话变假而变红,只能靠人读到。
复现(只读,离线)
grep -n ' All docs are in' CONTRIBUTING.md
grep -n ' dir:' apps/site/source.config.ts # => dir: '../../content/docs'
ls docs/ # => adr audits ARCHITECTURE.md screenshots ...
ls content/docs/ # => api blocks components core fields guide layout plugins rfcs utilities
建议
把这句改成如实的两句:站点文档写在 content/docs/**(fumadocs collection,baseUrl: '/docs');仓库根 docs/ 放 ADR / 审计等不发布 的内部材料。顺带确认紧随其后的 pnpm site:dev / pnpm site:build 两条命令仍然有效(本单未逐条核实这两条)。
关联
#3570 (同节两处过期陈述,PR 在飞)、#3545 (同节 3 条死链)、#3449 (lychee 扫描面曾指错到 docs/** 的同源错误)、#3536 / #3572 (SCAN_ROOTS 扫描面扩展)。
⚠️ 本单未认领 ,留给 PM 分诊。
修 #3570(PR 见该单)时在同一节读到的第三处过期陈述。#3570 的文件面被 PM 明确限定为「Documentation 节的那两处 + 一句提示」,本处不在其中,按 Prime Directive #10 未在那个 PR 里改,另立本单。
现文(
CONTRIBUTING.md:412-414,### Writing Documentation)与现状对不上
docs/。apps/site/source.config.ts:6写的是dir: '../../content/docs'—— 已发布的 183 篇文档全在content/docs/**;docs/是内部材料树(adr/、audits/、ARCHITECTURE.md、screenshots/),不进站点、没有/docs/...路由;.github/workflows/check-links.yml的头注释专门记了 check-links.yml(Lychee)扫的是 docs/**(15 个文件),不是站点文档 content/docs/**(183 个文件) #3449 的教训 —— lychee 的扫描面曾经只指向仓库根docs/**,「had therefore never scanned a single published page」;scripts/check-doc-links.mjs的SCAN_ROOTS也是把content/docs(docs 路由语义)和其余磁盘路径分开的。也就是说:唯独 CONTRIBUTING.md 这句还停在搬迁前,而它恰好是新贡献者「文档该写在哪」的第一落点。照它做的人会把新页面放进
docs/,站点上永远不出现,链接门禁也不看那棵树(SCAN_ROOTS里没有它)。为什么门禁抓不到
这是散文里的一句目录名断言,不是链接 ——
check-doc-links.mjs只解析 markdown 链接,docs/写在反引号里(反而会被stripCode()抹掉)。没有任何检查会因为这句话变假而变红,只能靠人读到。复现(只读,离线)
建议
把这句改成如实的两句:站点文档写在
content/docs/**(fumadocs collection,baseUrl: '/docs');仓库根docs/放 ADR / 审计等不发布的内部材料。顺带确认紧随其后的pnpm site:dev/pnpm site:build两条命令仍然有效(本单未逐条核实这两条)。关联
#3570(同节两处过期陈述,PR 在飞)、#3545(同节 3 条死链)、#3449(lychee 扫描面曾指错到
docs/**的同源错误)、#3536 / #3572(SCAN_ROOTS扫描面扩展)。