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>
This commit is contained in:
2026-10-05 21:47:52 +02:00
parent 6212fc971f
commit 03d2ece7d6
2 changed files with 60 additions and 21 deletions
+40 -4
View File
@@ -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
+20 -17
View File
@@ -9,25 +9,28 @@
Valgrind limpio. Falta `escpos_buffer_append`: el parámetro con la cantidad,
`const`, reservar `len + cantidad`, `memcpy` y el comentario de la cabecera.
Ahora copia 1 byte (`sizeof *byte`).
- Entorno: Fedora 42 nativo (gcc 15.2, clang 20, make 4.4, gdb 17,
valgrind 3.26) y Windows con MSYS2 UCRT64. **Próxima sesión en Windows**
(2026-10-05).
- Máquinas: sobremesa con Windows (MSYS2 UCRT64) y portátil con Fedora 42
(gcc 15.2, clang 20, make 4.4, gdb 17, valgrind 3.26). Ver "Pendiente por
máquina".
### Al llegar a Windows
## Pendiente por máquina
1. `git pull` desde la terminal UCRT64 de MSYS2.
2. Comprobar que están las herramientas: `gcc --version`, `make --version`,
`gdb --version`. Si falta algo:
`pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb make`.
3. Cerrar la Fase 1 en Windows: `make` debe generar `build/hello.exe`. El
Makefile todavía no añade `.exe` (falta el `ifeq ($(OS),Windows_NT)` de
`docs/06-make.md`). Ojo: `mkdir -p` y `rm -rf` solo funcionan en la shell de
MSYS2, no en `cmd` ni en PowerShell.
4. VS Code: `.vscode/launch.json` y `c_cpp_properties.json` ya tienen la
configuración de Windows (`C:/msys64/ucrt64/bin/...`). Comprobar que la ruta
de MSYS2 es esa.
5. Valgrind no existe en Windows. La parte portable se sigue validando en
Fedora. En Windows se puede seguir avanzando con el 2.3b.
### Windows (sobremesa)
- Al llegar: `git pull` en la terminal UCRT64 y comprobar `gcc`, `make` y `gdb`.
Si falta algo:
`pacman -S mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-gdb make`.
- Cerrar la Fase 1: `make` tiene que generar `build/hello.exe`. Falta en el
Makefile el `ifeq ($(OS),Windows_NT)` de `docs/06-make.md`. `mkdir -p` y
`rm -rf` solo funcionan en la shell de MSYS2.
- Probar F5 en VS Code: `.vscode/` ya tiene la configuración de Windows con
rutas `C:/msys64/ucrt64/...`.
- El 2.3b se puede avanzar aquí; la comprobación de memoria queda para Fedora.
### Fedora (portátil)
- Validar con valgrind el 2.3b cuando esté hecho (y con ASan/UBSan antes de
cerrar la Fase 2).
## Hecho