import { TriggerDefinition, TriggerType } from './rules.type';
/** Value-level constants for trigger modes (the *builder* view used by the
 *  dashboard UI). Each entry's string is the *backend* `source_type` value
 *  read off `ContentRule.trigger` by `engine.py:_match_trigger` and the SQL
 *  filter at `trigger_api.py:fire_signal`:
 *
 *  - `SIGNAL` → `"signal"` (API pod, `POST /api/v1/rules/signals/fire`).
 *  - `CRON`   → `"cron"`   (cron evaluator pod).
 *  - `EVENT`  → `"event_dto"` (NOT `"event"` — the engine matcher reads
 *    `source_type` as `"event_dto"`).
 *
 *  Use {@link TRIGGER_TYPE} for the wire-level `trigger_type` value (which
 *  uses `"event"`, not `"event_dto"`). */
export declare const TRIGGER_MODE: {
    readonly SIGNAL: "signal";
    readonly CRON: "cron";
    readonly EVENT: "event_dto";
};
/** The trigger modes the dashboard builders author — derived from {@link TRIGGER_MODE}. */
export type TriggerMode = (typeof TRIGGER_MODE)[keyof typeof TRIGGER_MODE];
/** Value-level constants for the *wire-level* `trigger_type` field (the
 *  schema-validated field on `TriggerDefinition`,
 *  `eaera_cms/core/rules/definitions.py:33-39`).
 *
 *  For event rules the wire value is `"event"`, NOT `"event_dto"` — the
 *  latter is the `source_type` value. The two diverge on purpose; the
 *  pack loader emits `trigger_type: "event"` + `source_type: "event_dto"`
 *  (`packs/registry.py:463-470`).
 *
 *  - `SIGNAL` → `"signal"`
 *  - `CRON`   → `"cron"`
 *  - `EVENT`  → `"event"`
 *  - `STREAM` → `"stream"` (backend-only — no SDK builder). */
export declare const TRIGGER_TYPE: {
    readonly SIGNAL: "signal";
    readonly CRON: "cron";
    readonly EVENT: "event";
    readonly STREAM: "stream";
};
/** The wire-level `trigger_type` union — derived from {@link TRIGGER_TYPE}. */
export type TriggerTypeValue = (typeof TRIGGER_TYPE)[keyof typeof TRIGGER_TYPE];
/** The Kafka `content.events` event types the trigger pod subscribes to.
 *
 *  Authoritative list — `eaera-mt5/eaera_mt5/pipeline/event_publisher.py` (the
 *  four MT5 pipeline publishers) and `eaera-mt5/worker/sync/account_sync.py`
 *  (`_emit_account_upsert_events`). The CMS schema validator does not whitelist
 *  the value (any string is accepted), but the engine matcher and the
 *  `Mt5AccountSyncService` only act on these five. */
export declare const EVENT_TYPE: {
    readonly DEAL_CLOSE: "deal_close";
    readonly STATEMENT: "statement";
    readonly POSITION: "position";
    readonly ORDER: "order";
    /** FEAT-009 identity-provisioning bridge — emitted by the MT5 `account_sync`
     *  worker whenever an account is upserted. The trigger service ALSO
     *  auto-upserts an `Mt5Account` content row on `(server_name, login)` via
     *  `Mt5AccountSyncService` before evaluating rules. Common use: provision
     *  a CMS user when the account email is present (the live `user_sync` rule
     *  uses `event: 'mt5_account_upsert'` + `trigger.conditions: [email contains '@']`). */
    readonly MT5_ACCOUNT_UPSERT: "mt5_account_upsert";
};
/** Event type union — derived from {@link EVENT_TYPE}. */
export type EventType = (typeof EVENT_TYPE)[keyof typeof EVENT_TYPE];
/** A labelled option for the event-payload picker. */
export interface EventTypeOption {
    label: string;
    value: EventType;
    /** Short human hint shown in tooltips / Data Set reference. */
    hint?: string;
}
/** Human labels for the {@link EVENT_TYPE} options. */
export declare const EVENT_TYPE_OPTIONS: readonly EventTypeOption[];
/** Helper: true iff the given string is a known event type. */
export declare const isKnownEventType: (raw: unknown) => raw is EventType;
/** Coerce an arbitrary event-type string (e.g. from a stored `sourceConfig.event`)
 *  to a known {@link EventType}. Falls back to {@link EVENT_TYPE.DEAL_CLOSE} for
 *  unknown / missing values so the rule editor always has a valid pick. */
export declare const coerceEventType: (raw: unknown) => EventType;
/** A labelled cron preset for the schedule picker. */
export interface CronPreset {
    label: string;
    value: string;
}
/** Human cron presets (standard 5-field expressions). */
export declare const CRON_PRESETS: readonly CronPreset[];
/** Default cron schedule when none is provided (skills' historical default). */
export declare const DEFAULT_CRON_SCHEDULE = "*/5 * * * *";
/** Default Kafka topic for event triggers. Sourced from `CONTENT_TYPE.MT5_ACCOUNT`. */
export declare const DEFAULT_EVENT_CONTENT_TYPE: "Mt5Account";
/** Build a signal trigger over the metric stream.
 *
 *  Emits the canonical pair:
 *  - `triggerType: 'signal'` (schema-validated)
 *  - `sourceType: 'signal'` (engine matcher)
 *
 *  Both are the same value for signal rules. */
export declare const buildSignalTrigger: (signalName: string) => TriggerDefinition;
/**
 * Build a cron trigger. `schedule` is a standard 5-field cron expression;
 * `extra` is merged into `sourceConfig` (e.g. skills pass `promptName` /
 * `queryTools`).
 *
 *  Emits the canonical pair:
 *  - `triggerType: 'cron'` (schema-validated)
 *  - `sourceType: 'cron'` (engine matcher)
 */
export declare const buildCronTrigger: (schedule: string, extra?: Record<string, unknown>, timezone?: string) => TriggerDefinition;
/**
 * Build an event trigger on the Kafka `content.events` topic.
 *
 *  Emits the canonical pair — NOT the same value on both fields:
 *  - `triggerType: 'event'` (schema-validated, `definitions.py:36`)
 *  - `sourceType: 'event_dto'` (engine matcher, `engine.py:369`)
 *
 *  Earlier SDK builds emitted both as `"event_dto"`, which passed engine
 *  matching but drifted from the canonical pack-authored contract
 *  (`packs/registry.py:463-470`). This builder now emits the correct pair.
 *
 *  The `event` (singular) and `eventTypes`/`contentTypes` (plural) shapes
 *  are both stored so the engine reads either form.
 */
export declare const buildEventTrigger: (event: EventType, contentType?: string, extra?: Record<string, unknown>) => TriggerDefinition;
/** Derive the builder trigger mode from a stored `ContentRule.trigger`.
 *
 *  Accepts BOTH the camelCase fields the SDK writes (`sourceType`,
 *  `triggerType`) and the snake_case JSONB keys the backend reads
 *  (`source_type`, `trigger_type`) so rules authored before the trigger
 *  wire-shape fix still load in the Fixed Rules editor without showing up
 *  as the wrong mode.
 *
 *  Both `source_type === "event_dto"` (engine matcher) and `trigger_type
 *  === "event"` (schema-validated) map to the builder's `EVENT` mode. */
export declare const triggerModeOf: (trigger: TriggerDefinition | Record<string, unknown> | null | undefined) => TriggerMode;
/** Read the cron `schedule` out of a stored `ContentRule.trigger`. */
export declare const scheduleOf: (trigger: TriggerDefinition | Record<string, unknown> | null | undefined) => string;
/** Read the signal `signalName` out of a stored `ContentRule.trigger`. */
export declare const signalNameOf: (trigger: TriggerDefinition | Record<string, unknown> | null | undefined) => string;
export type { TriggerType };
export { TRIGGER_TYPE as TRIGGER_TYPE_VALUE };
//# sourceMappingURL=triggers.d.ts.map