You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed unassigned for triage by the dev seat that implemented #6893 (PR #7007). This is the half of #6893 that PR deliberately did not attempt, split out because it is a design decision rather than a defect fix, with the measurement attached so the next person does not have to redo it.
Searched open issues first (drift symbol granularity docs affected-docs, "docs drift") — only #6893 itself and unrelated #7002.
#7003 is the sharper specimen of the two: if package granularity cannot tell a prose-only JSDoc reword from a semantic change, the "may need an implementation-accuracy re-verification" claim carries essentially no information on that class of PR.
Two reasons, both worth the maintainer's attention before anyone starts:
It contradicts a stated design principle in the tool itself.scripts/docs-audit/affected-docs.mjs says, in its header: "Over-inclusion is intentionally preferred over misses; the periodic FULL audit is the backstop for docs that describe a package without naming it." Narrowing to symbols or exports trades that the other way. That is a legitimate trade to make — but it is a decision about what the check is for, not a bug fix, and it should be made deliberately.
A narrower edge that misses a doc is strictly worse than a wide one that over-lists, because catching drift is the whole point. The failure mode is invisible: the comment gets shorter and looks better while quietly reporting less.
Two edge kinds, both of which any narrowing must handle
On #7003, 12 rows came from the npm name (via @objectstack/client) and 2 from the repo path (via packages/client). These are separate arms of the matcher. Narrowing one and leaving the other yields a half-fix that looks complete on whichever specimen you happen to test.
Cap and summarise. Above N docs print the count plus the top few by reference density, with the full list behind a drill-down. Cheap, honest about being coarse, changes nothing about what is computed. fix(devx): docs drift check —— dev-only manifest 改动不再点亮整包文档,release 页改为只读分区 (#6893) #7007 deliberately did not do half of this: choosing N and the ranking belongs with whoever owns the granularity question.
Filter to docs the diff can plausibly affect — e.g. only those whose own frontmatter names a symbol in the diff. Note that hand-written docs currently carry no such frontmatter (checked: title / description only), so this direction implies authoring it first.
Filed unassigned for triage by the dev seat that implemented #6893 (PR #7007). This is the half of #6893 that PR deliberately did not attempt, split out because it is a design decision rather than a defect fix, with the measurement attached so the next person does not have to redo it.
Searched open issues first (
drift symbol granularity docs affected-docs,"docs drift") — only #6893 itself and unrelated #7002.What #7007 fixed, and what it left
PR #7007 removed two things from the Docs Drift Check advisory:
package.jsonwhose changed top-level keys are all in{scripts, devDependencies}no longer counts as a package change. This was the entire cause of [finding][devx] Docs Drift Check is package-granular, so any PR touching @objectstack/spec lists ~112 docs — an advisory that large is one every reader learns to skip #6893's headline "112": PR feat(devx): 给 check:dev-prereqs 补上「陈旧 dist」判定(内容指纹,非 mtime) (#5864) #6892's onlypackages/change was onescripts.buildline. Measured across 400 merged commits, five commits had a manifest as their sole implementation change, all five dev-only, 152 false rows total, now 0.content/docs/releases/**rows are now partitioned into a read-only section that says "file an issue, do not edit here", per the docs-accuracy-audit 会就地改写 content/docs/releases/**(9 页),与 AGENTS.md「release-owned,禁止在代码 PR 中编辑」直接冲突 #4920 ruling (they stay in the computed set; only the presentation forks).It changed nothing about how a changed package maps to docs. That mapping is still: doc text mentions the package's npm name or repo path.
The residual, measured
packages/client/src/index.ts— no behaviour, no export, no typepackages/spec/src/**change (storage contract)#7003 is the sharper specimen of the two: if package granularity cannot tell a prose-only JSDoc reword from a semantic change, the "may need an implementation-accuracy re-verification" claim carries essentially no information on that class of PR.
Why #7007 did not narrow the edges
Two reasons, both worth the maintainer's attention before anyone starts:
scripts/docs-audit/affected-docs.mjssays, in its header: "Over-inclusion is intentionally preferred over misses; the periodic FULL audit is the backstop for docs that describe a package without naming it." Narrowing to symbols or exports trades that the other way. That is a legitimate trade to make — but it is a decision about what the check is for, not a bug fix, and it should be made deliberately.Two edge kinds, both of which any narrowing must handle
On #7003, 12 rows came from the npm name (
via @objectstack/client) and 2 from the repo path (via packages/client). These are separate arms of the matcher. Narrowing one and leaving the other yields a half-fix that looks complete on whichever specimen you happen to test.Directions (unchanged from #6893, none chosen)
title/descriptiononly), so this direction implies authoring it first.Reproducing the measurement
docsis the full set,releaseOwnedDocsits read-only subset,detail[].vianames the edge kind that produced each row.