import type { Integration as IntegrationDefinition, Plugin as PluginDefinition } from '@botpress/client';
import type { DependencyState, StatusVerdict } from '@botpress/runtime';
/**
 * The canonical verdict for an OAuth/connection-gated integration the user has
 * not authorized yet. Shared by the codegen carrier (the authorization gate) and
 * the offline snapshot readers (via the persisted `authorizationPending` flag) so
 * every surface words the same condition identically.
 */
export declare function authorizationPendingVerdict(): StatusVerdict;
/**
 * Whether an integration requires configuration before it can be enabled.
 *
 * The default-configuration branch of {@link computeIntegrationStatus}. Behavior is
 * equivalent to the original `bot-generator/generator.ts` helper for all valid
 * JSON-schema input, including the deliberately conservative
 * `!configuration => requires config` rule (an integration whose definition could
 * not be fully resolved is treated as requiring config, so it is not auto-enabled).
 * The one intentional refinement: a malformed `required` entry that isn't a string
 * is ignored (see {@link schemaRequiredFields}), where the original counted any
 * non-empty array; real JSON schemas only contain string entries.
 */
export declare function integrationRequiresConfiguration(definition: IntegrationDefinition): boolean;
/** Whether a plugin requires configuration before it can run. Plugins have no identifier. */
export declare function pluginRequiresConfiguration(definition: PluginDefinition): boolean;
/**
 * Whether an integration's active configuration gates on an external *authorization*
 * (an OAuth / connection identifier) rather than plain config fields. Such an integration
 * cannot be registered until the user completes the connect flow — Cloud's `register`
 * lifecycle hook hard-fails otherwise (e.g. "No refresh token found. Please complete the
 * OAuth flow to obtain a refresh token"). Used by {@link isAuthorizationPending} to leave an
 * unauthorized OAuth integration inert (`enabled: false`) rather than letting Cloud's
 * `register` hook abort the whole deploy/dev boot.
 *
 * Narrower than {@link integrationRequiresConfiguration}, which also counts plain required
 * schema fields — those CAN be satisfied from config without a cloud roundtrip, so they
 * don't need this register-time guard (a missing one is already `unconfigured`).
 */
export declare function integrationRequiresAuthorization(definition: IntegrationDefinition, configurationType?: string): boolean;
export interface ComputeIntegrationStatusInput {
    /** Whether the integration's module exists on disk (`bp_modules/integration_<alias>`). */
    installed: boolean;
    /** Catalog/cloud definition; `null` when it could not be resolved. */
    spec: IntegrationDefinition | null;
    /** Resolved enabled flag — the snapshot's intent, optionally reconciled with cloud by the caller. */
    enabled: boolean;
    /** Effective merged configuration (server + local). */
    config?: Record<string, unknown>;
    /** Active variant key when the integration uses `configurations` (plural). */
    configurationType?: string;
    /**
     * Authoritative missing-field set captured from Cloud at install time and
     * persisted in the snapshot (WS0). Wins over schema-derived fields when provided:
     * an explicit empty array means "Cloud confirms configured".
     */
    persistedMissingFields?: string[];
    /**
     * Cloud's current enabled state, when known (codegen path). Disambiguates
     * identifier/OAuth integrations whose required fields aren't enumerable
     * client-side: Cloud only keeps such an integration enabled once configured.
     */
    cloudEnabled?: boolean;
    /**
     * Last-known authorization state persisted in the snapshot (WS5/#7): `true` means
     * the integration gates on an OAuth/connection identifier the cloud bot did
     * not have at the last refresh. Yields the same `unconfigured` verdict the
     * codegen authorization gate bakes into the runtime carrier.
     */
    authorizationPending?: boolean;
}
/**
 * Resolve an integration's capability state. Precedence:
 * `not_installed` > `unresolved` > `unconfigured` > `disabled` > `available`.
 */
export declare function computeIntegrationStatus(input: ComputeIntegrationStatusInput): StatusVerdict;
export interface AuthorizationGateInput {
    /** Whether the integration's active config gates on an OAuth/connection identifier. */
    requiresAuthorization: boolean;
    /**
     * Whether the integration is authorized on the target cloud bot (has an `identifier`).
     * `undefined` means it's not on the cloud bot yet → treated as not authorized.
     */
    cloudAuthorized?: boolean;
    /** True when the cloud read failed this pass — then we can't conclude anything. */
    cloudFetchErrored?: boolean;
}
/**
 * Whether an integration must be left inert (emitted `enabled: false`, but still declared)
 * because it gates on an authorization the user hasn't completed yet. The classic case: a
 * managed-OAuth integration (`gmail`) toggled on but never connected — Cloud's `register`
 * hook hard-fails ("No refresh token found …") and aborts the WHOLE `adk dev` / `adk deploy`
 * boot if the integration is declared `enabled: true`.
 *
 * The fix is to demote it to `enabled: false`, NOT to omit it from the definition: `bp`
 * skips registering a disabled integration (so the boot survives), yet keeps it on the bot
 * so (a) the user can still authorize it in the Control Panel — omitting it makes `bp` prune
 * it from the cloud bot, a first-auth dead end — and (b) any plugin whose dependency maps to
 * this alias still resolves at `addPlugin` time. Once the user authorizes it the cloud
 * integration gains an `identifier`, this returns false, and codegen re-enables it.
 *
 * Keyed off *authorization* (the `identifier`), NOT the registration lifecycle status: a
 * disabled integration reports `unregistered`, which a status-based gate would read as
 * "still blocked" forever even after the user connects it — a dead loop. The identifier
 * persists across the enable/disable toggle, so it's the signal that lets us self-heal.
 *
 * Only authorization-gated integrations are affected: plain config/schema integrations
 * register fine from their config without an out-of-band step. Guarded by `cloudFetchErrored`
 * so a transient cloud-read failure never demotes a working integration (unknown ≠
 * unauthorized).
 */
export declare function isAuthorizationPending(input: AuthorizationGateInput): boolean;
export interface PluginDependencyStatus {
    alias: string;
    verdict: StatusVerdict;
}
/**
 * Transitive rule shared by every plugin-verdict path (spec-aware, codegen
 * carrier, snapshot-only): a plugin cannot run while a backing integration is inert.
 * A deliberately *disabled* backing integration makes the plugin `disabled` —
 * an intentional, supported state that must not read as a failure (or block a
 * deploy) — while any other non-available state makes it `unresolved`.
 * Returns `null` when every backing integration is available.
 */
export declare function transitiveDependencyVerdict(dependencyStatuses: PluginDependencyStatus[] | undefined): StatusVerdict | null;
/**
 * Shape a plugin's `dependencies` map into the {@link PluginDependencyStatus}
 * list the transitive rule consumes, resolving each backing integration's
 * verdict through the caller's lookup. Shared by codegen and the offline
 * resolver so the fallback — a reference to an integration that has no verdict,
 * i.e. one not declared in the project — reads identically everywhere.
 */
export declare function mapPluginDependencyStatuses(dependencies: Record<string, {
    integrationAlias?: string;
}> | undefined, verdictFor: (alias: string) => StatusVerdict | undefined): PluginDependencyStatus[];
export interface ComputePluginStatusInput {
    /** Whether the plugin's module exists on disk (`bp_modules/plugin_<alias>`). */
    installed: boolean;
    /** Catalog/cloud definition; `null` when it could not be resolved. */
    spec: PluginDefinition | null;
    /** Resolved enabled flag. */
    enabled: boolean;
    /** Effective merged configuration (server + local). */
    config?: Record<string, unknown>;
    /** Authoritative missing-field set persisted in the snapshot (WS0). Wins when provided. */
    persistedMissingFields?: string[];
    /**
     * Capability verdicts of the integrations backing this plugin's interface
     * dependencies. A plugin cannot run if any backing integration is inert.
     */
    dependencyStatuses?: PluginDependencyStatus[];
}
/**
 * Resolve a plugin's capability state. Same precedence as integrations, plus a
 * transitive rule: a plugin is `unresolved` if any backing integration (the
 * concrete fulfilment of an interface dependency) is itself not `available`.
 * Precedence: `not_installed` > `unresolved` (own or transitive) > `unconfigured` > `disabled` > `available`.
 */
export declare function computePluginStatus(input: ComputePluginStatusInput): StatusVerdict;
export interface ComputePluginCarrierStatusInput {
    /** Whether the plugin's module exists on disk (`bp_modules/plugin_<alias>`). */
    installed: boolean;
    /** Cloud's persisted install-time missing-field verdict, if any. */
    persistedMissingFields?: string[];
    /**
     * Capability verdicts of the integrations backing this plugin's interface
     * dependencies. A plugin cannot run if any backing integration is inert.
     */
    dependencyStatuses?: PluginDependencyStatus[];
}
/**
 * Plugin capability verdict for the **codegen carrier**, where the plugin spec
 * is intentionally not loaded (the build pipeline loads integration and
 * interface definitions, but not plugin definitions). It therefore covers
 * on-disk presence, transitive integration-dependency availability, and the
 * persisted Cloud missing-field verdict captured during install/refresh:
 *
 * - `not_installed` — the plugin module is missing on disk (MODE B)
 * - `disabled`      — a backing integration is deliberately disabled
 * - `unresolved`    — a backing integration is otherwise not `available`
 * - `unconfigured` — Cloud rejected the plugin's own required config
 * - `available`    — installed, configured, and all backing integrations are available
 *
 * The runtime drift backstop still catches missing config that Cloud has not
 * persisted yet. The spec-aware {@link computePluginStatus} is used by the
 * offline CLI path, where the plugin definition is available.
 */
export declare function computePluginCarrierStatus(input: ComputePluginCarrierStatusInput): StatusVerdict;
export interface ComputeSnapshotOnlyStatusInput {
    /** Whether the dependency's module exists on disk (`bp_modules/...`). */
    installed: boolean;
    /** Resolved enabled flag (the snapshot's cloud-reflected intent). */
    enabled: boolean;
    /** Cloud's persisted install-time missing-field verdict (WS0), if any. */
    missingFields?: string[];
    /** Persisted last-known authorization state (WS5/#7), integrations only. */
    authorizationPending?: boolean;
}
/**
 * Capability verdict from the **snapshot alone** — no catalog spec. This is the
 * offline reader's path (`adk integrations status`, `adk check`, the `adk dev`
 * boot summary) when a spec wasn't (or couldn't be) fetched.
 *
 * It trusts the snapshot because the snapshot reflects Cloud's validated state: Cloud only
 * keeps an integration `enabled` once its required config is satisfied, so
 * `enabled` ⟹ `available`. A persisted missing-field verdict (WS0) overrides that
 * with `unconfigured`. Unlike {@link computeIntegrationStatus}, this never returns
 * `unresolved` for a missing spec — the absence of a spec here means "not fetched",
 * not "unresolvable".
 *
 * Precedence: `not_installed` > `unconfigured` (persisted) > `disabled` > `available`.
 */
export declare function computeSnapshotOnlyStatus(input: ComputeSnapshotOnlyStatusInput): StatusVerdict;
/** A dependency's capability state is callable only when `available`. */
export declare function isCallable(state: DependencyState): boolean;
//# sourceMappingURL=status.d.ts.map