El trabajo llega a Coroid desde usuarios del portal, de Slack o Telegram, desde sus propios sistemas y asistentes, y desde la automatización propia de Coroid. La opción Nuevo trabajo, en la que una persona describe el trabajo en el portal, es una de estas vías. Todas convergen en la misma ruta de ejecución— especificación, plan, desarrollo, verificación, revisión, solicitud de extracción.
| Ruta | Cuándo usar |
|---|---|
| Nuevo trabajo | Alguien necesita algo y está listo para describirlo |
| Importar incidencias | La solicitud ya existe en Jira, Linear, Trello o en GitHub Issues |
| Consultar a Coroid | Prefiere describirlo de forma conversacional |
| Slack o Telegram | Alguien lo solicita mediante chat |
| Recepción de trabajo en API | Otro sistema registra la solicitud, como un formulario de solicitud de funcionalidad en su producto |
| Automatizaciones de eventos | Algo en GitHub, Slack, Telegram o Jira debe convertirse en trabajo |
| Coroid MCP | Un asistente o agente como Hermes, Codex o Claude Code gestiona el trabajo |
| Programaciones | El desencadenante es el tiempo |
| Enlaces | El desencadenante es un evento de plataforma |
| Informes y hallazgos | Un informe o una comprobación de calidad detectó un problema a solucionar |
Solicitudes
Nuevo trabajo
Alguien lo describe
Importar incidencias
Desde un gestor de tareas
Ingestión mediante API
Tu producto o un agente
Automatizaciones de eventos
Un pull request, comentario o mensaje
Calificación
Se filtra, eliminan duplicados y se verifica la solicitud; luego se determina la ruta. Nada se crea hasta que apruebe los criterios.
Se convierte en
- Tarea
- Plan
- Informe
- Cronograma
Seleccione uno o deje Create en Automático y deje que Qualification decida.
Tareas y planes: especificación, plan, compilación, verificación, revisión, pull request
Se verifica y luego se enruta
Una solicitud procedente de Nuevo trabajo o de una importación no se crea al llegar. Primero pasa por la fase de Calificación. Coroid la analiza en busca de valores sensibles, la compara con la versión actual, busca duplicados, verifica lo que puede y determina lo que debe convertirse en. Nada se crea hasta que apruebe el proceso. Ver Describir lo que necesita.
Las solicitudes recibidas mediante la recepción de trabajo en API también pasan por este proceso, al igual que los eventos que una automatización de eventos envía a Calificación.
Lo que se convierte en trabajo sigue una de cuatro rutas:
| Ruta | Produce |
|---|---|
| Tarea | Una única tarea, que termina en una solicitud de extracción de pull request |
| Plan | Un plan por fases que apruebas antes de escribir código |
| Informe | Un informe generado |
| Automatización | Trabajo que se ejecuta según un horario o al producirse un evento |
En el formulario de Nuevo trabajo puedes elegir tú mismo la ruta o dejarla en modo Automático Automático y deja que Qualification decida. Si eliges una opción y Qualification recomienda otra, verás la recomendación y tomarás la decisión.
El funcionamiento de Ask Coroid es distinto. En su modo Assistant, el asistente de chat crea tareas y planes directamente, sin necesidad de Qualification. Un chat de Preparar trabajo, el flujo de trabajo SDLC guiado, envía su especificación aprobada a Qualification antes de iniciar la planificación. Ver Asistente de chat.
Las demás rutas crean trabajo directamente, sin Qualification, y sus propias configuraciones determinan qué puede iniciarse. Para el servidor MCP, esas son sus aprobaciones y políticas de automatización.
Cuando comienza el trabajo
Nadie espera en el portal una solicitud del sistema de entrada de trabajo API o una automatización de eventos. Coroid crea su trabajo en cuestión de minutos después de que Qualification lo apruebe. Que una tarea también se inicie por sí sola depende del origen de la solicitud:
| Origen | Se inicia por sí solo |
|---|---|
| Una cuenta de servicio configurada para iniciar automáticamente el trabajo cualificado | Sí |
| Un GitHub pull request o incidencia cuyo autor tenga acceso de escritura al repositorio | Sí |
| Un comentario en GitHub que mencione a Coroid, válido únicamente si proviene de autores con permisos de escritura | Sí |
| Cualquier otra cuenta de servicio | No |
| Slack, Telegram, Jira y cualquier otro origen | No |
Una tarea que no se inicia por sí sola espera a que alguien la inicie. Qualification muestra la solicitud como pendiente de inicio, con un enlace a la tarea. Los planes nunca se inician por sí solos: esperan aprobación, como siempre. Un horario espera en revisión a que una persona decida cuándo ejecutarse.
Coroid asigna el trabajo al primer miembro activo de esta lista: la persona que presentó la solicitud o configuró la automatización, el creador de la cuenta de servicio, el creador del proyecto y el propietario de la organización.
Una solicitud que no especifique proyecto se dirige al único proyecto de la organización. Si hay varios, la solicitud espera revisión en Qualification y el revisor elige el proyecto al aceptarla.
¿Tarea o plan?
La prueba útil es que se pueda revisar. Si el trabajo terminado es una pull request que un compañero podría leer de una sentada, es una tarea. Si requiere varios cambios en un orden definido, o quieres aprobar el enfoque antes de que se implemente nada, es un plan.
Si tienes dudas, opta por un plan para todo lo sustancial. Un plan te ofrece un punto de aprobación antes de que exista el código, que es el momento más económico para cambiar de opinión. Una tarea que resulte ser demasiado grande simplemente agotará su espacio disponible.
Trabajo importado
Los problemas importados desde un sistema de seguimiento pasan por el mismo proceso de Calificación. Los duplicados, los problemas ya solucionados y las solicitudes que no se pueden verificar se detienen en esa etapa, y el resto se convierten en tareas o planes. Una lista de pendientes es una lista de deseos, por lo que este filtro es más importante para las importaciones que en cualquier otro caso. Ver Importar trabajo.
Desde sus propios sistemas
Otro sistema puede enviar solicitudes a través del módulo de entrada de trabajo API: por ejemplo, un formulario de solicitud de funcionalidad dentro de su propio producto, o una herramienta de soporte que transmita lo que piden los clientes.
El módulo API requiere una Cuenta de servicio, la cual está incluida en los planes Profesional y Empresarial. Cree una en Configuración → Cuentas de servicio. Su clave de API necesita este alcance: intake:write. La clave se muestra una sola vez al crearla, y al desactivar la cuenta de servicio se invalidan todas sus claves.
Envíe cada solicitud al gateway de API, utilizando la clave como token de autenticación:
curl -X POST https://api.coroid.ai/api/v1/organizations/work/intake \
-H "Authorization: Bearer ak_…" \
-H "Content-Type: application/json" \
-d '{"title": "Export invoices as CSV", "content": "Customers want to download their invoices as CSV from the billing page."}'| Campo | Requerido | Descripción |
|---|---|---|
title | Sí | Un nombre corto, de hasta 500 caracteres |
content | Sí | El contenido de la solicitud, de hasta 20.000 caracteres |
projectId | No | El proyecto al que pertenece el trabajo |
workType | No | task, plan, report o schedule |
signal | No | El error, alerta o problema del que proviene la solicitud, descrito a continuación |
Sin un tipo de trabajo definido, la Calificación determina la ruta a seguir. La Calificación se ejecuta en cada solicitud de API y no se puede omitir.
Cuando la solicitud proviene de la monitorización u otra fuente automatizada, describa su señal. Coroid la utiliza para detectar si el mismo incidente se ha registrado dos veces en cualquier proyecto y para redactar el contrato de resultado.
signal campo | Requerido | Descripción |
|---|---|---|
fingerprint | Sí | Una identidad estable para el incidente, como el ID del problema en su sistema de seguimiento de errores |
source | No | El origen de la señal, por ejemplo glitchtip o sentry |
routes | No | Las rutas afectadas por el incidente, hasta 50 |
minExposure | No | ¿Cuántas solicitudes en esas rutas deben atenderse antes de evaluar el resultado? |
url | No | Un enlace al incidente |
Con routes y minExposure, el contrato es medible: el incidente debe quedar sin ruido. Sin ellos, el contrato registra que no se puede medir. A
mandato puede negarse a iniciar trabajos que no sean medibles.
Una tarea cualificada desde una Cuenta de servicio espera a que alguien la inicie. Un propietario o administrador puede modificar esto para la cuenta en Cuentas de servicio con esta configuración: Iniciar el trabajo cualificado automáticamente. Actívelo solo cuando todo lo que envíe la cuenta provenga de personas de confianza. Ver Cuándo comienza el trabajo.
Los Eventos en GitHub, Slack, Telegram y Jira también pueden convertirse en solicitudes, sin necesidad de volver a escribirlos. Una automatización de eventos los envía a Qualification. Ver Desencadenadores y destinos.
Desde sus asistentes
Un asistente o agente que ejecute, como Hermes, Codex o Claude Code, puede trabajar con Coroid a través de su servidor MCP. Puede leer sus proyectos y trabajos, y crear, ejecutar y entregar trabajo dentro de los alcances que le otorgue. El trabajo que cree no pasa por Qualification. Ver Coroid como servidor MCP.
Entrada automatizada
Las Programaciones y los hooks abren trabajos sin intervención humana; la diferencia radica en el desencadenador: tiempo u otro evento. Ambos son automatizaciones, listados en la fábrica y creados en Nuevo trabajo.
Las verificaciones de calidad también generan trabajo de corrección. Cuando una política de calidad analiza un informe y detecta problemas en el producto, Coroid abre una tarea de remediación para ellos. Fábrica → Revisión muestra las fallas de prueba que no tienen asignada ninguna tarea. Corregir convierte una de ellas en una tarea de corrección.
Todo esto consume slots de agente reales y gastos de modelo reales. Asigne a los trabajos automatizados una prioridad más baja que al trabajo que alguien esté esperando — ver Capacidad y slots de agente.