Habilidad de Registro de Crecimiento
El problema: La mayoría de la gente escribe "arreglé un bug en X" como registro de aprendizaje. Eso es una entrada de diario, no un artefacto de aprendizaje. Un verdadero registro de crecimiento extrae el patrón para que lo reconozcas la próxima vez.
Esta habilidad enseña: Cómo escribir entradas de aprendizaje que se acumulen entre sesiones. Funciona con cualquier sistema de toma de notas — archivos Markdown, Notion, Obsidian, texto plano. Las plantillas son genéricas; adáptalas a tu configuración.
Cuándo Activarla
- Después de completar una tarea compleja (varios archivos, nueva funcionalidad, cambio de arquitectura)
- Después de un fallo, error o momento de "esto fue más difícil de lo esperado"
- Cuando quieras revisar lo que has aprendido durante un período
Cuándo NO activarla: Cambios triviales (correcciones tipográficas, ajustes de una línea, cambios de valor de configuración sin depuración). El umbral: ¿esta tarea implicó depuración, rehacer, reversión o una decisión no obvia? Si sí → escribe una entrada. Si no → omítela.
Las Tres Reglas
Regla 1: Fallos > Logros
Un fallo es nutricionalmente más denso que un éxito. Un bug que tardó 2 horas en encontrar enseña más que 3 funciones que funcionaron al primer intento.
Malo: "Implementé exitosamente el flujo de inicio de sesión."
Bueno (desarrollo web): "Flujo de inicio de sesión: el token de sesión no persistía porque la cookie SameSite predeterminaba a Lax en Chrome 128+. Patrón: siempre establecer explícitamente SameSite=None; Secure cuando sea de origen cruzado. Señal para reconocer: la autenticación falla después de una actualización del navegador o al cruzar límites de origen."
Bueno (tubería de datos): "La importación CSV falló silenciosamente con filas vacías porque pandas.read_csv(dropna=False) mantiene filas de ancho cero que len() cuenta como válidas. Patrón: siempre df.dropna(how='all', inplace=True) antes de la validación de recuento de filas."
Regla 2: El Principio Bole (伯乐原则)
Antes de escribir una nueva entrada, pregúntate: "¿Es esto fundamentalmente lo mismo que algo que ya registré?"
Misma causa raíz, diferente síntoma → fusiona, no dupliques. Nueva causa raíz → nueva entrada.
Cómo verificar: Busca en las entradas existentes palabras clave de tu causa raíz antes de escribir. Si encuentras una coincidencia, añade tu nuevo síntoma como un ejemplo adicional dentro de la entrada existente en lugar de crear un duplicado.
Ejemplo: "Olvidé actualizar el índice de salida después de crear un archivo" y "Olvidé actualizar las valoraciones de habilidades después de una tarea" — misma causa raíz (sin disparador de captura automática). Fusionar en una entrada sobre "brechas de captura posteriores a la tarea".
Regla 3: Debe ser Transferible
Cada entrada debe responder: "La próxima vez que enfrente una situación similar, ¿qué haré diferente?"
Si no puedes escribir esa frase, aún no has extraído el patrón.
Cómo extraer un patrón de un evento concreto:
- Expresa lo que sucedió en una oración
- Pregunta "¿por qué?" iterativamente hasta llegar a la causa raíz (generalmente 3-5 porqués)
- Generaliza: "¿De qué clase de problema se trata?" (no "bug de Chrome 128" sino "cambio predeterminado del navegador que rompe el comportamiento existente")
- Formula como: "La próxima vez que vea [señal], haré [acción]."
- Nombra la señal: ¿qué observable específico te indica que este patrón está activo?
Plantilla de Entrada
Alcance: Una entrada por causa raíz distinta. Longitud típica: 4-8 oraciones. Si toma más de 2 minutos escribirla, estás narrando eventos. Si menos de 30 segundos, no has profundizado lo suficiente.
## [Título: el patrón, no el evento]
### Contexto
- ¿Qué estaba intentando hacer?
- ¿Qué salió mal / qué funcionó sorprendentemente bien?
### Causa Raíz / Idea Central
- El mecanismo subyacente, no solo el síntoma
### El Patrón (transferible)
- La próxima vez [situación similar], haré [acción específica].
- Señal para reconocer: [¿qué observable me indica que este patrón está activo?]
### Relacionado
- [nombre-entrada](../../ruta/a/entrada-relacionada.md)
Tipos de Entrada
Los cuatro tipos usan la plantilla anterior. El tipo determina qué secciones tienen más peso:
| Tipo | Cuándo Usarlo | Énfasis | Ejemplo de Título |
|---|---|---|---|
| Fallo | Algo se rompió, necesitó depuración o requirió rehacerlo | Causa Raíz | "Herencia de configuración ≠ herencia de comportamiento entre sesiones" |
| Metodología | Surgió un proceso repetible del trabajo | Contexto / Patrón | "PPT → guía de estudio para examen tipo libro abierto: estructura de tres capas" |
| Descubrimiento de Patrón | Una idea reutilizable sobre herramientas, sistemas o pensamiento | Sección de Patrón | "Plantilla de descripción de PR: describe la brecha, no la funcionalidad" |
| Cambio de Capacidad | Una mejora medible de habilidad | Contexto (antes vs después) | "Git: de clonar/enviar a PR independiente con 12 commits" |
Lista de Verificación de Calidad
Antes de finalizar una entrada de registro de crecimiento:
- ¿El título nombra el patrón, no el evento?
- ¿Hay una oración "La próxima vez haré..."?
- ¿La "Señal para reconocer" es lo suficientemente específica para activar el patrón la próxima vez?
- ¿Busqué entradas existentes en busca de duplicados antes de escribir? (Principio Bole)
- ¿La causa raíz se distingue del síntoma?
- ¿Los recuerdos relacionados están enlazados?
- ¿La entrada tiene entre 4 y 8 oraciones? Más corta = demasiado superficial; más larga = narración de eventos.
Anti-Patrones
- Evitar: "Arreglé un bug en el módulo de pagos" (evento, no patrón)
- Evitar: Copiar el mensaje de commit textualmente (los commits describen qué cambió; los registros extraen por qué es importante)
- Evitar: Escribir una entrada por cada commit (solo cuando surge un patrón)
- Evitar: Omitir la oración transferible (sin ella, es solo un diario — esto no es negociable)
- Evitar: Duplicar el mismo patrón bajo diferentes títulos (viola el Principio Bole — busca antes de escribir)
Almacenamiento
Guarda las entradas donde guardes tus notas. Patrones comunes:
- Archivos Markdown en un directorio
growth-log/(un archivo por día:YYYY-MM-DD.md) - Una sección dedicada en Notion, Obsidian o tu aplicación de notas
- Archivos de texto plano con una convención de nomenclatura consistente
Elige una convención y mantente firme. La capacidad de búsqueda importa más que el formato.
Si Usas Delivery Gate
El gancho de parada delivery-gate verifica que los archivos de aprendizaje se modificaron hoy mediante marcas de tiempo del sistema de archivos. Esta habilidad enseña qué escribir — para que el archivo que delivery-gate verifica contenga patrones útiles, no marcas de tiempo vacías.
Tarea completada → delivery-gate verifica: ¿se tocó el archivo de aprendizaje hoy?
→ Desactualizado (ningún archivo modificado): bloquea — "¿qué aprendiste?"
→ Reciente (archivo tocado): pasa — esta habilidad asegura que el contenido sea útil
Tener cumplimiento sin metodología → entradas vacías. Tener metodología sin cumplimiento → capturas olvidadas. Cada una es útil independientemente; juntas cierran el círculo.