**Critical Analysis Toolkit - Application Requirements** **1. Core Purpose:** To provide users with a tool that uses the Gemini API to perform various types of critical analysis on user-provided text. The goal is to offer different perspectives, identify weaknesses, uncover blind spots, and explore alternative solutions. **2. General Application Behavior:** - The application shall be a single-page web application (SPA). - It must be responsive and adapt to various screen sizes (desktop, tablet, mobile). - It must support light and dark themes, respecting system preference and allowing user override (though user override UI for theme is not explicitly in current code, the mechanism is). - It must provide clear instructions on how to use the application. - It must handle errors gracefully and provide informative messages to the user. - All interactions with the Gemini API should be asynchronous, with visual feedback for loading/processing states. - The application must not include any UI for entering or managing the Gemini API key. The API key must be exclusively sourced from the process.env.API_KEY environment variable. **3. User Input:** - **Text Area Input:** - Users must be able to directly type or paste text into a multi-line text area. - The content of the text area should be persisted in localStorage so it's available if the user reloads the page. - **File Upload:** - Users must be able to upload text files. - Supported file types: .txt (text/plain) and .md (text/markdown). - Upon successful file upload, its content should populate the text input area. - The original name of the uploaded file should be stored (e.g., in localStorage and associated with analysis results for export). - Error handling for invalid file types or read errors. - **Input Area Management:** - The input area (textarea and file upload) should be collapsible to save screen space. - Input fields should be disabled during ongoing analysis operations. **4. Analysis Types:** The application must support the following predefined analysis types, each with a specific prompt template: - **Adversarial Critique:** Identify weakest points and potential exploits. - **Red Teaming:** Identify compromise vectors, failures, unintended negative consequences. - **Johari (Unknown-Unknowns):** Speculate on overlooked areas, factors, or consequences. - **Devil's Advocate:** Rigorously challenge core premises, assumptions, and conclusions. - **Inversion:** Describe how to achieve the opposite outcome or ensure failure. - **Contrarian Approach:** Propose unconventional perspectives or solutions. - **Blind Spots & Gaps:** Identify missing information, unstated assumptions, logical gaps. - **Full Solution Space:** Explore a wide range of alternative approaches beyond the stated text. **5. Analysis Process & Gemini API Interaction:** - **API Client Initialization:** - Initialize the @google/genai client using new GoogleGenAI({ apiKey: process.env.API_KEY }). - Handle potential errors during client initialization. - **Model:** Use gemini-2.5-flash-preview-04-17 for all text-based analyses. - **Prompting:** - For each analysis type, use a specific, pre-defined prompt template (as in constants.ts). - The user's input text must be inserted into the {userInput} placeholder in the template. - Prompts must instruct the model to cite specific examples or phrases from the input text to support its points. - **Content Generation:** - Use the ai.models.generateContentStream method for streaming responses. - Thinking config should default to enabled (omit thinkingConfig or set thinkingBudget > 0) for higher quality. - **Error Handling:** - Implement robust error handling for API calls (e.g., invalid API key, network issues, model errors). - Provide clear error messages to the user for specific failures (e.g., API key issues, empty input). - If an analysis completes but the API returns no content (empty stream), inform the user, suggesting potential API key issues or an empty response for their input. **6. Displaying Analysis Results:** - **Individual Analysis Cards:** - Each analysis result (or ongoing analysis) should be displayed in its own distinct card. - The card must clearly display the AnalysisType. - While an analysis is in progress (loading or streaming), a loading indicator (e.g., spinner) must be shown in the card. - The generated content should be displayed as it streams in. - Render the content as Markdown, supporting GitHub Flavored Markdown (GFM). - If an error occurs for a specific analysis, display an error message within its card. - If no analysis has been performed or content is not yet available (and not loading/error), display a placeholder message. - **Result Management:** - Results should be displayed in a consistent order (e.g., the order defined in AnalysisType). - Only display cards for analyses that have been initiated (i.e., have content, are loading, or have an error). - **Card Actions (for completed & successful analysis):** - **Copy to Clipboard:** A button to copy the generated text content of that specific analysis to the clipboard. Provide feedback (e.g., "Copied!"). - **Save as Markdown:** A button to download the generated text content of that specific analysis as a .md file. The filename should be dynamically generated (e.g., [originalFileName_if_any_or_AnalysisType]_[AnalysisType_Sanitized]_[timestamp].md). **7. Global Controls & Actions:** - **Analysis Selection:** - Provide individual buttons for each AnalysisType to trigger that specific analysis. - Buttons should indicate a loading/processing state if that specific analysis is running. - Buttons should be disabled if any analysis is globally in progress (e.g., "Run All") or if the input is empty. - **"Run All Analyses":** - A button to trigger all available analysis types sequentially on the current input text. - This button should show a "Processing All..." state and be disabled during its operation. - Other individual analysis buttons should also be disabled during "Run All". - **"Clear All Results":** - A button to clear all currently displayed analysis results, error messages, and reset their states. - This should also clear any global error messages. - Disabled if any analysis is actively running. - **"Export All Results":** - A button to compile all successfully generated analysis results into a single Markdown file for download. - The export should include a header with the input source (file name or "Text Input") and a timestamp. - Each analysis should be a section in the Markdown file, clearly titled with its AnalysisType. - Disabled if any analysis is actively running or if there are no results to export. - **Global Error Display:** A dedicated area to display global errors (e.g., empty input before analysis, file read errors not specific to one analysis card). **8. UI/UX Details:** - **Styling:** Use Tailwind CSS for styling. - **Icons:** Use SVG icons for UI elements like chevrons for collapsible sections. - **Accessibility:** - Use appropriate ARIA attributes (e.g., aria-label, aria-expanded, role="alert") to enhance accessibility. - Ensure good color contrast for text and UI elements in both light and dark themes. - **Layout:** - Header with application title. - Collapsible instructions section. - Collapsible user input section. - Global error message area. - Analysis controls section (buttons for each type + "Run All"). - Results section (with "Clear All" and "Export All" buttons, followed by analysis cards). - Footer with a brief attribution (e.g., "Powered by Gemini API"). **9. State Management:** - The application needs to manage: - User input string. - Original uploaded file name (if any). - State for each analysis type (isLoading, isStreaming, content, error, originalFileName). - Global error messages. - State of collapsible sections (instructions, input area). - State for "Run All Analyses" in progress.