Verificacion Operativa Diaria

Objetivo

Empezar y cerrar el dia sabiendo que OPS esta en un estado fiable. Esta guia reduce sustos: tareas que no se lanzaron, dispatch bloqueado, recurrentes duplicadas, trabajos cerrados sin tiempo o cambios sin documentar.

La verificacion diaria no tiene que ser larga. Debe ser constante.

Cuanto tiempo deberia llevar

Para un workspace pequeno:

• revision rapida: 5 a 10 minutos;
• revision completa: 15 a 25 minutos;
• revision con incidencias: lo que requiera corregir y documentar.

Si la verificacion diaria lleva siempre demasiado, probablemente hay ruido en tareas, recurrentes o estados.

Inicio del dia

1. Confirmar workspace activo

Por que:

• Evita revisar tareas del entorno equivocado.
• Evita crear trabajo en un workspace que no corresponde.

Comprueba:

• workspace visible;
• proyectos esperados;
• usuario/rol correcto si vas a operar.

2. Revisar waiting

Por que:

• waiting deberia representar decisiones o bloqueos reales.
• Si se acumula, el sistema esta pidiendo atencion humana.

Mira:

• que decision falta;
• quien debe decidir;
• si ya puedes desbloquear;
• si hay tareas antiguas que deberian cerrarse o archivarse.

3. Revisar review

Por que:

• review contiene trabajo terminado pero no validado.
• Si se ignora, parece que el sistema avanza pero nada se cierra.

Mira:

• evidencia;
• output IA;
• cambios de codigo/documentacion;
• si falta tiempo;
• si puede cerrarse o debe volver a waiting.

4. Revisar recurrentes de hoy

Por que:

• Las recurrentes son fuente comun de duplicados o ausencias.
• Una recurrente que no lanza cuando debe rompe confianza en el sistema.

Comprueba:

• que tareas debian lanzarse hoy;
• si se crearon;
• a que hora;
• si tienen fecha de ejecucion;
• si quedaron en el estado esperado;
• si no duplicaron una tarea activa.
• si hay alertas recurring-watchdog o dispatch-watchdog.

5. Ejecutar Runtime check

Por que:

• Antes de enviar trabajo IA, hay que saber si runtime y credenciales estan sanos.
• Evita reintentos inutiles.

Mira:

• runtime disponible;
• blockers;
• worker fresco;
• credenciales activas;
• modelos compatibles.

6. Revisar dispatching antiguo

Por que:

• Una tarea mucho tiempo en dispatching puede estar colgada.
• Si se ignora, bloquea confianza en dispatch.

Acciones:

• revisar output;
• reconciliar si hay watchdog;
• mover a waiting si fallo runtime;
• relanzar solo despues de corregir causa.

7. Preparar plan del dia

Por que:

• Evita empezar por lo ultimo que hizo ruido.
• Ayuda a separar trabajo humano, IA y revision.

Salida esperada:

• tareas prioritarias;
• bloqueos claros;
• recurrentes revisadas;
• dispatch en estado seguro.

Durante el dia

Buenas practicas:

• Mueve tareas a doing cuando las trabajas.
• Registra comentarios cuando tomas decisiones.
• Si una tarea cambia de alcance, actualiza descripcion o crea otra.
• Si una IA genera output, revisalo antes de cerrar.
• Si algo falla dos veces, corrige la causa, no solo reintentes.

Cierre del dia

1. Cerrar lo terminado

Cierra solo si:

• esta verificado;
• tiene tiempo;
• no quedan decisiones pendientes;
• si cambio sistema, hay doc o nota.

2. Registrar tiempo

Por que:

• El resumen por proyecto depende de esto.
• Sin tiempo, no se ve el coste real.

Regla:

• Si una tarea consumio tiempo real, registralo antes de cerrarla.

3. Bloquear lo pendiente

Pasa a waiting si:

• falta decision del usuario;
• falta credencial;
• falta revisar contenido;
• falta input externo;
• no conviene que dispatch lo ejecute.

4. Crear siguiente tarea

Si queda un siguiente paso claro, crealo.

Por que:

• Evita reconstruir contexto al dia siguiente.
• Permite que el proyecto siga vivo sin depender de memoria.

5. Actualizar documentacion

Actualiza docs si:

• cambio comportamiento;
• cambio flujo;
• cambio seguridad;
• se corrigio un incidente;
• se aprendio una regla operativa.

Senales de alarma

• Dispatch on con runtime bloqueado.
• Tareas IA cerradas sin evidencia.
• Muchas tareas sin proyecto.
• Recurrentes duplicadas.
• Recurrentes que no lanzan y nadie sabe por que.
• Skills o subagentes importados sin auditoria.
• Cambios de credenciales sin comentario.
• Produccion desplegada sin verificacion.
• Mucho trabajo cerrado sin tiempo.

Comandos utiles del asistente

• runtime check
• resume tarea 700
• cierra tarea 700 20 min nota: verificado
• bloquea tarea 700 nota: pendiente de decision
• anade 15 min a tarea 700 nota: revision
• automatizaciones
• skills
• subagentes

El asistente debe ayudar a operar, no saltarse criterios. Si la accion es sensible, debe pedir confirmacion.

Resultado esperado

Al terminar la revision diaria deberias saber:

• que se ejecuta hoy;
• que esta bloqueado;
• que espera review;
• que recurrentes funcionaron;
• que proyectos acumularon horas;
• que riesgos existen antes de tocar produccion;
• que debe documentarse.