Compare the sentence in the roster against the description each repository publishes

[iderex]

Depends on #5 and on the roster parser issue.

The roster carries one sentence per plugin and the site renders it. Two other
copies of that sentence are already published, and they do not agree:

gh api repos/Flowfin/.github/contents/profile/README.md --jq '.content' \
  | base64 -d | grep -o 'Share one library item[^|]*'
Share one library item with invited guests, through a link that expires and can be revoked
gh api repos/Flowfin/jellyfin-plugin-share-links --jq '.description'
Share single Jellyfin items with invited, signed-in guests through expiring links

Run 2026-08-08. One plugin, two sentences, written at different times and never
compared. It is not one repository that has a description either:

gh repo list Flowfin --limit 60 --json name,description \
  --jq '[.[]|select(.name|startswith("jellyfin-plugin-"))|select(.description!="")]|length'
12

#5 makes the roster the source for the site and for the profile table and stops
there. That leaves the description on each repository as the copy nothing
derives and nothing compares, and this site is about to make the disagreement
easy to find, because a reader who opens a plugin page and then the repository
it links meets both sentences inside one click.

The comparison shape is a decision this issue records rather than assumes. Two
sentences written for different places can differ in wording and mean the same
thing, and a check demanding an exact match against prose somebody edits freely
is a check that goes red for nothing and gets switched off. Either the roster
sentence is the one both places carry, and the comparison is exact, or the
roster gains a second field for the repository description and the check
compares that one. The first costs a rewrite of twelve descriptions once. The
second costs a field and admits that the two audiences are different, which they
are: one is read next to a state word on a page that explains the project, the
other is read in a list of repositories with no context at all.

The check reports and does not write. A repository description is a setting on
another repository, nothing here has any business changing it, and the output is
a difference a person applies. That is #25's rule for the same reason.

It runs on a schedule rather than in the merge gate. It reads twelve
repositories over the network, and a merge blocked because somebody edited a
description elsewhere is a gate punishing the wrong change.

Fail closed on a fetch error. A run that could not read the descriptions says so
rather than passing as though they agreed.

Done when

The check runs on a schedule over the twelve repositories, reds when a
description differs from what the roster says it should be, names each differing
repository with both strings, writes nothing anywhere, and reports a fetch
failure as a failure rather than as agreement; and the issue records which of
the two comparison shapes was taken and what the other would have cost.

[iderex]

The body puts the cost of the exact comparison at a rewrite of twelve
descriptions once. I read both sets to see what that rewrite would have to do,
and one word decides most of it.

Every repository description names the server the plugin is for. None of the
twelve sentences in the profile does:

gh repo list Flowfin --limit 60 --json name,description \
  --jq '[.[]|select(.name|startswith("jellyfin-plugin-"))|select(.description|test("Jellyfin"))]|length'
12
gh api repos/Flowfin/.github/contents/profile/README.md --jq '.content' \
  | base64 -d | grep -E '^\| \[[a-z-]+\]' | cut -d'|' -f3 | grep -c 'Jellyfin'
0

Both run 2026-08-12. That is not twelve accidents. A description is read in a
list of repositories with nothing around it, so it carries the word that says
what the plugin plugs into, and a profile sentence is read in a table whose
heading has already said it. An exact comparison makes one of the two wrong:
either the roster sentence repeats the word inside a table that already carries
it, or the descriptions lose it and somebody meeting one in a repository list
has to guess what it is for.

The second thing that rewrite moves is a version, and there is an issue here
that asks for exactly that to be refused. One description names the server
generations:

gh repo list Flowfin --limit 60 --json name,description \
  --jq '[.[]|select(.name|startswith("jellyfin-plugin-"))|select(.description|test("[0-9]+[.][0-9]+"))]|map(.name)'
["jellyfin-plugin-sso"]
gh repo list Flowfin --limit 60 --json name,description \
  --jq '.[]|select(.name=="jellyfin-plugin-sso")|.description'
Single sign-on for Jellyfin via OpenID Connect & SAML 2.0 - a security-first revival of the archived 9p4/jellyfin-plugin-sso, for Jellyfin 10.11 (.NET 9) and 12.0 (.NET 10).

Both run 2026-08-12. #91 asks that no server version appear in the roster,
refused by the invariant gate with the offending file named. Making the roster
sentence the published description puts 10.11 and 12.0 into the roster,
which is what that row is meant to refuse, so the exact comparison and #91
cannot both be taken as they are written. Either the description drops the
generations first, or the exact shape is taken against a sentence another row
on this board refuses.

The sizes say the same thing again, measured against what the schema asks a
summary for:

gh api repos/Flowfin/site/contents/docs/roster-schema.md --jq '.content' \
  | base64 -d | sed -n '42,43p'
`summary` is one sentence saying what the plugin does, in the voice the site
uses. It is one sentence and not a paragraph: the paragraphs that make a plugin

gh repo list Flowfin --limit 60 --json name,description \
  --jq '[.[]|select(.name|startswith("jellyfin-plugin-"))]|.[]|"\(.description|length)\t\(.name)"' \
  | sort -rn | head -2
173	jellyfin-plugin-sso
85	jellyfin-plugin-whisper-subtitles

Both run 2026-08-12. So the rewrite is not twelve edits of one size. Eleven are
a sentence each, and one has to decide what to drop before it is a sentence in
that voice at all.