Skip to content

The line telling you what to widen to should name your documentation, not your biggest folder - #23

Merged
melbinjp merged 2 commits into
mainfrom
suggest-the-documentation-tree
Aug 19, 2026
Merged

The line telling you what to widen to should name your documentation, not your biggest folder#23
melbinjp merged 2 commits into
mainfrom
suggest-the-documentation-tree

Conversation

@melbinjp

Copy link
Copy Markdown
Owner

report_coverage names the unread directories and then tells the reader how to widen. It picked the directory to suggest by file count, which is almost never the documentation.

Measured

Sweep batch 10: twenty-three public repositories, 4,819 unread documentation files. The largest unread top-level segments across all of them:

segment files
skills/ 429
tools/ 176
docs.feldera.com/ 131
datafusion/ 123
.changeset/ 108
.claude/ 108
src/ 97
backends/ 77
crates/ 69

One of those nine is documentation. The rest are source-tree READMEs, agent skill definitions and changelog fragments, which is exactly what find_docs excludes and exactly what its docstring says it excludes: "a fixture, a vendored README or a changelog fragment deep in a package is not a promise the project is making."

So the scope was never the defect. Grouped by kind, the 4,819 unread break down as 30% package-internal, 17% working documents (plans, tickets, agent skills), 9% changelogs, and the remainder mostly source-tree READMEs. The default is right. The advice underneath it was wrong.

What it did

project suggested its actual documentation tree
immich-app/immich mobile/ (89) readme_i18n/ (20)
pytorch/executorch examples/ .wiki/
langchain-ai/deepagents libs/ openwiki/

Three of twenty-three change. The other twenty already pointed at the right place, or had nothing better to point at.

And when nothing looks like documentation, it says so

superset-sh/superset has 276 unread across apps/ 116, plans/ 100, packages/ 21. Suggesting apps/**/*.md tells the reader to widen into precisely the package-internal READMEs the scope exists to skip, which would manufacture the findings nobody asked for. It now prints:

     none of them is named like a documentation tree; if one is, widen with
     --docs 'DIR/**/*.md' or [tool.docproof] docs = ["DIR/**/*.md"]

Both routes stay, because a project whose docs live somewhere odd still needs to know how to say so.

The list itself still ranks by count, unchanged: that is what shows the reader the shape of their tree, and .changeset/ 108 is self-explaining in a way a curated list would not be.

199 tests.

… not your biggest folder

Measured over sweep batch 10, twenty-three repositories, 4,819 unread documentation
files. The largest unread segments across all of them:

    skills/ 429, tools/ 176, docs.feldera.com/ 131, datafusion/ 123,
    .changeset/ 108, .claude/ 108, src/ 97, backends/ 77, crates/ 69

One of those nine is documentation. The rest are source-tree READMEs, agent skill
definitions and changelog fragments, which is to say find_docs is RIGHT to leave them
out and its docstring already argues so. The scope was never the defect. The defect was
that the line telling a reader how to widen picked the biggest directory, so immich was
told to read mobile/ while its readme_i18n/ tree went unmentioned, executorch was told
examples/ over .wiki/, and deepagents libs/ over openwiki/.

And where nothing is named like documentation, it now says that instead of naming the
biggest. superset has 276 unread across apps/, plans/ and packages/; suggesting apps/
would tell the reader to widen into exactly the package-internal READMEs the scope
excludes on purpose. Both widening routes are still printed for a project whose docs
live somewhere odd.

Three of twenty-three suggestions change. The other twenty already pointed at the right
place or had nothing better to point at.

199 tests.
@melbinjp
melbinjp merged commit f544a54 into main Aug 19, 2026
21 checks passed
@melbinjp
melbinjp deleted the suggest-the-documentation-tree branch August 19, 2026 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant