/**
 * Brainstorm tool for generating diverse approach ideas
 *
 * This module implements a lightweight "brainstorm-only" mode that generates
 * multiple distinct approach ideas without implementing them. Uses a single
 * LLM call with higher temperature for creativity.
 *
 * Key differences from generate_solutions:
 * - Single LLM call instead of 1 + N (orchestrator + sub-agents)
 * - Returns structured ideas, not implementations
 * - Much faster and more cost-effective
 * - Claude implements after receiving ideas
 */
import type { LLMClient, ChatMessage } from "../../llm/client.js";
import type { ProgressCallback } from "../../llm/pool.js";
/**
 * A single approach idea from brainstorming
 */
export interface ApproachIdea {
    /** Unique identifier for this idea (1-indexed) */
    id: number;
    /** Brief name/description of the approach (max 50 chars) */
    approach: string;
    /** Why this approach fits (1-2 sentences) */
    rationale: string;
    /** Pros and cons (2-3 bullet points) */
    tradeoffs: string;
    /** Key considerations for implementation (2-3 bullet points) */
    implementation_hints: string;
}
/**
 * Error thrown when parsing brainstorm response fails
 */
export declare class BrainstormParseError extends Error {
    /** The raw response that failed to parse */
    readonly rawResponse: string;
    /** Specific parsing issue encountered */
    readonly parseIssue: string;
    constructor(message: string, rawResponse: string, parseIssue: string);
}
/**
 * System prompt for the brainstorm LLM call
 *
 * This prompt instructs the LLM to generate diverse approach ideas with:
 * - Brief approach name
 * - Rationale for why it fits
 * - Tradeoffs (pros/cons)
 * - Implementation hints
 *
 * Higher temperature (0.7) encourages creativity and diversity.
 */
export declare const BRAINSTORM_SYSTEM_PROMPT = "You are a senior software architect providing diverse solution approaches.\n\n## Your Role\n\nGiven a coding task and context, suggest multiple distinct approaches WITHOUT implementing them.\n\n## Instructions\n\n1. **Analyze the Task**: Understand the requirements, constraints, and goals.\n\n2. **Consider the Context**: Use the provided codebase information to understand:\n   - Existing patterns and conventions\n   - Available dependencies and utilities\n   - Code structure and organization\n\n3. **Generate Distinct Approaches**: Create exactly N different approaches where:\n   - Each approach uses a fundamentally different algorithm, pattern, or strategy\n   - Approaches should vary in trade-offs (e.g., simplicity vs performance, memory vs speed)\n   - Avoid minor variations of the same approach\n   - Consider both conventional and creative solutions\n\n4. **Provide Structured Information**: For each approach, include:\n   - **approach**: Brief name (max 50 characters)\n   - **rationale**: Why this approach fits the task (1-2 sentences)\n   - **tradeoffs**: Pros and cons (2-3 bullet points)\n   - **implementation_hints**: Key considerations for implementation (2-3 bullet points)\n\n## Output Format\n\nYou MUST respond with ONLY a valid JSON array. No markdown, no explanation, no code blocks.\n\nEach element in the array must have exactly these fields:\n- \"id\": Integer starting from 1\n- \"approach\": Brief name (max 50 chars)\n- \"rationale\": Why this approach fits (1-2 sentences)\n- \"tradeoffs\": Pros and cons (2-3 bullet points)\n- \"implementation_hints\": Key considerations for implementation (2-3 bullet points)\n\nExample output structure:\n[\n  {\n    \"id\": 1,\n    \"approach\": \"Token bucket algorithm\",\n    \"rationale\": \"Classic rate limiting algorithm with smooth burst handling. Well-suited for API rate limiting where occasional bursts are acceptable.\",\n    \"tradeoffs\": \"Pros: Simple to implement, handles bursts gracefully, memory-efficient\\nCons: Requires timer management, not distributed by default\",\n    \"implementation_hints\": \"- Use a timestamp and counter to track tokens\\n- Refill tokens based on elapsed time\\n- Consider using a background interval for auto-refill\"\n  },\n  {\n    \"id\": 2,\n    \"approach\": \"Sliding window counter\",\n    \"rationale\": \"Provides more accurate rate limiting by tracking requests in a rolling time window. Better for strict rate enforcement.\",\n    \"tradeoffs\": \"Pros: More accurate than fixed windows, prevents boundary gaming\\nCons: Higher memory usage, more complex state management\",\n    \"implementation_hints\": \"- Store timestamps of recent requests in a queue\\n- Prune old entries before checking limits\\n- Consider using a circular buffer for efficiency\"\n  }\n]\n\n## Guidelines for Good Approaches\n\n1. **Diversity**: Each approach should be meaningfully different:\n   - Different algorithms (e.g., BFS vs DFS, iterative vs recursive)\n   - Different data structures (e.g., array vs tree vs hash map)\n   - Different architectural patterns (e.g., event-driven vs polling)\n   - Different libraries or built-in features\n\n2. **Practicality**: All approaches should be implementable and reasonable:\n   - Consider the complexity budget\n   - Account for the existing codebase structure\n   - Ensure compatibility with stated requirements\n\n3. **Trade-off Awareness**: Document the trade-offs clearly:\n   - Performance characteristics\n   - Complexity and maintainability\n   - Resource usage\n   - Scalability considerations\n\nRemember: Output ONLY the JSON array. No other text.";
/**
 * Build the user message for brainstorming
 *
 * @param task - The task or problem to brainstorm for
 * @param context - Context about the codebase structure and relevant files
 * @param count - Number of ideas to generate
 * @returns Formatted user message string
 */
declare function buildUserMessage(task: string, context: string, count: number): string;
/**
 * Create the messages array for the brainstorm LLM call
 *
 * @param task - The task or problem to brainstorm for
 * @param context - Context about the codebase structure and relevant files
 * @param count - Number of ideas to generate (default: 3)
 * @returns Array of ChatMessage ready for the LLM client
 */
export declare function createBrainstormPrompt(task: string, context: string, count?: number): ChatMessage[];
/**
 * Extract JSON array from LLM response
 *
 * Handles various response formats:
 * - Raw JSON array
 * - JSON wrapped in markdown code blocks
 * - JSON with leading/trailing whitespace
 *
 * @param response - Raw LLM response string
 * @returns Extracted JSON string
 */
declare function extractJSON(response: string): string;
/**
 * Validate a single approach idea object
 *
 * @param obj - Object to validate
 * @param index - Index in array for error reporting
 * @returns Validated ApproachIdea
 * @throws Error if validation fails
 */
declare function validateApproachIdea(obj: unknown, index: number): ApproachIdea;
/**
 * Parse and validate brainstorm response into ApproachIdea array
 *
 * @param response - Raw response string from the brainstorm LLM
 * @returns Array of validated ApproachIdea objects
 * @throws BrainstormParseError if parsing or validation fails
 */
export declare function parseBrainstormResponse(response: string): ApproachIdea[];
/**
 * Input options for the brainstorm function
 */
export interface BrainstormOptions {
    /** The task or problem to brainstorm approaches for */
    task: string;
    /** Context about the codebase structure and relevant files */
    codebase_context: string;
    /** Number of approach ideas to generate (default: 3) */
    count?: number;
    /** Progress callback for reporting brainstorm progress */
    onProgress?: ProgressCallback;
}
/**
 * Output from the brainstorm function
 */
export interface BrainstormResult {
    /** Generated approach ideas */
    ideas: ApproachIdea[];
    /** Optional: ID of the recommended approach */
    recommended?: number;
}
/**
 * Generate diverse approach ideas for a coding task
 *
 * This is the main entry point for the brainstorm tool. It:
 * 1. Calls the LLM once with higher temperature to generate ideas
 * 2. Returns structured ideas with rationale, tradeoffs, and hints
 * 3. No execution phase - just planning
 *
 * Much faster and more cost-effective than generateSolutions since it's
 * a single LLM call instead of 1 + N (orchestrator + sub-agents).
 *
 * @param client - LLM client for API calls
 * @param model - Model ID to use for brainstorming
 * @param options - Brainstorm options including task, count, and context
 * @returns Promise resolving to approach ideas
 *
 * @example
 * ```typescript
 * const result = await brainstorm(client, "glm-4-plus", {
 *   task: "Implement a rate limiter",
 *   codebase_context: "TypeScript project using Express...",
 *   count: 3,
 * });
 * console.log(`Generated ${result.ideas.length} approach ideas`);
 * for (const idea of result.ideas) {
 *   console.log(`${idea.id}. ${idea.approach}`);
 *   console.log(`   Rationale: ${idea.rationale}`);
 * }
 * ```
 */
export declare function brainstorm(client: LLMClient, model: string, options: BrainstormOptions): Promise<BrainstormResult>;
export { extractJSON as _extractJSON };
export { validateApproachIdea as _validateApproachIdea };
export { buildUserMessage as _buildUserMessage };
//# sourceMappingURL=brainstorm.d.ts.map