14 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	99eb679c07	feat(clients): a moved mgmt port now outlives the advert that announced it ... Moving the mgmt port off 47990 (the fix for sharing a box with a Sunshine fork, whose web UI owns that port) only ever worked for as long as mDNS did. The real port lived in the advert and nowhere else: every client read it live and threw it away, so on a VPN, a routed subnet, or any multicast-dead network the library silently fell back to a port nothing was listening on. `KnownHost` gains `mgmt_port: Option<u16>` + `effective_mgmt_port()` + `learn_mgmt_port()`, exactly the shape `mac` and `os` already use ("learned from the advert while online, persisted so it survives the host going to sleep") — except this one is load-bearing rather than cosmetic, so `upsert` states the preserve rule explicitly instead of relying on the does-not-mention-it accident that `clipboard_sync` survives by, and `upsert_trusted` carries it across a re-key. Wired through all four client families, each of which was wrong in its own way: * CLI / Windows / Linux reached for `DEFAULT_MGMT_PORT` at the call site — the constant is the FALLBACK, not the answer. Windows also needed the port on `Target`, which the library screen has instead of a `KnownHost`. * The session console read `advert.and_then(mgmt_port)` with NO saved fallback, two lines above an `os` that gets the three-rung treatment right. It now matches, and learns on every tick. * Linux's `mgmt_port_for` consulted live adverts only; it now falls back to the store. * Android never carried the port at all — its native discovery record stopped at 8 fields. Added `mgmt` as the 9th (the record's own documented "new fields append, never reorder" rule), then through `DiscoveredHost` -> `KnownHost` -> `LibraryScreen`. * Apple LOOKED done and was not: `StoredHost.mgmtPort` and `effectiveMgmtPort` have existed all along, but nothing anywhere wrote the field and the `mgmt` TXT was never parsed — so it was permanently nil and every Apple client resolved to 47990 regardless. That is worse than the honest omissions above, because it reads as finished. Now parsed, carried on `DiscoveredHost`, and written by `HostStore.updateMgmtPort` at the same site that learns MACs and the OS chain. Also `PUNKTFUNK_NATIVE_PORT` in host.env, finishing the pair with PUNKTFUNK_MGMT_BIND: `--native-port` was likewise CLI-only and died on a package upgrade. A bad value is a startup ERROR rather than the silent fall back to 9777 that `PUNKTFUNK_DATA_PORT` still does — the failure that reads as "I moved the port and the client still can't reach me". The client side of the native port already worked (`KnownHost.port` is persisted, `--connect HOST:PORT` names it). Adding the field broke three `KnownHost` literals in tests, which is the `Default` impl's stated purpose working ("adding a field here can't silently produce records that lack it"). All three now carry 47991 — deliberately NOT the default, so the assertions cannot pass vacuously against a hardcode. New coverage: forward-compat decode of a store predating the field, the resolver fallback, re-key carry-forward, and on Android the 9th-field parse plus 0/non-numeric/out-of-range all reading as unknown. What this does NOT fix: a host that moved its mgmt port and has NEVER been seen over mDNS. Nothing tells the client where to look, and the honest fix is for the host to announce it in-band — the `Welcome` message has an established "append a trailing field, older peer decodes to the default" pattern for exactly this, at the cost of a C ABI accessor and a bump. Left for a separate change. Verified: Linux (punktfunk-rust-ci/pf-lxcheck2, amd64) `cargo check --all-targets` clean for pf-host-config, punktfunk-host, pf-client-core, punktfunk-cli, punktfunk-client-linux and punktfunk-client-session — the last confirmed non-vacuous by planting a compile_error! and watching the gate fail (cargo prints "Compiling", not "Checking", for bin-only packages, so the usual marker grep lies about it). Android: :kit + :app compileDebugKotlin clean, ParseRecordTest 12/12 with both new cases named in the XML. Apple: xcframework built, `swift build` complete, SharedFoundationTests pass. cargo fmt --all --check clean. NOT verified: the Windows client (192.168.1.133 unreachable).	2026-08-14 19:44:19 +02:00
enricobuehler	51a005dd43	fix(deps): close the audit gaps, drop unused declarations, declare what is used ... Acting on the 2026-08-13 dependency sweep. Every claim below was re-verified against the tree before acting on it (greps carry a positive control; the advisories were re-checked with cargo audit 0.22.2). SECURITY - event-listener 5.4.1 -> 5.4.2 (RUSTSEC-2026-0221, unsound Send/Sync on StackSlot; reaches the tray via zbus and the host via ashpd). This sat unnoticed because `cargo audit` reports unsoundness as a WARNING and the job fails only on vulnerabilities — audit.toml now says so out loud. - spin 0.9.8 -> 0.9.9. 0.9.8 is YANKED and was genuinely compiled (flume via mdns-sd and relm4, plus lazy_static). - wayland-scanner 0.31.10 -> 0.31.11, which moves quick-xml 0.39 -> 0.41. That is the exact trigger audit.toml documented for RUSTSEC-2026-0194/0195, so both ignores are deleted rather than left as permanent exceptions. Only RUSTSEC-2023-0071 (rsa Marvin, still unfixed upstream) remains. - Corrected audit.toml's claim that `paste` arrives "via utoipa-axum": rav1d pulls it too, so every client has it through the decode path and dropping utoipa-axum would not have cleared it. TWO CI GATES THAT SCANNED NOTHING - `cargo audit` only ever reads the ROOT Cargo.lock. The drivers lock was already in this job's `paths:` filter, so edits to it triggered a run that then ignored them. All four secondary workspaces now get an explicit `--file` (verified: clean, bar the known `paste` warning in drivers). - packaging/windows/pf-vkhdr-layer had NO lockfile at all while shipping as a DLL in the host installer, so every build resolved fresh and neither cargo-audit nor cargo-about ever saw it. Lockfile generated and committed, and added to `paths:`. UNUSED / DUPLICATE DECLARATIONS - punktfunk-host: removed 13 dependencies it never references — the Wayland stack (client, protocols{,-wlr,-misc}, scanner, backend), xkbcommon, reis, khronos-egl, ash, usbip-sim, parking_lot, bytemuck. The code moved to pf-inject and pf-zerocopy in the subsystem extraction and those crates declare them; only the manifest entries and their now-false comments stayed. Also dropped four redundant re-declarations (tokio/serde_json/futures-util in the Linux block, tower in dev-deps). - Removed genuinely unused: bytes (punktfunk-core), anyhow (pf-win-display), tracing (clients/cli), anyhow (clients/session), serde (clients/windows). - Removed the high-level `wdk` crate from all five driver crates and the drivers workspace: none of them ever referenced `wdk::` (62 `wdk_sys::` uses; pf-umdf-util is a full WDF crate that never declared it). `tracing`/`tracing-subscriber` remain in that lock afterwards but ONLY as wdk-sys build-dependencies, not in the DLLs. - pf-win-display took punktfunk-core with `quic` for one type (`Mode`) that lives in the ungated `config` module; now `default-features = false`, which keeps quinn/tokio/rcgen/opus out of a leaf crate's declared closure. - pf-encode declared the windows-rs feature `Wdk_Graphics_Direct3D` for a call that lives in pf-frame and is resolved via GetProcAddress on gdi32. LATENT BREAKAGE (compiled only by feature unification) - pf-inject uses `tokio::select!` without declaring `macros` (borrowed from punktfunk-core's quic feature); pf-capture uses `tokio::sync::oneshot` without declaring `sync` (borrowed from ashpd->zbus); pf-client-core uses the `minwindef` and `winnt` windows-rs headers without declaring them (borrowed from clients/windows). Each now declares what it uses, so an unrelated crate changing its features cannot break them. - pf-console-ui took pf-client-core WITHOUT `default-features = false`, unlike every other consumer. That default is `pyrowave`, which compiles the vendored PyroWave C++ — "fatal on Windows ARM64". Only safe today because the ARM64 leg passes --no-default-features (which also drops `ui`). CORRECTED A FALSE INVARIANT - clients/windows claimed "the workspace builds ONE windows-rs". It does not: wasapi pulls the crates.io windows 0.62.2 beside the git-rev copy. The invariant that DOES hold is narrower (reactor and that crate share one rev, which is what makes the IDXGISwapChain1 hand-off type-check). Comment rewritten, with a warning against "fixing" it via a blanket [patch.crates-io] — this rev uses header-named features while a dozen other manifests use the old Win32_* namespace ones. Plus the safe in-compat `cargo update` sweep (no manifest edits). Verified on macOS: punktfunk-core 385, pf-update-check 32, c_abi 1 (with LIBRARY_PATH=/opt/homebrew/opt/opus/lib), cargo audit clean bar the two known unmaintained warnings. Linux and Windows legs follow.	2026-08-13 12:41:47 +02:00
enricobuehler	79d755cd98	feat(crypto): move the rustls backend from ring to aws-lc-rs, with PQ key exchange ... The workspace pinned `ring` everywhere because aws-lc-sys 0.41.0 failed to C-compile on the Windows CI runner. Re-tested on that runner (.133) with aws-lc-sys 0.44.0: the `params.c` cl.exe failure does not reproduce under MSVC 14.44, and rustls's `aws_lc_rs` feature turns on `aws-lc-rs/prebuilt-nasm`, so no NASM is needed on the box either. That unblocks post-quantum TLS: `prefer-post-quantum` offers X25519MLKEM768 first on every TLS 1.3 handshake (mgmt API, native control plane, QUIC), which ring cannot do — it has no ML-KEM. Classical curves stay in the list, so older clients still connect. rustls, quinn, rcgen and tokio-rustls each select a backend independently, so all four had to move together; a single dissenter pulls a second crypto stack in via feature unification. The direct `ring` users (ed25519 in pf-update-check, SHA-256 in the Windows updater) moved to aws-lc-rs, whose API is ring-compatible. `ring` does NOT leave the tree: ureq 2 names `features = ["ring"]` in its own rustls dependency line and cargo features are additive, so no dependent can switch it off. Two backends compiled in means rustls refuses to infer one, and anything built via `ClientConfig::builder()` panics instead of picking — which is what ureq's default agent does on its first HTTPS request. `tls::install_default_provider()` makes the choice explicit; it runs at each binary's entry point and defensively in pf-client-core, which several binaries link. Dropping ring entirely needs the ureq 2 -> 3 upgrade (36 call sites), deliberately left out of this change. Verified on macOS: pf-update-check 32, punktfunk-core 385, c_abi 1 (the last with LIBRARY_PATH=/opt/homebrew/opt/opus/lib) — aws-lc-sys links into the C ABI harness, so the Swift/Kotlin embedders keep working. cargo fmt --all --check clean.	2026-08-13 12:41:47 +02:00
enricobuehler	0d407a866d	fix: a host that changed DHCP lease could no longer be streamed from the panel ... An adversarial review of this branch found a regression I introduced, plus three smaller defects. All four are fixed here, each verified on .21. **The regression.** `mergeHosts` names a host by its record's stable id, and `hosts list --json` always emits one (`KnownHosts::load` mints ids for every record). So a launch always went out as `punktfunk launch <uuid>` → `ConnectPlan::for_host` → `HostTarget::from(&KnownHost)`, which copies the address stored ON THE RECORD. Meanwhile the panel deliberately renders the LIVE advert's address. Nothing on a Deck ever writes a moved address back — `discover` and `hosts list` are both reads, and only the desktop shells' hosts pages update one. So after any DHCP move the row read "online" at the new address and every press dialled the old one: a 15 s dead connect, or — if a MAC had ever been learned — a black Steam "game" for the full 90 s wake budget. Proven with a stub session binary: `launch abc-123` emitted `--connect 10.0.0.5:9777` for a host answering at `10.0.0.99`. This worked on origin/main, which dialled `toHost(v).host` — the advert's address. The fix restores that without giving up stable ids: `hosts add <new-addr> --fp <known-fp>` now MOVES the matching record instead of filing a second one (the fingerprint is the identity — this is the same rule that makes the verb idempotent), and the panel re-points a host it can see has moved before launching it. Verified: `moved 10.0.0.5:9777 to 10.0.0.99:9777`, one record still, and `launch abc-123` then emits `--connect 10.0.0.99:9777`. **"No hosts yet" was also how a missing client looked.** `_cli_argv()` returning None becomes `client-unavailable`, which the panel dropped on the floor — so a Deck with no client installed was told its network was empty, under a button that launches the client that isn't there. It now says which of the two it is. **The browse worker never exited on a quiet LAN.** `discover_for` drops the receiver and the doc claimed that stops the thread. It does not: the worker parks in `recv()`, and the arms that ignore an event (`SearchStarted`, `ServiceFound`, `SearchStopped`, a v6-only advert) never touch the sender, so on a LAN with no Punktfunk host nothing ever wakes it. Harmless today because the only caller is a short-lived CLI process, but the function invites in-process use, where it would leak a thread and an mDNS daemon per call. Now polled with a 250 ms tick and a check at the top of the loop. Verified: ten back-to-back browses settle back to the baseline thread count. **A `pair=optional` host was recorded as paired.** Every unsaved host now goes through the trust sheet (it has no pin, so it cannot stream without one), but the sheet's only non-PIN action ran `--request-access`, which persists `paired: true` on Ready. An optional host admits anyone who pins its identity — there is no operator decision, so nothing was approved and the same box read "paired" here and "trusted" in the desktop client. Such a host now gets **Connect** instead, which pins and streams without claiming an approval, and the "approve this Deck" toast is no longer shown to someone who has nobody to ask. Also: `PF_CLIENT_BIN` was the one launch-option value never validated — a client installed under a path with a space would split Steam's tokenizer.	2026-08-04 21:26:09 +02:00
enricobuehler	414380fc9e	fix(cli): discover reads the host store without writing to it ... `KnownHosts::load()` mints a stable id for any record that lacks one and SAVES it — which makes it a write, and `discover` was calling it purely to annotate what the browse found with saved/paired. It never hands those ids back to anyone. That matters because the Decky panel issues `discover` and `hosts list` together, in parallel. Against a store written before ids existed, both processes read it, both mint DIFFERENT ids for the same record, and both save. Whichever loses the race has already handed its ids to its caller — so the panel could draw a row whose host reference no longer resolves, and pressing it would exit 5 ("no saved host matches") until the next refresh settled things. `KnownHosts::read()` is `load` without the mint: the store exactly as it is on disk. `discover` uses it; every caller that dials a host by id still uses `load`, so ids are still minted the first time anything needs one. Verified on a fixture store with no ids: `punktfunk discover` leaves it byte-identical, and a following `punktfunk hosts list` mints as before.	2026-08-04 21:07:37 +02:00
enricobuehler	f84c5b8114	feat(cli): launch --request-access — let the host's operator admit this device ... Request access is not a second pairing ceremony, it is a LAUNCH: an ordinary identified connect with the advertised fingerprint pinned and the handshake budget stretched past the host's approval window. The host parks the connection until somebody approves the device in its console or web UI, then admits the same connection and the stream starts by itself. The desktop shells and the console home have had this for a while (`SpawnOpts::persist_paired`, `screens/pair.rs`); headless callers had no door to it. punktfunk launch <host-ref> --request-access Two behaviours, both small: * `connect_timeout_secs = 185`, matching the host's PENDING_APPROVAL_WAIT. Anything shorter gives up while the approval prompt is still on the operator's screen. * `run_plan` records the host as paired on SessionEvent::Ready. That event IS the approval arriving, and it records the pin the session actually connected WITH rather than re-reading the store — the handshake completed against that identity, which is what makes the record true. Every other launch still records nothing: a plain connect proves reachability, not a new trust decision. Refused under `--exec` (exit 5) rather than silently downgraded. Under --exec the CLI BECOMES the session, so no process survives to observe Ready — a quiet downgrade would leave hosts reading "trusted" forever with nobody able to explain why.	2026-08-04 20:28:34 +02:00
enricobuehler	aec02b9d26	fix(cli): hosts add --fp fills in an empty fingerprint instead of dropping it ... `punktfunk hosts add <addr> --fp <hex>` against an address already in the store printed "is already saved" and exited 0 — having done nothing at all. The --fp was silently discarded, so a host saved by address stayed pinless and every later connect refused for want of a fingerprint, with no line anywhere saying why. Three outcomes now, and the difference between them is a trust decision: • no fingerprint on the record, one offered → fill it in, print `updated <addr>:<port>` • the same fingerprint offered again → no-op, exit 0 (a panel may retry a step whose state is already correct without having to invent an error to show) • a DIFFERENT fingerprint → refuse, exit 3 The refusal is the important one. A changed identity is a decision for a person at a surface that can show them both — the rule `upsert_trusted` exists to enforce — and quietly overwriting a pin here would be a back door through the pinning the rest of the client is built on. A record still named after its own address takes an offered --name; a label the user chose is theirs and an advert's name must not overwrite it.	2026-08-04 20:28:11 +02:00
enricobuehler	48bb1769b4	feat(cli): punktfunk discover — browse the LAN, annotated against what you've saved ... The CLI could do everything with a host except FIND one, so every headless consumer grew its own mDNS: the Decky plugin parses ~120 lines of avahi TXT escaping in Python, which drifts from the host's advert every time a key is added and makes the plugin depend on Avahi being the resolver. `discovery::discover_for(timeout)` is the bounded collector beside the streaming `browse()` the UI uses — same service type, same TXT keys, folded to one row per host. A refreshed advert wins (it carries the newer address), a removal drops the row, and dropping the receiver on the way out stops the worker so a one-shot call can't leak a browse per invocation. The verb annotates each hit against the saved-hosts store rather than handing back two lists to join: `saved`/`paired` are answered by fingerprint first and address second — the same rule every other surface uses. That is what stops a host that moved DHCP lease from reading as new, and stops a different box that inherited the old address from reading as paired. punktfunk discover [--json] [--timeout SECS] Default 3 s, capped at 30 — this is called from a Quick Access panel, and a typo'd `--timeout 3000` would hang that panel with no way to cancel. An empty LAN exits 0: a caller branching on the code is asking whether the browse ran, and it did.	2026-08-04 20:26:59 +02:00
enricobuehlerandClaude Fable 5	f4f83202cb	feat(core/client): an AU's prefix reaches the decoder while its tail is on the wire ... Delivery used to be all-or-nothing: the decoder saw byte 0 only after the last packet of the AU landed, so the whole transmit time sat in front of decode. With the slice-streamed wire (previous commit) blocks now arrive addressable, and a client can opt in (connect's new frame_parts) to receive each AU's newly-contiguous prefix as Frame::part pieces - offset tiling, first/last marked, the completing push carrying only the suffix. A PARTIAL_FRAME-capable decoder then chews slices concurrently with the remaining network transfer. The reassembler walks a per-frame cursor over successfully-completed blocks (failed FEC reconstructs don't advance it), coalesces blocks that finished out of order into one part, keeps probe filler whole, and stops short of the final block so the zero-padded tail still trims at completion. Whole-frame consumers see byte-identical behavior - parts never flow without the opt-in, and never on PyroWave (its newest-wins draining assumes whole AUs). Per-AU accounting keeps its units: OWD/ABR feeds, the inter-arrival series and the clock-based jump-to-live detector only count completing deliveries, and FrameChannel::depth() counts AUs so a part-rich queue can't trip jump-to-live at a fraction of the real backlog. The consumer contract (gap or orphan part = AU lost: abandon, flush, resync on the next first) is documented on FramePart; the C ABI keeps parts off until PunktfunkFrame can express them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 14:14:46 +02:00
enricobuehlerandClaude Fable 5	8e396b8391	feat(cli): every command explains itself ... `punktfunk help` was one usage blob, and `punktfunk pair --help` was worse than nothing: the flag fell through to the verb, which read "--help" as its subject, printed a terse usage line to stderr and exited 5. For the command that is about to be the documented door for scripts and plugins (Playnite shells to `library --json`), "self-documenting" has to actually hold. Now `punktfunk help <command>` — and `--help`/`-h` after any verb, caught BEFORE dispatch so no verb can mistake the flag for its subject — prints that command's own page: flags, what lands on stdout vs stderr, and which exit code means what, which is the part a script author actually needs. Help goes to stdout and exits 0; an unknown topic refuses with 5. A unit test walks USAGE and asserts every advertised verb has a help page that leads with its own invocation, so the overview and the pages cannot drift apart, and an integration test runs the REAL binary over both spellings. `reachable` also stops scolding: probing an unsaved address is that verb's documented use, but it resolved through the saved-host path first, whose "pair it first" advice printed before the probe ran. It resolves quietly now — same lookup, no lecture. Verified on the Windows CI runner (clippy -D warnings, fmt, 8/8 tests, and the built punktfunk.exe by hand: overview, per-verb pages, quiet `reachable` exit 2) and in the Linux CI image (same gates, 8/8). One field note from the hand run: the exe needs the FFmpeg DLLs beside it or on PATH — true of the session binary already, and the MSIX ships them next to both, so packaging is unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 10:58:44 +02:00
enricobuehlerandClaude Fable 5	9b2404a580	feat(core): every connect introduces the device by name ... The wire always had Hello.name and the host always honored it - but the connect path hardcoded None (only the PIN-pairing ceremony sent a name), so every no-PIN "request access" knock surfaced as the fingerprint placeholder "device abcd1234", and approving one without retyping a name persisted that placeholder into the trust store forever. NativeClient::connect now takes the device name. The session workers and the probe connects pass trust::device_name() (the hostname), the C ABI defaults to the same without a signature change (an ex10 variant can make it explicit if an embedder wants a custom label), and Android threads Build.MODEL through nativeConnect - the same convention its pairing dialogs already use for nativePair. The host, in turn, resolves the streaming client's display name (trust store first, so an approval-time rename wins; else the sanitized Hello name) and exposes it as client_name in GET /api/v1/local/summary for the tray's connect toast - a deliberate, documented loosening of that route's "no device names" contract, in the local user's favor: it tells them who is on their machine. A paired-but-idle device's name still never appears, which the mgmt tests now pin explicitly. openapi.json, its docs-site copy, and the SDK bindings regenerate. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 21:32:50 +02:00
enricobuehlerandClaude Fable 5	944c03dd32	feat(client): the desktop clients wear the host's OS mark ... The client half of the host's new `os=` advert, shared once in pf-client-core: `sanitize_os` (mDNS is unauthenticated input — lowercase `[a-z0-9._-]` tokens, capped) and `os_icon_tokens`, the most-specific-first walk with the brand aliases (`macos`→apple, `steamos`→steam) every platform resolves through. `DiscoveredHost` carries the chain, `KnownHost` persists it (`serde(default)`, elided when empty — older stores load unchanged and older clients read back exactly what they wrote), `upsert` moves it only when carried, and `learn_os` mirrors `learn_mac` — no-op, no disk write when unchanged — so the mark survives the host going to sleep. GTK shells: the card's status row leads with a recolorable symbolic glyph. That needed real embedded assets — the shells had none — so `data/` gains the ten `pf-os-*-symbolic` SVGs compiled into a gresource (new build.rs, glib-build-tools) and registered on the icon theme at startup; the Adwaita theme then tints them like every other status glyph. WinUI shell: reactor renders raster-from-URI only, so the embedded mid-gray PNGs (legible on both themes) materialize once into %LOCALAPPDATA%\punktfunk\os-icons\ — the library's poster-art pattern — and the tile's status row leads with a 16px image. The couch UI plumbs `HostRow.os` (live advert preferred, else the store) for a Skia glyph that is a declared follow-up; `--list-hosts` / `hosts --json` emit the stored chain so the Decky plugin can read it. A host that advertises no `os` renders everywhere exactly as it did before the field existed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 17:58:33 +02:00
enricobuehlerandClaude Opus 5	f32c3aaa71	feat(session): spec mode — the renderer stops resolving policy and stops writing settings ... C2 of design/client-architecture-split.md, and the last of the session's overreach. `--resolved-spec <path>` hands the session everything it needs already resolved — effective settings, the host's clipboard decision, the profile's name — and in that mode it performs ZERO store reads. It had been re-deriving all three, which meant policy was being evaluated inside the thing that draws pixels, and that the spawner and the child could disagree about a file either of them might have written in between. First-party spawns (the shells, the CLI) always pass one now. The compat path stays for hand-run `punktfunk-session --connect` and old Decky scripts — but it calls the SAME helper, so the two modes cannot drift; it is the identical function invoked in-process instead of by the parent. A spec that is named but unreadable fails loudly rather than quietly falling back: a spawner that asked for exact settings must not get store-derived ones instead. The match-window write-back is gone too. The callback used to load-modify-save the shared settings file from inside the renderer — one of that file's five concurrent writers, for a value only the parent needs. It now reports `{"window":{w,h}}` on stdout and the spawner persists it, on a real change only. A hand-run session still persists its own window, because nobody is listening to its stdout there and the event alone would drop the value. Verified on .21: a spec naming a profile that doesn't exist in the catalog is honoured (proving no lookup happened), a missing spec errors instead of falling back, and the CLI's spec file is written and cleaned up per launch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00
enricobuehlerandClaude Opus 5	0594056e02	feat(cli): punktfunk — one headless front-end over the brain ... C1 of design/client-architecture-split.md. There were four overlapping, none-complete CLIs: the Linux shell's rich headless verbs, the Windows shell's near-none (it could not start a stream at all), the session's own, and punktfunk-probe's diagnostics. This is the one a script or a plugin should reach for, and it is a FRONT-END, not the brain — policy stays in `pf-client-core` and the GUI shells keep calling it in-process. Shelling out for connects would have traded duplicated code for a duplicated IPC protocol. punktfunk pair | hosts list/add/forget | wake | library | launch | open reachable | speed-test | profiles list | reset Because it runs the same plan builder and the same wake machine as a card click, `launch` and `open` WAKE A SLEEPING HOST — which the Linux shell's exec-style `--connect` never did; it fired a packet at best and dialled into the void. Host references resolve through the shared `resolve_host`, so `punktfunk launch desk` and `punktfunk://connect/desk` cannot disagree about which box "desk" is. Exit codes extend the session's contract so a consumer can branch without parsing prose: 0 ok, 2 connect, 3 trust, 4 renderer, 5 nothing matched what you named, 6 refused because it needs a person. That last one is why `pair` and `reset` check for a terminal before prompting — a CLI that blocks a CI job on a hidden question is a hang, not a UX. Two deliberate non-features. `speed-test` measures and prints but does NOT apply: which layer a bitrate belongs in is a decision the GUI makes with the user (global vs the bound profile), and a CLI silently rewriting a profile is exactly the surprise that rule exists to prevent. And `open` refuses an unknown host rather than pairing it — a URL may never pair or trust on its own, at any surface. `library` keeps TSV as its default output because that is what Decky's consumer parses; `--json` is the door for tools, and the Playnite importer shells to exactly that. The existing shell flags are untouched: they are a frozen compat contract until Decky migrates. Verified on .21 against hand-authored stores: hosts list (TSV and JSON, with each host's resolved profile and pins), profiles list, a launch honouring the binding ("Game"), a one-off overriding it ("Work"), the same through `open` with `profile=`, and the refusal codes (6 for an unknown host, 5 for `punktfunk://pair/...`). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 01:16:17 +02:00