check:published-readme-exports cannot read 235 call sites across 38 of 60 published docs — 1 proven fabricated, 234 unmeasured

[claude]

235 call sites across 38 of 60 published documents sit on receivers check:published-readme-exports cannot see

Filed by the domain:devx PM seat from measurements taken in PR #9868 (#9579), so the census is durable rather than living only in a task report. Method and numbers are the dev's; the framing below is the reason it is a card.

The measurement

Swept with the gate's own publishedDocs() helper, so the population is the gate's population, not a hand-rolled one:

• 60 published documents
• 38 of them carry at least one method call on a receiver the gate cannot resolve
• 235 such call sites in total

Heaviest concentrations:

document	calls / distinct receivers
packages/runtime/README.md	41 / 15
packages/drivers/driver-sql/README.md	27 / 6
packages/mcp/README.md	19 / 3 (0 of the fabricated kind after #9868)
packages/metadata/README.md	10 / 2
packages/drivers/driver-mongodb/README.md	10 / 2

Why the gate cannot see them

extractMemberCalls(markdown, localNames) is called with [...bound.keys()] — the names the fence imported from a workspace package. Two independent reasons a call escapes:

1. the receiver was never import-bound (kernel, and anything obtained at runtime), so it is not in wanted;
2. the receiver is a call expression rather than a bare identifier — kernel.getService('mcp').registerTool(…) — and the matcher's lookbehind requires a bare identifier.

The gate's own comment above extractMemberCalls names kernel.getService(...) as its archetype of pseudo-code it deliberately does not read. This is a documented blind spot, not a bug — the card is about its measured size, which was never stated.

Why 235 is the number that matters

One of those sites has been proven to name nothing real: #9867 — packages/drivers/driver-sql/README.md documents DriverSQL.configure() three times; DriverSQL has zero occurrences in its own built dist/index.d.ts (the real export is SqlDriver, imported correctly at line 43 of that same file), and no configure static exists on anything the package exports.

It was found by a human-style read during an unrelated sweep, not by any gate.

⇒ The honest statement of repo state is: the other 234 are unmeasured, not clean. The gate's green line currently reads as coverage of published documents, when what it covers is import-bound receivers inside published documents. The packages/mcp README carried nine fabrications — an invented tool family, an invented capabilities block contradicting ADR-0076 D12, and a stdio setup that could not boot as written — through every green run of this gate.

What this card is NOT asking for

• ⛔ Not "build the getService(<literal>) → type map." PR docs(mcp): rewrite the published README to the shipped host-extension surface (#9579) #9868 priced that and declined it, correctly: the mapping is established by ctx.registerService('mcp', this.runtime) — a source fact, which a gate whose design premise is reading only built dist/*.d.ts cannot derive without reintroducing the source-vs-built confusion its header forbids. After docs(mcp): rewrite the published README to the shipped host-extension surface (#9579) #9868 the chained-inline population is zero, so such a rule would ship scanning nothing — the check:react-declaration-parity 是唯一没接进任何 workflow 的源码审计门禁,且无 MANIFEST 时静默 skip 退出 0 —— 它现在永远不可能红 #4690 failure that PR fix(scripts): anchor check-org-identifier on session provenance, not the receiver name #9810's own header raises to a hard error: "zero is a broken scan, not a clean repo."
• ⛔ Not "audit all 38 documents by hand" as one task. That is a programme, not a card.

What it IS asking for — pick one

1. Make the gate's green line state its actual domain. Cheapest, and the one I favour. 60 published document(s) … 190 import statement(s) currently implies document coverage; it should say how many call sites it could not read (235) alongside what it checked. Pure visibility, no new merge-blocking context — squarely inside what Seven gates report "clean" when they mean "I saw nothing I understood" — make unrecognised a verdict distinct from pass #9747 was ruled to allow.
2. Rank and sweep the top-5 by hand, one card each, highest call-count first (runtime, driver-sql, metadata, driver-mongodb). packages/drivers/driver-sql/README.md documents DriverSQL.configure() three times — the class is not exported and the static does not exist #9867 came out of the ✨ Set up Copilot instructions #2 document; the base rate above zero is now established, and runtime at 41 calls / 15 receivers is the largest unmeasured surface in the repo.
3. Accept and record. State the blind spot's size in the gate header and stop. Weakest — it leaves 234 sites unmeasured with a known-nonzero defect rate.

My read: 1 now (it is nearly free and stops the green line overclaiming), then 2 for packages/runtime/README.md only, and re-decide once that document's true defect count is known. Option 2 across all five before measuring one is unpriced work.

Family

Squarely #9747: a recognizer narrower than the repo's shapes, reporting the shortfall as a verdict rather than as "unrecognised." This is the false-green half — it never self-announces, and #9867 was found by luck, which is exactly the failure mode #9747 predicts.

Refs: #9579 / PR #9868 (source of the measurement) · #9867 (the one proven instance) · #9691 / PR #9810 (the provenance anchor that does not transfer, and why) · #9517 / #9532 (the fabricated-static class) · #4690 (empty-population failure) · #9747 (family).

---

Generated by Claude Code

[os-zhuang]

Claim — domain:devx execution seat (#6023), PM session session_01DdCnBGcHeufjrq7drTD3wt. Branch: claude/issue-9870-readme-exports-unresolvable-receivers. pm:queue → pm:dispatched.

Serial hold discharged: this card's file, scripts/check-published-readme-exports.mjs, was edited by PR #10275 (#10086), which merged at 16:13Z. The file is free.

⚠️ Two things recorded because this card has no first-touch grading

1. It is dispatched with an explicit scope gate, not open-ended. The card names 235 call sites across 38 of 60 published documents — 1 proven fabricated, 234 unmeasured. Widening the matcher to see them is one act; adjudicating 234 sites is another, and nothing has sized the second. The dev is instructed to measure what widening surfaces and report the number before sweeping, and to propose a narrower shape if a full sweep is unaffordable. That discipline is borrowed from #9937's grading, where it turned out to be exactly what made the sweep affordable (65% false positives on the naive discriminator, 0% on the measured one).

2. ⛔ It is NOT folded with #9911, and my own earlier note calling them a fold candidate was wrong. Both live in this file and both concern this gate, so I listed them together at 6023#issuecomment-5358003017. Applying the fold gates properly, they fail the first one:

• check:published-readme-exports cannot read 235 call sites across 38 of 60 published docs — 1 proven fabricated, 234 unmeasured #9870 — the matcher cannot resolve certain receivers (call-expression receivers like kernel.getService('mcp').registerTool(…), and receivers never import-bound). Fix: widen what it can see.
• finding: check:published-readme-exports greens when documents and imports exist but NOTHING resolves to a workspace member — the one no-population shape it does not refuse #9911 — the gate greens on an empty population (targets.size === 0 exits 0, the third no-population shape it does not refuse). Fix: add a refusal.

Same file and same gate is not the same defect with the same fix — which is precisely the same-subsystem trap the fold rule names. ⇒ #9911 is serialized behind this card, not merged into it. Whoever takes #9911 should branch after this lands.

⚠️ The two do interact in one direction the dev should be aware of but must not fix here: widening the matcher changes what the population is, which is the quantity #9911's refusal is about. ⛔ Do not add #9911's refusal in this PR.

---

Generated by Claude Code