Un depósito HTTP que no puede aterrizar en una plataforma de contenido en marcha sigue siendo un ensayo. Hoy añado el sustrato de despliegue de Alfresco que VALESKA realmente arranca, y arreglo un defecto más callado: el re-depósito sobreescribía el contenido del nodo en el sitio, así que los bytes PDF/A sustituidos desaparecían y la etiqueta de versión nunca avanzaba.
El camino equivocado
La integración habitual es «apunta la URL a Alfresco y llámalo desplegado». El otro error habitual es tratar un segundo depósito del mismo registro como un reemplazo silencioso. Ambos destruyen evidencia. Una bóveda que olvida lo que tuvo ayer no guarda registros. Guarda el último archivo.
Una biblioteca que reshelva una edición nueva tirando la vieja no puede decirte qué era verdad el año pasado. Quiero una versión de verdad: mayor cuando el estado de ejecución es executed, menor en otro caso, con un comentario de gobernanza en la subida.
Sustrato, luego historia
El 27 de junio añado el sustrato — el compose y la configuración que de verdad levantan la plataforma de contenido al lado de VALESKA. Al día siguiente cambio el depósito. El primer depósito crea el nodo con el aspecto cm:versionable y auto-versión. Un re-depósito asegura ese aspecto y sube el contenido como una versión nueva. El recibo reporta el cm:versionLabel vivo leído de Alfresco.
Lo verifiqué contra un nodo vivo de Alfresco que luego borré: executed fue a 2.0 mayor, pending a 2.1 menor, la etiqueta del recibo coincidió cada pasada, y la historia se acumuló. La suite de depósito sigue reportando 17 que pasan. Los nodos creados antes del arreglo necesitan un retrofit de una vez del aspecto versionable. No finjo que ese retrofit ya corrió en la bóveda de un cliente. No ha corrido. Este es mi entorno, mis propios nodos, mis propios datos.
Vine de una biblioteca que rechazaba sobres incompletos. HTTP le dio una puerta. Esta semana la puerta aterriza en una bóveda en marcha, y la bóveda guarda los bytes de ayer. Sin esos tres pasos en orden tendría una demo de rechazo, una demo de POST y una bóveda que olvida.
La siguiente prueba
La siguiente prueba es el camino HTTP del 12 de junio a través de este versionado en un nodo que conservo. Hasta que un recibo, una etiqueta viva y una versión anterior se puedan mostrar juntos, esto es un sustrato y una escritura reparada, no un programa de archivos en producción.
Base histórica: commits de VALESKA aeb5374 (27 jun) y 647bf07 (28 jun 2026).