Next.js Supabase V3 (#463)

Version 3 of the kit:
- Radix UI replaced with Base UI (using the Shadcn UI patterns)
- next-intl replaces react-i18next
- enhanceAction deprecated; usage moved to next-safe-action
- main layout now wrapped with [locale] path segment
- Teams only mode
- Layout updates
- Zod v4
- Next.js 16.2
- Typescript 6
- All other dependencies updated
- Removed deprecated Edge CSRF
- Dynamic Github Action runner

.claude/skills/server-action-builder/SKILL.md

@@ -17,19 +17,21 @@ Create validation schema in `_lib/schemas/`:
 
 ```typescript
 // _lib/schemas/feature.schema.ts
-import { z } from 'zod';
+import * as z from 'zod';
 
 export const CreateFeatureSchema = z.object({
   name: z.string().min(1, 'Name is required'),
   accountId: z.string().uuid('Invalid account ID'),
 });
 
-export type CreateFeatureInput = z.infer<typeof CreateFeatureSchema>;
+export type CreateFeatureInput = z.output<typeof CreateFeatureSchema>;
 ```
 
 ### Step 2: Create Service Layer
 
-**North star: services are decoupled from their interface.** The service is pure logic — it receives a database client as a dependency, never imports one. This means the same service works whether called from a server action, an MCP tool, a CLI command, or a plain unit test.
+**North star: services are decoupled from their interface.** The service is pure logic — it receives a database client
+as a dependency, never imports one. This means the same service works whether called from a server action, an MCP tool,
+a CLI command, or a plain unit test.
 
 Create service in `_lib/server/`:
 
@@ -62,11 +64,13 @@ class FeatureService {
 }
 ```
 
-The service never calls `getSupabaseServerClient()` — the caller provides the client. This keeps the service testable (pass a mock client) and reusable (any interface can supply its own client).
+The service never calls `getSupabaseServerClient()` — the caller provides the client. This keeps the service testable (
+pass a mock client) and reusable (any interface can supply its own client).
 
 ### Step 3: Create Server Action (Thin Adapter)
 
-The action is a **thin adapter** — it resolves dependencies (client, logger) and delegates to the service. No business logic lives here.
+The action is a **thin adapter** — it resolves dependencies (client, logger) and delegates to the service. No business
+logic lives here.
 
 Create action in `_lib/server/server-actions.ts`:
 
@@ -107,13 +111,18 @@ export const createFeatureAction = enhanceAction(
 
 ## Key Patterns
 
-1. **Services are pure, interfaces are thin adapters.** The service contains all business logic. The server action (or MCP tool, or CLI command) is glue code that resolves dependencies and calls the service. If an MCP tool and a server action do the same thing, they call the same service function.
-2. **Inject dependencies, don't import them in services.** Services receive their database client, logger, or any I/O capability as constructor arguments — never by importing framework-specific modules. This keeps them testable with stubs and reusable across interfaces.
+1. **Services are pure, interfaces are thin adapters.** The service contains all business logic. The server action (or
+   MCP tool, or CLI command) is glue code that resolves dependencies and calls the service. If an MCP tool and a server
+   action do the same thing, they call the same service function.
+2. **Inject dependencies, don't import them in services.** Services receive their database client, logger, or any I/O
+   capability as constructor arguments — never by importing framework-specific modules. This keeps them testable with
+   stubs and reusable across interfaces.
 3. **Schema in separate file** - Reusable between client and server
 4. **Logging** - Always log before and after operations
 5. **Revalidation** - Use `revalidatePath` after mutations
 6. **Trust RLS** - Don't add manual auth checks (RLS handles it)
-7. **Testable in isolation** - Because services accept their dependencies, you can test them with a mock client and no running infrastructure
+7. **Testable in isolation** - Because services accept their dependencies, you can test them with a mock client and no
+   running infrastructure
 
 ## File Structure