Coroid es una fábrica de software AI para sistemas de producción. El equipo de ingeniería define el estándar una sola vez: el contexto del proyecto, las políticas de calidad que deben cumplir todas las modificaciones, las reglas de revisión y quién otorga la aprobación. Después de eso, cualquier empleado de su empresa puede solicitar un cambio en lenguaje sencillo, sin necesidad de usar la CLI ni conocer los detalles de la compilación del código. Coroid planifica el trabajo, escribe el código, lo prueba y lo revisa según ese estándar, y abre un pull request en su repositorio para que usted lo apruebe.
Esta documentación cubre el producto tal como se entrega hoy. Si una función no está documentada aquí, aún no está disponible.
Nuevo aquí
Siga los pasos de Comenzar en orden. Este proceso le guiará desde una cuenta vacía hasta un pull request fusionado: cree una organización, conecte un repositorio, cree un proyecto, ejecute una tarea y revise el resultado.
Entender cómo funciona
Cómo una tarea se convierte en un pull request es la página a la que todas las demás hacen referencia: la ruta completa desde su descripción hasta un PR, con cada etapa nombrada.
Luego Roles de los agentes para saber quién hace qué, y Guía de desarrollo basado en especificaciones, que es lo más eficaz que puede dominar. La calidad de lo que construye Coroid está limitada por la calidad de lo que se le pide construir.
- 1
EspecificaciónQué se construirá y cómo sabrás que funcionó
ArquitectoPuedes editar - 2Planificación
Pasos ordenados, revisados antes de escribir cualquier código
ArquitectoTú apruebas - 3
DesarrolloCódigo y pruebas escritos en un espacio de trabajo aislado
Desarrollador - 4
VerificaciónTu suite de pruebas, además de comprobaciones y controles de calidad
Control de calidad - 5
RevisiónUna revisión automatizada del diff
Revisor - 6Solicitud de incorporación de cambios
En una rama de tu repositorio, esperando tu aprobación
Tú fusionas
Los resultados de verificación fallidos y las observaciones de revisión corregibles vuelven al desarrollador como reelaboración, antes de que se abra cualquier pull request.
Orientarse
| Sección | Qué cubre |
|---|---|
| Comenzar | Desde la cuenta hasta el primer pull request fusionado |
| Conceptos | Cómo funciona realmente el sistema |
| Trabajo y planificación | Iniciar trabajos, tareas, planes y lanzamientos |
| Proyectos y código | Repositorios, configuración de compilación y pruebas, contexto |
| La fábrica | Ejecutar trabajos, automatizaciones e informes |
| Calidad y revisión | Controles, hallazgos, evidencias y pruebas en navegador |
| Globalización | Idiomas, traducciones y código listo para el mundo |
| Operaciones y supervisión | Mission Control, hallazgos y notificaciones |
| Configuración de la organización | Miembros, claves, políticas y retención |
| Facturación y capacidad | Slots, créditos, uso y facturas |
| Integraciones | Control de código fuente, chat, MCP, evidencias y hooks |
| Referencia | Glosario, estados, límites y solución de problemas |
Tres cosas que vale la pena saber de inmediato
Los slots de agentes determinan cuántas tareas se ejecutan simultáneamente, no la velocidad a la que se ejecuta una tarea. La duración de una tarea depende del tamaño del cambio y de su suite de pruebas. Consulte Capacidad y slots de agentes.
NEEDS_HUMAN_REVIEW no es un fallo. Significa que el trabajo ha llegado a una decisión que solo usted puede tomar. Resuélvala y la tarea continuará. Consulte
Estados de la tarea.
Algo no se comporta como se esperaba
Empiece por el índice de solución de problemas, que relaciona los síntomas con las respuestas.