Ángulo

Cada piso del contexto que absorbe quinientos correos de una comunidad de propietarios se añadió por una avería fechada del nivel anterior: el diario cronológico porque la agregación había borrado las fechas de la obra, el archivo de directrices porque las reglas de tratamiento se ahogaban bajo la materia, el reparto en quince archivos temáticos porque context.md había pasado de las mil líneas, el glosario porque el mismo vocabulario técnico se repetía por todas partes. La arquitectura final —directrices, glosario, índice, archivos temáticos— se lee por tanto como la lista de las averías encontradas, en su orden de aparición; y como esa lista es justo lo que le falta a quien la retoma desde fuera, un sistema copiado por su forma solo devuelve la estructura de quien la sufrió, dejando intactas las averías que todavía no has encontrado.

Síntesis

Las cuatro averías de la serie no tienen nada en común en cuanto a su causa. Una es un borrado voluntario que no produce ningún error: una ficha exacta, simplemente amnésica. Otra es un desacuerdo de organización, donde la máquina trabajó bien y lo que devuelve no es la estructura de nadie que vaya a usarla. Una tercera es un efecto de volumen que se vuelve contra el propio modelo. La última es una redundancia de vocabulario. Lo que las une se reduce a una sola cosa: ninguna era visible desde el escalón anterior, y cada una solo pudo nombrarse después de haberla sufrido.

De ahí se sigue el orden, que no es intercambiable: solo se reparte limpiamente por temas después de haber sacado las reglas del archivo, sin lo cual no sabes qué hay que copiar en cada trozo. Y de ahí se sigue el estatuto singular del primer escalón: no produce un sistema, produce el inventario de las averías por venir, lo que hace que sustituirlo sea normal en lugar de costoso, y lo que explica que ese inventario no se pueda tomar prestado de otro: una arquitectura acabada solo enseña sus respuestas.

Queda la condición que autoriza todo el planteamiento, y que ninguno de estos escalones enuncia. Reparar después de la avería supone que la avería se paga en rodeo y no en pérdida: el histórico que falta se recupera en los correos en bruto guardados al lado, un proveedor mal asignado se corrige reabriendo un mensaje. Sobre una materia donde el error no tiene vuelta atrás, la construcción por averías sucesivas deja de ser un método y se convierte en una apuesta.

Tensiones / contradicciones

Dos consignas de la misma serie no tiran en el mismo sentido. Una dice que solo hay que cruzar un escalón cuando el anterior ya no basta; la otra dice que la primera versión está hecha para tirarse. Reparar a pequeños pasos y volver a empezar de cero son dos gestos distintos, y nada dice en qué momento uno deja de ser el bueno.

Otra tensión, entre el principio y la práctica de quien lo enuncia: recomienda partir de un archivo y avanzar por averías, mientras mantiene un sistema de contextos completo —carpetas, manifiestos de carga, notas relacionadas— del que ya va por la tercera versión. El consejo se dirige a quien empieza; no describe la posición de quien lo da.

Preguntas

• Un sistema heredado —recogido de un compañero, de una plantilla pública— ¿puede producir sus propias averías lo bastante rápido como para entenderlas, o hay que haberlo construido uno mismo para verlas?
• ¿Cuántos escalones puede cruzar un equipo junto, cuando la avería solo la siente la persona que trata la materia?
• ¿Qué pasa con un piso cuya avería de origen ha desaparecido —al haber cambiado el umbral que lo motivó— y que nadie piensa en desmontar?