一种 _redirects 规则写法：被计为有效，却一次都匹配不上
协议相对的 source（`//host/path`）能通过「以 / 开头」的相对路径校验，被计入「Parsed N valid redirect rules」，在任何一层都不报警，然后一次请求都匹配不上。实测的 12 条协议相对规则里有 11 条是这个形态（矩阵 48 条里的 11 条）；第 12 条在解析期被点名了，但点的是它的目标，不是它的 source。读数取自本地 Pages 模拟器，不是生产边缘。
简报第 01 期2 分钟读完
简报 01 — 那些不出声的失效
三件事，都是靠量自己的站、而不是读自己的文档发现的：一种被接受却毫无作用的重定向写法、四张上线时没有 CSS 的表格，以及一项只对测试夹具跑过的跨资源检查。
下面每一条都是同一个法子找出来的：不去读那份声称规则已被强制的文档，而是去查那个 本该强制它的东西。
这套做法不是因为我们觉得它严谨才选的。是同一周里连着三次，白纸黑字的规则被查出压根 没在强制，之后才落到这一步。
同一个形状
一道门可以写着、认了、却不在。下面三个例子都是这个形状，全部出自本站，全部在同一 轮里被找出来：
- 发布标准里写着
assets不得为空。本该强制这条的 schema 里没有这条规则——一条assets: []的资源照样构建通过。 - 一组跨资源检查（重复 id、断掉的内链）写好了，也有测试。但构建路径上没有一处调用 它。它守着的只有测试夹具，别的什么都没守。
- 一道 SEO 检查确认 markdown 表格渲染出来了。可渲染从来不是问题所在。
这三条，去读那份声称它们都被强制了的文档，一条都看不出来。而去看那个本该执行强制的 东西——一个 schema、一张调用图、一份编译后的样式表——三条加起来大约一分钟就全看见了。
我们改了什么
现在每一条都是一道会让构建变红的门，而且每道门都验过：把它守的东西弄坏，确认它真的 报红。从没见它红过的门，什么都不能证明。
重定向那条发现还变成了一件工具——只活在报告里的结论，寿命很短。
新增
2四张 GFM 表格上线时没有任何 CSS
我们的 SEO 门断言的是「markdown 表格渲染出来了」。它一个字没说这结果能不能读。编译后的样式表里有 17 条 `.prose-body` 规则，没有一条碰到表格。那四张是两页 × 两语种——research-to-artifact 与 research-to-executive-report——发现当天数的。现在两页都带样式了，之后站上的表格还更多了：这次修复补的正是缺的那些表格规则。
更新
1证据与引文核查清单
现在带上了资源库其余部分都在用的生命周期字段——「最后更新」与「最后核验」是两个分开的日期，于是重跑一次检查，在搜索引擎看来不再像是一次改动。