Thanks for this, @NF0T — clean, well-scoped, and it correctly closes a real silent-no-op gap on Windows. The implementation faithfully follows the hidapi/FFTW3/DeepFilterNet3 setup-script pattern, the find_package PREPEND is properly WIN32-guarded so Linux/macOS are untouched, error handling in the PowerShell script is solid ($ErrorActionPreference = "Stop" plus per-step $LASTEXITCODE checks), and the windeployqt pre-stage workaround is both correct and well-commented. All six checks (build, check-windows, check-macos, CodeQL, analyze) are green, and the deploy-block copies are Test-Path-guarded so they also work on a cache hit. No application code changed, as advertised.

One substantive, non-blocking note:

Cache key doesn't capture the Qt version (windows-installer.yml:46-49). The key is qtkeychain-${{ runner.os }}-${{ hashFiles('scripts/setup/setup-qtkeychain.ps1') }} — identical to the opus/fftw/hidapi/deepfilter pattern, so this matches convention. But qtkeychain is the one dependency here that links against Qt and whose ABI must match the app's Qt exactly (the PR body calls this out). The workflow pins Qt at 6.8.* (line 24), a floating minor. A future bump of that line to e.g. 6.9.* would not invalidate this cache, so CI could silently reuse a qtkeychain built against the old Qt minor against a newer Qt — exactly the ABI mismatch the build-from-source approach exists to avoid. (Within 6.8.x patch bumps this is ABI-stable, so the practical risk is low and only bites on a minor bump.)

Cheap hardening: fold the Qt version into the key, e.g. key: qtkeychain-${{ runner.os }}-6.8-${{ hashFiles('scripts/setup/setup-qtkeychain.ps1') }}, or hash the workflow file alongside the script. Your call whether it's worth it now vs. a comment for whoever next bumps Qt.

Minor / optional: the tarball download has no SHA-256 verification — consistent with the other setup scripts, so not a regression, just noting it as future defense-in-depth for the third-party fetch.

Nothing here blocks merge.

_{🤖 aethersdr-agent · cost: $5.2686 · model: claude-opus-4-8}

Reviewed the full diff against the existing windows-installer.yml and the established hidapi/FFTW3/DeepFilterNet3 dependency pattern. This is clean, well-scoped, and the explanation matches what the code actually does. Nice work, @NF0T — thanks for closing the silent Windows credential-persistence gap.

What checks out

• Scope is tight: the three files are exactly the build pipeline, no application code, consistent with the "SmartLinkClient.cpp is already correct" claim.
• The setup script mirrors the other setup-*.ps1 scripts: $ErrorActionPreference = "Stop", per-step $LASTEXITCODE guards on tar/configure/build/install, an idempotency guard on Qt6KeychainConfig.cmake, and absolute-path normalization. Error handling at the download/extract/build boundaries is solid.
• The cache step matches the sibling deps (path + runner.os + script hash), and the cmake --install staging produces the layout find_package(Qt6Keychain QUIET) resolves against — with the list(PREPEND CMAKE_PREFIX_PATH ...) correctly WIN32-gated so Linux/macOS are untouched.
• The DLL is copied into the deploy/ dir inside the "Deploy Qt" step, so it's captured by all three downstream artifacts (portable ZIP via Compress-Archive deploy\*, Inno, and MSIX -DeployDir deploy) — the PR claim is accurate.

One thing worth a note (non-blocking)

The cache key (qtkeychain-${{ runner.os }}-${{ hashFiles('setup-qtkeychain.ps1') }}) is copied verbatim from the other deps, but qtkeychain differs from them in one way: Opus/FFTW3/hidapi/DeepFilterNet3 are Qt-independent C libraries, whereas qt6keychain.dll links Qt6Core and was built against whatever Qt install-qt-action resolved 6.8.* to in the run that populated the cache. On a cache hit in a later run with a newer 6.8 patch, the stale-built DLL is reused against newer Qt.

In practice this is low-risk — Qt 6 guarantees forward binary compatibility across the 6.x series and qtkeychain only touches Qt6Core, and the version is floated forward (never pinned back), so the cached build is always equal-or-older than the runtime Qt. So no action strictly required. If you want belt-and-suspenders, you could fold the resolved Qt version into the key (it's the one dep where the Qt ABI is actually a cache input), but it's fine to leave as-is to stay consistent with the other entries.

The workflow_dispatch validation on your fork (qtkeychain built against 6.8.3, HAVE_KEYCHAIN defined, DLL in artifact) is exactly the end-to-end evidence this needs. LGTM.

_{🤖 aethersdr-agent · cost: $2.3721 · model: claude-opus-4-8}

Downloads Qtkeychain from upstream github and builds during CI run. Thanks Ryan

Approving — clean, well-scoped, demonstrated CI/build fix that activates SmartLink credential persistence on Windows release artifacts (no app code).

Verified:

• Setup script builds qtkeychain 0.16.0 against QT_ROOT_DIR (ABI matches the app's Qt), is idempotent, has $ErrorActionPreference=Stop + per-step $LASTEXITCODE checks, and cmake --installs the find_package-resolvable layout. Follows the hidapi/FFTW3/DFN pattern.
• The WIN32 CMAKE_PREFIX_PATH prepend is correctly scoped (Linux/macOS untouched) and harmless where qtkeychain isn't staged — which is why the regular check-windows CI still passes (no regression).
• Workflow wiring is right: cache keyed on the script hash, setup after Install-Qt/before Configure, and the qt6keychain.dll→Qt-bin pre-stage with a clear comment on the real windeployqt quirk; DLL copied into the deploy block (ZIP/installer/MSIX).
• Demonstrated end-to-end on the fork (Principle XI): built against Qt 6.8.3, HAVE_KEYCHAIN defined, DLL deployed.

CI green across all six, already core-dev-approved. One non-blocking note: the download isn't checksum-verified — consistent with the existing setup scripts, so I'll file a follow-up to pin SHA256s across all of them rather than gate this. Nice work @NF0T.