# Procedimiento de conmutación y retorno — modelo a adaptar

El caso Capordia es un equipo que procesa lotes independientes. El objetivo
es retomar los trabajos identificados sin perder su aceptación. Una
interrupción planificada es posible. La duración admisible, los criterios de
calidad y las responsabilidades se deciden antes de la ventana de migración.

## 1. Designar las responsabilidades

| Rol | Responsabilidad | Prueba que conservar |
|---|---|---|
| Piloto de conmutación | Autoriza la detención, el cambio de autoridad y la reanudación | Decisión y hora UTC |
| Responsable de los datos | Fija las entradas, controla la copia y el inventario | Manifiesto versionado y huellas |
| Responsable del procesamiento | Detiene el productor, clasifica los intentos | Registro de lotes y diario del proceso |
| Responsable de recepción | Compara salidas y criterios acordados | Resultados, rechazos y acuerdo de recepción |

Un equipo pequeño puede acumular roles, pero la persona que pronuncia
la aceptación y la que sabe detener la antigua autoridad deben ser
identificables. El modelo CSV proporcionado no impone ningún nombre de persona.

## 2. Establecer la referencia antes de copiar

Atribuir a cada lote un identificador estable y una versión de entrada.
Registrar su ruta, su huella, el procesamiento exacto y el criterio
de aceptación. Distinguir un intento lanzado de un resultado aceptado.
Conservar los parámetros y dependencias necesarios para la reanudación, incluidos
los estados de cálculo que su software exija. Un nombre de archivo `final`
no basta para probar una aceptación.

En el ejercicio, ocho lotes representan 48 cupones ficticios. La aceptación
se basa en un resultado determinista en enteros; no es un modelo de
checkpoint GPU. Las ocho salidas de referencia se calculan antes del corte.

## 3. Detener la llegada de nuevos trabajos

Cerrar la admisión de nuevos lotes y anotar el último identificador admitido.
Detener el worker o esperar la frontera de reanudación prevista. Confirmar
que ningún proceso de la máquina antigua puede aún aceptar salidas.
Clasificar el registro: terminado, en curso, por reanudar. Preservar las trazas
de un lote ambiguo en lugar de declararlo terminado por suposición.

En el ejercicio, el corte en LOT-004 da 3 / 1 / 4. Un relanzamiento sin
reconciliación se rechaza. El registro y sus resultados permanecen juntos.

## 4. Copiar, controlar, cambiar de autoridad

El destino debe disponer del conjunto fijado, del estado necesario y del programa
compatible. Verificar las huellas y el inventario desde el destino.
Bloquear la reanudación si falta una entrada, si el manifiesto ha cambiado o si un
resultado ya no corresponde a su huella y a la regla de aceptación.

En este ejercicio, `basculer` cierra primero el origen, luego copia los
archivos tras el cierre de las conexiones. El programa abre el destino a la
producción solo después del control. No imitar una copia en caliente de una
base activa fuera de este procedimiento. Un fallo deja el origen detenido.

En un sistema real, el cierre de un archivo local no impide que una máquina antigua
aislada siga funcionando. Un derecho de publicación exclusivo debe imponerse
mediante el sistema que recibe los resultados, con rechazo de los antiguos derechos
y prueba de ese rechazo. El presente programa no proporciona esta protección.

## 5. Reconciliar y recepcionar

Verificar que todos los resultados terminados están presentes y son aceptables.
Los intentos en curso sin aceptación se devuelven a por reanudar tras
confirmar la detención de su antiguo productor. Hacer una reanudación limitada
antes de reabrir la admisión. Contabilizar los lotes esperados, los identificadores
únicos aceptados, los errores y las reanudaciones. Registrar una aceptación
distinta del simple fin del proceso.

En el programa: `preparer-reprise` transforma el único lote en curso en lote
por reanudar. `executer` no recalcula los tres lotes terminados. El control
final exige ocho salidas aceptadas e idénticas a la referencia. LOT-004 tiene
dos intentos, pero una sola salida aceptada.

## 6. Activar el retorno ante una señal observable

| Señal | Decisión propuesta para este ejercicio |
|---|---|
| Huella de entrada diferente | Bloquear antes del procesamiento; recuperar la versión congelada |
| Resultado faltante o alterado | Bloquear la recepción; examinar el lote y el estado |
| Dos autoridades posibles | Detener la reanudación; establecer una autoridad única |
| Programa incapaz de reanudar | Mantener la admisión cerrada y transferir el estado reciente al entorno compatible |
| Plazo de ventana superado | Aplicar la decisión y el límite fijados por el equipo antes de la conmutación |

Si el destino ya ha aceptado nuevos resultados, volver a la copia antigua
de la fuente perdería esas aceptaciones. Congelar el destino, exportar su estado
reciente, verificarlo y transferirlo a una nueva ubicación de retorno.
Reconciliar los resultados antes de relanzar. En presencia de efectos externos,
su inventario forma parte del retorno; este ejercicio no produce ninguno.

```text
python exercice.py basculer --source manuel/cible --destination manuel/retour --proprietaire atelier-retour
python exercice.py preparer-reprise --dossier manuel/retour
python exercice.py executer --dossier manuel/retour
python exercice.py comparer --reference manuel/reference --candidat manuel/retour
```

Tras esta operación, `manuel/source` y `manuel/cible` quedan cerrados. Solo
`manuel/retour` puede trabajar. Si la copia falla o si el control rechaza
un resultado, conservar las pruebas y no desbloquear dos productores.

## 7. Cerrar la migración

Conservar el manifiesto, el registro antes/después, las huellas, los resultados de control,
la versión del programa, la decisión de reanudación y la decisión de retorno eventual.
No eliminar la copia antigua hasta después del periodo de conservación elegido
por el equipo. El ejercicio no elimina ninguna carpeta; sus recursos son
ficticios y pueden archivarse con el informe.