2.12.1 — a website, and Restore All no longer ends early when one step throws

[Anton-Babaskin]

What this changes

A landing page at anton-babaskin.github.io/SysTuneX,
in English and Russian, with the download button in the first screen. And the rollback path no
longer gives up halfway when one restorer throws.

Why

Restore All could end early and say nothing useful. Restorers run in order, so an exception in
one took every later one with it — and the RollbackReport, which exists specifically to say which
changes came back and which did not, was never returned at all. The user would be told the rollback
failed, with nothing saying which half went through. A machine left mid-rollback is the worst state
this application can put one in.

Nothing is known to throw today; that was checked rather than assumed. UnblockTelemetryHostsAsync
catches and returns an OperationResult, including the Defender refusal the release notes already
document, and RegistryValueComparer.Materialize uses TryParse throughout and returns null rather
than throwing on a journal entry it cannot read. But the restorers reach bcdedit, netsh, the
registry, the task scheduler and PowerShell, and "everything down there reports rather than
throws" is not a property the rollback can rely on. A throw is now what a refusal already was:
counted against that restorer, named in the user's language, and not the end of the rollback.
Cancellation still propagates — the user left the page, which is not a restorer failing.

The settings page can no longer enforce two of its own rules. Splitting it into a page and five
sections in 2.12.0 turned one loading flag into six independent checks. A handler that does not
consult it fires while the page is filling its controls in and writes the settings file several
times over, applying each value as though it had just been chosen. A section the page never loads
shows its defaults and then writes those over the real settings. Nothing is broken today — all
fifteen handlers do consult the flag, in three different spellings — and that variety is exactly why
a check is worth having.

How it was verified

• dotnet build SysTuneX.sln -c Release — no warnings
• dotnet test tests/SysTuneX.Core.Tests — 461 green, up from 456
• dotnet test tests/SysTuneX.App.Tests — Windows only; CI runs it
• The website was rendered and looked at, at 1440 and 390 wide, in both languages

Each behavioural claim was checked by breaking the code and confirming the right test failed:

Broken deliberately	Caught by
A restorer throws mid-rollback	A_restorer_that_throws_does_not_stop_the_ones_after_it — the later restorer still ran
Cancellation treated as a restorer failure	Cancellation_is_not_recorded_as_a_failure
One settings handler with its guard removed	named with its file
A section dropped from OnEnterAsync	named on its own

Two real defects in the website, found by rendering it rather than trusting it:

1. The whole middle of the page was invisible. Every section was opacity:0 waiting for a
   scroll observer, so anything that stopped the script — a blocked request, an old browser, a
   crawler that does not run JavaScript — left a hero, a footer and nothing between them. For a page
   whose entire job is being found in search, that is the worst possible failure. The reveal is an
   enhancement now: content is visible on its own and only hides once scripting is confirmed.
2. The page scrolled sideways on a phone — 605px of it in a 390px window, because the hero's
   gradient field is deliberately wider than the viewport. It clips now, with overflow-x:clip
   rather than hidden so the sticky header survives, and the field scales down under 700px.

Also checked: no console errors, no missing local references, and both JSON-LD blocks parse.

Risk and rollback

• Writes to the registry: no new writes; the catalogue is unchanged.
• Changes service configuration: no.
• Reversible from the change journal: yes, and more reliably than before — that is the point of
  the change.
• The website is static files under docs/. It ships nothing inside the executable and cannot
  affect a running install.

Release

• release.version bumped to v2.12.1, and CHANGELOG.md has a ## v2.12.1 section
• All four READMEs link the website
• Every new user-visible string exists in Strings.resx, Strings.ru.resx and
  Strings.uk.resx — the rollback failure message is translated in all three

Why the number moved. release.version was still v2.12.0, which shipped on 18 September.
Merging on that number would not have failed — the workflow sees the existing tag and quietly
replaces its assets with --clobber. That is the problem: a real behaviour change would have gone
out under release notes that do not mention it, silently changing the binary and its checksum
underneath anyone who had already downloaded and verified it. RELEASING.md names that trade
directly, so the number moves instead.

After merging, GitHub Pages needs turning on once: Settings → Pages → Deploy from a branch →
main / /docs. Until then the README links point at a 404.

---

Generated by Claude Code