Three tabs. Connections lists each bank's configured link with its last
status, and lets an operations user test or run a sync. Field mapping is
the screen that carries the argument: one row per loan-book field, one
column per lender's name for it, which is what "every bank's core is
different" actually reduces to. Sync history reads as an audit — a
failed run is a row, because a feed that stopped three weeks ago must be
visible as something other than silence.
Simulated adapters are badged everywhere they appear, including in the
run history, because the failure mode that matters here is a demo
mistaken for a live feed. Unmapped vendor columns are shown being
dropped at the boundary, with identifying ones marked never stored.
The client-side identifying-column check mirrors the backend's, matching
on the whole name and on each part with separators and camelCase split
alike — so CUST_NAME and borrowerMobile are refused next to the field
rather than after a round trip.
Follows the house pattern: useQuery against the real endpoint, in-file
demo fallback, "Demo data" pill when the backend is unreachable. The
demo fixtures deliberately include one connection that has never run and
one that last failed. Build and oxlint clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Points at the backend README for project documentation and covers what is
specific to this app: the three routes and their tiers, why login routing
is a convenience the backend does not trust, and the useQuery + demo
fallback + Demo data pill pattern every screen follows.
Records why the demo fallbacks deliberately contain failure states. A demo
where every upload is clean and every cell is publishable teaches the wrong
thing — a reviewer who only sees green rows will not know the rejection
panel or the suppression behaviour exist.
Carries the DataMeet CC BY 4.0 attribution.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>