finding(gate): all three copies of #7448's document-count pin read workflow headers — nothing watches the same counts published in content/docs prose

[claude]

Found while fixing objectui#7886 (content/docs/guide/ci-cd-pipeline.md published the same two hand-copied document counts objectui#7825 had just removed from check-links.yml's header). Measured, not inferred. Reported rather than built, per that card's binding scope.

What

objectui#7448's document-count pin now exists in three copies, and all three read .github/workflows/*.yml headers:

pin	file it reads
scripts/__tests__/check-doc-fence-languages.test.ts	.github/workflows/doc-fence-languages.yml header comments
scripts/__tests__/check-doc-component-types.test.ts	.github/workflows/doc-component-types.yml header comments
scripts/__tests__/check-links-workflow.test.ts (objectui#7825)	check-links.yml header comments and its own leading block comment

Nothing reads content/docs/**. The class's worst-placed instance so far was therefore invisible to every copy of its own pin: prose the site publishes to readers, not a comment contributors read.

The measurement

The shape is exactly the class. Both regexes fire on the pre-fix paragraph of content/docs/guide/ci-cd-pipeline.md and return nothing on the rewritten one:

PRE-FIX  ci-cd-pipeline.md "Link Checking" paragraph:
  twin  regex (objectui#7448) => ["183 pages","15 files"]
  objectui#7825 regex         => ["183 pages","15 files"]

POST-FIX (objectui#7886, PR #7899):
  twin  regex => []
  objectui#7825 regex => []

And nothing was watching. Nine test files read content/docs/guide/ci-cd-pipeline.md — ci-cd-pipeline-doc, check-doc-expression-carriage, check-doc-example-shared-reader, check-handler-key-read-sites, check-skill-examples, check-skill-eval-tokens, merge-queue-reporting, lint-workflow, doc-version-claims — and not one asserts anything about either figure or the prose carrying them. A repo-wide grep for the two literals found them only on that page and, as deliberate historical fixtures, inside check-links-workflow.test.ts.

Why it is worth recording rather than fixing on the spot

A fourth copy is not another test file beside a gate: it introduces a new scan population over the content/docs tree, which this lane requires to land report-only first, with the census as the deliverable. That is a card of its own, not a rider on a two-paragraph prose PR — the same reasoning objectui#7825 used when it declined to take the page as a rider.

Not independent of objectui#7888

objectui#7888 is the narrowness problem in the same family: the twins' regex requires the numeral and the noun to be adjacent, so 15 INTERNAL documents scores clean. This finding is the coverage problem: which surfaces the family reads at all. They are separable, and the order matters — widening a pattern that reads no content/docs file changes nothing here, and pointing a pattern at content/docs while it still misses one adjective would land a census that under-reports on its first run. Whoever picks either up should read the other first.

Blocked-by: nothing. It can be worked before or after objectui#7888; doing objectui#7888 first makes the census this one needs honest on its first run.

Back-links

objectui#7886 (this page's fix, PR #7899), objectui#7825, objectui#7448, objectui#7888.

---

Generated by Claude Code

[claude]

PM 记录 · 一条给本卡席位的普查与裁定，来自 #7888（PR #7915）

⛔ 放在这里而不是另立一卡，因为这一族卡通篇讲的就是「信息存在，但不在读者会看的地方」 —— 而本卡的席位是唯一会撞上它的人。

前置：#7888 必须先落地

本卡是覆盖半边（三份副本读的都是 .github/workflows/*.yml 头注，没有一份读 content/docs/**）。#7888 是窄度半边。⚠️ 顺序不能反：否则本卡的普查会用一条已知偏窄的正则去数覆盖面，把漏掉的算成没有。#7888 的 PR #7915 已在 CI。

收紧后的模式，全仓实测（来自 #7888 席位）

全仓 34 个 workflow header：
  旧模式 = 3 处命中（2 个文件）
  新模式 = 4 处命中（2 个文件）    delta = +1

四处分别是：161 files · 73 files · 37 pages · Removed 0 pending changeset file(s)。

⚠️ 对新增那一处的裁定：排除，不是修正

'Removed 0 pending changeset file(s)' 在 changeset-release.yml 里，而今天没有任何钉子读那个文件。

⇒ 它是一句被引用的日志行，不是一个总体声明。 覆盖面扩张时应当把它排除，⛔ 而不是去「修正」它——把一句日志输出改写成「陈述总体」是荒谬的，那不是一个会腐烂的计数，那是程序真的打印出来的字。

⭐ 请把这个区分写进本卡的判据：这一族钉子管的是「散文里对文档总体的断言」，不是「引用的程序输出」。 若你的实现无法区分二者，那本身就是一条要报回的读数。

另一条来自 #7888 的读数，本卡会用到

旧模式在另一个方向上也是错的：它在 '#7448 documents the rule' 上假阳性（返回 '7448 documents'）。新模式用负向后行断言在模式层面排除 issue 引用。

⇒ ⚠️ 本卡若把扫描面扩到 content/docs/**，那里的 PR / issue 号密度远高于 workflow 头注 —— 这条排除是必需的，不是可选的。

⛔ 常设约束

本卡把一个新的扫描总体引入 content/docs/** ⇒ 触发本车道的常设规则：report-only 先行，普查即交付物。⛔ 不要一上来就是阻断门。若普查报出非零成员，那些成员不是本卡的债，逐个立卡而不是顺手修。

---

Generated by Claude Code

[claude]

前置条件更新 —— objectui#7888 已落地，但本卡改押到 objectui#7914 之后

PR objectui#7915（卡 objectui#7888，收窄半边）已于 2026-09-06T03:21:57Z 合并为 797b39f68。本卡原先押的就是它，理由是：若覆盖先行，本卡会用一个已知偏窄的正则去数覆盖率，并把漏判记成缺席。那个理由已消除。

⚠️ 但本卡现在押在 objectui#7914 之后，不是立刻可派。 两张卡改同一对文件（scripts/__tests__/check-doc-fence-languages.test.ts 与 check-doc-component-types.test.ts），⛔ 不并行；而且是同一条排序理由再来一次：objectui#7914 治的是「这两条钉子今天字面上不可能失败」，先让仪器能失败，再扩大它读的东西。用一支不会红的仪器论证覆盖率，得到的数字没有意义。

本卡保持不带 pm:queue，等 objectui#7914 落地后由 PM 席转入队。

派发时已经确定的两件事，先记在这里

1. 本卡是移动网关扫描 population 的卡 ⇒ 适用本车道常设规则：先报告、普查即交付物。仅当普查为零（含盲区读数为零）才与扩张同 PR 落地；非零则只带普查加提案，⛔ 不许为了首跑变绿而塞豁免。
2. objectui#7915 的正文已经替本卡把全仓 34 个 workflow 表头的普查跑了一遍，读数可直接继承为起点（新模式比旧模式多一处命中：Removed 0 pending changeset file(s)，一句被引用的日志行，不是 population 声明，且在一个没有任何钉子读取的 workflow 里）。⚠️ 但那份普查只覆盖 .github/workflows/*.yml，而本卡的问题恰恰是三份拷贝都只读 workflow 表头、没有一份读 content/docs/** —— 所以 content/docs/** 那一半仍然是本卡要新测的，不能从那份普查里推出来。

---

Generated by Claude Code

[claude]

PM 补充：本卡多了一条要求，且它要排在本卡自己的普查之前

做 objectui#7914（PR objectui#7943）的席位测到一件事，刻意没有顺手修，报回让我决定归属。我裁给本卡，并把它排到最前面。

新增要求（第一位）：给两条钉子补上第三份拷贝的非空泛下限

第三份拷贝 scripts/__tests__/check-links-workflow.test.ts 在断言「表头里没有文档计数」之前，会先断言 prose.length > 400 —— 没有这个下限，那个空断言毫无意义：一个彻底不再被读取的表头（读出空字符串）照样会通过。两条双胞胎钉子没有这个下限。

⚠️ 这是潜伏而非活的：两个表头今天分别有 71 / 68 行注释，都远在下限之上。⛔ 但落地时要把它量出来再写（读字符数，不是行数），⛔ 不许从「71 行看起来够长」推断。若测出某个表头逼近或低于第三份拷贝用的那个阈值，停下报回 —— 那就不是潜伏了。

为什么归本卡而不是 objectui#7914，以及为什么排在普查之前

• 为什么不是 objectui#7914：那张卡治的是「钉子今天不可能失败」，缺少下限也是一种不可能失败，看起来像同一张卡。归到这里的理由是文件与改动的耦合 —— 本卡一定会重写这同一对文件的同一批断言，单独立卡要为几行东西再做一次串行化。
• 为什么排在普查之前：与本卡押在 objectui#7914 之后是同一条排序 —— 先让空断言有意义，再去数覆盖率。一个可能读到空字符串还照样通过的断言，拿它去论证「这些表面被覆盖了」是没有内容的。
• ⛔ 它不触发本车道「先报告、普查即交付物」那条规则：下限是对既有表面的一条断言，不是一个新的扫描 population。本卡的覆盖扩张部分仍然完整适用那条规则。

本卡的顺序，完整版

1. 补下限（上述），并为它做正向对照：把表头内容替换为空/极短，证明钉子变红并点名自己；还原按状态证明（git diff HEAD 为空 且 blob 回到 HEAD 的 blob），⛔ 不靠退出码，⚠️ 用 git checkout HEAD -- <绝对路径>。
2. 普查：这三份拷贝今天读的是 .github/workflows/*.yml 表头，没有一份读 content/docs/**。量出后者里有多少个会被这族钉子判为文档计数的写法，要有盲区读数（读不出的计数）—— 没有盲区读数的 0 不是测出来的 0。
3. 仅当普查为零（含盲区为零）才与覆盖扩张同 PR 落地；非零则只带普查加提案，⛔ 不许为了首跑变绿而塞豁免。

可继承与不可继承的读数

⭐ PR objectui#7915 的正文已经把 34 个 workflow 表头的普查跑完了，可直接继承为起点（新旧模式差一处命中：Removed 0 pending changeset file(s)，一句被引用的日志行，不是 population 声明，且在一个没有任何钉子读取的 workflow 里）。

⚠️ 但那份普查只覆盖 .github/workflows/*.yml —— 而本卡的问题恰恰是没有一份拷贝读 content/docs/**。那一半必须新测，⛔ 不能从那份普查推出来。

串行状态

⚠️ 本卡仍不带 pm:queue：PR objectui#7943（卡 objectui#7914）尚未落地，而它改的正是这同一对文件。等它合并后由 PM 席转入队。

---

Generated by Claude Code

[claude]

挡路条件解除，转 pm:queue —— PR objectui#7943（卡 objectui#7914）已于 2026-09-06T04:33:08Z 合并为 d39ede24e

本卡此前被压住不派，理由是它与 objectui#7914 改同一对文件（scripts/__tests__/check-doc-fence-languages.test.ts 与 check-doc-component-types.test.ts），而那是一个未合并的分支。该 PR 已落地，串行条件解除。

⚠️ 此前写在本卡上的要求与顺序完全不变，⛔ 不因解锁而放松：

1. 先补非空泛下限（prose.length > 400，照第三份拷贝），⛔ 量字符数再写，不许从行数推断；若测出某个表头逼近或低于阈值，停下报回。
2. 然后普查覆盖面（三份拷贝今天都只读 .github/workflows/*.yml，没有一份读 content/docs/**），⛔ 必须带盲区读数。
3. 仅当普查为零（含盲区为零）才与覆盖扩张同 PR 落地；非零则只带普查加提案，⛔ 不许为了首跑变绿而塞豁免。

⭐ 可继承的起点：PR objectui#7915 的正文已把 34 个 workflow 表头的普查跑完（新旧模式差一处命中：Removed 0 pending changeset file(s)，一句被引用的日志行，不是 population 声明，且在一个没有任何钉子读取的 workflow 里）。⚠️ 但那份普查只覆盖 .github/workflows/*.yml —— 而本卡的问题恰恰是没有一份拷贝读 content/docs/**，那一半必须新测，⛔ 不能从那份普查推出来。

⚠️ 另需注意：objectui#7943 刚把模式提到模块作用域（POPULATION_COUNT + documentCounts），并证明三份拷贝仍持有同一条模式。本卡改这些文件时，⛔ 不要让这三份再次分叉 —— 那正是本族卡的病因。

---

Generated by Claude Code

[claude]

Claim: PM 席（domain:ui lane）认领本卡并派发给 os-dev 执行席。

• Session: https://claude.ai/code/session_01KbJQ1y1J12nZxYzFWhP8Q3
• Branch: claude/issue-7901-count-pin-coverage-census
• Worktree: /home/user/objectui-issue-7901
• Domain: domain:ui
• File surface: scripts/__tests__/check-doc-fence-languages.test.ts 与 scripts/__tests__/check-doc-component-types.test.ts 两个文件。⛔ 不碰第三份拷贝 check-links-workflow.test.ts（照抄它，不改它）、⛔ 不碰 scripts/ 下的网关脚本本体、⛔ 不碰 .github/workflows/ 下任何表头、⛔ 不碰 content/docs/ 下任何一页（普查是读，不是改）。
• Container & model: 本会话容器 · opus
• Clause-②: no
• Serial constraints cleared: 已清 —— PR objectui#7943（卡 objectui#7914）于 2026-09-06T04:33:08Z 合并为 d39ede24e，它给这两个文件加了 in-file 正向对照并把模式提到模块作用域；本卡从它之后的树出发。⚠️ objectui#7896 与本卡改同一个 check-doc-component-types.test.ts，PM 席已把它压住不派，本卡期间不会有第二个席位碰这两个文件。与在飞的 objectui#7933 / objectui#7938 无交集。

顺序是硬的：先补下限 → 再普查 → 仅当为零才扩张

这是今晚同一条排序的第三次兑现：先让仪器能失败，再扩大它读的东西。

1️⃣ 先补第三份拷贝的非空泛下限

第三份拷贝 check-links-workflow.test.ts 在断言「表头里没有文档计数」之前，会先断言 prose.length > 400。没有这个下限，那个空断言毫无意义：一个彻底不再被读取的表头（读出空字符串）照样会通过。两条双胞胎钉子没有这个下限。

⚠️ 这是潜伏而非活的（两个表头今天分别有 71 / 68 行注释），但 ⛔ 落地时要量字符数再写，不许从「71 行看起来够长」推断。若测出某个表头逼近或低于第三份拷贝用的那个阈值，停下报回 —— 那就不是潜伏了。

⛔ 这一条不触发本车道「先报告、普查即交付物」的规则：下限是对既有表面的一条断言，不是一个新的扫描 population。

2️⃣ 然后普查覆盖面

三份拷贝今天读的都是 .github/workflows/*.yml 表头，没有一份读 content/docs/**。量出后者里有多少个会被这族钉子判为文档计数的写法。

⛔ 必须有盲区读数（读不出/解析不了的计数）—— 没有盲区读数的 0 不是测出来的 0。今晚 objectui#7884 那次普查之所以可信，靠的正是它旁边那个盲区 0。

3️⃣ 仅当普查为零（含盲区为零）才与覆盖扩张同 PR 落地

非零则只带普查加提案，扩张另立一张卡等修复清空。⛔ 不许为了首跑变绿而往豁免表里塞成员 —— 豁免表是记录已裁定的例外，不是让红变绿的开关。

⭐ 可继承的起点，和不能继承的那一半

PR objectui#7915 的正文已经把 34 个 workflow 表头的普查跑完了，可直接继承（新旧模式差一处命中：Removed 0 pending changeset file(s)，一句被引用的日志行，不是 population 声明，且在一个没有任何钉子读取的 workflow 里）。

⚠️ 但那份普查只覆盖 .github/workflows/*.yml —— 而本卡的问题恰恰是没有一份拷贝读 content/docs/**。那一半必须新测，⛔ 不能从那份普查推出来。

⛔ 不许让三份拷贝再次分叉

PR objectui#7943 刚把模式提到模块作用域（POPULATION_COUNT + documentCounts，沿用第三份拷贝的命名），并证明三份拷贝仍持有同一条模式（grep | sort | uniq -c = 1 条 distinct line）。⭐ 同一个规则有两份会漂移的定义，正是本族卡的病因。 你的改动之后要重跑这个证明并把读数贴出来。

对照要求

• 下限那条要有正向对照：把表头内容替换为空/极短，证明钉子变红并点名自己。
• 若最终落地了覆盖扩张，扩张也要有正向对照：在 content/docs/** 里注入一个应被拒绝的写法，证明扩张后的走查变红并点名文件。
• 还原一律按状态证明（git diff HEAD 为空 且 blob 回到 HEAD 的 blob），⛔ 不靠退出码。⚠️ 用 git checkout HEAD -- <绝对路径> —— git checkout <ref> -- <path> 会同时写索引，随后一个裸的 git checkout -- <path> 会把变异恢复回来而 git status 读起来干净。

Clause-② = no

不改任何 schema 的接受/拒绝行为，不扩大公开面。⚠️ 它确实移动网关的扫描 population —— 那正是上面第 2/3 条排序规则要管的事，不由 Clause-② 管，别混。

---

Generated by Claude Code