Keep the reader's colour scheme and motion preference, and refuse a page that drops them

[iderex]

Depends on #63 and on #66.

The pages served today answer two questions about the reader's own machine, and
nothing in this plan says the generated ones have to:

for p in / /design-system.html; do
  printf "%-40s " "https://flowfin.dev$p"
  curl -sS "https://flowfin.dev$p" \
    | grep -o -i -E 'prefers-color-scheme: *[a-z]+|prefers-reduced-motion: *[a-z-]+|color-scheme: *[a-z ]+' \
    | sort -u | tr '\n' ' '
  echo ""
done
https://flowfin.dev/                     color-scheme:light dark prefers-color-scheme:dark
https://flowfin.dev/design-system.html   prefers-color-scheme: light prefers-reduced-motion: reduce prefers-reduced-motion:no-preference prefers-reduced-motion:reduce

Run 2026-08-08. The page that demonstrates the design system also carries the
motion it demonstrates:

curl -sS https://flowfin.dev/design-system.html \
  | grep -o -i -E '(transition|animation)[a-z-]*:' | sort | uniq -c
      1 animation:
      4 transition:

Run 2026-08-08. Both behaviours exist in what is published now, and the
generator in #4 is the thing that would drop them. Every check in this plan
stays green if it does. The byte budget in #34 counts bytes and would get a
smaller number. The audit in #36 runs at whatever the harness opens with. Its
contrast leg covers the colour vision presets rather than the scheme. #71 loads
a narrow viewport and enlarged text and says nothing about either of these. The
only party who finds out is a reader on a machine set to the other scheme, or
one who asked their system to reduce motion.

Two rules, both decidable by a machine, and neither of them a preference this
issue invents. They are what is published today, kept.

Every produced page follows the reader's colour scheme, and the document says
which schemes it supports so that a browser picks the right default background
and the right form control rendering before any stylesheet has been read.

Every produced page follows a request to reduce motion. Anything that moves sits
inside a query that switches it off. This is not a rule about whether the site
animates. It is a rule that the answer belongs to the reader.

Both legs run in the headless browser #63 pins, over every produced page, under
that browser's emulation of each preference, with the honesty rule the rest of
the plan uses: a browser that cannot start reds the run and never passes it.

The static half is cheaper and catches the ordinary case. A produced page
carrying a motion-bearing declaration that no reduce query switches off reds the
invariant gate in #14, by the same walk over the output that #85 uses for image
dimensions.

Where a value behind either behaviour is a token it comes from the pinned copy
#66 keeps, and nothing here defines one. That is #65's rule rather than a new
one.

Done when

Every produced page declares the schemes it supports and renders under each,
shown by the headless run loading every page under both emulated schemes; every
produced page renders with motion switched off under an emulated request to
reduce it, shown by the same run; a produced page carrying a motion-bearing
declaration outside a reduce query reds the invariant gate and the failure names
the page and the declaration; a browser that is present and cannot start reds
the run; and no colour value behind either behaviour is defined in this tree.

[iderex]

The body says the generator is the thing that would drop these two behaviours. One of
the two is already dropped, and the other has nothing to drop yet, and the difference
decides which half of this issue can be worked before the browser arrives.

Nothing the build reads declares a colour scheme or a motion preference:

for f in templates/page.html.tmpl content/index.txt content/privacy.txt; do
  printf "%-28s " "$f"
  gh api "repos/Flowfin/site/contents/$f" --jq '.content' \
    | base64 -d | grep -c -iE 'color-scheme|prefers-color-scheme|prefers-reduced-motion'
done
templates/page.html.tmpl     0
content/index.txt            0
content/privacy.txt          0

and the head the pages are rendered into carries three elements:

gh api repos/Flowfin/site/contents/templates/page.html.tmpl --jq '.content' \
  | base64 -d | sed -n '3,7p'
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>{{ .Title }}</title>
  </head>

Both run 2026-08-12 against main. So the scheme declaration is gone from what this
repository produces, against a served page that carries one. That half costs one element
in the head, it is independent of any stylesheet, and it is what tells a browser which
background and which form control rendering to pick before it has read anything.

The motion half is in a different state, and reporting it as the same one would be
wrong. The pages carry no stylesheet and nothing that moves:

gh api repos/Flowfin/site/contents/templates/page.html.tmpl --jq '.content' \
  | base64 -d | grep -c -iE '<style|rel="stylesheet"|transition|animation'
0

Run 2026-08-12. There is no declaration for a reduce query to switch off, so the rule
about motion has nothing to bite on today and a green run over it would be measuring an
empty set. The static row this issue asks for is worth landing before the motion
arrives rather than after, for the reason #85 gives about the first image, but it has to
report that it examined nothing while the count is zero rather than reporting ok.

That leaves the browser half where it was. Loading every page under each emulated scheme
and under an emulated request to reduce motion still waits on #63.

[iderex]

Both static halves are on main now, so the reading above has moved: the scheme
declaration is back in what this repository produces, and the motion rule has a
row of its own rather than nothing to bite on.

go run . invariants | grep -E 'declares-the-schemes|motion-answers'
  page-declares-the-schemes-it-supports: ok, 4 file(s) of every page the build produced
  page-motion-answers-the-reader: 4 file(s) of every page the build produced carried no declarations that move something, so this rule decided nothing

The second line is the shape asked for while the count is zero. It reports what
it read rather than ok, so a set of pages carrying nothing that moves cannot be
read as a set carrying it correctly, and the row starts saying ok on the day a
declaration arrives.

Both rows go red when what they name is taken away, and each reds only itself:

go test ./internal/invariant -run 'Scheme|Motion' -count=1 -v \
  | grep -E '^(--- PASS|--- FAIL)'
--- PASS: TestRunRefusesATemplateThatDroppedTheSchemeOnEveryPageItProduced (0.25s)
--- PASS: TestTheSchemeRowReadsTheValueRatherThanTheAttribute (0.00s)
--- PASS: TestAHeadWithNoSchemeRedsExactlyOneRow (0.00s)
--- PASS: TestTheMotionRowTellsTheQueryFromTheCascade (0.00s)
--- PASS: TestTheMotionRowNamesTheLineAndTheDeclaration (0.00s)
--- PASS: TestMotionInTheCascadeRedsExactlyOneRow (0.00s)

The last condition holds and is decided rather than asserted. No colour value
behind either behaviour is written into what the build reads, and the row that
refuses one covers the same population:

go run . invariants | grep design-tokens-live
  design-tokens-live-in-exactly-one-file: ok, 5 file(s) of every tracked file the build reads to render a page

All commands run 2026-08-16 at 8af1685.

What is left is the three clauses that name a browser: every page loaded under
both emulated schemes, every page loaded under an emulated request to reduce
motion, and a browser that is present and will not start reddening the run.
There is no browser in this tree to load anything with, and #63 is where one is
pinned, so those close there rather than here. The static rows above are not
that condition and this comment does not tick it off: reading the bytes of a
produced page says what the page declares, and says nothing about what a browser
does with it.