ZQ Engine
A desktop engine that launches everything
The lifecycle, walked through
The real rules the kernel runs my machine by, stage by stage.
declared
One schema describes anything the engine can run: how to launch it, how to know it is ready, what surface it shows, what services it needs, what capabilities it may use, what policies govern it. A wallpaper widget and a database backend are the same kind of citizen.
An interactive walkthrough of the engine's real lifecycle rules, taken from its build records. It is deliberately not a live feed: the engine runs on my desktop, and this site will not pretend otherwise.
ZQ Engine is the desktop engine that runs my whole local setup: a light, always-on Electron app that launches, supervises and surfaces every project from one place. The shorthand I use for it is a Steam client for my own software.
At its core is a kernel with one manifest schema. Anything I want it to run (a web app and its dev server, a script, a scheduled agent, an external tool, a desktop surface) is described by the same six composable blocks: how to launch it, how to know it is ready, what surface it shows, what services it needs, what capabilities it may use, and what policies govern it. There is no privileged type of thing; a wallpaper widget and a database backend are both just runnables.
The wallpaper trick
Its most visible feature is the desktop surface layer: the engine can render an app as the live Windows 11 wallpaper, sitting behind the desktop icons, with real hit-testing so widgets are clickable exactly where they should be and the desktop stays usable everywhere else. My wallpaper shows live server status, agent schedules and system health, rendered by the engine itself. The recipe (the WorkerW window layer plus a low-level mouse hook) is written up in the devlog.
Supervision that learned humility
The engine's process supervision got its scars honestly. Its original health model polled apps over HTTP, and one hardcoded timeout caused it to kill a perfectly healthy app whose first render was legitimately slow. The postmortem led to a redesign: apps now push their readiness and heartbeats to the engine over a loopback report rail, and the reaper never kills anything for a single missed beat. Both the bug and the redesign are devlog stories.
Beyond launching, the engine owns scheduling (cron-style agents with missed-run catch-up), adopts externally-started servers it discovers, and keeps an activity ledger. It runs at boot and has quietly become the thing everything else here stands on.