import { R as ProjectionMapping, S as RelationshipsMap, a as ClivlyEntitiesConfig, h as FilterExpr } from "./entity-config-OhC4Otkz.cjs";
//#region src/mappings-config.d.ts
/**
 * Mappings → Entity Config bridge.
 *
 * `crm_entity_mappings` rows are the single source of truth for how a host
 * schema maps onto Clivly's CRM concepts. This module compiles those rows into
 * a `ClivlyEntitiesConfig` — the contract the view compiler and sync engine
 * consume — so the persisted mapping and the runtime pipeline never diverge.
 *
 * The row model has no explicit entity-key column (it's keyed by
 * `sourceTable + targetConcept + role`), but the config's `relationships`
 * reference other entities *by key*. This builder therefore derives a stable
 * key per row and resolves each relationship's `entity` reference through the
 * same derivation — so a relationship stored as `entity: "<relatedTable>"`
 * (the shape `mappings.suggest` produces) resolves to the right entity.
 */
/**
 * A persisted `crm_entity_mappings` row, narrowed to the columns the builder
 * reads. Structurally compatible with the Drizzle row (jsonb columns typed
 * loosely) so the API layer can pass `db.select()` results straight in.
 */
export interface EntityMappingRow {
  fieldMap: Record<string, string>;
  filter?: Record<string, unknown> | null;
  /**
   * Advanced mapping: a base table plus explicit joins. When set, this — not
   * `fieldMap` — is the authored source of truth, and `sourceTable` merely
   * mirrors `projection.baseTable`.
   */
  projection?: ProjectionMapping | null;
  relationships?: Record<string, unknown> | null;
  role?: string | null;
  sourceTable: string;
  status?: string | null;
  targetConcept: string;
  targetObjectTypeId?: string | null;
}
/**
 * Compile persisted mapping rows into a `ClivlyEntitiesConfig`. Only `active`
 * rows with at least one mapped field are included; disabled/suggested rows and
 * unmapped rows are skipped. Returns `{ entities: {} }` when nothing is
 * eligible — a no-op the view compiler and sync engine both tolerate.
 */
export declare function mappingsToEntitiesConfig(rows: EntityMappingRow[]): ClivlyEntitiesConfig;
/**
 * Entity Config → Mappings, the inverse of `mappingsToEntitiesConfig`.
 *
 * `objectType` in config creates the custom object but nothing creates the
 * MAPPING, so config-as-code ended at a created object and a sync that stored
 * nothing. This produces the rows that close that gap.
 *
 * The two shapes align column for column, with one asymmetry that cannot be
 * resolved by naming: the row model has no entity-key column — a row is keyed by
 * `(sourceTable, targetConcept, role)` — while a CUSTOM entity's key *is* its
 * object type slug, and is routinely different from its source table
 * ("client-accounts" derived from "accounts"). So the key travels explicitly on
 * every row rather than being left for the reverse derivation to guess.
 */
export interface MappingFromConfig {
  /**
   * The config entity key this row came from. Not a row column — the caller
   * needs it to resolve a custom object type and to report what it wrote.
   */
  entityKey: string;
  fieldMap: Record<string, string>;
  filter?: FilterExpr;
  /** Rows from this entity are their company's point of contact. */
  isPrimaryContact?: boolean;
  /** Declared custom object, when the config declares one rather than pinning an id. */
  objectType?: {
    iconKey?: string;
    name: string;
    pluralName?: string;
  };
  /** The custom object type's slug — the entity key. Custom entities only. */
  objectTypeSlug?: string;
  projection?: ProjectionMapping;
  relationships?: RelationshipsMap;
  role: string;
  sourceTable: string;
  targetConcept: string;
  targetObjectTypeId?: string;
}
export declare function entitiesToMappings(config: ClivlyEntitiesConfig): MappingFromConfig[];
//#endregion