Completes the wave — all six library sources are now pinned.
gog 0.1.0 is published but CANNOT SEE A SINGLE GAME on any machine: the kit's
regSubKeys built its match prefix from the abbreviated HKLM\... key it was
handed, while reg.exe always echoes HKEY_LOCAL_MACHINE\..., so it returned [].
0.1.1 is the first build that works, on plugin-kit 0.3.2.
Verified on .173 against a live host with the PUBLISHED 0.3.2 (clean install),
this plugin unregistered so the host was still on its built-in scanner:
detect present (was absent), scan 1 games (was 0), and the id, title, launch
recipe and metadata all match the built-in scanner exactly.
Parity reports art.hero/logo/header changed, and that is EXPECTED rather than a
loss: this plugin deliberately emits no art, the host's own built-in gog scanner
does not read art from disk either (it attaches cached_art), and a background
pf-art-warmer thread resolves art host-side every 300s for exactly gog and xbox
because the other stores carry their own. Entry ids are byte-identical, so the
warmer repopulates these entries just as it did the scanner's.
reviewedAt stays unset — still the reviewer's to write.
Fortnite finished installing on .173, so the gate could finally run. Its manifest
is now in Manifests\ with bIsIncompleteInstall=False and the folder has real
content (Engine, FortniteGame); disk went 24.6 GB -> 69 GB free, which was the
actual blocker all along.
Parity against the live host, this plugin unregistered so the host was still on
its built-in scanner:
scan: present: 1 games, 0 launcher entries
parity: OK - 1 entries identical
exit: 0
Note the 0 launcher entries: unlike lutris/heroic/steam/playnite, this plugin
publishes no launcher tile. Nothing is wrong - it simply does not implement the
kit's launchers() hook.
minHost 0.25.0 is deliberately conservative. The `epic` launch kind this plugin
emits IS already in v0.24.0 (ecfa7121), and it sends no role/launcher_ui, so a
lower floor is probably correct - but it has only ever been verified against a
main-build host, so the floor is what was actually tested. Too high only delays
availability; too low breaks installs.
platforms is [windows] - it reads %ProgramData%\Epic\EpicGamesLauncher\Data\Manifests.
Still NOT pinned: gog (no hardware yet) and xbox (structurally cannot see
pure-UWP Game Pass titles - see the PR body).
Published and parity-verified. Run against a live host on .21 with this plugin
unregistered, so the host was still on its built-in scanner:
scan: present: 5 games, 1 launcher entries
parity: OK - 5 entries identical (+1 expected steam:big-picture tile)
That box has 10 appmanifests; 5 are real games and the rest are Proton and
redistributable tools the kit's isSteamTool filters. Both sides independently
produced the same 5 - the strongest parity sample of this wave (lutris and heroic
were n=1 each).
minHost 0.25.0 like the others: the launcher tiles need the role/launcher_ui wire,
which no released host has yet.
platforms is [linux, windows] because the kit's steamRoots() handles both (Program
Files + the HKLM InstallPath on win32, POSIX homes otherwise). ONLY THE LINUX ARM
HAS BEEN EXERCISED - the Windows path is untested.
epic, gog and xbox are published too but are deliberately NOT here: none has a
green parity run. .173 has no Epic game installed (Fortnite is an incomplete
download - 83 GB wanted, 24.6 GB free) and no GDK game at all, so there was
nothing for either to reconcile against.
reviewedAt stays unset - still the reviewer's to write.
All three are published and their integrity hashes cross-check against the live
registry (`bun run validate`: 5/5 ok). What is NOT done is the part only a person
can do, so this PR is deliberately RED.
* playnite 0.3.0 -> 0.4.0. The published 0.3.0 emits launch.kind = "command"
for every game, which the security review made operator-only, so on a host
carrying that change it syncs nothing at all. 0.4.0 publishes through the
host-owned `playnite` kind instead, and adds a fullscreen launcher tile.
* lutris 0.1.0 and heroic 0.1.0, both first releases. Parity verified against a
live host on .21 for each (lutris: 1 entry identical; heroic: 1 entry
identical). lutris only works at all on plugin-kit 0.3.1 — the kit's SQLite
reader never opened a database on Linux before that.
minHost is 0.25.0 on all three, NOT the 0.15.0 the older entries carry. Measured
against tag v0.24.0, the latest release: it contains neither 6f07bd94
(role/launcher_ui), nor 8ff2c2e1 (the playnite launch kind), nor 81039581 (the
operator-only command rule). So on a released host today, the currently pinned
playnite 0.3.0 still WORKS and 0.4.0 would not, and lutris/heroic launcher tiles
would be refused. 0.25.0 is the release that carries the wire; minHost is exactly
the field that keeps these entries from being offered before it exists.
verification.reviewedAt is unset on all three — including playnite, whose
2026-07-27 date attested to 0.3.0 and must not ride along to a different build.
The validator requires the field, so this cannot merge until a human reviews each
published tarball and dates it. That is the intended gate, not an oversight: a
merge here ships code to every host that trusts this index, under unom's key.
New plugin: hands a physical USB device on the couch to the host for the length of a session
and gives it back after, by driving a separately-licensed VirtualHere client. Nothing from
VirtualHere is bundled or downloaded.
Pinned integrity verified independently against the registry tarball, not only via CI.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0.3.0 teaches the provider to report where a game is installed. Each exported
entry now carries `detect: { install_dir }` when Playnite knows one, which is
what lets the host recognize a title's process after Playnite's launcher hands
off and exits — the case where the host would otherwise lose the game the
moment the shim returns, and end the session with it.
The published delta is exactly that, and nothing else:
* `installDir` added to the exported-game schema (nullable, defaults null),
threaded into the entry as `detect.install_dir` when non-blank.
* `@punktfunk/plugin-kit` ^0.1.4 -> ^0.2.0.
* The version bump, embedded in both bundles.
The console UI rebuilt because plugin-kit moved, but did not change: the diff
against 0.2.0's chunk is minifier identifier churn (`Rt`->`kt`, `ar`->`lr`)
with zero prose added or removed, so there is no new user-visible text and no
new behaviour. Fonts and CSS are byte-identical.
No new outbound hosts. Every absolute URL in the tarball is a schema/XML
namespace, the plugin's own homepage and registry, or an effect/react error-doc
link — no telemetry, no beaconing. No install lifecycle scripts (`prepublishOnly`
is author-side and unchanged). No `eval`, `new Function`, or `child_process` in
any bundle.
minHost stays 0.15.0. The new `detect` key is additive and optional on the host
side (`#[serde(default)]`, and the host denies no unknown fields), so 0.3.0 on a
pre-`detect` host simply behaves like 0.2.0 rather than failing to ingest.
Integrity was fetched from the registry and independently recomputed from the
downloaded tarball; both agree.
Both entries were stale — the index still pinned rom-manager 0.3.1 and
playnite 0.1.1 while the registry had moved on.
rom-manager 0.3.2 is a bug-fix release: the API encoded absent optional fields
as `null`, which the UI's own decoder then rejected, so the Overview page broke
on a never-synced host and the Emulators page's Detect button broke on any box
with an emulator installed. The published delta is exactly that fix plus the
version bump — no new files, no new outbound hosts.
playnite 0.2.0 is a ground-up rewrite onto @punktfunk/plugin-kit: three
workspaces, a three-page console UI, per-game include/exclude overrides, and an
allow-listed cover-art proxy. Behaviour that matters is preserved verbatim — the
ingest inbox is still read first, the art modes are unchanged, and launches
still hand back to Playnite. The bundled C# exporter is untouched (same wire
schema), so an installed .pext keeps working.
Also: playnite's card icon now matches the icon the plugin registers for its own
console nav entry (`library-big`), and both descriptions mention the console UI.
minHost stays 0.15.0 for both — neither release needs anything newer from the
host than the plugin-UI surface and the ingest inbox already provide.
The previous key was pasted into unom/punktfunk's secret store rather than
this one. Gitea secrets don't cross repos and can't be read back, so that
key was unusable here and is abandoned; INDEX_SIGNING_KEY on THIS repo now
holds the private half of the key pinned below.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The bootstrap key generated during implementation was lost with its scratch
directory. Nothing shipped pinning it, so this is a straight replacement of
slot 0 rather than a rotation — the second slot stays reserved for a real one.
The private half now lives only in the INDEX_SIGNING_KEY secret, so CI is the
only thing that can sign. This push is what makes it do so: the committed
signature is still the old key's, and the verify self-check will fail loudly
if the secret does not match the public key pinned here.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed locally with the key whose public half the host pins. ed25519 is
deterministic, so the publish workflow re-signing this exact document with
the same key produces byte-identical output — this is the bootstrap for a
repo whose CI secret is not yet configured, not a parallel signing path.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The catalog the Punktfunk plugin store fetches. Served straight out of this
repository over Gitea's anonymous raw endpoint:
https://git.unom.io/unom/punktfunk-plugin-index/raw/branch/main/v1/index.jsonhttps://git.unom.io/unom/punktfunk-plugin-index/raw/branch/main/v1/index.json.sig
Hosts verify the ed25519 signature against a compiled-in public key and only
then parse. Verified that the raw endpoint serves blobs byte-for-byte, which
the signature depends on; .gitattributes pins LF so a Windows checkout cannot
break it from the other direction.
Entries pin one exact version plus that version's registry tarball integrity
hash -- no ranges, no "latest". A plugin author publishing a new version
changes nothing for users; the new version becomes installable only when a
reviewer works the checklist and lands a new pinned entry here. That data
shape is what makes "verified on every release" enforceable rather than a
promise.
Seeded with the two first-party plugins, both integrity hashes confirmed
against the live registry:
- @punktfunk/plugin-rom-manager 0.3.1 (linux, windows)
- @punktfunk/plugin-playnite 0.1.1 (windows)
Tooling (bun + TypeScript, node builtins only):
- validate: every field rule the host enforces, plus a live registry
cross-check that the pinned version exists and its dist.integrity matches
the pin. Strict on unknown keys, since the host silently drops entries
that fail validation -- a `min_host` typo would otherwise ship as a
missing version floor with no error anywhere.
- sign / verify / keygen: ed25519 over the exact bytes of index.json.
keygen never prints the private key; verify defaults to the host-pinned
public key so an index can be audited with no arguments.
CI splits by trust: pull requests run validate only and hold no secrets, so a
fork PR can never reach the signing key or a token that can write to main.
Publishing from main validates, signs, self-verifies, then commits the
signature back. The loop guard is a paths-ignore filter on v1/index.json.sig,
with a [skip ci] marker as a second line of defence; ed25519 determinism means
an unchanged index re-signs to identical bytes and commits nothing at all.
CI signs after the merge, so there is a brief window where index.json is newer
than its signature. It fails closed -- hosts reject the document and keep
their last good cached catalog -- and is documented as such in the README.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
enricobuehler
unom-bot
enricobuehlerandClaude Fable 5