Casos, tareas y registros

Un caso es un asunto real. Se puede anclar a una versión de Playbook inmutable o iniciar ad hoc con un título. Un caso respaldado por Playbook almacena el ID del Playbook y el ID de la versión; no realiza un seguimiento del progreso del paso.

Ciclo de vida del caso

Un caso es open o closed. El cierre establece un resultado de completed, cancelled o abandoned. completed requiere que todas las tareas estén cerradas; la cancelación o el abandono cierra las Tareas abiertas restantes como parte de la transición del Caso. Reabrir un Caso no vuelve a abrir sus Tareas.

Archivar es distinto de cerrar. Un Caso archivado sale de todas las listas, recuentos y grafos de traspaso, y deja de resolverse en las lecturas, mientras que sus Tareas, Registros y Traspasos se conservan en lugar de eliminarse. Sólo quien inició el Caso o su responsable actual puede archivarlo, desde la aplicación web.

Un Caso puede finalizar sin Tareas ni Registros. Utilice esa forma ligera cuando sólo sea necesario retener el hecho y el resultado.

Las mutaciones de casos utilizan concurrencia optimista. Envíe el último lockVersion; después de un conflicto, vuelva a leer el caso y reconsidere el cambio en lugar de repetir una intención obsoleta.

Las tareas se crean bajo demanda

Una Tarea es un trabajo explícito dentro de un Caso. Su tipo es work o review; puede asignarse a un Usuario, vincularse a un Paso de origen y, para el trabajo de revisión, señalar el Registro temático exacto.

Iniciar un caso no crea una tarea por paso. Cree una tarea solo cuando la responsabilidad, la transferencia, la revisión o un trabajo con seguimiento por separado deban ser visibles. Se pueden abrir varias tareas y cerrar una no hace avanzar el caso automáticamente.

Las actualizaciones de tareas también utilizan lockVersion. Una Tarea cerrada sólo se puede reabrir mientras su Caso principal esté abierto.

Las transferencias dirigidas conectan Casos

Los casos se pueden vincular en un grafo acíclico dirigido (DAG) mediante transferencias o handoffs (fromCaseId -> toCaseId). Las transferencias modelan transiciones multietapa o entre equipos manteniendo las ACL y ciclos de vida de cada caso:

• Prevención de ciclos: La creación de transferencias garantiza grafos sin ciclos mediante verificaciones transaccionales. Los autoenlaces y ciclos son rechazados.
• Descubrimiento de candidatos: Consulte casos válidos ascendentes o descendentes para encontrar objetivos de conexión seguros sin errores.
• Grafo de transferencias: Visualice el DAG conectado alrededor de un caso raíz según el alcance (self, ancestors, descendants, neighbors, connected).

Los registros son la superficie de transferencia

Los registros son entradas inmutables, que solo se pueden agregar en la línea de tiempo de un Caso y también pueden pertenecer a una Tarea o Paso de origen. Incluyen un kind definido por la aplicación, contenido opcional legible por humanos, datos estructurados, origen (user, agent o system), creador, identidad del cliente y tiempo de creación.

Los buenos registros incluyen resultados, evidencia, decisiones, comentarios de revisión, referencias de archivos u objetos, resúmenes de transferencia, errores significativos y actividad de coordinación. No almacene automáticamente cadenas de pensamiento, cada llamada a herramienta, salida de shell sin procesar, credenciales, historial de reintentos, latidos o el gráfico de tiempo de ejecución.

Corrija un Registro agregando un Registro nuevo. Los Registros se listan dentro de un Caso, con paginación estable del cursor y filtros opcionales de tarea, autor, tipo, origen, ACL y orden de clasificación. El uso de scope (ancestors o connected) expande la consulta a través de transferencias conectadas evaluando el acceso del usuario para cada caso individualmente.