Context
modules/metadata converts each repo's DESCRIPTION.md and TAGS.md into a GitHub description and topic list. It has 6 passing tests and reproduces live GitHub values for 50 of 54 repos, with the 4 exceptions handled by explicit overrides.
Two gaps are real but unreachable with current repository content. Neither is urgent. Both are cheap, and both fail in ways that are annoying to diagnose later.
Gap 1, no guard on GitHub's 50-character topic limit
The module caps topic count at 20 but never checks individual topic length. GitHub rejects topics over 50 characters with a 422, which would fail the apply for that repository.
Longest derived topic today is 32 characters (round-trip-string-json-converter), so nothing currently trips it. A single long tag added to any TAGS.md would.
Gap 2, desc_clean strips carriage returns but not newlines
desc_clean = trimspace(replace(var.description_raw, "\r", ""))
Every DESCRIPTION.md in the org is currently a single line. A future two-paragraph description would embed a newline, split(". ") would not see the .\n sentence boundary, and truncation would silently degrade to the word-boundary fallback instead of cutting on a sentence. The output stays valid, it just quietly gets worse.
Acceptance criteria
Lower priority
There is also a whitespace edge case: the fallback returns "" if the first 349 characters are entirely whitespace. That is semantically the right answer for a whitespace-only file and is not worth code.
Context
modules/metadataconverts each repo'sDESCRIPTION.mdandTAGS.mdinto a GitHub description and topic list. It has 6 passing tests and reproduces live GitHub values for 50 of 54 repos, with the 4 exceptions handled by explicit overrides.Two gaps are real but unreachable with current repository content. Neither is urgent. Both are cheap, and both fail in ways that are annoying to diagnose later.
Gap 1, no guard on GitHub's 50-character topic limit
The module caps topic count at 20 but never checks individual topic length. GitHub rejects topics over 50 characters with a 422, which would fail the apply for that repository.
Longest derived topic today is 32 characters (
round-trip-string-json-converter), so nothing currently trips it. A single long tag added to anyTAGS.mdwould.Gap 2,
desc_cleanstrips carriage returns but not newlinesEvery
DESCRIPTION.mdin the org is currently a single line. A future two-paragraph description would embed a newline,split(". ")would not see the.\nsentence boundary, and truncation would silently degrade to the word-boundary fallback instead of cutting on a sentence. The output stays valid, it just quietly gets worse.Acceptance criteria
Lower priority
There is also a whitespace edge case: the fallback returns
""if the first 349 characters are entirely whitespace. That is semantically the right answer for a whitespace-only file and is not worth code.