CLAUDE.md: adaptar sesiones a Windows/Fedora y preferencias de enseñanza

Las preferencias (pasos pequeños, pistas por niveles, chuleta) pasan a
CLAUDE.md para que estén en las dos máquinas. PROGRESO.md tiene ahora una
sección de pendientes por máquina.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -21,13 +21,38 @@ pregúntame marca y modelo de cada una.
 
 # Entorno
 
-- Windows: MSYS2, entorno UCRT64, con GCC, gdb y make
-- Fedora en WSL: para compilar y probar la parte portable con
-  AddressSanitizer, UBSan y valgrind (en Windows con MinGW no funcionan)
+Trabajo en dos máquinas y voy cambiando de una a otra. Las sincronizo con git.
+
+- **Sobremesa: Windows** con MSYS2, entorno UCRT64, con GCC, gdb y make.
+- **Portátil: Fedora** nativo, con gcc, clang, gdb, make y valgrind. Aquí se
+  prueba la parte portable con AddressSanitizer, UBSan y valgrind, que no
+  funcionan en Windows con MinGW.
 - Estándar: C17
-- Flags: -std=c17 -Wall -Wextra -Wpedantic -g
+- Flags: -std=c17 -Werror -Wall -Wextra -Wpedantic -g
 - Makefile único que funcione en Windows (MSYS2) y en Linux
 
+# Adaptar la sesión a la máquina
+
+Al empezar cada sesión, antes de proponer nada:
+
+1. Detecta en qué máquina estoy: la plataforma del entorno (`win32` es el
+   sobremesa con Windows y `linux` el portátil con Fedora) o `uname -s`.
+2. Lee PROGRESO.md, incluida la sección "Pendiente por máquina".
+3. Dime en una línea en qué máquina estoy y qué toca, sin preguntarme.
+   - Si el paso actual se puede hacer en esta máquina, sigue con él.
+   - Si necesita la otra (por ejemplo, valgrind en Windows o Winsock en
+     Fedora), dímelo, déjalo apuntado en "Pendiente por máquina" y proponme
+     algo que sí se pueda hacer aquí.
+4. Usa los comandos de esta máquina en enunciados y comprobaciones (por
+   ejemplo, `build/hello.exe` y las rutas de MSYS2 en Windows).
+
+Qué encaja mejor en cada una:
+
+- Windows: lo específico de Windows (Makefile con `.exe`, Winsock, spooler,
+  WinUSB) y la parte portable sin comprobación de memoria.
+- Fedora: validar la parte portable con valgrind y sanitizers (obligatorio
+  antes de cerrar una fase), sockets POSIX y USB en Linux.
+
 # Arquitectura a construir
 
 - Núcleo portable: buffer de bytes, constructor de comandos ESC/POS,
@@ -82,6 +107,14 @@ pregúntame marca y modelo de cada una.
   pase AddressSanitizer y valgrind en Fedora.
 - Antes de imprimir en papel, comprobamos los bytes en un .bin con un
   volcado hexadecimal, para no gastar papel en pruebas fallidas.
+- Pasos pequeños: me saturo con enunciados largos. Una tarea corta cada vez
+  y teoría larga en `docs/`, no en el chat.
+- Nada de *vibecoding*. En cada paso de código dame solo el enunciado (qué
+  hace y cómo se comprueba) y pídeme una predicción antes de compilar. Sin
+  pseudocódigo, esqueletos ni líneas exactas. Si me atasco y pido ayuda,
+  sube poco a poco: la pista 1 dice dónde mirar, la 2 es más concreta y la
+  solución solo si la pido. Ante un error, pídeme primero mi diagnóstico.
+  No corrijas mi código salvo que te lo pida.
 
 # Seguimiento
 
@@ -95,6 +128,9 @@ con un índice en `docs/README.md`. Cada vez que explique un concepto nuevo,
 añádelo al fichero del tema que corresponda o crea uno nuevo y enlázalo en el
 índice. Incluye siempre la comparación con Go.
 
+Mantén `docs/cheatsheet.md` con cada comando nuevo que use, en el momento en
+que aparece, agrupado y con una línea que explique qué hace.
+
 # Comunicación
 
 - En español