/**
 * Messaging-runtime emitter — V2 Phase 3, Round 2.
 *
 * Handles `topology: 'messaging'` factories: async pub/sub providers reached
 * through external brokers (RabbitMQ, Kafka, NATS, AWS SQS).
 *
 * Conceptual difference from sync topologies (library / service / managed /
 * executable):
 *   - Sync topologies have a request/response contract: call op, get result.
 *   - Messaging has a fire-and-forget contract: publish event, receive response
 *     asynchronously or via subscription.
 *
 * For each `import:` entry the consumer declares, this emitter produces:
 *   clients/<kebab-provider>.ts   — broker publish wrapper
 *
 * The publish wrapper:
 *   - Reads `factory.v2metadata.protocol` to pick the SDK and init pattern:
 *       amqp   → amqplib-based publisher with assertExchange + publish
 *       kafka  → kafkajs producer
 *       nats   → TODO stub (clear comment + right SDK shape)
 *       sqs    → TODO stub (clear comment + right SDK shape)
 *       other  → TODO stub (clear comment + right SDK shape)
 *   - For each dotted op `Order.created`: emits a method that publishes the
 *     message to the appropriate routing-key/topic/queue (`order.created`).
 *   - Reads `factory.v2metadata.config?.exchange` / `config?.topic` /
 *     `config?.queue` for routing config.
 *   - Methods return `Promise<void>` (fire-and-forget).
 *
 * Connection lifecycle:
 *   - Emits `init()` (call at app startup) and `shutdown()` (call at graceful
 *     shutdown) on the client.
 *   - Round 2 does NOT auto-wire these into the consumer's startup — that is a
 *     Round 3 concern.
 *
 * No server-bind file:
 *   - Messaging brokers are external services, not something the consumer hosts.
 *   - Consumers PUBLISH to an existing broker; subscribe-side handlers come in
 *     Round 3 via `subscribes_to:` blocks.
 *
 * Deployment instance hint:
 *   - `result.notes` describes where the provider lands in the deployment spec:
 *     `deployments.<env>.instances.communications.<provider>`.
 *
 * --- Select grammar ---
 *
 * `import.select` entries follow the same dotted grammar as library.ts:
 *   - Dotted: `Order.created`  → publishes to routing-key `order.created`
 *   - Bare:   `Events`         → stub method; routing-key inferred from name
 *
 * --- Round 2 limitations ---
 *
 * - Subscribe-side handlers (receiving events from the broker) are deferred to
 *   Round 3; all `select:` entries are treated as publish-side by default.
 * - NATS and SQS emit TODO stubs rather than real SDK code.
 * - Config routing values (exchange, topic, queue) are read from
 *   `factory.v2metadata` when present; absent values use reasonable defaults.
 */
import type { RuntimeEmitter, RuntimeEmitterContext, RuntimeEmitterResult } from './dispatcher.js';
/**
 * Messaging-runtime emitter implementation.
 *
 * One call to `emit()` processes a single `import:` entry and produces
 * one client file under `clients/<provider-filename>.ts`.
 *
 * The client file contains:
 *   - A typed `<Provider>Client` interface with all selected operations as
 *     `(payload: unknown) => Promise<void>` methods, plus `init()` / `shutdown()`.
 *   - A protocol-specific implementation class (amqp / kafka) or a TODO stub.
 *   - An exported singleton constant `<provider>Client` for the consumer to import.
 *
 * No server-bind file is emitted — the broker is an external service.
 */
export declare class MessagingRuntimeEmitter implements RuntimeEmitter {
    readonly topology: "messaging";
    emit(ctx: RuntimeEmitterContext): Promise<RuntimeEmitterResult>;
}
//# sourceMappingURL=messaging.d.ts.map