/**
 * Per-forwarder drop-rule snippets for `log10x_top_patterns`.
 *
 * Every snippet is grounded in the 10x engine's actual forwarder module
 * at `~/git/l1x-co/config/modules/pipelines/run/modules/input/forwarder/`.
 * Each forwarder has a different mechanism by which the engine adds the
 * `tenx_hash` field on the return path; the drop-rule must filter on
 * that field at the right place in the pipeline (post-sidecar), or the
 * filter will fire on records that don't have the field yet.
 *
 * Each snippet returns `{ language, body, placementNote }`:
 *   - `language` — fence tag for the code block (xml / ini / ruby / yaml)
 *   - `body` — the snippet text, ready to copy-paste
 *   - `placementNote` — where in the user's config the snippet goes,
 *     and why (the "why" anchors the Reader to the engine's mechanism
 *     so they understand the filter isn't arbitrary)
 *
 * The hash-field name is configurable via the engine's
 * `symbolMessageHashField` setting (defaults to `tenx_hash`). Pass the
 * env's actual value as `hashField` so the snippet matches what the
 * sidecar is emitting.
 */
export type ForwarderId = 'fluentd' | 'fluent-bit' | 'logstash' | 'otel-collector' | 'filebeat' | 'splunk-uf' | 'datadog-agent';
export interface ForwarderSnippet {
    language: 'xml' | 'ini' | 'ruby' | 'yaml';
    body: string;
    placementNote: string;
}
export declare const ALL_FORWARDERS: ForwarderId[];
/**
 * Return the drop-rule snippet for the given forwarder + hash. The
 * `hashField` parameter is the engine's configured
 * `symbolMessageHashField` value (typically `tenx_hash`).
 */
export declare function dropRuleSnippet(forwarder: ForwarderId, hash: string, hashField?: string): ForwarderSnippet;
/** Other forwarders besides the detected one — used to render the
 * "also supports X, Y, Z — ask for syntax" hint. Stable order. */
export declare function otherForwarders(detected: ForwarderId): ForwarderId[];
/**
 * Per-forwarder "how to apply this to the running deployment" steps.
 *
 * Output is a 3-step bash block: discover the config (ConfigMap in
 * k8s, file path on a host), edit it, restart. We can't produce a
 * single self-applying one-liner because:
 *   - the ConfigMap name is install-specific (`fluentd-config`,
 *     `td-agent-config`, `fluent-bit`, etc. — depends on the Helm chart
 *     used)
 *   - the workload kind varies (DaemonSet vs Deployment)
 *   - the namespace varies (logging / kube-system / monitoring / etc.)
 *
 * So we generate templated commands the reader fills in. When
 * `namespace` is provided (pulled from the sample event's k8s metadata),
 * step 3 uses it concretely; otherwise it leaves a `<NAMESPACE>`
 * placeholder.
 *
 * When `isK8s` is false, the discovery step swaps to filesystem
 * inspection + `systemctl reload`.
 */
export interface ApplyInstructions {
    /** Markdown heading text (no leading `**`); caller wraps as needed. */
    heading: string;
    /** Multiline bash, ready for a ```bash fenced block. */
    steps: string;
}
export declare function applyInstructions(forwarder: ForwarderId, ctx: {
    namespace?: string;
    isK8s: boolean;
}): ApplyInstructions;