🧭 Proyecto 6: la mentalidad
Todo esto es iterativo. El módulo de cierre no instala nada: te entrega el hábito que hace que los cinco proyectos anteriores sobrevivan al próximo cambio de modelo — seguir lo que exige cada proveedor, registrar cada falla en una línea y dejar de administrar prompts.
🎯 El proyecto en una pantalla
Convertir lo que armaste en hábito: una rutina de mantenimiento que absorbe cambios de modelo, de proveedor y de harness sin rehacerlo todo.
Un FALHAS.md en la raíz del proyecto con al menos una línea real, un handoff de cierre escrito y el checklist de los 7 puntos para mañana.
Puedes decir, mirando el FALHAS.md, cuántas fallas fueron de prompt y cuántas de infra — y cuál fue la corrección mínima de cada una.
♻️ Cada cambio mejora un modelo y rompe otro
El escenario sigue cambiando, y esta no es una salvedad cortés al final del texto: es la condición permanente de trabajo. Cada cambio que haces en una skill, en un AGENTS.md, en un hook, puede mejorar esa skill para un modelo y romper la misma skill para otro. Ajustas la instrucción para el modelo que estaba divagando y, en la misma línea, le quitas el espacio que el otro necesitaba.
Por eso lo correcto no es congelar el workspace una vez armado — es seguir constantemente lo que cada modelo realmente necesita. El workspace agnóstico no elimina el mantenimiento; lo vuelve pequeño y localizado, en lugar de una migración completa en cada cambio.
El ciclo gira para siempre; lo que no gira es el núcleo. Cuando un cambio rompe un ejecutor, el arreglo ocurre en el borde de ese ejecutor — nunca reescribiendo el contexto que los tres comparten.
✓ Mantenimiento pequeño
- ✓El cambio entra en el núcleo; el adaptador de cada ejecutor se regenera.
- ✓El readback se ejecuta en los runtimes que usas, no solo en tu favorito.
- ✓¿Falló en uno solo? Arreglas el borde de ese, y el resto no se toca.
- ✓Lo que falló se convierte en una línea del changelog de fallas.
✗ Mantenimiento por reescritura
- ✗"Falló en Codex" se convierte en "voy a rehacer mis instrucciones desde cero".
- ✗Dos versiones de la skill, una por modelo, divergiendo cada semana.
- ✗Probar solo en el modelo que más te gusta y descubrir el resto en producción.
- ✗Ningún registro: seis meses después repites el mismo error.
Conceptos clave
El escenario cambia; el workspace lo acompaña, no se congela.
El mismo cambio tiene signos opuestos en modelos diferentes.
Adaptador del ejecutor, nunca el núcleo compartido.
Readback en cada runtime que realmente usas.
🔌 Seguir lo que exige cada proveedor
"Model-agnostic" nunca quiso decir "provider-agnostic sin esfuerzo". La capa de conocimiento es portátil; los bordes siguen siendo del proveedor, y cambian sin avisarte. Las diferencias que mostró todo el curso no son bugs: son el precio de usar más de un ejecutor.
📋 Lo que el kit ya descubrió sobre los bordes
- •Codex CLI no tiene import: no existe el
@arquivo.mdde Claude. Lo que debe leerse hay que decirlo en texto — "leecontext/overview.mdantes de responder" — o el contenido entra inline. - •Codex no lee un
AGENTS.mdglobal de la forma en que Claude lee elCLAUDE.mdglobal: lo que vale es el del proyecto (y el de~/.codexcuando está configurado). No asumas herencia; compruébalo con readback. - •Los hooks son diferentes en cada harness: nombre, evento, formato y momento de disparo no coinciden. Un hook siempre es código de borde — trátalo como adaptador, no como parte del núcleo.
- •Sandbox y permisos varían por máquina: en este host, forzar
-s read-onlyencodex execfalló por AppArmor. La corrección fue respetar elsandbox_modedeconfig.toml, no reescribir el script. - •Lo que es común a casi todos: Markdown.
agents.mdlo entienden varios;claude.mdes la excepción específica de Claude. Prácticamente todo lo demás es portátil.
💡 La rutina de drift, semanal
Una vez por semana, ejecuta el mismo readback en los runtimes que usas y compáralo con la semana anterior. No es paranoia: así descubres que una actualización cambió la carga de instrucciones antes de que lo descubra un cliente. Quince minutos por semana contra una migración de emergencia.
Conceptos clave
Import, archivo global, hooks, sandbox: todo específico.
Pide la lectura en texto; no cuentes con @arquivo.
La diferencia que aparece sola entre dos semanas.
El denominador común que sobrevive a todos ellos.
🔮 Los modelos cerrados quizá no necesiten skills; los locales sí
Una posibilidad real para el futuro: los modelos cerrados podrían, en algún momento, dejar de necesitar skills. Si se entrenan con base en las conversaciones y absorben esas capacidades, buena parte de lo que hoy es skill se vuelve comportamiento por defecto. Mientras tanto, los modelos locales tal vez sigan dependiendo de ellas — y hoy dependen.
La conclusión práctica no es elegir un bando. Es la frase que cierra el texto fuente: construye tu estructura de forma independiente del modelo, pero sigue lo que exige cada proveedor a lo largo del tiempo. Una skill que se volvió innecesaria en el modelo cerrado sigue siendo la muleta que hace funcionar al modelo local — y es lo que te da la opción de salir.
✓ Lo que sobrevive al cambio
- ✓Contexto, conocimiento y decisiones en Markdown.
- ✓Procesos, handoffs y criterios de validación.
- ✓Skills canónicas, con adaptadores generados por ejecutor.
- ✓Memoria curada con fuente y fecha.
✗ Lo que pierdes en el cambio
- ✗Prompts afinados para un modelo específico.
- ✗Memoria nativa del runtime, que no sale de ahí.
- ✗Hooks y configuraciones de harness escritos a mano.
- ✗Hábitos de interfaz — y nada de eso era tu trabajo.
💡 Sobre construir un "super-harness"
Para Claude y Codex no vale la pena: sus harnesses ya están muy optimizados, y los proveedores se encargan de adaptarlos a cada modelo nuevo. Donde sí vale construir el tuyo es donde nadie lo hace por ti: modelos locales y pipelines propios. Ahí el harness es tu producto, no una reimplementación de lo que ya existe listo.
Conceptos clave
Capacidad que el modelo pasa a tener sin necesitar un archivo.
Los modelos locales siguen necesitando las skills explícitas.
Construye de forma independiente, pero sigue lo que exige cada proveedor.
El valor real de ser agnóstico: poder cambiar sin rehacer.
🗂️ Dejas de administrar prompts
Este es el cambio de mentalidad que da nombre al módulo, y cabe en una frase: dejas de administrar prompts y pasas a administrar contexto, estado, herramientas, procesos y criterios de validación.
Administrar prompts es optimizar la frase. Da ganancias rápidas y se evapora con la próxima versión del modelo. Administrar contexto es responder quién es dueño de cada información, cuál es el estado actual de la tarea, qué herramientas puede usar el agente, cuál es el proceso y cómo se demuestra que quedó listo, y eso sigue valiendo cuando cambia el modelo.
A la izquierda, el trabajo que desaparece con la versión del modelo. A la derecha, los cinco bloques que administras y que sobreviven a cualquier cambio; el último, validación, es el que impide que los otros cuatro se vuelvan ficción.
Cómo cambia esto tu día: cuando algo sale mal, la primera pregunta deja de ser "¿cómo reescribo este prompt?" y pasa a ser "¿cuál de los cinco falló?". ¿Faltó contexto? ¿El estado estaba desactualizado? ¿La herramienta no existía en la sesión? ¿El proceso se saltó el handoff? ¿O simplemente nadie validó? Cuatro de esas cinco respuestas se arreglan en un archivo, no en una frase.
Conceptos clave
Hechos con dueño, fuente y fecha.
tasks/current.md: lo que se hace ahora y el criterio de terminado.
Handoff, prime, drift: el ciclo que repites.
Readback y canario; "el archivo existe" no es prueba.
📓 El changelog de fallas: una línea por falla
La herramienta de mantenimiento más barata del curso es un archivo FALHAS.md en la raíz del proyecto, con una línea por falla: fecha, qué se rompió, la corrección más pequeña posible, y si era un problema de prompt o de infra. Sin narrativa. Lo más reciente arriba.
Después de unas diez líneas el patrón se vuelve obvio, y dejas de reconstruir cosas que solo necesitaban una protección. Esa es la tesis de todo el archivo: si la respuesta fue reescribir o reconstruir, probablemente solo faltaba una protección: un tope, un retry, un guard, una validación. Registrarlo en la línea es lo que impide la próxima reconstrucción.
Code box 1 — el FALHAS.md real del kit
Objetivo: ver el formato en uso, con las dos fallas reales registradas durante la construcción de este material. Copia el encabezado a tu proyecto.
# Fallas (lo más reciente arriba)
| fecha | qué se rompió | corrección mínima | prompt \| infra |
|---|---|---|---|
| 2026-09-13 | readback-test.sh forzaba `-s read-only` en codex exec; bwrap falla por AppArmor en este host | quitar el flag, respetar sandbox_mode de config.toml | prompt \| infra |
| 2026-09-13 | el resumen de audit.sh contaba líneas de la sección 3 (73+17+4=94 ≠ 89) | restringir grep a la sección 2.1 | prompt |
Cómo verificar: wc -l FALHAS.md crece una línea por cada falla corregida, y grep -c 'infra' FALHAS.md te dice cuántas fueron de entorno. Si una línea se volvió párrafo, está en el archivo equivocado: el detalle largo va en un archivo aparte y se enlaza.
✓ Línea útil
- ✓Escrita al terminar de corregir, antes de la siguiente tarea.
- ✓La corrección más pequeña posible, no la que hiciste con rabia.
- ✓Marcada como prompt, infra, o ambas cuando sea ambas.
- ✓Una línea. El detalle largo va a un archivo aparte, enlazado.
✗ Línea inútil
- ✗"El script dio error, lo arreglé." — sin qué ni cómo.
- ✗Escrita al final de la semana, cuando ya olvidaste la causa.
- ✗"Reescribí el módulo" como corrección — eso es el síntoma, no el arreglo.
- ✗Tres párrafos de narrativa que nadie vuelve a leer.
💡 ¿Prompt o infra?
Prompt = pediste de una forma que indujo el error, o el modelo entendió mal. Infra = máquina, memoria, red, servicio caído, clave incorrecta, proceso sin supervisión. Cuando sea ambas, marca ambas — como la primera línea del kit, que era un script mal escrito y un AppArmor del host. Una falla que atraviesa varios proyectos va en el FALHAS.md del hub, no en el del proyecto donde apareció por casualidad.
Conceptos clave
Fecha, qué se rompió, corrección mínima, clasificación.
El punto del ejercicio: lo mínimo que lo resolvió.
Tope, retry, guard, validación — casi siempre era eso.
El archivo empieza a decirte dónde tropiezas siempre.
🏁 En una frase — y qué hacer mañana
Si cierras esta página y te quedas con una sola frase, que sea esta:
"No migres tu cerebro de Claude a Codex; separa el cerebro del modelo."
Lo que necesita sobrevivir al cambio no es Claude, ni Codex, ni Gemini. Es tu capa de contexto, conocimiento, Markdown, procesos, handoffs, memoria y herramientas.
Qué hacer mañana — 7 puntos
1. Ejecutar el doctor
Mira qué está instalado, en qué versión, y qué está roto hoy. Quince minutos antes de cualquier decisión.
2. Ejecutar el audit (MODE: audit)
No se escribe nada. Sales con el árbol propuesto, las reglas de propiedad y los checks de aceptación — y con la lista de lo que no se pudo inspeccionar.
3. Escribir el AGENTS.md global
Tus reglas genéricas, sin nombres de clientes, sin secretos. El CLAUDE.md global apunta a él.
4. Elegir UN piloto
Un proyecto real, con una tarea representativa. No cinco. La plantilla solo es plantilla después de que uno pasó.
5. Hacer el handoff hoy mismo
Al final de la primera sesión, antes de cerrar. El ciclo empieza a valer cuando la segunda sesión abre por el prime.
6. Agendar el drift semanal
Un recordatorio recurrente: mismo readback, mismos runtimes, comparado con la semana anterior.
7. Crear el FALHAS.md
Vacío, con el encabezado listo. La primera línea aparece antes de lo que imaginas — y escribirla ahí es lo que evita la primera reconstrucción.
Code box 2 — handoff de cierre (ejemplo)
Objetivo: cerrar el curso de la forma en que vas a cerrar cada sesión de aquí en adelante. Guárdalo como handoffs/latest.md en tu proyecto piloto y adapta las líneas.
# Handoff — 2026-09-14 — fin del curso Claude → Codex
## Proyecto y alcance
<mi-proyecto-piloto>: workspace agnóstico. Alcance: aplicar los 6 proyectos de la trilha 3.
## Objetivo actual
Correr una semana entera con handoff + prime antes de migrar el segundo proyecto.
## Estado aceptado
- AGENTS.md global escrito; CLAUDE.md global apunta a él.
- context/{overview,current-state,sources}.md y tasks/current.md completados.
- 3 hechos promovidos desde la memoria bruta, con fuente y dos fechas.
- FALHAS.md creado (1 línea: sandbox de codex exec — infra).
## Checks ejecutados y resultado
- readback en Claude: pasó (citó AGENTS.md y tasks/current.md).
- readback en Codex: pasó (citó AGENTS.md; sin import, lectura explícita).
- canario sintético entre clientes: NO EJECUTADO (aún sin workspace de cliente).
## Preguntas abiertas
- ¿Vale la pena montar el tercer ejecutor local ahora o después del segundo proyecto?
- ¿Qué skills se vuelven canónicas primero?
## Próxima acción exacta
`scripts/drift.sh` el lunes y comparar con el informe de esta semana.
Cómo verificar: abre una sesión nueva, pide que lea solo este archivo, y pregunta "¿cuál es la próxima acción exacta?". Si la respuesta es la línea final, el handoff está bien. Si la sesión te necesita para entender, falta contexto en el archivo — no en el modelo.
Último recordatorio: nada de esto exige que abandones Claude, ni Codex, ni ningún runtime. Solo exige que tu parte — contexto, estado, herramientas, procesos y validación — esté en archivos que puedas abrir, copiar y llevarte. Los modelos pueden cambiar. Tu estructura de trabajo debe seguir funcionando.
Conceptos clave
La frase que resume todo el curso.
La plantilla nace de un proyecto que funcionó.
El ciclo solo existe cuando la segunda sesión abre por el prime.
Drift semanal + FALHAS.md: mantenimiento barato y continuo.
Autoevaluación (opcional): uno de tus scripts falló porque el modelo devolvió una respuesta enorme y se agotó el tiempo. Reescribiste el script completo. ¿Qué va en la línea del FALHAS.md?
🎯 Resumen del proyecto
Fin de la Ruta 3:
Recorriste los seis proyectos. Mañana: doctor, audit, AGENTS.md global, un piloto, handoff hoy, drift semanal y el FALHAS.md creado.