The situation
I run roborev from its global configuration across multiple repositories and
machines, with all of them syncing to one PostgreSQL instance.
I want one simple, self-hosted browser view where I can see current activity and
completed reviews across every project.
What works today, and why it is not enough
PostgreSQL sync already consolidates terminal jobs (done, failed, and
canceled), reviews, and responses from multiple machines. Sync is
bidirectional, so the local TUI can show terminal jobs pulled from other
machines as [remote].
The missing part is a browser view over the central store. There is also no true
global view of active work because queued and running jobs remain local until
they reach a terminal state.
Kata's Web UI is a good model. It
uses Svelte 5, Bun, Vite, and @kenn-io/kit-ui, with a collection view, filters,
and list/detail navigation. Roborev should reuse that component system and those
patterns instead of creating another UI stack. Generic Kata components can be
extracted where there is a clean shared boundary; otherwise the
Roborev-specific views can use the same primitives.
Ask
Add a read-only Web UI backed by the PostgreSQL sync database.
The first version should:
- show jobs from every synced machine and repository;
- separate active and terminal jobs;
- filter at least by repository, machine, and status;
- open a job detail view with review output and basic metadata;
- use the same Svelte/Bun/Vite approach and
@kenn-io/kit-ui components as
Kata;
- embed the built assets in the roborev binary;
- run as one roborev process, without a separate Node application; and
- be easy to deploy next to the PostgreSQL instance.
Active jobs need an explicit design because PostgreSQL only receives terminal
jobs today. Use the smallest reliable mechanism, either machine-owned
active-state snapshots in PostgreSQL or a live daemon path. It must define
heartbeat or stale-state behavior so a dead machine does not leave a job looking
active forever.
The service should bind to loopback by default and document reverse-proxy or
private-network deployment. Built-in authentication, SaaS, multi-tenancy, write
controls, and a new design system are out of scope.
The goal is one small global dashboard for a self-hosted roborev installation.
The situation
I run roborev from its global configuration across multiple repositories and
machines, with all of them syncing to one PostgreSQL instance.
I want one simple, self-hosted browser view where I can see current activity and
completed reviews across every project.
What works today, and why it is not enough
PostgreSQL sync already consolidates terminal jobs (
done,failed, andcanceled), reviews, and responses from multiple machines. Sync isbidirectional, so the local TUI can show terminal jobs pulled from other
machines as
[remote].The missing part is a browser view over the central store. There is also no true
global view of active work because queued and running jobs remain local until
they reach a terminal state.
Kata's Web UI is a good model. It
uses Svelte 5, Bun, Vite, and
@kenn-io/kit-ui, with a collection view, filters,and list/detail navigation. Roborev should reuse that component system and those
patterns instead of creating another UI stack. Generic Kata components can be
extracted where there is a clean shared boundary; otherwise the
Roborev-specific views can use the same primitives.
Ask
Add a read-only Web UI backed by the PostgreSQL sync database.
The first version should:
@kenn-io/kit-uicomponents asKata;
Active jobs need an explicit design because PostgreSQL only receives terminal
jobs today. Use the smallest reliable mechanism, either machine-owned
active-state snapshots in PostgreSQL or a live daemon path. It must define
heartbeat or stale-state behavior so a dead machine does not leave a job looking
active forever.
The service should bind to loopback by default and document reverse-proxy or
private-network deployment. Built-in authentication, SaaS, multi-tenancy, write
controls, and a new design system are out of scope.
The goal is one small global dashboard for a self-hosted roborev installation.