# Onboarding Dev — Fundamental Skill

Skill para integrar nuevos developers al studio y sus ventures. Entregar al nuevo dev el día 1.

---

## Setup del entorno

### Prerrequisitos
- Node.js ≥ 20 LTS → `node --version`
- Git ≥ 2.40 → `git --version`
- Docker ≥ 24 → `docker --version`
- PNPM ≥ 9 → `pnpm --version`
- VS Code (última stable)
- GitHub CLI ≥ 2.40 → `gh --version`

### Pasos
1. Clonar repos: `git clone git@github.com:fundamental-lat/api.git`
2. Instalar dependencias: `pnpm install`
3. Configurar .env: `cp .env.example .env` (pedir .env de desarrollo al lead)
4. Levantar servicios: `docker compose up -d` → `pnpm dev` (API :3000, Web :5173)
5. Correr migrations y seeds: `pnpm db:migrate && pnpm db:seed`

### Verificación
- API responde en localhost:3000/health → 200 OK
- Frontend carga sin errores en consola
- `pnpm test` → todos verdes
- `pnpm lint` → 0 errors, 0 warnings

---

## Arquitectura del sistema

- **Frontend**: Astro + React. SSG con islas interactivas.
- **API**: Node.js + Fastify. REST /api/v1. JWT auth. Zod validation. Patrón repository.
- **Database**: PostgreSQL 16. Migrations con Drizzle ORM. Nunca SQL raw.
- **Cache**: Redis. Session store y cache de queries. TTLs por tipo de dato.
- **Queue**: BullMQ + Redis. Jobs asíncronos: emails, webhooks. Retry con backoff.
- **Infra**: Docker + Fly.io. CI/CD con GitHub Actions.

### Decisiones clave
- Fastify sobre Express: más rápido, schema validation nativo, mejor TypeScript
- Astro sobre Next.js: 0KB JS por defecto, ideal para contenido estático
- Drizzle sobre Prisma: más liviano, migraciones SQL legibles
- PNPM sobre NPM: instalación más rápida, node_modules estricto

---

## Primer PR — paso a paso

1. Agarrá un ticket con label `good first issue`
2. Creá branch: `git checkout -b feat/mi-primer-feature`
3. Escribí código (empezá por tests si aplica)
4. `pnpm test && pnpm lint` — arreglá antes de pushear
5. Commiteá con Conventional Commits: `git add -p`
6. Abrí PR con template completo
7. Respondé al review — cada comentario es aprendizaje
8. Squash and merge (default)
9. Verificá en staging, cerrá el issue

### Errores comunes
- ❌ Pushear sin correr tests → ✅ `pnpm test` siempre antes
- ❌ PR con 40 archivos y 3 features → ✅ dividir en PRs chicos
- ❌ No leer .env.example completo → ✅ leerlo entero
- ❌ Commitear node_modules o .env → ✅ revisar .gitignore
- ❌ 3 días sin pushear ni preguntar → ✅ push de WIP al final del día

---

## People & Links

### A quién preguntar qué
- Tech Lead: Arquitectura, decisiones técnicas, code review bloqueante
- Frontend Lead: Componentes, diseño, accesibilidad, performance
- Backend Lead: Endpoints, DB, queues, workers
- DevOps: CI/CD, staging, Docker, secrets, dominios
- Product Owner: Requerimientos, prioridad, criterios de aceptación
- Design: Figma, componentes de diseño, flujos de usuario
- QA: Casos de prueba, datos de test, bugs en staging

### Canales
- #dev (Slack): Dudas técnicas, código, bugs, PRs
- #general (Slack): Anuncios, demos, planning
- #alerts (Slack): Incidentes en producción
- Daily 9:30 AM (Google Meet): Qué hice, qué voy a hacer, qué me bloquea
- Sprint Planning: Lunes cada 2 semanas
- Retro: Viernes fin de sprint