Record the answers to entries 5 and 7 where the work reads them

decisions/0015-what-the-mark-is.md

@@ -0,0 +1,94 @@
+# 0015. What the mark is
+
+A browser asks every site for an icon on the first visit to any page, and where
+no page offers one it guesses at a fixed address. That request is answered or it
+is served an error page, so a site that publishes no image still owes an answer
+about one. What the icon shows is not a build question and could not be settled
+by the change that produces the file: the build can put any bytes at that
+address, and which bytes those are is a statement about whether the project has
+a face. Entry 7 of #7 is where the question was held, and it was answered on
+2026-08-24. This record is that answer written where the work that reads it can
+find it, rather than on a tracker.
+
+## What was measured
+
+The project published no image anywhere at the time the question was taken. The
+served pages referenced none, and neither the tree behind the domain nor the
+organisation profile held one:
+
+    curl -sS https://flowfin.dev/ | grep -c -i '<img'
+    0
+    gh api 'repos/Flowfin/hub/git/trees/HEAD?recursive=1' --jq '[.tree[].path|select(test("(png|svg|ico|jpg|webp)$"))]'
+    []
+
+Run 2026-08-08, and carried here from the entry that took the question rather
+than re-run, because what it establishes is the state the decision was taken
+against.
+
+## The decision
+
+A typographic icon, and no drawn mark.
+
+The icon is a letter set in the type the design system already declares, built
+out of the pinned token copy rather than authored as an asset. The project's
+visual identity is its typography and its accent, and that is stated as a
+position rather than left as an absence.
+
+A drawn mark can arrive additively later if a good one does. Nothing downstream
+has to carry a symbol in the meantime, which is what makes the answer safe to
+build against now: no page, no manifest and no client is written to expect a
+glyph that does not exist.
+
+What that means for the file is in the build rather than here. The mark is
+produced from the token copy on every run, so it is not an asset anybody keeps
+current, and the values behind it move when the design system moves.
+
+## Why
+
+A mark is the first asset the project would own that nothing in this repository
+can derive or check. Everything else the site publishes is either prose somebody
+reviews or a value read out of a file, and both have a route by which a wrong
+one is found. A drawn mark has neither, and it becomes a thing to keep current
+in more than one place the moment it is used anywhere but the icon.
+
+A letter costs nothing to design and nothing to keep, and it is derivable, which
+means the ordinary rules of this repository reach it: the values it is drawn
+from are refused if they go missing, and the file it produces is compared byte
+for byte between two builds like everything else the build writes.
+
+The position is also honest about where the project is. A project with no
+releases behind most of its plugins does not need a visual identity before it
+needs the plugins, and an icon that says so by being plain is a smaller claim
+than one that says otherwise by being drawn.
+
+## What the alternatives cost
+
+A mark, drawn once, used as the icon and wherever else the project appears.
+Cost: somebody draws it, it becomes a thing to keep current in more than one
+place, and it is the first asset the project owns that nothing here can derive
+or check. It is the answer that buys the most and is the hardest to withdraw,
+because a mark that has been published is one readers have already learned.
+
+No icon at all. Cost: every visit asks for one and is served an error page,
+which is the failure the build producing one exists to remove. This answer costs
+a request per reader rather than costing nothing, so it is not the cheap option
+it reads as.
+
+## When this is worth revisiting
+
+When a drawn mark exists and is good. The answer is written to be added to
+rather than replaced: the reference is one line in the frame and the file is one
+address, so a mark that arrives later changes what is behind that address and
+changes nothing else. A record superseding this one says which mark and where it
+came from.
+
+It is also worth revisiting if the project ever needs the icon somewhere the
+letter cannot go, such as a surface that renders no text of its own. Nothing
+today is in that position.
+
+## What this record does not decide
+
+Whether the pages carry pictures of the software. That is entry 5 of #7, it was
+answered on the same day, and it is a different question: this one is about
+whether the project has a face, and that one is about photographs of what the
+plugins do. 0016 carries it.

decisions/0016-whether-the-pages-carry-pictures.md

@@ -0,0 +1,79 @@
+# 0016. Whether the pages carry pictures
+
+A picture of a plugin answers what it looks like faster than any paragraph, and
+this site exists to tell a reader what twelve plugins are and which of them they
+can install. It is also the only kind of content in the plan large enough to
+threaten the byte budget, and the only kind that goes wrong by sitting still: a
+screenshot of software that has since changed is wrong in a way that looks
+exactly as finished as it did on the day it was taken. Entry 5 of #7 is where
+the question was held, and it was answered on 2026-08-24. This record is that
+answer written where the work that reads it can find it, rather than on a
+tracker.
+
+## The decision
+
+One current image on the landing page, as the visual anchor. The plugin pages
+stay textual.
+
+Per-plugin screenshots can come additively once there are releases behind the
+plugins and a picture would show something true. They are not refused; they are
+not taken yet, and the reason is that most of what would be photographed does
+not exist.
+
+## Why
+
+The staleness surface is what decides it, and it does not scale with how useful
+the pictures are. One image is one thing to keep current. Twelve are twelve, and
+they go stale silently: nothing in this repository can look at a screenshot and
+say whether the software still looks like that, so the check is a person
+remembering, and a person remembering twelve of anything is a register that
+drifts.
+
+The byte budget points the same way. The record that fixes it counts the landing
+page's requests, and it counts them because the first page has to be complete
+after the fewest exchanges. One image on that page is inside what the budget
+allows. A picture per plugin page would put the argument about the budget on
+twelve pages at once, for pictures of software that mostly has no release.
+
+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.
+
+## What the alternatives cost
+
+Screenshots on every plugin page. Cost: twelve images to keep current, each
+needing alternative text that says what the picture shows rather than that it is
+a picture, against a budget that counts every byte. They go stale silently and
+nothing here can tell. It is the answer that helps a reader most on the day it
+lands and costs most on every day after.
+
+No pictures at all. Cost: the pages are text and a reader decides from a
+description, which is what the site does today. It is honest and it is
+defensible, and what it gives up is the one thing a landing page is for, which
+is telling somebody what this is before they read anything.
+
+## When this is worth revisiting
+
+When a plugin has a release and a picture of it would show something a reader
+can install. The answer is written to be added to, so that arrives as a second
+record naming which pages gained pictures and what keeps them current, rather
+than as a reversal of this one.
+
+It is also worth revisiting if the landing image turns out not to fit the
+budget once it exists. The number that would force that is in the speed budget
+record rather than here.
+
+## What this record does not decide
+
+What the project's mark is. That is entry 7 of #7, it was answered on the same
+day, and it is a different question: this one is about photographs of the
+software, and that one is about whether the project has a face. 0015 carries it.
+
+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.

internal/icon/icon.go

@@ -9,11 +9,11 @@
 // budget counts requests. Referencing a file and producing it costs one request
 // either way, and the reference is what stops the guess.
 //
-// What the mark is was decided as a typographic icon and no drawn mark, so what
-// is here is a letter set in the reader's own font rather than artwork. That
-// decision is why this package can exist at all: a drawn mark is a file
-// somebody authors and this repository commits, and a letter is a function of
-// values the token file already carries.
+// What the mark is was decided as a typographic icon and no drawn mark, in
+// decisions/0015-what-the-mark-is.md, so what is here is a letter set in the
+// reader's own font rather than artwork. That decision is why this package can
+// exist at all: a drawn mark is a file somebody authors and this repository
+// commits, and a letter is a function of values the token file already carries.
 //
 // So the file is produced rather than committed, which is the rule the
 // exclusion file and the sitemap are already written under: a committed file