/**
 * Critérios de aceite VINDOS DO USUÁRIO.
 *
 * O Commander sempre gerou critérios, e todos falam da FORMA do artefato:
 * `artifact-valid`, `min-size 200`, `contains "<campo do schema>"`,
 * `not-contains "TODO"`. Nada disso fala do que foi pedido: "adicionar
 * paginação em GET /users" não produzia nenhum critério sobre paginação, e a
 * especificação do runtime pede o contrário ("o Commander gera critérios
 * QUANDO o usuário não os fornece"). Como não havia por onde fornecer, o
 * "quando" era sempre.
 *
 * Aqui o usuário fornece. A regra de tradução é uma só e está no prefixo:
 *
 *   contains: paginação            -> determinístico, decidido sem modelo
 *   not-contains: TODO             -> determinístico
 *   matches: limit=\d+             -> determinístico (regex validada na carga)
 *   min-size: 500                  -> determinístico
 *   file-exists: src/routes.ts     -> determinístico, contra o disco
 *   json-field: total              -> determinístico
 *   references-exist               -> determinístico (sem valor)
 *   o endpoint aceita ?page e ?limit  -> semântico: precisa de juiz
 *
 * O default é SEMÂNTICO de propósito. Um critério em prosa é o que uma pessoa
 * escreve naturalmente, e transformá-lo em `contains` da frase inteira
 * reprovaria toda entrega correta que usasse outras palavras: um check
 * determinístico inventado sobre uma frase é pior que nenhum check, porque
 * parece evidência. Sem juiz configurado o critério semântico fica UNVERIFIED,
 * que é "não medi", nunca "está errado".
 */
import type { AcceptanceCriterion, TaskContract } from './task-contract.js';
export interface ParsedAcceptance {
    /** Critérios prontos para entrar num contrato. */
    criteria: AcceptanceCriterion[];
    /**
     * Entradas recusadas, com o motivo. Recusa NÃO é silenciosa: um critério que
     * o usuário escreveu e o runtime descartou sem avisar é a pior forma de
     * verificação, porque o run termina VERIFIED sem ter medido o que foi pedido.
     */
    issues: string[];
}
/**
 * Converte as linhas do usuário em critérios.
 *
 * `id` é derivado da posição (`user:1`, `user:2`), não do texto: o texto pode
 * repetir, e dois critérios com o mesmo id calariam um deles na verificação.
 */
export declare function parseAcceptance(lines: string[]): ParsedAcceptance;
/**
 * A quais contratos os critérios do usuário se aplicam.
 *
 * As tarefas TERMINAIS que produzem produto: as que nenhuma outra tarefa de
 * produto consome. É onde o trabalho está inteiro. Aplicar o mesmo critério a
 * todo nó reprovaria a pesquisa por não conter o código, e multiplicaria a
 * chamada de juiz por nó do grafo, que é o custo que esta arquitetura existe
 * para não pagar.
 */
export declare function acceptanceTargets(contracts: TaskContract[]): string[];
/**
 * Acrescenta os critérios do usuário aos contratos-alvo.
 *
 * Os critérios determinísticos entram TAMBÉM em `verification.deterministic`,
 * que é a lista que a Verification Engine aplica ao artefato: um critério que
 * fica só em `acceptance` é registrado e não é medido.
 */
export declare function applyAcceptance(contracts: TaskContract[], criteria: AcceptanceCriterion[]): TaskContract[];
//# sourceMappingURL=acceptance.d.ts.map