20260916 #7 — Nadie diseñó el frontmatter

Abro cualquier archivo de estos repos en VS Code y antes del primer título el panel Outline muestra un bloque de nombres: title, numero, date, sesion_fuente, fecha_creacion, description, tags, destacado, slug. Esta nota lleva esos nueve arriba, y sumará un décimo al publicarse. Ayer me pregunté quién decidió cada uno. Respuesta corta: nadie, de una vez.

Ese bloque es el frontmatter: unas líneas clave: valor entre dos --- al tope de un archivo Markdown. No forma parte del texto; es lo que el archivo dice de sí mismo —título, fecha, etiquetas, de dónde salió— en un formato que un script puede leer sin entender la prosa. Nadie lo escribe desde cero: cada tipo de archivo tiene una plantilla con el bloque ya armado y los valores vacíos, y quien crea el archivo la copia y la completa; algunos campos los rellena después un script —el hook que cierra una sesión, el paso que publica una nota. Sirve para que el sitio ordene las notas, para que un hook rellene fechas, para que un radar cruce sesiones con notas ya publicadas. Y sirve, sobre todo, mientras alguien lo lea.

Cuatro cunas

Reconstruir el origen tomó una tarde: siete familias de campos, nacidas en cuatro lugares. La de las sesiones —alias, fecha_inicio, estado— nació un 16 de agosto en otro proyecto, cuando dos sesiones seguidas fijaron cómo nombrar y elegir una sesión de trabajo. Seis días después, en el molde con el que levanto proyectos, nació una clasificación de dos campos, domain y type, con vocabulario cerrado, para etiquetar por igual reglas, agentes, tickets y decisiones. La tercera cuna es este proyecto: entre el 3 y el 15 de septiembre, en cinco rondas, los campos que identifican una nota. La cuarta, el 11: la versión en inglés, en un archivo aparte con su propio bloque.

Lo que viajó y lo que no

Cada familia viaja por un mecanismo distinto, y ninguno es todo o nada: el scaffold inicial copia todo; la sincronización solo actualiza agentes, reglas y scripts; un hook rellena un puñado de campos al cerrar cada sesión. El resultado: de los tickets de un proyecto anterior a la clasificación, 1 de 84 la tiene; en uno posterior, 178 de 178; acá, donde nació, 48 de 215. Y esos dos campos no los lee ningún script: la regla que los define los llama, textualmente, "metadata".

El segundo hueco es más raro. El mismo hook, al registrar una sesión nueva, rellena su identificador con una expresión regular; como ese campo arranca vacío, se come también la línea siguiente —la de la fecha de inicio. 254 de 260 sesiones de un proyecto nacieron sin ella, y nadie lo notó hasta que otro script tuvo que deducirla del nombre del archivo.

Lo que aguanta

Los cuatro campos que identifican una nota —slug, numero, fecha_creacion, tags— tienen lo que la clasificación nunca tuvo: un lector que falla ruidosamente. El build corta si falta uno. Y el estado de publicación de una pieza no se guarda: se recalcula al consultarlo. Menos cómodo, imposible de desincronizar. Un campo no sobrevive por la intención con la que se creó, sino porque alguien, o algo, lo sigue leyendo.

El bloque de arriba no lo diseñó nadie de punta a punta: tiene la forma de su historia. De los que encabezan tus archivos, ¿cuántos sabés quién los escribió, y cuántos sabés que alguien todavía los lee?

Tags: frontmatter · metadatos · convenciones entre proyectos · propagación · validación en build