Okay, let's break down these implementation steps for your codexcrmapp project. This plan involves significant restructuring towards a more scalable monorepo architecture, integrating robust backend patterns with tRPC, enhancing security with RLS, and setting up a solid foundation with migrations and testing.

I'll follow the order you provided, explaining each item and giving detailed commands and context based on your current repository state (assuming it's a standard Next.js app currently named shadcn-supabase-app at the root) and the target monorepo structure.

Important Preliminaries:

1. Terminal: Ensure you have a terminal open. When I say "your terminal" or "your codexcrmapp terminal," I mean the command-line interface pointing to the root directory of your project repository (codexcrmapp/).

2. Git: Make sure you commit your current changes before starting this major refactor:

   # In your current project directory (likely shadcn-supabase-app)
   git add .
   git commit -m "chore: pre-monorepo refactor commit"
   cd .. # Move one level up from shadcn-supabase-app
   # Now you should be in the directory containing shadcn-supabase-app
   
   

3. Tools: Ensure you have node, npm/pnpm (we'll use pnpm for workspaces), and the Supabase CLI installed and logged in (supabase login).

Item 1: Protect pages by wrapping layout components with your SupabaseProvider and checking session in a React Server Component.

• Explanation: This is about securing your application routes. Only logged-in users should access certain pages (like /clients, /dashboard, etc.). In Next.js App Router, the best place to do this is server-side within Server Components (Layouts or Pages) before rendering sensitive content. We use Supabase's server-side helpers (@supabase/ssr) to check the user's session. If no valid session exists, we redirect them to the sign-in page. The SupabaseProvider is typically used client-side to make the Supabase client instance available via context, but the primary protection happens server-side.
• Detailed Steps:

  1. Install Server-Side Helpers: If you haven't already, you need @supabase/ssr for robust server-side session management in Next.js.

     # Navigate into your app folder (before the move)
     cd shadcn-supabase-app
     pnpm add @supabase/ssr @supabase/supabase-js
     # Or if you use npm: npm install @supabase/ssr @supabase/supabase-js
     cd .. # Go back to the parent directory
     
     

     (After the monorepo setup, you'll run this in apps/web)

  2. Create Auth Helpers (Example): You likely have Supabase client setup (lib/supabase/client.ts, lib/supabase/server.ts). Ensure your server client creation uses createServerClient from @supabase/ssr. Let's assume you create a helper function lib/auth.ts (this path will change after the monorepo move).

     // Example: lib/auth.ts (adjust path and implementation based on your setup)
     import { createServerClient, type CookieOptions } from '@supabase/ssr';
     import { cookies } from 'next/headers';
     import { redirect } from 'next/navigation';
     
     export async function getSession() {
       const cookieStore = cookies();
       const supabase = createServerClient(
         process.env.NEXT_PUBLIC_SUPABASE_URL!,
         process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
         {
           cookies: {
             get(name: string) {
               return cookieStore.get(name)?.value;
             },
           },
         }
       );
       const { data: { session } } = await supabase.auth.getSession();
       return session;
     }
     
     export async function protectPage() {
       const session = await getSession();
       if (!session) {
         redirect('/sign-in'); // Or your login route
       }
       return session; // Return session if needed on the page
     }
     
     

  3. Protect a Page (Server Component): Open a page file you want to protect, for example, shadcn-supabase-app/app/clients/page.tsx. At the top of the component function, call your protection logic.

     // Example: shadcn-supabase-app/app/clients/page.tsx
     import { protectPage } from '@/lib/auth'; // Adjust import path
     
     export default async function ClientsPage() {
       const session = await protectPage(); // Checks session and redirects if null
     
       // If the code reaches here, the user is authenticated.
       // Fetch data or render the page content...
       // You can use the 'session' object if needed (e.g., session.user.id)
     
       return (
         <div>
           <h1>Clients Page (Protected)</h1>
           {/* Your client table or components go here */}
         </div>
       );
     }
     
     

  4. Protect Layouts: You can also apply protection to a layout file (e.g., app/dashboard/layout.tsx) to protect all routes under that layout. The principle is the same: check the session server-side at the beginning of the Layout Server Component.

  5. Supabase Provider (Client Context): Ensure your root layout (app/layout.tsx) correctly sets up the client-side context if components need access to the Supabase client interactively (e.g., for real-time subscriptions or client-side mutations, though tRPC often handles mutations). This typically involves creating a client Supabase client and passing it down. The @supabase/ssr package often includes examples for this context provider setup as well. The server-side check above handles the access control, while the provider handles client-side interaction.

• Note: After the monorepo move, these file paths will change (e.g., apps/web/app/clients/page.tsx, apps/web/lib/auth.ts).

Item 2: Turn on RLS from the Supabase dashboard and paste the “Owner can read/write” policy for every table.

• Explanation: Row Level Security (RLS) is a fundamental PostgreSQL feature that Supabase makes easy to manage. It ensures users can only access data rows they are permitted to see, typically based on their user ID. Enabling RLS and adding policies is crucial for multi-tenant applications like a CRM, where each user (practitioner) should only see their own clients, sessions, etc. The "Owner can read/write" policy is a common starting point.
• Prerequisites: Your tables (clients, services, programs, sessions, etc.) must have a column that references the user ID, commonly named user_id (type UUID) and often set up as a foreign key to auth.users(id).
• Detailed Steps:
  1. Go to Supabase Dashboard: Open your project in the Supabase Dashboard.
  2. Navigate to Policies: In the sidebar, go to Authentication -> Policies.
  3. Select a Table: Find one of your data tables (e.g., clients) in the list. If RLS is not enabled, it will say "0 policies".
  4. Enable RLS: Click on the table name. Toggle the switch "Enable Row Level Security (RLS)".
  5. Create Policies: Click "New Policy". You'll typically create policies for SELECT, INSERT, UPDATE, DELETE.
     • Option A: Use Templates (Easiest):
       • Click "New Policy" -> "Get started quickly".
       • Select the "Enable read access for authenticated users only" template.
         • Policy Name: Allow authenticated read access (or Owner can view)
         • Target roles: authenticated
         • USING expression: auth.uid() = user_id (Assuming your user ID column is user_id). Review and Save.
       • Click "New Policy" -> "Get started quickly".
       • Select the "Enable insert access for authenticated users only" template.
         • Policy Name: Allow authenticated insert access (or Owner can create)
         • Target roles: authenticated
         • WITH CHECK expression: auth.uid() = user_id. Review and Save.
       • Repeat for UPDATE (Enable update access based on user ID) and DELETE (Enable delete access based on user ID), ensuring the USING (for UPDATE/DELETE) and WITH CHECK (for UPDATE) expressions are auth.uid() = user_id.
     • Option B: Create Manually:
       • Click "New Policy" -> "Create a new policy from scratch".
       • SELECT Policy:
         • Policy Name: Owner can SELECT
         • Allowed operation: SELECT
         • Target roles: authenticated
         • USING expression: auth.uid() = user_id
       • INSERT Policy:
         • Policy Name: Owner can INSERT
         • Allowed operation: INSERT
         • Target roles: authenticated
         • WITH CHECK expression: auth.uid() = user_id
       • UPDATE Policy:
         • Policy Name: Owner can UPDATE
         • Allowed operation: UPDATE
         • Target roles: authenticated
         • USING expression: auth.uid() = user_id
         • WITH CHECK expression: auth.uid() = user_id
       • DELETE Policy:
         • Policy Name: Owner can DELETE
         • Allowed operation: DELETE
         • Target roles: authenticated
         • USING expression: auth.uid() = user_id
  6. Repeat for All Tables: Repeat steps 3-5 for every table that contains user-specific data (services, sessions, programs, notes, etc.).
• Blueprint Context: This corresponds to Section 3 of the blueprint ("Database & RLS Workflow"). The blueprint also mentions an SQL script (01_rls.sql) to automate this, which is a good practice once you move to CLI-managed migrations.

Item 3: Move to the Monorepo Structure.

• Explanation: This is the major restructuring step. You're converting your single Next.js application into a multi-package workspace managed by pnpm. This improves organization, code sharing (UI, types, server logic), and maintainability, especially as the application grows with background jobs and potentially other apps. We'll optionally add Turborepo later for optimized build/dev workflows.