Actualización de ThreadCells
Una actualización es una promoción controlada de candidato con un rollback verificado, no una sobrescritura in situ de los archivos que casualmente se estén ejecutando.
Antes de la actualización
- Lea las notas de release y Limitaciones.
- Confirme la salud actual y las identidades de compilación activa/de rollback.
- Deje que las operaciones críticas de proveedor/pesadas alcancen un límite seguro.
- Inspeccione los flujos de trabajo abiertos y los resultados entregados.
- Cree una copia de seguridad coherente y ejecute comprobaciones de integridad de la base de datos.
- Conserve el candidato actual como rollback.
Compilar y verificar
Desde el commit de código fuente previsto:
python3 scripts/build_local_candidate.py --output "$PWD/threadcells-candidate"
candidate="$PWD/threadcells-candidate/threadcells-0.3.4a0-local"
python3 scripts/verify_local_candidate.py --candidate "$candidate"No promocione si la identidad del candidato difiere del commit revisado o si fallan las comprobaciones de docs/Web/compilación.
Preparar y promocionar
Use las herramientas canónicas de despliegue local para preparar el candidato sin cambiar el puntero activo. Verifique los archivos preparados, después promocione de forma atómica y reinicie solo los servicios ThreadCells que consumen el release.
Resultado esperado: Settings → About, el pie de página de Docs y los metadatos de release identifican la misma revisión de candidato.
Comprobaciones posteriores a la actualización
curl -fsS http://127.0.0.1:9889/health- Abra Home e inspeccione el estado de capacidad/disco.
- Abra Agents/Flows existentes y confirme que se mantienen las relaciones duraderas.
- Compare la disponibilidad de proveedores en Settings y Spawn.
- Confirme que la autorización de operador está configurada y que las mutaciones protegidas siguen bloqueadas hasta desbloquear.
- Abra Statistics y confirme que una actualización/reinicio no duplica el uso.
- Abra rutas de Docs y verifique la identidad de la compilación empaquetada.
- Compruebe el streaming/reconexión de terminal.
- Verifique que el manifiesto de PWA y el service worker no almacenan solicitudes dinámicas en caché.
- Abra Settings → Telegram y confirme su estado seguro de configuración; si las credenciales nativas ya estaban configuradas, ejecute las comprobaciones explícitas de conexión y mensaje de prueba.
- Para un agente abierto que atraviese la promoción, confirme que cualquier reinicialización de conexión de control se complete una vez y que continúe su mismo flujo de trabajo duradero sin una reactivación del propietario ni un hijo/efecto duplicado.
Reparaciones históricas
Una actualización puede incluir una reparación de datos limitada. Ejecútela solo cuando la evidencia de origen sea determinista, manténgala idempotente y registre los recuentos antes/después. La telemetría de proveedor ausente debe seguir ausente; nunca invente uso histórico.
Rollback
Si la aceptación falla de forma material:
- conserve el candidato fallido y los registros seguros pertinentes;
- cambie el puntero activo canónico al candidato de rollback verificado;
- reinicie solo los servicios necesarios;
- verifique la compilación de rollback y las superficies principales;
- restaure la base de datos previa a la actualización solo si la compatibilidad de esquema/datos lo requiere.
No use Git reset destructivo ni elimine evidencia de runtime más reciente para simular un rollback.
Un Full Cleanup confirmado explícitamente es la excepción a la retención normal de releases locales: elimina todas las releases inactivas demostradas, incluido el rollback seleccionado durante el despliegue, y deja solo la release activa e inmutable. No lo ejecute durante la aceptación de una actualización ni mientras se esté ejecutando algún agente. Después de un Full Cleanup correcto, restaure la disponibilidad de rollback solo mediante la preparación de otra release verificada e inmutable; nunca la reconstruya a partir de un directorio no verificado.
Consulte Despliegue local y Copia de seguridad y restauración.