Go to file

Yashas 6df594f0b4 Render file and OCR fields as uploads, not text boxes Collect Documents shipped with every document field rendering as a plain text input — ActivityForm had no case for `file` or `ocr`, so they fell through to the default. There was a form asking you to type an RC book. Uploads happen ON PICK rather than on submit, because /ocr-extract takes a REFERENCE to a stored file: the document crosses the wire once, it survives a reload (a draft cannot carry a File), and re-extracting costs no second upload. For an ocr field the extracted values are shown inline — "read from the document" — and filled into the fields they map to. Only into fields that are still blank: a value a person typed is never overwritten by one a model read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>		2026-08-25 13:37:51 +05:30
public/brand	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
src	Render file and OCR fields as uploads, not text boxes	2026-08-25 13:37:51 +05:30
.env.example	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +05:30
.gitignore	Wire the console to the platform and make it deployable	2026-08-24 15:20:13 +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