/**
 * Adaptive Routing — scoring de candidatos (agentes, skills, modelos).
 *
 * FinalScore = weighted sum de:
 *   relevance (semântica da task vs capabilities/triggers)
 *   historicalSuccess (estatística da memória de execuções)
 *   compatibility (resolver OK / versão compatível)
 *   risk (inverso — skills/agentes de alto risco pontuam menos)
 *   cost (inverso — barato pontua mais)
 *   latency (inverso)
 */
import type { CandidateScore } from '../types.js';
export interface ScoreInput {
    candidate: string;
    relevance: number;
    historicalSuccess?: number;
    compatibility?: number;
    risk?: number;
    cost?: number;
    latency?: number;
    weights?: Partial<Record<'relevance' | 'historicalSuccess' | 'compatibility' | 'risk' | 'cost' | 'latency', number>>;
    reasons?: string[];
}
export declare const DEFAULT_SCORE_WEIGHTS: {
    relevance: number;
    historicalSuccess: number;
    compatibility: number;
    risk: number;
    cost: number;
    latency: number;
};
export declare class CandidateScorer {
    score(input: ScoreInput): CandidateScore;
}
/**
 * Relevância semântica simples (sem dependências): tokenização + overlap
 * de termos entre query e alvo (capabilities/triggers/description).
 * Suficiente para ranqueamento determinístico em CLI.
 */
export declare function semanticRelevance(query: string, target: string): number;
/**
 * Cobertura de termos, para CAPABILITY MATCHING de agentes.
 *
 * Existe separada de `semanticRelevance` porque as duas perguntas são
 * diferentes, e responder as duas com a mesma função escolhia o agente errado
 * em metade dos objetivos medidos:
 *
 * - `semanticRelevance` pontua pela ESPECIFICIDADE média do termo casado, e por
 *   isso satura: um único termo longo em comum já devolve ~0.8. "Escreva a
 *   função validarCPF em TypeScript" dava exatamente 0.81 para
 *   `automation-engineer` e para `senior-engineer`, e o empate caía no
 *   desempate por ordem alfabética. Todo despacho errado observado terminou num
 *   agente alfabeticamente inicial, que é a assinatura desse empate.
 * - Aqui a pergunta é QUANTO do objetivo o agente cobre. A nota é cobertura:
 *   fração dos termos significativos do objetivo que o alvo casa. Casar 1 de 5
 *   termos vale 0.2, não 0.8.
 *
 * Duas normalizações que a outra não faz, e sem as quais justamente os termos
 * que decidem o roteamento não casavam:
 *
 * - **Verbo genérico de pedido sai do cálculo.** "criar", "escreva", "fazer"
 *   aparecem em quase todo objetivo e não distinguem agente nenhum, mas casavam
 *   com o texto de qualquer agente e produziam relevância do nada (era o que
 *   dava 0.67 ao `skill-architect` num objetivo sobre migration Postgres).
 *   Quando o objetivo é SÓ verbo genérico eles voltam a valer, porque aí são o
 *   único sinal que existe. Verbo que ROTEIA (auditar, explicar, revisar,
 *   corrigir, projetar) não entra nesta lista de propósito.
 * - **Casamento por prefixo a partir de 5 caracteres:** "postgres" casa
 *   "postgresql", "migration" casa "migrations". Sem isso o agente `database`
 *   tirava zero de relevância léxica num objetivo sobre migration Postgres,
 *   enquanto um agente que casou o verbo "criar" tirava 0.67.
 */
export declare function capabilityCoverage(objective: string, target: string): number;
//# sourceMappingURL=scorer.d.ts.map