An operator who installs a build meant for a different server generation gets a
plugin that does not load, and the site as planned says nothing that would stop
them. Every page in this plan carries what a plugin does and whether it ships.
None of them carries the one fact that decides whether it will run.
The plugin that ships today publishes two builds under one identity, one per
server generation:
gh api repos/Flowfin/jellyfin-plugin-sso/contents/build.yaml --jq '.content' \
| base64 -d | grep -E '^(version|targetAbi|framework):'
version: "4.3.0"
targetAbi: "10.11.0.0"
framework: "net9.0"
gh api repos/Flowfin/jellyfin-plugin-sso/contents/build-jf12.yaml --jq '.content' \
| base64 -d | grep -E '^(version|targetAbi|framework):'
version: "5.0.0"
targetAbi: "12.0.0.0"
framework: "net10.0"
What the pages say about a server version today:
for p in / /design-system.html; do
curl -s "https://flowfin.dev$p" | grep -oE 'Jellyfin [0-9]+\.[0-9]+'
done; echo "exit=$?"
exit=1
Both run 2026-08-08. Nothing, on either page.
The value is not typed here and the roster gains no field for it, on the same
reasoning as #22: which server a build targets is a fact about what was
published rather than an opinion anybody records. It is recorded by the same
refresh path into the same file, so a build with no network still renders it and
the page states the point in time the data was taken.
What a page shows, and where the honesty is. A plugin with a release prints the
generation that release targets. A plugin whose releases span more than one
generation prints one line per generation rather than one line per plugin, which
is the case the shipping plugin is already in and the case a single-value field
would render wrong. A plugin with no release prints that there is nothing to
install rather than a version read out of a source file, because a source file
says what somebody intends to publish and only a release says what somebody can
install.
The install page carries the same value from the same place. A reader deciding
what to paste into a server is the reader this fact exists for, and a second
source for it here would be the drift #5 refuses for the state table.
Done when
The recorded release data carries the targeted server generation for every
plugin that has a release; every produced plugin page with a release prints it,
and a fixture carrying releases on two generations produces two lines on that
page rather than one; a plugin with no release prints that there is nothing to
install and prints no version; the install page prints the same value read from
the same file; no server version appears in a template, in content/ or in the
roster, refused by the invariant gate with the offending file named; and the
pages stay inside every line of the budget in #6.
An operator who installs a build meant for a different server generation gets a
plugin that does not load, and the site as planned says nothing that would stop
them. Every page in this plan carries what a plugin does and whether it ships.
None of them carries the one fact that decides whether it will run.
The plugin that ships today publishes two builds under one identity, one per
server generation:
What the pages say about a server version today:
Both run 2026-08-08. Nothing, on either page.
The value is not typed here and the roster gains no field for it, on the same
reasoning as #22: which server a build targets is a fact about what was
published rather than an opinion anybody records. It is recorded by the same
refresh path into the same file, so a build with no network still renders it and
the page states the point in time the data was taken.
What a page shows, and where the honesty is. A plugin with a release prints the
generation that release targets. A plugin whose releases span more than one
generation prints one line per generation rather than one line per plugin, which
is the case the shipping plugin is already in and the case a single-value field
would render wrong. A plugin with no release prints that there is nothing to
install rather than a version read out of a source file, because a source file
says what somebody intends to publish and only a release says what somebody can
install.
The install page carries the same value from the same place. A reader deciding
what to paste into a server is the reader this fact exists for, and a second
source for it here would be the drift #5 refuses for the state table.
Done when
The recorded release data carries the targeted server generation for every
plugin that has a release; every produced plugin page with a release prints it,
and a fixture carrying releases on two generations produces two lines on that
page rather than one; a plugin with no release prints that there is nothing to
install and prints no version; the install page prints the same value read from
the same file; no server version appears in a template, in
content/or in theroster, refused by the invariant gate with the offending file named; and the
pages stay inside every line of the budget in #6.