import type { BinaryGeneratorRegistry } from '@cat-factory/kernel';
import type { BinaryGeneratorEntry } from './define.js';
export { type BinaryGeneratorEntry, type BinaryGeneratorInput, defineBinaryGenerator, openApiContract, } from './define.js';
export { NANO_BANANA_CREDENTIAL_KEY, NANO_BANANA_GENERATOR_ID, nanoBananaGenerator, } from './generators/nano-banana.js';
export { NANO_BANANA_OPENAPI } from './contracts/nano-banana.openapi.js';
/**
 * The integrations the platform ships, in registration order.
 *
 * Exported as data so a deployment can register a SUBSET (or none) onto its own registry instance
 * without reaching into this package's internals, and so a test can assert over the shipped set
 * rather than over whatever a helper happened to install.
 */
export declare const BUILTIN_BINARY_GENERATORS: readonly BinaryGeneratorEntry[];
/**
 * Install the built-in integrations onto an app-owned registry instance, and return it.
 *
 * Idempotent by id: registering twice replaces rather than duplicates, so an entry point a test
 * also drives is safe to call again. Registration ORDER is what makes a deployment's own
 * definition of a shipped id an override, so the built-ins go first.
 */
export declare function registerBuiltinBinaryGenerators(registry: BinaryGeneratorRegistry, generators?: readonly BinaryGeneratorEntry[]): BinaryGeneratorRegistry;
/**
 * A fresh {@link BinaryGeneratorRegistry} carrying the shipped integrations.
 *
 * What each facade defaults to when a deployment injects no registry of its own, exactly as
 * `gateRegistryWithBuiltins()` and `promptFragmentRegistryWithBuiltins()` are. An INJECTED registry
 * replaces this one rather than merging with it, so a deployment that wants its own integrations
 * AND the shipped ones starts from this call and registers onto the same instance:
 *
 *     const binaryGeneratorRegistry = binaryGeneratorRegistryWithBuiltins()
 *     binaryGeneratorRegistry.registerAll(myIntegrations)
 *     startLocal({ binaryGeneratorRegistry })
 *
 * That matters more here than for the other two registries, because the shipped `pl_media` preset
 * SELECTS `nano-banana` by id: a registry without it refuses that pipeline's runs at admission
 * (`binary_output_generator_invalid`) rather than degrading, which is the correct disposition for
 * a step naming an integration nobody registered and a loud one to meet on upgrade.
 *
 * Registered ONCE per deployment, on the process that owns the registry. In mothership mode that
 * is the mothership: a node resolves integrations over `/internal/binary-generators` and consults
 * no registry of its own, so the set the pipeline builder offers and the set admission resolves
 * are one set however far behind the node's build has drifted.
 */
export declare function binaryGeneratorRegistryWithBuiltins(): BinaryGeneratorRegistry;
//# sourceMappingURL=index.d.ts.map