The shell everything later hangs on. An application that opens, shows something, and closes again, plus the choices underneath it that every visible thing will inherit. No remote is involved anywhere in this epic and nothing is read.
It is first because there is nothing to hang an interface on yet, and because these choices are cheap now and expensive once there are screens built on them.
What was chosen
Decided in conversation on 15 August 2026, before any code existed.
- Electron. The reason is the boundary, not the framework: the config codec is TypeScript and must never be reimplemented here, and the library that opens a remote needs Node in the process that talks to it. A shell without Node in its main process pays for that with a sidecar and a second process boundary.
- React, which follows from the component library rather than being chosen on its own.
- Mantine for components. Well stocked enough that a dense interface exists on day one, and its own visual language rather than Material.
- Sass, through CSS modules. Mantine styles with plain CSS and CSS variables rather than a runtime style engine, and it documents a Sass setup, so this costs one helper file and some configuration. No Tailwind and no CSS in JS.
- JSX carries placement only. Spacing, size and position props are fine. Colour, weight, type size, family and alignment are not, because appearance belongs in a stylesheet. Enforced by a lint rule rather than left as a good intention.
What was considered and not chosen
A browser application speaking to the remote directly. Chrome can address HID devices, and the codec is ordinary TypeScript that would run there unchanged, so this is a real option and not a strawman. It would remove the installation problem on every platform at once. It costs two things that matter here: it works in Chrome and Edge only, and file handling gets weaker exactly where this project cannot afford it, since the first thing the application must do with a remote is keep a complete copy of it forever. A backup living in browser storage is the wrong direction for hardware nobody can buy any more.
A different shell to avoid the macOS warning. It does not help. Any application somebody downloads and installs meets the same gatekeeping, whatever it was built with, so this is a signing question rather than a framework question.
The consequence for the architecture is that the layer touching devices and files sits behind one bridge, which is what #8 is for. Done properly, a browser build later is a second back end rather than a rebuild.
What this epic delivers
An application that starts, welcomes you, and quits, built from a checkout by one command and started by double clicking it. Signing and prebuilt downloads are undecided and out of scope, see #11.
Deliberately left out
A splash screen. It earns its place only if starting is slow enough to be annoying, and nobody knows yet whether it is.
The shell everything later hangs on. An application that opens, shows something, and closes again, plus the choices underneath it that every visible thing will inherit. No remote is involved anywhere in this epic and nothing is read.
It is first because there is nothing to hang an interface on yet, and because these choices are cheap now and expensive once there are screens built on them.
What was chosen
Decided in conversation on 15 August 2026, before any code existed.
What was considered and not chosen
A browser application speaking to the remote directly. Chrome can address HID devices, and the codec is ordinary TypeScript that would run there unchanged, so this is a real option and not a strawman. It would remove the installation problem on every platform at once. It costs two things that matter here: it works in Chrome and Edge only, and file handling gets weaker exactly where this project cannot afford it, since the first thing the application must do with a remote is keep a complete copy of it forever. A backup living in browser storage is the wrong direction for hardware nobody can buy any more.
A different shell to avoid the macOS warning. It does not help. Any application somebody downloads and installs meets the same gatekeeping, whatever it was built with, so this is a signing question rather than a framework question.
The consequence for the architecture is that the layer touching devices and files sits behind one bridge, which is what #8 is for. Done properly, a browser build later is a second back end rather than a rebuild.
What this epic delivers
An application that starts, welcomes you, and quits, built from a checkout by one command and started by double clicking it. Signing and prebuilt downloads are undecided and out of scope, see #11.
Deliberately left out
A splash screen. It earns its place only if starting is slow enough to be annoying, and nobody knows yet whether it is.