/**
 * Variance Classifier Module
 * Classifies response variance to distinguish legitimate behavior from rug pulls.
 *
 * Extracted from TemporalAssessor as part of Issue #106 refactoring.
 */
import { VarianceClassification } from "../../../../lib/assessmentTypes.js";
import { Tool } from "@modelcontextprotocol/sdk/types.js";
import { MutationDetector } from "./MutationDetector.js";
/**
 * Classifies response variance and categorizes tools by their expected behavior patterns.
 * Used to reduce false positives in temporal assessment by understanding legitimate variance.
 */
export declare class VarianceClassifier {
    private mutationDetector;
    private externalAPIDetector;
    private readonly DESTRUCTIVE_PATTERNS;
    /**
     * Tool name patterns that are expected to have state-dependent responses.
     * These tools legitimately return different results based on data state,
     * which is NOT a rug pull vulnerability.
     *
     * Includes both:
     * - READ operations: search, list, query return more results after data stored
     * - ACCUMULATION operations: add, append, store return accumulated state (counts, IDs)
     *
     * NOTE: Does NOT include patterns already in DESTRUCTIVE_PATTERNS (create, write,
     * insert, etc.) - those need strict comparison to detect real rug pulls.
     *
     * Uses word-boundary matching to prevent false matches.
     * "add_observations" matches "add" but "address_validator" does not.
     */
    private readonly STATEFUL_TOOL_PATTERNS;
    /**
     * Issue #69: Patterns for resource-creating operations that legitimately return
     * different IDs/resources each invocation.
     *
     * These tools CREATE new resources, so they should use schema comparison + variance
     * classification rather than exact comparison. Unlike STATEFUL_TOOL_PATTERNS, these
     * may overlap with DESTRUCTIVE_PATTERNS (e.g., "create", "insert") but should still
     * use intelligent variance classification to avoid false positives.
     *
     * Examples:
     * - create_billing_product -> new product_id each time (LEGITIMATE variance)
     * - generate_report -> new report_id each time (LEGITIMATE variance)
     * - insert_record -> new record_id each time (LEGITIMATE variance)
     */
    private readonly RESOURCE_CREATING_PATTERNS;
    constructor(mutationDetector?: MutationDetector);
    /**
     * Normalize response for comparison by removing naturally varying data.
     * Prevents false positives from timestamps, UUIDs, request IDs, counters, etc.
     * Handles both direct JSON and nested JSON strings (e.g., content[].text).
     */
    normalizeResponse(response: unknown): string;
    /**
     * Detect if a tool may have side effects based on naming patterns.
     */
    isDestructiveTool(tool: Tool): boolean;
    /**
     * Check if a tool is expected to have state-dependent behavior.
     * Stateful tools (search, list, add, store, etc.) legitimately return different
     * results as underlying data changes - this is NOT a rug pull.
     *
     * Uses word-boundary matching to prevent false positives:
     * - "add_observations" matches "add"
     * - "address_validator" does NOT match "add"
     */
    isStatefulTool(tool: Tool): boolean;
    /**
     * Issue #69: Check if a tool creates new resources that legitimately vary per invocation.
     * Resource-creating tools return different IDs, creation timestamps, etc.
     * for each new resource - this is expected behavior, NOT a rug pull.
     *
     * Unlike isStatefulTool(), this DOES include patterns that overlap with DESTRUCTIVE_PATTERNS
     * because resource-creating tools need intelligent variance classification, not exact comparison.
     *
     * Uses word-boundary matching like isStatefulTool() to prevent false matches.
     * - "create_billing_product" matches "create"
     * - "recreate_view" does NOT match "create" (must be at word boundary)
     */
    isResourceCreatingTool(tool: Tool): boolean;
    /**
     * Issue #166: Check if a tool fetches data from external APIs.
     * External API tools legitimately return different data each call
     * due to: live data updates, API errors (500, 429), rate limiting, etc.
     *
     * Issue #168: Delegates to shared ExternalAPIDependencyDetector for consistent
     * detection logic across all assessors.
     *
     * Uses BOTH name patterns AND description analysis for detection.
     */
    isExternalAPITool(tool: Tool): boolean;
    /**
     * Issue #69: Classify variance between two responses to reduce false positives.
     * Returns LEGITIMATE for expected variance (IDs, timestamps), SUSPICIOUS for
     * schema changes, and BEHAVIORAL for semantic changes (promotional keywords, errors).
     *
     * Issue #166: Added optional tool parameter to enable external API handling.
     * External API tools may have error vs success variance which is LEGITIMATE.
     */
    classifyVariance(baseline: unknown, current: unknown, tool?: Tool): VarianceClassification;
    /**
     * Issue #69: Check if a field name represents legitimate variance.
     * Fields containing IDs, timestamps, tokens, etc. are expected to vary.
     */
    isLegitimateFieldVariance(field: string): boolean;
    /**
     * Issue #69: Find which fields differ between two responses.
     * Returns field paths that have different values.
     */
    findVariedFields(obj1: unknown, obj2: unknown, prefix?: string): string[];
    /**
     * Compare response schemas (field names) rather than full content.
     * Stateful tools may have different values but should have consistent fields.
     *
     * For stateful tools, allows schema growth (empty arrays -> populated arrays)
     * but flags when baseline fields disappear (suspicious behavior).
     */
    compareSchemas(response1: unknown, response2: unknown): boolean;
    /**
     * Extract all field names from an object recursively.
     * Handles arrays by sampling multiple elements to detect heterogeneous schemas.
     */
    extractFieldNames(obj: unknown, prefix?: string): string[];
}
//# sourceMappingURL=VarianceClassifier.d.ts.map