Filed unassigned from the domain:cli lane while landing #11180 and #11262. Recording only — not graded here, and no domain:* applied: this seat does not produce routing.
The observation
The docs-drift check answers a README-only diff with:
Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)), so this run has no opinion about the docs.
- 1 changed file(s) yielded no anchor (
packages/console/README.md) — pages documenting those are invisible to this run
Measured live today on this lane's own PRs, twice, with the changed file named each time: packages/console/README.md (#11262) and packages/cli/README.md (#11180).
Why this is filed even though #9282 is closed
⚠️ It is not a duplicate and not a regression. I checked by symptom rather than by issue number, per the shared-infrastructure rule, and then read how the sibling actually closed.
#9282 recorded exactly this mechanism — "the file that CARRIES a rule several pages restate yields no anchor, so changing the rule produces 'no opinion'" — and listed four possible closes. It was closed by PR #9394, feat(docs-audit): anchor a changed @docs-rule block on the expressions it states, which is its option 1: an explicit opt-in marker.
That close is sound for what it covers, and it does not reach a README. A README carries no @docs-rule block, exports no symbol, mounts no route, and declares no SDK method — so it remains anchorless, and #9282's own options 3 (fall back to the coarse package-mention list for an anchorless file's package rather than reporting no opinion) and 4 (record in the check's own output that anchorless files are not covered, so "no opinion" is never read as "nothing to check") were not taken.
Why READMEs specifically are worth the row
A README is documentation — it is the published front page of a package on npm — so a class of documentation the docs-drift check cannot see at all is a real hole rather than a tolerable exclusion. And the class is live, not theoretical: both README defects this lane landed today are precisely what the gate cannot detect.
Neither could have been surfaced by this check on any run. #9632 ("no gate reads a published README's links at all", closed) established the adjacent hole for README links; this is the same corpus, for README claims.
Anti-vacuity framing
This is the standard shape: a gate that extracts zero anchors passes perfectly. The honest half — and it is genuinely honest, per #9192's precision-first rework — is that the run names the file it could not anchor. The gap is purely in how the headline reads: a reviewer sees "no opinion" and reasonably concludes "nothing to check". Option 4 alone would close that reading without touching the anchor logic at all.
Not measured here
Routing note for triage: the tool is scripts/docs-audit/affected-docs.mjs and its workflow.
Related: #9282 (same mechanism, closed by PR #9394 taking option 1) · #9394 · #9192 · #9632 · #6893 · #7009 · #9037 · #11180 · #11262
Filed unassigned from the
domain:clilane while landing #11180 and #11262. Recording only — not graded here, and nodomain:*applied: this seat does not produce routing.The observation
The docs-drift check answers a README-only diff with:
Measured live today on this lane's own PRs, twice, with the changed file named each time:
packages/console/README.md(#11262) andpackages/cli/README.md(#11180).Why this is filed even though #9282 is closed
#9282 recorded exactly this mechanism — "the file that CARRIES a rule several pages restate yields no anchor, so changing the rule produces 'no opinion'" — and listed four possible closes. It was closed by PR #9394,
feat(docs-audit): anchor a changed @docs-rule block on the expressions it states, which is its option 1: an explicit opt-in marker.That close is sound for what it covers, and it does not reach a README. A README carries no
@docs-ruleblock, exports no symbol, mounts no route, and declares no SDK method — so it remains anchorless, and #9282's own options 3 (fall back to the coarse package-mention list for an anchorless file's package rather than reporting no opinion) and 4 (record in the check's own output that anchorless files are not covered, so "no opinion" is never read as "nothing to check") were not taken.Why READMEs specifically are worth the row
A README is documentation — it is the published front page of a package on npm — so a class of documentation the docs-drift check cannot see at all is a real hole rather than a tolerable exclusion. And the class is live, not theoretical: both README defects this lane landed today are precisely what the gate cannot detect.
os studio— the CLI ships no such command #11180 —packages/cli/README.mdadvertisedos studio, a command the CLI does not ship.packages/console/README.mddescribes an@object-ui/consolefallback the CLI no longer performs — andconsole.tssays the opposite in the same repo #11262 —packages/console/README.mdasserted a@object-ui/consolefallback that the code no longer performs.Neither could have been surfaced by this check on any run. #9632 ("no gate reads a published README's links at all", closed) established the adjacent hole for README links; this is the same corpus, for README claims.
Anti-vacuity framing
This is the standard shape: a gate that extracts zero anchors passes perfectly. The honest half — and it is genuinely honest, per #9192's precision-first rework — is that the run names the file it could not anchor. The gap is purely in how the headline reads: a reviewer sees "no opinion" and reasonably concludes "nothing to check". Option 4 alone would close that reading without touching the anchor logic at all.
Not measured here
@docs-ruleblock and opt in under the existing mechanism.Routing note for triage: the tool is
scripts/docs-audit/affected-docs.mjsand its workflow.Related: #9282 (same mechanism, closed by PR #9394 taking option 1) · #9394 · #9192 · #9632 · #6893 · #7009 · #9037 · #11180 · #11262