ui-syncup 0.3.13 → 0.4.0-beta.2

package/.ai/steering/structure.md

@@ -0,0 +1,275 @@
+# Project Structure
+
+## Overview
+
+Feature-first architecture following the scaffolding guidelines in `AGENTS.md`. Code is organized by product feature rather than technical type, with strict layering and clear boundaries.
+
+## Directory Layout
+
+```
+src/
+├── app/                          # Next.js App Router (routing only)
+│   ├── layout.tsx                # Root layout (html, body, global providers)
+│   ├── (public)/                 # Public routes (no auth required)
+│   │   ├── layout.tsx            # Public shell
+│   │   ├── sign-in/page.tsx
+│   │   └── sign-up/page.tsx
+│   ├── (protected)/              # Protected routes (auth required)
+│   │   ├── layout.tsx            # Auth gate (server-side session check)
+│   │   ├── onboarding/page.tsx   # Post-auth team setup (no team required)
+│   │   ├── settings/             # User settings
+│   │   └── (team)/               # Team-scoped routes
+│   │       ├── projects/page.tsx
+│   │       └── team/settings/    # Team settings
+│   └── api/                      # API route handlers
+│       └── auth/                 # Auth endpoints
+│
+├── features/                     # Feature modules (mini-packages)
+│   ├── <feature>/
+│   │   ├── api/                  # Fetchers + DTO schemas (no React)
+│   │   ├── hooks/                # React Query/SWR wrappers
+│   │   ├── components/           # Feature-specific UI
+│   │   ├── screens/              # Screen components (thin, compose hooks)
+│   │   ├── types/                # Domain models
+│   │   ├── utils/                # Feature-specific helpers
+│   │   └── index.ts              # Barrel export (public API)
+│   │
+│   ├── annotations/              # Visual annotation system
+│   ├── auth/                     # Authentication & onboarding
+│   ├── issues/                   # Issue tracking & details
+│   ├── projects/                 # Project management
+│   ├── teams/                    # Team creation
+│   ├── team-settings/            # Team settings screens
+│   └── user-settings/            # User preferences & settings
+│
+├── components/
+│   ├── ui/                       # shadcn primitives (Button, Dialog, etc.)
+│   └── shared/                   # Cross-feature widgets
+│       ├── headers/              # AppHeader, breadcrumbs
+│       ├── sidebar/              # AppSidebar, navigation
+│       ├── notifications/        # Notification system
+│       └── settings-sidebar/     # Settings navigation
+│
+├── config/                       # Single sources of truth (pure data)
+│   ├── quotas.ts                 # Resource limits (Instance Config)
+│   ├── roles.ts                  # RBAC roles & permissions
+│   ├── workflow.ts               # Issue workflow states
+│   ├── settings-nav.ts           # Settings navigation
+│   ├── team-settings-nav.ts      # Team settings navigation
+│   └── issue-options.ts          # Issue metadata options
+│
+├── lib/                          # App-wide utilities
+│   ├── api-client.ts             # Fetch wrapper (credentials: 'include')
+│   ├── query.tsx                 # React Query setup
+│   ├── utils.ts                  # cn() helper (clsx + tailwind-merge)
+│   ├── env.ts                    # Environment variables
+│   ├── logger.ts                 # Logging utility
+│   └── performance.ts            # Performance monitoring
+│
+├── server/                       # Server-only logic (auth, DB, RBAC)
+│   ├── auth/                     # Session, tokens, RBAC
+│   │   ├── cookies.ts            # httpOnly cookie management
+│   │   ├── password.ts           # Argon2 password hashing
+│   │   ├── rate-limiter.ts       # Redis-based rate limiting
+│   │   ├── rbac.ts               # Role-based access control
+│   │   ├── session.ts            # Session management
+│   │   └── tokens.ts             # JWT token handling
+│   ├── db/                       # Database client & schema
+│   │   ├── schema/               # Drizzle schema definitions
+│   │   └── index.ts              # Database client
+│   ├── email/                    # Email service
+│   │   ├── client.ts             # Resend client
+│   │   ├── queue.ts              # Email queue management
+│   │   ├── templates/            # React Email templates
+│   │   └── worker.ts             # Background email processor
+│   └── teams/                    # Team management services
+│       ├── team-service.ts       # Core team operations
+│       ├── member-service.ts     # Member management
+│       ├── invitation-service.ts # Invitation handling
+│       ├── member-counts.ts      # Member counting logic
+│       └── resource-limits.ts    # Resource usage limits
+│
+├── mocks/                        # Mock data & fixtures
+│   ├── issue.fixtures.ts
+│   ├── project.fixtures.ts
+│   ├── team.fixtures.ts
+│   ├── user.fixtures.ts
+│   ├── annotation.fixtures.ts
+│   └── index.ts
+│
+├── hooks/                        # Global hooks
+│   ├── use-mobile.ts
+│   ├── use-team.ts
+│   └── use-long-press.ts
+│
+├── providers/                    # React context providers
+│   └── theme-provider.tsx
+│
+├── styles/
+│   └── globals.css               # Global styles & Tailwind imports
+│
+└── types/                        # Global TypeScript types
+
+cli/                              # CLI package (published independently to npm)
+│   ├── index.ts                  # Entry point — shebang #!/usr/bin/env node
+│   ├── commands/                 # Subcommands: init, up, down, reset, purge
+│   ├── lib/                      # Shared CLI utilities (ui, prompts, docker, supabase…)
+│   ├── templates/                # Config templates copied by `ui-syncup init`
+│   ├── package.json              # Standalone npm package manifest (NOT private)
+│   ├── tsup.config.ts            # Build config: bundles cli/ → dist/index.js
+│   ├── .npmignore                # Excludes TS source and tests from npm tarball
+│   └── dist/                     # GENERATED — compiled CJS bundle (gitignored)
+│       └── index.js              # What npm users actually run
+│
+docs/                             # Architecture documentation
+tests/                            # Test files
+drizzle/                          # Database migrations
+supabase/                         # Supabase configuration and seed data
+public/                           # Static assets
+```
+
+## Proxy (formerly middleware)
+
+- Next.js 16 uses `src/proxy.ts` instead of `middleware.ts`. Keep the exported handler named `proxy` and avoid multiple files—the Next codemod (`npx @next/codemod@canary middleware-to-proxy`) can help if a legacy `middleware.ts` still exists.
+- Treat the proxy as a last-resort HTTP boundary: read/modify requests, set headers, or do quick auth redirects, but don’t put feature logic there. Prefer App Router route handlers, rewrites, or server components for most behaviors.
+- Keep the proxy stateless and fast; because it runs for every matching request, avoid heavy computations and consolidate cross-cutting checks (auth guard, header tweaks) behind clear guards in `src/proxy.ts`.
+- Document any non-trivial proxy guard (why it exists, what routes it affects) in your feature’s ADR or docs so future maintainers understand why middleware couldn’t suffice.
+
+## Layer Contracts (Import Rules)
+
+- **app/** can import: `features/*`, `components/*`, `hooks`, `lib`, `config`
+- **features/\<name\>/components** can import: own `hooks`, `types`, `utils` + `components/ui`, `components/shared`, `lib`, `config`
+- **features/\<name\>/hooks** can import: own `api`, `types`, `utils` + `lib`
+- **features/\<name\>/api** can import: `lib`, own `types`/`utils` (no React)
+- **components/ui** can import: `lib`, `utils` (never `features/*`)
+- **components/shared** can import: `components/ui`, `lib`, `utils` (never `features/*`)
+- **server/** is server-only; never import from client components
+
+## Feature Module Anatomy
+
+Each feature follows this structure:
+
+```
+features/<feature>/
+├── api/                          # Network layer
+│   ├── get-<resource>.ts         # GET operations
+│   ├── create-<resource>.ts      # POST operations
+│   ├── update-<resource>.ts      # PUT/PATCH operations
+│   ├── delete-<resource>.ts      # DELETE operations
+│   ├── types.ts                  # DTO schemas (Zod)
+│   └── index.ts                  # Barrel export
+├── hooks/                        # React hooks
+│   ├── use-<resource>.ts         # Query hook
+│   ├── use-<resources>.ts        # List query hook
+│   ├── use-create-<resource>.ts  # Mutation hook
+│   └── index.ts                  # Barrel export
+├── components/                   # Presentational components
+│   ├── <feature>-list.tsx
+│   ├── <feature>-detail.tsx
+│   ├── <feature>-form.tsx
+│   └── index.ts                  # Barrel export
+├── screens/                      # Screen components (thin)
+│   ├── <feature>-screen.tsx      # Main screen
+│   └── index.ts                  # Barrel export
+├── types/                        # Domain types
+│   └── index.ts
+├── utils/                        # Feature utilities
+│   └── index.ts
+└── index.ts                      # Public API (barrel)
+```
+
+## RBAC & Plans
+
+- `config/roles.ts` declares the canonical roles referenced in `.ai/steering/product.md` (e.g., `PROJECT_EDITOR`, `TEAM_ADMIN`). Keep that file in sync with the product doc whenever plan limits or role names change.
+- `server/auth/rbac.ts` enforces those roles on the backend and should reference the same role/permission enums used by `features/auth/hooks/use-session.ts` and the guarding middleware(proxy) in `app/(protected)/layout.tsx`.
+- When a product role gains or loses permissions for a feature, update the adjacent `features/<feature>/components` screens (and tests) so the UI matches what the RBAC guard allows.
+- Configuration changes should centralize in `config/` so logic, UI copy, and enforcement all read from the same source of truth.
+
+## Naming Conventions
+
+- **Files**: kebab-case (`create-issue-dialog.tsx`, `use-issues.ts`)
+- **Components**: PascalCase (`CreateIssueDialog`)
+- **Hooks**: camelCase with `use` prefix (`useIssue`, `useIssues`)
+- **API functions**: verb-noun (`getIssues`, `createIssue`, `updateIssue`)
+- **Types**: PascalCase (`Issue`, `IssueStatus`, `IssuePermissions`)
+- **Constants**: UPPER_SNAKE_CASE (`ISSUE_WORKFLOW`, `PLANS`)
+
+## Page Structure (Thin Pages Pattern)
+
+Pages are thin route handlers that:
+1. Read `searchParams`, cookies, headers (server component)
+2. Perform auth/tenant gating
+3. Light Zod validation
+4. Render a single feature Screen with minimal props
+5. Own `loading.tsx`, `error.tsx`, `not-found.tsx`
+
+Example:
+```tsx
+// app/(protected)/issues/page.tsx
+import { IssuesListScreen } from '@/features/issues'
+
+export default function IssuesPage({ searchParams }) {
+  const teamId = cookies().get('team_id')?.value
+  if (!teamId) redirect('/select-team')
+  return <IssuesListScreen teamId={teamId} search={searchParams} />
+}
+```
+
+## Barrel Exports
+
+Each feature exposes its public API via `index.ts`:
+```ts
+// features/issues/index.ts
+export { IssueDetailsScreen } from './screens'
+export { IssuesList, IssuesCreateDialog } from './components'
+export { useIssues, useIssue, useCreateIssue } from './hooks'
+export type { Issue, IssueStatus, IssuePermissions } from './types'
+```
+
+## Mock Data Strategy
+
+- All mock data lives in `src/mocks/*`
+- Domain-based files (`team.fixtures.ts`, `issue.fixtures.ts`)
+- Used for visual UI development before backend implementation
+- Easy to swap with real API calls later
+
+## Mock Data Maintenance
+
+- Tie each fixture set to the feature that consumes it (e.g., `features/issues` imports from `src/mocks/issue.fixtures`) so you instinctively revise the fixture whenever the feature’s Zod DTOs or API responses change.
+- When a DTO schema in `features/<feature>/api/types.ts` is updated, add a checklist item to refresh the matching fixture file and scenario exports to keep UI mockups accurate.
+- Consider a lightweight lint/story checkpoint (e.g., a `vitest` smoke test or Storybook story that renders the fixtures) so stale mock data is caught before it drifts from real API surfaces.
+
+## Testing Structure
+
+- Unit/integration tests: Co-located with source files in `__tests__/` folders or as `*.test.ts(x)` files
+- E2E tests: `tests/e2e/*.spec.ts`
+- Test fixtures: `tests/e2e/helpers/test-fixtures.ts`
+- Property-based tests: Use `*.property.test.ts` naming convention
+- Mock data: `src/mocks/*.fixtures.ts`
+
+Example test locations:
+```
+src/
+├── lib/
+│   ├── __tests__/
+│   │   ├── auth-config.test.ts
+│   │   └── logger.property.test.ts
+│   └── auth-config.ts
+├── server/
+│   └── teams/
+│       ├── __tests__/
+│       │   ├── team-service.test.ts
+│       │   └── team-context.property.test.ts
+│       └── team-service.ts
+└── features/
+    └── issues/
+        └── components/
+            ├── issue-list.tsx
+            └── issue-list.test.tsx
+```
+
+## Documentation
+
+- Feature-level docs in `features/<feature>/docs/`
+- Architecture docs in `docs/`
+- See `AGENTS.md` for complete scaffolding guidelines

package/.ai/steering/tech.md

@@ -0,0 +1,188 @@
+# Tech Stack
+
+## Framework & Runtime
+
+- **Next.js 16** (App Router) - React framework with server-first routing
+- **React 19.2** - UI library
+- **TypeScript 5** - Type safety
+- **Node 20 LTS** - Runtime (see `.nvmrc`)
+- **Bun** - Package manager (preferred over npm/yarn)
+
+## UI & Styling
+
+- **shadcn/ui** - Component library built on Radix UI primitives
+- **Radix UI** - Headless accessible components
+- **Tailwind CSS 4** - Utility-first styling
+- **Framer Motion** (motion) - Animations
+- **Lucide React** + **Remix Icon** - Icon libraries
+- **next-themes** - Dark mode support
+
+## Data & State
+
+- **TanStack Query (React Query) 5** - Server state management, caching, mutations
+- **Zod** - Runtime validation and type inference
+- **SWR** - Alternative data fetching (used in some features)
+- **Supabase Realtime** - Real-time database updates via WebSockets
+
+## Forms & Validation
+
+- **React Hook Form** - Form state management
+- **@hookform/resolvers** - Zod integration for forms
+
+## Database
+
+- **PostgreSQL 15** - Primary database via Supabase
+- **Drizzle ORM** - Type-safe database queries and migrations
+- **Supabase CLI** - Local development environment (replaces docker-compose)
+- **Supabase** - PostgreSQL hosting, Auth, Storage, and additional services
+
+## Storage
+
+- **Cloudflare R2** - S3-compatible object storage for file uploads
+- **AWS SDK** - S3 client for R2 integration
+
+## Auth & Security
+
+- **better-auth** - Authentication library with session management
+- **@node-rs/argon2** - Password hashing
+- **ioredis** - Redis client for rate limiting and session storage
+
+## Email
+
+- **Resend** - Transactional email service
+- **React Email** - Email template components
+
+## Testing
+
+- **Vitest** - Unit and integration tests (with jsdom/happy-dom)
+- **@testing-library/react** - Component testing utilities
+- **Playwright** - E2E browser tests
+- **fast-check** - Property-based testing
+- **pg-mem** - In-memory PostgreSQL for testing
+
+### Testing Rules
+
+- **ALWAYS** use `bun run test` (or `vitest`) for unit tests
+- **NEVER** use `bun test` (Bun's native runner) - it ignores test config and can corrupt your local database
+- Tests use in-memory database by default (safe)
+- E2E tests (`bun run test:ui`) use local database
+
+## CLI Tooling (cli/ package)
+
+The `cli/` directory is a **standalone npm package** published separately from the Next.js app.
+
+- **tsup** - Bundles `cli/index.ts` and all imports into `cli/dist/index.js` (CJS, Node 20)
+- **commander** - CLI argument parsing. Listed as a runtime `dependency` (not bundled) because its dual ESM+CJS exports cause class-instance conflicts when bundled
+- All other CLI deps (`dotenv`, `postgres`, `zod`) are bundled — no runtime install needed
+
+**Key files:**
+- `cli/package.json` — npm package manifest; `"bin": { "ui-syncup": "dist/index.js" }`, `"files": ["dist", "templates"]`
+- `cli/tsup.config.ts` — `shims: true` (for `import.meta.url` → CJS), `external: ["commander"]`
+- `cli/.npmignore` — excludes TS source and `__tests__/` from the published tarball
+
+**Build & publish workflow:**
+```bash
+cd cli
+bun run build          # compiles → dist/index.js
+npm publish --dry-run  # preview tarball (auto-runs build via prepublishOnly)
+npm publish --access public
+```
+
+**Local testing:**
+```bash
+cd cli && npm link     # simulates global install
+ui-syncup --help
+npm unlink -g ui-syncup
+```
+
+**Template resolution after bundling:** `findTemplatePath()` in `cli/lib/filesystem.ts` checks `__dirname/../templates/` first (bundled layout) then falls back to the dev source layout.
+
+**Version resolution after bundling:** `getVersion()` in `cli/lib/constants.ts` searches candidate `package.json` paths ordered for the bundled layout (`dist/` → `../package.json`) before the dev layout.
+
+## Dev Tools
+
+- **ESLint 9** - Linting
+- **Prettier** - Code formatting
+- **TypeScript** - Type checking
+
+## Common Commands
+
+```bash
+# Development
+bun dev                 # Start dev server (http://localhost:3000)
+bun build              # Production build (Next.js app)
+bun start              # Start production server
+
+# Code Quality
+bun typecheck          # Run TypeScript compiler checks
+bun lint               # Run ESLint
+bun format             # Format code with Prettier
+
+# Testing (⚠️ Use 'bun run test', NOT 'bun test')
+bun run test           # Run unit tests (Vitest) - SAFE
+bun run test:watch     # Run tests in watch mode
+bun run test:ui        # Run E2E tests (Playwright)
+
+# Database
+bun run db:generate    # Generate Drizzle migrations
+bun run db:migrate     # Run migrations
+bun run db:studio      # Open Drizzle Studio
+bun run db:seed        # Seed database with test data
+
+# Supabase (Local Development - replaces docker-compose)
+bun run supabase:start # Start local Supabase stack (Postgres, Studio, Auth, Storage)
+bun run supabase:stop  # Stop local Supabase
+bun run supabase:status # Check Supabase status and get connection details
+
+# Validation
+bun run validate-env   # Validate environment variables
+```
+
+## CLI Commands (run from cli/ directory)
+
+```bash
+cd cli
+bun run build          # Compile CLI → dist/index.js via tsup
+npm publish --dry-run  # Preview npm tarball without publishing
+npm publish --access public  # Publish to npm registry
+npm link               # Install CLI globally for local testing
+```
+
+## Path Aliases
+
+- `@/*` maps to `./src/*` for absolute imports
+
+## Key Libraries
+
+- **class-variance-authority** - Component variant management
+- **clsx** + **tailwind-merge** - Conditional className utilities (via `cn()` helper)
+- **cmdk** - Command palette component
+- **date-fns** - Date utilities
+- **sonner** - Toast notifications
+- **uuid** - Unique ID generation
+
+## Environment Variables
+
+- Validated with Zod in `src/lib/env.ts` at build time
+- Local development: Copy `.env.example` to `.env.local`
+- Vercel deployment: Configure in Project Settings → Environment Variables
+- Run `bun run validate-env` to check configuration
+- See `docs/ENVIRONMENT_CONFIG.md` for detailed setup
+
+## Local Development
+
+- **Supabase CLI** is used for local development (not docker-compose)
+- Run `bun run supabase:start` to spin up local Postgres, Auth, Storage, Studio, and more
+- Supabase Studio available at http://127.0.0.1:54323 for database management
+- Local database runs on port 54322 (not 5432)
+- See `docs/SUPABASE_LOCAL_SETUP.md` for detailed setup instructions
+
+## Architecture Notes
+
+- Server components by default; use `"use client"` only when needed
+- API routes in `src/app/api/*` for backend endpoints
+- Mock data in `src/mocks/*` for development/testing
+- Feature-first organization in `src/features/*`
+- Prefer `lib/logger` and `lib/performance` when you add instrumentation or observability hooks so new pages stay consistent with the shared plumbing rather than introducing ad-hoc console/log statements
+- httpOnly cookies for session/token storage (never localStorage)
+- All network boundaries validated with Zod schemas

package/.claude/agents/database-architect.md

@@ -0,0 +1,96 @@
+---
+name: database-architect
+description: Use this agent when you need expert guidance on database administration, architecture decisions, performance optimization, high-availability setup, disaster recovery planning, query tuning, index strategies, replication configuration, backup solutions, monitoring setup, capacity planning, or troubleshooting database-related issues. Examples:\n\n<example>\nContext: User is designing a new application that requires a highly available database setup.\nuser: "I'm building a critical financial application that needs to handle 10,000 transactions per second with zero data loss. What database architecture should I use?"\nassistant: "Let me use the Task tool to launch the database-architect agent to provide expert guidance on the optimal high-availability architecture for your requirements."\n<commentary>\nThe user needs expert database architecture advice for a high-availability, high-transaction system. This matches the database-architect agent's core expertise in high-availability architectures and performance requirements.\n</commentary>\n</example>\n\n<example>\nContext: User has just written database migration scripts and schema changes.\nuser: "I've created these migration scripts for our user authentication tables"\nassistant: "Great! Now let me use the database-architect agent to review your migration scripts for performance implications, indexing strategies, and potential issues."\n<commentary>\nAfter database-related code is written, proactively launch the database-architect agent to review for performance optimization, proper indexing, transaction handling, and disaster recovery considerations.\n</commentary>\n</example>\n\n<example>\nContext: User mentions slow database queries in their application.\nuser: "Our application is experiencing slow response times and I think it might be database-related"\nassistant: "I'm going to use the Task tool to launch the database-architect agent to help diagnose and resolve the performance issues."\n<commentary>\nPerformance problems are a core concern for the database-architect agent. Launch it to provide systematic diagnosis and optimization recommendations.\n</commentary>\n</example>
+tools: Edit, Write, NotebookEdit, Bash, Glob, Grep, Read
+model: sonnet
+color: yellow
+---
+
+You are a senior database administrator with 15+ years of experience specializing in PostgreSQL and mastery across major database systems including MySQL, Oracle, SQL Server, MongoDB, and Redis. Your expertise encompasses the complete lifecycle of database systems with particular focus on high-availability architectures, performance optimization, and disaster recovery.
+
+## Core Competencies
+
+### High-Availability Architecture
+- Design and implement multi-region, multi-master replication topologies
+- Configure automatic failover mechanisms with sub-30-second recovery times
+- Architect solutions for 99.99%+ uptime requirements
+- Implement connection pooling, load balancing, and read replica strategies
+- Design zero-downtime deployment and upgrade procedures
+
+### Performance Optimization
+- Analyze and optimize queries to achieve sub-second response times
+- Design optimal indexing strategies (B-tree, GiST, GIN, BRIN, partial, covering)
+- Tune database parameters for specific workload characteristics
+- Implement query plan analysis and optimization workflows
+- Configure connection pooling and statement caching
+- Design efficient partitioning and sharding strategies
+- Optimize storage layouts and tablespace management
+
+### Disaster Recovery & Backup
+- Design comprehensive backup strategies (full, incremental, differential, continuous archiving)
+- Implement point-in-time recovery (PITR) solutions
+- Create and test disaster recovery runbooks with defined RTOs and RPOs
+- Design cross-region backup replication and verification
+- Implement automated backup testing and validation
+
+### Monitoring & Observability
+- Configure comprehensive monitoring for performance metrics, resource utilization, and health indicators
+- Design alerting strategies with appropriate thresholds and escalation paths
+- Implement query performance tracking and slow query logging
+- Set up proactive capacity planning and forecasting
+- Monitor replication lag, connection pools, and transaction rates
+
+## Operational Approach
+
+When addressing database challenges:
+
+1. **Gather Context**: Ask clarifying questions about current setup, workload characteristics, data volume, transaction patterns, and specific constraints
+
+2. **Analyze Systematically**: 
+   - Review current architecture and identify bottlenecks
+   - Examine query patterns and execution plans
+   - Assess resource utilization (CPU, memory, I/O, network)
+   - Evaluate configuration parameters against best practices
+
+3. **Provide Actionable Recommendations**:
+   - Prioritize solutions by impact and implementation complexity
+   - Include specific configuration values and parameter settings
+   - Provide complete code examples for queries, scripts, and configurations
+   - Explain the reasoning behind each recommendation
+   - Highlight potential risks and mitigation strategies
+
+4. **Think Long-Term**:
+   - Consider scalability implications of proposed solutions
+   - Factor in maintenance overhead and operational complexity
+   - Anticipate future growth and capacity requirements
+   - Design for observability and debuggability
+
+## Technical Guidelines
+
+- Always provide PostgreSQL-specific solutions first, then alternatives for other systems when relevant
+- Include version-specific considerations and compatibility notes
+- Reference official documentation and established best practices
+- Provide migration paths when recommending architectural changes
+- Include rollback procedures for risky operations
+- Consider security implications (encryption, access control, audit logging)
+- Balance performance with data integrity and consistency requirements
+
+## Quality Assurance
+
+Before finalizing recommendations:
+- Verify that solutions address root causes, not just symptoms
+- Ensure recommendations are production-ready and battle-tested
+- Confirm that monitoring and alerting cover the new solution
+- Validate that backup and recovery procedures remain effective
+- Check for potential race conditions, deadlocks, or edge cases
+
+## Communication Style
+
+- Be precise and technical while remaining accessible
+- Use concrete examples and specific metrics
+- Explain trade-offs clearly when multiple approaches exist
+- Warn about potential pitfalls and anti-patterns
+- Provide estimates for implementation time and expected impact
+- When uncertain about specific environment details, ask rather than assume
+
+Your ultimate goal is to deliver database solutions that are performant, reliable, maintainable, and aligned with industry best practices while meeting the specific requirements of each use case.