Un ciclo de escritura que nunca fusiona nada

Por un tiempo, la capa de memoria de mi homelab era excelente para notar cosas. Podía decirme que un registro de decisión se había vuelto obsoleto, que un servicio documentado no coincidía con lo que estaba corriendo, que una creencia se había vuelto contradictoria. Luego dejó de hacerlo, porque lo único que pasaba después de notar algo era que yo leía un reporte.

Cerrar ese ciclo es donde la automatización autohospedada normalmente falla, así que quiero ser específico sobre lo que sí y no construí.

Detectar, proponer, aprobar, actuar

Cada hallazgo del analista se mapea a una propuesta tipada:

Hallazgo	Propuesta	Qué hace la aprobación
decisión obsoleta	borrador de supersesión	registra una tarea de redacción
sujeto no documentado	tarea de documentación	registra una tarea de docs
desviación declarada vs observada	reconciliación	registra una tarea de colocación
hecho contradicho	reconciliación de hechos	inicia una cola de corrección que ella misma está controlada por separado

Esa última fila es la interesante. Una reconciliación de hechos aprobada no cambia un hecho. Gana el derecho de ser propuesta como cambio de hecho, que luego un humano vuelve a aprobar. Dos filtros antes de que una creencia almacenada se mueva.

Tres restricciones que lo hacen seguro

Fundamentado o descartado. Una propuesta sin cita está bloqueada y contabilizada, nunca se propone. La misma regla que en todo el sistema.

Propagación limitada, particionado por co-ubicación. Como máximo una propuesta por sujeto y tipo. Sin esto, un solo problema en un host se multiplica en una propuesta por cada servicio que esté ahí, y terminas con una cola de cien elementos describiendo una sola cosa. El tope es 25.

Dos etapas, nunca auto-aplicado. La detección es solo lectura. El encolado agrega a un archivo pendiente ignorado por git. Solo una aprobación explícita con aplicación escribe en la capa comprometida — y la capa comprometida es una lista de tareas de conocimiento, no infraestructura.

La característica definitoria del ejecutor

El último paso convierte una propuesta aprobada en una rama, un commit y un pull request en borrador que nunca se fusiona. Esa no es una limitación que planee quitar; es el producto.

Está deshabilitado por defecto detrás de una bandera de entorno, se niega a sobrescribir archivos existentes, solo agrega un nuevo archivo markdown, y nunca toca archivos compose, contenedores ni hosts. Toda la cadena desde la detección hasta el cambio fusionado pasa por cuatro filtros humanos.

Lo probé en vivo una vez, con un hallazgo real sobre un repositorio de respaldos. Abrió el PR. No fusionó el PR. Ambas mitades de esa frase eran la prueba.

Por qué no dejar que lo aplique

Porque el valor del ciclo es que nota, y notar es barato de verificar mientras que actuar es caro de deshacer. El cuello de botella en mi homelab nunca fue mi capacidad de hacer cambios. Era saber qué cambios se necesitaban. Automatizar la mitad en la que soy bueno, para ahorrar en la mitad en la que no, habría sido el intercambio equivocado.

Un sistema que me entrega de forma confiable cinco tareas correctas, citadas y revisables con un clic cada mañana ya me da la mayor parte del valor que promete la autonomía total, con solo una fracción del radio de impacto.