the published face vs the forward path

The runtimes today

Two runtimes serve the issue tracker. A static HTML renderer is live now. The server-driven-UI stack is the forward path. One is the destination, one is the rollback, and they share the same store.

Two runtimes, one tracker

The issue tracker has two runtimes. One is live now; one is the forward path. Knowing which is which is what keeps a deploy safe.

The published face: a static HTML renderer

issues.kinogaki.com is served by a static-HTML renderer. It reads the .prisma issue Documents and writes a multi-page site, the same way every docs site is built (see the docs topology). It has no socket and no live edit: it is read-only and fast, and it is what the public sees today. A commit to the issue store pulls on the server and rebuilds the pages.

The forward path: the server-driven-UI stack

poc.kinogaki.com runs the server-driven-UI loop: a Python server pushes view-Documents over a WebSocket to the Kinogaki UI board compiled to WebAssembly. It reconnects, diffs, reconciles in place, takes keyboard input, and writes new issues back. This is where the tracker is going: an interactive app, the same view rendered natively by kinogaki run.

Destination and rollback

The server-driven-UI stack is the destination: the interactive, two-faced app. The static renderer is the rollback: if a live deploy ever shows something wrong, the server reverts to serving the static board, which never stopped working. The two share the store, the same .prisma Documents, so switching faces never touches the data. The forward path adds interactivity; the data layer underneath is the same Prism it always was. That is the through-line of the whole architecture: the model is stable, and the faces over it can change without risking the file.