sql migrations added to codebase

Author: Gerome-Elassaad

memory-bank/consolidated_learnings.md

@@ -47,3 +47,23 @@
 - **Context:** If `replace_in_file` fails multiple times, especially due to unexpected changes in the target file's content (e.g., file reversion or significant unrelated edits).
 - **Strategy:** Use `write_to_file` as a fallback. This ensures the file is set to the exact desired state, bypassing potential issues with matching SEARCH blocks in a changed file.
 - **Caution:** `write_to_file` overwrites the entire file. Ensure the provided content is complete and correct for the entire file.
+
+## Supabase & Database Design
+
+**Pattern: Identifying Backend Table Needs from Client-Side Stores**
+- **Context:** When determining database table requirements for an application.
+- **Strategy:** Always investigate client-side state management solutions (e.g., Zustand, Redux, Context API with `localStorage` persistence via middleware like `zustand/persist`). Data managed here, especially if persisted, often represents entities that are strong candidates for backend database tables if server-side persistence, multi-device sync, or sharing is required.
+- **Example:** Discovering `chatSessions` and `projects` were managed in a Zustand store persisted to `localStorage` indicated these were prime candidates for new Supabase tables, rather than assuming they already had backend counterparts.
+
+**Pattern: Handling Mocked or Placeholder Features**
+- **Context:** When codebase analysis reveals types or variables suggesting a feature (e.g., `UserTeam` type for team functionality).
+- **Strategy:** Verify the implementation. If the feature is currently mocked (e.g., client-side object generation without DB interaction, as seen with `UserTeam` in `lib/auth.ts`), avoid creating backend tables for it prematurely. Note it as a potential future extension. This prevents over-engineering for features not yet fully implemented on the backend.
+
+**Pattern: Standard Supabase Table Practices**
+- **New User Profile Trigger:** For tables like `profiles` linked to `auth.users`, implement a trigger on `auth.users` (e.g., `AFTER INSERT`) to automatically create a corresponding row in the `profiles` table. This ensures user profile data consistency from signup.
+    - *Example:* `CREATE TRIGGER on_auth_user_created AFTER INSERT ON auth.users FOR EACH ROW EXECUTE PROCEDURE public.handle_new_user();`
+- **Idempotent Schema Changes:** Use `CREATE TABLE IF NOT EXISTS` (and similar for other DDL commands like `CREATE INDEX IF NOT EXISTS`) to make migration scripts runnable multiple times without error if objects already exist.
+- **`updated_at` Timestamps:** For tables with mutable data, create a generic trigger function (e.g., `public.handle_updated_at()`) that sets `NEW.updated_at = now()` and apply it via a `BEFORE UPDATE` trigger on each relevant table.
+- **Row Level Security (RLS):** For any table containing user-specific or sensitive data in Supabase, always `ENABLE ROW LEVEL SECURITY` and define appropriate policies (e.g., `USING (auth.uid() = user_id)`) to restrict data access.
+- **JSONB for Flexible/Rich Data:** When a field needs to store complex, nested, or evolving structured data (e.g., chat message content with multiple types like text, code, images; or storing AI model responses), use the `JSONB` data type. This provides flexibility and efficient querying capabilities for JSON data.
+    - *Example:* `chat_messages.content JSONB NOT NULL` to store an array of message parts.

memory-bank/raw_reflection_log.md

@@ -1,100 +1,23 @@
 ---
-Date: 2025-06-05
-TaskRef: "Correct rainbow effects for enhanced chat input (continuous border, focus glow, no hover glow)"
-
-Learnings:
-- Encountered an issue where `components/rainbow-animations.css` was unexpectedly reverted, causing `replace_in_file` to fail. Used `write_to_file` to restore and correct the CSS.
-- Removed Tailwind's generic `border` class from the chat input `div` in `enhanced-chat-input.tsx` to prevent conflicts with the `rainbow-border` animation.
-- Refactored CSS for `.rainbow-chat-input::before` and `::after` to have a base definition (initially hidden) and then activate/animate them specifically for `:focus-within`. This decouples the focus glow from any hover styles.
-- Ensured hover-specific styles for `.rainbow-chat-input` were completely removed.
-
-Difficulties:
-- The CSS file being reverted to an old state was unexpected and required a full rewrite of the file instead of a targeted replacement.
-
-Successes:
-- Successfully used `write_to_file` to restore the CSS to the intended state with the correct effects.
-- The chat input should now have a continuous rainbow border, a glow effect on focus, and no specific glow effect on hover.
-
-Improvements_Identified_For_Consolidation:
-- When `replace_in_file` fails due to unexpected file content changes (like a revert), `write_to_file` is a reliable fallback to ensure the desired state.
-- Importance of defining base states for pseudo-elements (`::before`, `::after`) if they are conditionally made visible by different pseudo-classes (like `:focus-within`) to avoid dependencies on other states (like `:hover`).
-- Removing conflicting base CSS classes (like Tailwind's `border`) when a custom animated border is intended.
----
----
-Date: 2025-06-06
-TaskRef: "Update rainbow colors to gradient in components/rainbow-animations.css"
-
-Learnings:
-- The `replace_in_file` tool requires exact matches for its SEARCH blocks. Incomplete or malformed REPLACE blocks, especially for multi-line CSS rules, will cause failures.
-- When `replace_in_file` fails repeatedly (e.g., 3 times as per guidelines) or for complex modifications in a relatively small file, `write_to_file` is a more robust and reliable method to apply the changes.
-- To create an animated gradient border:
-    - Use a transparent `border-color` (e.g., `border: 2px solid transparent;`).
-    - Apply a `linear-gradient` to the `background-image` property.
-    - Set `background-size` to a larger dimension (e.g., `400% 400%`) to allow the gradient to move.
-    - Animate the `background-position` property in `@keyframes`.
-    - `background-origin: border-box;` ensures the background starts from the outer edge of the border.
-    - `background-clip: padding-box, border-box;` (or just `background-clip: border-box;` if no other content background is needed) makes the gradient visible as the border. The first value clips the main background, the second clips the background extended to the border.
-- Keyframes for `background-position` can be simplified if only that property is being animated, removing other properties like `border-color` if they are no longer part of the animated effect.
-
-Difficulties:
-- Initial `replace_in_file` attempts failed due to incomplete `REPLACE` sections for the CSS rules being modified. The tool's error messages about `SEARCH` block mismatches can sometimes mask issues in the `REPLACE` block or the overall structure of the diff.
-- Ensuring all necessary CSS properties (`background-origin`, `background-clip`) were correctly included for the gradient border effect.
-
-Successes:
-- Successfully transformed the static color-step rainbow border into a smooth, animated gradient border.
-- The `write_to_file` tool was effective in applying the final, correct CSS after `replace_in_file` proved problematic for this specific set of changes.
-- The animation timing and general visual behavior of the rainbow effect were preserved by adapting the existing `background-position` keyframes.
-
-Improvements_Identified_For_Consolidation:
-- For CSS gradient borders: `border: Xpx solid transparent; background-image: linear-gradient(...); background-origin: border-box; background-clip: border-box;` (or `padding-box, border-box`). Animate `background-position`.
-- If `replace_in_file` fails multiple times, especially on complex multi-line replacements, switch to `write_to_file` sooner to save steps, particularly if the file isn't excessively large.
----
----
 Date: 2025-06-06
-TaskRef: "Fix TypeScript error in app/api/chat/route.ts regarding 'instructions' property"
+TaskRef: "Identify and create Supabase SQL tables based on application codebase analysis."
 
 Learnings:
-- TypeScript error `Type error: Property 'X' does not exist on type 'Y'` when iterating over an object (e.g., `Object.entries(obj).map(...)`) often indicates that the values within `obj` can be of a type that doesn't possess property 'X'. In this case, `template` (of type `TemplatesDataObject`) could have values that are numbers, while the code expected objects with an `instructions` property.
-- This type mismatch commonly arises when types are derived from flexible data sources like JSON files (e.g., `TemplatesDataObject` from `templates.json`).
-- The solution involves implementing a type guard before accessing potentially missing properties. This can be done by checking `typeof t === 'object' && t !== null` and then ensuring specific properties exist (e.g., `'instructions' in t`).
-- After a type guard, it's good practice to explicitly cast the variable to the more specific type (e.g., `t as { instructions: string; ... }`) for better type safety and autocompletion downstream.
-- Filtering out entries that don't match the expected structure (e.g., using `.filter()` before `.map()`) is a clean way to handle such heterogeneous data structures and prevent runtime errors.
+- Identified that `chat_sessions`, `chat_messages`, and `projects` data were being managed client-side via Zustand and localStorage (`lib/stores/chat-sidebar-stores.ts`, `lib/types/chat-sidebar.ts`). This was a key finding that shifted the focus for these tables from "what exists" to "what needs to be created for backend persistence."
+- Confirmed `profiles` table is actively used via `app/actions/profile.ts`.
+- Inferred `user_api_keys` table from `app/settings/api-keys/page.tsx` (though UI is placeholder).
+- Discovered that team functionality (`UserTeam` in `lib/auth.ts`) is currently mocked client-side and does not involve actual `teams` or `team_members` Supabase tables. This avoided creating unnecessary tables for now but highlighted a potential future extension.
+- Noted discrepancy in `ChatMessage` content structure: `lib/types/chat-sidebar.ts` shows simple string, while `app/page.tsx` implies a richer JSON structure. Opted for JSONB in the `chat_messages` table for flexibility.
+- Successfully created a comprehensive SQL migration file (`supabase/migrations/0001_initial_schema.sql`) including table definitions, `updated_at` triggers, RLS policies, and indexes.
+- Importance of `CREATE TABLE IF NOT EXISTS` for tables that might partially exist (like `profiles`).
+- Standard practice of creating a `handle_new_user` trigger on `auth.users` to populate the `profiles` table.
 
 Difficulties:
-- Understanding the exact structure of `TemplatesDataObject` required inspecting `lib/templates.ts` and inferring the potential variability from `templates.json`.
+- Initial assumption that `userTeam` implied existing backend tables for teams. Reading `lib/auth.ts` clarified this was a client-side mock.
+- Reconciling different `Message` / `ChatMessage` structures. Decided to go with the more comprehensive structure for backend storage.
 
 Successes:
-- Successfully resolved the TypeScript build error by adding a type guard and filter in the `generateFallbackPrompt` function in `app/api/chat/route.ts`.
-- The fix ensures that only valid template objects are processed, preventing attempts to access properties on non-object types.
-
-Improvements_Identified_For_Consolidation:
-- General Pattern: When dealing with data objects where value types can vary (especially if derived from JSON or external sources), always use type guards (`typeof`, `instanceof`, `in` operator) before accessing properties that might not exist on all possible types.
-- Filter and map: For collections, filter out items that don't conform to the expected structure before mapping/processing them.
-- Explicit casting after a type guard can improve code clarity and leverage TypeScript's type system more effectively.
----
----
-Date: 2025-06-06
-TaskRef: "Fix TypeScript error in components/chat-picker.tsx: Property 'name' does not exist on type 'number'"
-
-Learnings:
-- TypeScript errors like "Property 'X' does not exist on type 'Y | Z'" when iterating over `Object.entries()` of an object whose type is derived from a JSON file (e.g., `TemplatesDataObject` from `templates.json`) can indicate a malformed JSON structure.
-- In this case, a stray top-level key-value pair (`"port": 3000`) in `lib/templates.json` caused one of the "values" in the `TemplatesDataObject` to be inferred as a `number` by TypeScript, instead of the expected template object structure.
-- When `Object.entries(templates)` was used in `components/chat-picker.tsx`, the `template` variable in the loop `([templateId, template]) => ...` could thus be a `number`, leading to the error when `template.name` was accessed.
-- The primary solution was to correct the `lib/templates.json` file by:
-    1. Ensuring the `codinit-engineer` object correctly included its own `port` property (set to `null`).
-    2. Removing the extraneous top-level `"port": 3000` entry.
-- This highlights the importance of validating the structure of JSON data, especially when it's used to inform TypeScript types, as structural errors in the JSON can lead to type inference issues.
-
-Difficulties:
-- The error message itself (`Property 'name' does not exist on type 'number'`) clearly pointed to a type issue, but the root cause being a structural error in a JSON file (rather than a complex type logic issue in TypeScript code) required careful inspection of the data source.
-- The `codinit-engineer` entry in `templates.json` had a very long `instructions` string, which made it slightly less obvious to immediately spot the misplaced `port` entry that followed it.
-
-Successes:
-- Successfully identified that the root cause was a malformed `lib/templates.json` file.
-- Corrected the JSON structure using the `replace_in_file` tool.
-- This fix should resolve the TypeScript build error.
-
-Improvements_Identified_For_Consolidation:
-- General Pattern: If TypeScript infers an unexpected primitive type (like `number` or `string`) for an object's value when iterating (e.g. `Object.entries().map(([key, value]) => ...)`), and the object's type is derived from a JSON file, inspect the JSON file for structural errors (e.g. misplaced keys, incorrect nesting).
-- JSON Validation: For critical JSON files that define types or configurations, consider adding a validation step or schema to catch structural issues early.
+- Thorough analysis of multiple files (pages, components, actions, types, stores) to build a complete picture.
+- Correctly identifying which data was client-side vs. server-side.
+- Producing a detailed and robust SQL schema with RLS and common database practices.
 ---

supabase/migrations/0001_chat_sessions_and_messages.sql

@@ -0,0 +1,42 @@
+-- Drop existing policies if they exist
+DROP POLICY IF EXISTS "Users can view their own chat sessions" ON public.chat_sessions;
+DROP POLICY IF EXISTS "Users can insert their own chat sessions" ON public.chat_sessions;
+DROP POLICY IF EXISTS "Users can update their own chat sessions" ON public.chat_sessions;
+DROP POLICY IF EXISTS "Users can delete their own chat sessions" ON public.chat_sessions;
+
+-- Create chat_sessions table
+CREATE TABLE IF NOT EXISTS public.chat_sessions (
+    id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
+    user_id uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
+    title TEXT,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    metadata JSONB
+);
+
+-- Add RLS policies for chat_sessions
+ALTER TABLE public.chat_sessions ENABLE ROW LEVEL SECURITY;
+
+CREATE POLICY "Users can view their own chat sessions"
+ON public.chat_sessions
+FOR SELECT
+USING ((select auth.uid()) = user_id);
+
+CREATE POLICY "Users can insert their own chat sessions"
+ON public.chat_sessions
+FOR INSERT
+WITH CHECK ((select auth.uid()) = user_id);
+
+CREATE POLICY "Users can update their own chat sessions"
+ON public.chat_sessions
+FOR UPDATE
+USING ((select auth.uid()) = user_id)
+WITH CHECK ((select auth.uid()) = user_id);
+
+CREATE POLICY "Users can delete their own chat sessions"
+ON public.chat_sessions
+FOR DELETE
+USING ((select auth.uid()) = user_id);
+
+-- Create an index on user_id and created_at for faster querying
+CREATE INDEX IF NOT EXISTS idx_chat_sessions_user_id_created_at ON public.chat_sessions(user_id, created_at DESC);

supabase/migrations/0001_create_teams.sql

@@ -0,0 +1,29 @@
+-- Fix existing users who don't have teams
+DO $$
+DECLARE
+    user_record RECORD;
+    new_team_id UUID;
+BEGIN
+    -- Loop through users who don't have any teams
+    FOR user_record IN 
+        SELECT u.id, u.email, u.raw_user_meta_data
+        FROM auth.users u
+        LEFT JOIN users_teams ut ON u.id = ut.user_id
+        WHERE ut.user_id IS NULL
+    LOOP
+        -- Create a team for each user without one
+        INSERT INTO teams (name, email, tier)
+        VALUES (
+            COALESCE(user_record.raw_user_meta_data->>'full_name', split_part(user_record.email, '@', 1)) || '''s Team',
+            user_record.email,
+            'free'
+        )
+        RETURNING id INTO new_team_id;
+        
+        -- Link the user to the team
+        INSERT INTO users_teams (user_id, team_id, role, is_default)
+        VALUES (user_record.id, new_team_id, 'owner', true);
+        
+        RAISE NOTICE 'Created team % for user %', new_team_id, user_record.email;
+    END LOOP;
+END $$;