Crear Tareas y Ejecutarlas

Objetivo

Crear tareas que puedan ejecutarse, verificarse y cerrarse sin ambiguedad. En OPS, la tarea es la unidad minima de trabajo: si esta bien escrita, el sistema puede priorizarla, ejecutarla, medirla y documentarla.

Una tarea mala no solo molesta en la UI. Tambien rompe automatizaciones, resumenes por proyecto y auditoria de IA.

Tipos de tarea

Tarea humana:

la ejecuta una persona;
puede usar el asistente para comentar, cerrar o registrar tiempo;
requiere criterio claro para saber cuando esta terminada.

Tarea IA interactiva:

se prepara con perfil/subagente y skills;
puede requerir confirmacion humana antes de mutar datos;
suele terminar en review o waiting si hay decision pendiente.

Tarea IA automatica:

entra en queued;
la reclama dispatch;
debe tener instrucciones muy completas;
no debe usarse para acciones sensibles sin gate.

Tarea recurrente:

nace desde una plantilla;
debe incluir fecha de ejecucion;
debe evitar duplicados;
debe tener proyecto y comportamiento esperado.

Paso 1: escribir titulo accionable

Un buen titulo dice que hay que hacer.

Ejemplos buenos:

"Documentar guia how-to de tareas recurrentes"
"Verificar runtime OpenCode antes de dispatch"
"Proponer temas LinkedIn para la semana del 8 de mayo"

Ejemplos malos:

"Revisar"
"Cosas de IA"
"Pendiente"

Por que importa:

El titulo aparece en cola, busqueda, Kanban y resumenes.
Si no se entiende en una linea, seguramente falta contexto.

Anatomia de una buena tarea

Una buena tarea tiene cinco piezas:

Accion: que hay que hacer.
Objeto: sobre que se actua.
Contexto: en que proyecto, pantalla, repo, cliente o flujo.
Criterio: como se acepta.
Limite: que no debe hacer o cuando debe parar.

Ejemplo pobre:

"Mirar runner".

Ejemplo bueno:

"Verificar runner local Kodavio antes de poner tareas en cola".

Descripcion:

"Comprobar heartbeat reciente, ruta permitida, agente Codex y modelo operativo. No mover tareas a queued si el doctor no pasa. Dejar evidencia y registrar tiempo."

Esta segunda tarea permite actuar sin preguntar de nuevo.

Campos recomendados

Para una tarea normal:

Titulo.
Proyecto.
Estado inicial.
Descripcion.
Criterios de aceptacion.
Prueba o evidencia.
Estimacion.
Responsable o perfil.
Tags utiles.

Para una tarea automatizable, anade:

execution mode;
agente;
modelo;
skills;
target;
execution_contract;
dependencias;
fallback de bloqueo.

Para una tarea sensible, anade:

spec aprobada;
backup o rollback;
gate humano;
entorno;
criterio de no ejecucion;
evidencia post-cambio.

Como escribir el titulo

Formato recomendado:

Verbo + objeto + contexto

Buenos verbos:

Crear
Revisar
Corregir
Verificar
Importar
Documentar
Publicar
Preparar
Migrar
Bloquear
Archivar

Evita verbos vagos:

Mirar
Tema
Cosas
Gestionar
Mejorar

Mejorar puede usarse si despues concreta el resultado:

Malo: "Mejorar proyectos".
Bueno: "Mejorar busqueda de proyectos por actividad reciente".

Como escribir la descripcion

La descripcion debe explicar:

por que existe la tarea;
que debe cambiar;
que datos o documentos usar;
donde esta el trabajo;
que no debe tocarse;
que salida se espera.

Plantilla corta:


Contexto:

- ...



Objetivo:

- ...



Alcance:

- ...



No hacer:

- ...



Evidencia esperada:

- ...

Si la tarea la ejecutara IA, escribe como si no pudiera preguntarte durante la ejecucion.

Paso 2: asignar proyecto

Asigna proyecto al crear la tarea o antes de cerrarla.

Por que importa:

Las horas ejecutadas por proyecto dependen de esta relacion.
Un proyecto sin tareas no refleja actividad.
Una tarea sin proyecto es dificil de recuperar meses despues.

Regla practica:

Si consume tiempo o cambia el sistema, debe tener proyecto.
Si es una nota temporal, puede estar en inbox, pero no deberia cerrarse sin contexto.

Paso 3: elegir estado inicial

Estados habituales:

inbox: entrada sin clasificar.
next: lista para trabajar.
queued: lista para dispatch automatico.
dispatching: reclamada por worker.
doing: en ejecucion humana.
waiting: bloqueada o pendiente de decision.
review: hecha, pero pendiente de validacion.
done: cerrada y verificada.
archived: fuera de flujo operativo.

Como elegir:

Si falta informacion, usa inbox o waiting.
Si esta lista para humano, usa next.
Si esta lista para IA automatica y todo esta preparado, usa queued.
Si requiere validacion posterior, usa review.

Paso 4: describir criterio de terminado

Incluye que significa "hecho".

Ejemplos:

"Build pasa y la ruta aparece en help."
"La tarea queda bloqueada hasta que el usuario elija tema."
"Se registra tiempo y se actualiza la documentacion."
"No se despliega produccion sin confirmacion."

Por que importa:

Sin criterio, el ejecutor decide por intuicion.
La IA tiende a cerrar demasiado pronto si no se le dice cuando parar.

Criterios de aceptacion buenos

Un criterio de aceptacion debe ser verificable. Evita criterios que solo expresan deseo.

Malos criterios:

"Que quede bien."
"Que funcione."
"Que sea mas claro."
"Que no de problemas."

Buenos criterios:

"La pagina publica responde 200."
"La tarea queda en review con salida y tiempo registrados."
"No hay tareas importadas en queued tras el import."
"El smoke final pasa sin warnings."
"La UI muestra los chips y al hacer click filtran la lista."

Regla practica:

Si no puedes comprobarlo con una revision, consulta, comando, captura o decision humana, no es criterio de aceptacion. Es intencion.

Pruebas y evidencias

Cada tarea debe decir que evidencia espera.

Ejemplos por tipo:

Docs: enlace, build, verificacion de rutas.
UI: captura, smoke frontend, navegacion manual.
Backend: test, endpoint, log sin error.
Datos: conteo antes/despues, backup, consulta.
Runner local: doctor, heartbeat, ruta permitida, tarea piloto.
Marketing/contenido: brief, fuente, aprobacion, publicacion o borrador.
Deploy: health, smoke, rollback documentado.

Una tarea puede cerrar en review si la evidencia existe pero necesita validacion humana.

Estimacion de tiempo

La estimacion no tiene que ser perfecta. Sirve para decidir tamano, prioridad y coste real.

Guia rapida:

15 min: verificacion simple o ajuste pequeno.
30 min: doc corta, investigacion acotada, configuracion simple.
60-90 min: cambio normal con verificacion.
2-4 h: bloque de implementacion con pruebas.
Mas de 4 h: dividir o convertir en fase.

Aunque no se facture, registra el tiempo real al cerrar. Si la diferencia con la estimacion es grande, deja nota. Ese aprendizaje mejora planes futuros.

Paso 4.1: decidir si necesita spec, brief o triage

Usa spec completa si la tarea toca codigo, infraestructura, datos, credenciales, deploy, produccion, seguridad, cliente, runner local, dispatch, recurrentes, beta o una promesa publica.

Usa brief ligero si es contenido, comunidad, newsletter, social, marketing recurrente o trabajo editorial.

Usa triage si es historica, duplicada, de prueba, pertenece a otro proyecto, esta dormida o requiere decision comercial antes de trabajar.

Regla practica: si una tarea puede romper algo, cambiar datos o afectar a un cliente, necesita spec. Si solo ayuda a producir contenido, necesita brief. Si no sabemos si merece existir, necesita triage.

Buenas specs de tarea

Una spec no debe ser literatura. Debe reducir incertidumbre.

Debe contener:

resumen;
contexto;
alcance;
no alcance;
criterios de aceptacion;
pasos previstos;
pruebas;
riesgos;
fallback o bloqueo;
notas de seguridad.

Para tareas automaticas, la spec debe decir:

que agente puede ejecutarla;
que modelo usar;
que target o repo tocar;
que comandos o pruebas ejecutar;
que hacer si falta algo;
que salida debe entregar.

La spec puede ser breve si la tarea es simple. Lo importante es que quite ambiguedad.

Paso 5: crear tarea IA

Ademas de los campos normales, define:

perfil/subagente;
runtime o modelo si aplica;
execution mode;
skills requeridos;
instrucciones completas;
limites de actuacion;
estado final esperado;
execution_contract si la tarea debe ejecutarse de forma autonoma o formar parte de una cadena.

Para tareas autonomas, el contrato debe contener solo contexto operativo verificable:


{

  "preflight_required": true,

  "preferred_agent_slug": "opencode",

  "project_path": "/ruta/absoluta/al/proyecto",

  "working_folder": "src",

  "depends_on": [1011],

  "deliverables": ["src/Foo.php"],

  "verify_commands": ["php -l src/Foo.php"],

  "acceptance_criteria": [

    "El archivo compila sin errores.",

    "La salida final incluye comandos ejecutados y resultado."

  ],

  "blocked_fallback": "Si falta contexto o ruta local, dejar en waiting con pregunta concreta."

}

Regla practica: depends_on decide el orden real de ejecucion entre tareas. El score ayuda a priorizar, pero no debe usarse como dependencia implicita. Si una tarea B necesita que A este terminada, B debe incluir "depends_on": [A].

No rellenes rutas, comandos o dependencias por intuicion. Si no se conocen, la tarea debe quedar en waiting o pedir aclaracion antes de entrar en queued.

si necesita human gate.

Instruccion minima para IA:

contexto;
objetivo;
restricciones;
pasos esperados;
que no debe hacer;
como debe verificar;
como debe devolver resultado.

Tareas automaticas: definition of ready

Antes de poner una tarea IA en queued, debe cumplir:

proyecto correcto;
spec o brief;
agente activo;
modelo operativo;
credencial o sesion disponible;
target si toca entorno, sitio o disco;
dependencias resueltas;
criterio de aceptacion;
fallback de bloqueo;
estado final esperado;
no hay decision humana pendiente.

Si falta uno de estos puntos, usa next o waiting, no queued.

Ejemplos completos

Ejemplo tecnico

Titulo:

"Verificar que el import Kodavio no deja tareas en cola"

Descripcion:

"Revisar en produccion las tareas importadas desde kodavio_30d_import_2026_05_30. Confirmar que estan en next, execution auto, con spec aprobada y target local. No mover ninguna a queued."

Criterios:

"21 tareas estan en next."
"0 tareas estan en queued."
"21 specs aprobadas existen."
"La consulta queda registrada en comentario."

Evidencia:

consulta SQL o resumen de verificacion.

Estado final:

done si los conteos cuadran;
waiting si aparece alguna tarea en queued.

Ejemplo editorial

Titulo:

"Proponer topics comunidad Flowtitude semana 23"

Descripcion:

"Buscar cinco temas actuales para la comunidad Flowtitude con fuente y angulo editorial. No redactar articulos todavia. Dejar opciones para seleccion humana multiple."

Criterios:

"Cada topic tiene titulo, fuente, resumen y angulo."
"La tarea queda bloqueada esperando seleccion humana."
"No se crean tareas derivadas hasta que haya seleccion."

Evidencia:

lista de opciones en el panel de decision.

Estado final:

waiting.

Ejemplo de deploy

Titulo:

"Publicar how-to de importacion plan y runner local"

Descripcion:

"Compilar docs publicas, sincronizar export en el portal y comprobar que la nueva URL responde. No cambiar contenido ajeno."

Criterios:

"docs:publish-public pasa."
"La URL publica responde 200."
"Health de produccion OK."
"Tiempo registrado."

Evidencia:

salida de build, URL y health.

Estado final:

done.

Paso 6: ejecutar tarea

Para tarea humana:

Mover a doing.
Ejecutar.
Dejar comentario si hay decisiones.
Registrar tiempo.
Mover a review o done.

Para tarea IA:

Verificar runtime.
Confirmar credencial.
Confirmar perfil/skills.
Poner en queued solo si esta lista.
Revisar output.
Pasar a review, waiting o done segun evidencia.

Paso 7: registrar tiempo

Registra tiempo al cerrar o al terminar una fase significativa.

Por que importa:

El resumen por proyecto usa time_logs.
Sin tiempo, el proyecto parece menos costoso de lo que realmente fue.
Registrar tiempo ayuda a decidir si una automatizacion compensa.

Buenas notas de tiempo:

"Ampliada guia how-to y publicada doc Syntax"
"Verificado runtime y corregida credencial"
"Revision UI + ajuste tabla subagentes"

Evita:

notas vacias en trabajos importantes;
tiempo inflado sin explicacion;
cerrar varias tareas con tiempo duplicado.

Paso 8: cerrar o pasar a review

Cierra como done solo si:

el resultado fue verificado;
el criterio de terminado se cumple;
el tiempo esta registrado;
no quedan decisiones abiertas;
si hubo IA, el output fue revisado.

Para tareas IA, OPS valida tambien QA por tipo antes de aceptar done: codigo necesita verificacion tecnica, deploy necesita healthcheck o rollback, recurrentes necesitan evidencia de scheduler/watchdog, imagen necesita prompt/modelo/ruta y todas necesitan tiempo registrado.

Niveles de QA:

Nivel	Uso	Evidencia minima
Smoke	Docs, copy, tarea pequena reversible	Revision, ruta/enlace, nota de resultado y tiempo
Standard	Producto normal, UI no sensible, specs, planes	Spec/brief, verificacion funcional, riesgo residual y tiempo
Strict	Codigo, infra, datos, runner, recurrentes, cliente	Preflight, tests/smoke, evidencia antes/despues, rollback o fallback y tiempo
Release	Deploy, dominio, publicacion, cliente o promesa externa	Strict + gate humano + smoke post-deploy + rollback documentado

Usa review si:

hay que comprobar visualmente;
falta validar contenido;
el usuario debe aprobar;
se genero codigo/documentacion con posible impacto.

Usa waiting si:

falta input;
falta credencial;
falta elegir opcion;
hay riesgo de ejecutar sin confirmacion.

Resolver una tarea bloqueada

Cuando una tarea esta bloqueada, la accion principal debe estar en el panel superior del detalle. Ese panel existe para que no haya que buscar en comentarios ni adivinar que boton toca.

Usa Solo guardar nota si quieres anadir contexto, pero todavia no has decidido que debe pasar. La tarea sigue bloqueada.

Usa Responder y desbloquear si ya has dado la respuesta y quieres que vuelva al flujo manual normal. La tarea deja de estar bloqueada y vuelve a quedar disponible, pero no se lanza automaticamente.

Usa Responder y ejecutar si la tarea es automatizable y quieres que continue en cola. Esta accion guarda la respuesta, quita el bloqueo y llama a dispatch. Si la tarea requiere Human Gate, OPS debe dejarla desbloqueada pero sin ejecutarla hasta aprobar el gate.

Regla base: comentar no desbloquea. Desbloquear es una accion explicita para evitar malentendidos entre humanos, agentes y automatizaciones.

Uso del asistente OPS

El asistente puede ayudar con operaciones controladas. Ejemplos:

resume tarea 700
anade 15 min a tarea 700 nota: revision
comenta tarea 700: pendiente de validar
cierra tarea 700 20 min nota: desplegado
bloquea tarea 700 nota: falta decision

Regla de seguridad:

El asistente debe proponer y confirmar antes de mutar datos sensibles.
No debe inventar proyectos, credenciales o estados.
Si hay ambiguedad, debe pedir aclaracion o dejar la tarea bloqueada.

Errores comunes

Crear tareas sin proyecto.
Usar queued sin runtime check.
Cerrar sin tiempo.
Cerrar IA sin evidencia.
Mezclar muchas acciones en una unica tarea.
No explicar por que una tarea queda bloqueada.
Cambiar perfil/modelo sin comentario.

Resultado esperado

Una tarea bien creada permite que cualquier persona vea:

que hay que hacer;
por que importa;
quien o que lo ejecuta;
cuando debe parar;
como se verifica;
cuanto tiempo consumio.