Put the visual anchor on the landing page

[iderex]

decisions/0016-whether-the-pages-carry-pictures.md is landed and decides that
the landing page carries one current image as the visual anchor, with the plugin
pages staying textual. Nothing on this board holds the work that record
authorises, and two open issues wait on it by description rather than by number.

The record names what it left open and calls those build questions:

sed -n '/^It also does not decide which page/,$p' decisions/0016-whether-the-pages-carry-pictures.md
It also does not decide which page the landing image sits on beyond naming the
landing page, what it shows, or what element carries it. Those are build
questions, and the element in particular is one another issue is waiting on: the
row comparing an image's stated size against the file it names has nothing on
the markup side until a page states one, and the mark referenced from the head
of every page states none.

Run 2026-08-30 at 951bcb1.

No produced page carries an image element

The build writes one image and no page states a size for it. Every page
references the mark from its head with a link element, and a link element states
no width and no height:

go run . build > /dev/null && grep -rl -i '<img' dist | wc -l
0
grep -o 'rel="icon"[^>]*' dist/index.html
rel="icon" href="/icon.svg" type="image/svg&#43;xml" /

Run 2026-08-30 at 951bcb1. The entity in the type is the frame escaping an
attribute value, and a browser reads it back as image/svg+xml.

What is waiting on this, and why neither of the two can produce it

The last condition of #85 is that the dimensions written into the output are read
from the image file rather than from a template. The row that would decide it
prints what it is waiting for and names no issue that holds the work:

go run . invariants | grep image-dimensions-match-the-file
  image-dimensions-match-the-file: not decided, waiting on the first page that states a size for an image, in #85. [...] This row starts deciding on the day a page states a size for an image, which is an element that carries one rather than a second reference to the same mark

Run 2026-08-30 at 951bcb1, elided for length. #69 puts the reference in the head
of every page and says in its own words that a picture on a page is outside what
it authorises. So the issue that needs the second side of that comparison cannot
build it, the issue that produced the first side may not, and the row goes on
printing that it has nothing to decide over a tree that does write an image.

The budget allows exactly one and no more

The row that counts the landing page's requests counts the mark in the head
together with the image elements in the body, so the page asks for one today
against a record that allows two:

sed -n '2116,2117p' internal/invariant/invariant.go
	found := len(imgElement.FindAllIndex(body, -1)) + len(iconLink.FindAllIndex(body, -1))
	if found <= budget.LandingImages {
grep -n 'LandingImages = ' internal/budget/budget.go
42:	LandingImages = 2
go run . invariants | grep '  landing-page-asks'
  landing-page-asks-for-at-most-two-images: ok, 1 file(s) of every page the build produced

All run 2026-08-30 at 951bcb1. One image element in the body of that page is
inside the budget and a second one is not, so the count bounds this work rather
than being something to check after it.

What this issue answers before it can be built

What the picture shows. The record leaves it open and writes the constraint the
answer has to meet in its own timing argument: a screenshot is worth taking when
it shows something a reader can go and get, and a picture of software with no
release is work in progress presented as a product. Three of the twelve have a
finished release behind them:

jq -r '.repositories | to_entries[] | "\(.key)\t\(.value.finished)"' data/releases.json | sort -k2 -rn
Flowfin/jellyfin-plugin-sso	29
Flowfin/jellyfin-plugin-stats	1
Flowfin/jellyfin-plugin-requests	1
Flowfin/jellyfin-plugin-whisper-subtitles	0
[...]

Run 2026-08-30 at 951bcb1, elided for length. So the subject comes from those
three rather than from the twelve, and the reading that picks one belongs here.

The image itself comes from outside this tree. A photograph of a plugin is taken
against a running server, which is not something this repository builds or can
produce, so this issue lands the plumbing and the choice and carries the asset
rather than generating it. That is the one part of this work that does not
happen here, and it is named rather than discovered when the change is attempted.

The staleness the record argues about does not disappear at one image. What keeps
the single picture current is a person, and this issue says so rather than
implying that something checks it.

The means

Go and the templates the generator already renders every other page with, and the
asset in the tree beside the mark. The row that refuses an image with no usable
dimensions exists, the row that refuses a produced image with no alternative text
covers every produced page, and the byte budget is already counted over what the
build writes, so the artefact is testable by the suite that is here and needs no
language, runtime or dependency this tree does not carry. The format is decided
with the picture rather than inherited from the mark: the mark is an SVG because a
typographic mark stays text, and a photograph of software is not text, so a raster
format is what it takes and the byte budget is what bounds its size.

Done when

go run . build writes the landing image into the output; the produced landing
page carries it as an image element whose width and height are read from the image
file rather than typed beside it; the element carries alternative text saying what
the picture shows rather than that it is a picture; the landing page passes the
request count with the mark counted beside it and still fits the markup and
stylesheet budgets; the subject of the picture is written down here with the
reading that chose it; and what keeps it current is named rather than left to be
remembered.

[iderex]

The subject clause, taken, because it is the half of this work that needs no running server

One clause of the done-when asks that the subject of the picture is written down
here with the reading that chose it. That clause is answerable at the mainline
today, and I took it rather than leaving it for whoever supplies the asset:
otherwise the choice gets made by whoever holds the camera, with no argument
behind it and nowhere it was written.

Everything below is at:

git rev-parse HEAD
a0da59350c8217b4ce25b5057d959612847ab9d4

The criterion is the record's own, not a preference

sed -n '/^The timing is the third reason/,/^$/p' decisions/0016-whether-the-pages-carry-pictures.md
The timing is the third reason and it is the one that will change. A screenshot
is worth taking when it shows something a reader can go and get. Most of these
plugins publish nothing today, so a picture of one would be a picture of work in
progress presented as a product, which is the claim this site is most careful
not to make.

The three that clear it, and the one that clears it by a factor of twenty-nine

python -c "
import json
d=json.load(open('data/releases.json'))
print(d['taken'])
for k,v in sorted(d['repositories'].items(), key=lambda r:-r[1]['finished']):
    print('%-44s %2d' % (k, v['finished']))
" | head -4
2026-08-26
Flowfin/jellyfin-plugin-sso                  29
Flowfin/jellyfin-plugin-requests              1
Flowfin/jellyfin-plugin-stats                 1

The roster carries the same ordering, and it carries it in the data rather than
in a sort anybody has to justify:

python -c "import json;print([r['id'] for r in json.load(open('data/roster.json'))][:3])"
['sso', 'share-links', 'watchlist']

Both run 2026-08-30.

The reading

sso. Three plugins clear the record's bar and they do not clear it equally.
One finished release is a thing a reader can go and get; twenty-nine is a thing
somebody has been running for a while, and a landing page whose one picture
shows the plugin behind twenty-nine releases is making the weakest claim of the
three about how finished this project is.

The cost of that choice, stated rather than left to be met later. sso is also
the plugin whose interface has moved most - twenty-nine finished releases is
twenty-nine chances for the picture to stop being what the software looks like -
so the staleness the record argues about lands hardest on exactly this subject.
The record already answers who carries that, and it is a person rather than
anything in this tree, which is the other clause of this done-when.

What the reading does not settle is which screen of that plugin the picture
shows. That is not a property of the release counts and no reading of this tree
decides it; it is settled with the asset, by whoever takes it.

What is left is the asset, and nothing on this board subtracts this issue for it

The body already says the asset comes from outside this tree. What is not
written anywhere is that this issue carries no label saying so:

gh issue view 216 --repo Flowfin/site --json labels,assignees,milestone --jq '{labels:[.labels[].name],assignees:[.assignees[].login],milestone:.milestone.title}'
{"assignees":["iderex"],"labels":["enhancement"],"milestone":"The pages"}

ls assets ; echo "exit=$?"
ls: cannot access 'assets': No such file or directory
exit=2
go run . build | grep -i asset
no assets/ in the tree, so nothing was copied verbatim
grep -rl -i '<img' dist | wc -l
0

All run 2026-08-30. The plumbing this issue would land is further along than the
body reads: the build already copies assets/ verbatim and reports an absent
one, image-carries-its-own-dimensions and page-image-carries-alternative-text
already run over every produced page, and image-dimensions-match-the-file
already prints what it is waiting for. What none of that supplies is a
photograph taken against a running server.

So this issue is waiting on an artefact rather than on a change to this tree, and
none of the three labels this board has says that:

gh label list --repo Flowfin/site --json name,description --jq '.[] | select(.name | startswith("blocked-on-")) | "\(.name)\t\(.description)"'
blocked-on-a-decision	Waits on a decision that is not taken yet. No change to this tree moves it.
blocked-on-another-issue	Waits on work tracked by another open issue on this board.
blocked-on-a-repository-setting	Waits on a repository setting rather than a change to this tree.

Run 2026-08-30. Unlabelled, it is counted as available and is read as work by
every session that reaches this board, one after another, and each of them
re-derives the paragraph above. Which label it takes, or whether the vocabulary
gains a fourth for an artefact that has to be made off this board, is a call
rather than something a reading of the tree settles, so I have not applied one
that would be false.

What this does not move

Every other clause of the done-when. Nothing here writes an image element, and
the landing page carries none.

[iderex]

The paste that bounds this work no longer returns the lines it was taken for

The body reads the request count out of internal/invariant/invariant.go by line
number, at 951bcb1, to show that the row counts the mark in the head together
with the image elements in the body. Those two line numbers hold something else
now:

git rev-parse origin/main
acf49eeeefafecf8fdc77928b9c2e8475a1121d8
sed -n '2116,2117p' internal/invariant/invariant.go
// decideWebFont refuses a produced page declaring a face that fetches a file.
//

Run 2026-08-31. One commit moved them, and it moved them by twenty-eight lines
rather than changing them:

git log --oneline 951bcb1..origin/main -- internal/invariant/invariant.go
8619199 Judge the files the build reads values out of, which no row did [#219]
grep -n -A1 'found := len(imgElement' internal/invariant/invariant.go
2144:	found := len(imgElement.FindAllIndex(body, -1)) + len(iconLink.FindAllIndex(body, -1))
2145-	if found <= budget.LandingImages {

Both run 2026-08-31. The second spelling carries its own line numbers and returns
the same two lines whatever moves above them, which is why it is the one used
here.

The bound the paste was quoted for is unmoved

grep -n 'LandingImages = ' internal/budget/budget.go
42:	LandingImages = 2
go run . invariants | grep '  landing-page-asks'
  landing-page-asks-for-at-most-two-images: ok, 1 file(s) of every page the build produced

Both run 2026-08-31. So the budget is still two, the landing page still asks for
one, and one image element in the body is still inside it and a second one is not.

Every other reading on this issue reproduces

I re-ran the rest rather than assuming the drift was confined to one paste. The
two extracts from decisions/0016-whether-the-pages-carry-pictures.md are
anchored on the text of their opening lines and return what they returned; the
build still writes no image element and one link element in each head; the row
that waits on this work still prints what it waits for; the release counts still
put sso at twenty-nine ahead of two plugins at one; and the tree still holds no
assets/:

go run . build > /dev/null && grep -rl -i '<img' dist | wc -l
0
grep -o 'rel="icon"[^>]*' dist/index.html
rel="icon" href="/icon.svg" type="image/svg&#43;xml" /
go run . invariants | grep -o 'image-dimensions-match-the-file: not decided, waiting on the first page that states a size for an image, in #85'
image-dimensions-match-the-file: not decided, waiting on the first page that states a size for an image, in #85
jq -r '.repositories | to_entries[] | "\(.key)\t\(.value.finished)"' data/releases.json | sort -k2 -rn | head -3
Flowfin/jellyfin-plugin-sso	29
Flowfin/jellyfin-plugin-stats	1
Flowfin/jellyfin-plugin-requests	1
ls assets ; echo "exit=$?"
ls: cannot access 'assets': No such file or directory
exit=2
go run . build | grep -i asset
no assets/ in the tree, so nothing was copied verbatim

All run 2026-08-31.

What this does not move

Every clause of the done-when. Nothing here writes an image element, the landing
page carries none, and what this issue waits on is still the photograph, which is
taken against a running server and is not something this tree builds.