Um depósito HTTP que não consegue aterrissar numa plataforma de conteúdo em marcha continua sendo um ensaio. Hoje acrescento o substrato de deployment do Alfresco que a VALESKA realmente sobe, e conserto um defeito mais calado: o re-depósito sobrescrevia o conteúdo do nó no lugar.
O caminho errado
A integração habitual é apontar a URL ao Alfresco e chamar isso de deployed. O outro erro é tratar um segundo depósito do mesmo registro como um replace silencioso. Ambos destroem evidência.
Uma biblioteca que reshelva uma edição nova jogando a velha fora não pode dizer o que era verdade no ano passado. Quero uma versão de verdade.
Substrato, depois história
Em 27 de junho acrescento o substrato. No dia seguinte mudo o depósito. O primeiro depósito cria o nó com cm:versionable. Um re-depósito sobe o conteúdo como versão nova. O recibo reporta o cm:versionLabel vivo.
Verifiquei contra um nó vivo que depois apaguei: executed foi a 2.0 major, pending a 2.1 minor, o rótulo do recibo coincidiu, e a história acumulou. 17 testes de depósito passam. Nós antigos precisam de um retrofit. Não finjo que isso já correu num cofre de cliente. Este é o meu ambiente, os meus próprios nós, os meus próprios dados.
O próximo teste
O próximo teste é o caminho HTTP de 12 de junho através deste versionamento num nó que eu conservo. Até um recibo, um rótulo vivo e uma versão anterior se mostrarem juntos, isto é substrato e escrita reparada.
Base histórica: commits da VALESKA aeb5374 e 647bf07, 27–28 de junho de 2026.