Nouveau travail Constitue la principale façon d'introduire du travail dans Coroid. Vous décrivez le travail une fois, puis vous le routez sous forme de tâche, de plan échelonné, de rapport ou de planning récurrent.
Routage — choisissez d'abord le résultat attendu
Le routage est un choix que vous faites, pas une estimation faite par Coroid. Sélectionnez-le en premier ; le formulaire n'affichera alors que les options pertinentes pour ce résultat.
| Option | Produit |
|---|---|
| Une tâche exécutable unique | Une tâche unique aboutissant à un seul pull request. |
| Plan de travail échelonné | Un plan échelonné que vous validez avant l'écriture du code. |
| Rapport | Un rapport généré |
| Planning | Un moniteur récurrent |
Choisissez une tâche exécutable unique lorsque le travail correspond à un changement unique qu'un reviseur peut lire en une seule séance. Choisissez plan de travail échelonné lorsqu'il nécessite plusieurs modifications dans un ordre précis, ou lorsque vous souhaitez voir l'ensemble de l'approche avant de vous engager dans quoi que ce soit.
Deux raccourcis sont disponibles à côté du formulaire : Importer des tickets permet d'importer du travail depuis un outil de suivi, et Demander à Coroid confie la même tâche au assistant de chat.
Projets
Sélectionnez le projet auquel ce travail appartient. Vous pouvez ajouter d'autres projets lorsque le travail concerne plusieurs projets dépendants — c'est ainsi que le travail inter-projets est exprimé.
Décrire le travail
Deux champs, ayant chacun une fonction distincte.
Titre du travail — un nom court. C'est ce que vous rechercherez plus tard dans les listes.
Description — le contenu essentiel : résultat attendu, contexte, contraintes, documents sources, et ce que Coroid doit livrer. Rédigez le résultat plutôt que l'implémentation ; Coroid en fera une spécification vérifiable avant que le travail ne soit vérifié par rapport à ces exigences.
Add rate limiting to the public API.
100 requests per minute per API key. Exceeding it returns 429 with a
Retry-After header. Limits are per key, not per IP.
Internal service-to-service calls are exempt — they authenticate with
service tokens, not API keys.
Do not change the existing auth middleware's public interface.Cette dernière ligne joue un rôle crucial. Les lignes de périmètre définissent la différence entre un changement ciblé et un changement étendu.
Paramètres avancés
Optionnel, et généralement défini avant le début de la planification.
Utiliser le workflow SDLC
Désactivé par défaut. Activez-le pour examiner une intention et une spécification avant le début de la planification. Si désactivé, la planification commence directement à partir de votre description.
Activez-le lorsque le travail est suffisamment important pour justifier un point de contrôle avant même l'élaboration d'une approche. Laissez-le désactivé pour les travaux dont la description est déjà claire.
Objectif
Ce que le plan doit accomplir au-delà de la description. Utilisez-le pour l'objectif sous-jacent à la demande — la description indique ce qui doit être construit, l'objectif précise à quoi cela sert.
AI profile
Quels modèles traitent ce travail. Consultez AI profiles.
Vérifications Qualité
Quelle politique de qualité s'applique. Par défaut, elle correspond à la politique de Contrôle qualité de l'organisation, et la politique retenue est fixée au démarrage de l'exécution — modifier ultérieurement la politique de l'organisation ne modifie pas rétroactivement le travail déjà en cours.
Consultez Politiques et barrières de qualité.
Priorité
P0 vers P3, avec une valeur par défaut de P2. La priorité ordonne la file d'attente lorsque le nombre de travaux en attente dépasse le nombre de slots d'agents. Elle n'augmente pas la capacité — consultez
Capacité et slots d'agents.
Budget de jetons par tâche générée
Plafond de la quantité de contexte qu'une tâche générée peut consommer. Augmentez-le pour les travaux nécessitant une lecture étendue dans un grand codebase ; diminuez-le pour maîtriser les coûts sur les travaux courants.
Contraintes
Contraintes de planification, objectifs non visés, dépendances et règles de livraison. C'est ici que les objectifs non visés doivent être explicitement indiqués — le champ le plus efficace pour éviter le débordement de périmètre.
Point de départ / Pull request vers
La branche à partir de laquelle le travail démarre, et la branche cible de pull request. Identique au point de départ est cochée par défaut, afin que les deux suivent le même paramétrage.
main → new Coroid branch → PR into mainCoroid crée toujours la branche de travail. Ces champs ne modifient que le point de création de la branche et l'emplacement où atterrit pull request ; ils ne permettent pas à Coroid de valider directement des modifications sur une branche existante.
Utilisez-les lorsque vous fusionnez dans une branche autre que votre branche par défaut, comme une
develop branche ou un train de publication.
Ajouter un contexte complémentaire
Fichiers optionnels et spécification structurée. Joignez les éléments propres à ce travail : un ticket, un document de conception, une trace d'erreur.
Pour les informations pérennes concernant le projet, utilisez le contexte du projet à la place, afin qu'il s'applique à tout sans avoir à le joindre à chaque fois.
Lancer le processus
Créer et démarrer la planification COROID_TERM_0 génère le plan à partir de votre description et commence immédiatement la planification.