Coroid est une usine logicielle AI dédiée aux systèmes de production. Les équipes d'ingénierie définissent une fois pour toutes la norme : le contexte du projet, les politiques de qualité que chaque modification doit satisfaire, les règles de revue et les personnes habilitées à approuver. Ensuite, tout collaborateur de votre entreprise peut demander une modification en langage courant, sans avoir besoin d'utiliser une interface en ligne de commande ni de connaître les détails de la construction du code. Coroid planifie le travail, rédige le code, le teste, le soumet à la revue selon cette norme, puis ouvre un pull request dans votre dépôt pour que vous puissiez l'approuver.
Ces documents décrivent le produit tel qu'il est livré aujourd'hui. Si une fonctionnalité n'est pas documentée ici, elle n'est pas encore disponible.
Nouveau ici
Suivez l'ordre suivant : Se lancer pour progresser pas à pas. Ce processus vous guide depuis un compte vide jusqu'à une pull request fusionnée : créez une organisation, connectez un dépôt, créez un projet, exécutez une tâche et examinez le résultat.
Comprendre son fonctionnement
Comment une tâche devient une pull request constitue la page de référence pour tout le reste : elle présente l'ensemble du parcours depuis votre description jusqu'à une PR, en nommant chaque étape.
Ensuite Rôles des agents pour savoir qui fait quoi, et Guide du développement piloté par les spécifications, ce qui représente l'aspect le plus rentable à maîtriser. La qualité des éléments créés par Coroid dépend de la qualité des instructions qui lui sont données.
- 1
SpécificationCe qui sera construit et comment vous saurez que cela fonctionne.
ArchitecteVous pouvez modifier - 2Planification
Étapes ordonnées, révisées avant toute écriture de code.
ArchitecteVous approuvez - 3
ConstructionCode et tests écrits dans un espace de travail isolé.
Développeur - 4
VérificationVotre suite de tests, ainsi que les vérifications et portes de qualité.
Responsable QA - 5
ExamenUne passe de révision automatisée sur le diff.
Réviseur - 6Demande de fusion
Sur une branche de votre dépôt, en attente de votre validation.
Vous fusionnez
Les échecs de vérification et les observations de révision corrigibles reviennent au développeur sous forme de retravail, avant toute ouverture de pull request.
S'orienter dans l'interface
| Section | Contenu couvert |
|---|---|
| Se lancer | Du compte à la première pull request fusionnée |
| Concepts | Le fonctionnement réel du système |
| Travail et planification | Démarrer le travail, les tâches, les plans, les versions |
| Projets et code | Dépôts, configuration de la compilation et des tests, contexte |
| L'usine | Exécuter le travail, automatisations, rapports |
| Qualité et révision | Portefeuilles, résultats d'analyse, preuves, tests dans le navigateur |
| Globalisation | Langues, traductions, code prêt pour l'usage mondial |
| Opérations et surveillance | Mission Control, résultats d'analyse, notifications |
| Paramètres de l'organisation | Membres, clés, politiques, conservation des données |
| Facturation et capacité | Places, crédits, utilisation, factures |
| Intégrations | Contrôle de source, messagerie, MCP, preuves, hooks |
| Référence | Glossaire, statuts, limites, dépannage |
Trois points essentiels à connaître immédiatement
Les emplacements d'agents déterminent le nombre de tâches exécutées simultanément — pas leur vitesse d'exécution. La durée d'une tâche dépend de l'ampleur des modifications et de votre suite de tests. Consultez Capacité et emplacements d'agents.
NEEDS_HUMAN_REVIEW n'est pas une erreur. Cela signifie que le travail nécessite une décision que seul vous pouvez prendre. Répondez-y et la tâche se poursuivra. Consultez-en les détails.
États des tâches.
Un comportement inattendu est observé
Commencez par le index de dépannage, qui associe les symptômes aux solutions correspondantes.