Tell the user a newer build exists, after asking whether to look

[peopleworks]

The desktop app has no auto-update and never will — the build is unsigned, and a program that
downloads and runs code on its own is precisely the behaviour this project tells teachers to be
suspicious of.

Without one, though, somebody who downloaded 0.2.0 in July is still running it. And 0.2.0 gives a
verdict on a pasted paragraph, which since #59 we know is a verdict about a length nobody measured.
Leaving them there is its own harm.

So the app can look, and report a number and a link. The person decides.

It asks first

This is the first network call the app would make without being asked, and a tool whose case rests on
"nothing leaves your machine" does not get to make an exception quietly — not even one that sends no
text, no account and no identifier.

A quiet strip on first run:

Check for new versions?
This app does not update itself. A check asks GitHub which build is newest — no text, no account and
no identifier are sent, and nothing is ever downloaded for you. You can change this later on the
Windows app page.
[Yes, check] [No]

Until it is answered, nothing is checked. The answer is remembered and can be changed on
/download, which is already the page about versions in the desktop host.

When there is something to say:

Version 0.5.0 is published
You are running 0.4.0. Nothing here updates itself — read what changed and decide.
[What changed] [Not now]

Told once per version, not once per launch.

What actually leaves the machine

One GET to the public releases endpoint. GitHub sees an address and a user agent — the same as if the
person opened the releases page in a browser.

At most once a day. Sixty unauthenticated requests an hour are shared by every machine behind a
school's NAT, and a class exhausting the limit between first and second period would be our doing.

Failure is silence. Offline, a proxy returning an HTML login page, a 403 rate limit, a malformed
body — all return the same nothing as "you are up to date". An error banner about a version check, on
a page about somebody's essay, is noise the reader cannot act on.

It never downloads or runs anything. The link goes to the release notes; a test asserts the URL
contains neither .zip nor /download/.

The half that can be quietly wrong

Version picking is pure, lives next to the tag convention it depends on (DesktopRelease), and is
tested without a network — because two plausible implementations are wrong in ways nobody would
report:

• Ordering by date picks a NuGet release with no app attached. The two tag lines interleave; the
  live API right now returns desktop-v0.4.0, v0.4.0, desktop-v0.3.0, v0.3.0, ….
• Ordering as text puts 0.10.0 before 0.4.0 and tells everyone they are up to date for the
  rest of the project's life. The message simply never appears, so nobody files a bug.

Prereleases and unparseable tags are ignored rather than guessed at.

Shape

IUpdateCheck follows IFolderBatch: a capability in the shared UI with a no-op browser
implementation (NoUpdateCheck — a tab is always whatever was last deployed, so it renders nothing at
all) and a real one in the desktop host. UpdatePreference owns consent, the daily schedule and the
dismissed version, so there is one answer to "may we check?" rather than one per surface.

Documented, not buried

The README's privacy paragraph now carries it, and says explicitly that this is not a fifth
exception to the four: those four can send your text; this one cannot send anything.

Verified

• 417 tests, 17 new.
• Both strip states rendered and read in a browser, using a stub registered locally and reverted
  before committing — no test scaffolding ships.
• The parsing checked against the live GitHub response, which picks 0.4.0 correctly.

🤖 Generated with Claude Code

https://claude.ai/code/session_015PEbbiYSNPw7jE3LrPNhyF