Levandor

Empire UI = the Levandor CRM — crypto lane-ops is a new CRM tab, not new React

5 min read

The central “empire” UI is the Levandor CRM (React + Vite + Supabase + Clerk, built by agent @crm). It already renders pmv2_* / pm_* tables directly from the same Supabase project that hosts our crypto_shortterm schema — so a crypto lane-ops UI is a new tab in that CRM, not a new app, and crypto’s deliverable is SQL views/RPCs + a build-prompt for @crm, likely with no React written by crypto. Confirmed 2026-07-06 from /Users/levander/coding/polymarket_fetch/CRM_DASHBOARD_PROMPT.md.

For Agents — binding facts

  1. Empire UI = Levandor CRM — React + Vite + Supabase + Clerk, owned by @crm (see levandor-crm).
  2. One Supabase project holds everything. The CRM, the pmv2/pm_* tables, AND our crypto_shortterm schema all live in project mgmt, ref mkofmdtdldxgmmolxxhc (crypto_algo .env SUPABASE host = mkofmdtdldxgmmolxxhc.supabase.co). The CRM reads that DB directly (Supabase client), not through an API layer.
  3. The CRM already reads pmv2/pm tables — via as never casts (they’re absent from database.types.ts), in an existing Polymarket surface with tabs Scout / Copy Lane / Longshot / Bets.
  4. A crypto lane-ops UI = one more tab in that surface. Crypto’s deliverable is public SQL views/RPCs (to bridge crypto_shortterm → PostgREST) + a cash-truth ingester + a CRM_DASHBOARD_PROMPT-style build-prompt handed to @crm. Crypto probably writes no React.

The empire UI is the Levandor CRM

There is no separate “empire dashboard” project to build. The central operator UI already exists: the Levandor CRM (levandor-crm), a React + Vite + Supabase + Clerk app maintained by agent @crm. Polymarket monitoring is already a first-class surface in it.

Shared Supabase project — the key topology fact

Everything sits in one Supabase project:

ThingWhere
Levandor CRM app DBproject mgmt, ref mkofmdtdldxgmmolxxhc
pmv2 executor tables (pmv2_*, pm_*)same project, public schema
Our recorder tablessame project, isolated crypto_shortterm schema

The crypto_algo .env SUPABASE host is mkofmdtdldxgmmolxxhc.supabase.co — the same ref. The CRM connects with a Supabase client and reads tables directly; there is no bespoke backend between the UI and the DB. That means a crypto lane-ops view is a matter of what SQL the CRM can SELECT, not of building an API.

The CRM already renders pmv2 / pm tables

The CRM’s Polymarket surface already queries pmv2_* / pm_* tables even though they are not in the generated database.types.ts — it uses as never casts to reach past the typed client. Existing tabs: Scout / Copy Lane / Longshot / Bets. So rendering pmv2-owned trading data in the CRM is a solved, in-production pattern, not a research question.

What “a crypto lane-ops UI” actually means (the deliverable)

Because the CRM reads the DB directly, the crypto side’s work is almost entirely data-shaping + a spec, not frontend:

  1. Public SQL views / RPCs that surface crypto lane-ops data (per-lane W/L, net P&L, fill vs signal, current lane state). These must live in a PostgREST-reachable schema — see the bridge caveat below.
  2. A cash-truth ingester — persist on-chain realized cash so the UI reads a table, not a live data-api scrape (see crypto-shortterm-pnl-onchain-cash-truth-2026-07-06 for the cash-truth definition and the reusable scripts/wallet_lane_cashflow.py / scripts/wallet_pnl_reconcile.py).
  3. A CRM_DASHBOARD_PROMPT.md-style build-prompt handed to @crm describing the new tab (columns, filters, the views/RPCs to read). @crm writes the React.

Reuse what already exists

The per-lane P&L dashboard (dashboard_data.py + build_dashboard.py) already computes the exact per-lane W/L + net P&L a CRM tab would show — but it is a snapshot HTML artifact with no live DB access. The CRM tab is the live, always-current replacement: same metrics, sourced from views instead of a one-shot pull.

Isolated schema — the bridge caveat

Our recorder tables are in the isolated crypto_shortterm schema (and the hard rule is: never touch pmv2’s public / pm_* tables). PostgREST only serves schemas in Supabase’s exposed-schemas list — typically public. So a crypto lane-ops tab most likely needs public views/RPCs that read from crypto_shortterm as the bridge (a thin read-only projection), rather than exposing crypto_shortterm directly. Whether crypto_shortterm is already PostgREST-exposed or must be bridged is an open item below.

Code pattern / precedent

  • CRM code layout: web/src/lib/*.ts (data access) + web/src/lib/hooks/* (query hooks) + web/src/pages/polymarket/* (the surface), with unit tests.
  • Precedent for handing @crm a spec exists: CRM_DASHBOARD_PROMPT.md (source of these facts) is exactly a build-prompt for a CRM dashboard surface. A crypto lane-ops tab follows the same handoff.

Pending / unconfirmed

Not yet verified (2026-07-06)

  • Exact CRM repo path / git remote — not confirmed here.
  • Whether @crm is registered on babylon — the handoff channel to @crm is not yet confirmed. (Coordination today runs through the pmv2 hub; see crypto-shortterm-multi-asset-status-babylon-2026-07-02.)
  • Whether crypto_shortterm is PostgREST-exposed or must be bridged via public views/RPCs — determines whether step 1 above is “grant/expose” or “write bridge views.” Default assumption: bridge via public.

Graph View

Backlinks