2486 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	72777119fd	fix(client/android): stop reporting every disconnect as a lost connection ... The stream watchdog polled a bare "has the session ended" boolean, so it had exactly one thing it could say and said it every time: "Connection lost — the host may be asleep. Wake it to reconnect." That ran when the player quit their game, when an operator ended the session from the console, and when they pressed Back themselves — telling them to go wake a host that was never asleep. It now reads the end reason. Only a connection that actually died gets that line, a host-side failure gets its own, and the three deliberate endings say nothing at all: leaving the stream is already the feedback, and a toast on top of it is just noise. A game launched from a library also returns to that library instead of host selection, which needs the intent hoisted out of the console shell: the stream replaces that shell in the composition, discarding the `remember`s holding its screen and host, so by the time the session ends there is nothing left to navigate back with. The parent holds it across the gap and the shell consumes it on the way in. The touch UI has no library — only the console shell does — so there it is the toast fix alone.	2026-08-06 14:30:59 +02:00
enricobuehler	81b4f76c4d	fix(client): a session ending on purpose stops reading as a failure ... The desktop clients turned every host-side close into "Host ended the session", and a reason string means "abnormal" to everything downstream: the GTK and Windows shells raised a banner, the console overlay drew a status strip. Quitting a game you launched yourself produced all of that. Now only a host error or a lost connection carries a message; the deliberate endings return the silence those shells already give a clean exit, which is also what puts the console back in its library with nothing in the way. The Apple client gains the same distinction. It had one line for every ending — "Session ended by <host>." — which is fine for an operator stopping the session and wrong for a link that died, so each now says what happened. A game exiting stays silent and returns to the library it was launched from. Both read the reason while the connection is still up, because tearing it down is what makes it unreadable, and both fall back to their previous wording when there is no verdict — an older core, or a close that raced the read — rather than inventing a new one for a case they cannot see.	2026-08-06 14:30:46 +02:00
enricobuehler	ec44496285	feat(client): tell clients WHY a session ended, not just that it did ... A session ending was a single bit. A player quitting their game, an operator ending the session from the console, a stop the client itself asked for, a host crashing and a Wi-Fi drop all arrived as the same "closed" — so every client had to write one message covering all of them, and every client picked an error. That is how quitting your own game came to be reported as trouble on all three. The information was already there and thrown away: the host closes with APP_EXITED when a launched game exits, with 0 when it ends the session cleanly and 1 when it fails, and a link that simply dies never closes at all. The connection watcher now classifies that into a PunktfunkEndReason — local, game exited, host ended, host error, lost — and latches it before the shutdown flag, since the two are read by different threads and the reason must never arrive second. Exposed as punktfunk_connection_end_reason. This replaces the game-exited flag added a moment ago rather than joining it: that question is one row of this table, and it was never released. Still additive to any embedder that ignores it, and the host sends the same bytes either way, so the wire is untouched. `is_normal()` is the question nearly every caller actually has, so both the Rust and C surfaces answer it directly rather than making each client re-derive which of five values are worth alarming a user about.	2026-08-06 14:30:33 +02:00
enricobuehler	d4dd5f7a3d	feat(client): a game exiting takes you back to its library ... Quit a game you launched from a host's library and the stream ended with "Session ended by <host>." on the host-selection screen — an error report for something you had just done on purpose, and several taps away from starting the next title. The host has always said what happened: it closes the connection with APP_EXITED when the game it launched for a session exits, and that code's own documentation describes this feature. Nothing ever read it — a search across every client found zero consumers. (It also could not reach anyone until the previous commit, since the close only happens once the lease declares the game gone.) The core now records the reason as it observes the close, latched before the shutdown flag because different threads watch the two, and exposes it as punktfunk_connection_game_exited. Purely additive: a client that never asks behaves exactly as before, the host sends identical bytes, and the wire version is untouched — ABI 17. The Apple client asks while the connection is still up, then treats a game exit as the normal finish it is: no error banner, and if the session began as a library launch it reopens that library so the next title is one tap away. Any other ending — a stop, the host going away, network loss — is unchanged. The other clients keep their existing end-of-session behaviour; the call is there when they want it.	2026-08-06 13:58:57 +02:00
enricobuehler	ea762b849d	fix(client/ios): Escape stays in the game instead of freeing the pointer ... Pressing Escape mid-stream on an iPad handed the mouse back to iPadOS: the captured cursor was swapped for the system one and the game stopped receiving relative motion, so aiming died until you clicked back in. Two previous attempts treated that release as unavoidable and built recovery around it — a re-lock burst, then a click that re-asks. Both came back from the field unchanged, because both fought the release after it had already happened, inside the cooldown the platform applies straight after its own "let me out" gesture. The release was never unavoidable. This app had no UIKit key handling at all: every key arrives on the GameController path, which is a parallel HID feed that does not consume the UIKit event, and the only thing that ever became first responder was the video view, and only to summon the soft keyboard. So every hardware Escape reached UIKit unclaimed — and an unclaimed key press is precisely what lets the system apply its own default for that key. Apps that read a hardware keyboard the ordinary way consume the event as a side effect and never see this. So claim it. The stream controller becomes first responder while capture is engaged and takes Escape in pressesBegan/pressesEnded, passing every other press to super untouched. Escape still reaches the host on the GameController path, so in-game menus open exactly as before; only the system's own interpretation is suppressed. Scoped to captured input, so Escape keeps dismissing sheets and leaving full screen whenever the stream doesn't own the keyboard, and the deliberate ways out are untouched — Cmd-Escape and Ctrl-Opt-Shift-Q are read off the same GameController path and clear capture themselves. The recovery path stays as a backstop and is retimed to match what was measured: the old burst spent its entire budget within ~0.6 s of the drop, i.e. wholly inside the cooldown, where the answer can only be no. Retries now continue at 1.2 s and 2.4 s, and quietly — they don't hide the cursor or mute pointer motion the way the burst does, so a longer recovery costs nothing when it fails.	2026-08-06 13:58:41 +02:00
enricobuehler	76e8bd1b98	fix(host/gamelease): a game that exited stops counting as running ... When a launched game's processes are all gone, the watcher asks one last out-of-band question before ending the session: does the launcher still think the game is up? On Windows that reads Steam's per-app `Running` registry flag. It was only ever meant to be a tie-breaker for a scan that momentarily can't see the game — a launcher re-execing, an engine relaunching itself into a new pid. It had no bound. Honouring the flag reset the confirm window every pass, so a flag Steam left set — it does that whenever it doesn't cleanly observe the exit: it crashed, it was closed first, the game re-parented — pinned the lease in `running` for the life of the host. The console kept showing the game, `session_on_game_exit` never fired, and the only way to get the stream back was a manual "End". Reported from the field on Windows 0.24.0. `steam_running_hint` also believes the FIRST hive that says so, so a stale flag in any loaded profile was enough. The absence timer now keeps running instead of being reset, and that is what bounds it: past `VETO_LIMIT` (30 s) with nothing of the game on the box, the launcher's opinion is stale rather than early and the session ends anyway, logged at WARN so it is visible. Ending a moment early is the cheaper failure — the stream drops while the game lives, the user reconnects, and nothing is ever killed. Ending never was the bug. The rule is now a pure `exit_confirmed(gone_for, hint_running)` with a test. The watch loop polls a live process table and can't be unit-tested, which is exactly how an unbounded veto shipped unnoticed.	2026-08-06 13:58:24 +02:00
enricobuehler	35ba64ca0f	Merge pull request 'fix(flatpak): Deck HDR works on a plain install' (#64) from worktree-deck-hdr-wsi-env into main ... Reviewed-on: #64	2026-08-05 22:21:51 +00:00
enricobuehler	5f71aeb024	feat(flatpak): vendor the gamescope WSI layer so Deck HDR works on a plain install ... HDR on a Deck needed a manual second step nobody took: flatpak install --user flathub org.freedesktop.Platform.VulkanLayer.gamescope//25.08 documented only in a comment in this file. Build the layer ourselves instead, so a plain `flatpak install` is all it takes. The layer is genuinely required, not legacy. Measured on SteamOS 3.8.16 (gamescope 3.16.23.4): the gamescope-0 socket advertises gamescope_swapchain_factory_v2 but NOT wp_color_manager_v1, with HDR both off and on — so Mesa's Wayland WSI has no colour-management protocol to negotiate HDR10 through, and this layer is the only thing that can append the ST.2084 surface formats. Removing the extension gives zero [Gamescope WSI] lines and hdr10_format=None. Vendored rather than declared via add-extensions autodownload: the extension is 94 MB of whole-gamescope for one 4 MB .so, its layer JSON hardcodes a /usr library_path that an app-scoped extension mounted under /app would not satisfy, and it would make flathub a hard install-time dependency of an app we self-host on flatpak.unom.io. enable_gamescope=false skips subdir('src') and every compositor dependency, so only protocol/ and layer/ build. buildsystem is simple rather than meson because glm and stb ship no meson.build of their own - the wraps' patch_directory supplies it, and without that copy configure dies with "Subproject exists but has no meson.build file". meson generates the layer JSON from prefix+libdir, so it self-writes library_path=/app/lib/... into /app/share/vulkan/implicit_layer.d, which XDG_DATA_DIRS already covers. VK_ADD_IMPLICIT_LAYER_PATH is therefore dropped - keeping it would also risk double-loading two same-named layers for anyone who still has the flathub extension installed. Pinned to the same gamescope rev as packaging/gamescope/PKGBUILD so the client's layer and the host's punktfunk-gamescope come from one tree. Verified on a Deck OLED: builds offline (--wrap-mode=nodownload) in org.gnome.Sdk//50, and the resulting .so drives the Deck's system gamescope to "hdr formats exposed to client: true" with hdr10_format=Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT). Still user-side, and not fixable in packaging: gamescope's hdr_enabled convar (Steam's HDR display setting) must be on.	2026-08-06 00:15:16 +02:00
enricobuehler	e1adc5d6d7	fix(flatpak): export GAMESCOPE_WAYLAND_DISPLAY so the Deck actually gets HDR ... The gamescope WSI layer decides whether to engage from one signal: isRunningUnderGamescope() reads $GAMESCOPE_WAYLAND_DISPLAY and nothing else. flatpak does not forward host env into the sandbox, so it arrived unset and the layer's CreateInstance early-returned before creating a GamescopeInstance — no gamescope surface, so the HDR10/ST.2084 formats were never appended and the surface stayed SDR. The layer still loads and still logs its generic bits in that state, so it reads as working. It is not: the three settings already here (layer search path, ENABLE_GAMESCOPE_WSI, the socket bind) all sit downstream of this gate and buy nothing without it. Measured on a Deck OLED (Galileo, SteamOS 3.8.16), client --browse, reading "swapchain config": unset -> no [Gamescope WSI] Surface state block, None set, hdr_enabled=0 -> server hdr output enabled: false, None set, hdr_enabled=1 -> hdr formats exposed to client: true, Some(A2B10G10R10_UNORM_PACK32, HDR10_ST2084_EXT) Matches the field report of "HDR->SDR" in the stats overlay on a correct HDR host. DXVK_HDR was ruled out by measurement. The remaining gate (gamescope's hdr_enabled convar = Steam's HDR display setting) is a user-side step, not a packaging one.	2026-08-05 23:59:45 +02:00
enricobuehler	76a271b97a	Merge pull request 'Worktree decky brand name' (#63) from worktree-decky-brand-name into main ... Reviewed-on: #63	2026-08-05 21:41:17 +00:00
enricobuehler	b53568c99f	fix(decky): a host saved under its own IP now shows the name it advertises ... The panel captioned most rows with an IP address. The saved records were the source: `hosts add` falls back to the address when the pairing path knew nothing better, so `name` is literally "192.168.1.21" — and `mergeHosts` took `s.name || s.addr` unconditionally. The fallback only ever fired for an EMPTY name, so a name that was already a copy of the address sailed through as if it were meaningful, and the row printed the address twice: once as its title, once as its subtitle. The friendly name was in hand the whole time. The row is built by joining the saved record to the live advert, and that advert carries the host's actual hostname — the join was already trusted for address, port, online and OS, and only the name was read from the saved side alone. So treat a name equal to the record's own address as the placeholder it is and yield to the advert. A real saved name still wins, even when stale: it may be one the user chose, and an advert must never silently overwrite it. The comparison is against the SAVED address, so a host that moved DHCP lease still recognises its old address as a placeholder rather than mistaking it for a chosen name. Checked against the Deck that reported this, over its actual store and browse: three online rows turn into home-worker-5, ENRICOS-DESKTOP and steamdeck, the four offline ones keep their address (nothing is advertising a better name for them yet), and a user-chosen name survives a conflicting advert.	2026-08-05 23:37:18 +02:00
enricobuehler	db0637928b	fix(decky): the shortcut liveness guard answered "alive" for every appId ... `shortcutStillExists()` extracted the store method before calling it: const get = appStore?.GetAppOverviewByAppID; return get(appId) != null; `GetAppOverviewByAppID` reads the store's own state (`this.m_mapApps`), so the unbound call throws on the lost `this` — and the function's own `catch { return true }` swallowed it. The guard therefore returned "still exists" for EVERY appId. Not a stale-data bug: it never once answered no. Everything downstream of it was consequently inert. A dangling appId — the documented hazard this guard exists to catch, since the id outlives the shortcut in Steam's CEF localStorage across a plugin reinstall — was never dropped, so `ensureGamepadUiShortcut` always took the reuse branch and `SetShortcut*`'d a dead id (silent no-ops). The visible library entry never came back, `recreateShortcuts` reported success having done nothing (its toast only checks for a non-null appId, and the dead one is non-null), and "Open Punktfunk" ran `RunGame` on the dead id — Steam answers that with "Game configuration unavailable". Call it as a method so `this` survives, and guard the global with `typeof` first: `appStore` is Steam-injected, and a bare reference to a missing one is a ReferenceError that optional chaining does not prevent — which would have landed in the same catch. Verified against the live Deck that hit this: evaluated both versions over its actual appIds, and where the old guard says alive/alive, the fixed one says alive for the live stream shortcut and dead for the dangling UI id — so the stale key now drops and the entry is recreated on the next mount.	2026-08-05 23:33:25 +02:00
enricobuehler	22bc81238d	fix(decky): Decky's plugin list says "Punktfunk", not "punktfunk" ... The label Decky shows for an installed plugin is plugin.json "name", which we had set to the lowercase directory name — so the one place every user sees the plugin listed was the one place it was off-brand, while the panel header (titleView) already read "Punktfunk". The two were conflated because the name looked load-bearing: the zip's top-level dir becomes ~/homebrew/plugins/<dir>, and the scripts derived that dir FROM plugin.json "name". They are in fact independent — Decky extracts the zip as-is and locates an installed plugin by MATCHING plugin.json "name", never by folder name (that is how a plugin can live in DeckWebBrowser/ and list itself as "Web Browser"). So brand-case the label and pin the on-disk dir to the literal `punktfunk` in package.sh/deploy.sh/CI instead of deriving it. Pinning is the part that matters: had the dir followed the label, this rename would have installed a second `Punktfunk/` folder beside the existing `punktfunk/` and the plugin would have shown up twice. The self-update call passes the name Decky uninstalls before extracting, so it moves to "Punktfunk" with it. The upgrade INTO this build still passes "punktfunk" (the installed build's own value), which matches that build's plugin.json — so the old folder is removed and the new zip lands in the same lowercase dir either way. Decky's per-plugin settings dir is unused (all state lives in ~/.config/punktfunk), so nothing is stranded.	2026-08-05 23:20:28 +02:00
enricobuehler	de6b9e94ec	Merge pull request 'fix(client/windows): settings persist when the app isn't installed on C:' (#62) from worktree-client-msix-persist into main ... Reviewed-on: #62	2026-08-05 20:53:38 +00:00
enricobuehler	5ebe840320	fix(client/windows): settings persist when the app isn't installed on C: ... Reported from the field (2026-08-05): a fresh Windows 11 box with a data partition, "New apps will save to: D:", and the client installed there. It launches, finds hosts and streams — but no setting and no profile survives a restart. Reinstalling to C: fixes it completely. The reporter's read was "it's in read-only mode", and that is almost exactly right. The one clue that localises it: the client creates its mTLS identity with a plain `fs::write` on first run and hard-exits if that fails. Their app started, so ordinary file creation in the config directory works. Only the config stores were being lost — and those are the three files that go through `write_atomic`, which writes a sibling temp and renames it over the target. The rename is what breaks. The client ships as a full-trust MSIX package, so its `%APPDATA%` writes are redirected into the package container. When the package lives on a secondary drive, Windows keeps that redirected state on the package's own volume: `C:\Users\<u>\AppData\Local\Packages\<pfn>\` stays a real directory on C:, but its children (LocalCache, RoamingState, …) are junctions to `D:\WpSystem\<SID>\…`. Both sides of our rename still spell `C:\Users\…`, so nothing looks unusual, but they can resolve across that junction boundary — and `std::fs::rename` is `MoveFileExW` with `MOVEFILE_REPLACE_EXISTING` and *not* `MOVEFILE_COPY_ALLOWED`, so a cross-volume move fails outright rather than degrading to a copy. Creating files still works, which is why everything else about the install looks healthy. So the fix is not to make the rename work — it is to stop treating it as the only way to persist. `write_atomic` now falls back to writing the target in place when the atomic route fails. That is the same operation the identity files already use, and those demonstrably round-trip on the affected installs, so the fallback lands on a path we know resolves. It trades crash-atomicity for exactly the writes that would otherwise be lost, and nowhere else: temp+rename stays the normal route everywhere it works. Writing into a redirected location cannot desync from reading it — Microsoft documents one private-location-first resolution order for both, so whichever layer a write lands in is the layer the next read finds. The fallback verifies anyway, by reading the bytes straight back: a write that reports success and disappears is precisely the bug being fixed, so this path does not get to claim success on an `Ok(())` alone. It costs nothing normally — it only runs on an install that has already shown it does something unusual. Two things this uncovered on the way: The temp file was a single shared `<name>.json.tmp`, but these stores have five whole-file writers (WinUI shell, session, console UI, CLI, Decky). Two saving at once collide on it — on Windows the second write hits a sharing violation, and worse, one process can rename the other's half-written bytes over the target. The scratch path now carries the pid. And none of this was visible to anyone. Every save on this page is fire-and-forget by design (a failed settings write must never take a stream down), so ~15 call sites discard the error and the UI cheerfully shows the toggle you just moved. The reporter had no log file to send either, because "Open log folder" was handing out a phantom path — a separate bug, already fixed in f3c0ee47 but not in the 0.24.0 they were running. `store_health` records the last persistence failure centrally, and Settings shows an error bar naming the path when the store is refusing writes, so a client that cannot save says so instead of pretending. `update.rs` had hand-rolled the same temp+rename inline, so it neither cleaned up its temp on a failed rename nor picks up the fallback; it now goes through the one writer. The update floor silently never rising is how a declined update comes back forever. Deliberately NOT done: disabling MSIX AppData virtualization in the manifest (`desktop6:FileSystemWriteVirtualization`). It would stop the redirection at the source, but every existing packaged install's settings, profiles and pairings live inside the container today — turning it off points the client at an empty real `%APPDATA%` and silently resets all of them. That needs a migration, not a manifest flag. Also considered and not taken: resolving the destination directory with `GetFinalPathNameByHandleW` and creating the temp inside the resolved path, to keep atomicity. It does not reliably close this hole — when the target file exists only in the unvirtualized layer while its directory resolves to the private one, the rename still straddles the boundary — and it would rest on canonicalisation behaving through the redirection, which we have never verified on a packaged run. Verified on the RTX box (.173, Windows 11 26200), which is the platform that actually has these rename semantics: `cargo fmt --all --check`, the full `pf-client-core` lib suite (109 passed), and clippy `-D warnings --all-targets` on both `pf-client-core` and `punktfunk-client-windows` — all clean. Also green under linux/amd64 (116 passed). Three new tests: the pid-scoped scratch path, the fallback actually persisting and reading back when the atomic route is blocked, and a genuinely unwritable store surfacing its error instead of swallowing it. The mechanism above is established from documentation and third-party reports, not from a reproduction on a second-drive install — that box does not exist here. The fix does not depend on the diagnosis being exactly right: it repairs any install where the rename fails but a direct write succeeds.	2026-08-05 22:33:36 +02:00
enricobuehler	4b1ce6b905	Merge pull request 'fix(android/hud): stop charging the compositor's wait to the stream' (#61) from worktree-android-hud-os-floor into main ... Reviewed-on: #61	2026-08-05 20:31:46 +00:00
enricobuehler	a11c672bea	fix(android/hud): stop charging the compositor's wait to the stream ... The Android HUD headlined `capture→displayed` with SurfaceFlinger's latch and scanout inside it — pipeline depth no client can pace under. The usual Android streaming overlays stop measuring at decode-complete, so users comparing overlays read our honesty as latency: on a 60 Hz panel that floor alone clears 30 ms, more than everything those overlays display put together. Exclude it, the way the Apple clients have since the presentation rebuild (8a40e467): shave the measured floor off the shown display and end-to-end at every tier, and name what came off in Detailed as `os present +N excluded (display pipeline minimum)`. The equation still tiles the headline, because the `display` term is shaved by the same amount. The floor is the `latch` p50 we already measure (release→OnFrameRendered), not a modelled 2/refresh: it moves with the panel rate, tunnelled playback and the vendor's low-latency mode, and it exists on every render path (the release stamp is parked on all three), so it does not depend on the timeline presenter being active. Unmeasured reads 0.0 and nothing is shaved — we exclude only what we actually measured. With the floor out, the `display` term is already just `pace`, so the `(pace + latch)` split now renders only on a window where no latch sample paired, and the hardcoded 2-refresh Apple-equivalence twin is gone with it. Raw numbers are untouched in the 1 Hz `pf.present` logcat line, so HUD-off A/Bs and cross-session comparisons still read unshaved values.	2026-08-05 22:28:43 +02:00
enricobuehler	cbd0e9664d	Merge pull request 'fix(ci): builder-image pushes authenticate, and :latest stops being a tag anyone can move' (#60) from worktree-security-h6-registry-auth into main ... Reviewed-on: #60	2026-08-05 20:11:17 +00:00
enricobuehler	66df1624b6	Merge pull request 'Library scanners become plugins — the bridge half (host, wire, kit, console, packaging)' (#59) from worktree-library-plugins into main ... Reviewed-on: #59	2026-08-05 19:58:44 +00:00
enricobuehler	6f07bd94d3	feat(library): launcher tiles a plugin can actually publish ... Design D4 promised entries that open the LAUNCHER — Steam Big Picture, Heroic, Lutris — and the plumbing for it landed in M2/M4: the `role` field, the `steam_ui` kind, the console's Launchers rail. But nothing could flow through it for anything except Steam. D4 said the other launchers would ride the `command` kind. The 2026-08-05 review then made `launch.kind = "command"` operator-only (it is handed to a shell), so a plugin publishing one is refused with a 403. The two changes are individually right and jointly leave a hole: `steam_ui` was the only launcher kind a plugin could publish, so a Heroic or Lutris tile was unreachable. New `launcher_ui` kind, valued by store id. One kind rather than one per store because every launcher except Steam has exactly a single UI to open; Steam keeps its own kind because it genuinely has two. D1 is preserved — the plugin names a launcher, the host builds the command, and no shell string crosses the wire: heroic -> the same native-or-Flatpak resolution the `heroic` game kind uses, minus --no-gui and minus the URI, so the window itself opens lutris -> bare `lutris`, which opens the window (the URI form is `lutris_id`) Platform-gated to what this host can actually resolve, and validated INBOUND: a value naming a launcher this OS cannot open is a 400 the plugin author can act on, not a tile that silently does nothing when a user clicks it. Windows launchers (Epic, GOG Galaxy, Xbox app) are deliberately absent — each needs its own verified activation and a guess would ship exactly that dead tile. Also closes a WP4.3 item I under-delivered and did not flag: the console's add/edit form had no way to mark an entry as a launcher, so even hand-adding one was impossible. It now has the checkbox — and `formFrom` round-trips it, without which editing a launcher entry would silently demote it to a game, which is the precise bug that file's own comment warns about. Gates on .21: punktfunk-host 435 passed / 0 failed (two new), workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift green. Console: orval + paraglide regen, tsc clean, check-i18n at 604 messages for en + de. Still unproven on hardware: no launcher tile has been clicked on a real host. The steam plugin (the first to emit one) is not built yet.	2026-08-05 21:12:19 +02:00
enricobuehler	d2085879da	Merge main: plugin art rides THROUGH the H-2 confinement, not around it ... PR #58 hardened the art proxy in the same three files this branch rewrote, and the two changes pull in opposite directions: #58 narrowed what the host will read from disk, while WP1.2 widened what counts as a local art path so an extracted scanner's covers can be served at all. Resolved so the widening goes through the gate rather than beside it. Kept from #58, unchanged: art_path_is_confined (UNC refusal, canonicalize-or- refuse, config-dir exclusion, roots check), the image-extension whitelist, sniff_image_type, validate_art_paths as write-time validation, the AuthLane privileged-field check on every entry in a reconcile payload, and the launch redaction in GET /library. Three reconciliations: * `local_art_bytes` converts a `file://` value to a path BEFORE calling art_path_is_servable, so the confinement check and the read see the same path. Ordering is the point: percent-decoding happens before canonicalization, so a `%2e%2e` escape cannot hide from the traversal check. Pinned by a test. * `art_roots()` gains $HOME on POSIX. This is the one that would have bitten silently: the list was empty on non-Windows, which was correct while is_local_art_path was Windows-shaped (Playnite is Windows-only, so nothing on a POSIX host was ever classified as local art and the confinement had nothing to confine). Once WP1.2 classifies POSIX paths as local, an empty root list is not "secure by default" — it serves NO plugin art on Linux, which is every cover the lutris and steam plugins emit. $HOME is the exact analogue of the Windows users base #58 already ships, and covers Steam's librarycache and grid overrides, Lutris's coverart/banners (both copies), Heroic's caches and all the Flatpak variants. It is not the load-bearing control: a value still needs an image extension, must canonicalize to a real regular file inside a root and outside the config dir, and must CONTAIN image bytes. * The two tests that both wanted to mutate PUNKTFUNK_LIBRARY_ART_ROOTS became one. Cargo runs tests as parallel threads of a single process, so two tests setting the same env var race. The `file://` and confinement assertions moved into #58's existing confined test; what remains of the WP1.2 test is the pure classification/rewrite half, which touches neither env nor filesystem. Also: `steam_ui` was missing from the list of host-resolved launch kinds in privileged_field's doc comment and in the 403 a plugin sees. Prose only — the check is a denylist (prep, launch.kind = "command"), so steam_ui was never actually refused — but a plugin author reading that error would have concluded otherwise. Gates on .21: punktfunk-host 433 passed / 0 failed (including #58's H-2 tests and the new file:// ones), full workspace tests clean, workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green.	2026-08-05 19:59:11 +02:00
enricobuehler	19f637ea6e	fix(ci): builder-image pushes authenticate, and :latest stops being a tag anyone can move ... Second half of security-review-2026-08-05 H-6. The infra half (unom/infra, runners/ci-core/) split the LAN registry in two: :5010 serves GET/HEAD only and refuses everything else with 405, :5011 demands basic auth on every request including the /v2/ ping. Both fronts sit on one store, and a registry keys by repository name rather than by the host:port the client used, so an image pushed to :5011 is the identical image every consumer pulls from :5010. So: builds tag the write port, a docker login precedes the push, and the release-tag manifest PUTs authenticate. Consumers are untouched — every `container:` in every other workflow still pulls anonymously from :5010, and ci/rust-ci-arm64cross.Dockerfile's `FROM 192.168.1.58:5010/...` still resolves. Not doing the digest pinning the review asked for, deliberately, and the header says why at length. Once pushes are authenticated, the people who can overwrite a tag are exactly the people who can push to main and edit a pinned digest in this file — a pin defends against nobody it did not already trust, and costs a two-commit dance on every ci/ change (~3x a month) during which consumers run a builder image predating the change they are testing. What does close the residual gap is making :latest a checked function of the tree. reconcile-latest.sh asserts on every run that :latest and :ck-$KEY are the same digest, re-points it when they are not, and warns loudly. An out-of-band overwrite is caught on the next push to main with no churn, and it fixes a pre-existing bug on the side: reverting ci/ used to leave :latest on the newer build forever, because the older key is a cache hit and nothing re-pointed it. Repair rather than fail, because a legitimate revert must not red-line main. Verified against the live registry from a runner host with the real docker client: unauthenticated push denied, push to :5010 refused 405, authenticated push to :5011 accepted, that same image pulled back anonymously from :5010. reconcile-latest.sh exercised over all three cases (diverged -> repaired, already equal -> no-op, missing key -> exit 1). All seven builder images are consistent with their content keys today, so the new step is a silent no-op on its first real run.	2026-08-05 19:52:19 +02:00
enricobuehler	4a0d0ce587	Merge pull request 'The plugin lane stops being a way in — 37 of the 38 security-review findings' (#58) from worktree-security-review-0805-fixes into main ... Reviewed-on: #58	2026-08-05 17:39:02 +00:00
enricobuehler	0d94ef0dbe	fix(host/mgmt): the field gate returns the refusal, not an error carrying it ... `check_entry_fields` returned `Result<(), Response>`, which trips `clippy::result_large_err` under CI's `-D warnings`: an axum `Response` is 128 bytes and it was riding in the `Err` variant. `Option<Response>` is the shape this always wanted. There is no error value to propagate here — the "error" IS the response the handler sends back — so `None` means "the payload may proceed" and `Some(r)` is the refusal to return. The call sites read the same, one word different. Caught by CI, not by me: I ran `cargo check` and not `cargo clippy -D warnings`.	2026-08-05 19:14:19 +02:00
enricobuehler	a1b8627e70	feat(plugin-kit): the lutris pilot as a worked example, and the export gap it found ... Writing a real scanner against the kit before six repos get cut from it, rather than after. It is the lutris pilot (M5/WP5.1) — the smallest of the six and the one that exercises the POSIX local-art path end to end. It earned its keep immediately: withReadOnlyDb / openReadOnly were never exported from the parsers barrel, so the single most distinctive thing the lutris plugin needs was unreachable from @punktfunk/plugin-kit/library. Nothing caught that, because nothing had consumed the public surface yet. It also caught a vacuous green in this package: tsconfig's include was ["src","test"], so anything under examples/ type-checked as a no-op. `examples` is now in the check scope; tsconfig.build.json still narrows to src and package.json still ships only dist + README, so nothing new is published (verified against the built dist). The example carries two deliberate departures from the Rust original, both documented inline: art is emitted as file:// URLs instead of inlined data: URLs (the host proxies the bytes, so the payload stays small — inlining covers is what blew the 2 MB body limit at 49 titles during the playnite work, and is exactly why the POSIX art path exists), and the untrusted-slug guard is carried over verbatim, since the slug comes from Lutris's own database and is interpolated into a path the host will later be asked to serve. What it demonstrates, which is the reason one-repo-per-plugin is safe: everything below `scan` is store-specific parsing, and everything else — store claim, sync engine, launcher entries, __config, console registration, and the CLI verbs including the parity gate — comes from defineLibraryPlugin. plugin-kit: tsc clean (now including examples), 56 tests pass, build clean. plugin-kit-v0.3.0	2026-08-05 18:54:47 +02:00
enricobuehler	91fa32fbb6	feat(plugin-kit): the parity gate moves into the kit, so plugins can be one repo each ... One plugin = one repo, matching the house pattern (playnite, rom-manager and virtualhere are already each their own repo with their own biome/bunfig/tsconfig /CI). The implementation plan's WP5.0 had proposed a single workspace repo for all six library scanners; this is the piece that makes the split cost nothing. Everything the six scanners share is already published rather than adjacent: the parsers and defineLibraryPlugin live in @punktfunk/plugin-kit/library, so repo boundaries are irrelevant to them. Fixtures are not shared in practice either — the Rust scanners build theirs inline in code, there are no fixture files, and the one genuinely cross-plugin builder (binary shortcuts.vdf) is already in this package's own tests. A pga.db fixture is useless to the epic plugin. The parity harness was the exception: generic across all six, and parked in the shared repo the plan assumed. It moves here. What it is: the acceptance gate for an extracted scanner. Ported unit tests pin the PARSERS; they do not prove the plugin reproduces the scanner it replaces. A plugin that parses perfectly and emits steam:440.0 instead of steam:440 breaks every Moonlight pin on the host and no parser test notices. punktfunk-plugin-steam parity --snapshot before.json # host on its built-in punktfunk-plugin-steam parity --compare before.json # offline; exits non-zero --compare runs the plugin's own scan rather than requiring it to be installed first, so a mismatch is visible before anything is published and the run is repeatable while you fix it. Three judgement calls in the diff, each pinned by a test: * art is compared by PRESENCE, not value. The representation legitimately changes on extraction (a host-relative proxy path or inlined data: URL becomes a file:// path or a CDN URL), so comparing values would fail every run for no reason. Losing an art kind fails; gaining one does not. * launcher entries (role: "launcher") are reported separately instead of as unexpected extras — the built-in scanner had no concept of them, so they can never be in a baseline. An ORDINARY title the scanner never had still fails, which is what catches a bad tool filter. * absent and empty are the same thing in metadata: the host omits empty lists and nulls, so a plugin sending genres: [] has not changed anything. plugin-kit: tsc clean, 56 tests pass (10 new).	2026-08-05 18:52:38 +02:00
enricobuehler	defdfbdb58	fix(security): plugin UIs get their own origin ... Closes H-3 of the 2026-08-05 review, the last of its six highs. A plugin's interface was reverse-proxied onto the console's own origin and framed with `allow-same-origin`, so plugin JS ran as first-party code on that origin: one `fetch('/api/**', {credentials:'same-origin'})` and the BFF attached the operator's ADMIN bearer. That reached everything `plugin_may_access` withholds — arm pairing, read the host PIN, approve a device, read `/hooks`. The "open in new tab" link was the same escalation with no iframe involved at all. The fix is not a sandbox attribute, and it is worth writing down why, because the obvious change is the one that does not work. Dropping `allow-same-origin` gives the frame an OPAQUE origin; its subresource requests are then cross-site; the `SameSite=Lax` session cookie stops being sent; every plugin asset 302s to /login and the frame is blank. Nothing about the new-tab link is helped either. So the origin moves instead. A second listener on its own port (default PORT + 1) serves plugin UIs and nothing else: different ORIGIN — scheme+host+PORT — so the same-origin policy separates the plugin from the console: it cannot read the console's DOM, its cross-origin fetch of /api/** is unreadable (no CORS) and cannot mutate (Sec-Fetch-Site sees same-site). same SITE — cookie scope ignores the port and SameSite is computed on the site, so the session cookie still reaches the plugin listener and plugin pages keep working. Enforcement is two refusals and both are load-bearing: the console origin refuses /plugin-ui/**, and the plugin origin refuses everything ELSE — above all /api/**, which would otherwise hand the admin bearer right back to plugin JS that is now same-origin with that listener. Both are unconditional: if the plugin port cannot be bound, plugin UIs are DISABLED and the console says so, rather than falling back to the arrangement this exists to remove. Two consequences that would otherwise bite in the field: The port has to be open. Done for the Windows netsh rule, the firewalld service and the ufw profile. A browser stores a self-signed-certificate exception per ORIGIN, including the port — and a certificate interstitial can never be shown inside an iframe, so the frame would just sit blank with nothing on screen explaining why. A `no-cors` probe distinguishes it (a TLS failure rejects; any HTTP answer, even 401, resolves) and the console renders a card linking the operator to open the port once in a real tab. Also here: the health probe moved server-side to the console origin (it used to rely on being same-origin with the plugin), the postMessage listener now verifies `event.origin` — a real check rather than a tautology — and plugin-kit's `postMessage(..., "*")` is documented as load-bearing, since narrowing it to `location.origin` would now target the plugin's own origin and silently drop every message. Verified against a running console with a fake mgmt API and a fake plugin: console /plugin-ui/** → 404; plugin-origin /api/v1/hooks, /, /login, /_auth/logout → 404; plugin page loads 200 through its own origin; unauthenticated plugin origin → 401 (not a redirect to a /login it does not serve); a forged x-pf-listener header changes nothing on either listener; the plugin's own Clear-Site-Data / Access-Control-Allow-Origin / Set-Cookie are dropped by the proxy allowlist; the plugin origin's CSP names the console as its only frame-ancestors source; and with the port squatted, ui-config reports `unavailable`, the console still refuses /plugin-ui/**, and the console itself keeps working. Still wants on-glass confirmation in a real browser — the cookie and framing behaviour is reasoned from spec, not observed. cargo fmt --all --check clean; cargo check -p punktfunk-host --all-targets green on Windows; web console builds and typechecks.	2026-08-05 17:50:04 +02:00
enricobuehler	8103958169	fix(security): the plugin lane stops being a way in ... Acts on the 2026-08-05 host security review. 36 of its 38 findings; the two exceptions are recorded below and in the review doc. The review's headline is that `plugin_may_access` was the one authorization gate in the system that was allow-by-default — a hand-maintained denylist of route prefixes, where every sibling gate is deny-by-default. Its own doc comment names the two capabilities it exists to withhold, and both were reachable one route over, because ~1450 commits of new routes were added and the list was never one of the things anyone remembered to update. So the gate is now an allowlist, and a test walks the live route table and fails the build for any route that has not been deliberately classified for both non-admin lanes. That test is the actual fix: it is what stops the next route from arriving pre-authorized. Route reachability and field authority turned out to be different questions. A provider plugin has to be able to reconcile its own library entries — that is what a scanner plugin IS — but `prep` and a `command` launch inside that payload are handed to `/bin/sh -c` as the host user, and every execution site documents them as operator-typed. Requests now carry the lane that authorized them, and those two fields are refused to everyone but the operator's own token. The art proxy read any absolute path off disk in the host process, which on Windows is LocalSystem, from a path the plugin lane could write and then read back — so it yielded `mgmt-token`, which is full admin. It now serves only real images (extension AND magic bytes, so a renamed secret fails), only from inside an allowed root, only after canonicalization, and never over UNC; and a path it would refuse to serve can no longer be persisted in the first place. On Windows, the config-dir hardening was skipped exactly when it was needed — it ran only in the branch that CREATES host.env, so the case it was written for (a local user pre-created the directory and planted one) was the one case it never ran in. It is now unconditional and first, an existing host.env is re-owned, and the inheritable OWNER RIGHTS ACE that kept an attacker's files theirs after the directory was re-owned is gone. The identity and token readers were hardening the directory only on the path that GENERATED a new secret, so a planted cert/key or token was adopted verbatim and permanently; they harden before the first read now. `ensure_admin_only_source` is implemented. The 2026-07-05 audit recorded it as FIXED and it was in no commit in this repository's history — the local EoP it described was live, and it is the payload half of the config-dir chain above. Also: the three input planes are bounded and lossy like the mic plane on the same loop already was; Android's library client no longer accepts any publicly-trusted certificate for the pinned host; the usbip vhci nodes get their own group instead of riding on `input`, which every packaging scriptlet tells users to join; a registry URL can no longer inject a TOML table into bunfig.toml; the pairing cooldown is charged before the arming state is read, so armed/disarmed is no longer a free oracle; and the whole Low tier, of which the two worth naming are a clipboard MIME NUL that panicked the host on one control message, and an unauthenticated global logout that let any LAN peer sign the operator out on a loop. NOT fixed, deliberately: H-3 (plugin UIs framed allow-same-origin). Dropping allow-same-origin does not work: the document's origin goes opaque, its subresource requests are then cross-site, the SameSite=Lax session cookie is not sent, and every plugin asset 302s to /login. The "open in new tab" link is the same escalation with no iframe at all, so the sandbox attribute is not where this gets fixed either. It needs a second listener — a distinct origin that is still the same site — which changes the console's deploy model and wants on-glass validation. The mechanism and the dead end are written down at the iframe. H-6 registry authentication, whose other half lives in unom/infra. The in-repo halves are done: workflow_dispatch inputs no longer interpolate into run: blocks (one of them in the step holding UPDATE_MANIFEST_KEY), and the syft installer is pinned to its tag instead of main. Digest pinning is left until the registry is authenticated, because a tag — content-keyed or not — can simply be overwritten while anonymous pushes are accepted. M-5 is half done: the oracle is closed, but binding the arming window needs the console to learn the fingerprint first, which is a knock-then-bind flow rather than an edit. Verified: cargo fmt --all --check clean; cargo check --all-targets green on Linux and on Windows (confirmed non-vacuous — a planted type error in windows/install.rs fails the build); scripts/xcheck.sh windows check green; cargo test -p punktfunk-host --bins 416 passed, the single failure being gamestream::stream::tests::sender_delivers_batches, the known qemu-environmental UDP-loopback flake that fails identically on clean main in the same container; cargo test -p pf-clipboard 13 passed; web console typechecks.	2026-08-05 17:12:12 +02:00
enricobuehler	ce8f3e9eaf	feat(packaging): the plugin runner becomes a default component ... WP6.1 of design/library-scanner-plugins-implementation-plan.md. The library is a flagship surface and cannot depend on an opt-in subsystem (design D9, closing G9): once the scanners are plugins, a host whose runner is off comes up with an empty library and no obvious reason why. The security posture for on-by-default was already built and shipped — LocalService on Windows, a sandboxed systemd --user unit on Linux, the scoped plugin-token lane. Windows (.iss): the PunktfunkScripting task is registered ENABLED and started on a FRESH install, and left to the existing restore path on an upgrade. The distinction is a new TaskExists probe taken before StopBunRuntimes disables anything — TaskEnabled alone cannot tell a fresh install from an operator who deliberately turned the runner off, and defaulting to "on" would silently switch it back on for them. deb/rpm: `systemctl --global enable` from the postinst/%post, guarded to first install only so an upgrade never undoes a mask. `--global` because a maintainer script has no user session to act on, and it is the only mechanism that makes a --user unit on-by-default for everyone. sysext: RPM scriptlets never run from a sysext image, so the enablement symlink is baked in directly (/usr/lib/systemd/user/default.target.wants/). Without it the runner would ship present-but-off on exactly the platform where an operator is least likely to go looking for it. Opt-out throughout is `systemctl --user mask punktfunk-scripting` — `mask`, not `disable`, since a plain disable cannot remove a symlink under /etc or /usr. The unit comment, both package descriptions, and the docs-site plugins page all say so; the page also gains the Windows equivalent. Not gated on hardware: none of this is verifiable from a Mac. The .iss change needs an installer run (fresh + upgrade, and an upgrade with the task deliberately disabled), and the deb/rpm/sysext changes need a package build.	2026-08-05 10:08:11 +02:00
enricobuehler	bd383f1820	feat(web): one Game sources surface, launcher rail, and the migration nudge ... M4 of design/library-scanner-plugins-implementation-plan.md, plus WP6.2. WP4.1 — SourceToggles and ProvidersCard merge into Library/Sources.tsx. They were two cards because they were two different things: scanners were compiled into the host, plugins were an afterthought. After the extraction they are the same thing — the host reports ONE list of sources whose ids match whether they came from a built-in scanner or the plugin replacing it — so one surface is both simpler and the only honest presentation. Each row carries its toggle, a running/stopped badge for plugin sources, an entry count, filter, settings and an uninstall that offers to remove the games too. An "Add a source" rail lists uncatalogued library plugins with a "Detected" badge; `detected` is deliberately tri-state, so only a POSITIVE probe badges — an entry with no probes for this platform is unknown, and calling that "not installed" would be a lie. The settings drawer (SourceSettings.tsx) renders a generic form from the plugin's own JSON Schema over GET/PUT /__config, through the existing session-gated /plugin-ui/<id>/ proxy — zero new host surface, and the browser never learns the plugin's port or secret. It flattens allOf branches (effect nests a checked schema's annotations there, so a form reading only the top level silently loses every title and default) and falls back to a JSON editor when any field is a shape it cannot express — partial rendering would be worse than none, because a field missing from the form is a setting the operator cannot change. WP4.2 — uiPlugins() now excludes category "library", which covers both the sidebar and the mobile overflow since they share the selector. The /plugins/$pluginId/$ route still resolves, so existing deep links keep working; library plugins are just not advertised. WP4.3 — LibraryGrid groups role:"launcher" entries into a rail above the grid, and the empty state points at the sources surface rather than leaving a bare grid (after extraction, "no games" is the expected first-run state). WP6.2 — a migration banner offering one install per still-built-in scanner whose plugin is catalogued. One button per scanner, never a single "migrate everything" and never a silent auto-install: installing code stays an explicit operator act, and per-scanner is what makes it safe to repeat (the claim suppresses the built-in idempotently, so a half-finished migration is a valid state). WP4.4 — i18n en+de (kept under the existing "Game sources" label rather than minting a third "Plugins"), Storybook stories for the sources card in three states, the launcher rail and the banner. Gates: orval regen, tsc clean, vite build clean, check-i18n green at 595 messages for both locales. Still owed: the browser click-through (the store's Tabs-theme bug shipped through green types and lint), and an AppShell nav story — that one needs the plugins query mocked, which does not exist in this Storybook setup yet.	2026-08-05 10:03:24 +02:00
enricobuehler	8728d90e01	feat(plugin-kit): the library-plugin framework — parsers, __config, defineLibraryPlugin ... M3 of design/library-scanner-plugins-implementation-plan.md. Target shape: a first-party scanner plugin is its parsers plus a scan function. WP3.1 — a parsers module under the new ./library subpath, porting what the six in-host scanners hand-rolled: text VDF/ACF, the BINARY shortcuts.vdf KeyValues walker with its CRC-32 appid derivation and the 64-bit rungameid composition, read-only SQLite (bun:sqlite, immutable=1 so a scan can never take a lock or spawn WAL sidecars next to a launcher's live database), a reg.exe wrapper, capped readers, the path-confinement join that keeps a crafted goggame-*.info from pointing a launch at an arbitrary program, Steam root/library discovery, art location helpers, and a fetch helper carrying the host's no-redirect anti-SSRF posture. Every parser is total: a missing launcher or a truncated file degrades to "no titles", never to a throw. Two deliberate departures from the Rust originals, both about the Windows runner's account: steam root discovery now also reads HKLM Valve\Steam InstallPath (a non-default install dir was previously uncovered), and the registry wrapper refuses HKCU outright — as LocalService that is not the operator's hive, so reading it would silently look like "not installed". WP3.2 — GET/PUT /__config on the kit's UI server, so a plugin with settings does not ship an SPA (closes G8). GET answers {schema, value}: the derived JSON Schema and the raw operator-authored config. PUT validates by decoding and only then persists RAW, so defaults are never baked into the file. The handler is split out as makeConfigHandler and driven directly in tests. WP3.3 — defineLibraryPlugin wires SyncEngine (poll + fs-watch + debounce), the store-claiming reconcile, launcher entries appended to every sync, a UI server serving only __config under category "library" (which keeps six installed scanners out of the console nav), and the standard detect/scan/uninstall CLI verbs. It warns ONCE when a pre-M2 host silently ignores the store claim — that degradation is otherwise invisible except as duplicated titles. M0/S2 is recorded here as a committed fixture rather than prose. Two findings the original spike missed because deriving a schema does not exercise it: withDecodingDefaultKey takes an Effect, not a thunk — a thunk type-checks, derives fine, and dies at decode time; and a checked schema (Schema.Int) nests its annotations under allOf, so a form must merge those branches. Both are pinned. plugin-kit: version 0.3.0, tsc clean, 46 tests pass (16 ported parser tests, 10 config/derivation). Publishing (WP3.4) is deferred — it needs a tag and a push.	2026-08-05 09:53:58 +02:00
enricobuehler	3d4a659959	feat(host,sdk,kit): store claims, launcher entries, and plugin sources on the wire ... M2 of design/library-scanner-plugins-implementation-plan.md. Everything a library scanner plugin needs is now expressible over the API; all additive. WP2.1/2.2 — store claims (D2). library.json gains a v2 shape ({entries, claims}) that loads the v1 bare array unchanged and is written on the first mutation. PUT /library/provider/{p}?store=<s> claims a store for a provider: its entries then surface with deterministic <store>:<external_id> ids and the store's own badge instead of opaque custom:<id> ones. That identity is the whole point — entry ids, GameStream FNV app ids, client art caches and Moonlight pins all survive a title moving from an in-host scanner to a plugin. One provider per store (409 otherwise); DELETE releases; an empty reconcile does NOT (a store can legitimately have zero titles). While a claim is held, all_games() skips the matching built-in scanner, so the two never double-list during the bridge. WP2.3 — DetectHint gains steam_appid and env_marker, the two store-derived signals the host used to read for itself. Without them a steam plugin's lease tracking would drop from reaper-exact to dir-prefix, and Heroic-under-Proton would lose the only signal that works. Malformed markers are dropped, not honoured — this feeds a path that can end processes. WP2.4/2.5 — role: game|launcher on the entry shapes (serde-default, skipped when default), and a steam_ui launch kind valued bigpicture|desktop that opens the Steam client itself. Validated inbound as well as at launch. WP2.6 — GET/PUT /library/scanners generalizes to SOURCES: built-in scanners minus claimed ones, plus claimed stores, plus any provider with entries. The same library-scanners.json disabled-set backs all of them and the ids match by construction, so a user's disabled state carries over verbatim through the whole migration. A disabled plugin source has its entries filtered at read time, exactly like a disabled scanner. WP2.7/2.8 — plugin registration gains a category field (the console keeps library plugins out of the nav); index entries gain categories and per-platform detect probes, evaluated existence-only into CatalogEntry.detected so the host never re-grows per-store knowledge. Index SCHEMA stays 1 — additive. WP2.9 — OpenAPI + SDK regenerated on Linux; kit wire widened (LaunchSpec.kind is now a plain string documented against the host's vocabulary — closes G3), and ProviderClient.reconcile takes an optional store and returns the host's echoed entries so a caller can detect a pre-M2 host silently ignoring the claim. Also fixes a bug the S3 spike turned up: is_steam_launch gated on a steam:// URI, so a steam_ui launcher entry would have skipped BOTH gamescope's --steam mode and the B1 single-instance free — on a box autologged into game mode, the nested second Steam would see the first and exit, crashing the spawn. It now tests the first token. Gates on .21: workspace tests green (punktfunk-host 425 passed), workspace clippy -D warnings clean, cargo fmt --all --check clean, OpenAPI drift test green. plugin-kit: tsc clean, 20 tests pass.	2026-08-05 09:39:31 +02:00
enricobuehler	a418d2852a	refactor(host/library): launch helpers into launch.rs, art proxy resolves any id ... M1 of design/library-scanner-plugins-implementation-plan.md — behavior-frozen groundwork for lifting the six scanners out into plugins. WP1.1: heroic_command/heroic_launch_prefix, epic_launch_uri, gog_spawn, valid_steam_appid and shortcut_gameid move into library/launch.rs with their unit tests. The scanner modules beside it now do enumeration only, so they can be deleted wholesale later without taking launch logic with them (D1). WP1.2: is_local_art_path accepts file:// (the plugin contract) and POSIX absolute paths, excluding the two /-leading shapes the host itself emits (its own /api/ proxy path and protocol-relative CDN URLs). local_art_bytes percent-decodes and converts a file:// value first. The art proxy and fetch_box_art resolve ANY id against library.json before the legacy steam: branch, so a plugin's entries serve art without the host knowing its store. No API change; no user-visible change.	2026-08-05 09:09:19 +02:00
enricobuehler	110ac9b663	Merge pull request 'fix(stall): T2 amplification kill — resume-edge pacing + ABR starved-window guard' (#53) from worktree-stall-ride-through into main	2026-08-05 06:35:30 +00:00
enricobuehler	1d6f4760f3	Merge branch 'main' into worktree-stall-ride-through	2026-08-05 06:22:41 +00:00
enricobuehler	9dfbc2f895	Merge pull request 'fix(client-core): pad-audio references the WASAPI module by its mounted name' (#57) from fix/pad-audio-wasapi-module-path into main	2026-08-05 06:22:31 +00:00
enricobuehler	56adb47026	fix(client-core): pad-audio references the WASAPI module by its mounted name ... The Windows build of pf-client-core has been red on main since the pad-audio merge (#23): pad_audio.rs calls `crate::audio_wasapi::device_by_id`, but lib.rs mounts audio_wasapi.rs AS `crate::audio` via the #[path] per-OS swap — the `audio_wasapi` module name never exists. Windows-gated call site, so every Linux leg stayed green while both `windows / build` targets failed E0433. One-line rename to the mounted path (+ the comment that pointed readers at the phantom name). Verification is the PR's own windows leg — the crate builds on no other platform this path compiles on.	2026-08-05 08:15:02 +02:00
enricobuehler	52a9d02355	Merge pull request 'fix(deps): close the undici, fast-uri, postcss and brace-expansion advisories' (#55) from worktree-audit-undici into main ... Reviewed-on: #55	2026-08-05 05:51:06 +00:00
enricobuehler	e5ca213339	fix(core/abr): a starved window is never a decode-knee sample ... Stall program T2 (amplification kill), the phantom-latch half. A deciding window that delivered under a quarter of the target rate (a host-side capture stall, an outage, a mid-window pause) carries starvation-shaped distress — a jump-to-live flush, a keyframe-ask burst — that the decode-cap latch read as decoder evidence: under a periodic capture stall (the RDNA4 standby-sink field cases, one stall every ~5 s) every edge offers another 'backoff' at the SAME rate, and one pair latches a phantom decoder knee at whatever rate the display driver happened to interrupt. The session then fights the cap's re-probe ladder (+12.5% per 16-128 clean windows) for minutes on a decoder that was never the problem. Starved windows still back off (real damage deserves the safe response) but take the same 'not a knee sample either way' arm as a draining backoff: they neither latch a decode cap nor erase the reference a genuine choke set, so a real knee's pair still finds itself around the interruption. The ¼ bar sits deliberately far under the ×¾ utilization bar climbs require. Gates: 44 abr tests green (2 new: the stall-cycle no-latch scenario and the reference-preservation scenario), full core lib suite 346 green (--features quic), fmt + clippy clean.	2026-08-05 00:28:25 +02:00
enricobuehler	e5416646f9	fix(host/send): a stall-resume frame paces at the proven rate instead of blasting ... Stall program T2 (amplification kill), the resume-burst half. The native pace budget was min(0.9 × time-to-deadline, overflow at ~3× stream rate) — for steady-state frames the rate term is smaller and decides, but for an OVERSIZED frame (a capture-stall resume carrying seconds of scene delta, a cold IDR) the deadline term clamped a multi-interval overflow into the remainder of ONE: an instantaneous many-×-stream-rate blast that overruns the socket tx-buffer and loses the very frame that would have ended the freeze. Field fingerprint across three RDNA4 standby-sink cases: WSAENOBUFS(10055) + loss_ppm spikes at stall edges, then a recovery-IDR round trip per retry while the client shows 'current bitrate 0.1'. The budget is now the overflow's wire time at the pace rate itself (send_pacing::native_budget, pure + unit-tested), bounded by an absolute 100 ms ceiling so a pathological frame can't park the send thread; the deadline stays a target, never a license to blast. Steady-state frames produce byte-identical schedules (the rate term already decided); PUNKTFUNK_PACE_FACTOR=0 keeps the legacy deadline-only spread; the GameStream plane's Moonlight-pinned schedule is untouched. Gates: host clippy --all-targets -D warnings + 9 send_pacing tests green (linux/amd64 container), fmt clean.	2026-08-05 00:28:13 +02:00
enricobuehler	b79d90b463	fix(deps): close the undici, fast-uri, postcss and brace-expansion advisories ... audit.yml's three blocking bun-audit legs (web, sdk, plugin-kit) were all red on main. Ten findings in sdk and plugin-kit, eight in web; every one of them a transitive dependency, none reachable by bumping a direct dep. web already carried the right mechanism — an `overrides` block whose `undici` and `fast-uri` pins had simply gone stale — so it needed four bumps, not a new idea: undici 7.28.0 -> ^7.29.0 and fast-uri 3.1.4 -> ^3.1.5 for the reported advisories, plus postcss ^8.5.10 -> ^8.5.25 and brace-expansion ^5.0.8 -> ^5.0.9 for two more that were published after the failing run and would have gone red on the next audit anyway. All four stay inside their current major. sdk and plugin-kit were harder and the fix deserves an explanation. Their single finding is undici 8.7.0/8.8.0 pulled in by @effect/platform-node, a devDependency pinned at 4.0.0-beta.98. That dependency already declares `undici: ^8.7.0`, which permits the fixed 8.10.0 — the vulnerable version survives purely as a stale lockfile resolution. Nothing bumps it in place: `bun update` only walks direct dependencies, `bun install --force` preserves a resolution that still satisfies its range, and every platform-node release through beta.103 declares the same `^8.7.0`, so moving the dep changes nothing. Bun rejects the scoped form outright ("Bun currently does not support nested resolutions"), so a flat `overrides` entry is the only mechanism available, and it necessarily also moves sdk's top-level undici from 7.x to 8.x. That is safe here, and was verified rather than assumed. The only source use is sdk/src/config.ts, which does `new Agent({ connect: { ca } })` behind a dynamic import and a try/catch with a documented plain-fetch fallback; `Agent` and its `connect` option are unchanged between undici 7 and 8. sdk typechecks and its 72 tests pass against 8.10.0; plugin-kit typechecks and its 20 tests pass. Both trees now dedupe to a single undici 8.10.0. Consumers are deliberately untouched: `overrides` apply only at the root of the tree that declares them and are not honored when the package is installed as a dependency, so sdk's published `optionalDependencies: { undici: "^7.0.0" }` is left alone — a consumer resolves the latest 7.x, which is the fixed 7.29.0. The override governs this repo's own tree, which is exactly what audit.yml checks. Worth knowing: sdk's dev tree therefore exercises undici 8 while consumers get 7. One trap found on the way. Running `bun install` over plugin-kit's existing lockfile emitted a lockfile with two byte-identical `@punktfunk/host` entries — its `file:../sdk` dependency crossed with the new override — and bun then refuses its own output with "Error loading lockfile: InvalidPackageKey". That reads as a tooling error rather than a finding, so it would have taken the audit gate down while looking like something else entirely. Regenerating the lockfile from scratch produces a valid single entry; all three lockfiles are checked for duplicate keys. Also worth recording, because it nearly shipped: deleting the pinned nested entry from a lockfile makes `bun audit` report "No vulnerabilities found" while the vulnerable copy is still installed on disk. bun audit reads the lockfile, not node_modules. That is a vacuous green, not a fix, and was rejected. Verified: `bun audit` clean in all three trees; web builds and typechecks (its typecheck needs the build first, which generates routeTree.gen); sdk 72/72 and plugin-kit 20/20 tests pass.	2026-08-05 00:22:25 +02:00
enricobuehler	8983ec04b9	Merge pull request 'feat(pad-audio): DualSense voice-coil haptics + speaker, host to client' (#23) from feat/android-pad-audio into main	2026-08-04 21:56:37 +00:00
enricobuehler	d27e62f7c9	fix(pad-audio): close the twelve findings the sweep left open on this branch ... Everything the 2026-08-03 haptics sweep filed against the pad-audio branch (P2 + P3). Four of them are the difference between a feature that works and one that fails silently. **B6 — nothing ever un-muted the coils.** Every rumble report asserts `HAPTICS_SELECT`, which is SDL's "disable audio haptics" bit: the firmware mutes the very voice coils the 0xD1 stream drives. No code anywhere cleared it again, so ONE rumble left tier-A haptics silent for the rest of that pad's life — no error, nothing in a log, and the host happily streaming into a muted actuator. `DsDevice.ds5AudioHapticsReport` is the documented undo (flag0 with both bits clear); written EP0-direct when the stream starts and again after a rumble stop while a stream is live, because the stop report re-mutes on its way past. **B10 — the desktop mix could reach a controller's coils.** Pad endpoints were filtered out inside `plan()` only. The watchdog, Follow mode and the parked default all go through `judge_default`, which classifies by NAME — and a pad endpoint is deliberately stamped "DualSense Wireless Controller" so games treat it as the pad's speaker. No name rule could ever catch one. It now refuses them by identity. **B27 — an out-of-range pad aliased onto a real slot.** The 0xCD plane's pad is the only u16 index and every consumer narrowed it with `as u8` on an assumption nothing enforced, so wire pad 256 steered pad 0's speaker volumes. Rejected at the decoder, which makes the narrowings lossless by construction. An existing test had pinned the bug in place, asserting that wire pad 513 round-trips; corrected, plus a test for the 256→0 alias specifically. **B7 — caps that arrived late were never announced.** The renderer commits the tier-A trade only once its sink opens, which is well past the arrival burst's two 100 ms ticks, and `set_pad_audio_caps` only stored an atomic. The client believed it had pad audio while the host emitted nothing. The input task now compares the live registry against what the last arrival actually carried and re-arms the burst itself — no new plumbing, and no extra traffic when nothing changed. The rest: `needs_aeb_kick` is finally ACTED on (R4) — a stored-but-not-served endpoint is declined rather than opened, because `AUTOCONVERTPCM` makes it succeed and mis-route; a failed provisioning no longer latches `PROVISIONED` for the process lifetime (R5), and `host_cap` retries, so a host that started while the audio stack was busy recovers at the next connect instead of the next reboot; the loopback init timeout reaps its thread instead of detaching one per ~2 s reopen (R6); kind-change restarts are bounded (R3) since the trigger is a client-sent arrival; the devtest uses the endpoint's real channel mask (B11) instead of letting wasapi derive 0x0F against the endpoint's 0x33; the render loop asks `is_session_ended()` rather than spinning at nice -16 (R12); short writes are counted and reported instead of dropping the tail in silence (R13); and a frame addressed to another pad is dropped before it can seed the gap tracker from a foreign sequence space (R14). Verified: punktfunk-host clippy -D warnings **0 on a real Windows box**; Linux/amd64 clippy 0 with **589 tests** (pf-client-core 114, pf-inject 101, punktfunk-client-android 20, punktfunk-core 345+1+8); Android :kit: tests + :app: compile green; fmt clean. Six punktfunk-host tests fail on that Windows box. FIVE fail identically on a tree with no pad-audio code at all (QUIC `Rejected(SetupFailed)` — the box's network environment); the sixth passes 3/3 in isolation and only failed under the parallel run, on a locally-bound ephemeral port. Neither is this change. Still owed: on-glass. This is a hardware feature and none of it has been on a real DualSense since the merge.	2026-08-04 23:55:47 +02:00
enricobuehler	0a72959ef7	Merge main into feat/android-pad-audio ... 86 commits of main, including the whole M1-M12 haptics sweep. Twelve conflicting files; three of them were more than textual. **The capability bits collided.** Both branches allocated the SAME wire bits for DIFFERENT features: `client_caps 0x04` and `host_caps 0x20` are redundant desktop audio on main and pad audio here. Merged naively, a peer would negotiate one and get the other. Pad audio moves to the next free bits — `CLIENT_CAP_PAD_AUDIO = 0x08`, `HOST_CAP_PAD_AUDIO = 0x40` — and the `abi.rs` mirrors move with them (their compile-time equality assertions caught the mismatch, which is exactly what they are for). **Both branches also claimed ABI v15.** Main's shipped (the rumble-policy floor), so the pad-audio surface becomes **v16**. **`native/input.rs` would have reintroduced a fixed bug.** This branch resets `rumble_seq[idx]` on pad removal; M1 established that the client's reorder gate is per-connection with no reset path, so restarting the host counter strands every later envelope until it climbs back. Took main's seq-preserving `clear_pad_feedback` and kept only the branch's `pad_streams.stop(idx)`. The rest: `wiring_plan::plan` now delegates to main's `plan_with_formats`, so the pad-endpoint filter moved into that body and the predicate behind it is factored out as `is_pad_render` (also what B10 needs); `Ds5Feedback::AUDIO` derives from main's `REPORT_ID_LEN` like its siblings; `AudioCtl` joins the explicitly-listed unhandled variants so the guard-false case is covered rather than swept up by a `_`; `include/punktfunk_core.h` regenerated rather than hand-merged.	2026-08-04 23:27:06 +02:00
enricobuehler	2d223274fc	Merge pull request 'refactor(haptics): one copy of each thing every rumble path was transcribing' (#51) from worktree-haptics-m12-dry into main	2026-08-04 21:11:49 +00:00
enricobuehler	92f617a989	Merge remote-tracking branch 'origin/main' into worktree-haptics-m12-dry ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/GamepadFeedback.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:11:22 +02:00
enricobuehler	2f071a9a93	Merge pull request 'fix(clients/settings): controller settings that can't do anything no longer look live' (#50) from worktree-haptics-m11-settings into main	2026-08-04 21:08:15 +00:00
enricobuehler	62d35bc4b6	Merge pull request 'fix(core/wire): a truncated trigger datagram stops cancelling the effect it should carry' (#45) from worktree-haptics-m10-wire into main	2026-08-04 21:07:54 +00:00
enricobuehler	5d06ef26ac	Merge pull request 'fix(feedback): the pad stops keeping a game's trigger effect after the stream ends' (#44) from worktree-haptics-m9-richfb into main	2026-08-04 21:07:35 +00:00
enricobuehler	fcf4076eb7	Merge remote-tracking branch 'origin/main' into worktree-haptics-m9-richfb ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/DsCapture.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:07:18 +02:00