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 el 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.

Los casos públicos publican registros, no tareas

Un caso puede incluir public en su ACL, el mismo centinela que usan los playbooks. Quien solo tiene la concesión public lee el título publicado, la entrada, los registros y el vecindario de traspaso legible. Las tareas, la asignación y las identidades de los colaboradores no se publican; si importa el resultado de una tarea, ya debería ser un registro.

Los colaboradores de la ACL del caso siguen viendo el caso en vivo. Publicar no inicia un caso nuevo. El mismo caso continúa, y los registros posteriores siguen en esa proyección pública.

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. Quienes tienen acceso de trabajo pueden asignar el caso, cambiar el título, cerrarlo, reabrirlo y conectar transferencias. Reemplazar la ACL o el acceso, y archivar, quedan limitados al responsable actual. started_by es historia.

Las tareas se crean bajo demanda

Una tarea es un trabajo explícito dentro de un caso. Su tipo es work o approval; puede asignarse a un usuario, vincularse a un paso de origen y, para el trabajo de aprobación, señalar el registro temático exacto. Una tarea de aprobación es un juicio humano o de un agente sobre ese registro. Es distinta de una revisión de Epismo AI, que encola a Epismo AI para juzgar la evidencia compartida del caso y más tarde añadir un registro review con origin=system.

Iniciar un caso no crea una tarea por paso. Cree una tarea solo cuando la responsabilidad, la transferencia, la aprobació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. Cualquier editor del caso puede actualizar una tarea abierta, incluido su responsable. 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. Crear o eliminar una transferencia requiere lectura en el origen y acceso de trabajo en el destino: un caso público puede continuarse en un caso que el llamante pueda editar, pero un lector no puede adjuntar trabajo a un caso público.

• 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 de contexto compartido en la línea de tiempo de un caso y también pueden pertenecer a una tarea o paso de origen. kind es un conjunto cerrado: los clientes escriben note (comentario, una decisión o un traspaso), output (un entregable duradero; añadir uno puede desencadenar una revisión de Epismo AI) o review (un veredicto; data.verdict debe ser pass, changes_requested o insufficient). El servidor escribe activity (un evento de coordinación) y las revisiones de Epismo AI (origin=system). También incluyen contenido opcional legible por humanos, datos estructurados, origen (user, agent o system), creador, identidad del cliente y tiempo de creación. Los registros creados por un usuario o un agente pueden actualizarse o redactarse por su creador; la tarea y la procedencia permanecen fijas. Una eliminación deja una lápida (deleted_at) para que las referencias sigan funcionando.

Los buenos registros incluyen resultados, evidencia, decisiones, referencias de archivos u objetos, resúmenes de transferencia y errores significativos. 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. Cualquier editor del caso puede solicitar una revisión de Epismo AI con POST /v1/cases/{caseId}/review; esa llamada la encola y vuelve de inmediato. El prompt opcional añade orientación del llamador después de las reglas fijas de revisión. Active autoReview en el caso para que añadir un registro OUTPUT encole una. Consulte esos registros con kinds=review y origins=system. Cualquier editor del caso también puede solicitar un resumen situacional puntual con POST /v1/cases/{caseId}/overview; se ejecuta de forma síncrona y devuelve el texto en la respuesta. Reenvíe la misma clave de idempotencia para recibir el resumen anterior sin regenerarlo. Las revisiones automáticas y manuales, y los overviews, se cargan a la cuenta de facturación del caso capturada al iniciarlo. El hogar del caso debe permitir Epismo AI (ajustes de IA); cuando no lo permite, activar autoReview y las solicitudes de revisión u overview manual se rechazan, mientras que las revisiones automáticas ya activadas se omiten sin registro ni cargo.

El creador de un registro puede actualizar su tipo, contenido o datos, o redactarlo. Cualquiera cubierto por la ACL del caso puede seguir 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.