Las tareas son la unidad de ejecucion de OPS Center. La cola muestra el trabajo activo y evita que lo completado contamine la operativa diaria.
Estados visibles:
inbox: entrada sin decidir.next: lista, planificada o pendiente de lanzamiento manual.doing: trabajo activo o seguimiento.waiting: esperando input externo.review: resultado listo para validar.done: completada.archived: fuera del flujo activo, conservada por historico.Estados tecnicos de automatismo:
queued: esperando worker.dispatching: worker ejecutando.queued y dispatching pueden verse en diagnostico, pero no deben tratarse como columnas principales del usuario.
done significa trabajo completado.
archived significa fuera de flujo. Se usa para duplicados, tareas obsoletas, ideas descartadas, instancias recurrentes descartadas o tareas migradas a otra tarea. Archivar conserva contexto sin contar el trabajo como completado.
Archivar un proyecto no es borrar. Un proyecto archivado queda guardado con sus tareas, planes, specs, tiempo, targets y decisiones, pero sale de la lista activa para reducir ruido cuando esta parado, cancelado o en espera larga.
Borrar un proyecto es definitivo y solo debe estar disponible para proyectos vacios creados por error. Si existe cualquier tarea, plan, scope, recurrente, target o skill asociada, el sistema debe bloquear el borrado y recomendar archivar.
Una alerta no debe ser una preferencia personal ni una nota de trabajo. Eso debe vivir como tarea.
Las alertas quedan reservadas para senales generadas por el sistema: dispatch caido, recurrente fallida, credencial bloqueada, worker sin runtime, integracion rota o comprobacion critica que necesita atencion operativa. Cuando una alerta requiere decision, seguimiento o ejecucion humana, se pasa a tarea y la alerta queda reconocida o resuelta.
Dispatch now encola manualmente una tarea automatizable. Es util cuando una tarea automatica se crea en next porque debe revisarse, planificarse o lanzarse a mano.
No es lo mismo que mover a doing. Solo dispatch cambia una tarea a queued.
Cuando una tarea automatizable esta bloqueada por falta de input, la accion principal debe permitir:
Debe existir tambien una accion secundaria para guardar sin ejecutar y otra para guardar una nota sin cambiar estado.
Un comentario normal no debe desbloquear una tarea. Si comentar y desbloquear fueran la misma accion, el flujo se vuelve ambiguo: el usuario no sabe si ha contestado, si ha relanzado o si solo ha dejado una aclaracion. OPS debe separar esos tres caminos.
La puntuacion debe ayudar a decidir, no sustituir criterio humano. Los campos base son:
Cada tarea puede ejecutarse como:
Las tareas automaticas deben tener perfil, agente, credenciales y target cuando aplique.
Las tareas de IA pueden ejecutarse de dos formas:
Dispatch now / dispatcher: OPS encola y un worker ejecuta.El flujo de escritorio es valido siempre que la tarea deje la misma trazabilidad que el dispatcher: comentario final, evidencia, tiempo y estado correcto.
Para tareas reclamables por agentes, usa el bloque Instrucciones para agente en la descripcion. La UI lo inserta con + Instrucciones agente y debe indicar agente, modelo, contexto, criterio de terminado, registro obligatorio y fallback si hay bloqueo.
Ademas, cada tarea puede tener un execution_contract estructurado. Ese contrato vive separado de la descripcion y se edita desde el detalle de tarea. Si esta vacio, la tarea mantiene el comportamiento anterior.
El contrato efectivo puede heredar datos de workspace, perfil, plantilla y tarea. Si contiene preflight_required=true, OPS no debe enviar la tarea a dispatch si faltan campos minimos como agente/modelo preferente, criterios de aceptacion o fallback de bloqueo.
Una tarea ejecutada por IA no debe marcarse como done sin evidencia visible:
El cierre forzado queda reservado para operadores autorizados.