// WRONG - bypasses API layer
import { prisma } from '@/lib/prisma';
const employees = await prisma.employee.findMany(); // ❌

// CORRECT - use API
const response = await fetch('/api/v1/employees'); // ✅

primaryManagerId: string?        // 0..1 (direct manager)
dottedLineManagerIds: string[]   // 0..N (matrix reporting)
additionalManagerIds: string[]   // 0..N (secondary real managers)
teamIds: string[]                // 0..N (multi-team membership)
departmentIds: string[]          // 0..N (cross-department)
roleIds: string[]                // 0..N (multi-role)

// CTO with multiple responsibilities
CTO: {
  primaryManagerId: "ceo-id",
  dottedLineManagerIds: ["cfo-id"],
  roleIds: ["cto", "sales-manager"],
  teamIds: ["leadership", "sales"]
}

// Developer in multiple teams
Developer: {
  primaryManagerId: "dev-lead-id",
  additionalManagerIds: ["cto-id"],
  teamIds: ["saas", "web"],
  departmentIds: ["engineering", "product"]
}

# Project Context
Multi-tenant HRMS SaaS with flexible org structure.
- Next.js 15 (App Router) + NestJS 10 + PostgreSQL 17 + Prisma 5
- Shadcn/ui + Tailwind CSS
- Auth.js for authentication

## Architecture Principles
1. SIMPLICITY FIRST - No premature optimization
2. Single PostgreSQL with Row-Level Security
3. REST APIs only (no GraphQL)
4. Feature modules in NestJS

## ORG STRUCTURE RULES (CRITICAL)

### Model Split
- EmployeeCore = WHO (identity, job info, employment)
- EmployeeOrgRelations = HOW (managers, teams, departments, roles)

### Multi-Everything
- primaryManagerId: 0..1 (direct manager)
- dottedLineManagerIds: 0..N (matrix reporting)
- additionalManagerIds: 0..N (secondary real managers)
- teamIds: 0..N (multi-team membership)
- departmentIds: 0..N (cross-department)
- roleIds: 0..N (multi-role)

### Rules
- Every manager IS an employee (no separate Manager table)
- Self-management BLOCKED (employeeId !== managerId)
- Circular management ALLOWED by default (startup flexibility)
- No limits on any relations

## Code Style
- TypeScript strict (no `any`)
- Functional components with hooks
- Early returns for guards
- Descriptive names (no abbreviations)

## Database
- All tables have tenantId
- Always filter by tenantId
- Use Prisma transactions for multi-table ops
- Junction tables for many-to-many

## API Design
- REST with proper HTTP methods
- Consistent response shapes
- Pagination for lists

## Security
- Never trust client input
- Verify tenant context always
- Use isManagerOf() for permission checks
- Log security actions

## DO NOT
- GraphQL or event sourcing
- Separate microservices
- Abstractions without 3+ implementations
- Redux/MobX (use React Query)
- Separate Manager table
- Limit org relationships
- Block circular management by default

## COMMIT MESSAGE FORMAT (ENFORCED)
All commits MUST use conventional commits:
- Format: <type>: <description>
- Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
- feat = minor bump, fix/others = patch bump
- Add ! after type for breaking changes (major bump)

Good: feat: add employee dashboard
Bad: update stuff (CI rejects)

// CORRECT - Platform Admin endpoint pattern
@Controller('api/v1/admin/tenants')
@PlatformAdminOnly()
export class AdminTenantController { ... }

// WRONG - Missing guard
@Controller('api/v1/admin/tenants')
export class AdminTenantController { ... }

const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];
const MAX_SIZE = 5 * 1024 * 1024; // 5MB

<type>: <description>

feat!: redesign API endpoints

# Or use footer
feat: redesign API endpoints

BREAKING CHANGE: API endpoints have changed

# Correct
git commit -m "feat: add employee dashboard"
git commit -m "fix: resolve login timeout"
git commit -m "docs: update API guide"
git commit -m "refactor: simplify auth flow"

# Incorrect (CI will reject)
git commit -m "update stuff"         # Missing type
git commit -m "Feature: add login"   # Wrong case
git commit -m "feat add login"       # Missing colon
git commit -m "FEAT: add login"      # Uppercase type

## COMMIT MESSAGE FORMAT (ENFORCED)

All commits MUST use conventional commits format:
- Format: <type>: <description>
- Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
- feat = minor version bump, fix/others = patch version bump
- Add ! after type for breaking changes (major version bump)

Examples:
- feat: add employee dashboard
- fix: resolve login timeout
- docs: update deployment guide
- feat!: redesign authentication API

NEVER commit with messages like "update stuff" or "WIP" - CI will reject.

## DEPLOYMENT CHECKPOINT RULES (CRITICAL)

AI MUST pause and ask for human confirmation at these 4 gates:

1. CHECKPOINT 1: After commit, before push
   - Show diff, ask "OK to push?"
   - WAIT for "OK to push"

2. CHECKPOINT 2: After preview deploys
   - Show preview URL, ask "OK to merge?"
   - WAIT for "OK to merge"

3. CHECKPOINT 3: After staging deploys
   - Show staging URL, ask "OK to deploy production?"
   - WAIT for "OK to deploy"

4. CHECKPOINT 4: After production deploys
   - Show production URL, ask "Confirm complete?"
   - WAIT for "Complete"

NEVER proceed past a checkpoint without explicit human confirmation.
This is non-negotiable. Violations require session restart.

□ Is this edit required for the current step?
□ Is this edit explicitly requested?
□ Does this file appear in the current task specification?
□ Am I changing MORE than what the task requires?

If any checkbox fails → STOP and ASK