Sesiones remotas, rutinas asíncronas y proyecto final
Trabajar en remoto o por programación desplaza el control en el tiempo. Para seguir siendo fiable, la rutina debe saber quién la posee, dónde conserva el estado, cuándo detenerse y qué acciones esperan una decisión humana.
Qué trabajarás, paso a paso
El estado de una sesión
Cuando una sesión dura más que tu presencia delante de la pantalla, su estado no puede vivir solo en la conversación. Si la conexión se cae o vuelves al día siguiente, debes distinguir lo que se ha hecho, lo que solo se ha propuesto y lo que nunca llegó a arrancar.
Primero distingue el entorno: Remote Control sigue ejecutando las herramientas en tu máquina local; una sesión cloud, en cambio, se ejecuta sobre infraestructura remota. En ambos casos, una sesión recuperable registra la entrada, commit o snapshot de partida, el trabajo realizado, los artefactos, los errores y el siguiente paso.
Asigna un propietario humano y un límite temporal. «Trabaja hasta que termines» no es una stop condition; «analiza cinco dependencias y produce un informe en treinta minutos» sí lo es.
Una sesión remota ha analizado dependencias durante veinte minutos y luego ha perdido la conexión. No sabes si ha modificado archivos o solo ha producido un informe parcial.
- Lee el checkpoint con run-id, commit inicial y fase alcanzada; no te fíes del último mensaje visible.
- Compara el estado Git actual con el snapshot e identifica cada archivo modificado o artefacto creado.
- Verifica qué controles tienen un resultado registrado y considera no ejecutados los que no tengan salida ni exit code.
- Reanuda desde la primera fase incompleta con los mismos límites, o cierra la sesión si el repositorio ya no coincide con el punto de partida.
Resultado: La reanudación nace de datos persistentes. No duplicas trabajo ya probado ni atribuyes a la sesión actividades que no hayan dejado evidencia.
Programaciones idempotentes
Un scheduler puede arrancar la misma rutina más de una vez, incluso cuando has escrito «cada noche». Retry, timeout y cambios de horario vuelven normal la repetición. La idempotencia sirve justo aquí: la segunda ejecución no debe crear un segundo efecto como si fuera la primera.
Una rutina diaria puede arrancar dos veces por retry, cambio de horario o error del servicio. Usa un identificador que incluya el periodo lógico y la zona horaria, por ejemplo `review-2026-08-08-Asia-Singapore`, y comprueba si el informe de ese periodo ya existe antes de producir otro.
Los retry deben estar limitados y espaciados. Repetir inmediatamente una operación que falla por indisponibilidad remota puede agravar el problema y consumir recursos sin aportar información nueva.
El control de dependencias arranca a las 02:00, entra en timeout durante la notificación y el scheduler lo relanza. El informe ya se había guardado.
- Calcula el run-id con fecha, repositorio y versión de la rutina antes de cualquier escritura.
- Guarda el informe usando ese run-id como clave y registra por separado el estado de la notificación.
- En el retry, detecta el informe existente y omite análisis y escritura; reanuda solo la notificación que sigue incompleta.
- Después del número máximo de intentos, conserva el error y envía un aviso distinto, sin regenerar el informe.
Resultado: Obtienes un único artefacto didáctico y un rastro claro de los intentos de entrega. El retry completa lo que falta sin repetir lo que ya ha salido bien.
Control remoto y checkpoints humanos
Controlar una sesión desde el teléfono o continuar desde el navegador cambia el canal, no cambia la responsabilidad. Un botón remoto puede ser cómodo, pero no vuelve automáticamente segura la acción que pone en marcha. Antes de aprobar, aún debes entender estado, prueba y efecto.
Canales, control remoto e integraciones de navegador son superficies para enviar instrucciones o continuar una sesión. La interfaz remota no transfiere mágicamente filesystem ni credenciales: siempre importan la máquina o el cloud que ejecutan las herramientas. Leer un informe puede ser automático; publicar o modificar sistemas externos requiere un permiso apropiado.
Una notificación útil contiene estado, prueba, decisión solicitada y plazo. No debe obligar al usuario a reconstruir toda la sesión para entender si debe aprobar.
La rutina ha preparado una actualización de dependencia y pide desde el canal remoto permiso para abrir una pull request.
- Incluye run-id, repositorio y commit de partida, para que el usuario sepa exactamente qué trabajo está evaluando.
- Resume diff, pruebas ejecutadas y riesgo residual con enlaces o artefactos verificables, no con un simple «todo ok».
- Describe el efecto solicitado: crear una pull request sobre una rama precisa, sin merge y sin publicación.
- Añade vencimiento y comportamiento en ausencia de respuesta: ninguna acción, checkpoint conservado y sesión cerrada.
Resultado: El usuario puede aprobar o rechazar desde el canal remoto sin reconstruir el contexto y sin conceder una autorización más amplia que la solicitada.
Capstone: sistema completo, no autonomía total
El proyecto final no sirve para mostrar cuántas herramientas consigues encender. Sirve para demostrar que sabes construir un flujo comprensible incluso cuando algo falla. Un sistema maduro no es el que lo hace todo solo: es el que deja claras autoridad, estado y prueba en cada paso.
El workflow final usa contexto estable, una skill de review, un enlace de solo lectura, hooks locales, agentes con propiedad y una pipeline estructurada. Cada componente resuelve un límite específico; ninguno recibe poder solo porque exista.
Al final debes poder abrir el informe y responder en dos minutos: ¿quién autorizó qué? ¿Qué prueba se superó? ¿Desde dónde retomo si el servicio remoto no responde? Si no sabes responder, el workflow todavía no está listo. La entrega separa implementado, verificado y no verificado y conserva suficiente evidencia para reanudar.
- Crea un run-id y guarda el snapshot inicial del repositorio.
- Carga contexto estable y planifica una rutina con stop condition.
- Delega análisis independientes con propiedad y accesos mínimos.
- Aplica hooks, esquema JSON, lint y tests como gates recuperables.
- Guarda un checkpoint y pide aprobación antes de cada efecto externo.
- Entrega estado, pruebas, límites e instrucciones precisas para la reanudación.
Task Notes debe añadir el campo prioridad, actualizar las pruebas, producir una review y preparar una entrega remota sin publicar automáticamente.
- Crea un snapshot Git, escribe el objetivo en el contexto estable y define criterios visibles: prioridad guardada, mostrada y cubierta por las pruebas.
- Usa una fuente MCP en solo lectura para la documentación, un Explorer para el mapa y ownership separados para parser y pruebas.
- Aplica hooks locales a secretos y formato; luego ejecuta la pipeline con esquema JSON, lint, pruebas y parada en el primer gate fallido.
- Guarda informe y checkpoint. Pide aprobación solo para crear una pull request; deja merge y deploy fuera de la autoridad del flujo.
Resultado: El proyecto produce código y pruebas, pero sobre todo una cadena legible de decisiones. Otra persona puede entender qué ha pasado, repetir los controles y retomar sin confiar en la memoria de la sesión.
Revisión nocturna sin auto-merge
Task Notes controla dependencias cada noche, pero deja la última decisión al usuario.
Trigger: 02:00, run-id = fecha + repositorio
Lee: dependencias y advisories, solo lectura
Analiza: máximo 5 actualizaciones
Checkpoint: guarda informe y log
Notifica: riesgo, pruebas, decisión solicitada
Gate: ningún branch, push o merge sin aprobación