Decide whether the first release carries one plugin or two

[iderex]

decisions/first-release.md decides the catalogue's first release carries one
plugin, and it argued that against a source set in which exactly one repository
had published anything. A second one has now published, so the input to that
argument has moved and the answer is a maintainer's rather than a rewrite of the
file.

The evidence

for r in discover invites metadata-sync requests server-pairing share-links \n             smart-collections sso stats watch-sync watchlist whisper-subtitles; do
  printf "%s %s

" "$r" "$(gh api "repos/Flowfin/jellyfin-plugin-$r/releases?per_page=100" --jq 'length')"
done
discover 0
invites 0
metadata-sync 0
requests 1
server-pairing 0
share-links 0
smart-collections 0
sso 54
stats 0
watch-sync 0
watchlist 0
whisper-subtitles 0

Run 2026-08-08. The release on requests is a finished build rather than a test
one, and it carries an archive and sidecars in the same shape the pairing rule
was written against:

gh api 'repos/Flowfin/jellyfin-plugin-requests/releases?per_page=100' \n      --jq '.[] | {tag: .tag_name, prerelease, draft, assets: [.assets[].name]}'
{"assets":["requests_0.1.0.0.md5","requests_0.1.0.0.sha256","requests_0.1.0.0.zip","requests_0.1.0.0.zip.meta.json"],"draft":false,"prerelease":false,"tag":"0.1.0.0-stable"}

Run 2026-08-08. Its tag matches the same pattern the channel decision declares for
the other repository, so nothing about the split has to change for it to be
classifiable.

What is at stake either way

One entry. The argument already in decisions/first-release.md holds: fewer
things to debug against a real server, and the catalogue grows with no change here
when the second one is added. The cost is that a plugin which is ready is left out
of a catalogue that exists, and somebody has to decide when it goes in.

Two entries. The catalogue ships what is actually publishable, and the per-plugin
parts of the generator get exercised against two sources rather than one, which is
where a field that only ever held one value shows itself. The cost is that the
first install test now depends on two repositories being right rather than one,
and the second one has a single release with no history behind it.

What does not change either way: the generator reads a declaration rather than a
list written into it, so this decides what the declaration says on the day of the
release and not what the code can do.

Done when

decisions/first-release.md states how many entries the first release carries and
why, against the counts above rather than against the ones it was written with.
Reading-decidable.

[iderex]

The counts this issue reasons from have moved again, and this time in a way that
changes what each of the two options is worth. The route that turns the declared
set into the file now exists, so the question can be asked of the run rather than
of the release lists.

What the generator makes of the declared set today

go run . publish

  requests             resolved                 1 finished, 0 test
  sso                  resolved                 4 finished, 60 test

2 of 12 declared plugin(s) resolved with something to publish.
  10 no releases

what each resolved plugin's releases came to:
  requests             1 version(s), 0 skipped, 0 stopping the run
  sso                  0 version(s), 3 skipped, 1 stopping the run
    skipped 4.2.0-stable: no-descriptor: no asset is named sso-authentication_4.2.0.0.zip.meta.json, among sso-authentication_4.2.0.0.md5, sso-authentication_4.2.0.0.sha256, sso-authentication_4.2.0.0.zip
    skipped 4.1.1-stable: no-descriptor: no asset is named sso-authentication_4.1.1.0.zip.meta.json, among sso-authentication_4.1.1.0.md5, sso-authentication_4.1.1.0.sha256, sso-authentication_4.1.1.0.zip
    skipped v4.1.0.0: no-descriptor: no asset is named sso-authentication_4.1.0.0.zip.meta.json, among sso-authentication_4.1.0.0.md5, sso-authentication_4.1.0.0.sha256, sso-authentication_4.1.0.0.zip
    stops   4.2.1-stable: no-descriptor: no asset is named sso-authentication_4.2.1.0.zip.meta.json, among sso-authentication_4.2.1.0.md5, sso-authentication_4.2.1.0.sha256, sso-authentication_4.2.1.0.zip

exit status 1

Run 2026-08-13 at 8b4a971, which is the first commit the whole route runs from.
Nothing was placed.

Why the run stops, in the releases themselves

gh api 'repos/Flowfin/jellyfin-plugin-sso/releases?per_page=100' \
  --jq '.[] | select(.tag_name|test("^v?[0-9]+[.][0-9]+[.][0-9]+([.][0-9]+)?(-stable)?$")) | {tag: .tag_name, published: .published_at, assets: [.assets[].name]}'
{"assets":["sso-authentication_4.2.1.0.md5","sso-authentication_4.2.1.0.sha256","sso-authentication_4.2.1.0.zip"],"published":"2026-07-18T23:56:24Z","tag":"4.2.1-stable"}
{"assets":["sso-authentication_4.2.0.0.md5","sso-authentication_4.2.0.0.sha256","sso-authentication_4.2.0.0.zip"],"published":"2026-07-18T23:13:45Z","tag":"4.2.0-stable"}
{"assets":["sso-authentication_4.1.1.0.md5","sso-authentication_4.1.1.0.sha256","sso-authentication_4.1.1.0.zip"],"published":"2026-07-18T19:06:10Z","tag":"4.1.1-stable"}
{"assets":["sso-authentication_4.1.0.0.md5","sso-authentication_4.1.0.0.sha256","sso-authentication_4.1.0.0.zip"],"published":"2026-07-18T13:39:34Z","tag":"v4.1.0.0"}

Run 2026-08-13. Every finished release of that repository ships an archive, an
md5 and a sha256, and none of them ships the .zip.meta.json descriptor beside
the archive. That file is where decisions/plugin-identity.md reads the guid,
the name, the description, the overview, the owner and the category, and where
the version entry's four fields are read as well, so a release without one
produces no entry. The newest of the four is the release a run would publish, and
decisions/failure-posture.md stops the run on a defect in that one.

The same repository ships the descriptor on the other side of the split:

gh api 'repos/Flowfin/jellyfin-plugin-sso/releases?per_page=1' \
  --jq '.[] | {tag: .tag_name, prerelease, assets: [.assets[].name]}'
{"assets":["build.yaml","community-sso-for-jellyfin_5.0.0.47.md5","community-sso-for-jellyfin_5.0.0.47.sha256","community-sso-for-jellyfin_5.0.0.47.zip","community-sso-for-jellyfin_5.0.0.47.zip.md5sum","community-sso-for-jellyfin_5.0.0.47.zip.meta.json","openvex.json","openvex.sha256","sbom.cyclonedx.json","sbom.cyclonedx.sha256"],"prerelease":true,"tag":"5.0.0-JF12-beta.47"}

Run 2026-08-13. So the descriptor exists in the channel that is not published and
is absent from the channel that is. Entry 5 of #1 settled on the finished list
and no second address, so nothing in the catalogue reaches the releases that
carry one.

The other repository is the opposite case:

gh api 'repos/Flowfin/jellyfin-plugin-requests/releases?per_page=100' \
  --jq '.[] | {tag: .tag_name, published: .published_at, assets: [.assets[].name]}'
{"assets":["requests_0.1.0.0.md5","requests_0.1.0.0.sha256","requests_0.1.0.0.zip","requests_0.1.0.0.zip.meta.json"],"published":"2026-08-08T09:39:39Z","tag":"0.1.0.0-stable"}

Run 2026-08-13. With the sso declaration switched off in a working copy, the run
places a catalogue carrying that one entry, with the identity and the four
version fields read out of the descriptor and the checksum read out of the
sidecar. I reverted the switch and the placed file is not in the tree.

What this does to the two options

A published release is immutable, so the four above stay as they are. What moves
this is a new finished release of that plugin carrying a descriptor, and until
one exists the catalogue cannot carry that entry at all.

The one-entry option was argued in decisions/first-release.md when exactly one
repository had published, so the entry it had in mind was that one. Today that
plugin is the one that cannot be published and the newer repository is the one
that can, which is the reverse of the set the argument was made against.

The two-entry option is not available today either, for the same reason: two
repositories resolve with something to publish and one of them produces an entry.

The command at the top is what to re-run, since both counts move.