Commits
Borradores protegidos y actualizador a prueba
Un JSON incompleto de IA corrompió un borrador: parser más duro y validación
Día de mantenimiento fino: un borrador corrompido por una respuesta de IA y la decisión de cómo se actualizará el producto en los clientes.
Una respuesta incompleta corrompió un borrador
Una respuesta de MiniMax llegó como JSON incompleto, degenerando al final. El fallback de reescritura la aceptó como Markdown y el pulido confirmó el contenido antes de validar la respuesta siguiente. Resultado: un borrador parcial asociado a una ejecución fallida.
El arreglo es doble: el parser ahora rechaza envoltorios JSON incompletos en lugar de guardarlos como contenido, y el pulido calcula y valida reescritura y metadatos antes de aplicar ningún cambio. Borrador corrupto eliminado, ejecución reintentada correctamente y un artículo Lorem ipsum de prueba retirado de la programación.
Actualizaciones sin acceso al repositorio
La decisión del día: separar panel, API y frontend público para poder actualizar solo el núcleo del producto. Las releases se distribuyen como imágenes privadas e inmutables, y un actualizador restringido del host hará backup, migraciones, health checks y rollback sin sustituir nunca los datos, los medios ni el frontend personalizado del cliente.
Del documento al código
En unas horas la decisión ya tiene base técnica: objetivo de instalador para el cliente con el frontend base incluido, demonio actualizador conectado a la API, clave de verificación incluida en el paquete, manifiesto de actualización firmado y socket del actualizador montado en la API del cliente. Por los caminos, los fixes de siempre: sembrar el administrador inicial del cliente, migración idempotente del validador de fuentes, rutas compose resueltas y el propietario de la imagen GHCR aprobado para el publish.
Prueba de fuego: actualizador y limpieza protegidos
La tarde fue de pruebas de extremo a extremo. Nuevo fclean con root y confirmación exacta del dominio: sin escribir el dominio exacto, no borra nada. En el piloto se verificó toda la cadena: backup, migración, reinicio, rollback y conservación de la web pública del cliente. Mientras tanto, cinco fixes de cadena fina: propietario de la imagen aprobado para el publish, manifiesto firmado publicado, socket montado, metadatos compose preservados durante las actualizaciones y credenciales GHCR llegando al servicio systemd. El panel ya muestra su propia versión.
El botón que no llamaba a nada
El agente añadió detección, confirmación y progreso al resumen del panel. El botón se veía, pero al pulsar no salía ningún POST. Primero culpó al diálogo nativo y lo sustituyó por una confirmación visible; seguía sin funcionar. La causa real: onClick={() => void apply} en lugar de invocar apply(). Corregida la llamada y con los errores visibles en el panel. La lección queda apuntada: comprueba la petición real y el callback antes de publicar un arreglo de UX.
El cliente nunca ve el repositorio, pero una versión nueva llega tan controlada como un push: firmada, verificada y con rollback.