meshbay.git/packages/meshbay-node/tests/test_packaging_win.py, branch 0.16

style: the 98 ruff could not fix, so the linter is a signal again

2026-09-19T12:39:38Z

The pass before this applied ruff's own fixes. These are the ones needing a decision, and the point of doing them is that `ruff check .` now passes: a linter reporting 98 known-acceptable findings reports nothing, because the next real one arrives invisible. **Lines over 100 (70).** Mostly wrapped where they stood. Two exceptions: the aligned trailing comments in `protocol.py`'s message table were shortened rather than wrapped, because wrapping one row of a table breaks the table; and in `models.py` the column comments moved above their columns for the same reason. **Imports below the first statement (14).** `csam.py` kept its FastAPI imports under a section header halfway down the file; two node tests had a constant and a `pytestmark` wedged between two import blocks. Moved, not suppressed. **Bindings nothing reads (4).** Three in tests, where the call stays and only the name goes — `_user(client, "listener")` is there to create the user, not to return one. The fourth was in `revocation.py` and was not a lint finding at all: `_connect_and_listen` opened an httpx stream to the WebSocket URL, did `pass`, and then opened the real connection through the `websockets` library. One pointless request per connect, left over from before that library was used directly. Removed, and `httpx` with it. **`l` as a name (4)**, **semicolons (6)** in the POC spikes, and the rest. 2893 passed, the same count as the two commits before it. `meshbay_node/revocation.py` is worth a decision separately: 154 lines that nothing imports, superseded by `hub_client.maintain_ws`'s `on_revocation`. This commit only stopped it failing the linter. Co-Authored-By: Claude Opus 5

docs: drop the references to design notes that live outside the repo

2026-09-18T23:15:53Z

Seventeen comments across the Windows packaging targets pointed at C:\Users\admin\devel\light-client.md and msix-installer.md -- absolute paths on one developer's machine, unreadable to anyone else who clones this repository and unverifiable by any test here. The surrounding prose already carried the substance in every case, so these are removals, not rewrites, with two exceptions where the pointer was doing real work: electron-builder.msix.yml's header told the reader to go read §4 and §8 first. It now states the fact directly (an AppX/MSIX install never elevates, by design, so the package carries none of installer.nsh's elevation logic) and says the open items are called out at each declaration below -- which they already were, at `capabilities` and `customExtensionsPath`. The two "msix-installer.md §8" citations become "an open item" / "the other open item", beside the description of the item that was already there. Paragraphs the removals left ragged are re-wrapped. Verified: node suite 1403 pass / 4 skip (71 of them test_packaging_win.py), both electron-builder configs still parse as YAML, node --check on main.js. The .ps1 edits are inside <# #> comment headers plus one deleted Write-Host in a block that keeps two others; no pwsh on this machine to parse them. Not touched, and much larger: ~230 comments elsewhere in the codebase cite per-feature design notes (musicbay.md, mediacenter.md, auth-confirm.md and twenty more) that were merged into docs/MESHBAY_DESIGN.md. Co-Authored-By: Claude Opus 5

fix(win): a service-mode daemon can be replaced, and the Node page can link one

2026-09-14T21:51:36Z

Two live-reproduced bugs in Windows node start/stop, found sideloading the 0.14.0 build: - node:start's crash-recovery step killed a service-mode daemon with taskkill/CTRL_BREAK, both of which fail with "Access is denied" against a process running under the Scheduled Task's own S4U logon session (a different session from the Electron app's). The daemon it was meant to replace just kept running, unreplaced, and schtasks /run on a task Windows still considered Running was then a silent no-op too. Route through winServiceTaskEnd() (schtasks /end) first, the way nodeServiceStop/ nodeServiceRestart already correctly do. service-mode.ps1 also now starts the task right after registering it -- Register-ScheduledTask's own AtStartup trigger does not run it immediately, so nothing was listening until the next reboot. - The Node page's Start button called node.start() with no arguments, so an unlinked node (a fresh install, or one whose hub-side link was lost) could never link on Start alone -- only create-group-page.js's own call passed {hubUrl, username, token}. Reproduced on a fresh non-service install signed in to the real hub: Start hung for ~105s and failed with "could not link", pointing at a "Link Node" control that lives on Settings, not the Node page (that message is fixed too). Co-Authored-By: Claude Sonnet 5

fix(packaging): three MSIX first-run regressions found by a real sideload

2026-09-12T13:48:22Z

A second-machine sideload of the MSIX target surfaced three things the earlier verification round (which only proved the package installs and runs) had missed: 1. meshbay-node missing from PATH. installer.nsh's customInstall adds node-runtime\ to HKCU\Environment at install time -- an unelevated per-user write, never blocked by MSIX's no-elevation rule, only by the more basic fact that an AppX/MSIX install runs no custom code at all. packaging/win/ensure-node-path.ps1 (idempotent, no admin verb) plus main.js's winEnsureNodeOnPath() do it from the app itself instead, once per launch, shipped to Full and MSIX (not Light, nothing to add there). Verified live via the Node inspector protocol: the entry was in HKCU\Environment\Path after a launch, absent before. 2. A daemon that crashes on startup failed silently. spawnNodeDetached() used stdio: 'ignore', so a real crash reproduced live (a second instance colliding with the first on 127.0.0.1:18000) left waitForNode()'s generic 60s timeout as the only failure ever shown. spawnNodeDetachedWatched() pipes stdio and watches ~2.5s, rejecting immediately with the daemon's own stderr on an early exit; a survivor has its streams released and runs fully detached exactly as before. First version bounded the captured text by line count and a live test showed that cut the actual OSError line -- two uvicorn/asyncio tracebacks followed it in the real capture -- so it is bounded by characters instead. 3. No hint that a startup-mode choice exists. The install-time radio page was the only place this was ever offered, and nothing replaces it now that no install-time page can exist at all. SetupWelcome (the existing first-run banner) grew a conditional hint, shown only while a bundled node is present and neither autostart nor service mode is configured yet. Considered and rejected: linking straight to the Node page -- its route is gated on a linked hub node key, false on the exact fresh-install screen this hint targets, so the link would have been dead on arrival. New key setup.node_startup_hint, added to all ten locale catalogues. test_packaging_win.py gained six tests pinning all three (69 total). Full plan and verification detail: C:\Users\admin\devel\msix-installer.md section 13 (out of repo). Co-Authored-By: Claude Sonnet 5

feat(packaging): an MSIX target for Microsoft Store submission

2026-09-11T15:51:51Z

Store certification of the NSIS "MSI/EXE" submission failed on three checks (silent-install verification, Add/Remove Programs entry, bundleware check) -- traced and reproduced live to one cause: SmartScreen blocks an unsigned, internet-downloaded installer at the shell layer before Microsoft's own unattended validation bot ever gets to run it. MSIX sidesteps this class of failure entirely: submitted through the Store's native pipeline, there is no browser-download-then-launch step for SmartScreen to intercept, and Microsoft signs the package itself at publish time -- free, and specific to this submission type (Trusted Signing remains a paid service for the MSI/EXE path). Full plan and findings: C:\Users\admin\devel\msix-installer.md (out of repo). electron-builder.msix.yml carries the same bundle as Full (node runtime, ffmpeg, both service scripts) -- an AppX/MSIX install never elevates, by design, but that changes only *when* the two elevated operations can run, not whether the daemon ships. No main.js changes were needed: the on-demand elevation path for service-mode (winElevateServiceMode(), driven from the Node page) already existed for a different reason and depends only on service-mode.ps1 being present as an extraResource, true for any packaged Windows target. identityName/publisher/publisherDisplayName are the real values from Partner Center's app-identity reservation, not placeholders. build-win-msix.ps1 points electron-builder at the system Windows 10 SDK (auto-detected) instead of letting it download its own bundled copy -- that download's 7z extraction creates symlinks this target never uses and fails without SeCreateSymbolicLinkPrivilege, reproduced on this machine. build/appx/ carries the four tile images the AppX target requires regardless of showNameOnTiles, generated once from the existing app icon (see that directory's README) since the system-SDK redirect has no vendor samples to fall back to. build/appx-extensions.xml declares windows.startupTask by hand rather than via electron-builder's addAutoLaunchExtension, which always targets the Electron shell -- this points at the bundled node binary instead, matching what "starts at sign in" already means for Full. Verified live via a signed sideload install (self-signed test cert, cleaned up after): the package installs and the app runs correctly. One finding worth carrying forward -- the declared network capabilities (internetClientServer, privateNetworkClientServer) do not create any firewall exemption for this app, most likely because automatic capability-based exemption is an AppContainer-sandbox property and this app deliberately runs full-trust, outside any sandbox. Not a regression: no install-time elevation was possible either way, so the cost is the same one-time OS firewall prompt firewall.ps1's own header already documents as its fallback today. Co-Authored-By: Claude Sonnet 5

feat(packaging): a Light installer target with no bundled node runtime

2026-09-11T15:51:51Z

MeshBay Light ships the Electron client + UI only -- no PyInstaller node freeze, no ffmpeg, no service install/autostart. Two standalone electron-builder configs (Full via package.json's build field, Light via electron-builder.light.yml passed with --config, which reads only that file -- confirmed against app-builder-lib's own config loader) rather than one config branching on a flag. build-win-common.ps1 holds the steps both orchestrators share (Node check, npm ci, Electron bump, sync-ui) so build-win.ps1 (Full) and the new build-win-light.ps1 cannot drift apart; build-win.ps1 is refactored to dot-source it with no behavior change (rebuilt and diffed byte-identical output). installer-light.nsh keeps the one thing Light still needs -- an unconditional firewall rule, since the client listens too -- and none of the service-mode/autostart machinery installer.nsh carries, which has nothing to gate without a bundled node. dist-light/ (Light's own electron-builder output dir) gets its own .gitignore line since the bare dist/ rule does not match it. Co-Authored-By: Claude Sonnet 5

feat(packaging): one radio page for Windows autostart, firewall every mode

2026-09-10T23:33:05Z

Operator feedback on the 0.13.0 installer: - The all-users / current-user page (electron-builder's PAGE_INSTALL_MODE) only ever showed "anyone who uses this computer" disabled -- MeshBay is per-user only (account-bound keystore/DPAPI, MESHBAY_DESIGN.md 11.2) and build.nsis forbids elevation. customInstallMode forces $isForceCurrentInstall so the page is skipped. - The two nested Yes/No MessageBoxes are one nsDialogs radio page (customPageAfterChangeDir): only-while-open / at-sign-in / background service, default background service. customInit seeds MB_AutoMode "2" for silent installs where the page never runs. "At sign-in" now writes the Startup .vbs from the installer (meshbay-node autostart install, unelevated); the old per-user branch set up nothing. - The firewall rules go in for every mode, not behind a second opt-in -- a node that accepts no connections is the failure mode MESHBAY_DESIGN.md 7.5 names. Folded into the service elevation for mode 2; their own single elevation for 0/1. Unelevated short-circuit kept but narrower: firewall.ps1 check AND service.ps1 status must both pass to skip mode 2's UAC. Var MB_AutoMode lives inside customPageAfterChangeDir, not at file scope: the uninstaller compile pass inserts none of the macros that read it and makensis -WX turns "unused Var" (6001) into a hard error. Not yet exercised on a real machine -- the NSIS UI cannot be driven from the build env. test_packaging_win.py pins the script shape. Co-Authored-By: Claude Sonnet 5

fix(win): finish the desktop setup flow — node-key link + service task

2026-09-05T17:48:10Z

Two independent breaks in the Windows first-run path: - node:start's win32 branch never linked the node's Ed25519 key to the hub account, so the daemon sat at waiting_for_account and the Create Group wizard span on "Detecting local node…" for ever — the only way through was pasting the key by hand on the Profile page. The Linux branch has always done this inline; factor it into linkNodeKeyAndAwaitRunning() and call it from win32 too. PUT /v1/users/me/node_key overwrites, so this also recovers an account still carrying a previous machine's node key. - service.ps1's install branch did `$action = New-ScheduledTaskAction`, shadowing its own [ValidateSet(...)][string]$Action parameter (PowerShell variable names are case-insensitive). The CimInstance was coerced to the string "MSFT_TaskExecAction", Register-ScheduledTask -Action rejected it, and "background service" mode never created the task — reproduced live. Rename the locals to $taskAction / $bootTrigger / $taskPrincipal. Co-Authored-By: Claude Sonnet 5

fix(node): register the service-mode task with Register-ScheduledTask -LogonType S4U

2026-09-05T12:48:08Z

schtasks.exe has no flag naming the logon type directly -- it only infers S4U vs Interactive from whether /rp is present, and both readings broke live on a blank-password account: /rp "" fails schtasks' own credential validation, and omitting /rp registers "Interactive only", which never launches the process at boot or on demand despite installing cleanly. Register-ScheduledTask -LogonType S4U names the logon type explicitly, no inference. Confirmed live: install, manual start, and unattended boot-time start all now work. Co-Authored-By: Claude Sonnet 5

fix(win): graceful shutdown, one startup-mode control, and a stray-\r bug

2026-09-05T11:06:55Z

Windows-only changes, all found by actually running the previous session's work rather than by review alone: - CTRL_CLOSE_EVENT/LOGOFF/SHUTDOWN handler (platform.py, ctypes SetConsoleCtrlHandler) so closing a console window, signing off, or a system shutdown runs the daemon's real _shutdown() instead of Windows just ending the process — closing WebRTC sessions and any in-flight ffmpeg transcode instead of orphaning it. `taskkill /F` itself stays uncatchable (like SIGKILL), so autostart_run() now spawns with CREATE_NEW_PROCESS_GROUP instead of DETACHED_PROCESS and autostart_end() tries CTRL_BREAK_EVENT against the recorded pid first, falling back to the hard kill only if that doesn't stop it in time. - Replaced the Node page's two independent autostart/service-mode toggles with one "start automatically" select (off / at sign-in / as a background service). The old pair let both be active at once — starting the daemon twice, at boot and at sign-in — and their layout broke wrapping inside .node-service's flex row. The new control always removes whichever mechanism is active before installing the target; platform.py's service_install() does the same on the CLI side. The "background service" option disables itself (with a hint pointing at the CLI) when running unpackaged, since service-mode.ps1/service.ps1/firewall.ps1 all assume an installed build's layout — verified live rather than assumed by actually running those scripts unelevated. - findNodeBinary() no longer bakes a stray \r into resolved paths. Found by rebooting after enabling per-user autostart: where.exe listed two matches, and stdout.trim().split('\n')[0] only strips the whole string's ends, leaving line one's own trailing \r attached — which landed inside the Startup .vbs's quoted path and broke it with "Unterminated string constant" at boot. Fixed by splitting on \r?\n and trimming every line. - Dependency audit for the Windows installer (docs/WINDOWS-PORT.md): no VC++ Redistributable needed, confirmed by inspecting the built node-runtime's actual import table rather than assuming. New docs/windows-build.md: a concise clone-to-installer build guide. Co-Authored-By: Claude Sonnet 5