116 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	f34f311c69	Merge pull request 'fix(brand): capitalize "Punktfunk" in user-facing text; name the legal copyright holder' (#81) from worktree-docs-title-casing into main ... Reviewed-on: #81	2026-08-06 21:33:33 +00:00
enricobuehler	b0ec759fad	fix(brand): capitalize "Punktfunk" in user-facing text ... The docs site's page title read "punktfunk docs". Fixed that and swept the rest of the tree for the same defect, capitalizing the brand wherever it is shown to a human and leaving it lowercase where it is a technical identifier (CLI/package names, `punktfunk://` scheme, PnP enumerator, TLS SNI, logcat tag, config paths, CMS tenant id). User-visible fixes: - docs-site: page title -> "Punktfunk Docs"; API reference title, meta description and the branded bar's aria-label; the BrandMark/Wordmark SVG accessible names (the web console already had these capitalized -- the docs site had drifted from it). - Android: six strings of live UI copy -- the local-network permission dialog (x2), the connect-screen error banner, and the no-controller explainer. - Apple: the "No Hosts" empty-state text and the fallback display name for a host that advertises no instance name. - Windows client: the `--discover` progress line. - KWin fake-input: the application name passed to `authenticate()` (the grant is cached per-exe, so the string is display-only). - THIRD-PARTY-NOTICES: fixed in both generators (about.hbs and gen-third-party-notices.py) and applied to the three checked-in outputs so they match what a regeneration now produces. Every changed line differs from the original only by letter case, so line lengths are unchanged and no formatter width rule is affected. `cargo fmt --all --check` passes.	2026-08-06 23:10:25 +02:00
enricobuehler	185a69c806	fix(web/plugins): a plugin's interface loads again, instead of an empty panel ... Two separate things had to be wrong for this, and both were. The frame's own policy locked it out. Plugin UIs moved to their own origin so a plugin cannot act as the logged-in operator, and the plugin origin names the console as the only page allowed to frame it. It built that name from the incoming request — but Nitro hands the app a synthetic request with no TLS socket, so an HTTPS console reads back as `http:`. The header said `frame-ancestors http://host:47992` while the operator was on `https://host:47992`, and the browser refused the frame outright (ERR_BLOCKED_BY_RESPONSE). Nothing on screen said so; the reason was only in devtools. The scheme now comes from the listener's own TLS state, stamped at bind time, with x-forwarded-proto winning when something in front terminated TLS for us — the one case where the browser's scheme is not ours. And the port was shut. 47993 was added to the firewall definitions, but an already-open firewall does not pick a new port up: ufw expands an app profile into rules when you allow it and keeps those, so editing the profile on upgrade changes nothing, and firewalld needs a reload. Every upgraded Linux host kept a 47992-only rule, silently. The packages now notice on upgrade and print the one command that fixes it, without touching the running firewall. The NixOS module and the container image never learned the port at all; both now open it. Also: the console no longer mounts the frame while it is still checking whether that origin is reachable. A firewalled port drops rather than refuses, so the check hangs for the browser's whole connect timeout, and mounting meanwhile is exactly the empty panel with no explanation. The card that follows now names both causes it can be — an untrusted certificate for that port, or a closed one — because from a browser the two are indistinguishable. The rule is now a pure function with tests, since its failure mode is a well-formed header that only a browser rejects. Verified on glass against home-worker-5 (.21) and its ROM Manager plugin: the frame was refused before, renders the plugin's UI after.	2026-08-06 22:33:57 +02: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	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	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	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	b31495bea5	fix(host): a leftover Sunshine folder is not a conflict, and a crashed host gives the screen back ... Three things a field report (Discord, upgrade from 0.1x) turned up, all on the Windows host. 1. "It thinks I have Sunshine/Apollo running." It didn't — they were uninstalled. Both uninstallers leave their config/log directory in Program Files behind, and `detect.rs` counted a bare directory, or a service registered at ANY start type (including `disabled`), as a live conflict. The installer's own probe was narrowed to "service start type <= 2" after exactly this cried wolf on a `winget install`, and the tray dropped its always-on warning for the same reason in 3e782852 — the runtime probe never got the same treatment, so the one surface the user actually looks at kept shouting. `Evidence::is_active` now draws the line (running, or set to start on its own) and only active detections reach the startup warning, the `detect-conflicts` exit code, and `/local/summary`. Dormant findings still print in the full report, under a heading that says they need no action — that report is where "why does it think I have Apollo?" gets answered. 2. The console's conflicts card hardcoded "Another game-streaming server is **running** on this machine" regardless of what was found, so a dormant leftover was announced as a running server. It now says "active", and each entry names the observation — `Sunshine (running)`, `Apollo (starts automatically)`. 3. "The exclusive screen never times out going back to re-enabling the display." `isolate_displays_ccd` deactivates the operator's panels and hands the pre-isolate topology to the caller, which restores it at teardown — but that snapshot is PROCESS MEMORY, and Windows deliberately never saves the isolated topology to the CCD database. So a host that crashed, was killed, or was stopped mid-session left the desk dark with nothing in the product to undo it. There was one startup recovery leg already, but only for the EXPERIMENTAL `pnp_disable_monitors` axis, which is off by default — the default Exclusive path had none. `isolate_journal` now marks what an isolate is about to switch off (before the apply, so dying mid-apply is covered), clears the mark on restore, and force-EXTENDs at host startup if a mark survived. EXTEND rather than replaying the saved blob: the blob pins the virtual display's target id, which dies with the crashed host, so a replay would mostly fail BAD_CONFIGURATION into the very same backstop `restore_displays_ccd` already keeps — and EXTEND stays correct across a reboot, where saved ids would be stale.	2026-08-04 22:34:33 +02:00
enricobuehlerandClaude Opus 5	365caa23be	fix(plugins): plugin output reaches the console's log page, and /tmp is no longer hidden from the runner ... A user could not get the VirtualHere plugin to use their VirtualHere client and asked, reasonably, where the logs were. There was no good answer, and the reason they were stuck turned out to be ours. **The runner could not see /tmp.** `punktfunk-scripting.service` set PrivateTmp=yes, which hands the unit a private tmpfs. But integrating with things already running on the box is the entire job of a plugin, and on Linux those talk over /tmp: VirtualHere's client IPC is the FIFO pair /tmp/vhclient + /tmp/vhclient_response, X11 is /tmp/.X11-unix. So the plugin launched the vendor binary happily and could then never reach the daemon behind it — while the same command worked perfectly in the operator's own shell, because that shell has the real /tmp. No config change could fix it, which is exactly the loop the report described. PrivateTmp is now off, with /tmp added to ReadWritePaths (which ProtectSystem=strict would otherwise make read-only). **Plugin logs now land in the console.** Plugins are not host child processes — the runner is a separate bun process that import()s each plugin in-process — so nothing they print passed through the host's tracing, and the console's Logs page could not show a single plugin line. The fallback was journalctl on Linux; on Windows the runner's scheduled task writes no log file at all, so a failing plugin was diagnosable only by stopping the task and re-running the runner by hand. Both mean shell access on the host box, which is what the console exists to avoid — and it left the one question a stuck user asks with no answer. So the runner now tees its output to POST /api/v1/plugins/logs, and those lines join the host's own ring under one cursor, targeted plugin:<name>. The console grows a Host/Plugins switch beside the level filter; an empty Plugins view says the thing that is actually usually wrong (the runner isn't running) rather than "adjust the filter". The shipper keeps stdout authoritative — journald and foreground output are unchanged whatever the host is doing — and is built so that logging can never hurt the thing being logged: it never throws into a caller, holds a bounded queue that drops oldest and then says how many, backs off when the host is away (a restart is normal), and re-sends a batch the host failed to take. Lines logged while a POST is in flight are kept, which cost one round to get right: the first version held its recursion guard across the await and silently dropped exactly the lines a busy plugin produces. Runner lines that report a failure (a refused unit file, a crashed plugin, a give-up) now go out at warn/error instead of all arriving as INFO, so the console's level filter means something for them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:47:51 +02:00
enricobuehlerandClaude Opus 5	0985726415	fix(host,web): an empty update channel stops looking like a broken host ... A channel nobody has published to answers `manifest.json` with a 404, and the check reported that the same way it reports a dead registry or a bad signature: "Last check failed: feed returned HTTP 404". Every host on the stable channel shows it today, because the stable manifest only publishes when someone dispatches `announce` for a release tag — so the first thing an operator sees from the new Updates card is a red failure caused by nothing being wrong. The shared checker now distinguishes the two. `feed::fetch_manifest_blocking` returns a typed `FeedError` instead of a string, and only a 404 on the manifest ITSELF becomes `NotPublished` — a 404 on the detached signature still fails loudly, because that is the half-published pair the manifest-then-signature upload order can produce, and it must stay fail-closed. The host carries that through as `UpdateStatus.not_published`, mutually exclusive with `last_error`. It is benign only while no manifest has ever been seen for the channel: once a check has succeeded, the same 404 means the feed LOST a document it used to serve, which stays an error. The console then shows a plain sentence naming the channel instead of the failure banner, and "None published yet" rather than "Not checked yet". The Linux client makes the same distinction but deliberately NOT the same choice: `--check-update` keeps exiting 1 and keeps `error` set, because its consumer is a shell script and an empty channel is the absence of evidence that this build is current — not a confirmation that it is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:37:56 +02:00
enricobuehlerandClaude Opus 5	ff190e9825	fix(web): the logs filter row stops touching the card's edge on desktop ... Found on glass. The logs card has no CardHeader, so it puts the top padding back itself — but only at one breakpoint. `CardContent` is `p-4 pt-0 sm:p-6 sm:pt-0`, and tailwind-merge resolves conflicts only within the same variant: a bare `pt-6` cancels `pt-0` and leaves `sm:pt-0` standing. Measured on .173: 24px of top padding at 420px wide, 0px at 1280px, with the level filters and the search box sitting flush against the card border. It is the same trap `components/ui/card.tsx` documents for `p-0` — a variant cancelling its unprefixed counterpart and nothing else — just in the other direction, so the note now points both ways. This card was the only offender. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	f66de3eba4	fix(web): close the last two high-severity items from the closeout audit ... **The streamed-screen pin could still be clobbered by three other write paths.** Deferring it to the server's value on Save fixed the reported sequence but not the general case: the draft is only re-seeded while it is CLEAN, so once there is an unsaved edit its `capture_monitor` is frozen at whatever it was before the operator used the picker — and `applyAxis` (which spreads the last saved policy), the built-in preset switch and the custom-preset apply all put that stale value back. Every write path reads `serverCaptureMonitor()` now; no path spreads the draft's copy. **The session⇄game grace input had no accessible name.** That card has its own `Field` and only DisplayCard's was fixed, so the number input was still announced as an unnamed spin button. Same treatment: `htmlFor`/`id` for the single control, `fieldset`/`legend` for the two button groups. Verified in a browser — zero inputs without an accessible name across the Displays page. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	f2e1b9872c	fix(web): four "fixes" from this branch that did not actually fix anything ... A verification pass re-read every finding from the original sweep against the code on this branch rather than against the commit messages. It found that four of them were still broken, two because the edit I made was inert. Commit messages claim; code decides. - **The Storybook typecheck was never on.** `tsconfig.json` listed `.storybook` as a bare directory name, and tsc silently skips dot-prefixed directories in that form — so the entry typechecked nothing at all. Proved it by planting `export const __probe: string = 1` in `.storybook/preview.tsx` and watching `bun run lint` pass. `.storybook/**/*` is what actually pulls it in; the same probe now fails as it should. - **The Moonlight stale-PIN reset was a no-op.** `submit.reset()` sat at the top of `onSubmit`, immediately before `submit.mutate(...)` — which moves the status to pending in the same update, so it cleared a flag that was already changing. The green "PIN sent" note therefore still greeted the next pairing attempt over an empty PIN box. It now resets on the transition that actually matters: `pin_pending` going false → true. - **The session⇄game controls had the enforcement flag inverted**, and I never touched it. `enforced.length === 0 || …` reads an EMPTY list as "this build enforces everything", when the contract says the opposite in as many words: "Empty on a platform with no launch path (macOS), so the console can say so instead of offering a switch that does nothing". On exactly the platform the flag exists for, every control stayed live and reported success for an axis the host would never act on. Absent still means "assume it acts" — that is the compatible reading for an older host, and a different case from present-empty. - **Logout stopped revoking after a restart.** The epoch was a module-level counter starting at 1, so it revoked within one process run and then reset — and since the seal key derives from the stable mgmt token, a cookie captured before a restart unsealed fine and was accepted again for the rest of its 7-day TTL. One service restart undid the whole fix. It persists next to the host's config now. Verified: log out, restart the console, the captured cookie still 401s, a fresh login still works. Two more the pass rated as partial, both worth closing: - The plugin-UI response filter was a denylist of four header names, so `Clear-Site-Data` sailed through — a plugin error page could wipe `pf_session` and sign the operator out of the console, on our own origin, because the iframe is same-origin by design. It is an allowlist now; a plugin-supplied CSP, `X-Frame-Options` or CORS header no longer speaks for us either. - A half-configured TLS setup now refuses to start instead of logging a warning and serving anyway. Neither shape can work — one path missing puts the login password on the LAN in the clear, and PUNKTFUNK_UI_SECURE without TLS marks the cookie Secure so the browser drops it and login can never stick. Exiting with a reason beats a console that looks fine and is not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	dc57aa653c	feat(web): the console can say what just happened, and hand a phone the way in ... **Recent activity.** The console could describe the present — a status snapshot — but never the recent past. A client that connected and left while you were on another page left no trace anywhere you could look, and the host's own log is a developer artifact rather than a narrative. The event stream was already open for cache invalidation, so a feed costs one ring buffer next to it: every frame is recorded, labelled per kind, and rendered newest-first on the dashboard. Deliberately in-memory and bounded to 200. It starts empty on a page load and fills as things happen, which is the honest shape for a live tail — an audit trail would need the host to keep one, and pretending otherwise would be worse than not having it. **Connect a device.** The console knew the host's address and identity all along and never offered either in a form you could hand to a phone: pairing meant reading an IP off the Host page and retyping it on a couch. There is a card now with the address and a `punktfunk://connect/<uniqueid>` deep link, both copyable — the link is the shipped client grammar (clients/shared/deeplink-vectors.json), so an installed client opens straight onto this host. No QR: rendering one needs an encoder we do not bundle, and a wrong QR is worse than none. **Installable.** A web manifest and the theme/apple meta tags, so the console can live on a phone's home screen — which is where it is used from as often as from a desk. No service worker on purpose: an offline shell for a console whose every screen is live host state would only ever show stale numbers convincingly. The manifest is reachable without a session (install needs it, and it says nothing the login page doesn't); /api stays gated, verified. Verified in a browser: three host-emitted events appear in the feed with the right labels, the deep link renders and copies as `punktfunk://connect/abc123`, and the manifest serves 200 as application/manifest+json while /api/v1/host still answers 401. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	b8f603c8a1	feat(web): the numbers behind "it's slow to start" and a way to clean up after a plugin ... Three things the host already reports and the console never showed. **Stream diagnostics.** `RuntimeStatus.stream` has carried the session bring-up time, the last mid-stream resize cost, the client's FEC parity floor and the packet size for as long as the endpoint has existed, and the dashboard showed none of them. So "it takes ages to start" and "it hitches when I change resolution" had no number attached anywhere in the console — you had to take a stats capture to see a value the status endpoint was already returning. The two timings are native-plane only and null until the first frame lands, so each appears once it means something. **Loss and FEC recovery while the capture runs.** The health chart existed but only in the saved-recording view, which is backwards: dropped frames and FEC recovery are what you watch a live capture for. It now sits under the latency and throughput charts on the live card, keeping the GameStream caveat (only `frames` is instrumented on that plane). **Provider-owned library entries.** A plugin can sync entries into the library, and the host then refuses to edit or delete them one at a time — correct, and completely opaque once the plugin is gone: its games sit in the library with no console-side way to remove them. `DELETE /library/provider/{provider}` is the documented clean-uninstall path and nothing called it. There is a card now that names each provider, counts what it owns, filters the grid to it, and removes its entries in one go. Also: the dashboard's PIN tile really does say "Waiting"/"None" now. The earlier commit added the strings but the edit that was supposed to use them silently did not apply, so the tile still rendered a bare "●". Caught by auditing every message key for a call site — the other 543 are wired. Verified in a browser: the providers card shows, counts, and filtering hides non-provider entries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	0751265105	fix(web): editing a library entry warns before it wipes what the console cannot see ... `PUT /library/custom/{id}` replaces the whole entry — the host assigns `slot.prep = input.prep` and `slot.detect = input.detect` outright (library/custom.rs). But `GET /library` returns a `GameEntry`, which carries neither field, so the console builds its payload from a read model that has already lost them. Editing a title to fix a typo silently cleared any prep/undo commands and detection hints the entry had. The console cannot round-trip what the read API will not tell it, so this is a warning, not a fix: the edit form now says plainly that saving replaces the entry and that anything configured outside the console will be cleared. The actual fix is host-side — expose `detect` and `prep` on the library read model — and is noted in the code where it belongs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	b9b0df349d	fix(web): the charts stop lying about time, and logging out logs you out ... The stats charts drew every sample as an evenly-spaced slot, because recharts defaults to a category axis. A capture that idled for two minutes rendered that gap as a single step — so the one view you open specifically to find where the time went was the view least able to show it. All three charts use a numeric time axis now, so the spacing is the elapsed time. They also joined samples across a session boundary into one continuous line, implying a continuity that never existed: the stream stopped and somebody else started a new one. A capture is split at each `session_id` change now. And the live card plotted the whole capture-so-far every 2 s, re-serialising and re-plotting an unbounded series for a capture left running all evening; it plots a bounded tail and says so, with the full series still in the saved recording. Logging out only deleted the browser's copy of the cookie. The session is stateless, so a value captured beforehand — a shared machine, a shell history, a TLS-inspecting proxy — stayed valid for its full 7-day TTL and there was nothing the operator could do about it. Sessions carry an epoch now and logging out bumps it, which invalidates every cookie issued so far. Verified end to end: a captured cookie works, survives nothing across a logout, and a fresh login still works. The rest: - The update card could not show its own timeout warning. It was suppressed by a `job` field read from the last snapshot — which, when the host has gone away mid-job, is exactly the case the warning exists for. Nothing ever cleared the applying state either, so the card waited forever with no way out; there is a button now. "Check now" also surfaces the host's 429 instead of looking dead. - A running install survives a reload: the job id lived only in component state, so refreshing lost sight of an install that was still running while the Install buttons stayed armed against a host that answers 409. The host keeps the list — ask it. - An all-sources-failed catalog said "no plugins available". That is a successful request carrying nothing, not an empty store; it names the sources that failed. - The Installed tab rendered "vundefined" for a plugin with no recorded version (nullable in the contract, typed required here). - The Displays "In effect" badges were computed from the local draft, so they restated the operator's unsaved edits back to them as though the host had adopted them. They read the API's `effective` now. A failed background poll no longer replaces a form someone is editing, and leaving the page with unsaved edits prompts — the old `beforeunload` guard never fired for in-app navigation, which is how you actually leave. - Enter or Space on a preset's rename/update/delete icon applied the preset instead of running the action: keydown bubbled to the card. - Dates follow the console's locale, not the browser's. The dashboard's PIN-pending tile says "Waiting"/"None" instead of "●"/"—". - The Bun entry warns when TLS is half-configured, or when PUNKTFUNK_UI_SECURE is set without it — both of which silently break login. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	de17ceb8f8	fix(web): a newly installed plugin shows up on its own, and the display form can be used without a mouse ... Installing a plugin left the sidebar unchanged until a reload. The reason is timing, not caching: the host restarts the scripting runner AFTER the job reports done, and the plugin only registers its UI once that comes back — several seconds later, by which point the one-shot invalidation had already run and found the old list. The nav then waited out the 30 s idle poll, which in practice meant "until I reloaded". Anything that changes the installed set now switches the directory to a 2 s poll for a minute, so the entry lands about a second after the plugin actually comes up. Measured end to end in a browser: 29 s → 7 s, with the plugin registering at 6 s. The plugin entries also never animated. They are rendered outside the `motion.nav` that carries the variants and the stagger, so they inherited neither and simply appeared — most visibly in exactly the case above, where one shows up in a nav that is already on screen. They get their own animation container now, matching the main nav. (A motion-wrapped div around the link, not `motion(Link)`, which erases TanStack's typed `params`.) The accessibility pass on the display form, where the console's densest controls live: - The Custom block's numeric inputs had a `<label>` with no `htmlFor` next to an `<input>` with no `id`, which labels nothing at all — a screen reader announced them as unnamed spin buttons. Single controls are paired properly now; the button groups became real `<fieldset>`/`<legend>`, which is what they are. - Every option group signalled its active choice with fill colour alone. They carry `aria-pressed` now, so the state is available to assistive tech and not only to people who can compare two button variants. - `QueryState`'s error branch is a live region, so a query that fails announces the failure instead of silently swapping one region for another. - Motion honours `prefers-reduced-motion` instead of overriding it. - `<html lang>` follows the locale instead of claiming "en" while the app renders German. Verified: switching to de flips the attribute. - "Close menu", "Language" and "Loading" went through the message catalogue. Also: ten dead message keys removed (a whole removed Clients page and the old Settings token field), and the README no longer tells operators to set the management token under "Settings → API token" — that field is gone and the token has been server-side only for some time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	9e505aba41	fix(web): the console stops swallowing the host's answer when it says no ... The host writes genuinely useful refusals — "entry is owned by provider `x`, update it through its reconcile" — and a dozen call sites threw them away. The pattern was always one of two: a mutation whose `error` nothing rendered, or an `await mutateAsync(...)` with no catch, which additionally produced an unhandled rejection. Either way the operator clicked, nothing visible happened, and the thing they asked for silently hadn't. Fixed at each site, with the host's own message shown where there is one: - Adding or editing a library entry kept the form open and said why, instead of closing it as if it had saved and taking the typing with it. Deleting one reports the refusal rather than leaving the card sitting there. - The GPU preference, capture start/stop, recording delete and download, and the dashboard's stop-session / request-keyframe / end-game all report failure. The failed capture STOP is the one that mattered most: it is "stop & save", so a swallowed error meant minutes of recording vanished with nothing on screen. - The recordings Download had a comment claiming the detail view surfaces its errors. It only does that for the selected row, and Download is on every row. Two related fixes in the same area: - `apiFetch` no longer navigates to /login synchronously from inside whichever call noticed a 401 — very often a background poll the user never started. Tearing the page down mid-render took unsaved editing state with it, which the Displays page explicitly models. It defers a beat and coalesces, so a burst of parallel 401s schedules one navigation. - The plugin liveness probe treated the auth gate's 302 → /login → 200 HTML as a healthy plugin, and rendered the console's own login page inside the plugin's iframe. It also gave up permanently on the first failed probe, so the runner restart at the end of every install threw away whatever was open in another plugin. It rejects the redirect and keeps probing on a slower beat while down. `apiErrorMessage` moves out of the display card into src/lib/errors.ts, since half the console needs it now. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	4a5d4b0a71	feat(web): the console follows the host's events instead of asking ten times a minute ... The host has published every lifecycle transition on GET /api/v1/events since the API existed — client connect/disconnect, session and stream start/end, pairing decisions, display create/release, library, store and plugin changes — and nothing consumed a byte of it. The console instead polled ten endpoints on 1-5 s timers, so a change was up to 5 s stale and two pages could disagree while you looked at them. The Library page polled not at all: install a game in Steam and it never appeared until a full reload. The console now subscribes once and invalidates exactly the queries an event affects. Events never carry data into the cache — they only say "this is stale" — so an unknown future kind costs nothing and a missed event degrades to the polling that is still there underneath, now at a slow safety-net interval. The fast ticks that remain are the ones events cannot express: the live stream numbers while streaming, and a lingering display's teardown countdown. Four things had to be true for this to work, and none of them were. Each was found by measuring, not by reading: - Nitro's `localFetch` accumulates the response and only builds it when the handler returns, so nothing streams through the deployed Bun server. Three frames sent a second apart arrived together, three seconds late, when the upstream closed — and an SSE stream never closes, so nothing would ever have arrived. /api/v1/events gets its own route that hands back a web Response wrapping the upstream stream, which passes straight through. - Hydration mounts the app shell and discards it ~15 ms later. A subscription owned by that effect opened, closed, and never came back. It is a refcounted module singleton now, with a grace period so a remount re-attaches instead of reconnecting. - `getRouter()` runs more than once in the browser, and each call built its own QueryClient. The subscription held the first, the live pages read the second, and every invalidation went to a cache nobody was reading. One client per browser session; the server still gets a fresh one per request, which it must. - `invalidateQueries` only refetches queries that currently have an observer. An event means the HOST changed, so every cached copy is wrong whether or not something is watching it. Two features fall out of the same work: - **Automation** — a page for GET/PUT /api/v1/hooks. The host has run these hooks all along and the console never showed them, so the only way to see what your machine does when a stream starts was to open the config file. Writing one means writing a shell command the host will execute, so saving re-asks for the console password, like an update or an unreviewed install. - The Host page warns when another Moonlight-compatible server (Sunshine, Apollo) is running on the same machine. The host has detected this at startup for ages and reported it in /local/summary; nothing surfaced it. It is the most common reason a host looks installed and working but no client can reach it. Verified in a real browser against a mock host: three events drive three refetches of a query with no polling timer, the conflicts card names the intruder, the hook list and its dialog render, and the console reports no errors. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	55e01c1460	fix(web): stop shipping 7 MB of sound the console cannot play ... `@unom/ui/button` reaches `sound/defaults.js`, which resolves two game-UI sprite sheets with `new URL(…, import.meta.url)` at module scope — a 4.8 MB .wav and a 2.2 MB .mp3. Vite emitted both into the build, so they rode into the Windows installer and the .deb. The console never mounts UnomProviders, so no player is bundled and not one byte of it could ever be played. A build-time rewrite of those two expressions takes the asset payload from 8.2 MB to 1.5 MB; the login page and the button chunk are unchanged. Deleting the plugin is the whole revert if the console ever wants click sounds. Also: - `bun run dev` forwards the management bearer, so developing against a real host stops 401ing into a /login bounce that dev has no gate to satisfy. - `check-i18n` runs after `build`, not only inside `codegen`. It exists to stop a zero-message console shipping, and the CI job and the installer build both install with `--ignore-scripts`, so it had never once run where it mattered. - Bun's idle timeout goes from its 10 s default to 120 s. The host sends SSE keep-alives every 15 s, so anything long-lived proxied through the console was cut by us first — which the event stream is about to depend on. - The typecheck covers the Storybook config and preview. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	e30d94573a	fix(web): the logs come back after a host restart, and eight more that quietly lied ... The Logs page died permanently every time the host restarted — which the console's own update flow does. The host's log ring restarts at seq 1 while the page's cursor stays where it got to, and `GET /logs?after=8000` against a fresh ring is not an error, it is an empty page forever: no error, no dropped badge, stale lines on screen, and nothing short of a full reload to get out. A restart always breaks the poll first, so a failed poll now triggers a re-read from the start of the ring, and a page whose newest entry is older than what we hold is recognised as the sequence having restarted. Follow mode also stopped following at exactly the wrong moment. The autoscroll effect was keyed on the rendered row count, which pins at the 1000-row DOM cap — so once the log got busy enough to matter, the effect never re-ran again. It is keyed on the newest rendered seq now. And pausing now actually pauses: stopping the interval left React Query's focus/reconnect refetches landing, which evicted the very lines the operator had paused on. The rest: - A plugin could white-screen the whole console by registering `icon: "constructor"`. The icon map is a plain object, so the inherited key resolved to `Object`, which is truthy — the fallback never fired and React was handed `Object` as a component, from inside the app shell. - Saving a display arrangement deleted the saved position of every device that was not connected at that moment: the host replaces the whole map, and we only ever sent the displays we could see. - Flipping DDC, PnP or dedicated-game-sessions committed whatever unsaved edits the Custom block was holding, then cleared the "unsaved" badge so there was no trace of it. Those three apply on top of the SAVED policy now. - Saving the Custom block put the streamed-screen pin back to whatever it was when the form was seeded, undoing a change made in the picker below it. - "End now" on a running game calls the host's only stop, which ends EVERY live session; on a grace row with no app id it ended every waiting game. Both say so first now, when there is more than one to lose. - Edit and Delete were offered on library entries owned by a provider plugin, which the host refuses with 409 — silently. They are attributed instead. - An install whose first poll failed never polled again, and one whose host restarted spun forever with no way to dismiss it. - Submitting a second pairing PIN showed the previous attempt's "PIN sent" before a digit was typed, and the paired list it points you at never refreshed. - The streamed-screen picker claimed an env pin during every slow load, and rows that cannot be picked now look that way instead of silently eating the click. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Opus 5	4575134c21	fix(web): one bad password from anywhere stops locking out the whole console ... The console's login throttle was documented as per-IP and was not. Nitro's `localFetch` hands the app a synthetic request whose socket has no `remoteAddress`, so `getRequestIP()` returned undefined for every request and every attempt was charged to one shared "unknown" bucket. Five wrong guesses from any LAN peer locked out everyone — including the operator, and including the update-apply route, which shares that budget. The Bun entry is the only place the real peer is knowable, so it now stamps it into a header (deleting any client-supplied copy first) and `peerAddress()` reads it back. Verified on a real build bound to 0.0.0.0: seven wrong logins from 127.0.0.1 lock 127.0.0.1 out, a different peer still logs in on the first try, and a request forging the header is charged to its real address. Also on the way through: - Installing an unreviewed package and adding a catalog source now re-ask for the console password, like applying an update already did. A 7-day session cookie should not be able to run new code on the host, and `store/install` with `accept_unverified` did exactly that through the generic passthrough. The gate sits at the trust boundary — adding a source, or a raw spec — not on every install from a source the operator already chose to trust. - The ui-credential denylist is matched against the normalised path too, so `/api//v1/...` and friends can no longer walk around it. - The console serves nosniff, a no-referrer policy, and a CSP that pins frame-ancestors, object-src and base-uri. - A plugin UI's response no longer re-emits the content-encoding that `fetch` already decoded (which made compressed plugin pages fail to load), no longer sets cookies on the console's origin, and OPTIONS reaches the plugin instead of being refused 405 by us. - An unreachable host reads as 502 on these routes, matching the passthrough, instead of a bare 500. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:20:10 +02:00
enricobuehlerandClaude Fable 5	5926306a4c	feat(windows): the web console becomes a supervised child of the host service ... Three silent console outages in one week (0x1 / 0xFFFFFFFF / 0x41306), each a different proximate cause of the same structural defect: the console's lifecycle was owned by Task Scheduler — one best-effort start per boot/logon/install, no retry on a plain non-zero exit, no watchdog — while the product already shipped a real supervisor. The service now supervises the console as a second child slot: plain session-0 spawn (suspended → own no-breakaway kill-on-close job → resume), started only once the host has written mgmt-token + cert.pem + key.pem (the cert race dies by construction), secrets read from their files at every respawn, bun's stdout finally captured in logs\web.log, doubling backoff 0.5s→60s that never gives up. Session switches never touch it; a service stop takes it down via the job. The PunktfunkWeb task is retired: web setup slims to password + legacy task delete + firewall, the 127-line web-run.cmd batch supervisor is deleted, an [InstallDelete] entry reaps the stale copy, and service install now sets SCM crash-recovery actions (restart 1s/5s/60s) since the console rides on the service process. StopBunRuntimes stays for the scripting runner + the one migrating upgrade. Design: punktfunk-planning design/windows-web-console-lifecycle.md Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 20:16:19 +02:00
enricobuehlerandClaude Opus 5	5520167958	feat(clients): the OS marks tell gaming distros apart, and Windows looks current ... Three things were wrong with the host-card OS icons. The Windows mark was Font Awesome 5's, which is still the Windows 8/10 flag with the perspective skew — dated next to the flat four-pane mark Microsoft has shipped since Windows 11. No icon set has the current one (Simple Icons carries no windows/microsoft slug at all), so it is drawn here: four equal squares at the authentic 11.377 + 1.246 proportion. The Decky plugin was pulling FaWindows straight from react-icons, so it now inlines the masters like the web console does, or it would have kept the old flag regardless. Bazzite, CachyOS and Nobara collapsed onto their family's mark. The host already advertises the full chain, so this is purely missing art: all three now ship a leaf mark, because "a Bazzite box" and "a Fedora box" are different machines to the person reading the card. CachyOS and Nobara come from Simple Icons; Bazzite has no icon anywhere, so its "b" is lifted out of the project's own badge (Apache-2.0, attributed). On Android every non-square mark was stretched. A VectorPainter maps the viewport onto the ImageVector's default size with independent x and y scales, so declaring a 448x512 Tux as 24x24 dp squashed it — silently, no crash, no warning. The longest viewport edge now sets the 24 dp box and the other follows the ratio, which is what Icon()'s ContentScale.Fit expects. A unit test pins the invariant; every other client was already correct. Also: scripts/gen-os-icons.sh replaces the undocumented hand-run pipeline that turns a master into the GTK symbolic SVG, the Windows PNG and the Apple template PDF. It reproduces the committed artifacts byte-identically. Verified: web and Decky typecheck, Decky bundles, Android compiles and its tests pass, PunktfunkKit builds, osinfo's tests pass. Not verified on glass, and the GTK/Windows client crates do not build on macOS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 14:17:02 +02:00
enricobuehlerandClaude Fable 5	4a540bddc8	feat(host/deck): one-click source rebuild — the update.sh run as a transient user unit ... The U3.1 leg of planning:host-update-from-web-console.md. The Deck's on-device install gets the Update-now button with no opt-in (user-owned, no root): update.sh --pull runs under systemd-run --user so the script's own restart of punktfunk-host can't kill it mid-build (a child in our cgroup would die with us). Outcome without version equality — which a source rebuild can't promise: a failed build leaves the host alive to report it (unit watched to failure, log attached); a successful one restarts us, and the new source_build intent flag makes intent-present-at-boot itself the success signal (the script only restarts the host after a successful install). The console stops treating a live long build as a timeout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 16:28:40 +02:00
enricobuehlerandClaude Fable 5	239c69fd71	feat(web,docs): Linux one-click in the card — opt-in hint, staged and nothing-newer outcomes ... The apply panel serves staged kinds too; notify mode shows the group-join command when the helper is installed but not yet enabled; outcomes render 'staged — reboot to finish' and 'your package source had nothing newer yet' distinctly. Docs: the Linux opt-in section (why it's a group, what the grant bounds, the pacman stance). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 15:55:27 +02:00
enricobuehlerandClaude Fable 5	bb1f93d90e	feat(web,docs): the Update-now flow — password re-entry at the BFF, restart-tolerant progress, same-origin hardening ... apply.post.ts intercepts the one proxied route that restarts the host: the console password is re-verified per apply (login throttle shared, stripped before forwarding) so a 7-day cookie alone can't do it. New Sec-Fetch-Site same-origin check on every mutating request (login CSRF included). The card's apply flow: confirm dialog → live-session force escalation → download/verify/restart progress rendered from the last snapshot while polls fail (the host and, on Windows, this very server restart mid-flow) → durable success/failure from last_result. Docs: the one-click section + kill switch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 15:55:27 +02:00
enricobuehlerandClaude Fable 5	b275e6d34c	feat(web,docs): the Updates card — version, channel, install kind, and the exact update command ... Notify-only (U0): polls /update/status (which keeps the host's manifest cache warm), Check-now with the 30s limit surfaced, release-notes link, stale-feed and check-disabled states, copyable per-install-kind command. en+de strings; docs-site 'Updating the Host' page wired into the install section. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 14:34:47 +02:00
enricobuehlerandClaude Fable 5	77517bbe21	style(web): let biome format the message catalogues and the Logs story ... Cosmetic only, and kept out of the feature commit it rode in on so neither has to be read through the other. `biome check --write` reindents both message catalogues from two spaces to tabs (877 lines each, no key, order, or value touched — verified by comparing the parsed objects) and rewraps the Logs story fixtures onto one argument per line with trailing commas. Worth knowing for next time: the catalogues are also written by inlang, which formats with two spaces, so an edit made through that tooling will pull them back. Nothing depends on either shape — `bun run codegen` compiles 440 messages for both locales either way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 13:28:37 +02:00
enricobuehlerandClaude Fable 5	8d6241efae	feat(web): the logs page can hand a log off — as a file, or to the share sheet ... The Logs page could only be read in place. Getting a host log into a bug report meant selecting a screenful of monospace text and hoping the scroll container gave up the rest. Two controls in the toolbar now do it properly. Download writes a .log file named for the moment it was taken; the second button hands the same text to the OS share sheet where there is one (phones, iPads), and copies it to the clipboard everywhere else — which is why it is probed at runtime rather than guessed, and why the button is absent on the one combination where neither exists (plain HTTP, no Web Share). Both export what the filters currently match, not the rendered tail: the 1000-row cap is a DOM budget and has nothing to say about how long a file may be. Lines carry the full date and UTC offset, since a bare wall-clock time stops meaning anything the moment the file leaves the browser. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 13:07:15 +02:00
enricobuehlerandClaude Fable 5	bf9d101be8	fix(web): the approve button stops hiding off-canvas on portrait phones ... The pending-devices table's four p-card cells overflow a 360-430 px viewport, and the actions cell - Approve - ended up past the right edge of an overflow-auto wrapper inside the page's overflow-x-hidden column: the button existed but could not be seen or reached (landscape is wide enough, which is why it "worked" there). The name cell now flexes and truncates, and the fingerprint/age columns collapse into a sub-line under the name on narrow screens instead of widening the row. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:32:49 +02:00
enricobuehlerandClaude Fable 5	67ab64ed06	feat(web): the Host page names — and marks — the operating system ... The Identity card gains an "Operating system" row: the pretty name as text, the raw identity chain as its tooltip, and a leading OsIcon resolved by the same most-specific-first walk as the clients. lucide deliberately ships no brand marks, so os-icon.tsx vendors the ten as inline currentColor SVGs (the brand-mark precedent, the plugin-registry pattern), falling back to a generic monitor for a chain nothing recognizes. Row grows optional icon/title props rather than a fork; stories cover Bazzite, Windows and the unknown-distro degradation; labels land in both message files. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 17:58:33 +02:00
enricobuehler	50531c8e9e	fix(host/display): a screen picker that cannot stream a screen now says so instead of saving ... The Windows console's "Streamed screen" picker SAVED and then did nothing. `capture_monitor` is platform-neutral, so the PUT persisted; every consumer of it is Linux-gated, so a virtual display was still created on connect. The operator got a control that acknowledged the click and changed nothing — the worst of the three possible behaviours. The root cause is not a missing gate, it is a missing BACKEND. Per-monitor capture is Linux/portal only: `vdisplay::open`'s mirror arm is `#[cfg(target_os = "linux")]` because `pf-capture` has no Windows entry point that can capture an arbitrary head. Its sole Windows entry point is `open_idd_push`, a frame channel pushed by our OWN IddCx virtual display; DXGI Desktop Duplication was deliberately REMOVED (`windows/dxgi.rs` keeps the GPU-preference hook only to stop DXGI reparenting the virtual display off the pinned adapter, and says so). So there is nothing for a pin to aim at, and exposing the picker got ahead of that. Decision of record (user, this session): mark it unsupported now rather than build the Windows backend here. A Windows mirror backend is a real feature gap and a project of its own — it needs a duplication capturer plus everything the IDD-push path carries today (cursor sidechannel, 444, 10-bit, PyroWave, HDR) re-plumbed through it — not a follow-on to an enumeration commit. Three places, so the answer is consistent wherever it is asked: * `MonitorsResponse.pin_supported` — a CAPABILITY, reported by the build that would have to honor the pin rather than sniffed from the OS client-side. When a Windows mirror backend lands this flips and the console needs no change. `pinned` stays `None` off-Linux deliberately, and now says why: it is what the console highlights as "sessions stream this", and highlighting a head nothing will capture is the same lie in a different place. * `enforced` drops `capture_monitor` off Linux. That list is exactly the "which controls are live vs. coming soon" contract, and claiming this one unconditionally is what let the picker ship enabled. * The PUT drops a non-Linux `capture_monitor` instead of storing it, and logs that it did. COERCED, not rejected with a 400: this PUT is WHOLE-OBJECT, so a host that already stored a pin would have every later settings save rejected over a field the operator cannot see — taking the other axes down with it. This way such a policy self-heals on the next write. Console: the picker renders read-only with an explanation, reusing the `envLocked` shape rather than inventing a second one (`locked = envLocked || !pinSupported`). Managed heads were ALREADY excluded from selection here (`mon.enabled && !mon.managed`), which is the "grey out, never filter blindly" rule working as intended — the heads stay listed and explicable. `pin_supported` defaults to TRUE when absent so an older host, which only ever shipped this picker where it worked, is not retroactively locked out. ⚠️ `api/openapi.json` is hand-patched — punktfunk-host does not build on macOS, so the spec could not be regenerated from the binary. The shape was verified by running the real generator over it: orval emits `pin_supported: boolean` (required, no `?`) on `MonitorsResponse`. Verified: `bun run codegen` (orval + paraglide + i18n parity: 434 messages, en + de), `bun run build`, `bun run lint` (tsc --noEmit) all clean. Rust verified separately on .173 — see the next commit's note if that lands, since neither xcheck target covers punktfunk-host.	2026-07-29 00:18:27 +02:00
enricobuehlerandClaude Opus 5	9b38b6a22d	feat(stats): a capture records which encoder and GPU produced it ... The stage split is the thing an fps-shortfall report is diagnosed from, and it cannot be read without knowing the backend behind it: a p50 `submit` of 10 ms means "the GPU's CSC+encode throughput is the ceiling" on one backend and something else entirely on another. The capture's meta carried the mode, codec and client but neither the encoder nor the GPU, so every report so far cost a round-trip asking which one it was. Both come from `pf_gpu::active()` — the record the encoder open itself writes — so they name the branch that really opened rather than a re-derived guess that goes stale the moment a backend gains an internal fallback. Read once per capture, not per frame. The console shows them next to the mode in the recording's header. Both fields are `serde(default)`, so a recording made before this still loads and simply omits them. Refs #9 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:14:10 +02:00
enricobuehlerandClaude Opus 5	f98547c41f	fix(web-console): the paired-clients card counts both pairing planes ... GameStream and native (punktfunk/1) clients pair into separate stores, and `/status` only ever reported the GameStream certificate count. Native is the DEFAULT plane, so a host whose clients had all paired normally — and which Moonlight had never touched — showed "0 paired" on the dashboard. Report the native count alongside it, the way the tray's own summary route already does, and sum the two in the card. Closes #10 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:13:19 +02:00
enricobuehler	1db8f7631b	fix(nix): move the bun packages to bun2nix — no more hand-bumped deps hash ... `nix build .#punktfunk-web` has been broken since 1e9957d9 re-resolved web/bun.lock: the console's node_modules came from a fixed-output derivation whose single aggregate `outputHash` was last refreshed in 4094f620, so every lockfile change silently invalidated it and the fix required a round-trip on a Linux nix box (build, read the `got:` hash, paste it back). The runner (sdk/bun.lock) had the same latent trap. Replace both FODs with bun2nix (github:nix-community/bun2nix, pinned to 2.1.2). `fetchBunDeps` turns a generated, committed `bun.nix` into bun's global install cache — ONE `fetchurl` per package, keyed by the integrity hash already in the lockfile — and the setup hook then runs a fully offline `bun install` in `bunRoot`. There is no aggregate hash left to go stale. The `@unom` scope needs no special handling: bun.lock records those tarballs' full git.unom.io URLs and the registry is read-public. `bun.nix` keeps itself in step: `bun2nix` is now a devDependency of both packages and regenerates the file on every `bun install` — web via `postinstall`, the SDK via `prepare`, because sdk/ is the published @punktfunk/host package and a postinstall would fire on consumers' installs. Both the flake input and the npm devDependency are pinned to the same exact version; `bun.nix` has no schema stability guarantee across bun2nix releases, so they move together (README documents this). Dropped along the way: the manual `cp -R ${deps}/node_modules` + `chmod -R u+w` + `patchShebangs web/node_modules` dance, since bun2nix patches shebangs inside the cache. `dontUseBunPatch` keeps the hook from running `patchShebangs .` over the whole repo checkout (it would rewrite scripts/web-init.sh, which we ship verbatim); `dontRunLifecycleScripts` preserves the old `--ignore-scripts` behaviour, so playwright still never tries to download browsers. Verified on a Linux nix box (Determinate Nix 3.21.5): `.#punktfunk-web` and `.#punktfunk-scripting` both build green, offline; the i18n guard reports its 421 compiled messages, the `Bun.serve` bundle guard passes, and `nix run .#punktfunk-scripting -- --list` discovers an installed plugin. `nix flake show --all-systems` evaluates every output. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 4cfe7f05ee608868857be9e7eec079044448a965)	2026-07-28 17:01:59 +02:00
enricobuehler	0868b6a364	fix(vdisplay): compositor availability follows the live session, not the env ... GNOME/Mutter reported "Unavailable" on a host sitting in a live Mutter session — and, on the same request, "Default", because the two columns had different sources. available() asked each backend, and those probes read the process env (XDG_CURRENT_DESKTOP for Mutter, WAYLAND_DISPLAY for KWin's registry handshake, SWAYSOCK for sway) — env a host started outside the session (systemd --user, a TTY, ssh) never inherited. It is only retargeted at the live session on the connect path, so the answer also flipped depending on whether anyone had connected yet. Both columns now come from the same /proc scan detect() already used: the live session's compositor is usable by definition, as is an explicit operator pin, and the per-backend probe stays as the fallback for backends that are not the live session (gamescope, which spawns its own). A live KWin without the zkde_screencast grant now surfaces as available and fails at create with that probe's precise message, which beats "no usable compositor" on a box visibly running KDE. Mutter's env sniff stays deliberately narrow — one var, not three. XDG_CURRENT_DESKTOP is the one apply_session_env owns end to end (written per connect, scrubbed when nothing is live); sniffing DESKTOP_SESSION alongside would resurrect the bug that scrub exists to prevent, where a stale value after a gnome-shell crash routes the next client into a dead session. Non-Linux hosts now report no compositors at all rather than five Linux backends flagged unavailable with no default — on Windows the pf-vdisplay driver is the only backend and vdisplay::open ignores the argument, so the old list read as broken detection instead of "not applicable here". The console says so explicitly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit eb7ba3d6177552f5c3ed6a15439404084869c636)	2026-07-28 17:01:59 +02:00
enricobuehler	3b11288c97	fix(web): unsaved custom display settings are visible and recoverable ... Everything else on the Displays page auto-applies — a preset click, the game-session choice, the experimental toggles — but the Custom block does not, and its Save button sat at the bottom of a block taller than most viewports. People edited, never scrolled far enough to find it, navigated away, and silently lost the lot. The draft is now compared against the last-seeded server value, and that one boolean drives the whole affordance: a badge in the card header (visible without scrolling), an amber ring plus a title on the block, and a sticky action bar pinned to the viewport for as long as any part of the block is on screen. The bar states which of the two states you are in rather than leaving it implied, Save disables when there is nothing to save, and Discard changes puts the stored policy back. Two ways edits could still vanish are closed: a preset click now confirms before overwriting pending edits, and a reload/close warns. Re-picking Custom while already on Custom is a no-op instead of re-seeding, which would otherwise fill in defaults for unset fields and report "unsaved changes" for a click that changed nothing. Adds a `warning` badge variant + --warning token for the pending state — attention, not failure, and distinct from the destructive red. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit c4318609c0da5ae1313081c5e488f685504f70d1)	2026-07-28 17:01:59 +02:00
enricobuehler	40714317a8	fix(web): empty-state cards get their top padding back ... "No games found yet." sat flush against the top edge of its card on any screen ≥640px. The call sites overrode CardContent's padding with a bare `p-8`, but tailwind-merge only resolves conflicts within a variant: `p-8` cancels `p-4` and leaves `sm:p-6 sm:pt-0` standing, so the desktop breakpoint kept the zero top inset that exists for cards WITH a header. These three have none. Uses `flush` — the escape hatch CardContent documents for exactly this — so the padding is owned outright at every breakpoint instead of fought from the outside. The library grid is the one that was reported; the store catalogue and the recordings list are the same idiom with the same bug. PairedDevices deliberately keeps its `p-6`: it is a table under a header, where pt-0 is the intended look. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 71fc47f32af7c74327a26425035298f8e6464c96)	2026-07-28 17:01:59 +02:00
enricobuehlerandClaude Opus 5	8fe71be424	fix(web): applying a saved preset kept switching the streamed screen off ... `applyCustomPreset` builds a FRESH policy object instead of spreading the draft, so every field it doesn't name is dropped. `capture_monitor` was not named — so picking one of your own saved presets silently took a host that was mirroring a real monitor and put it back on a virtual display. The same omission in the Custom switch would have done it there too. Found on-glass against a running serve on .136: the PUT is whole-object, so the console is the only thing keeping the orthogonal axes alive, and these two sites were the ones building a policy from scratch rather than from what was already in force. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	d461d889c3	feat: the streamed screen is a persisted setting, pickable from the console ... P4 of design/per-monitor-portal-capture.md. The pin was an env var read once at startup, which a console picker can never write — so it becomes a field of the display policy (orthogonal to presets, like game_session), and `vdisplay::capture_monitor()` resolves env-over-policy: an appliance that pinned in its unit's host.env stays pinned there, and a console click cannot re-aim a machine whose operator already declared the answer. Read per `open` rather than cached, so a picker change takes effect on the next session instead of the next host restart. The host re-resolves the input anchor on every policy write — including clearing it when the pin is cleared, or a later virtual-display session inherits an anchor aimed at a monitor it is not showing. `with_manual_layout` carries the pin through like the other orthogonal axes: without that, saving a display ARRANGEMENT would silently swap the streamed screen back to virtual. Console: a "Streamed screen" card listing the host's real monitors beside "Virtual screen (default)", saving on selection. A disabled head is listed but not selectable (so "why isn't it here?" has an answer), and an env-pinned host renders read-only with the reason rather than offering controls that silently lose to the environment. Verified on GNOME/Mutter: pinning via the policy file alone (no env) routes sessions to the mirror and anchors input; setting the env to a different connector overrides it, exactly as documented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehler	ec9aa415f6	chore(web): override brace-expansion to 5.0.8 — clears GHSA-mh99-v99m-4gvg ... bun-audit has been red since the advisory published, so it was already failing before v0.20.0 was cut (same failure on 0323158a). High-severity DoS: unbounded expansion length causing an OOM crash. All three paths are dev tooling — orval→typedoc→minimatch, @storybook/react-vite→glob→minimatch, and nitro-v2-vite-plugin→nitropack→archiver→archiver-utils→glob→minimatch — so nothing shipped to a user was exposed, but the leg gates every lockfile change. Done as an `overrides` entry, joining the eight already there for exactly this purpose. `bun update brace-expansion` is NOT the fix and was reverted: for a package that is only transitive it adds a spurious DIRECT dependency, and it does not even resolve the advisory — it hoists 5.0.8 for the new direct dep and leaves `minimatch/brace-expansion` pinned at the vulnerable 5.0.7. The advisory's affected range is `<= 5.0.7` across ALL majors with 5.0.8 the only patched version, so the two nested 2.1.2 copies had to move too — a major bump for consumers declaring ^2.0.1/^2.0.2. Checked rather than assumed: 5.0.8 is dual ESM/CJS with a real `require` branch in its exports map (2.1.2 was plain CJS), so those consumers still resolve. Proven by building: the nitro build is itself one of the forced consumers. Verified: `bun audit` reports no vulnerabilities, both nested entries are gone from the lock, and the full CI web sequence is green — `bun install --frozen-lockfile --ignore-scripts`, `bun run build`, `bun run lint`.	2026-07-27 07:32:08 +02:00
enricobuehler	35b6c835fd	docs: on a gamescope session the display outranks the end-game setting ... On-glass on .41: with `game_on_session_end: keep` — "leave it running, nothing is ever closed" — a deliberate stop ended the game, and a drop ended it ~14 s later. Both times the LEASE did the right thing (no `ending the launched game` line); the game died because the virtual display was torn down, and a nested launch runs inside that gamescope. So on a dedicated gamescope session the game's lifetime IS the display's, and keep-alive decides it — not this setting: * a deliberate stop skips the linger by design, so the game goes at once, * a drop lingers the keep-alive window, then takes the game with it, * only keep-alive Forever actually keeps it — and `always` still ends it at the reconnect window, which is the documented precedence and was verified (a `forever`-pinned display released at grace expiry, 60.006 s). That makes the console's promise untrue on the most common Linux setup, so the card now says so for every option rather than only warning about `always`, and the docs get the three cases as a table. Worded so a non-gamescope host reads it and moves on — a desktop-session launch is an ordinary process and none of it applies. Not changing behavior here: making `keep` pin the display would pit it against "a stop must not leave a ghost display", and which wins is a product call rather than something to decide silently mid-test. web: codegen + tsc + biome clean, en/de complete. docs-site: build + tsc clean.	2026-07-27 01:43:40 +02:00
enricobuehler	39a9f09f04	fix(mgmt/web): the running-game cover slot says "game" when there is no art ... Rendered the Dashboard stories headlessly and looked at them, which is how this turned up: with no cover the slot was an empty grey rectangle, reading as something that failed to load rather than something absent. Plenty of rows will never have art — an operator-typed command has no catalog entry behind it, a custom entry may carry none, and nothing does until `/library` has loaded. The slot keeps its fixed size so rows stay aligned when only some titles have covers; it just holds a gamepad glyph instead of nothing.	2026-07-27 00:47:05 +02:00
enricobuehlerandClaude Opus 5	1ee06defa6	feat(library): descriptive metadata on every entry — platform, year, genres, and friends ... Emulation-and-beyond libraries need more than a title and a poster. Every library shape (GameEntry, CustomEntry, CustomInput, ProviderEntryInput) now carries a shared, flattened GameMeta: platform, description, developer, publisher, release_year, genres, tags, region, players. All fields are optional and flat on the wire, so existing library.json files, provider plugins, and clients keep working unchanged. - Installed-store scanners (Steam, Lutris, Heroic, Epic, GOG, Xbox) stamp platform=PC; custom/provider entries carry whatever was authored. - GET /library grows a ?platform= filter (case-insensitive) beside ?provider=. - Console: the add/edit form gets a Details section (round-tripping every field, since update replaces the entry), the poster tile a platform badge (non-PC only — the store badge already implies PC) and the year. - plugin-kit: ProviderEntry accepts the same fields (new GameMeta schema, spread flat); SDK + OpenAPI spec regenerated. - pf-client-core decodes platform for future client badges. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 19:00:30 +02:00
enricobuehler	6a2c127ce9	feat(mgmt/web): show the running game, and who decides when it ends ... The host knows what it launched and, after a disconnect, that it is counting down to closing it. None of that was visible: the console showed a stream with no game, and a game on its way to being closed was something you found out about afterwards. The Dashboard gains a running-game card above the session card — box art matched against the catalog it already fetches, so no new endpoint and no request on the 2 s status poll. "End now" means the two different things the row's state implies: a live game ends by stopping its session (what then happens to the game follows the policy — stopping a session is not licence to close a game), while one already waiting out its reconnect window has no session left to stop and is ended directly. The settings card sits next to the display keep-alive policy because that is the same question one step out: keep-alive decides how long a *display* outlives a disconnect, this decides whether the *game* does. The copy says plainly what `always` costs, that a drop is not someone pressing Stop, and that a display kept forever is unaffected either way — the precedence rule that would otherwise surprise someone. Where a build enforces nothing (macOS, no launch path) the controls are shown disabled rather than hidden: "does nothing here" is information. Also fixes the story fixtures, which had gone stale against the `games[]` field Phase 1 added, and adds a story for the state the card exists for — a game whose client walked away. web: build + tsc clean, biome-formatted; en/de messages complete.	2026-07-26 18:28:13 +02:00
enricobuehlerandClaude Fable 5	6c2c8b6eab	feat(mgmt/web): surface the host.env encoder pin so a conflicting GPU choice isn't invisible ... listGpus gains encoder_pin (PUNKTFUNK_ENCODER when it actually pins something — unset/auto stay null), and the console's GPU card shows it: a muted note when the pin is compatible, an amber warning naming the pinned vendor and the next session's GPU when it contradicts the selection (the host overrides such a pin at session open — without this field the selection just looked broken). Docs updated to say the adapter wins. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 16:53:19 +02:00