[erikdarlingdata]

Fixes #2413.

Five seconds after every launch, MainWindow.CheckForUpdatesOnStartupAsync calls github.com looking for a new version. It is gated on App.CheckForUpdatesOnStartup, which defaults to true and was drawn in no window, so the only supported way to refuse an unsolicited outbound call from a DBA workstation was to hand-edit check_for_updates_on_startup into settings.json. This adds the checkbox, and that is the whole change.

The issue said the key "appears in no sample file", and that turns out to be stronger than it reads: Lite/config/settings.json is the only thing resembling a sample, and it is CopyToOutputDirectory=Never and not in ConfigSeeder's seed list, so it ships nowhere and seeds nothing. It also still carries "theme": "light" where the loader reads color_theme. I left it alone rather than adding a key to a file nothing reads, but it is worth someone deciding whether it should be deleted or made real.

The default is unchanged. Leaving it on with a visible switch beside it is defensible and is what the issue scoped. Whether it should stay on is a product question about how users learn a release exists, and I did not want to answer it as a side effect of drawing a checkbox — say the word and I will file it separately.

Where it lives, and why not in SaveAlertSettings

The checkbox sits directly under "Minimize to system tray", which puts it above AlertsEnabledCheckBox — the master switch where Lite's alert block actually begins. Note that in Lite there is no "General" section: "Minimize to tray" is the first child of the Notifications border, sitting above that gate precisely because it is not an alert setting. The update announcement is itself a tray balloon (AnnounceUpdate → _trayService.ShowNotification), so the two tray-behavior switches reading together at the top of that panel is the placement that made sense.

Persistence deliberately does not go through SaveAlertSettings, even though MinimizeToTray next to it does. Being in the alert block would mean two wrong things: the control would gray out in UpdateAlertControlStates with the "Enable notifications" master switch, claiming a dependency the update check does not have, and RestoreAlertDefaultsButton_Click would stomp it. So it takes the shape the Dashboard Defaults knobs already use — LoadCheckForUpdates seeded from the static in the constructor, SaveCheckForUpdates called from the Save button, and one App.WriteSetting merge into settings.json.

The key name is unchanged, so anyone who already hand-edited it keeps their setting, and WriteSetting parses the existing document and mutates it rather than rewriting, so nothing else in the file moves.

The drift guard

AlertSettingsControlWiringTests.LiteSaveAlertSettings_PersistsEveryStaticItAssigns asserts every App.X = inside SaveAlertSettings has a matching root[...] = App.X in the same body. Putting the assignment in its own method leaves it outside that fact's scope, which is the correct answer rather than a dodge — the guard's subject is the alert block. The sibling EveryLoadedThresholdBox_IsAlsoGatedAndReset matches \bAlert\w*Box\b and explicitly drops anything ending in CheckBox, so it never reaches this control either.

Lite.Tests targets net10.0-windows and cannot run on macOS, so I reimplemented both facts in Python against the patched source — the same brace-matching method-body extraction and the same regexes — plus assertions on the new wiring itself. Both existing facts pass unchanged for Lite and for Darling (22 and 28 loaded threshold boxes, none ungated, none unreset; 56 assigned statics, all persisted), CheckForUpdatesOnStartup is confirmed absent from SaveAlertSettings's body, the control is confirmed absent from both the gate and the reset methods, and the XAML control is confirmed to sit between MinimizeToTrayCheckBox and AlertsEnabledCheckBox. CI is still the arbiter for the real run.

I did not add a new test. The risk this change carries — loaded but never saved — is shared by all five existing single-value Save* methods and none of them has a guard, so a pin for mine alone would be arbitrary; a general "every Load* in the constructor has a Save* in the Save button" check would need an exception list for LoadServerScheduleSummary and a special case for SaveMcpSettingsAsync, which is the hand-maintained-list smell. Happy to take it as a follow-up if you want it.

Darling

No equivalent, confirmed. The Darling Viewer's only Velopack use is in AboutWindow, on demand when the user opens it; there is no startup check and no setting to match wording with. Lite's AboutWindow does the same on-demand check, and I left it unconditional on purpose — opening About is asking, and this setting governs the call the user did not ask for. The tooltip says so, so a user turning the switch off is told where the deliberate check still lives; see the comment below for why it names the sidebar button rather than the "Help > About" the rest of the product promises.

Verification

Built Lite/PerformanceMonitorLite.csproj and Lite.Tests/Lite.Tests.csproj on macOS with EnableWindowsTargeting, both clean. The first attempt failed on MC3000 because the XAML comment contained --, which XML forbids; reworded. global.json was restored and is not in the diff.

[erikdarlingdata]

Follow-up commit f351c3e: my tooltip originally said the About check still runs from "Help > About". Lite has no Help menu — MainWindow.xaml has no menu bar at all, and About is a sidebar button directly under Settings (line 327). Reworded to "the sidebar's About button" so the new string is correct.

The three pre-existing strings that make the same claim (MainWindow.xaml.cs 353, 370, and the tray balloon at 391) are left alone here and filed as #2416 rather than folded in, so this stays a Settings-window diff. That one is worth a look on its own: the balloon at 391 exists precisely to stop people re-running Setup.exe, and sending them to look for a menu that isn't there is how they end up doing it anyway.

[claude]

Reviewed. Small, well-scoped change — verified against the code:

• App.CheckForUpdatesOnStartup is read live inside CheckForUpdatesOnStartupAsync after the 5s Task.Delay, so a setting change made in Settings before the delay elapses is honored correctly (no stale-read risk).
• The new checkbox is correctly excluded from UpdateAlertControlStates (no gating on "Enable notifications") and from RestoreAlertDefaultsButton_Click (Restore Defaults doesn't touch it) — matches the PR description's claim.
• LoadCheckForUpdates/SaveCheckForUpdates follow the exact same shape as the neighboring LoadTimeDisplayMode/SaveTimeDisplayMode single-value pattern, including reuse of the shared WriteSetting helper (read/merge/write, swallow+log on error) — consistent with existing style in this file.
• Darling parity: confirmed by grep — Darling's only Velopack/update-check usage is in AboutWindow, on-demand, with no startup check and no corresponding setting. The PR's "no equivalent" claim holds; nothing to add there.
• Tooltip wording ("the sidebar's About button") matches the actual UI — AboutButton_Click is a sidebar button, not a Help menu item, since Lite has no Help menu.

No correctness, parity, or security issues found. This isn't T-SQL so the collector-query style rules (OPTION(RECOMPILE), etc.) don't apply here.