[Views2k]

What changed

The release commits for Wisp 2.7 (version 2.7.0, shown as 2.7) on top of main 1560731. The owner chose to publish this as 2.7, a reliability update, instead of 2.6.14. There are no code changes here; the fixes were merged separately:

PR	Merge	Change
#139	621358e	Automatic update retries stop for the session when the update helper rejects the installation; the dashboard points to the full installer, and Tools receives the helper's failure code.
#140	01b6f2b	Game audio is no longer refused when the process-loopback device misreports its buffer size (the audio_endpoint_buffer_limit incident on Windows build 22631).
#143	7744faf	Overlay windows survive WM_DWMCOMPOSITIONCHANGED failures (0xD0000701), retry composition and report one renderer-host incident instead of closing Wisp.
#144	4ef379d	The recorder drops frames to stay on the wall clock instead of failing with scheduler_late and discarding the rolling buffer; spool writes moved off the media thread.
#145	793bdcf	Repairs the two nightly test failures on main (HudProfileCompletenessTests since 2.6.12, the drift worker test's dependence on test order since 2.6.13). Test-only.
#147	338ad07	The lossless encoder requests its keyframe again after an NVENC busy retry, so the 2 s GOP bound no longer stops recording.
#149	e354871	Lossless clips that dropped frames (variable frame rate since #144) play and export again; the playback copy no longer rejects a source that is not exactly 60 fps. Found by the owner's test of 2.6.14 RC 1; it never shipped, so it has no CHANGELOG line.
#152	d619f29	Native access and unsupported-build status is reported once per game process per session, not on every resume.
#150	3cdc4ed	A slow Windows crash-event lookup is reported as read-failed (timeout) and gets a 10 s bound instead of being cancelled at 150 ms per read.
#151	a4d56d4	A run that Windows ended (power loss, hard reset, system crash: Kernel-Power 41 / EventLog 6008 after the last checkpoint) is reported as system-stopped instead of shutdown-incomplete.
#154	bf14b96	Update checks wait out GitHub rate limits, report them as rate-limited, and report a network outage once instead of at every check.
#155	1560731	The update check reads the latest release tag through the github.com release-page redirect, with the API as fallback.

This commit changes the same nine files as the 2.6.13 release (#137):

• Version 2.7.0 in all five version files: Wisp.App.csproj (Version, FileVersion, AssemblyVersion), Wisp.Updater.csproj, installer/Wisp.iss, app.manifest and LICENSES/library-sources-distribution.json (version and file name; the source archive is still the 2.6.8 one, so no new library-sources prerelease is needed).
• CHANGELOG: the Unreleased section becomes ## 2.7.0 - 2026-10-21, with entries rewritten for players, plus four new entries for Report a slow crash-event lookup as a timeout and give it time to finish #150–Read the latest release tag from the release page before the API #155 (the Tools PRs added no Unreleased lines).
• README: intro and release-notes link. This also fixes the section heading, which still said 2.6.12.
• ReleaseNotesCatalog.cs: new current 2.7 entry (label RELIABILITY UPDATE, with Clips, Reliability, Updates and Diagnostics groups); 2.6.13 is no longer marked current.
• docs/releases/Wisp-2.7.0-release-notes.md, headed # Wisp 2.7 like 2.5 and 2.6.
• History on this branch: 91456f6 (2.6.14 release commit), 5a28bd1 (merge of main with Play and export lossless clips that dropped frames #149), 9271321 (retarget to 2.7), c053e56 (merge of main with Report a slow crash-event lookup as a timeout and give it time to finish #150–Read the latest release tag from the release page before the API #155), c90b6b4 (release text for those). Squash-merging gives one commit.

Why

• A PC on 2.6.12 retries a rejected update every two minutes, more than 100 failures a day (Stop automatic update retries when the update helper rejects the installation and report its code #139).
• A 2.6.13 player cannot record clips because game audio is refused (Stop refusing game audio when the loopback device misreports its buffer size #140).
• Two PCs on 2.6.13 closed when Windows restarted desktop composition (Keep the HUD overlay running when desktop composition changes #143).
• Clips restarted every few seconds and kept no history when the encoder could not keep up, five times in 26 s on the owner's PC and on four other PCs since 2.6.8 (Keep recording clips when the pipeline cannot keep up: drop frames to stay on the clock, write the spool from its own thread #144, Request a lossless keyframe again when NVENC was busy #147).
• The owner asked for the nightly test defects to be repaired, not waived, before release (Fix the two nightly test failures on main #145).
• The owner asked for the open Wisp Tools investigations to be fixed in this release, "mainly a reliability update" (Report a slow crash-event lookup as a timeout and give it time to finish #150, Report a run that Windows ended by stopping without shutting down as its own reason #151, Report native access and compatibility status once per game process #152, Wait out GitHub rate limits and report update-check outages once #154, Read the latest release tag from the release page before the API #155). The Tools side, wisp-site#328, is deployed and accepts system-stopped and rate-limited.

Checked

Final release gate at c90b6b4 on this PC, with the PC idle, a clean clone at exactly that commit, pinned SDK 8.0.425, VS 2022 Build Tools and local Inno Setup 6.7.3:

• Test-RepositoryPolicy.ps1: passed, including the 2.7.0 release-content check.
• installer/Build-Installer.ps1: passed. This covers 157 Python tool tests (2 skipped), the locked restore with NuGet audit, full-solution format verify, the Release build, the critical behaviour tests, the UiReview build, publish, identity checks, the updater guard smoke test, Inno packaging and installer runtime validation. It produced Wisp-Setup-2.7.0.exe, ProductVersion 2.7.0.0, SHA-256 0D9817CF8C0B4AA55DED892F3D175D48ECD5491E355AECB234BB032B1859EB8C (a local candidate; CI rebuilds the published bundle from the merge commit).
• Full suite: a plain dotnet test Wisp.sln failed 1 of 6000 App tests: TachRendererDiagnosticsTests.EnabledUncontendedProducerHasNoPerEventAllocations measured 6888 bytes allocated on its producer thread, against 0. That is one of the four allocation-sensitive tests the nightly has run in isolation since 2.6.9 (Test-AppBehavior.ps1 -Full), and no tach code changed in this release. The repo's own full procedure, Test-AppBehavior.ps1 -Full, passed on the same build: Core 776, Telemetry 96, App 5996, Update 184, Updater 75, plus each of the four isolated tests alone, 6000 App tests in all. The gate script now uses that procedure.
• Native renderer contracts on the hardware GPU: contractFailures 0.
• Wisp.Recorder.exe --self-test on the linked binary (same SHA-256 as the published copy): 100 policy contracts, 45 diagnostic, 80 thumbnail, 13 borderless, 21 screen.
• Recorder native contracts: AudioCapture 118, AudioTimeline 195, Buffer 73, EncodedSpool 62, RecorderProtocol 308.

Headless recorder fixture against the real NVENC session (release recorder sources, generated 2160p60 input, self-process audio). Every clip was checked with ffprobe/ffmpeg 9.0.1:

• 4K60 lossless, save at 35 s: the 28.9 s clip has 1735 frames with AAC stereo. The largest keyframe gap is 2.0 s, the largest frame gap 16.7 ms, a full decode shows 0 errors, and a seek to 10/50/90 % decodes. Audio and video start together and have the same duration.
• Pause, save and resume: three clips (3.9, 3.9 and 6.9 s), history verified, 0 decode errors, seeks decode, and audio and video lengths differ by at most 8.7 ms.
• The generated input never made the encoder drop frames. The variable-frame-rate path was exercised by the owner's 2.6.14 RC 1 gameplay clip (57.40 fps average), and Play and export lossless clips that dropped frames #149 was verified on that clip.

Owner's in-game tests: 2.6.14 RC 1 recorded without restarting but its saved lossless clip would not play; #149 fixed that. The owner then chose to publish without testing a further private installer ("i dont need the 2.7 installer just publish and tag when ready").

CI on this PR at c90b6b4: Build and test and CodeQL passed.

Not verified

• The final 2.7 build has not been tested in game. The owner's last in-game test was 2.6.14 RC 1, before Play and export lossless clips that dropped frames #149 and the Tools-side fixes.
• A dropped-frame 4K HDR lossless clip from the final build playing and exporting end to end (Play and export lossless clips that dropped frames #149 was verified on the owner's RC 1 clip with the real exporter).
• In-game confirmation of the clip audio fix on an affected device (Windows build 22631). After release, Tools should show no new audio_endpoint_buffer_limit incidents and a first clip from the affected player.
• The stuck 2.6.12 PC updating once 2.7 is out. Its rejection path is unit-tested, but the cause on that PC needs its diagnostics.
• A real desktop composition restart (Win+Ctrl+Shift+B) with the overlay up; the NVENC busy retry path (Request a lossless keyframe again when NVENC was busy #147); a real GitHub rate limit and the release-page redirect against the published 2.7 release (Wait out GitHub rate limits and report update-check outages once #154/Read the latest release tag from the release page before the API #155).
• Steam and Xbox: no platform-specific code changed. The same recorder, overlay, updater and diagnostics paths serve both, and no per-platform live check has been run.
• The installer lifecycle canary and library-source verification run in CI on the main push and on the tag.