Skip to content

S1 — Name all three packages where the wheel is described, and check it (closes C-96) - #275

Merged
Polichinel merged 1 commit into
developmentfrom
docs/s1-package-count-class
Aug 18, 2026
Merged

Polichinel merged 1 commit into
developmentfrom
docs/s1-package-count-class

Conversation

@Polichinel

Copy link
Copy Markdown
Contributor

S1 of epic #267. Closes #268.

The problem

The wheel has shipped three packages since v1.7.0. Two live documents still said two:

Site What was wrong Which half of the check sees it
.github/workflows/publish_package.yml named two of three — in the workflow that actually publishes completeness only (no count word used)
docs/guides/publishing-to-pypi.md # sanity: BOTH packages + their py.typed literal only (the file names all three elsewhere)

The second is why this got a register entry. That file was corrected earlier the same day and the class reported as fixed, after grepping for one remembered phrasing — the fourth time this register has recorded a fix reaching the instance rather than the class, and the first where the miss sat inside a file already edited.

The check

docs/validate_docs.sh check 10, two halves, because neither catches the other case.

Scoping is the load-bearing part. Five correct uses exist — ADR-017 "Two packages to maintain", C-23 "shipped in both packages", three postmortem "two sibling packages" — all true when written. Flagging them would make the check noise, and noisy checks get deleted. So it takes an explicit list of documents describing the current wheel, the way check 3 restricts itself to the constitutional ADRs.

Mutation-tested five ways, all erroring

stale count word reintroduced       -> ERROR, names the file and line
package dropped from the guide      -> ERROR
package dropped from the workflow   -> ERROR
a FOURTH package added, undocumented-> ERROR  (the generalisation test)
pyproject package list unreadable   -> ERROR  (non-vacuity)

And it caught a real regression minutes after being written. Cleaning up after the first mutation with git checkout discarded the still-uncommitted workflow fix — the check failed on the next run rather than the mistake reaching a commit.

One thing worth knowing

The first draft of the corrected comment quoted the old wording to explain the change, and the literal half flagged it. I reworded rather than teaching the check about quotation. The check stays dumb; that is the property that makes it survivable.

What it does not catch, stated in its own comment: a novel phrasing that omits a package in a file which names all three somewhere else. The completeness half is per-file, not per-claim.

Verification

validate_docs.sh   PASSED — OK (wheel ships 3 packages; checked 2 wheel-describing documents)
ruff check         All checks passed!
pytest --cov       100.00%

Register: 93 entries, 10 open, 83 resolved, 0 actionable.

🤖 Generated with Claude Code

… it (closes C-96)

S1 of epic #267. Closes #268.

Two live documents still said the wheel ships two packages. It has shipped three
since v1.7.0.

- `.github/workflows/publish_package.yml` — a comment in the workflow that ACTUALLY
  PUBLISHES, naming two of three. It uses no count word, so only a completeness
  check sees it.
- `docs/guides/publishing-to-pypi.md` — "BOTH packages + their py.typed", two lines
  above a comment corrected earlier the same day to say "all three". That file names
  all three elsewhere, so only a literal check sees it.

The second is why this is registered rather than just fixed. That file was corrected
on 2026-08-18 and the class reported as fixed after grepping for one remembered
phrasing. Fourth time this register has recorded a fix reaching the instance instead
of the class, and the first time the miss was inside a file already edited.

**Check 10 has two halves because neither catches the other's case.** Completeness:
every package in `[tool.hatch.build.targets.wheel]` is named in each wheel-describing
document. Literal: no stale count word in those documents.

Scoped on purpose to documents describing the CURRENT wheel. ADRs, postmortems, this
register and the CHANGELOG state counts that were true when written — ADR-017's "Two
packages to maintain", C-23's "shipped in both packages" — and flagging those would
make the check noise, which is how a check gets deleted. Same reasoning as check 3,
which restricts itself to the constitutional ADRs.

Mutation-tested five ways, all erroring: a stale count word reintroduced; a package
dropped from either document; a FOURTH package added to the wheel target and left
undocumented (the generalisation test); an unreadable package list.

Then it caught a live regression minutes after being written. Cleaning up after the
first mutation with `git checkout` discarded the still-uncommitted workflow fix; the
check failed on the next run instead of the mistake reaching a commit.

One thing the writing of it surfaced: the first version of the corrected comment
QUOTED the old wording to explain the change, which the literal half then flagged.
Reworded rather than teaching the check about quotation — the check stays dumb, which
is the property that makes it survivable.

What it does not catch, in its own comment rather than left to be found: a novel
phrasing that omits a package in a file naming all three somewhere else. The
completeness half is per-file, not per-claim.

Register: 93 entries, 10 open, 83 resolved. Still 0 actionable.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Polichinel
Polichinel merged commit ea4a106 into development Aug 18, 2026
11 checks passed
@Polichinel
Polichinel deleted the docs/s1-package-count-class branch August 18, 2026 12:02
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.

S1 — Kill the two-package claim as a class, and add validate_docs check 10 (Epic #267)

1 participant