v1.0.30

Fixes the Dismount-WindowsImage -Save lock that broke ISO creation — at its real root cause. v1.0.29 (now retracted) misdiagnosed the WIM-commit failure as transient host interference and bolted on a retry; the lock is actually an in-process .NET registry-provider handle held by the build's own PowerShell process, which a retry can never clear. Offline-hive value enumeration now uses reg.exe exclusively (never the HKLM:\z* provider), so no hive handle is held at dismount time — the reg.exe-only pattern of upstream tiny11builder and Microsoft's offline-servicing docs. Pester 521/0 (plus the admin-gated Synthetic harness).

Fixed

• The Standard build no longer fails at Dismount-WindowsImage -Save with "The process cannot access the file because it is being used by another process." Root cause: Invoke-RegistryPatternZeroAction read the loaded offline NTUSER hive through the .NET PowerShell registry provider (Test-Path / Get-Item on HKLM:\z…). The provider caches an in-process RegistryKey handle to the hive's backing file inside the mount; the kernel keeps a hive loaded while any key handle is open, and reg unload has no force flag — so the handle survived into the dismount and locked install.wim. v1.0.29's retry could not help: the handle is held by the same long-lived process for the whole retry window, and GC (the only thing that would release it) is non-deterministic and never fires during the backoff. The latent bug has existed since v1.0.3 — the provider read predates the v1.0.28 idiom tweak and was byte-identical in the v1.0.27 "revert to v1.0.6" — surfacing intermittently with GC timing and deterministically once a build actually reached the commit step. This corrects the v1.0.26–v1.0.29 "a transient WIM dismount/save file-lock is the leading suspect" framing: it was never environmental.
• Stale-hive recovery (Clear-Tiny11StaleHives) no longer opens a provider handle either. It detected stranded HKLM\z* hives with Test-Path HKLM:\z…, which — on the exact stranded-hive path it exists to recover — opened a fresh in-process handle. It now probes via reg.exe (Test-Tiny11HiveLoaded).

Changed

• All offline-hive registry access in the build process is now reg.exe-only. New Tiny11.Hives helpers: Get-Tiny11RegValueNames (value-name enumeration via reg query, replacing Get-Item … | Select-Object -ExpandProperty Property), Test-Tiny11HiveLoaded (load check via reg query), and Invoke-Tiny11RegExe (a %SystemRoot%\System32\reg.exe absolute-path wrapper — child process, handle closed on exit). Invoke-RegistryPatternZeroAction is rewritten onto Get-Tiny11RegValueNames. No change to a successful build's output image — the same value names are matched and the same reg add … /d 0 writes are issued.
• v1.0.29's WIM-integrity gate and -Save retry are retained as defense-in-depth (harmless, and they still guard a genuinely bad save or rare external interference), but they are no longer the mechanism — the reg.exe fix removes the in-process cause at the source.
• Offline-servicing binaries now resolve from %SystemRoot%\System32 by absolute path, not via %PATH% (Local-Dependencies-Only). reg.exe (Hives Invoke-RegCommand + Core's inline tweak writes), dism.exe (Worker cleanup/export, Core appx enumeration/removal, Actions.ProvisionedAppx, and the Start-CoreProcess wrapper that backs dism/takeown/icacls), and robocopy.exe (Worker ISO copy) are all OS-intrinsic servicing tools that can't be vendored, so they're pinned to the System32 path — blocking a PATH-hijacked stand-in. New Tiny11.Hives resolvers Get-Tiny11RegExePath / Get-Tiny11DismExePath. (The post-boot cleanup script's reg.exe runs on the target machine — a separate context — and is unchanged.)

Added

• Regression guard tests/Tiny11.OfflineHive.NoProvider.Drift.Tests.ps1 — a static scan that fails if any src module reintroduces an HK*:\z offline-hive provider-drive reference. Plus reg.exe-only unit coverage for Get-Tiny11RegValueNames, Test-Tiny11HiveLoaded, and the rewritten Invoke-RegistryPatternZeroAction. (The v1.0.29 synthetic-WIM harness never loaded a registry hive, so it structurally could not have caught this class.)

Notes

• Process fix: v1.0.29 shipped without a real end-to-end ISO build — only the content-agnostic synthetic-WIM test ran in CI — which is exactly why a real-build regression slipped through. v1.0.30 is gated on an actual install.wim-loading build (load hives → pattern-zero → unload → dismount-save) before release.
• v1.0.29 was retracted: its GitHub release and Velopack feed assets were deleted, so v1.0.28 remains the offered latest until v1.0.30 ships. The signed v1.0.29 tag is retained — the repo's tag-protection ruleset blocks tag deletion.

v1.0.28

Re-applies the safe image-shaping improvements on top of the proven v1.0.27 baseline, and retires the autounattend template's runtime network fetch. v1.0.27 reverted five image-shaping files wholesale to v1.0.6 to restore an installable ISO; this release re-applies the install-verified subset of those changes (the Compact OS toggle, catalog-load validation, and the registry-pattern-zero read fix) — each confirmed image-neutral — while permanently leaving out the one change that caused harm (the v1.0.8 State-throw guard). Standard-mode build and install behavior is unchanged from v1.0.27. Pester 491/0, xUnit 140/0.

Added

• Compact OS is a user-facing toggle again. Re-added tweak-compact-install as a real oobe catalog item (default: apply, metadata-only — it drives the <Compact> autounattend element, no offline action), so Compact OS surfaces as a checkbox and is genuinely user-controllable. It stays on by default, matching v1.0.27. To change it post-install instead: compact.exe /compactos:never (or /compactos:always).
• Catalog-load validation for registry-pattern-zero actions — the catalog loader now validates the field shape of registry-pattern-zero actions at load time.

Changed

• registry-pattern-zero reads value names via Get-Item … | Select-Object -ExpandProperty Property instead of Get-ItemProperty | Get-Member, avoiding PSObject metadata pollution (PSPath, PSChildName, …). Image-neutral — same value names matched, same result for the one SubscribedContent-*Enabled action.

Removed

• The autounattend template no longer performs a runtime network fetch. Get-Tiny11AutounattendTemplate previously fell through from the bundled file to a live Invoke-RestMethod against the fork's GitHub main branch, re-caching the result. Because the template ships bundled with the app (and is always present), that fetch tier was effectively unreachable in normal builds — and where it would have fired (a stale cache), it made raw.githubusercontent.com a live build-time dependency and a date-/network-dependent build input. The template is now bundled + embedded only: the shipped file is used, with the in-module embedded copy as the sole fallback, and template updates ride a normal app release. A Pester regression guard asserts no Invoke-RestMethod is performed.

Notes

• This completes the v1.0.27 follow-up bisect. Each of the five files v1.0.27 reverted was re-tested individually against a real build + install; all were confirmed image-neutral — consistent with the v1.0.26 install failure having been intermittent (a WIM dismount/save file-lock is the leading suspect, tracked separately) rather than caused by any one file. The only v1.0.8–v1.0.26 change deliberately not re-applied is the autounattend State-throw guard: a runtime throw on a missing catalog ID was the wrong layer — it turned a self-inflicted orphan into a build crash at 18% on the user's machine. State stays lenient (v1.0.6 behavior); orphan detection will return as a CI/load-time reference-integrity test, not a runtime throw. The Tiny11.Actions.Filesystem.psm1 takeown/icacls noise filter also stays reverted (plain | Out-Null).

v1.0.27

Heads up: Compact OS is forced ON in the ISOs this build produces. Windows installs with its system files compressed on disk (reclaims ~1.5-2.5 GB, at a small CPU cost to decompress on read), and there is no in-app toggle yet. To turn it off (or back on) on the installed machine, run from an elevated Command Prompt or PowerShell:

compact /compactos:never     (turn Compact OS OFF)
compact /compactos:always    (turn Compact OS ON)

---

First release since v1.0.6 that produces an installable Standard-mode ISO. v1.0.26 was the first to complete a Standard build, but the ISO it produced failed during Windows Setup at the file-copy step ("Windows installation has failed") — a build-pipeline regression in the image-shaping code that had accumulated between v1.0.7 and v1.0.26 and only became observable once the build could finally run to completion. v1.0.27 reverts that build code to the proven v1.0.6 state while keeping the safe post-v1.0.6 work. Verified end-to-end on a Win11 25H2 build: clean ISO build → clean install → Compact OS on → first-boot cleanup task deployed and working.

Fixed

• The generated Standard-mode ISO installs again. The files that shape the offline image — catalog/catalog.json, src/Tiny11.Autounattend.psm1, src/Tiny11.Catalog.psm1, src/Tiny11.Actions.Registry.psm1, src/Tiny11.Actions.Filesystem.psm1 — were reverted to their v1.0.6 content, the last version with a confirmed clean install (a dozen-plus smoke installs over several days). The changes that accumulated across v1.0.7–v1.0.26 in those files (takeown/icacls stderr handling, the autounattend State-throw guard, the registry-pattern-zero rework, catalog-load validation, and the tweak-compact-install catalog item) collectively produced an image that no longer installed; reverting them as one consistent v1.0.6 set restores the installable image. Compact OS stays on by default — v1.0.6's lenient State resolves the now-uncatalogued tweak-compact-install to apply → <Compact>true</Compact> — so the on-disk footprint is unchanged.

Changed

• Only the image-shaping build pipeline was reverted; the UI, logging, and failed-build cleanup stay current. Verified from the v1.0.6→v1.0.26 diffs to be cleanup/logging/robustness with zero effect on the output image, and therefore kept: the WebView2 UI redesign, build logging, stale-hive recovery (Clear-Tiny11StaleHives) and locked-scratch-file reporting in the Worker pipeline, the input-ISO drive-letter mount poll (Tiny11.Iso.psm1), and tiny11-cancel-cleanup.ps1. Core-mode (Tiny11.Core.psm1) and first-boot cleanup (Tiny11.PostBoot.psm1) — neither on the Standard install path — were also left current.

Deprecated

• Releases v1.0.7 through v1.0.26 are deprecated — none produces an installable Standard-mode ISO. v1.0.7 aborts the build (takeown/icacls 2>&1 becomes a terminating error under the orchestrator's Stop on the Windows PowerShell 5.1 build host); v1.0.8–v1.0.25 crash the build at 18% (the tweak-compact-install orphan reference once v1.0.8 made State throw); v1.0.26 builds an ISO but it fails to install at the Windows Setup file-copy step. Each GitHub release in that range carries a defect banner pointing here. Core-mode builds were unaffected throughout, and existing installs auto-update to v1.0.27 via Velopack. v1.0.6 and earlier predate the regression.

Notes

• The single change within the reverted set responsible for the install failure was not individually isolated — the five files were reverted together as the proven v1.0.6 image pipeline. A follow-up bisect can pinpoint it and re-apply the innocent improvements (e.g. catalog-load validation, the registry-pattern-zero correctness fix) on top of this working baseline.

v1.0.26

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version builds an ISO, but the ISO fails to install during Windows Setup at the file-copy step -- the build-pipeline image regression that had accumulated since v1.0.7.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

First release that completes a Standard-mode ISO build end-to-end. v1.0.25 fixed the autounattend orphan crash at 18%, but Standard builds still failed at the catalog-apply phase — an older, separate regression the orphan crash had been masking. v1.0.26 fixes it.

Fixed

• Standard-mode builds no longer abort on benign takeown/icacls "Access is denied" noise. Since v1.0.7, Invoke-NativeWithNoiseFilter ran & tool 2>&1 | ForEach-Object; on the build host (Windows PowerShell 5.1) under the orchestrator's $ErrorActionPreference='Stop', redirecting a native command's stderr via 2>&1 makes that stderr a terminating error — so benign protected-folder lines (…\LogFiles\WMI\RtBackup\*: Access is denied., …\WebThreatDefSvc\*) aborted the build at the catalog-apply step before the filter could suppress them. This regressed v1.0.3's | Out-Null behavior (which never aborted) and was hidden v1.0.8–v1.0.25 behind the earlier 18% orphan crash. Fix: a function-local $ErrorActionPreference='Continue' so native stderr flows through the filter instead of terminating — restoring the non-fatal contract while keeping the noise suppression. New regression guard spawns the real 5.1 host (pwsh 7 doesn't reproduce it).
• A failed build no longer bricks the next one (stale offline-hive recovery). A build that exited with the offline registry hives still loaded stranded HKLM\z{COMPONENTS,DEFAULT,NTUSER,SOFTWARE,SYSTEM}, making every subsequent build fail at reg load with "Access is denied". New Clear-Tiny11StaleHives runs at the start of both the Worker and Core pipelines (before any hive load), best-effort unloading any stranded z* hive and clearing corrupt WIM mount points; never fatal. Pester 521/0 → 524/0; xUnit 140/0.

Notes

• v1.0.8 through v1.0.25 cannot complete a Standard-mode ISO build (v1.0.8–v1.0.24: the 18% orphan crash; v1.0.25: the takeown regression above). The deprecation banners on those GitHub releases point to v1.0.26, the first release that builds a Standard ISO end-to-end. Core-mode builds were unaffected throughout, and existing installs auto-update to v1.0.26 via Velopack.

v1.0.25

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version fixed the 18% orphan crash, but the Standard-mode build still aborts at catalog-apply on the v1.0.7 takeown/icacls regression.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

Deprecated

• Releases v1.0.8 through v1.0.24 are deprecated — they shipped a defective Standard-mode build. Every release in that range crashes during a Standard-mode ISO build at the autounattend-render step (18%) with catalog item ID 'tweak-compact-install' not found in ResolvedSelections, producing no ISO. (Root cause under Fixed below: a long-latent orphaned catalog reference that v1.0.8's audit hardening turned from a silent default into a hard failure.) Core-mode builds in that range were unaffected. v1.0.25 is the fix. These releases remain published for auditability, but each one's GitHub release notes are annotated with a defect banner pointing to v1.0.25, and existing installs are offered v1.0.25 as the new latest via Velopack auto-update. v1.0.7 and earlier predate the change and were not affected.

Fixed

• Standard-mode (Worker pipeline) builds no longer crash at the 18% autounattend-render step. Get-Tiny11AutounattendBindings referenced catalog item tweak-compact-install, which was never present in catalog/catalog.json — only the binding and a hand-built test fixture existed (the Compact-OS toggle from the v0.1.0 design spec was half-implemented: consumer written, catalog producer never added). Since v1.0.8 hardened the bindings to throw on a missing ID instead of silently defaulting it to apply (audit A5), every Standard build failed with catalog item ID 'tweak-compact-install' not found in ResolvedSelections. Fix completes the feature: adds tweak-compact-install as a real oobe catalog item (default: apply, metadata-only — no offline action; it drives the <Compact> autounattend element only), so it now surfaces as a user-facing checkbox and <Compact> is genuinely user-controllable. Compact OS stays on by default, matching pre-v1.0.8 behavior. Core-mode builds were unaffected. Reported on a Win11 25H2 build.
• Closed the gap that hid the bug. The autounattend bindings tests (tests/Tiny11.Autounattend.Tests.ps1) now derive ResolvedSelections from the real catalog.json (via New-/Resolve-Tiny11Selections) instead of a fixture that fabricated tweak-compact-install as present — that fixture drift was exactly what masked the crash. Added tests/Tiny11.Catalog.ReferenceIntegrity.Drift.Tests.ps1: a defense-in-depth scan that fails if any production-runtime file (PS modules, orchestrator scripts, C# launcher) hardcodes a catalog-ID literal absent from catalog.json, stopping the whole orphan-reference class from recurring. Pester 518/0 → 521/0.

Changed

• Velopack 0.0.1298 → 1.0.1 (GA). Bumped both pins in lockstep — the vpk CLI (release.yml VPK_VERSION) and the Velopack NuGet PackageReference (launcher/tiny11options.Launcher.csproj). The .NET API surface used here (VelopackApp.Build().Run(), UpdateManager, GithubSource, the custom IUpdateSource) is source-compatible — no code changes. Verified locally: launcher publishes against 1.0.1, xUnit 140/0, and vpk 1.0.1 pack with the existing release.yml flags still emits releases.win.json + RELEASES + tiny11options-win-Setup.exe + *.nupkg (upload glob unchanged). 1.0.x additionally produces a Portable.zip that the glob deliberately does not upload (preserves prior behavior). Refreshed the stale release.yml asset-glob comment that referenced 0.0.1298 runtime behavior.

• Detached from upstream fork network. Repository is no longer a fork of ntdevlabs/tiny11builder per GitHub's "Leave fork network" Settings action. gh api repos/bilbospocketses/tiny11options --jq '.fork' now returns false; .parent and .source are both null. Formalizes what was already the project posture ("standalone fork — no upstream contributions" per project_tiny11options_dependency_policy.md, the existing CONTRIBUTING.md note "we do not contribute back to the upstream ntdevlabs/tiny11builder repo", and the README "Contribution / fork boundary" section). Historical attribution to ntdevlabs is preserved in README + LICENSE — credit, separate from the GitHub fork relationship.

• docs/release-signing-setup.md drift fix — Status banner refreshed from "v1.0.0 through v1.0.7 / v1.0.8 cycle" to "v1.0.0 through v1.0.24 / v1.1.0 cycle". Naming-note + FAQ updated to reflect the v1.0.24 azure/trusted-signing-action → azure/artifact-signing-action@v2.0.0 rename (pinned to commit c7ab2a86). Added explanation that v2.0.0 retains trusted-signing-account-name as a backward-compat input alongside the new signing-account-name, so existing TRUSTED_SIGNING_* secret names continue to work. Added v1.1.0 ci B2 scope mention (step-level secret scope narrowing, clears Scorecard TokenPermissionsID).

Added

• LICENSE — GPL-3.0-only license text added at repo root. Matches control-menu, ws-scrcpy-web, svgedit, and oao licensing posture. Clears the OpenSSF Scorecard LicenseID finding. README's existing "License / credits" section already references upstream + fork additions; this PR adds the formal license file.

Changed

• Microsoft.Web.WebView2 now resolved via NuGet end-to-end, not vendored DLLs.
  • launcher/tiny11options.Launcher.csproj: three <Reference HintPath="..."> + <Content Include="..."> blocks replaced with a single <PackageReference Include="Microsoft.Web.WebView2" Version="1.0.2535.41" />. MSBuild handles native asset deployment automatically (WebView2Loader.dll lands in both the build root and runtimes/win-x64/native/ per NuGet's standard layout). The published tiny11options.exe bundles all DLLs into the self-contained single-file artifact via IncludeAllContentForSelfExtract=true — end-user installs remain fully offline-capable.
  • src/Tiny11.WebView2.psm1: legacy PS WPF wizard now resolves DLLs from the NuGet global packages folder (%USERPROFILE%\.nuget\packages\microsoft.web.webview2\<version>\lib\net462\ for managed wrappers + \runtimes\win-x64\native\ for the loader). Get-Tiny11WebView2SdkPath swapped its -RepoRoot parameter for -NugetPackagesRoot (default: $env:NUGET_PACKAGES or $env:USERPROFILE/.nuget/packages). Error message points at dotnet restore launcher/tiny11options.Launcher.csproj when DLLs are missing.
  • tests/Tiny11.WebView2.Tests.ps1: 6 existing tests updated to assert the NuGet cache layout; 2 new tests added (NUGET_PACKAGES env var override + dotnet restore hint in the throw message). Pester baseline 516/0 -> 518/0.
  • CONTRIBUTING.md: documents dotnet restore as a one-time prereq for the legacy PS path. Production users of the released .exe are unaffected.
  • Deleted dependencies/webview2/1.0.2535.41/ (three checked-in DLLs: Core.dll, Wpf.dll, WebView2Loader.dll).
  • Future version bumps flow through Dependabot's nuget ecosystem; previously the vendored DLLs were invisible to Dependabot.

Security

• OpenSSF Scorecard BinaryArtifactsID finding cleared — the three WebView2 DLLs previously vendored under dependencies/webview2/ were the only binaries flagged. Going forward, binaries committed to the repo will be flagged by Scorecard so we know about them.
• Microsoft.Web.WebView2 now under Dependabot visibility — Dependabot's nuget ecosystem already tracks launcher/tiny11options.Launcher.csproj, so SDK CVEs + version bumps now arrive as auto-PRs. Vendored DLLs were invisible to Dependabot, which was the practical security gap that motivated this change (CVE-fix freshness, not active exploitability — the wrappers are thin shims over the user-installed Edge WebView2 Runtime).

v1.0.24

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version crashes the Standard-mode build at 18% -- the autounattend binding references catalog item tweak-compact-install, which was never added to catalog.json; v1.0.8 turned that missing id from a silent default into a hard error.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

Shippable result of the v1.0.23 security baseline work after two release-pipeline blockers. v1.0.23 cut the tag but the release workflow failed at action-resolution time: azure/trusted-signing-action@v0.5.1's action.yml calls actions/cache@v4 (unpinned) on lines 218 + 228, and the v1.0.23 baseline's new sha_pinning_required: true enforcement rejects transitive unpinned refs even for gate-skipped steps. The v1.0.23.1 hot-fix tag swapped the action to azure/artifact-signing-action@v2.0.0 (with SHA-pinned internals) but Velopack rejected the 4-part 1.0.23.1 version string ("must be a 3-part SemVer2 compliant version string"). v1.0.24 is the same hot-fixed code re-cut under a 3-part SemVer-compliant tag. The v1.0.23 + v1.0.23.1 tags remain on origin as zombies (no associated GitHub Release for either); the tag ruleset's deletion: true rule prevents their cleanup without a bypass.

Changed

• azure/trusted-signing-action@v0.5.1 → azure/artifact-signing-action@v2.0.0 in release.yml (both occurrences). SHA c7ab2a863ab5f9a846ddb8265964877ef296ee82. The Azure team renamed the repo + cut v2.0.0 with internally-SHA-pinned actions/cache@<sha> # v5.0.4. The rename was originally deferred to v1.1.0 per the v1.0.22 breadcrumb (ci B3); the v1.0.23 baseline's sha_pinning_required enforcement forced the rename forward. v1.1.0 scope now shrinks to: secret provisioning + step-level secret scope (ci B2).
• Repo-level patterns_allowed swapped azure/trusted-signing-action@* → azure/artifact-signing-action@*. ossf/scorecard-action@* unchanged.
• csproj <Version> 1.0.23 → 1.0.24. app.manifest assemblyIdentity version="1.0.23.0" → "1.0.24.0". ui/index.html style.css?v=1.0.23 → ?v=1.0.24.

Notes

• v1.0.23 + v1.0.23.1 tags are zombies. Both tags exist on origin but have no associated GitHub Release. The tag ruleset's deletion: true rule blocks deletion without a bypass; leaving them as audit-trail artifacts of the two release-pipeline blockers (transitive SHA-pinning + 4-part SemVer). Consumers should ignore both; v1.0.24 is the first shippable release after the security baseline pass.
• Lessons captured:
  • sha_pinning_required: true extends to transitive uses: inside composite actions. Auditing for SHA pinning means looking at our workflow files PLUS the action.yml of every action we call, recursively. The CM canonical baseline hasn't hit this because CM hasn't cut a release with sha_pinning_required: true enforcement active yet (v1.1.0-beta.3 shipped pre-hardening 2026-05-13; the 2026-05-18 hardening pass is still awaiting v1.1.0 VM smoke). When CM next tags, the same azure/trusted-signing-action@v0.5.1 block will surface — CM will need an analogous hot-fix.
  • Velopack's vpk pack rejects 4-part SemVer. --packVersion requires 3-part MAJOR.MINOR.PATCH (optionally with -prerelease / +build per SemVer2). 4-part Microsoft-style assembly versions are NOT accepted. When hot-fixing a tag mid-release-pipeline, pick a 3-part SemVer label (patch bump or prerelease form), not a 4-part one.

release: v1.0.22 -- inert trigger release for v1.0.21 dot-bg-fix smoke

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version crashes the Standard-mode build at 18% -- the autounattend binding references catalog item tweak-compact-install, which was never added to catalog.json; v1.0.8 turned that missing id from a silent default into a hard error.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

No-op smoke-trigger release for v1.0.21 dot-bg fix. Zero behavior change vs v1.0.21. Sole purpose: be the "newer release" that a v1.0.21-installed launcher detects via the v1.0.13-added window.focus re-check, so the v1.0.21 belt-and-suspenders fix (cache-bust ?v= query string + ::before pseudo-element for the visible dot) can be smoked end-to-end. Expected on v1.0.21 badge surface: resting blue pulsing dot (both themes); hover dark = solid white dot + white wave fading outward (both unified, ring AND inner circle now actually swap color); hover light = solid #3a3a3a dot + #3a3a3a wave fading outward; tooltip "Update available, click to install..." steady (no scale inheritance).

Changed

• launcher/tiny11options.Launcher.csproj — <Version>1.0.21</Version> → <Version>1.0.22</Version>.
• launcher/app.manifest — assemblyIdentity version="1.0.21.0" → "1.0.22.0".
• ui/index.html — style.css?v=1.0.21 → style.css?v=1.0.22. Per the v1.0.21 lesson, the cache-bust query string must be bumped in lockstep with the launcher <Version> on every release so WebView2's HTTP cache fetches the fresh style.css rather than serving a stale copy from %LOCALAPPDATA%\tiny11options\webview2-userdata\ cached against the same https://app.local/style.css URL from a prior version.

No CSS, JS, resource, or test changes. Pester 516/0 + xUnit 140/0 both expected to match v1.0.21 ship.

Note

• v1.1.0 = Microsoft Trusted Signing (still queued, unchanged).

fix(ui): cache-bust + ::before pseudo-element for dot bg (v1.0.21)

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version crashes the Standard-mode build at 18% -- the autounattend binding references catalog item tweak-compact-install, which was never added to catalog.json; v1.0.8 turned that missing id from a silent default into a hard error.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

Belt-and-suspenders fix for the persistent dot-bg-on-hover bug. v1.0.19 declared background-color: var(--badge-hover-color) explicitly in the :hover rule, which should have resolved the v1.0.17 var-indirection issue. User installed v1.0.19, hovered, reported the same bug: "1.0.19 has the same issue: theme color for circle on hover." Two plausible root causes were not previously addressed; v1.0.21 defends against both simultaneously, with the explicit ask "please figure out the issue, and only push one release (1.0.21)."

Changed

• ui/index.html — cache-bust style.css href via ?v=1.0.21 query string. WebView2's HTTP cache serves resources from VirtualHostNameToFolderMapping by URL. The URL https://app.local/style.css is identical across every app version, even though each version's launcher.exe maps app.local to a different on-disk ui-cache folder. The user's WebView2 userdata directory (shared across versions at %LOCALAPPDATA%\tiny11options\webview2-userdata\) caches HTTP responses by URL — so v1.0.19's CSS update would be invisible if the URL matches a previously-cached v1.0.17/v1.0.18 response. Adding ?v=1.0.21 forces a fresh fetch since the cache key includes the query string. This must be bumped in lockstep with launcher/tiny11options.Launcher.csproj <Version> for every release going forward.
• ui/style.css — .update-badge visible dot is now a ::before pseudo-element on the <button>, not the button itself. The <button> becomes a transparent click target (background: transparent, border: none, outline: none, appearance: none, etc); the ::before owns the bg-color, border-radius, and the pulse animation. The :hover / :focus-visible state propagates from the button to its ::before via .update-badge:hover::before / :focus-visible::before. Both the dot's bg AND the @keyframes box-shadow ring color follow a single --badge-pulse-color custom property scoped to the ::before — resting var(--accent) (blue), hover var(--badge-hover-color) (white in dark / #3a3a3a in light). The ::after tooltip is unaffected (always was on the button itself; its CSS is unchanged).
• --badge-pulse-color custom property is now defined on ::before rather than on the button. Scoped to where it's actually consumed (by the ::before's own background-color AND by the @keyframes box-shadow color that the ::before's animation drives).

Note

• Why two changes for one bug. Without dev-tools access on the live app, I can't tell whether the cause is the cache or a <button> UA quirk. The CSS restructure to ::before removes any possibility of a button-specific UA interaction since pseudo-elements have no button-specific UA defaults. The cache-bust handles the orthogonal possibility that v1.0.19's CSS never actually loaded due to stale WebView2 cache. Either fix alone could have been the right one; doing both eliminates the diagnostic ambiguity in one shot per user direction ("please figure out the issue, and only push one release").
• No v1.0.22 inert trigger this round. User explicitly: "only post 1.0.21. When I'm back I'll ask you to post 1.0.22 so we can see if 1.0.21 has the right fix." v1.0.21-installed clients will see no update until v1.0.22 publishes — manual smoke deferred to that follow-up push.
• v1.1.0 = Microsoft Trusted Signing (still deferred, unchanged from prior breadcrumbs).

release: v1.0.20 -- inert trigger release for v1.0.19 dot-bg-fix smoke

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version crashes the Standard-mode build at 18% -- the autounattend binding references catalog item tweak-compact-install, which was never added to catalog.json; v1.0.8 turned that missing id from a silent default into a hard error.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

No-op smoke-trigger release. Zero behavior change vs v1.0.19. Sole purpose: be the "newer release" that a v1.0.19-installed launcher detects via its (v1.0.13-added) window.focus re-check, so the v1.0.19 dot-bg fix can be smoked end-to-end. Expected on v1.0.19 badge surface: resting blue pulsing dot (both themes); hover dark = solid white dot at center + white wave fading outward; hover light = solid #3a3a3a dot at center + #3a3a3a wave fading outward; tooltip "Update available, click to install..." renders steady. The "nav bg shows through the dot" bug from v1.0.17/v1.0.18 is gone.

Changed

• launcher/tiny11options.Launcher.csproj — <Version>1.0.19</Version> → <Version>1.0.20</Version>.
• launcher/app.manifest — assemblyIdentity version="1.0.19.0" → "1.0.20.0".

No code, resource, or test changes. Pester 516/0 + xUnit 140/0 both expected to match v1.0.19 ship.

Note

• v1.1.0 = Microsoft Trusted Signing (unchanged from v1.0.18 breadcrumb).

v1.0.19

DEPRECATED: this release is defective. Use v1.0.27 instead.

No release from v1.0.7 through v1.0.26 produces an installable Standard-mode ISO. This version crashes the Standard-mode build at 18% -- the autounattend binding references catalog item tweak-compact-install, which was never added to catalog.json; v1.0.8 turned that missing id from a silent default into a hard error.

v1.0.27 reverts the image-shaping build pipeline to the proven v1.0.6 code -- verified end-to-end (clean build, clean install, Compact OS on, first-boot cleanup working) -- while keeping the post-v1.0.6 UI, logging, and failed-build cleanup. Existing installs auto-update via Velopack. Core-mode builds were unaffected.

---

Update-badge dot now actually shows the hover color (the wave already did since v1.0.17). User smoke of v1.0.17/v1.0.18: "the 'circle' inside the pulsing wave is still the theme color, not the hover color. all else is good to go. note that the pulse color is good to go." Screenshots showed the box-shadow ring fading correctly to the hover color but the inner dot rendering as if its background were transparent — the nav bg showed through.

Changed

• ui/style.css .update-badge background is now declared with background-color (longhand) instead of background (shorthand), and the value is the literal var(--accent) at rest / var(--badge-hover-color) on :hover / :focus-visible — no --badge-pulse-color indirection on the bg. v1.0.17 had background: var(--badge-pulse-color) and relied on the var change in the :hover rule to propagate to the static background. The @keyframes box-shadow ... var(--badge-pulse-color) indirection works fine (the ring color flips reliably on hover, confirmed in user smoke); the static-background-via-var indirection does not (the bg stayed at the rest-time computed value). Suspected WebView2 Chromium quirk with background shorthand combined with hover-triggered custom-property changes. Switching to background-color longhand AND making the hover override an explicit declaration both bypass the issue.
• --badge-pulse-color retained on .update-badge purely for the @keyframes badge-pulse ring-color reference. The hover rule still overrides it (so the ring keeps changing color in lockstep with the dot); the dot bg just no longer depends on that indirection.

Note

• v1.0.20 = inert smoke-trigger release. Same pattern as v1.0.14/v1.0.16/v1.0.18 — pure version bump so v1.0.19 clients detect a newer release via the v1.0.13 focus re-check + can manually smoke the corrected dot-bg behavior.
• v1.1.0 = Microsoft Trusted Signing (unchanged from previous breadcrumbs).
• Lesson worth noting. background: var(--x) and background-color: var(--x) are NOT equivalent under hover-triggered custom-property changes in WebView2's Chromium. The shorthand appears to compute once at element style time and not re-resolve when the var changes via a more-specific rule. Longhand background-color updates correctly. Defensive default for future similar work: prefer longhand for dynamic-var-driven properties.