A separate app from the desktop console, talking to the same platform with the same client. Not a breakpoint on the old one: the two answer different questions. The console answers "what is the state of the book?" across a wide grid; a phone answers "what needs me, and what happened to this one?" in a column you scroll with a thumb. The old console at 390px showed why. Tables scrolled sideways, nine queues stacked above the content ate the first screenful, and the action you came to perform sat below the fold. So every row of every table is a CARD — customer, stage, when it is due, who is holding it, and one line about what is happening. Everything else is one tap away. The queues live in a drawer. The action a lead is waiting on is pinned to the bottom of the screen, where a thumb already is. Shared with the console, because a divergence would be two apps disagreeing about the same lead: the whole api/ layer, ActivityForm, and Timeline — whose audit-row merging (one submission writes three rows) is hard-won and must not be reimplemented twice. Written fresh: the shell, the three screens, and the stylesheet. The colour rule is unchanged and is the product in four colours: blue the AI holds it, amber a person, teal the customer, red risk and nothing else. A PWA, so Add to Home Screen gives a full-screen app; the layout pads for the notch and the home indicator. Verified at 402x874: login, overview, drawer, a queue, and a lead, with no horizontal overflow on any of them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.5 KiB
Zurich Kotak — Lead Desk (phone)
The renewal desk on a phone. A separate app from the desktop console
(zurich_kotak), talking to the same platform with the same API client.
Why a second app rather than a breakpoint
The two answer different questions. The desktop console answers "what is the state of the book?" across a wide grid — six-column tables, a lead beside its record, a rail of queues always visible. A phone answers "what needs me, and what happened to this one?" in a column you scroll with a thumb.
Squeezing the first into 390px produced what it always produces: tables that scroll sideways, a menu that eats the first screenful, and a primary action somewhere below the fold. So the screens are written for the phone, and only the parts that must not diverge are shared.
What is shared, and what is not
Copied verbatim, because it is the contract with the platform — a divergence here would be two apps disagreeing about the same lead:
src/api/client.js every call
src/api/config.js stages, actions, doc slots, the workflow mirror
src/api/permissions.js who may perform what
src/api/portfolio.jsx the one record-view call the queues share
src/api/holder.js who is holding a lead
src/api/lead.js how to read a date, name a field, group the record
src/components/ActivityForm.jsx, FileField.jsx, Timeline.jsx
Timeline.jsx in particular is shared on purpose: its audit-row merging (one
submission writes three rows) is hard-won, and reimplementing it here would
mean two different accounts of the same history.
Written fresh for the phone: every screen, the shell, and the stylesheet.
The colour rule
Unchanged from the console, and it is the whole product in four colours:
blue the AI is holding it
amber a person is holding it
teal the customer is holding it
red risk — and nothing else
A lead that is amber on a laptop must be amber on a phone.
Run it
npm install
npm run dev # http://localhost:5176
VITE_ZINO_API_URL in .env for local dev only. In a deployed build the API
host is read at RUNTIME from the config.js the server writes when it places
the build — never compiled in, so one artifact is promoted between
environments unchanged.
Installing it
It is a PWA: manifest.webmanifest, a standalone display mode, and the navy
theme colour, so Add to Home Screen gives a full-screen app with no browser
chrome. The layout pads for the notch and the home indicator through
env(safe-area-inset-*).