ComandeskHelp Inicio

Editar y Mantener Elementos Existentes

Objetivo

Cambiar elementos ya creados sin perder trazabilidad ni romper automatizaciones. En OPS, editar no es solo "corregir un campo"; muchas piezas estan conectadas: tareas, proyectos, tiempo, recurrentes, flujos, perfiles, skills, credenciales y dispatch.

La regla base es: cambia lo minimo necesario, deja contexto cuando afecte a ejecucion, y verifica despues si el cambio toca automatizacion o IA.

Principios de mantenimiento

  • No reescribas historia si basta con comentar.
  • No borres si desactivar conserva trazabilidad.
  • No cambies proveedor/modelo sin motivo registrado.
  • No actives perfiles o skills importados sin auditoria.
  • No edites recurrentes en caliente sin probar manualmente.
  • No cierres tareas sin tiempo si consumieron trabajo real.
  • No uses dispatch para arreglar ambiguedad de instrucciones.

Editar una tarea

Cuando editar:

  • falta proyecto;
  • el titulo no se entiende;
  • el estado no refleja realidad;
  • cambio el responsable o perfil;
  • cambio el criterio de terminado;
  • se detecto que debe bloquearse.

Pasos:

  1. Abre la tarea desde cola, Kanban, busqueda o asistente.
  2. Identifica el campo minimo que hay que cambiar.
  3. Si cambias proyecto, revisa impacto en horas.
  4. Si cambias perfil/modelo/skills, comenta por que.
  5. Si cambia el alcance, actualiza descripcion.
  6. Si ya hubo ejecucion, no ocultes lo ocurrido: deja comentario correctivo.

Por que importa:

  • Las tareas son registro operativo.
  • Cambiar sin comentario puede hacer imposible entender por que se ejecuto de cierta forma.

Cambiar estado de una tarea

Usa next cuando:

  • esta lista para trabajar;
  • no falta input;
  • no hay bloqueo conocido.

Usa waiting cuando:

  • falta decision;
  • falta credencial;
  • falta input;
  • falta validar riesgo;
  • no debe ejecutarse automaticamente.

Usa review cuando:

  • hay output terminado;
  • falta revision humana;
  • falta comprobar visualmente;
  • se genero contenido/codigo que requiere aprobacion.

Usa done cuando:

  • el criterio de terminado se cumple;
  • hay evidencia suficiente;
  • el tiempo esta registrado;
  • no quedan decisiones abiertas.

Usa archived cuando:

  • ya no aplica;
  • es duplicada;
  • se conserva por historial.

Editar tiempo

Reglas:

  • El tiempo humano puede corregirse si hubo error.
  • El tiempo IA debe tratarse como registro inmutable si el sistema lo marca asi.
  • Si una tarea cerrada no tiene tiempo, anadelo con nota clara.
  • Si varias tareas comparten trabajo, reparte tiempo de forma razonable y explica si hace falta.

Por que importa:

  • El resumen de proyecto depende de time_logs.
  • El tiempo ayuda a saber si una automatizacion ahorra o consume demasiado.

Editar proyecto

Antes de editar:

  • revisa tareas activas;
  • revisa horas asociadas;
  • revisa recurrentes que apuntan al proyecto;
  • revisa si hay documentacion vinculada.

Buenas practicas:

  • Renombra solo si mejora claridad.
  • Desactiva proyectos obsoletos en vez de borrar.
  • No conviertas un proyecto en cajon de sastre.
  • Si mueves tareas, deja comentario si afecta a interpretacion de horas.

Editar credencial

Pasos:

  1. Ve a Automatizacion -> Credenciales.
  2. Revisa uso actual.
  3. Actualiza secreto o crea nueva credencial segun politica.
  4. No pegues secretos en notas.
  5. Ejecuta Runtime check.
  6. Prueba con una tarea controlada si afecta a dispatch.

Cuando bloquear:

  • si no sabes si la credencial aplica;
  • si el proveedor no coincide con la tarea;
  • si el runtime no esta disponible;
  • si la credencial afecta a produccion.

Editar perfil/subagente

Un perfil/subagente representa un rol operativo. No es solo una etiqueta.

Antes de editar:

  • revisa si esta activo;
  • revisa tareas que lo usan;
  • revisa recurrentes que lo usan;
  • revisa skills asociados;
  • revisa runtime/modelo por defecto.

Buenas practicas:

  • Cambia descripcion para aclarar uso y no uso.
  • Mantiene defaults conservadores.
  • Si dos perfiles se solapan, marca uno como pendiente de fusion o inactivo.
  • No actives perfiles importados sin test minimo.

Por que importa:

  • Un cambio de perfil puede afectar muchas tareas futuras.
  • Con volumen alto de agentes, la calidad del catalogo importa mas que la cantidad.

Editar skill

Un skill debe aportar una capacidad reusable y clara.

Antes de editar:

  • busca duplicados o solapes;
  • revisa si existe una version mejor;
  • identifica que partes merece la pena fusionar;
  • define cuando usarlo y cuando no.

Buenas practicas:

  • Fusiona contenido util si dos skills se solapan.
  • Deja una sola version recomendada.
  • Marca como inactiva o pendiente la version superada.
  • Prueba el skill con una tarea real.
  • Documenta casos de uso y limites.

Por que importa:

  • Un repositorio infinito de skills no mejora el sistema.
  • La meta es un catalogo de alta calidad, auditable y facil de elegir.

Editar recurrente

Antes de editar:

  • revisa ultimas tareas creadas;
  • revisa si hubo duplicados;
  • revisa si lanzo en fecha/hora esperada;
  • revisa proyecto, perfil, modelo e instrucciones.

Pasos:

  1. Pausa si el cambio es importante.
  2. Edita una cosa cada vez.
  3. Lanza ejecucion manual.
  4. Comprueba tarea creada.
  5. Comprueba estado final esperado.
  6. Reactiva solo cuando la prueba sea correcta.

Por que importa:

  • Una recurrente mal editada puede generar errores todos los dias.
  • Probar manualmente evita esperar al siguiente ciclo para descubrir el fallo.

Editar flujo

Antes de editar:

  • revisa tareas recientes creadas desde el flujo;
  • revisa si el flujo sigue representando el proceso real;
  • revisa defaults IA;
  • revisa criterios de verificacion.

Pasos:

  1. Cambia pasos de uno en uno.
  2. Crea tarea de prueba.
  3. Verifica output.
  4. Ajusta si hay ambiguedad.
  5. Documenta cambios importantes.

Editar documentacion

Actualiza docs cuando:

  • cambia comportamiento del sistema;
  • se corrige una incidencia recurrente;
  • se crea un proceso nuevo;
  • se cambia seguridad, credenciales o dispatch;
  • se cambia UI de una forma que afecte guias.

Regla:

  • Si alguien podria preguntarlo otra vez, probablemente merece estar documentado.

Corregir errores comunes

Tarea sin proyecto:

  • asignar proyecto;
  • revisar si tiene tiempo;
  • comentar si afecta a cierre.

Tarea cerrada sin tiempo:

  • abrir detalle;
  • anadir tiempo;
  • nota breve con lo realizado.

Recurrente duplicada:

  • conservar una tarea;
  • archivar duplicado;
  • corregir plantilla;
  • probar manualmente.

Runtime bloqueado:

  • revisar credenciales;
  • revisar worker;
  • revisar modelo;
  • bloquear tarea con motivo;
  • no cambiar proveedor en silencio.

Skill duplicado:

  • comparar contenido;
  • fusionar lo util;
  • dejar una version clara;
  • marcar pendiente de auditoria si no esta probado.

Perfil incorrecto:

  • mover tarea a waiting;
  • corregir perfil;
  • comentar motivo;
  • relanzar solo si runtime check esta OK.

Resultado esperado

Despues de editar, el sistema debe quedar mas claro que antes. Si una edicion deja dudas, crea una nota, bloquea la tarea o documenta la regla. La meta no es tocar menos: es tocar con trazabilidad.