Provenance

La provenance constitue l'historique d'un élément de travail : une tâche, un plan, une tâche de plan ou un paquet de travail. Elle répond aux questions que doit aborder un changement bien après son intégration : d'où provient-il, qui l'a demandé, qui en est le propriétaire, qui a décidé quoi et pourquoi, et ce qui a été livré.

Coroid établit cet historique à partir des événements liés au déroulement du travail au sein de l'usine : la conversation ou la demande qui l'a déclenché, les documents approuvés par les personnes concernées, les décisions prises, ainsi que les demandes de fusion et les commits ayant permis sa livraison. Vous retrouvez le même historique dans le portail, dans les demandes de fusion et dans les commits ; les agents travaillant sur la tâche y accèdent également.

Ce que la provenance répond#

• Origine. Ce qui a déclenché le travail, avec un lien vers l'élément concerné : une conversation de chat, une révision de type Prepare Work, une demande de Nouveau travail, un problème importé ou généré par un webhook, un hook, un planning, un client MCP, le API, une constatation ou un rapport, ou encore un plan ou une tâche parent.
• Demandeur et propriétaire. La personne qui a demandé le travail et celle qui en est actuellement le propriétaire. Lorsque le travail provient d'un compte de service ou d'une personne extérieure à votre organisation, comme l'auteur d'un problème GitHub, la provenance indique ce compte ou cette personne. Coroid ne complète jamais ces informations par des données qu'il devrait deviner.
• Décisions. Les approbations, demandes de modification, démarrages, arrêts, nouvelles tentatives, fusions, substitutions et changements de propriété, chacun accompagné de l'auteur, de la date et, le cas échéant, de la raison.
• Discussion. Les messages échangés par les personnes ayant influencé le travail : de courts extraits des conversations ayant mené à sa création et des retours sur ses documents, chacun accompagné de l'auteur et d'un lien.
• Livraison. Les demandes de fusion, les commits, les verdicts de contrôle qualité, les décisions de révision et les preuves associées.

Une tâche appartenant à un plan partage l'origine et le demandeur du plan. Sa provenance indique également sa lignée : la tâche, son plan et son paquet de travail, ainsi que la conversation ou la demande qui les ont générés.

Résumé en premier#

Chaque vue de la provenance commence par un résumé, afin de vous permettre de voir d'un coup d'œil à quoi sert le travail et qui en est à l'origine :

• Intention: ce que fait le travail et pourquoi, sous forme de paragraphe court. Cette information provient de l'intention approuvée, sinon de la spécification approuvée, sinon de la demande initiale, sinon de la description de la tâche ou du plan. Une ligne ci-dessous précise l'origine de ces informations.
• Demandé par: la personne, le compte de service ou l'interlocuteur externe qui a fait la demande.
• Propriétaire: celui qui possède actuellement le travail. Il s'agit de la dernière personne à qui il a été transféré, sinon de la personne à qui la tâche est assignée, sinon du propriétaire de la conversation ayant donné naissance au travail, sinon du demandeur.
• Approuvé par: les personnes ayant approuvé l'intention, les spécifications, le plan d'implémentation et le plan lui-même, avec le rôle qu'elles ont approuvé.
• Décisions clés: jusqu'à cinq des dernières décisions prises par les utilisateurs, accompagnées de leur raison d'être.

Les personnes listées comme approuvantes sont toujours des humains. Une approbation enregistrée automatiquement par Coroid n'est pas incluse ; consultez Décisions automatiques.

Où vous le voyez#

Dans le portail#

Ouvrez une tâche ou un plan dans l’Usine et développez la section provenance. Sous le résumé, vous trouverez les éléments suivants :

• Origine: l'origine du travail, avec un lien vers la conversation, la demande, l'issue ou le rapport correspondant.
• Lignée: le plan et le lot de travaux auxquels appartient une tâche, lorsqu'elle est rattachée à un plan.
• Décisions: classées du plus ancien au plus récent, chacune accompagnée de sa justification. Huit décisions les plus récentes sont affichées ; un clic permet d'en voir davantage.
• Discussion: les messages ayant influencé l'élaboration des travaux, classés du plus récent au plus ancien.
• Livraison: les demandes de fusion, les personnes ayant effectué la fusion, les commits, les verdicts de contrôle qualité, les révisions et les preuves associées.

Une version condensée s'affiche dans l'onglet Détails d'une tâche et dans la révision de promotion d'un plan, avec un lien vers l'ensemble des données de provenance.

L'accès aux données de provenance suit le parcours des travaux. La provenance d'une tâche nécessite un accès en lecture au projet concerné, tandis que celle d'un plan est consultable au niveau de toute l'organisation, tout comme le plan lui-même.

Dans les demandes de fusion#

Chaque pull request Coroid ouvert comporte une section provenance, qu'il s'agisse d'une tâche, d'un plan ou d'un pull request de version. Cette section débute par le même résumé : l'intention, le travail à réaliser, la personne ayant demandé le travail, le propriétaire du travail, l'approbateur et les décisions clés. L'origine et ses liens suivent ensuite, puis la lignée, les décisions prises, la livraison et un lien pour ouvrir le travail dans Coroid.

Coroid rédige les autres sections autour de celle-ci : un résumé de la modification, un lien vers la tâche et les preuves de révision, les critères d'acceptation, ainsi que l'état des contrôles qualité et de la révision.

Coroid ne gère que les sections qu'il marque avec des commentaires cachés dans la description. Lorsqu'il met à jour le pull request, après une refonte par exemple, il remplace ces sections tout en conservant intégralement ce que vous ou vos réviseurs avez écrit. Si l'historique est trop long pour tenir dans la section, les décisions les plus anciennes sont supprimées en premier et la section indique que le reste se trouve dans Coroid.

Un pull request de version liste chacun des pull request regroupés : ce qu'il livre, la personne ayant demandé le travail et l'approbateur, dans l'ordre de fusion.

Dans les commits#

Chaque commit généré par Coroid se termine par des trailers indiquant le travail auquel il appartient :

Coroid-Task: 3f6e2b1c-7d4a-4c1e-9b2f-0a8d5e6c7b91
Coroid-Plan: 8a41b7c3-25d0-4f6b-a1e9-6c3d2b7f4e05
Coroid-Requested-By: Maya Lindqvist
Coroid-Origin: prepare_work

Selon le type de travail, un commit mentionne également sa tâche de plan, son lot de travail, son exécution d'agent, son correctif ou sa version. Le trailer du demandeur indique un nom, jamais une adresse e-mail.

Coroid est l'initiateur de chaque commit qu'il génère. Lorsqu'un commit est rédigé à partir du compte d'une personne connectée, Coroid s'ajoute également en tant que co-auteur :

Co-authored-by: Coroid <ai@coroid.ai>

Coroid conserve également sa propre cartographie reliant chaque commit à la tâche ou au plan concerné. Lorsqu'une demande de fusion de pull request ouverte par Coroid est intégrée dans GitHub ou GitLab, Coroid enregistre le commit de fusion ou de regroupement généré, afin qu'une fusion par regroupement ne rompe pas ce lien.

Pour les agents#

L'ordre de travail de chaque agent sur une tâche résume sa provenance : pourquoi le travail existe, qui l'a demandé, qui en est responsable et quelles décisions ont été prises. Lorsqu'un agent a besoin d'en savoir plus, il peut consulter le dossier complet, une section à la fois.

Les spécifications restent prépondérantes. Si la provenance et les spécifications diffèrent, un agent suit les spécifications et mentionne le conflit dans son rapport au lieu de prendre une décision en secret. Les messages et justifications rédigés par les humains passent par le filtre anti-injection de prompt de Coroid avant que l'agent ne les lise, et le texte bloqué par ce filtre n'est pas transmis.

Ce qui n'est jamais envoyé à votre hôte Git#

Le texte des conversations n'est jamais écrit dans un pull request ni dans un commit. Une demande d'intégration porte les noms, les rôles, les décisions, les raisons et les liens. La discussion n'apparaît que sous forme de nombre de messages et des noms des auteurs, avec un lien vers la conversation dans Coroid. Les adresses e-mail ne sont jamais inscrites ; les personnes sont identifiées par leur nom.

Liens uniquement#

Par défaut, la section provenance d'un pull request inclut le paragraphe d'intention, les décisions clés et les raisons avancées par les personnes. Une organisation peut opter pour l'affichage de liens uniquement. Cette section indique alors qui a demandé le travail, qui en est le propriétaire, qui a donné son approbation, les décisions prises et les liens vers Coroid, tout en omettant le paragraphe d'intention, les décisions clés et chaque raison.

Choisissez l'option « Liens uniquement » lorsque des personnes non autorisées à consulter vos justifications produit peuvent accéder à votre dépôt, par exemple dans le cas d'un dépôt public. Ce choix s'applique aux demandes d'intégration que Coroid ouvre ou met à jour après sa sélection. Il n'existe pas encore d'interface de configuration pour cela. Contactez-nous pour passer votre organisation en mode « Liens uniquement ».

Décisions et leurs raisons#

Coroid enregistre qui a pris quelle décision au fur et à mesure de l'avancement du travail : approbations de l'intention, des spécifications et des plans, qualifications, démarrages, arrêts, nouvelles tentatives et achèvements manuels, fusions et fusions forcées, exceptions aux contrôles, approbations de publication, modifications du propriétaire ou des participants à une conversation, ainsi que les verdicts des agents de contrôle qualité et de révision, et du coordinateur.

Lorsque vous approuvez et lancez un plan, démarrez un plan, arrêtez une tâche ou retentez une tâche, la confirmation vous invite à saisir une raison optionnelle pouvant atteindre 2 000 caractères. Elle est sauvegardée avec votre nom dans la provenance du travail, et affichée dans les demandes d'intégration sauf si votre organisation utilise l'option « Liens uniquement ». Une seule phrase suffit. « Les clients l'ont demandé avant la campagne du printemps » renseigne le lecteur plus efficacement qu'une simple approbation. Une fusion forcée nécessite déjà une raison écrite, qui est enregistrée de la même manière.

Décisions automatiques#

Certaines décisions sont enregistrées au nom de quelqu'un plutôt qu'établies par cette personne. Le contrat de livraison d'une tâche de plan est approuvé automatiquement à partir du plan approuvé, et un plan approuvé sans personne désigne son créateur comme représentant. La chronologie étiquette ces décisions « Automatiques », et elles ne comptent jamais comme une approbation personnelle.

Les décisions prises par les agents, comme les verdicts de contrôle qualité et de révision, ainsi que celles du coordinateur, apparaissent sous le nom de l'agent avec le résumé qu'il a fourni.

Ajouter du contexte à une tâche en cours#

Vous pouvez transmettre des informations aux agents pendant l'exécution d'une tâche, sans l'interrompre. Ouvrez l'onglet Activité de la tâche et sélectionnez « Ajouter du contexte » à côté de l'activité en cours. Rédigez les informations que les agents doivent connaître, jusqu'à 2 000 caractères, puis confirmez.

• Lorsqu'un agent est en cours d'exécution, il lit votre message lors de son prochain tour d'action. Un coordinateur qui attend qu'un autre agent termine se réveille pour le lire.
• Si aucun agent n'est en cours d'exécution, le prochain agent à démarrer le lira.

Le message est enregistré dans la provenance de la tâche en tant que décision « Contexte ajouté », avec votre nom. Il ne modifie pas ce que la tâche doit livrer : si votre message entre en conflit avec les spécifications, l'agent signalera ce conflit au lieu de choisir silencieusement. Pour modifier le résultat, modifiez les spécifications ou renvoyez la tâche en tant que nouveau travail.

Pour ajouter du contexte, un accès en écriture au projet de la tâche est requis. Les tâches terminées ou annulées ne permettent pas cette action.

Retracer le code jusqu'à son origine#

Vous pouvez partir d'une ligne de code et retrouver le travail qui l'a générée. Le portail, les agents, les clients MCP et Git vous y mènent tous.

Pourquoi cela se trouve-t-il ici ?#

Lors de la révision de code d'une tâche, chaque portion modifiant des lignes existantes dispose de ce bouton. Il recherche les commits ayant dernièrement modifié ces lignes sur la branche cible et affiche leur provenance :

• Réalisé par Coroid: la tâche ou le plan, avec son intention, la personne qui l'a demandée et approuvée, les décisions clés et un lien vers la provenance complète.
• Créé en dehors de Coroid: aucune Tâche ou Plan ne détaille la raison de cette modification ; ainsi vous voyez l'auteur et la date.

Un fichier ajouté par la modification ne contient aucune ligne antérieure, donc il n'y a pas de bouton.

Avec un agent ou un client MCP#

Les agents et les clients MCP posent la même question à l’aide d’un outil. Celui-ci prend en entrée un fichier et, si vous le souhaitez, une plage de lignes ainsi qu’une branche, une balise ou un commit. Il renvoie chaque plage de lignes avec le commit qui l’a modifiée en dernier. Pour un commit créé par Coroid, il renvoie également la tâche ou le plan associé et résume sa provenance. L’outil s’appelle explain_code.

• Agents: Les agents Développeur, Réviseur et coordinateur de Coroid le consultent avant de modifier ou supprimer du code dont l’objectif n’est pas clair.
• Clients MCP: il s'agit d'un outil en lecture seule ; il nécessite donc le rôle de réviseur et cette portée : mcp.read. Il fonctionne uniquement dans les projets accessibles via la connexion et autorise 30 appels par minute.

Avec Git#

Chaque commit réalisé par Coroid nomme son travail dans ses en-têtes, ce qui permet également à Git de vous y conduire :

git blame -L 120,120 src/search/alerts.ts   # the commit that last changed line 120
git log -1 <sha>                            # its Coroid-Task or Coroid-Plan trailer

Ouvrez ensuite cette tâche ou ce plan dans le portail pour consulter sa provenance :

• Tâche : https://client.coroid.ai/factory/task:<task id>?panel=provenance
• Plan : https://client.coroid.ai/factory/<plan id>#provenance

Pour un commit de fusion ou de regroupement, ouvrez le pull request dont il provient. Sa section de provenance renvoie vers Coroid.

Exporter la provenance#

Le panneau propose deux boutons de téléchargement en haut. Le format Markdown permet de télécharger la provenance sous forme de document avec un résumé en premier : il présente la même structure que la section pull request, avec les motifs et sans le texte des conversations. JSON permet de télécharger l'ensemble du registre, y compris les extraits de discussion, pour vos propres archives ou outils. Conservez le fichier JSON aussi privé que la conversation qu'il cite.

Origine non enregistrée#

Coroid enregistre la provenance pour les travaux créés après l'introduction de cette fonctionnalité. Les travaux plus anciens affichent ce message au lieu d'une origine :

Origine non enregistrée. Ce travail a été créé avant que Coroid n'enregistre la provenance.

Lorsque Coroid connaît une source grâce à des enregistrements antérieurs, comme la conversation ayant donné naissance à un plan ou le rapport associé, le panneau l'affiche comme une source connue. Les décisions déjà enregistrées auparavant, comme les approbations de documents, apparaissent toujours ; d'autres peuvent être absentes.

Une origine étiquetée « Dérivée » a été reconstituée à partir d'enregistrements antérieurs plutôt qu'être capturée lors de la création du travail.

Liés#

• Tâches
• Plans
• Réviser et fusionner le résultat
• Assistant de chat
• Spécifications
• Coroid en tant que serveur MCP