La araña de conocimiento

Muestra demostrativa. Este artículo existe para probar cómo se ve la metodología de araña dentro del garden — hay dos renders del mismo dato (SVG inline y radar-beta de Mermaid) para decidir cuál se queda. Los números son reales: salen del assessment de background jobs.

La araña —spider chart, radar chart, como quieras llamarle— no es decoración. Es el resultado de un procedimiento: medir el conocimiento con evidencia antes de enseñar nada. Sin la medición, el material apunta al nivel equivocado y aburre o ahoga.

Los cinco ejes

Cada eje es una forma distinta de tener un conocimiento, no un subtema. Se puede implementar algo en producción sin poder explicarlo, y viceversa — por eso son ejes separados y no un solo número.

La escala va de 0 a 1. La barra de referencia (0.80 en los cinco ejes) es “entrevista senior”: no es el techo, es el umbral donde deja de notarse el hueco.

Render A — SVG inline

Ventaja: controla el color con las variables del tema (--secondary, --highlight), así que cambia solo entre día y noche. Desventaja: las coordenadas son a mano.

Render B — Mermaid radar-beta

---
config:
  radar:
    graticule: polygon
    showLegend: true
---
radar-beta
  title Araña TOMO · background jobs
  axis def["Definición"], fey["Feynman"], ana["Analogía"], imp["Implementación"], tro["Troubleshooting"]
  curve bar["Barra senior"]{0.80, 0.80, 0.80, 0.80, 0.80}
  curve hoy["Medición de hoy"]{0.30, 0.25, 0.35, 0.30, 0.15}
  max 1
  min 0

Ventaja: el dato se lee en texto plano y se edita sin calcular nada. Desventaja: el tema lo pinta Mermaid, no la paleta del garden, y radar-beta sigue siendo beta (necesita Mermaid ≥ 11.6; el garden ya está en 11.15).

El procedimiento, en cinco fases

1. Calibración por evidencia. Antes de enseñar nada, leer la evidencia primaria — work-logs, commits, código real, conversaciones viejas— y estimar el nivel por subdominio. Regla que no se relaja: distinguir evidencia de hacer (código escrito, incidentes vividos) de evidencia de leer (clippings, guías, material generado). Solo el hacer sostiene un nivel alto. Una nota sobre un tema no prueba entenderlo.
2. Preguntas con metacognición explícita. Cada pregunta apunta al borde de la incertidumbre: la óptima es la que tienes ~50% de probabilidad de contestar al nivel superior. Una que seguro apruebas o seguro fallas da cero bits de información.
3. Formato de impartición. Diagrama del mecanismo, código que corre de verdad (y correrlo, y mostrar la salida), HTTP crudo cuando aplique, URLs a la fuente primaria.
4. Verificación adversarial. Revisores independientes intentando refutar el material antes de estudiarlo. En la sesión original encontró 20 errores en un solo documento, dos de ellos config que reventaba el boot.
5. Persistencia. Un índice con prior → target, un archivo por lección con su Feynman checkpoint y sus probes de salida, y la araña actualizada para registrar el delta.

Por qué funciona

Las auto-evaluaciones inflan. Siempre. La araña sirve precisamente porque no se llena con lo que uno cree que sabe: se llena con lo que la evidencia sostiene. Ver el eje de troubleshooting en 0.15 cuando llevas seis años en producción es incómodo, y esa incomodidad es el dato.

Ver la metodología corriendo

El caso completo —chat a la izquierda, artículo reescribiéndose a la derecha, la araña subiendo en vivo— está en el demo interactivo:

• Demo TOMO — conversación con la araña, con guión reproducible (botón ▶ auto-demo).
• El assessment de background jobs — de dónde salen estos números.
• Diseñar un DSL en Ruby — otra araña, otro dominio.