Verify a clean install and an upgrade from the published manifest, and record it

[iderex]

Everything before this proves the artifact exists. Only an install proves it installs.

Done when

• On a stock server of each supported line, the plugin is installed the way a user would install it, from the published manifest, and the run is recorded.
• The record carries: the server version, the plugin version installed, the log lines showing it loaded, and a walk through one add and one removal ending in a client-visible playlist.
• The record shows the upgrade path too: install the previous release, upgrade to the new one, and confirm the stored lists survived.
• The run needs no display and no elevation on the machine performing it, matching the rule from M7.
• A failure of this check blocks the release rather than being noted afterwards.

Scope: docs/.

---

The headless rule these tests run under is in Jellyfin.Plugin.Watchlist.Tests/HEADLESS.md, with every refusal and the replacement that takes its place. It is not repeated here.

[iderex]

It waits on more than the manifest.

Read against origin/master at 6e3e136990112f1968b37c131168fd8f8004f7b0:

$ gh api repos/iderex/jellyfin-plugin-watchlist/releases --jq 'length'
0

There is nothing published to install from, which is #74, and nothing packaged for it to publish, which is #73.

The third condition cannot be met at all by a first release. It asks that the record show the upgrade path, installing the previous release and upgrading to the new one, and a first release has no previous one. That is not a reason to weaken the condition. It is a reason to fix now that the first run of this check covers a clean install only, records that the upgrade half was not exercised and why, and that the second release is where the upgrade half is first met. A record that quietly leaves it out reads as an upgrade that was checked.

The second condition also depends on question 5 on #1. A walk through one add and one removal ending in a client-visible playlist has to happen on a stock server of each supported line, and whether a 12.0 artifact of 1.0 exists at all, and against which package set it was built, is what that question decides.

What unblocks this: question 5, then #73 and #74, and the projection and the API the walk-through drives. The record's shape can be written before any of that, and the sentence about the missing upgrade half belongs in the shape rather than being remembered on the day.

[iderex]

Cannot be closed. There is no published manifest to install from and no release to install:

gh api repos/iderex/jellyfin-plugin-watchlist/releases --jq 'length'
0

and there is nothing on a client to walk through, because the projection is not built:

git grep -c 'IPlaylistManager' origin/master -- Jellyfin.Plugin.Watchlist/ ; echo "exit=$?"
exit=1

The fourth condition here is the one to hold on to while the rest is waiting, because it is the one an install check is most likely to break. The run must need no display and no elevation on the machine performing it. An install driven through a server dashboard in a browser is a display, so what this issue records has to be taken through the server's own API or through a container, and the record has to say which. Writing it as a click-through and then discovering that is a rewrite rather than an edit.

[iderex]

A correction to one of the two commands the comment above rests on, made by re-running both rather than reading them back. It says there is nothing on a client to walk through because the projection is not built, and supports that with a grep that finds nothing. At origin/master, 304cc7cbda01cb939c7de290f118e32e5d699394, that grep finds a file:

$ git grep -c 'IPlaylistManager' origin/master -- Jellyfin.Plugin.Watchlist/ ; echo "exit=$?"
origin/master:Jellyfin.Plugin.Watchlist/Projection/ServerPlaylistGateway.cs:2
exit=0

The other command still answers as it did, at this board's own path:

$ gh api repos/Flowfin/jellyfin-plugin-watchlist/releases --jq 'length'
0
$ git ls-remote --tags origin | wc -l
0

What the walk-through half waits on now

A playlist is created for a user and remembered by its identifier. Nothing yet puts an item inside one, and the second condition here asks for a walk through one add and one removal ending in a client-visible playlist - which is entries rather than the list itself:

$ git grep -n '\.AddAsync(\|\.RemoveAsync(' origin/master -- Jellyfin.Plugin.Watchlist/ ; echo "exit=$?"
exit=1

That pass is #19, and the removal made on the client coming back into the store is #20. So this half waits on those two rather than on the projection being absent.

The install half is where the comment above leaves it and is not repeated: there is no release and no manifest to install from, which is #134 and #74.

The fourth condition, that the run needs no display and no elevation, is unchanged and is the one worth keeping in view while the rest waits. blocked-on-issue stays.

I read the tree and the tracker, installed nothing, started no container and changed nothing:

$ git status --short
(no output)

[iderex]

The comment above says the walk-through half of the second condition waits on #19
and #20, and supports it with a grep that finds nothing. Both have moved.

$ gh issue view 19 --repo Flowfin/jellyfin-plugin-watchlist --json number,state,stateReason --jq '"#\(.number) \(.state) \(.stateReason)"'
#19 CLOSED COMPLETED
$ gh issue view 20 --repo Flowfin/jellyfin-plugin-watchlist --json number,state,stateReason --jq '"#\(.number) \(.state) \(.stateReason)"'
#20 CLOSED COMPLETED
$ git grep -c '\.AddAsync(\|\.RemoveAsync(' origin/master -- Jellyfin.Plugin.Watchlist/
origin/master:Jellyfin.Plugin.Watchlist/Projection/WatchlistReconciler.cs:6

A reader arriving at that block finds both issues closed and the grep answering,
and reads this issue as ready to start. It is not, and what it waits on is now one
thing rather than three.

The walk-through is a routine that runs, against a server that is not the one this issue is about

#52 landed a harness that drives exactly the walk this condition describes - one
add and one removal, ending in a playlist read with the queries a client issues -
and #62 decided where it runs. Read at origin/master,
eb13391d1d58449e35ee65684e07b9f2acf4d10b:

$ git grep -l 'drive-the-whole-loop-on-a-line.sh' origin/master -- .github/
origin/master:.github/scripts/drive-the-whole-loop-on-a-line.sh
origin/master:.github/workflows/whole-loop.yaml

Its run on 33494240316 is recorded as a row in docs/client-verification.md.

WHAT THAT RUN IS NOT IS THIS ISSUE'S SUBJECT, and the difference is the whole of
this issue rather than a detail. That harness unpacks an archive into a server's
plugin directory itself. The first condition here asks for the plugin to be
installed the way a user would install it, from the published manifest, which
is a different act with different failures - a manifest entry naming the wrong
checksum, an archive the server refuses to unpack, a version the catalogue will
not offer. None of those is reachable by copying a directory in.

So what is left is the install, and there is nothing to install from

$ gh api repos/Flowfin/jellyfin-plugin-watchlist/releases --jq 'length'
0
$ git ls-remote --tags origin | wc -l
0

No release, no tag and no manifest, which is #74 and #134. The third condition
needs two releases rather than one, because it walks an upgrade. The fourth
condition - no display and no elevation on the machine performing the run - is
unchanged and is now met in advance by the route this would take: the harness that
does the walk needs neither, and says so in its own header.

blocked-on-issue stays, and what it names is #134 and #74 rather than #19 and
#20.

Bounds

I installed nothing, started no container and looked at no client. Every reading
above is a command against this tree or the tracker.

[iderex]

The comment above supports "there is nothing to install from" with two counts,
and both have moved. What this issue waits on is one thing now, and it is not
the two issues that comment names.

gh api repos/Flowfin/jellyfin-plugin-watchlist/releases --jq 'length'
2
git ls-remote --tags origin | wc -l
4

Four refs is the two tags and their dereferenced peels:

git ls-remote --tags origin | sed 's/^.*refs/refs/'
refs/tags/0.1.0.0-stable
refs/tags/0.1.0.0-stable^{}
refs/tags/0.1.1.0-stable
refs/tags/0.1.1.0-stable^{}

So there are two published releases, which is what the third condition needs to
walk an upgrade at all, and #134 is closed on them.

What is left is the manifest, and it is not this repository's to move

The first condition asks for the plugin installed the way a user would install
it, from the published manifest. The address serves a catalogue that does not
list this plugin:

curl -sS https://flowfin.dev/manifest.json | jq -r '[.[].name] | join(", ")'
Requests, Playback Statistics

so there is no entry for a server to resolve, and the install this condition is
about cannot be attempted. The rebuild that would add one is on the hub board,
its result is sitting in an open pull request there, and reading it turned up
something worth knowing before this run is attempted: it carries 0.1.0.0 alone,
which is the release that answers NotSupported on the floor it declares. That
reading and its commands are on #74 rather than repeated here.

What that does to this issue is narrow it rather than block it further. When the
catalogue carries both versions, the first and third conditions become one run:
install 0.1.0.0 from the catalogue, upgrade to 0.1.1.0, confirm the stored lists
survived. The upgrade half in particular is worth taking on exactly that pair,
because the older of the two does not load on the floor, so a reader on a
10.11 server below 10.11.11 meets the upgrade as their first working install.

The fourth condition stays met in advance, for the reason above: the harness
needs no display and no elevated rights.

Bounds

I installed nothing, started no container for this issue and touched nothing on
the hub. Every reading above is a command against this repository's remote, the
tracker, or the published address.