Summary
repo_audit.py compares a repo's GitHub topics against slugified pyproject.toml keywords. A maintainer who sets topics by hand — even sensible, correct topics — can therefore leave the github-metadata finding unresolved, with no indication of what the audit actually wanted.
Observed
On i2mint/guided, a hand-picked topic list did not clear the github-metadata finding, because the audit expects topics derived from the pyproject keywords via slugification rather than any reasonable-looking set.
Why it matters
The rollout automates the github-metadata dimension with gh repo edit --add-topic .... If the topic list is chosen from the package description rather than mechanically derived from keywords, the audit still reports drift after the fix — so the dimension looks unfixable and gets skipped.
Suggested fix
Either:
- Make the expectation explicit in the finding message — e.g.
topics drift: expected {slugify(k) for k in keywords}, got {...}, so the fix is obvious; or
- Relax the check to "topics is non-empty and overlaps keywords" rather than requiring exact slug correspondence; or
- Ship a helper (
wads ... sync-github-metadata) that derives and applies the topics from keywords directly, so hand-picking never happens.
(1) is the minimum — the current failure mode is that the audit knows the answer and does not say it.
Surfaced during the 2026-07-30 wave-0 rollout batch. Cross-ref: #51.
Summary
repo_audit.pycompares a repo's GitHub topics against slugifiedpyproject.tomlkeywords. A maintainer who sets topics by hand — even sensible, correct topics — can therefore leave thegithub-metadatafinding unresolved, with no indication of what the audit actually wanted.Observed
On
i2mint/guided, a hand-picked topic list did not clear thegithub-metadatafinding, because the audit expects topics derived from the pyprojectkeywordsvia slugification rather than any reasonable-looking set.Why it matters
The rollout automates the
github-metadatadimension withgh repo edit --add-topic .... If the topic list is chosen from the package description rather than mechanically derived fromkeywords, the audit still reports drift after the fix — so the dimension looks unfixable and gets skipped.Suggested fix
Either:
topics drift: expected {slugify(k) for k in keywords}, got {...}, so the fix is obvious; orwads ... sync-github-metadata) that derives and applies the topics fromkeywordsdirectly, so hand-picking never happens.(1) is the minimum — the current failure mode is that the audit knows the answer and does not say it.
Surfaced during the 2026-07-30 wave-0 rollout batch. Cross-ref: #51.