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. Cada caso recibe un UUID interno id y un código de caso inmutable y legible por humanos (p. ej., PANDA-317). Las lecturas de detalles y acceso del caso aceptan cualquiera de los dos identificadores. Cuando otra operación pide un ID de caso, use el UUID. 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.

Entrada y selección de playbook

Los editores pueden adjuntar o sustituir una versión legible y no archivada de un playbook en un caso abierto (open). En la API o MCP, use versionId: null para quitar el playbook u omita el campo para conservar la selección actual.

Adjuntar, sustituir o quitar un playbook crea una actividad del sistema con las versiones anterior y seleccionada, según corresponda. Se conservan las tareas, los registros y los informes existentes; las tareas mantienen sus referencias originales a pasos.

Cada actualización de título, entrada o playbook valida la entrada resultante contra el esquema de la versión seleccionada, si hay un playbook. Enviar input sustituye el objeto completo; omitirlo reutiliza la entrada actual. La selección del playbook y la sustitución opcional de entrada se guardan juntas; si falla la validación, no se guarda ninguna. Quitar el playbook conserva la entrada sin aplicar el esquema anterior.

Ciclo de vida del caso

El estado de un caso es open, completed o cancelled. completed requiere que todas las tareas estén cerradas; cancelled cambia las tareas abiertas restantes a cancelled como parte de la transición del caso. Reabrir un caso devuelve su estado a open, pero no vuelve a abrir sus tareas.

Archivar es distinto de cerrar. Los editores y propietarios pueden archivar desde Web, CLI, API o MCP. Los Casos archivados salen de vistas activas, recuentos y grafos y no pueden abrirse, pero conservan su trabajo. Liste con archived=true (case list --archived) para obtener el UUID y la última versión de bloqueo; restaurar conserva estado, responsables y permisos. Solo un propietario puede eliminar definitivamente un Caso archivado, con el último expectedLockVersion. Se eliminan sus Tareas, Registros, Fuentes y enlaces; otros Casos y el contenido original del proveedor permanecen.

Un caso puede finalizar sin tareas ni registros. Utilice esa forma ligera cuando sólo sea necesario retener el hecho de la finalización.

Los Casos públicos muestran Tareas y Registros

Los Casos públicos muestran el título, entrada, Tareas, Registros y traspasos legibles actuales, incluidas las incorporaciones posteriores. Conservan referencias públicas de autores y responsables, pero omiten permisos privados, fuentes vinculadas, informes y resúmenes de Review y configuración privada. La publicación permite solo leer. Los lectores explícitos también pueden leer Casos privados y sus fuentes; escribir requiere edición.

Las mutaciones de Casos y Tareas requieren el último expectedLockVersion (la lectura devuelve lockVersion). Ante un conflicto, lea el estado actual y reconsidere el cambio. Los editores pueden asignar, cambiar títulos, cerrar, reabrir, reemplazar todos los permisos, archivar y restaurar. La asignación no concede acceso: el destinatario debe tener edición. Eliminar permisos no cambia al responsable. Los iniciadores, autores y aprobaciones completadas permanecen como historial.

Playbooks y Casos tienen una cuenta propietaria de Usuario o Espacio de trabajo (ownerId), que también paga su uso. El propietario personal tiene todos los derechos; los Owners y Admins actuales ejercen esos derechos para un Espacio de trabajo. Los demás miembros necesitan permisos explícitos de usuario o Equipo, o visibilidad pública para leer contenido publicado. La membresía por sí sola no concede acceso. Al eliminar un miembro, se revocan sus permisos directos sobre los recursos propiedad de ese Espacio, incluidos los completados y archivados. Si la eliminación dejara algún recurso sin editor explícito, añada primero otro usuario o equipo editor, incluidos los recursos completados o archivados. Se conservan los permisos sobre recursos personales y de otros Espacios. Los permisos de Equipo y administración dependen de la membresía actual. El SSO obligatorio se aplica a los miembros; los usuarios externos con permisos directos usan la autenticación normal de Epismo. El acceso de Equipo entre espacios verifica el SSO del espacio de participación. Los listados usan permisos explícitos y la visibilidad pública admitida; la propiedad por sí sola no incluye un recurso.

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 Case Review, que encola una evaluación de IA sobre la evidencia compartida del caso.

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.

Una tarea work admite los estados open, completed y cancelled. Una tarea approval admite open, approved, rejected y cancelled. El estado expresa el resultado; los detalles y motivos se guardan en registros.

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). El recorrido continúa por todos los casos legibles, incluidos los públicos, y se detiene ante los que el lector no puede consultar. Así, quien lee un caso público también puede ver otras ramas publicadas del mismo grafo conectado.

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) o agreement (una decisión o compromiso compartido). El servidor escribe activity (un evento de coordinación). 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 registros usan note, output, activity, agreement (reservado al sistema) o agreement. Los nuevos registros y los cambios de tipo aceptan note, output o agreement. Las evaluaciones humanas y de agentes pueden guardarse como notas; AI Review guarda informes separados.

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.

Case Review

Entiende dónde está el trabajo, qué necesita atención y qué hacer después. AI review reúne la evidencia y las acciones propuestas en un informe. Registra el resultado y reevalúa para dar continuidad al juicio.

Cualquier editor del caso puede solicitar una evaluación de AI review con POST /v1/cases/{caseId}/report (epismo report case generate o epismo_report_case_generate). Esa llamada encola la evaluación y devuelve de inmediato los metadatos del trabajo. Review utiliza instrucciones de evaluación integradas; no admite instrucciones personalizadas de la cuenta propietaria ni prompts por solicitud. La búsqueda web durante la evaluación se puede habilitar si la política del espacio de trabajo lo permite.

Una vez procesado, el último informe sintetizado y las propuestas accionables se pueden leer con GET /v1/cases/{caseId}/report (epismo report case get o epismo_report_case_get). Los editores del caso pueden actuar sobre las propuestas con POST /v1/cases/{caseId}/report/actions (epismo report case act o epismo_report_case_act), confirmando acciones como crear tareas de seguimiento o descartando propuestas. Revise todo el contenido de la propuesta guardada y envíe reportId, proposalId y action (create o dismiss), con feedback opcional al descartar. La creación utiliza el contenido guardado sin cambios para crear una tarea, un caso con un enlace de traspaso dirigido, una sugerencia o un playbook con su primera versión. No envíe title, content, cambios de definición ni idempotencyKey; los reintentos utilizan la identidad de la propuesta. Las decisiones se conservan por propuesta: repetir una ya atendida devuelve el informe guardado actual sin crear más trabajo.

Los nuevos casos y playbooks utilizan la cuenta de facturación activa de quien confirma, con acceso restringido al creador; no se copian los permisos ni las fuentes externas del caso original. Crear un caso añade un enlace de traspaso dirigido desde el caso evaluado sin cerrarlo. La creación de playbooks se propone con moderación, cuando hay evidencia de un patrón recurrente y un uso futuro probable; las recomendaciones de creación ya atendidas no se vuelven a proponer para ese caso. Un informe desactualizado muestra un aviso orientativo de reevaluación y no bloquea las acciones; siguen aplicándose los permisos actuales y la validación de cada operación.

El creador de un registro normal escrito por un cliente 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.

Fuentes externas

Vincule un hilo de Slack, un mensaje/hilo de Discord o un archivo nativo de Google Docs, Sheets o Slides con su cuenta conectada en el espacio activo. Slack y Discord requieren un espacio de trabajo; Google Drive admite espacios personales y de trabajo. Primero conecte Google Drive y seleccione el archivo con Google Picker en Web; una URL por sí sola no concede acceso. Las fuentes de Google Drive usan la clave de proveedor gdrive. Vincular y desvincular cuestan 2 créditos cada uno; la captura inicial está incluida al vincular. Cada actualización manual o automática completada cuesta 1 crédito a la cuenta de facturación de ese caso. Los casos cerrados solo se actualizan por solicitud explícita. Encolar, fallar, paginar y reintentar no tienen costo; las solicitudes agrupadas en una captura generan un solo cargo para ese caso. case get incluye sources solo para colaboradores de trabajo. Las lecturas usan capturas guardadas; compruebe el estado y las fechas. Si se omite contenido, obtenga la fuente completa más reciente con su ID. No se conserva contenido histórico. Las fuentes son independientes de los registros y no se incluyen en respuestas públicas. Consulte Slack, Discord y Google Drive para compartir, actualizar automáticamente y eliminar capturas.

Transfiera la propiedad de un Caso con epismo_case_owner_transfer, case owner transfer <case-id> --owner-id <account-id> --lock-version <n> o PATCH /v1/cases/{caseId}/owner (ownerId, expectedLockVersion, idempotencyKey). Requiere propiedad actual. Un Caso personal puede pasar al Espacio conectado; si es público, también exige gestión del Espacio de destino. Un Caso del Espacio puede pasar a su creador o a un Owner de ese Espacio. Se rechazan transferencias entre usuarios o entre Espacios. Se conservan asignación y permisos, cambia la cuenta de facturación y se borran los informes de Review derivados. Reasignar por sí solo no realiza estos cambios de propiedad.