Go to file

Yashas 171aa4c2fa console: a live trail, faces for the agents, and the thread as a thread Five of the six asks. The sixth — the whole row as the click target — shipped in `704afe1` and is already live on both grids. THE AUDIT TRAIL WAS FROZEN. Timeline fetched the rows once on mount and never again, so a lead being worked by five agents in three minutes showed the trail as it was when the page opened — on the one screen whose job is watching work happen. The rows move to the lead page, which already polls every 12s, and Timeline becomes presentational. One fetch, one poll, and the conversation view reads the same rows so the two cannot disagree. THE ACCEPTANCE BUTTON OUTLIVED THE ACCEPTANCE. Recording an acceptance twice is not a loop, a recovery or an alternative — it is meaningless, and offering it invites someone to overwrite a customer's WhatsApp acceptance with a worse record of the same event. Gone once acceptance_ref is set, replaced by a line saying who accepted and when. THE AGENTS HAD NO FACE. Five of them carry this workflow and the console named them three different ways — "ai_engage" here, "Engage" there, "Engage AI" elsewhere — so nobody could see that the thing which called the customer and the thing which wrote the quote were one worker. One roster now (api/agents.js): a short name, a colour and two initials each, used wherever an agent is named. People get a disc too, in grey — a trail where the machines are decorated and the humans are plain text reads as though the machines are the important ones, which is backwards on a screen built for oversight. A "Worked by" strip above the trail shows the team at a glance. THE CONVERSATION WAS A LOG, NOT A THREAD. Each turn sat as its own entry among twenty others. Now one button opens it as a thread — theirs left, ours right, oldest first — and the footer says plainly which parts it holds: the quote, the read receipt and the acceptance confirmation are sent by trigger nodes and never written to a field, so they are not there. A thread that quietly omitted them would be worse than one that admits what it is. CONFIRMING A PREMIUM IS A SIGN-OFF, NOT A TASK. It is the only step locked to one role and the only one that touches money — an employee that could mark a premium received could put a customer on risk for a policy nobody paid for. It sat fourth in a list of six queues. It gets its own band now, shown only to the role that owns it, amber only when something is actually waiting: a permanent alert colour on an empty queue teaches people to stop seeing it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-09-08 15:29:02 +05:30
public/brand	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
src	console: a live trail, faces for the agents, and the thread as a thread	2026-09-08 15:29:02 +05:30
.env.example	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
.gitignore	Updated to new frontend specifications	2026-09-04 13:26:20 +05:30
CLAUDE.md	Updated to new frontend specifications	2026-09-04 13:26:20 +05:30
eslint.config.js	Empty vite-react project	2026-08-24 12:27:21 +05:30
index.html	fix(build): add BASE_HREF placeholder + config.js tag to index.html	2026-08-24 15:47:26 +05:30
package-lock.json	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
package.json	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
README.md	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
vite.config.js	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30

README.md

Zurich Kotak — Lead Desk

Operator console for the Zurich Kotak "Lead to Policy" demo. Leads arrive through three channels — direct, bancassurance and agency — and run one state machine to policy issuance. The agents do the work; a person appears at one queue.

Workflow config is seeded from sm2/custom-apps/zurich-kotak/ (org 84, app 536, workflow zk_wf_lead). Design doc: sm2/app-designs/zurich-kotak/design.html. Workflow spec PDF: sm2/custom-apps/zurich-kotak/zurich-kotak-workflow.pdf.

Run it

npm install
npm run dev          # http://localhost:5175
npm run build        # → dist/

.env carries the API host for local dev only:

VITE_ZINO_API_URL=https://dev.getzino.in

Logins (all password ZurichKotak@2026, org 84):

Email	Role	Can do
`sanjay.uw@zurichkotak.example`	SME Underwriter	Clear / Decline Referral — the only human decision
`meera.rm@zurichkotak.example`	Bancassurance RM	Submit a Partner Bank Lead
`arjun.posp@zurichkotak.example`	POSP / Broker	Submit a Partner Agent Lead
`kavya.csr@zurichkotak.example`	Direct / Call centre	Submit a Self-Serve Lead
`deepa.ops@zurichkotak.example`	Operations	Cross-channel visibility

How it talks to the platform

Everything goes through src/api/client.js:

POST /usr/login — auth. org_id must be a string; a number returns cannot unmarshal number into Go struct field LoginRequest.org_id.
POST /app/536/view/recordview — every queue is one record view (zk-rv-leads) filtered server-side on current_state_name.
POST /app/536/view/form-screens then POST /app/536/activity — forms are read from the live activity schema and submitted straight back.

Forms are not defined in this repo

Whatever /view/form-screens returns is what renders — labels, types, select options, which fields are mandatory. Add a field to an activity in Studio, redeploy, and it appears here with no frontend change. That is deliberate: the workflow is the source of truth, and a hardcoded form would quietly diverge from it.

Permissions are never enforced here

The console does not hide a button to stop someone using it. Every permission decision is the workflow's, made server-side on each submission — the platform refuses and this app reports what it said. Two refusals worth knowing: /activity answers 403, /start answers 400, and both carry permission denied.

The runtime-config contract

VITE_ZINO_API_URL is read at runtime from a config.js the server writes when it places the build — never compiled in. One artifact is promoted between environments unchanged, so a build-time URL would point every environment at whichever backend happened to build it. requireConfigValue throws if it is missing, so a production build with no config.js fails loudly rather than calling the wrong backend.

vite.config.js uses base: './' and the router takes its basename from the <base href> the server writes, so one build serves any mount path. Do not reintroduce a build-time base.

This is also why the fonts and logo live under src/assets/ and not public/. Vite rewrites bundled asset URLs to be relative; a public/ file referenced as /fonts/… stays absolute and 404s under the /zurich-kotak/ mount path. The favicon is the one exception — it stays in public/brand/ and is referenced relatively from index.html.

Deployment

Registered with frontgen by sm2/custom-apps/zurich-kotak/05_frontgen_project.sql (slug zurich-kotak, repo_name zurich_kotak, org 84). A push to main builds and serves at https://preview-dev.getzino.in/zurich-kotak/.

The webhook only fires on a new push — a push made before the frontgen project row existed matched no project and did nothing.

State of the build

Piece	Status
Brand — Zurich Sans, palette, logo	done (kept from the original scaffold)
Sign-in against the real gateway	done
Runtime config, relative base, router	done
Pipeline sidebar (mirrors `tbl_wf_states`)	done
Queue lists	waiting on the `zk-rv-leads` record view
Lead file, activity forms, attribution panel	waiting on `zk-dv-lead` + form screens