What it is
A reference, not a template. mani shows the stack working; shashki shows what happens when the same stack is asked to do something with money, maps, real-time positions and a design kit it did not choose — a ride-hailing service, two Compose Multiplatform bundles compiled to Wasm, a Ktor server holding two sagas, and eleven of the libraries on this site doing load-bearing work rather than appearing in a dependency list.
It is a demo the way a wind tunnel is a demo. Nothing here is deployed for the public; what it produces is the list below.
The seams, which is the point
Three mechanisms were built at both ends and joined at neither — and none of them was found by a test. Backend-driven screens had a renderer on the client and a tree on the server with nothing between them; the settlement had a capture, a receipt sender and a payout ledger, each written, tested and constructed by nobody; sign-in had PKCE on one side and a validator on the other, and the application called neither. Each was found by asking whether something was called, which is a question a green test suite never asks. A fourth arrived from the running stand: a driver who finished a ride stayed reserved for the life of the process, while the rider's screen kept showing a wait for that car — two answers to the word "available", computed in two places and compared nowhere.
The map had to be drawn. No published library renders vector tiles in Compose for Kotlin/Wasm, so the product reads pmtiles over ranged HTTP, decodes MVT, and paints roads, water and labels in Compose itself. That is not a boast: it is the reason the browser target survived at all, and the style is a transcription of two style documents rather than an engine that interprets them.
The saga was killed at every phase boundary. For both sagas, at each boundary, the test asserts what a dead process must not leave behind: no held payment, no reserved driver, no event escaping a saga that never completed, and nothing captured twice.
The screenshots are the tests. Every screen on this page's repository is a golden recorded on a Mac and verified byte-for-byte on Linux inside the ordinary check; the light theme doubled the suite and its first light picture of the offer card found a fare at 2.11:1 on white.
One number per claim
| Claim | Number | Where it comes from |
|---|---|---|
| routing on the city's own graph | 2.57 ms median, 6.6 ms worst of 201 | CityGraphMeasurement, research §1.6e |
| the image's start-up | 1.5 – 3.7 s to healthy, of which the road graph is 0.18 – 0.40 s | three restarts of the container, B-35 |
| observability, checked against itself | 8 = 8 = 8 — requests sent, metrik's delta, tracy's spans | B-39, on the stand |
| goldens across hosts | 0.19 % of pixels on one extra character, against a 0.05 % tolerance | B-02 |
| the design kit's light theme | 2.11:1 for the offer card's fare on white — the defect the light goldens found | B-48 |
Every number above is traceable to a backlog item or a research section by name, and each of the fifty-two items ends with a section called What it turned out to be.
The stack, and what is not in it
| Library | In shashki | How |
|---|---|---|
| kvadrant-ui | used | the base of every screen; two hooks were added to it for the design kit |
| viddik | used | the acceptance gate — goldens inside check, and the Wasm suite in a headless browser |
| petich | used | two sagas on one engine, killed at every phase boundary |
| booblik | used | a ride's events out of the outbox, one consumer sharing nothing with the saga |
| kompot | used | one screen the server owns, and a degradation sink that reports what a client could not draw |
| shildik | used | both bundles sign in; the rider's and the driver's routes are behind the token |
| katcher | used | browser crash reports over the ingest endpoint, no client library needed |
| metrik, tracy | used | named spans per saga phase, and the two collectors checked against each other |
| smtpkn | used, on the JVM | the receipt — its first JVM consumer |
| bochka | a host, not a dependency | it serves the tile archive over public ranged HTTP; the browser is the client, and a Kotlin client would have nothing to do |
| s3kn | not in the graph | the same finding as bochka's, from the other side: the one scenario left for it is driver onboarding, and that is an open question rather than a plan |
| telek | not used | it builds Telegram bots as state machines; alerting is metrik's own notifier. An item assumed otherwise and had to say so |
What it does not show
An empty backlog is not a finished product, and the repository says where the edge is.
One replica, because the geo-index and the offer board live in one process — the chart refuses replicaCount > 1 rather than defaulting to 1 with a comment. No real driver position: the driver bundle sends its configured point and says so on the screen. 569 MB of image, of which the process needs about a third. A renderer, not an engine: a third map style would be code, not configuration. And no hosted instance — what exists is docker compose up and an image tagged with the commit that built it.
Of the design kit's eighteen screens, the product now draws about twelve. The rest are items, with the mechanism behind each one named.
Where to look first
github.com/youndie/shashki, and inside it the research document, which is the thing this repository is really about: four of the brief's assumptions turned out to be wrong when checked, and each is recorded next to the artefact that disproved it, with the wrong idea left standing beside its correction.