@cubis/foundry 0.3.82 → 0.3.84

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/drizzle-orm/SKILL.md

@@ -1,81 +0,0 @@
----
-name: drizzle-orm
-description: "Use when building or refactoring TypeScript data layers with Drizzle ORM: schema-as-code, relational queries, type-safe SQL, drizzle-kit migrations, and edge/serverless deployment patterns."
----
-# Drizzle ORM
-
-## Purpose
-
-Guide developers through production-grade Drizzle ORM usage including TypeScript-first schema definition, relational query building, type-safe SQL composition, drizzle-kit migration workflows, and deployment patterns for edge and serverless runtimes. This skill ensures type-safe, performant, and migration-safe database layers in TypeScript applications.
-
-## When to Use
-
-- Defining or refactoring Drizzle schema files with `pgTable`, `sqliteTable`, or `mysqlTable`.
-- Building relational queries with `db.query.*` API or composing type-safe SQL with `select()`.
-- Creating, reviewing, or troubleshooting drizzle-kit migration workflows.
-- Deploying Drizzle-backed APIs to edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy).
-- Migrating from Prisma, TypeORM, or raw SQL to Drizzle ORM.
-- Tuning query performance, connection pooling, or prepared statement strategies.
-
-## Instructions
-
-1. **Confirm the target database engine and runtime before writing schema code** because Drizzle uses engine-specific schema builders (`pgTable`, `sqliteTable`, `mysqlTable`) that produce different SQL dialects, and mixing them causes build-time type errors and runtime failures.
-
-2. **Define all tables in schema files using the TypeScript-first schema API** because Drizzle derives all TypeScript types directly from schema definitions, making `typeof users.$inferSelect` and `typeof users.$inferInsert` the single source of truth for both database and application types, eliminating type drift.
-
-3. **Use `relations()` declarations for every foreign key relationship** because Drizzle's relational query API (`db.query.users.findMany({ with: { posts: true } })`) requires explicit relation definitions to function, and missing relations silently fall back to returning incomplete data.
-
-4. **Prefer the relational query API for reads that involve joins** because it generates optimized SQL with proper JOIN or subquery strategies, provides fully typed nested results, and eliminates the manual mapping layer that raw `select().from().leftJoin()` requires.
-
-5. **Use the SQL-like `select()` API for writes, aggregations, and complex WHERE clauses** because the relational query API is read-optimized and does not support `INSERT`, `UPDATE`, `DELETE`, `GROUP BY`, or subquery composition, which are core to transactional write paths.
-
-6. **Configure `drizzle-kit` with explicit `schema`, `out`, and `dialect` fields** because ambiguous configuration causes migrations to target the wrong tables or generate empty diffs, and dialect mismatch between config and schema silently produces invalid SQL.
-
-7. **Run `drizzle-kit generate` in CI to detect schema-migration drift** because developers frequently modify schema files without generating a migration, and this drift only surfaces during deployment when the database does not match the schema.
-
-8. **Use `drizzle-kit push` only for prototyping and development databases** because push applies schema changes directly without migration files, making production rollback impossible and leaving no audit trail of schema evolution.
-
-9. **Write migration files with both up and down logic when custom SQL is needed** because drizzle-kit auto-generated migrations handle schema additions but frequently miss data transformations, enum modifications, and index strategy changes that require manual intervention.
-
-10. **Scope database connections to the runtime deployment model** because Cloudflare Workers use D1 or Hyperdrive bindings, Vercel Edge uses connection strings with `@vercel/postgres`, and Node.js uses `database-design` or `better-sqlite3`, each requiring different Drizzle driver initialization.
-
-11. **Use `$inferSelect` and `$inferInsert` types instead of manually defining interfaces** because Drizzle derives these types from the schema at compile time, and manual interfaces drift from the schema as columns are added, renamed, or made nullable.
-
-12. **Use `prepared()` statements for hot-path queries** because prepared statements skip the SQL compilation step on repeated execution, reducing latency by 20-40% in high-throughput endpoints, and Drizzle's `.prepare()` method makes this a one-line optimization.
-
-13. **Validate schema changes against the target database before deploying** because Drizzle generates SQL at build time but does not validate against the live schema, so renaming a column that a deployed migration already renamed will produce a duplicate alteration error at runtime.
-
-14. **Separate read-only queries from write operations at the connection level** because read replicas, connection pooling, and edge caching all depend on clean read/write separation that Drizzle supports through multiple `drizzle()` instances.
-
-15. **Test Drizzle queries against the target database engine, not in-memory mocks** because SQLite, Postgres, and MySQL have different type coercion, JSON handling, and constraint enforcement behaviors that mocks cannot reproduce.
-
-16. **Use transactions for multi-table writes with `db.transaction()`** because Drizzle does not auto-wrap related writes in a transaction, and interleaved failures without transactions leave the database in an inconsistent state that is expensive to diagnose and repair.
-
-## Output Format
-
-Provide implementation guidance, code examples, and configuration as appropriate to the task. Include complete schema definitions, query patterns, migration scripts, and drizzle-kit configuration when the task requires them. Use TypeScript with strict mode throughout.
-
-## References
-
-| File | Load when |
-| --- | --- |
-| `references/schema-definition.md` | Defining or refactoring table schemas, column types, constraints, relations, or type inference patterns. |
-| `references/queries.md` | Writing relational queries, SQL-like queries, transactions, prepared statements, or aggregation patterns. |
-| `references/migrations.md` | Creating, reviewing, or troubleshooting drizzle-kit migrations, push vs generate workflow, or migration chain management. |
-
-## Scripts
-
-No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
-
-## Examples
-
-- "Help me design a Drizzle schema for a multi-tenant SaaS with Postgres"
-- "Review my drizzle-kit migration workflow for production safety"
-
-## Antigravity Platform Notes
-
-- Use Agent Manager for parallel agent coordination and task delegation.
-- Skill and agent files are stored under `.agent/skills/` and `.agent/agents/` respectively.
-- TOML command files in `.agent/commands/` provide slash-command entry points for workflows.
-- Replace direct `@agent-name` delegation with Agent Manager dispatch calls.
-- Reference files are loaded relative to the skill directory under `.agent/skills/<skill-id>/`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/drizzle-orm/evals/assertions.md

@@ -1,52 +0,0 @@
-# Drizzle ORM Eval Assertions
-
-## Eval 1: Schema Definition with Relations
-
-This eval tests the ability to produce a correctly structured Drizzle ORM schema with table definitions, relations, type inference, and indexes for a multi-entity blog platform.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `pgTable` — Correct table builder               | PostgreSQL requires pgTable. Using the wrong dialect builder produces incompatible SQL and type errors at build time. |
-| 2 | contains | `relations` — Relation declarations              | Drizzle's relational query API (db.query.*) requires explicit relation definitions. Without them, nested queries silently return incomplete data. |
-| 3 | contains | `$inferSelect` — Schema-derived types            | Manual TypeScript interfaces drift from the schema as columns change. $inferSelect and $inferInsert are the single source of truth. |
-| 4 | contains | `references` — Foreign key constraints           | Foreign keys enforce referential integrity at the database level. Relations alone only enable the query API — they do not create constraints. |
-| 5 | contains | `pgEnum` — Native PostgreSQL enum                | Post status as pgEnum enforces valid values at the database level and produces a fully typed column in TypeScript, unlike plain varchar. |
-| 6 | contains | `primaryKey` — Junction table composite key      | Many-to-many junction tables without a composite primary key allow duplicate rows, corrupting the relationship. |
-
-### What a passing response looks like
-
-- A `users` table with email, displayName, and role columns.
-- A `posts` table with title, content, and a `pgEnum` status column (draft/published/archived).
-- A `comments` table with foreign keys to posts and users.
-- A `tags` table and a `postsToTags` junction table with a composite primary key.
-- `relations()` declarations for all entities enabling nested queries.
-- `$inferSelect` and `$inferInsert` type exports for at least the main entities.
-- Indexes on foreign key columns (authorId on posts, postId on comments).
-
----
-
-## Eval 2: Migration Workflow
-
-This eval tests the ability to produce a safe drizzle-kit migration workflow including schema changes, migration generation, custom data migration, and deployment steps.
-
-### Assertions
-
-| # | Type     | What it checks                                  | Why it matters                                                                                       |
-|---|----------|-------------------------------------------------|------------------------------------------------------------------------------------------------------|
-| 1 | contains | `drizzle-kit` — Migration tool usage             | Drizzle ORM relies on drizzle-kit for migration management. Omitting it means no structured migration workflow. |
-| 2 | contains | `generate` — Migration file generation           | `drizzle-kit generate` creates versioned SQL files. Using `push` instead skips file creation and makes rollback impossible. |
-| 3 | contains | `pgEnum` — Native enum for status column         | Using pgEnum ensures the database rejects invalid status values. A plain varchar with application validation can be bypassed. |
-| 4 | contains | `transaction` — Atomic data migration            | Data migrations that update existing rows must be wrapped in transactions. Partial updates from failed migrations leave data inconsistent. |
-| 5 | contains | `default` — Default value on new column          | Adding a NOT NULL column without a default to a table with existing rows fails. Defaults ensure backward compatibility during migration. |
-
-### What a passing response looks like
-
-- A `drizzle.config.ts` with schema path, output directory, and dialect.
-- Schema changes: new `orgStatusEnum`, new `organizations` table, nullable `organizationId` on users.
-- Command sequence: `drizzle-kit generate` to create the migration file.
-- Generated SQL reviewed (CREATE TYPE, CREATE TABLE, ALTER TABLE ADD COLUMN).
-- A custom data migration script using `db.transaction()` to set all users to "active" status.
-- Command to apply: `drizzle-kit migrate`.
-- No use of `drizzle-kit push` for production.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/drizzle-orm/evals/evals.json

@@ -1,71 +0,0 @@
-[
-  {
-    "name": "drizzle-schema-definition-with-relations",
-    "description": "Validate that the skill produces correct Drizzle schema definitions with proper table builders, column types, relations, type inference, and index declarations for a multi-entity domain.",
-    "input": "Design a Drizzle ORM schema for a blog platform using PostgreSQL. The domain includes: users (email, display name, role), posts (title, content, status as draft/published/archived, author), comments (content, post, author), and tags with a many-to-many relationship to posts. Include type inference, relations, and indexes on foreign keys. Use pgTable and the relational query API conventions.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "pgTable",
-        "description": "Tables must be defined using pgTable since the target is PostgreSQL. Using sqliteTable or mysqlTable would generate incompatible SQL."
-      },
-      {
-        "type": "contains",
-        "value": "relations",
-        "description": "Relation declarations must be present for the relational query API (db.query.*) to function. Missing relations cause incomplete query results."
-      },
-      {
-        "type": "contains",
-        "value": "$inferSelect",
-        "description": "Type inference must use $inferSelect and $inferInsert from the schema rather than manually defined interfaces, preventing type drift."
-      },
-      {
-        "type": "contains",
-        "value": "references",
-        "description": "Foreign key columns must use .references() to create database-level constraints for referential integrity."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The post status (draft/published/archived) should use pgEnum to leverage PostgreSQL native enums for type safety at both database and TypeScript levels."
-      },
-      {
-        "type": "contains",
-        "value": "primaryKey",
-        "description": "The many-to-many junction table (posts-to-tags) must have a composite primary key to prevent duplicate associations."
-      }
-    ]
-  },
-  {
-    "name": "drizzle-migration-workflow",
-    "description": "Validate that the skill produces a correct drizzle-kit migration workflow including configuration, generation, custom data migration, and deployment safety practices.",
-    "input": "I have an existing Drizzle schema with a users table (id, email, name, created_at). I need to: (1) add a 'status' enum column (active, suspended, deleted) with default 'active', (2) add an 'organization_id' foreign key column that's nullable for now, (3) create the organizations table, and (4) write a data migration to set all existing users to 'active' status. Show the full drizzle-kit workflow: config, schema changes, generate, custom migration, and apply steps.",
-    "assertions": [
-      {
-        "type": "contains",
-        "value": "drizzle-kit",
-        "description": "The workflow must reference drizzle-kit commands (generate, migrate, or push) since drizzle-kit is the migration tool for Drizzle ORM."
-      },
-      {
-        "type": "contains",
-        "value": "generate",
-        "description": "The workflow must use drizzle-kit generate (not push) to create migration files, since push is unsafe for production databases."
-      },
-      {
-        "type": "contains",
-        "value": "pgEnum",
-        "description": "The status column must be defined as a pgEnum to leverage PostgreSQL native enums rather than plain varchar, ensuring database-level validation."
-      },
-      {
-        "type": "contains",
-        "value": "transaction",
-        "description": "The data migration must be wrapped in a transaction to ensure atomicity — partial backfills leave the database in an inconsistent state."
-      },
-      {
-        "type": "contains",
-        "value": "default",
-        "description": "The new status column must have a default value ('active') so that existing rows and future inserts without explicit status are handled correctly."
-      }
-    ]
-  }
-]

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/drizzle-orm/examples/01-basic-schema.md

@@ -1,153 +0,0 @@
-# Example: Basic Schema Definition and Queries
-
-## Scenario
-
-A team is building a project management API with Drizzle ORM and PostgreSQL. They need a schema for users, teams, and projects with basic CRUD queries. The application runs on Node.js with the `postgres` driver.
-
-## Prompt
-
-"Help me set up a Drizzle schema for a project management app. I need users, teams, and projects tables. Users belong to teams, and projects belong to teams. Include basic queries for creating users, fetching a team's projects, and updating a project name."
-
-## Expected Output
-
-### Drizzle Configuration
-
-```typescript
-// drizzle.config.ts
-import { defineConfig } from "drizzle-kit";
-
-export default defineConfig({
-  schema: "./src/db/schema/index.ts",
-  out: "./drizzle/migrations",
-  dialect: "postgresql",
-  dbCredentials: {
-    url: process.env.DATABASE_URL!,
-  },
-});
-```
-
-### Schema Definitions
-
-```typescript
-// src/db/schema/teams.ts
-import { pgTable, serial, varchar, timestamp } from "drizzle-orm/pg-core";
-import { relations } from "drizzle-orm";
-
-export const teams = pgTable("teams", {
-  id: serial("id").primaryKey(),
-  name: varchar("name", { length: 100 }).notNull(),
-  slug: varchar("slug", { length: 100 }).notNull().unique(),
-  createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-});
-
-export const teamsRelations = relations(teams, ({ many }) => ({
-  members: many(users),
-  projects: many(projects),
-}));
-```
-
-```typescript
-// src/db/schema/users.ts
-import { pgTable, serial, varchar, integer, timestamp, uniqueIndex } from "drizzle-orm/pg-core";
-import { relations } from "drizzle-orm";
-import { teams } from "./teams";
-
-export const users = pgTable(
-  "users",
-  {
-    id: serial("id").primaryKey(),
-    email: varchar("email", { length: 255 }).notNull(),
-    displayName: varchar("display_name", { length: 100 }).notNull(),
-    teamId: integer("team_id").references(() => teams.id),
-    createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-  },
-  (table) => [uniqueIndex("ix_users_email").on(table.email)]
-);
-
-export const usersRelations = relations(users, ({ one }) => ({
-  team: one(teams, {
-    fields: [users.teamId],
-    references: [teams.id],
-  }),
-}));
-```
-
-```typescript
-// src/db/schema/projects.ts
-import { pgTable, serial, varchar, text, integer, timestamp } from "drizzle-orm/pg-core";
-import { relations } from "drizzle-orm";
-import { teams } from "./teams";
-
-export const projects = pgTable("projects", {
-  id: serial("id").primaryKey(),
-  name: varchar("name", { length: 200 }).notNull(),
-  description: text("description"),
-  teamId: integer("team_id").notNull().references(() => teams.id),
-  createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-  updatedAt: timestamp("updated_at", { withTimezone: true }),
-});
-
-export const projectsRelations = relations(projects, ({ one }) => ({
-  team: one(teams, {
-    fields: [projects.teamId],
-    references: [teams.id],
-  }),
-}));
-```
-
-```typescript
-// src/db/schema/index.ts
-export * from "./teams";
-export * from "./users";
-export * from "./projects";
-```
-
-### Database Instance
-
-```typescript
-// src/db/index.ts
-import { drizzle } from "drizzle-orm/postgres-js";
-import postgres from "postgres";
-import * as schema from "./schema";
-
-const client = postgres(process.env.DATABASE_URL!);
-export const db = drizzle(client, { schema });
-```
-
-### Basic Queries
-
-```typescript
-import { db } from "./db";
-import { users, teams, projects } from "./db/schema";
-import { eq } from "drizzle-orm";
-
-// Create a user
-const [newUser] = await db.insert(users).values({
-  email: "alice@example.com",
-  displayName: "Alice",
-  teamId: 1,
-}).returning();
-
-// Fetch a team with its projects using relational query API
-const teamWithProjects = await db.query.teams.findFirst({
-  where: eq(teams.id, 1),
-  with: { projects: true },
-});
-
-// Update a project name
-await db.update(projects)
-  .set({ name: "New Project Name", updatedAt: new Date() })
-  .where(eq(projects.id, 5));
-
-// Type inference
-type User = typeof users.$inferSelect;
-type NewUser = typeof users.$inferInsert;
-```
-
-## Key Decisions
-
-- **`serial` for primary keys** — simpler than UUID for a non-distributed system, avoids index fragmentation.
-- **`relations()` declared separately from tables** — required for the relational query API (`db.query.*`).
-- **`$inferSelect` and `$inferInsert`** — derived types from the schema eliminate manual interface drift.
-- **`withTimezone: true` on timestamps** — prevents timezone-related bugs when the server and database are in different zones.
-- **Schema organized per entity** — one file per domain table with its relations, re-exported from `index.ts`.

package/workflows/workflows/agent-environment-setup/platforms/antigravity/skills/drizzle-orm/examples/02-advanced-migrations.md

@@ -1,191 +0,0 @@
-# Example: Advanced Migrations and Relations
-
-## Scenario
-
-A SaaS application needs to evolve its Drizzle schema. The team must add a multi-tenant structure with organizations, handle a many-to-many relationship between users and organizations with roles, create a custom enum, and write a data migration that backfills existing users into a default organization. The team uses PostgreSQL and `drizzle-kit` for migrations.
-
-## Prompt
-
-"I need to add multi-tenancy to my Drizzle app. Create an organizations table, a junction table linking users to organizations with roles, add a custom status enum, and show me how to write a migration that backfills existing users into a default org. I want both the drizzle-kit workflow and a custom data migration."
-
-## Expected Output
-
-### New Schema Additions
-
-```typescript
-// src/db/schema/organizations.ts
-import {
-  pgTable, serial, varchar, timestamp, pgEnum, integer, index,
-} from "drizzle-orm/pg-core";
-import { relations } from "drizzle-orm";
-
-export const orgStatusEnum = pgEnum("org_status", ["active", "suspended", "archived"]);
-
-export const organizations = pgTable("organizations", {
-  id: serial("id").primaryKey(),
-  name: varchar("name", { length: 200 }).notNull(),
-  slug: varchar("slug", { length: 100 }).notNull().unique(),
-  status: orgStatusEnum("status").notNull().default("active"),
-  createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
-  updatedAt: timestamp("updated_at", { withTimezone: true }),
-});
-
-export const organizationsRelations = relations(organizations, ({ many }) => ({
-  memberships: many(orgMemberships),
-}));
-```
-
-```typescript
-// src/db/schema/org-memberships.ts
-import {
-  pgTable, integer, varchar, timestamp, primaryKey, index,
-} from "drizzle-orm/pg-core";
-import { relations } from "drizzle-orm";
-import { users } from "./users";
-import { organizations } from "./organizations";
-
-export const orgMemberships = pgTable(
-  "org_memberships",
-  {
-    userId: integer("user_id").notNull().references(() => users.id, { onDelete: "cascade" }),
-    orgId: integer("org_id").notNull().references(() => organizations.id, { onDelete: "cascade" }),
-    role: varchar("role", { length: 20 }).notNull().default("member"),
-    joinedAt: timestamp("joined_at", { withTimezone: true }).notNull().defaultNow(),
-  },
-  (table) => [
-    primaryKey({ columns: [table.userId, table.orgId] }),
-    index("ix_org_memberships_org").on(table.orgId),
-  ]
-);
-
-export const orgMembershipsRelations = relations(orgMemberships, ({ one }) => ({
-  user: one(users, { fields: [orgMemberships.userId], references: [users.id] }),
-  organization: one(organizations, { fields: [orgMemberships.orgId], references: [organizations.id] }),
-}));
-```
-
-### Step 1: Generate the structural migration
-
-```bash
-# Generate migration from schema diff
-npx drizzle-kit generate
-
-# This creates a file like: drizzle/migrations/0003_add_organizations.sql
-# containing CREATE TYPE, CREATE TABLE, and index statements.
-```
-
-### Step 2: Review the generated migration
-
-```sql
--- drizzle/migrations/0003_add_organizations.sql (auto-generated, reviewed)
-CREATE TYPE "org_status" AS ENUM ('active', 'suspended', 'archived');
-
-CREATE TABLE "organizations" (
-  "id" serial PRIMARY KEY NOT NULL,
-  "name" varchar(200) NOT NULL,
-  "slug" varchar(100) NOT NULL,
-  "status" "org_status" DEFAULT 'active' NOT NULL,
-  "created_at" timestamp with time zone DEFAULT now() NOT NULL,
-  "updated_at" timestamp with time zone
-);
-
-CREATE UNIQUE INDEX "organizations_slug_unique" ON "organizations" ("slug");
-
-CREATE TABLE "org_memberships" (
-  "user_id" integer NOT NULL REFERENCES "users"("id") ON DELETE CASCADE,
-  "org_id" integer NOT NULL REFERENCES "organizations"("id") ON DELETE CASCADE,
-  "role" varchar(20) DEFAULT 'member' NOT NULL,
-  "joined_at" timestamp with time zone DEFAULT now() NOT NULL,
-  CONSTRAINT "org_memberships_pkey" PRIMARY KEY ("user_id", "org_id")
-);
-
-CREATE INDEX "ix_org_memberships_org" ON "org_memberships" ("org_id");
-```
-
-### Step 3: Write a custom data migration
-
-```typescript
-// scripts/migrate-backfill-default-org.ts
-import { db } from "../src/db";
-import { organizations, orgMemberships } from "../src/db/schema";
-import { users } from "../src/db/schema";
-
-async function backfillDefaultOrg() {
-  await db.transaction(async (tx) => {
-    // 1. Create the default organization
-    const [defaultOrg] = await tx
-      .insert(organizations)
-      .values({ name: "Default Organization", slug: "default" })
-      .returning();
-
-    // 2. Fetch all existing users
-    const allUsers = await tx.select({ id: users.id }).from(users);
-
-    // 3. Batch insert memberships (500 at a time to avoid parameter limits)
-    const batchSize = 500;
-    for (let i = 0; i < allUsers.length; i += batchSize) {
-      const batch = allUsers.slice(i, i + batchSize);
-      await tx.insert(orgMemberships).values(
-        batch.map((u) => ({
-          userId: u.id,
-          orgId: defaultOrg.id,
-          role: "member" as const,
-        }))
-      );
-    }
-
-    console.log(`Backfilled ${allUsers.length} users into default org.`);
-  });
-}
-
-backfillDefaultOrg().catch(console.error).finally(() => process.exit());
-```
-
-### Step 4: Apply and verify
-
-```bash
-# Apply the structural migration
-npx drizzle-kit migrate
-
-# Run the data backfill
-npx tsx scripts/migrate-backfill-default-org.ts
-
-# Verify: check migration status
-npx drizzle-kit check
-```
-
-### Querying many-to-many relations
-
-```typescript
-// Fetch a user with all their organizations
-const userWithOrgs = await db.query.users.findFirst({
-  where: eq(users.id, userId),
-  with: {
-    memberships: {
-      with: { organization: true },
-    },
-  },
-});
-
-// Access: userWithOrgs.memberships[0].organization.name
-// Access: userWithOrgs.memberships[0].role
-
-// Fetch all members of an organization
-const orgMembers = await db.query.organizations.findFirst({
-  where: eq(organizations.id, orgId),
-  with: {
-    memberships: {
-      with: { user: true },
-    },
-  },
-});
-```
-
-## Key Decisions
-
-- **`pgEnum` for status** — uses PostgreSQL native ENUM, enforced at the database level, fully typed in Drizzle.
-- **Composite primary key on junction table** — prevents duplicate memberships and serves as the clustered index.
-- **Separate data migration script** — drizzle-kit auto-generated migrations handle DDL but not data transformations. Custom scripts wrapped in `db.transaction()` ensure atomicity.
-- **Batch inserts in data migration** — PostgreSQL has a parameter limit (~65535). Batching prevents exceeding it for large user tables.
-- **`onDelete: "cascade"` on junction foreign keys** — removing a user or org automatically cleans up memberships.
-- **`drizzle-kit generate` then review** — never run `drizzle-kit push` in production. Always generate, review, then apply.