ReviewOS

reviewos/app

public
Clone

Push over the same URL. A password will not work: create a token under access tokens and use it in place of one.

A native desktop client for ReviewOS — review, stage and commit without leaving the machine. Built with stx and craft.

main · 28 commits

Mirrored from ReviewOS/app · synced 11 minutes ago

README.md

ReviewOS

A native desktop client for reviewing, staging and committing work, built with stx and craft.

It is laid out like GitHub Desktop — a chrome of four segmented controls over a list pane and a diff pane — with one difference: the left rail is stx's Arc sidebar, and each open repository is a space. Spaces carry their own colour, so switching repositories is a swipe and the panel tells you where you are before you have read anything.

Not Electron. The window is a real WebKit view driven by Craft's Zig binary — and the same binary puts the same app on a phone.

On a phone

bun run ios starts the server, has Craft generate an Xcode project pointed at it, and installs and launches the app on a simulator. It is the same server, the same session and the same .stx views as the window: a file staged on the phone is staged in the window, because there is only one of each.

What differs is the layout. /mobile is a large title, a row of filters that scrolls sideways, one dense list and a bar at the bottom — built out of the mobile primitives in @stacksjs/components (NavBar, FilterChips, SectionCard, ListRow, TabBar) rather than out of this application's own markup, because a tab bar is not a ReviewOS idea. A request to / from a phone lands there on its own; both layouts stay reachable by URL either way.

The phone layout needs neither Xcode nor Craft to look at: bun run serve and open /mobile in any browser. bun run ios is what turns it into an app, and it needs Xcode with an iOS runtime — xcodebuild -downloadPlatform iOS if craft-ios reports that there are no simulators.

Running it

pantry install && bun install && bun run start

bun run start opens the repository in the current directory. To open another:

bun run start --repo ~/Code/some-project

Other entry points:

CommandWhat it does
bun run iosBuilds the iOS app and runs it on a simulator
bun run devSame, with the webview inspector and hot reload
bun run serveStarts the server with no window, for driving from a browser
bun run testRuns the suite
bun run lintLints with pickier

How it is put together

src/
  git/       git, wrapped — status, log, diff, branches, and the writes
  server/    the local HTTP server, the session, and prop shaping
  views/     the .stx templates the panes are rendered from
  client/    the webview's only script

Three ideas carry most of the design.

Only the server renders. The panes are .stx components, and every interaction re-renders them on the server and swaps the fragment in. The client does not build any markup. That is what keeps the tenth interaction identical to the first paint — there is no second renderer to drift.

Selection lives on the server. One window, one process, one session. The checkbox state the user sees and the set of paths a commit will include are the same object, so a stale page cannot commit a selection the current view never showed.

git is spoken to in argv, never in a shell string. Every call goes through one module, with --porcelain=v2 and NUL-separated output, so a branch called --upload-pack=… or a path with a newline in it is an argument rather than syntax.

Requirements

Everything comes from pantry; see deps.yaml.

  • bun 1.4
  • craft — the native webview binary, on PATH
  • git 2.47 or newer, for --pathspec-from-file and worktree porcelain

Licence

MIT.