Operator Core

Un operador no 'usa' la IA desde una web: la opera desde su máquina, con acceso a sus archivos, su git y su terminal. Eso es Claude Code. Antes de instalarlo necesitas tres cimientos: una terminal donde corres comandos, un editor (VS Code) donde ves y editas el código, y un gestor de paquetes para instalar herramientas. En macOS la terminal es Terminal.app o iTerm2; en Windows usa WSL2 (Ubuntu) porque Claude Code y la mayoría de herramientas asumen un entorno tipo Unix. No intentes operar desde PowerShell puro: te va a costar el doble.

Primero comprueba qué tienes. Abre Terminal y ejecuta `node --version` y `git --version`. Si `node` no existe o es menor que v18, instala Node LTS. En macOS lo limpio es Homebrew: `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` y luego `brew install node git`. Tras instalar Homebrew, el instalador te imprime DOS líneas `eval "$(/opt/homebrew/bin/brew shellenv)"` que debes añadir a tu `~/.zprofile` — si las saltas, `brew` 'desaparece' al abrir una terminal nueva. Este es el primer fallo de PATH que vas a encontrar y conviene entenderlo: el PATH es la lista de carpetas donde el shell busca comandos; si la herramienta no está en una de ellas, el shell dice `command not found` aunque el archivo exista en el disco.

Instala Claude Code con `npm install -g @anthropic-ai/claude-code` y verifica con `claude --version`. Si npm se queja de permisos (`EACCES`) NO uses `sudo npm` — eso te deja archivos root que luego no puedes borrar. La solución correcta es apuntar npm a un prefijo en tu home: `npm config set prefix ~/.npm-global` y añadir `export PATH=~/.npm-global/bin:$PATH` a tu `~/.zshrc`. Recarga con `source ~/.zshrc`. Ahora `claude` arranca y te pide autenticarte con tu cuenta Anthropic vía navegador; ese token queda guardado y no lo vuelves a meter.

VS Code es tu ventana al código mientras Claude Code es tus manos. Instálalo desde code.visualstudio.com y, dentro, abre la paleta de comandos (Cmd+Shift+P) → 'Shell Command: Install code command in PATH'. Eso te da el comando `code .` para abrir la carpeta actual en VS Code desde la terminal — el gesto que harás cien veces al día. Instala al menos estas extensiones: la oficial de tu lenguaje, GitLens, y un formateador como Prettier. No infles el editor con 40 extensiones; cada una es superficie de ataque y ruido.

El flujo de trabajo real es siempre el mismo y lo vas a interiorizar este módulo. Abres una terminal, navegas a tu proyecto con `cd ~/mi-proyecto`, escribes `claude` para lanzar la sesión, y en otra pestaña (o panel dividido de VS Code) tienes el editor abierto con `code .`. Claude Code propone cambios, tú los revisas en el editor o con `git diff`, y los aceptas. La terminal y el editor no compiten: la terminal es donde ocurre la acción, el editor es donde verificas. En MOONKEY LAB, por ejemplo, una sesión típica es `cd ~/xop && claude` y pedirle que toque un componente Astro mientras tú miras el archivo en VS Code.

Verifica el entorno completo con una prueba de fuego antes de dar el módulo por cerrado. Crea una carpeta `mkdir ~/lab-01 && cd ~/lab-01`, inicializa git con `git init`, lanza `claude`, y pídele que cree un `hola.txt` con tu nombre. Sal de Claude, ejecuta `cat hola.txt` para confirmar que el archivo existe en disco, y `code .` para verlo en el editor. Si los cuatro pasos funcionan (terminal navega, claude arranca y escribe, el archivo aparece, VS Code lo abre) tu entorno está operativo. Documenta en una nota personal las versiones exactas que instalaste: cuando algo se rompa dentro de un mes, esa nota te ahorra una tarde.

CLAUDE.md es un archivo de texto en la raíz de tu proyecto que Claude Code lee automáticamente al arrancar cada sesión. No es documentación para humanos (aunque también sirve): es el contexto que la IA carga antes de hacer nada. Si tu `package.json` dice React pero tú usas Astro, o si tienes una regla de 'nunca añadas dependencias sin justificarlas', ese archivo es donde vive. La IA no adivina tu criterio; tú se lo escribes una vez y lo reutiliza para siempre.

El error del principiante es escribir un CLAUDE.md genérico ('este es un proyecto web, usa buenas prácticas'). Eso no aporta nada porque la IA ya asume buenas prácticas. El valor está en lo ESPECÍFICO y lo NO-OBVIO: qué stack REAL usas (no el que parece), qué tablas de tu base de datos son de otro proyecto y no debe tocar, qué patrón de i18n sigues, qué se traduce y qué no. Mira el CLAUDE.md real de MOONKEY LAB: tiene una sección '⚠️ La DB Supabase es COMPARTIDA con XHUB IRON' que lista las tablas prohibidas (`iron_*`, `world_*`) y las permitidas (`profiles, progress, feedback, leads, proofs`). Esa única línea evita que la IA borre datos de otro producto. Ese es el tipo de conocimiento que solo tú tienes y que el archivo captura.

Estructura un CLAUDE.md eficaz en secciones claras con encabezados Markdown. Las que importan: (1) Visión — una frase de qué es el proyecto. (2) Stack REAL — versiones y herramientas exactas, marcando dónde la realidad difiere de lo aparente. (3) Modelo de seguridad o de datos — quién puede tocar qué. (4) Convenciones — nombres, estructura de carpetas, tipografía, lo que sea que tenga reglas. (5) Tono — cómo debe sonar el texto que genere. (6) Reglas de coste — qué NO hacer. En MOONKEY esa última sección dice literalmente 'No añadir dependencias sin justificación. No JS donde basta HTML/CSS.' — prohibiciones concretas, no consejos vagos.

La regla de oro es: cada línea de CLAUDE.md debe cambiar una decisión. Si una frase no altera lo que la IA haría por defecto, sóbrala. 'Escribe código limpio' no cambia nada. 'Hrefs deben ser locale-aware: usa localizedPath(/ruta, locale), nunca /ruta crudo (rompe bajo prefijo de idioma)' cambia cada link que genere. Lo segundo es oro; lo primero es relleno. Un CLAUDE.md de 80 líneas densas vale más que uno de 300 líneas de obviedades, y consume menos contexto en cada sesión.

CLAUDE.md es un documento vivo, no un acto fundacional. Cada vez que la IA hace algo mal de forma sistemática — añade una dependencia que no querías, usa el patrón de i18n equivocado, traduce un término de marca que no se traduce — ese es un fallo del archivo, no de la IA. Vuelve y añade la regla. Con el tiempo el archivo se convierte en el destilado de todas las correcciones que has hecho. En la práctica, una buena sesión termina con 'añade esto a CLAUDE.md para que no vuelva a pasar'. Mantén también las cosas de tu máquina y preferencias personales fuera del CLAUDE.md del repo (eso va en memoria de usuario o en un CLAUDE.local.md no versionado): el del repo lo comparte el equipo.

Para escribirlo, no partas de una plantilla en blanco. Ejecuta `claude` en tu proyecto y pídele: 'Recorre la estructura del repo, lee package.json y los archivos de config, y propón un borrador de CLAUDE.md que capture el stack real y las convenciones que detectes.' La IA es buenísima leyendo tu propio código y resumiéndolo. Luego TÚ corriges: añades las prohibiciones que ella no puede saber (las tablas de otro proyecto, los términos que no se traducen, las decisiones de negocio) y borras lo genérico. Ese ciclo — la IA propone desde el código, tú inyectas el conocimiento que solo está en tu cabeza — produce un archivo honesto en veinte minutos.

Un prompt no es una pregunta: es una instrucción de trabajo. Cuando le pides a un compañero competente que haga algo, no dices 'arregla el login'; dices 'el magic-link de Supabase no redirige tras autenticar, revisa el callback en src/lib/supabase.ts, el problema es probablemente la URL de redirect en la config'. Le das rol implícito, contexto, foco y una hipótesis. Un buen prompt hace lo mismo de forma explícita. Los cuatro pilares son: ROL (quién debe ser la IA: 'eres un ingeniero de Postgres revisando RLS'), CONTEXTO (qué necesita saber: el stack, el archivo, la restricción), ESTRUCTURA (cómo quieres la salida: 'devuelve solo el SQL, sin explicación' o 'lista 3 opciones con trade-offs'), e INTENCIÓN (el objetivo real detrás de la petición, no solo el paso).

El ROL no es teatro: cambia qué conocimiento activa la IA y qué estándar aplica. 'Revisa este código' produce una revisión blanda. 'Eres un auditor de seguridad adversarial: tu trabajo es refutar la afirmación de que esta RLS es segura, busca el camino de escalación' produce un análisis completamente distinto, porque le has dado una postura. En XCAP, los prompts de research llevan el rol de 'analista que no se miente a sí mismo' precisamente porque el sesgo por defecto de un modelo es complacer; el rol lo contrarresta.

La ESTRUCTURA de salida es lo que más tiempo te ahorra y lo que más se olvida. Si no especificas el formato, la IA elige uno y suele ser prosa larga que tienes que recortar. Di exactamente qué quieres: 'Devuelve un único bloque de SQL listo para pegar, sin comentarios ni explicación.' O 'Responde con una tabla de tres columnas: opción, ventaja, riesgo.' O 'Dame el diff, no el archivo completo.' En MOONKEY, donde el tono es 'claro, directo, sin humo ni emojis', un prompt de generación de copy incluye esa restricción de formato textualmente, porque si no la IA mete adornos que luego borras a mano.

La INTENCIÓN es el porqué, y desbloquea soluciones que no pediste. Si dices 'añade un índice a esta columna', la IA lo añade. Si dices 'esta query tarda 2 segundos en la página de cuenta y quiero bajarla de 200ms; el índice es mi primera idea pero abre a alternativas', puede que te diga que el problema real es un N+1 y el índice no ayuda. Cuando das la intención, la IA puede cuestionar tu solución propuesta y ofrecer una mejor. Cuando solo das la orden, ejecuta a ciegas.

Un arsenal es una colección versionada de estos prompts, organizada por tarea, que reutilizas. No empieces de cero cada vez: ten un prompt de 'auditoría de seguridad de RLS', uno de 'genera copy en la voz de la marca', uno de 'refactoriza este componente preservando comportamiento', uno de 'escribe el mensaje de commit a partir del diff'. Guárdalos en un archivo `prompts.md` en tu proyecto o en una nota. MOONKEY LAB tiene una página entera, `/prompts`, dedicada a esto, porque un arsenal es un activo: cada prompt afinado es trabajo que no repites. Parametriza los prompts con huecos `[ARCHIVO]`, `[RESTRICCIÓN]` que rellenas al usarlos.

Itera el prompt, no la salida. Cuando un resultado sale mal, el reflejo del principiante es corregir la respuesta a mano. El reflejo del operador es preguntarse 'qué le faltó saber al prompt' y arreglar el prompt. Si la IA usó tabs y tú quieres espacios, no edites el archivo: añade 'indentación con 2 espacios' al prompt y guárdalo así para siempre. Cada corrección que metes en la plantilla es una corrección que no vuelves a hacer. Con el tiempo tus prompts del arsenal se vuelven quirúrgicos y los resultados salen bien a la primera — que es el objetivo: dejar de iterar.

Git resuelve un solo problema, pero es el más importante: poder volver a cualquier estado anterior de tu proyecto. Cada vez que haces un `commit`, congelas una foto del proyecto a la que siempre puedes regresar. Esto cambia tu psicología de trabajo: cuando sabes que el último estado bueno está guardado, dejas a la IA hacer cambios agresivos sin miedo, porque lo peor que pasa es `git restore` y vuelves atrás. Un operador sin Git trabaja con miedo; con Git, trabaja rápido. El flujo mínimo es: `git status` para ver qué cambió, `git add -p` para revisar y elegir cambios trozo a trozo, `git commit -m 'mensaje'` para congelar, y `git log --oneline` para ver tu historia.

El ciclo diario es ver-revisar-congelar. Tras una sesión de Claude Code, NUNCA confíes en que el cambio es correcto: ejecuta `git diff` y lee exactamente qué tocó. Aquí descubres si la IA cambió algo que no debía, borró una línea sin querer o añadió una dependencia. `git diff` es tu herramienta de revisión número uno y la usas en cada sesión. Solo cuando el diff te convence, haces `git add` y `git commit`. Este hábito —leer el diff antes de aceptar— es lo que separa a un operador de alguien que copia y pega a ciegas.

Los commits deben ser atómicos: un commit, un cambio lógico, con un mensaje que explique el PORQUÉ, no el qué. 'Arregla el login' es malo (¿qué tenía?). 'Corrige redirect de magic-link: la URL de callback no incluía el locale y rompía bajo /en/' es bueno: dentro de seis meses, ese mensaje te dice por qué tocaste ese archivo. Claude Code es excelente escribiendo mensajes de commit a partir del diff — pídele 'escribe un mensaje de commit para estos cambios explicando el porqué' y suele clavarlo. Pero revisa: a veces describe el qué y tienes que pedirle el porqué.

Las ramas (`branches`) son universos paralelos para experimentar sin tocar lo que funciona. La rama principal (`main`) es tu versión estable. Cuando vas a probar algo arriesgado —una refactorización grande, una feature nueva— creas una rama con `git checkout -b mi-experimento`, trabajas ahí, y si sale bien la fusionas; si sale mal, la borras y `main` ni se entera. Regla práctica de operador: nunca trabajes directamente en `main` para cambios no triviales. Crea una rama. En MOONKEY LAB cada cambio de seguridad o de RLS va en su rama y se fusiona solo cuando `get_advisors` da luz verde.

GitHub es Git en la nube: tu copia de seguridad remota y el sitio desde donde se despliega tu proyecto. Conectas tu repo local con `git remote add origin git@github.com:usuario/repo.git` y subes con `git push`. A partir de ahí, `git push` tras cada sesión buena guarda tu trabajo fuera de tu máquina — si tu disco muere, tu proyecto vive. Además, plataformas como Cloudflare Pages (que despliega MOONKEY LAB desde `garciafradepablo-pixel/xop`) observan tu repo de GitHub y publican automáticamente cada push a `main`. Así Git no es solo versionado: es el motor de tu deploy, que verás en el siguiente módulo. Para hablar con GitHub desde la terminal, instala el CLI `gh` y autentícate con `gh auth login`.

Un `.gitignore` es tan importante como los commits: lista los archivos que Git debe IGNORAR. Aquí van `node_modules/` (se reinstala desde package.json, no se versiona), archivos `.env` (secretos — NUNCA subas claves a GitHub), y artefactos de build. Subir un `.env` con una clave a un repo público es uno de los incidentes de seguridad más comunes del mundo, y una vez subida la clave, aunque borres el commit, queda en la historia: hay que rotarla. Por eso el `.gitignore` se configura ANTES del primer commit. Pídele a Claude Code 'genera un .gitignore para un proyecto Astro con Supabase' y revisa que incluye `.env` y `node_modules`.

La automatización empieza en lo pequeño: un comando que repites se convierte en un script. Si cada vez que terminas escribes `npm run build && git add -A && git commit -m wip && git push`, eso es un script `deploy.sh` de cuatro líneas que ejecutas con `./deploy.sh`. El principio es: lo que haces más de tres veces, lo guardas. Pide a Claude Code 'crea un script bash que haga build, commit con timestamp y push, y que aborte si el build falla' — el `&&` entre comandos ya garantiza que si uno falla, los siguientes no corren, que es exactamente lo que quieres en un deploy.

El deploy moderno de un sitio estático es casi gratis de montar y se llama deploy continuo. Plataformas como Cloudflare Pages observan tu repo de GitHub: cada vez que haces `git push` a `main`, ellos clonan tu repo, ejecutan tu comando de build (`npm run build` para Astro), y publican el resultado en una URL real. MOONKEY LAB funciona exactamente así: `git push` al repo `garciafradepablo-pixel/xop` y unos segundos después los cambios están en `moonkeylab.pages.dev`. No subes archivos por FTP, no tocas un servidor: tu único gesto de deploy es `git push`. Esto une el módulo de Git con este: Git no solo versiona, es el gatillo del deploy.

Configurar el deploy continuo es un proceso de una sola vez. Conectas tu cuenta de Cloudflare (o Vercel, o Netlify) a GitHub, eliges el repo, y declaras dos cosas: el comando de build (`npm run build`) y la carpeta de salida (`dist` en Astro). Cloudflare guarda esa config y a partir de ahí cada push dispara un build. Si el build falla, NO publica — tu sitio anterior sigue vivo. Esa es una propiedad de seguridad enorme: un commit roto no tira tu sitio, simplemente no se despliega y te avisa. Verás el log del build en el panel de Cloudflare; cuando algo falla en deploy pero funciona en local, ese log es lo primero que lees.

Las variables de entorno son el puente entre tu deploy y tus secretos, y aquí se cruza con seguridad. Tu código necesita la URL de Supabase y la anon key, pero esas NO van hardcodeadas en el repo (lo viste en el módulo de Git). En local viven en un `.env`; en el deploy las metes en el panel de Cloudflare como variables de entorno, y la plataforma las inyecta en el build. Distinción crítica que aprenderás a fondo en Ops & Security: la anon key de Supabase SÍ puede vivir en el cliente (está protegida por RLS), pero una service-role key JAMÁS — esa daría acceso total saltándose toda la seguridad. Saber qué clave va dónde es competencia de operador.

El siguiente nivel es automatizar tareas recurrentes que no dependen de un push: cosas que deben correr según un horario. Esto son tareas programadas (cron). En XCAP, por ejemplo, hay 'autopilot ticks' — bucles que corren periódicamente para ingerir datos de mercado y actualizar el ledger de Market Memory sin que nadie pulse un botón. La idea general: defines un comando y un horario ('cada día a las 6:00', 'cada 15 minutos'), y la plataforma lo ejecuta sola. Para un sitio estático esto suele vivir en funciones serverless (Cloudflare Workers) o en cron jobs. La clave de operador es que el bucle sea honesto e idempotente: que correr dos veces no duplique datos, y que acumule aprendizaje en vez de ruido — exactamente la disciplina del 'capital invariant' de XCAP, donde el estado solo cambia en eventos reales, no en cada tick.

Automatizar sin observabilidad es peligroso: un sistema que corre solo y falla en silencio es peor que uno manual. Por cada automatización, ten una forma de saber si funcionó. El build de Cloudflare te manda un email si falla. Una tarea cron debe loguear su resultado en algún sitio que tú revises. La regla: nunca automatices algo que no puedas verificar después. Empieza siempre por una versión que corre y te avisa, y solo cuando confías en ella la dejas correr de verdad sola. Un deploy automático sin revisar el log la primera vez es cómo se publica un sitio roto a producción sin enterarte.

La diferencia fundamental no es de modelo, es de paradigma. ChatGPT es una conversación: tú escribes, la IA responde texto, y tú copias ese texto a tu proyecto a mano. El contexto vive en el hilo, y cuando el hilo crece demasiado o lo cierras, ese contexto se evapora. Claude Code es un operador: vive en tu terminal, lee y escribe tus archivos directamente, ejecuta comandos, hace commits. El contexto no vive en una conversación efímera — vive en CLAUDE.md y en tu repo, que son permanentes y versionados. Migrar es mover tu conocimiento de un sitio que se borra a uno que persiste.

Empieza por auditar qué contexto valioso tienes atrapado en ChatGPT. Probablemente hay hilos donde definiste el stack de un proyecto, decisiones de arquitectura, convenciones de estilo, prompts que te funcionaron bien. Todo eso es activo que ahora mismo solo existe en hilos. El primer paso de la migración es extraerlo: recorre tus conversaciones importantes y saca las decisiones duraderas (no el chat completo, las conclusiones). 'Usamos Astro, no React, por X', 'el tono es directo sin emojis', 'la DB la comparto con otro proyecto y estas tablas son intocables'. Eso es exactamente el material de un CLAUDE.md.

El corazón de la migración es construir el CLAUDE.md a partir de ese contexto extraído. Lo que en ChatGPT tenías que repetir al inicio de cada hilo ('recuerda que uso Astro y Supabase y el tono es...'), en Claude Code lo escribes una vez en CLAUDE.md y se carga solo en cada sesión, para siempre. Esto conecta directamente con el módulo OC-02: la migración no es más que volcar el contexto disperso de tus hilos en el archivo de memoria persistente. Un buen ejercicio es pedirle a ChatGPT mismo: 'resume todas las decisiones técnicas y convenciones de este hilo en formato de bullets para un archivo de contexto' — y usar esa salida como borrador.

Cambia también tu forma de pedir las cosas. En ChatGPT pides 'escríbeme el código para X' y recibes un bloque que pegas. En Claude Code pides 'crea el archivo src/lib/x.ts que haga X, siguiendo las convenciones de CLAUDE.md, y enséñame el diff' — la IA crea el archivo en su sitio, tú revisas el diff con git, y haces commit. El gesto de copiar-y-pegar desaparece. Esto requiere desaprender un hábito: dejar de tratar a la IA como un generador de texto y empezar a tratarla como un colaborador que actúa sobre tu proyecto. Al principio cuesta confiar en que tocará los archivos correctos; por eso `git diff` y los commits del módulo OC-04 son tu red de seguridad.

Migrar bien significa montar el sistema completo, no solo cambiar de herramienta. El sistema de un operador es: un repo con git, un CLAUDE.md con el contexto, un .gitignore protegiendo secretos, un arsenal de prompts en un prompts.md, y el deploy continuo conectado. Cuando tienes esos cinco elementos, has dejado de 'usar una IA' y has montado una operación. Cada uno de los módulos anteriores de Operator Core era una pieza; este módulo las ensambla migrando un proyecto real desde el caos de hilos de ChatGPT hasta ese sistema documentado. El resultado es que cualquier sesión nueva — tuya o de un colaborador — arranca con todo el contexto cargado.

El valor que sentirás de inmediato es la continuidad. En ChatGPT, retomar un proyecto tras una semana significa releer hilos y recordar dónde estabas. En el sistema migrado, abres la terminal, `cd` al proyecto, `claude`, y la IA ya sabe el stack, las convenciones y las prohibiciones porque están en CLAUDE.md; tú ves dónde estabas en `git log`. El proyecto se documenta a sí mismo. Esa continuidad es lo que permite operar muchos proyectos a la vez sin que se mezclen — como hace falta cuando llevas XNLAB, XHUB, XCAP, Espejo y esta escuela en paralelo: cada uno con su CLAUDE.md, su repo y su contexto aislado, todos operados con el mismo flujo.

Verificación NO es testing automatizado, y NO es solo de seguridad. Es la disciplina general de probar que un cambio se comporta como esperas ANTES de publicarlo. Tiene cuatro niveles que se aplican en orden y casi nunca necesitas los cuatro: (1) ¿compila / arranca sin error? (2) ¿el diff dice lo que creías pedir? (3) ¿el comportamiento observable cambió como esperabas? (4) ¿rompiste algo que antes funcionaba (regresión)?

El nivel barato y obligatorio: LEER EL DIFF. Antes de aceptar nada, `git diff` (o el panel de diff del editor). Claude Code es excelente describiendo lo que hizo y mediocre delatando lo que hizo de más: un archivo que no pediste tocar, un `console.log` olvidado, una dependencia añadida, un bloque borrado "de paso". Si el diff toca más de lo que tu frase pedía, eso es una señal, no una casualidad. Regla: nunca aceptes un cambio cuyo diff no entiendes línea por línea.

"Parece que funciona" es una mentira cómoda con tres caras. Cara 1: arrancó sin error → confundes 'no crashea' con 'hace lo correcto'. Cara 2: lo probé una vez con el caso feliz → no probaste el input vacío, el duplicado, el usuario sin permiso. Cara 3: la IA me dijo que lo verificó → la IA no ejecutó nada, predijo texto. El antídoto es siempre el mismo: observar el comportamiento real con tus propios ojos, no aceptar el reporte de quien hizo el cambio (ni humano ni IA).

Smoke test = el camino más corto que demuestra que la pieza central respira. No es cobertura total; es el 20% de pruebas que atrapan el 80% de los desastres. Para una web: levanta `npm run dev`, abre la ruta que tocaste, haz la acción principal, mira que pasa lo esperado. Para un script: córrelo con un input conocido y compara la salida con lo que SABES que debe dar. Defines el smoke test ANTES de pedir el cambio, no después, para no engañarte ajustando la prueba al resultado.

Aserción sobre observación: no mires la pantalla buscando confirmación, define de antemano la afirmación falsable. Mal: "a ver si carga bien". Bien: "al enviar el formulario sin email, debe aparecer el error 'email requerido' y NO debe insertarse fila en `leads`". Una buena verificación se puede escribir como una frase que sería claramente falsa si el cambio falló. Si no puedes escribir esa frase, no sabes qué estás verificando.

Regresión: el cambio nuevo a menudo rompe lo viejo. La pregunta que separa al senior del junior no es "¿mi feature funciona?" sino "¿qué funcionaba antes que mi cambio pudo haber roto?". En esta escuela, tocar `galaxy.ts` puede romper el mapa SVG y todas las páginas de constelación, porque se generan del mismo archivo. Antes de publicar, lista mentalmente qué OTRAS cosas dependen de lo que tocaste y comprueba al menos una.

Cómo usar a Claude Code COMO verificador, sin delegarle el juicio: pídele que ejecute el comando real (`npm run build`, el test, el script) y te pegue la SALIDA cruda, no su resumen. "Corre el build y pégame la salida completa" es verificable; "¿funciona el build?" invita a la alucinación complaciente. La IA verifica ejecutando y mostrando evidencia; tú verificas leyendo esa evidencia. Nunca al revés.

Verificación proporcional al riesgo (no toda verificación cuesta lo mismo). Cambiar un texto de copy: leer el diff basta. Tocar RLS, un trigger de Postgres o el flujo de pago: build + smoke + regresión + revisar advisors. El operador maduro calibra el esfuerzo de verificación al coste de equivocarse, no verifica todo igual ni confía en todo igual.

Las señales de degradación de contexto, en orden de aparición: (1) la IA te vuelve a preguntar algo que ya respondiste; (2) re-implementa código que ya existía o deshace un cambio acordado; (3) sus respuestas se vuelven genéricas, pierden los nombres concretos de tu proyecto; (4) edita el archivo equivocado o inventa rutas. En cuanto veas la señal 1-2, estás en la zona roja. No esperes a la señal 4: ahí ya estás limpiando un destrozo, no avanzando.

La intuición correcta es contraintuitiva: cuando la sesión se descarría, parar y reiniciar es MÁS RÁPIDO que insistir. Pelear contra un contexto saturado es interés compuesto negativo: cada turno añade ruido al ruido. La pregunta no es "¿cómo le explico mejor?" sino "¿este contexto todavía me ayuda o ya me estorba?". Si estorba, el arreglo no es un prompt mejor, es un contexto nuevo.

El handoff: cómo reiniciar SIN perder estado. Antes de cerrar una sesión derailada, pide el resumen de traspaso: "Resume en un bloque qué intentábamos, qué decisiones tomamos, qué archivos tocamos, qué quedó pendiente y cuál es el siguiente paso concreto". Ese bloque es tu estado portátil. Sesión nueva → pegas el resumen → Claude Code arranca con contexto fresco y memoria de lo importante, sin arrastrar el ruido. El handoff convierte un reinicio de pérdida total en un reinicio de costo casi cero.

Tu memoria persistente vive en disco, no en la ventana. Lo que de verdad importa no debe vivir solo en el chat: vive en `CLAUDE.md` (decisiones de proyecto, convenciones, qué NO tocar) y en archivos de notas del repo. Una sesión nueva que lee tu `CLAUDE.md` ya sabe lo esencial. Regla: si una decisión la vas a necesitar mañana, no la dejes en el chat — escríbela en `CLAUDE.md`. La ventana de contexto es RAM volátil; el repo es tu disco.

Prevención: sesiones cortas y de foco único superan a la maratón. Una sesión = un objetivo acotado. "Arregla la verificación de RLS" es buena sesión; "refactoriza todo el backend" es una maratón que se va a degradar a mitad. Cuando una tarea es grande, la partes en sesiones independientes con handoff entre ellas, no la metes entera en una ventana que no aguanta.

Delegación a subagentes: paralelismo y aislamiento de contexto. Un subagente es una sesión hija con su PROPIA ventana de contexto, a la que le das una tarea acotada y un entregable definido. Dos ganancias: (1) trabajo paralelo — un subagente audita seguridad mientras otro escribe tests; (2) aislamiento — el subagente quema su contexto investigando un archivo enorme y te devuelve solo el resumen, sin contaminar tu sesión principal. Delegas lo que es voluminoso de explorar pero compacto de reportar.

Cómo escribir un buen encargo de subagente: como si el subagente no tuviera memoria de tu conversación — porque no la tiene. Rutas absolutas, contexto autocontenido, y un entregable explícito ("devuélveme X"). Un encargo vago a un subagente es peor que no delegar: gastas una ventana entera para recibir basura genérica. El subagente brilla en tareas con frontera clara, no en "ayúdame con esto".

Recuperar el hilo cuando Claude Code se pierde a media tarea: no sigas empujando. Para, pídele que te diga con SUS palabras qué cree que está haciendo y por qué. Si su versión no coincide con la tuya, ahí está la deriva — corrígela explícitamente o haz handoff a sesión limpia. La peor opción es la del novato: dar más instrucciones encima de un modelo que ya entendió mal, apilando correcciones sobre un malentendido de base.