feat: complete v1.2.0 Visual Progress phase 3

[HelloThisWorld]

Summary

Completes Phase 3 of the winTerm 1.2.0 Visual Progress milestone:

• Promotes Visual Progress to a stable, searchable feature with safe defaults.
• Adds adaptive performance governance, accessibility semantics and announcements, lifecycle hardening, and decorative-failure isolation.
• Preserves bounded, local, fail-open CLI recognition and strict output-replacement safety.
• Updates authoritative application, package, module, resource, documentation, and release-note versions to 1.2.0.
• Prepares—but does not publish—the v1.2.0 release.

Related issues

N/A — v1.2.0 release-preparation milestone work.

Detailed changes

Stable settings and defaults

{
  "visualProgress.enabled": true,
  "visualProgress.recognizeCliProgress": true,
  "visualProgress.performanceMode": "automatic",
  "visualProgress.replaceRecognizedOutput": false
}

The settings are exposed under Settings → Appearance → Visual progress, participate in search and localization, apply to open panes, and preserve dependent saved values when the master or recognition setting is disabled. WINTERM_DISABLE_VISUAL_PROGRESS=1 remains the authoritative emergency override.

Progress ownership and replacement safety

Progress ownership remains within the normalized per-pane architecture:

1. Explicit OSC 9;4 taskbar progress.
2. High-confidence built-in CLI provider.
3. OSC 133 shell lifecycle state.
4. Hidden.

Lower-priority sources cannot overwrite a valid higher-priority owner. Split, detach, collapse, reload, focus, visibility, and provider-transfer paths preserve or safely rehydrate current state.

Recognized-output replacement remains off by default. When explicitly enabled, only high-confidence, self-contained transient frames from pip, Git, curl, or wget are eligible. Newline logs, prompts, warnings, errors, summaries, alternate-screen output, malformed or fragmented input, contention, stale generations, overflow, renderer unavailability, and uncertain records all fail open and preserve the original bytes. Docker, BuildKit, package managers, build tools, and generic recognition remain overlay-only.

Adaptive performance and lifecycle

• One window-scoped low-priority sampler runs about once per second only while eligible visible progress is active; there is no permanent per-pane timer or CPU frame loop.
• Automatic permits Full for one active indicator, caps at NoSparks for two or three, and caps at StaticGradient for four or more.
• Full, Balanced, and Minimal respectively permit Full, cap at NoSparks, and cap at StaticGradient.
• Reduced Motion, software rendering, remote sessions, and constrained energy state cap at StaticGradient; limited runtime effects cap at NoSparks; High Contrast uses Solid.
• Three consecutive samples at or above 100 ms degrade one tier.
• Fifteen consecutive samples at or below 40 ms may recover one tier after a 10-second cooldown.
• Neutral samples reset the relevant streak, idle resets sampling history, and ordinary latency adaptation clamps at Solid. A hard renderer failure may disable only the affected decorative overlay.
• Spark resources remain bounded to 8 per active pane and 24 globally.

Renderer faults revoke replacement immediately, release resources through a reentrancy-safe deferred lifecycle, and leave PTY, input, output, selection, copy/paste, and pane management unaffected.

Accessibility and privacy

The overlay exposes localized UI Automation ProgressBar semantics using Command progress. Determinate providers expose only real 0–100 values; indeterminate progress remains nonnumeric. Announcements are limited to the active visible pane, cover start, 25/50/75/100-percent milestones, waiting, and one terminal result, and use a four-second nonterminal throttle with duplicate/background suppression.

Recognition remains local, incremental, bounded, and in memory over newly arriving output. It does not scan scrollback, upload or persist terminal content, add Visual Progress telemetry, or retain command text, provider/package names, paths, URLs, usernames, hostnames, environment variables, credentials, or clipboard data.

Versioning and compatibility

Application/module metadata is now 1.2.0, Windows/package file metadata is 1.2.0.0, the channel remains stable, and the expected future tag is v1.2.0.

Workspace schema 2, docking model 1, shell protocol 1, theme schema 1, update-manifest schema 1, package identity, executable alias, application-data isolation, and Microsoft Terminal coexistence remain unchanged. Existing settings and workspaces require no migration.

Validation performed

Environment: Windows 11 x64, local repository checkout.

Validation	Command	Result
Release build and compiled tests	.\scripts\winterm\build.ps1 -Configuration Release -Platform x64 -IncludeTests	PASS; final terminal run 706.6 s
Release relevant tests	.\scripts\winterm\test.ps1 -Suite Relevant -Configuration Release -Platform x64	PASS: SettingsModel 230/230, TerminalApp 51/51, Control 30/30
Debug build and compiled tests	.\scripts\winterm\build.ps1 -Configuration Debug -Platform x64 -IncludeTests	PASS; 713.9 s
Debug relevant tests	.\scripts\winterm\test.ps1 -Suite Relevant -Configuration Debug -Platform x64	PASS: SettingsModel 230/230, TerminalApp 51/51, Control 30/30
Visual Progress source policy	.\scripts\winterm\test-visual-progress.ps1 -SourceOnly	PASS
Diff whitespace	git diff --check	PASS
Structured-file checks	PowerShell parser, ConvertFrom-Json, and XML parsing over changed files	PASS
Final unpackaged stage	.\scripts\winterm\build-unpackaged.ps1 -Configuration Release -Platform x64 -OutputDirectory .\artifacts\phase3-validation\stage-x64 -Force	PASS; 171 files
Final Portable ZIP	.\scripts\winterm\build-portable.ps1 -Version 1.2.0 -Platform x64 -StageDirectory .\artifacts\phase3-validation\stage-x64 -OutputDirectory .\artifacts\phase3-validation\release -SkipBuild -Force	PASS; 173-file layout
Portable isolation and launch	.\scripts\winterm\test-portable.ps1 -PortablePath .\artifacts\phase3-validation\release\winTerm-1.2.0-portable-x64.zip -Platform x64 -Version 1.2.0 -RunLaunch	PASS: extraction, launch, adjacent data mode, and installed-state isolation
Portable artifact	Get-FileHash with SHA256	16,372,782 bytes; 5929CC8302FE65054979B69D4776E278274D4160E0A1750DCC05B0D718012B15

An initial 30-minute outer command timeout interrupted the first Release orchestration while SettingsModel was still compiling, without a compiler or test diagnostic. Its verified orphan processes were stopped, and the same unchanged build then completed successfully in the terminal as recorded above.

Bounded Portable soak

The workload ran inside a fresh extraction of the final Portable ZIP through a completion-sentinel and process-metrics harness.

Single stream:

.\scripts\winterm\invoke-visual-progress-smoke.ps1 -DelayMilliseconds 1 -SoakIterations 10000

Result	Duration	Samples	Working set start / last / peak	Private peak	Handle peak	Host CPU
PASS	161.47 s	1,409	13.34 / 145.14 / 146.06 MB	104.74 MB	2,093	5.28 s

A phased steady-state run used the same script four times with -SoakIterations 2500 in one Portable host, for 10,000 total iterations:

Phase	Working set	Private bytes	Handles
1	145.05 MB	100.08 MB	2,067
2	145.00 MB	100.43 MB	2,057
3	145.09 MB	100.49 MB	2,059
4	145.14 MB	102.55 MB	2,056

PASS in 167.21 s. Inclusive observed peaks were 145.81 MB working set, 102.55 MB private bytes, and 2,089 handles. Phase 1 → 4 deltas were +0.09 MB working set, +2.48 MB private bytes, and -11 handles; no monotonic handle or working-set leak was observed.

Local gaps and CI expectations

• Inno Setup was not installed locally, so local Setup EXE creation and current-user/all-users install, upgrade, and uninstall lifecycle tests were unavailable.
• The noninteractive environment could not provide human visual sign-off for the full theme, 100/125/150/200% DPI, High Contrast, Reduced Motion, and Narrator matrix. Related source and compiled policy coverage passed.
• PR CI is expected to run quick source/smoke validation, x64 Debug and Release builds with relevant tests, and packaging with pinned Inno Setup 6.7.3, Setup/Portable creation, current-user/all-users/Portable lifecycle validation, and the final ci-gate.
• The tag-triggered formal Release workflow is intentionally not run by this PR. Checksums, both SBOM formats, attestations, the exact eight-file allowlist, and public re-download validation remain mandatory before any future publication.

This PR does not merge itself, create or push v1.2.0, create a GitHub Release, or change winterm.dev/winterm-site.

Checklist

• The change is focused and does not include unrelated formatting.
• Tests were added or updated where appropriate.
• All tests claimed above actually ran and passed.
• User-facing behavior and limitations are documented in this repository.
• Version or schema changes include compatibility and migration notes.
• Package identity, winterm.exe, and Microsoft Terminal coexistence remain isolated.
• No command text, terminal output, clipboard content, credentials, or private paths are logged.
• New source and script files contain the appropriate MIT license header.
• I did not include generated build output, secrets, certificates, or local absolute paths.

[HelloThisWorld]

CI validation completed successfully: GitHub Actions run 30691803765. Passed: exact change classification; source and smoke validation; x64 Debug build/tests; x64 Release build/tests; unpackaged, Setup, and Portable distribution verification; current-user, all-users, and portable lifecycle tests; and the final ci-gate. The local-only gaps documented in the PR remain the manual human theme/DPI/high-contrast/Narrator matrix and local Inno Setup availability; CI covered the automated Setup and lifecycle work. The PR remains Draft and unmerged, with no tag, GitHub Release, or website change performed.