/**
 * Context-correct remediation for missing externalized LLM SDKs
 * (mmnto-ai/totem#2018 L2).
 *
 * The LLM SDKs (`@google/genai`, `@anthropic-ai/sdk`, `openai`) are optional
 * peer dependencies by design (mmnto-ai/totem#2018 / the `google-genai-coupling`
 * parity contract): they must resolve from the CONSUMING PROJECT, never from
 * this package. That design has a sharp edge: a globally-installed `totem`
 * binary can never resolve them — and installing the SDK globally does not fix
 * it either (verified empirically on mmnto-ai/totem#2018). The remediation
 * therefore has to branch on context, or it sends the user down a dead end.
 */
/**
 * Build the recovery hint for a failed SDK import, branched on what is
 * actually true on disk:
 *
 * 1. The cwd is inside the totem monorepo → point at the workspace build.
 *    Checked FIRST: in the workspace the SDK may ALSO sit in node_modules
 *    (sibling devDependency), and the project-local-CLI hint is wrong there
 *    (`exec totem` re-routes to the same unresolvable binary).
 * 2. The SDK IS installed in the project but this binary couldn't resolve it
 *    → the binary is the problem (global install) — point at the
 *    project-local CLI, never at another install.
 * 3. Otherwise → project-local install hint, with the externalized-by-design
 *    context and an explicit warning away from global installs.
 */
export declare function buildMissingSdkHint(pkg: string, opts?: {
    cwd?: string;
    packageManager?: string;
    /**
     * Extra sentence appended ONLY to the genuinely-absent branch (e.g. "use
     * another provider"). In the workspace and binary-can't-resolve branches
     * an alternative would dilute — or contradict — the precise fix: switching
     * provider cannot help when the replacement SDK is just as unresolvable
     * from the same binary (#2150 round-2).
     */
    absentAlternative?: string;
}): string;
//# sourceMappingURL=missing-sdk.d.ts.map