Repository navigation
check-links.yml(Lychee)扫的是 docs/**(15 个文件),不是站点文档 content/docs/**(183 个文件) #3449
Description
Activity
- added 2 commits that reference this issue
on Aug 6, 2026 - addedbugSomething isn't workingSomething isn't workingand removed
on Aug 6, 2026 发现分诊轮(晋级):摘
finding换bug+pm:queue。前提复核 live:check-links.yml:25-26仍扫docs/**(15 个内部文件)而非站点的content/docs/**(183 个)。具名单文件修;#3213 裁决里「可选 cron」的前置——范围不修,cron 只会定时产出假绿报告。
Generated by Claude Code
认领:objectui 分片 PM 并行批第 48 单
会话:session_01GTRjn8xBqp75dk7kFupVRt
分支:claude/issue-3449-lychee-scope
Worktree:objectui-issue-3449
文件面:.github/workflows/check-links.yml(+lychee.toml若需排除项)。PM 裁定(issue 留下的两点):① 扫描面两棵树都扫(
content/docs/**为主 + 保留docs/**与 README——内部 ADR 的外链也值得巡检,成本为零);② 同 PR 补 weeklyschedulecron——范围修对后,#3213 裁决 B 的「定时巡检」本义才成立;cron 仅 schedule 不进 PR 门禁,外链 flaky 不伤门禁。如有异议此处否决。
Generated by Claude Code
验收:ACCEPT → PR #3477(并行批第 48 单,会话
session_01GTRjn8xBqp75dk7kFupVRt),14/16 检查零失败(两个 shard 系 runner 拥堵,改动零包源码)。ready + auto-merge 因 GraphQL 配额排队,恢复即执行。复核要点:
- 裁定两点(两树都扫 + weekly cron)如实落地,且 dev 发现了派发词没看到的承重前提:content/docs 有 297 个站点绝对路径链接,Lychee 在 URI 构造阶段即失败、exclude 是空操作(实测),不改 lychee.toml 则 workflow 生而为红(316 错)。sentinel root_dir + 命名空间排除的修法保持「路由→文件解析只归 check-doc-links.mjs」单一职责,死 remap 配置的删除有「从未 fire 过」的证明。
- 拒绝
--fallback-extensions是本单最重要的判断:它把 33 错降到 6,但吞掉的 13 个是真缺陷(.md 链到 .mdx 文件,fumadocs 路由下就是站上 404)——消费端宽容遮生产端错误,正是 #0.1 禁的形状。丑而真优于绿而假。 - 预期管理已写明:首次 cron run 会是真红(37 个真实断链,其中 README 的 4 个在旧扫描面里本来就红、只是从没人 dispatch 过)——届时不是 flake,是 content/docs 有 16 个失效的相对链接,且 check-doc-links.mjs 对相对链接一律放行 #3479/README.md 推荐了 4 个不存在的 example 应用(examples/crm、todo、kitchen-sink、msw-todo) #3480 的工作清单。
- pin 测试从 site config 派生期望范围(硬编码正是本 bug 的出生方式);dev 自己一条断言被测试抓错后按正确理由重写并存档。
- 衍生两单已分诊:content/docs 有 16 个失效的相对链接,且 check-doc-links.mjs 对相对链接一律放行 #3479(相对链接无任何门禁校验 + 16 个断链目标)
bug+pm:queue;README.md 推荐了 4 个不存在的 example 应用(examples/crm、todo、kitchen-sink、msw-todo) #3480(README 幽灵示例 ×4)documentation+pm:queue。
Generated by Claude Code
- added a commit that references this issue
on Aug 10, 2026
现象
.github/workflows/check-links.yml里 Lychee 的扫描目标是:但站点发布的文档并不在
docs/,而在content/docs/(apps/site/source.config.ts里dir: '../../content/docs',apps/site/lib/source.ts里baseUrl: '/docs')。实测两棵树的规模:
也就是说:即使有人手动
workflow_dispatch触发 Lychee,它也从来没有检查过发布出去的那 183 个文档文件。 根目录docs/是内部资料(ADR、审计报告、架构说明),被扫的是它。为什么现在记为 finding 而不是缺陷
check-links.yml目前只有workflow_dispatch(push/pull_request被注释掉,见 #3213),从不自动运行 —— 属于「未被执行的配置漂移」,今天没有用户会撞到。因此按 finding 归类,不带pm:queue。与 #3213 裁决的关系
#3213 的裁决是「B 保持定时/手动(可选补 cron)」。修复 #3213 的 PR 有意没有加这条 cron,理由就是本 issue:在扫描范围还指向错误目录时加 cron,只会按时产出一份「检查了内部 ADR、没检查站点文档」的绿色报告,是加噪声不加覆盖,并且会让人误以为已发布文档的外链已被守住。
建议顺序:先修扫描范围,再谈是否加 cron。
建议
content/docs/**/*.md、content/docs/**/*.mdx(是否保留docs/**与README.md由维护者定;两棵树都扫也合理)。schedulecron —— 届时 cron 才有意义。scripts/check-doc-links.mjs只校验站内/docs/...路由是互补关系,不是重复。这也是裁决把 A 放进 PR 门禁、B 留在定时/手动的原因。相关
pnpm docs:check-links在 main 上就退出 1,但没有任何工作流跑它(两个链接检查器都不拦 PR) #3213 / docs:content/docs/core/enhanced-actions.mdx指向不存在的/docs/components/form#3292 的修复 PR 顺带发现