auth updated, ai chat improved, github import fixed

Author: Gerome-Elassaad

.env.example

@@ -0,0 +1,46 @@
+# E2B Configuration
+E2B_API_KEY="your_e2b_api_key_here"
+
+
+# AI API Keys
+ANTHROPIC_API_KEY="your_anthropic_api_key_here"
+DEEPSEEK_API_KEY="your_deepseek_api_key_here"
+FIREWORKS_API_KEY="your_fireworks_api_key_here"
+GOOGLE_AI_API_KEY="your_google_ai_api_key_here"
+MISTRAL_API_KEY="your_mistral_api_key_here"
+OPENAI_API_KEY="your_openai_api_key_here"
+TOGETHER_AI_API_KEY="your_together_ai_api_key_here"
+XAI_API_KEY="your_xai_api_key_here"
+
+# Google Services
+GOOGLE_CLIENT_ID="your_google_client_id_here"
+GOOGLE_VERTEX_CREDENTIALS="your_google_vertex_credentials_here"
+
+# GitHub Configuration
+GITHUB_PERSONAL_ACCESS_TOKEN="your_github_personal_access_token_here"
+NEXT_PUBLIC_GITHUB_CLIENT_ID="your_github_client_id_here"
+NEXT_PUBLIC_GITHUB_CLIENT_SECRET="your_github_client_secret_here"
+NEXT_PUBLIC_GITHUB_PRIVATE_KEY_PEM="your_github_private_key_pem_here"
+PATH_TO_PRIVATE_KEY_PEM="/path/to/your/private_key.pem"
+
+# Supabase Configuration
+NEXT_PUBLIC_ENABLE_SUPABASE="true"
+NEXT_PUBLIC_SUPABASE_URL="your_supabase_url_here"
+NEXT_PUBLIC_SUPABASE_ANON_KEY="your_supabase_anon_key_here"
+SUPABASE_SERVICE_ROLE_KEY="your_supabase_service_role_key_here"
+
+# PostHog Analytics
+NEXT_PUBLIC_POSTHOG_KEY="your_posthog_key_here"
+NEXT_PUBLIC_POSTHOG_HOST="https://us.i.posthog.com"
+
+# reCAPTCHA
+RECAPTCHA_SITE_KEY="your_recaptcha_site_key_here"
+RECAPTCHA_SECRET_KEY="your_recaptcha_secret_key_here"
+
+# Other APIs
+FIGMA_API_KEY="your_figma_api_key_here"
+
+# Application Configuration
+NEXT_PUBLIC_SITE_URL="https://yoursite.com"
+NEXT_PUBLIC_HIDE_LOCAL_MODELS="true"
+WEB_PUSH_CERTIFICATE="your_web_push_certificate_here"

.github/CODEOWNERS

@@ -0,0 +1,7 @@
+See [GitHub documentation](https://help.github.com/en/articles/about-code-owners)
+for more info about CODEOWNERS file.
+
+These owners will be the default owners for everything in
+the repo. Unless a later match takes precedence.
+
+@Gerome-Elassaad/CodingIT @Gerome-Elassaad

CODE_OF_CONDUCT.md .github/CODE_OF_CONDUCT.mdCODE_OF_CONDUCT.md renamed to .github/CODE_OF_CONDUCT.md

@@ -10,14 +10,17 @@
 # production
 /build
 
+# update files
+.clinerules
+.memory-bank
+
 # debug
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 .pnpm-debug.log*
 
 # env files
-.env*
 .env.local
 .env
 

CONTRIBUTING.md .github/CONTRIBUTING.mdCONTRIBUTING.md renamed to .github/CONTRIBUTING.md

@@ -0,0 +1,121 @@
+# AI Chat UI Improvement Plan
+
+## 1. Introduction and Goals
+
+This document outlines a plan to address potential bugs, practical errors, and areas for improvement within the existing AI Chat UI. The primary goals are to enhance stability, usability, and maintainability of the chat interface. The analysis covered frontend components, backend API interactions, state management, and overall code structure.
+
+## 2. Identified Issues and Proposed Solutions
+
+### 2.1. Configuration and Settings
+
+**Issue 2.1.1: `ChatSettings` API Key/Base URL Input Logic (components/chat-settings.tsx, app/page.tsx)**
+*   **Problem**: Conditional rendering based on `!process.env.NEXT_PUBLIC_NO_API_KEY_INPUT` might behave unexpectedly if env vars are undefined (showing inputs when they should be hidden). Placeholder "Auto" can be misleading when input is cleared.
+*   **Proposed Solution**:
+    *   Change env var check to be explicit, e.g., `process.env.NEXT_PUBLIC_NO_API_KEY_INPUT === 'true'`.
+    *   Improve UI feedback for cleared API key/Base URL fields. Instead of "Auto", perhaps show "Using default" or ensure the input visually reflects its empty state if that means "use global/default". Clarify if an empty input truly falls back to a system default or if it means "no key provided".
+
+**Issue 2.1.2: `ChatSidebar SettingsDialog` Display Settings Persistence (components/chat-sidebar/settings-dialog.tsx)**
+*   **Problem**: Display settings (Auto-save, Show timestamps, Compact view) are local to the dialog and not persisted or applied globally.
+*   **Proposed Solution**:
+    *   If these settings are intended to be functional, use `useLocalStorage` (similar to `languageModel` state in `app/page.tsx`) to persist their values.
+    *   Implement logic in relevant components (e.g., `ChatSessionItem`, `Chat.tsx`) to read and apply these settings. For example, "Compact view" could reduce padding/margins in chat items. "Show timestamps" would toggle timestamp visibility on messages. "Auto-save" might influence how/when sessions are saved (though current saving seems implicit).
+
+### 2.2. Error Handling and Feedback
+
+**Issue 2.2.1: Error Parsing in `EnhancedChatInput` for AI Enhance (components/enhanced-chat-input.tsx)**
+*   **Problem**: The `handleEnhanceMessage` feature uses basic error parsing (`error.message`) instead of the more robust `parseApiError` utility from `app/page.tsx`.
+*   **Proposed Solution**:
+    *   Refactor `EnhancedChatInput` to use or import `parseApiError` (or a shared error parsing utility) for the `/api/ai/enhance-text` call to provide more consistent and user-friendly error messages.
+
+**Issue 2.2.2: Clarity on Rate Limiting Feedback (app/page.tsx, components/enhanced-chat-input.tsx)**
+*   **Problem**: Rate limit feedback is primarily tied to the main `/api/chat` via `useObject`. Other API calls (e.g., `/api/sandbox`, `/api/ai/enhance-text`) might not trigger the same specific UI feedback if their error formats differ.
+*   **Proposed Solution**:
+    *   Ensure all backend API endpoints that can be rate-limited return a consistent error structure (e.g., `{ code: "RATE_LIMITED", message: "..." }`).
+    *   Update client-side error handling for all API calls to recognize this consistent rate limit error structure and set the `isRateLimited` state appropriately.
+
+### 2.3. Component Interactions and State
+
+**Issue 2.3.1: `EnhancedChatInput` GitHub Import DOM Manipulation (components/enhanced-chat-input.tsx)**
+*   **Problem**: Direct DOM manipulation (`textarea.value = ...; textarea.dispatchEvent(...)`) to set the chat input after GitHub import might conflict with React's controlled component pattern. The `setTimeout` for `handleSubmit` is also a minor concern.
+*   **Proposed Solution**:
+    *   Instead of direct DOM manipulation, the `handleGitHubImport` function should call `handleInputChange` (passed as a prop from `app/page.tsx`) to update the `chatInput` state in `app/page.tsx`. This ensures React controls the input value.
+    *   Evaluate if the `setTimeout` for `handleSubmit` is strictly necessary or if the state update can reliably trigger submission.
+
+**Issue 2.3.2: Redundant Floating Action Button (FAB) (app/page.tsx)**
+*   **Problem**: The "Create New Project" FAB (`FolderPlus` icon) is rendered twice with identical logic.
+*   **Proposed Solution**:
+    *   Remove one of the duplicate FAB rendering blocks in `app/page.tsx`.
+
+**Issue 2.3.3: Command Palette `onOpenSettings` Not Implemented (app/page.tsx)**
+*   **Problem**: The `CommandPalette`'s `onOpenSettings` prop is an empty function. The `isSettingsDialogOpen` state is unused.
+*   **Proposed Solution**:
+    *   Implement the `onOpenSettings` callback to toggle the `isSettingsDialogOpen` state.
+    *   Connect `isSettingsDialogOpen` to the `open` prop of the `SettingsDialog` from `components/chat-sidebar/settings-dialog.tsx` (or a new main settings dialog if appropriate). This requires passing down the state and setter or using a global state/context.
+
+**Issue 2.3.4: `Chat` Component's `setCurrentPreview` Prop Usage (app/page.tsx, components/chat.tsx)**
+*   **Problem**: `currentPreview` state (a string title) in `app/page.tsx` is set by `Chat` but doesn't seem to directly control the `Preview` panel's visibility or content, which is driven by the `fragment` object.
+*   **Proposed Solution**:
+    *   Clarify the role of `currentPreview`. If it's unused, remove it.
+    *   If it's intended for a feature (e.g., scrolling to a specific part of a preview or highlighting), implement that feature or remove the state to avoid confusion. The `onClick` in `Chat.tsx` that sets this could directly set the main `fragment` and `result` states if that's the goal.
+
+### 2.4. Data Handling and Display
+
+**Issue 2.4.1: `Chat` Component Image Rendering Performance (components/chat.tsx)**
+*   **Problem**: Large base64 encoded images in messages could impact rendering performance or hit browser data URI limits.
+*   **Proposed Solution**:
+    *   Consider client-side image resizing/compression before converting to base64 if feasible, especially for pasted images or very large uploads.
+    *   Alternatively, implement a size limit for image uploads/pastes with user feedback.
+    *   For display, ensure Next.js `Image` component's `sizes` and `quality` props are used effectively if applicable for base64.
+
+**Issue 2.4.2: Hardcoded Template Fallback for `codinit-engineer` (app/page.tsx)**
+*   **Problem**: A specific hardcoded fallback for the `codinit-engineer` template might mask a missing template in `templates.json` or indicate an undocumented special case.
+*   **Proposed Solution**:
+    *   Verify if `codinit-engineer` should be part of `lib/templates.json`. If yes, add it.
+    *   If it's a deliberate special case, add a comment explaining why it's handled this way.
+    *   Consider a more generic fallback mechanism if a template ID is not found in `templates` data to prevent runtime errors if other templates go missing.
+
+## 3. General UI/UX Enhancements
+
+*   **Loading States**: Review all loading states for consistency and clarity. Ensure spinners or loading indicators are present for all asynchronous operations (e.g., AI enhance, GitHub import analysis).
+*   **Empty States**: Improve empty state displays (e.g., no chat messages, no projects in sidebar) to be more informative and visually appealing.
+*   **Accessibility (A11y)**: While not deeply analyzed, ensure all interactive elements have proper ARIA attributes, keyboard navigation is smooth, and color contrasts meet WCAG guidelines. The existing use of `lucide-react` icons and Shadcn UI components is a good start.
+*   **Consistency in Terminology**: Ensure terms like "Project", "Session", "Fragment" are used consistently across the UI.
+
+## 4. Refactoring and Code Quality Suggestions
+
+*   **Shared Error Parsing**: Create a shared error parsing utility (e.g., in `lib/utils.ts` or `lib/errors.ts`) and use it across all components making API calls (e.g., `EnhancedChatInput`, `app/page.tsx` for sandbox execution).
+*   **State Management for Sidebar Settings**: If sidebar display settings become functional, consider moving their state to the `useChatSidebarStore` (Zustand store) for easier global access and persistence.
+*   **Environment Variable Handling**: Centralize or create helpers for accessing and parsing environment variables, especially for boolean flags, to ensure consistent interpretation.
+*   **Review `app/page.tsx` Complexity**: This file is very large and handles a lot of state and logic. Consider opportunities for further custom hooks or component modularization if complexity grows. For instance, logic related to fragment execution and its effects could potentially be encapsulated in a custom hook.
+
+## 5. High-Level Implementation Steps
+
+1.  **Configuration Fixes**:
+    *   Address Issue 2.1.1 (ChatSettings env vars and input clarity).
+    *   Address Issue 2.4.2 (codinit-engineer template).
+2.  **Error Handling Improvements**:
+    *   Address Issue 2.2.1 (EnhancedChatInput error parsing).
+    *   Address Issue 2.2.2 (Consistent rate limit feedback).
+3.  **Component Interaction & State Fixes**:
+    *   Address Issue 2.3.1 (EnhancedChatInput DOM manipulation).
+    *   Address Issue 2.3.2 (Redundant FAB).
+    *   Address Issue 2.3.3 (Command Palette settings).
+    *   Address Issue 2.1.2 (Sidebar display settings persistence and functionality - if deemed necessary).
+    *   Address Issue 2.3.4 (Chat component setCurrentPreview).
+4.  **Data Handling/Display Improvements**:
+    *   Address Issue 2.4.1 (Chat image performance - investigate and implement if significant).
+5.  **Code Refactoring**:
+    *   Implement shared error parsing utility.
+    *   Review and refactor other areas as identified during the fixes.
+6.  **Testing**:
+    *   Manually test all affected areas and user flows.
+    *   Consider adding automated tests for critical functionalities if not already present.
+
+## 6. Future Considerations
+
+*   **Optimistic Updates**: For actions like renaming chat sessions/projects or starring projects, implement optimistic updates for a smoother UX.
+*   **WebSockets for Real-time**: For a more dynamic experience, especially if collaboration features are planned, consider WebSockets.
+*   **Advanced Image Handling**: If image uploads are a core feature, consider dedicated image storage and serving instead of only base64 in messages, especially for larger files or more complex image manipulations.
+*   **Comprehensive End-to-End Testing**: As the application grows, a more robust testing strategy will be crucial.
+
+This plan provides a roadmap for the immediate improvements. Each item should be broken down into smaller, manageable tasks for implementation.

SECURITY.md .github/SECURITY.mdSECURITY.md renamed to .github/SECURITY.md

@@ -0,0 +1,83 @@
+# Implementation Plan: Fix Pylance Errors in `codeanalysisviewer.pyi`
+
+## 1. Analyze Errors and Identify Solutions
+
+The Pylance errors in `typings/gradio_codeanalysisviewer/codeanalysisviewer.pyi` stem from several issues:
+
+*   **Missing Type Arguments for Generics:**
+    *   `dict` is used without specifying key and value types (e.g., `dict` should be `dict[str, Any]`).
+    *   `Callable` is used without specifying argument and return types (e.g., `Callable` should be `Callable[..., Any]`).
+*   **Undefined Names:**
+    *   `Literal`: This type hint is used but not imported. It needs to be imported from `typing`.
+    *   `Block`: This type is used in method signatures but not defined or imported. Based on Gradio's typical structure, `Block` likely refers to `gradio.blocks.Block`.
+    *   `Dependency`: This type is used as a return type but not defined or imported. This likely refers to `gradio.dependencies.Dependency`.
+*   **String Literals as Types:**
+    *   Strings like `"full"`, `"minimal"`, `"hidden"`, `"once"`, `"multiple"`, `"always_last"`, `"default"` are used within `Literal` annotations. This is correct once `Literal` is imported.
+
+## 2. Implementation Steps
+
+To resolve these errors, the following changes will be made to `typings/gradio_codeanalysisviewer/codeanalysisviewer.pyi`:
+
+1.  **Add Imports:**
+    *   Import `Literal` from `typing`.
+    *   Import `Block` from `gradio.blocks`.
+    *   Import `Dependency` from `gradio.dependencies`.
+    *   Ensure `Any` is imported from `typing` (it already is).
+
+2.  **Specify Type Arguments for `dict`:**
+    *   Change `value: dict | Callable | None` to `value: dict[Any, Any] | Callable[..., Any] | None` in `__init__`. (Using `Any, Any` as a general placeholder, can be refined if more specific types are known for the dictionary's structure, but for a generic viewer, `Any` is often acceptable in stubs).
+    *   Change `payload: dict | None` to `payload: dict[Any, Any] | None` in `preprocess`.
+    *   Change `value: dict | None` to `value: dict[Any, Any] | None` in `postprocess`.
+    *   Change `cancels: dict[str, Any] | list[dict[str, Any]] | None` to `cancels: dict[str, Any] | list[dict[str, Any]] | None` (this one is already correctly typed for the dict part, but listed for completeness of review).
+
+3.  **Specify Type Arguments for `Callable`:**
+    *   Change `value: dict | Callable | None` to `value: dict[Any, Any] | Callable[..., Any] | None` in `__init__`.
+
+4.  **Address `TYPE_CHECKING` block:**
+    *   Move the new imports (`Block`, `Dependency`) into the `if TYPE_CHECKING:` block if they are only needed for type hinting and to avoid circular dependencies, which is a common practice in Gradio. `Literal` can stay at the top level.
+
+## 3. Code Changes (Diff Format)
+
+The following `replace_in_file` operations will be performed:
+
+```diff
+------- SEARCH
+from collections.abc import Callable, Sequence
+from typing import Any, TYPE_CHECKING
+from gradio.components.base import Component, FormComponent
+=======
+from collections.abc import Callable, Sequence
+from typing import Any, TYPE_CHECKING, Literal
+from gradio.components.base import Component, FormComponent
++++++++ REPLACE
+------- SEARCH
+if TYPE_CHECKING:
+    ...
+=======
+if TYPE_CHECKING:
+    from gradio.blocks import Block
+    from gradio.dependencies import Dependency
+    ...
++++++++ REPLACE
+------- SEARCH
+    def __init__(self, value: dict | Callable | None = ..., *, placeholder: str | None = ..., label: str | I18nData | None = ..., every: Timer | float | None = ..., inputs: Component | Sequence[Component] | set[Component] | None = ..., show_label: bool | None = ..., scale: int | None = ..., min_width: int = ..., interactive: bool | None = ..., visible: bool = ..., rtl: bool = ..., elem_id: str | None = ..., elem_classes: list[str] | str | None = ..., render: bool = ..., key: int | str | tuple[int | str, ...] | None = ..., preserved_by_key: list[str] | str | None = ...) -> None:
+=======
+    def __init__(self, value: dict[Any, Any] | Callable[..., Any] | None = ..., *, placeholder: str | None = ..., label: str | I18nData | None = ..., every: Timer | float | None = ..., inputs: Component | Sequence[Component] | set[Component] | None = ..., show_label: bool | None = ..., scale: int | None = ..., min_width: int = ..., interactive: bool | None = ..., visible: bool = ..., rtl: bool = ..., elem_id: str | None = ..., elem_classes: list[str] | str | None = ..., render: bool = ..., key: int | str | tuple[int | str, ...] | None = ..., preserved_by_key: list[str] | str | None = ...) -> None:
++++++++ REPLACE
+------- SEARCH
+    def preprocess(self, payload: dict | None) -> dict | None:
+=======
+    def preprocess(self, payload: dict[Any, Any] | None) -> dict[Any, Any] | None:
++++++++ REPLACE
+------- SEARCH
+    def postprocess(self, value: dict | None) -> dict | None:
+=======
+    def postprocess(self, value: dict[Any, Any] | None) -> dict[Any, Any] | None:
++++++++ REPLACE
+```
+
+*(Note: The diff for the `change`, `input`, and `submit` methods will be extensive due to the repeated nature of `Block`, `Literal`, and `Dependency`. The key is to ensure these types are correctly imported and used. The example above shows the import changes and the first few direct type fixes. The repeated parameter lists in `change`, `input`, `submit` will be implicitly corrected by the imports of `Block`, `Literal`, and `Dependency`.)*
+
+## 4. Verification
+
+After applying the changes, Pylance errors should be resolved. The type stub file will be more accurate and provide better type checking for users of the `CodeAnalysisViewer` component.