Aller au contenu
Documentation : Soumission et revue

Soumission et revue

Du brouillon à l'approbation : les statuts, les vérifications et ce que regardent les réviseurs.

La documentation fournie avec Ronne AI Marketplace 0.3.0, traduite de l'anglais.

Statuts

StatutSignification
draftTravail en cours, privé : seul son auteur le voit.
submittedEn attente d'un réviseur. Ses fichiers sont figés dans une révision.
changes requestedRenvoyé à son auteur, qui le modifie et le soumet de nouveau comme révision suivante. Le message du réviseur figure en haut de sa page.
approvedPrêt à être publié, par son auteur, un modérateur ou le root. Les soumissions approuvées attendent dans l'onglet To release de la file de revue, et peuvent être publiées plusieurs à la fois.
publishedPublié comme version.
rejectedFermé par un réviseur. La raison figure en haut de sa page et dans la conversation.
withdrawnRetiré de la revue par son auteur. Seul celui-ci le voit, sous Archived dans My submissions, et il peut le restaurer comme brouillon.

My submissions liste les vôtres une page à la fois (25, 50 ou 100), du changement le plus récent au plus ancien ou par nom, avec un lien pour chaque statut que vous avez et son nombre; les soumissions archivées ne figurent que sous Archived. Cherchez par une partie du nom de l'élément, ou choisissez un type; les deux s'affichent comme des puces, et les liens de statut conservent votre tri et votre taille de page.

Retirer : archiver ou supprimer

Withdraw est offert sur votre propre soumission jusqu'à sa publication : comme brouillon, en attente de revue, renvoyée pour changements ou approuvée. Il se trouve dans l'en-tête de sa page, sur sa ligne dans My submissions et sur sa page de revue. Une version publiée ne peut pas être retirée; utilisez plutôt Deprecate ou Yank. Au retrait, on vous demande quoi en faire :

  • Archive (par défaut) : elle quitte la revue et la liste de My submissions. Vous seul la voyez, sous le filtre Archived. Restore la ramène comme brouillon, avec ses fichiers, ses révisions et sa conversation; la prochaine soumission devient sa révision suivante.
  • Delete for good : elle est supprimée avec ses fichiers et son historique, et c'est irréversible. Ce choix n'est offert que tant qu'aucun réviseur ne l'a commentée ni n'a pris de décision à son sujet; ensuite, la conversation sert aussi de trace aux réviseurs, donc elle ne peut qu'être archivée. Une soumission archivée peut être supprimée de la même façon, depuis sa page ou le filtre Archived.

Dans les deux cas, le nom est libéré : une soumission archivée, comme un brouillon, ne le réserve pas. Ce qui en dépend est marqué bloqué tant qu'elle est archivée, et non soumis une fois qu'elle est supprimée. Le journal d'audit garde une trace de chaque suppression.

Les vérifications à la soumission

Un brouillon peut être enregistré avec des problèmes, mais la soumission attend qu'il n'y en ait plus. Dans l'éditeur, une icône rouge après le nom d'un fichier signifie qu'il contient des erreurs, et une icône ambre, seulement des avertissements : cliquez dessus pour les voir, puis sur l'un d'eux pour aller à sa ligne. Le résumé à côté du nom de l'élément les compte tous. Submit for review reste désactivé tant qu'il y a des erreurs ou des modifications non enregistrées (signalées par ● Unsaved changes à côté du nom). La boîte de dialogue de soumission vérifie ensuite :

  • le manifeste et les fichiers sont valides pour le type, et respectent les limites de taille;
  • le nom est libre : aucun élément publié, ni aucune soumission ouverte par quelqu'un d'autre, ne l'utilise;
  • chaque dépendance est permise pour le type, et publiée avec une version compatible, ou en revue : sa version est alors vérifiée quand celle-ci est publiée. Une dépendance qui n'est qu'un brouillon ne compte pas encore;
  • pour une proposition de changement : le type est celui de l'élément, elle change quelque chose, et aucun conflit de rebase ne reste ouvert.

Un brouillon sans aucun de ces problèmes est prêt. My submissions marque chaque brouillon Ready, ou indique combien de problèmes restent à corriger, et la soumission en bloc ne prend que les brouillons prêts. Les avertissements sont affichés mais ne l'empêchent pas.

Soumettre en bloc

Dans My submissions, chaque brouillon, et chaque soumission renvoyée pour changements, a une case à cocher quand il est prêt. Cochez ceux que vous voulez, ou Select all ready, puis Submit selected : la liste s'affiche et une confirmation vous est d'abord demandée, puis chacun est soumis séparément, avec le résultat pour chacun. Un brouillon qui a cessé d'être prêt entre-temps, parce que quelqu'un d'autre a soumis le même nom, indique pourquoi, et les autres partent quand même. Select all ready prend tous les brouillons prêts, y compris ceux d'autres pages ou masqués par une recherche.

Depuis un terminal, avec rmk :

rmk submit --all --dry-run          # what's ready, and what's in the way of the rest
rmk submit @team/reviewer @team/style
rmk submit --all                    # every ready one, after asking
  • Le nom d'un élément désigne votre brouillon ouvert de cet élément; s'il y en a plusieurs, désignez-le par l'identifiant dans son adresse. --all désigne tous vos brouillons et toutes vos soumissions renvoyées pour changements, les 100 plus récents à la fois.
  • Il vérifie d'abord, affiche Ready to submit et Not ready avec chaque problème, puis demande confirmation. Sans terminal, il faut --yes.
  • Il se termine avec le code 0 quand tout ce que vous avez désigné a été soumis, et 1 quand quelque chose ne l'a pas été.

Depuis votre outil d'IA, le serveur MCP du registre fait la même chose : check_drafts montre ce qui est prêt, et submit_drafts, pour lequel votre outil vous demande confirmation, le soumet.

Vos propres brouillons dont dépend un brouillon sélectionné sont inclus, et passent en premier : une fois qu'ils sont en revue, ce qui les utilise peut être soumis. Cocher un brouillon dans My submissions les coche aussi; rmk submit les liste sous Included, et --no-deps les laisse de côté. La suite est expliquée dans Dépendances en revue.

Les réviseurs peuvent aussi approuver en bloc : Approuver en bloc.

Dépendances en revue

Une soumission peut dépendre d'éléments pas encore publiés, tant qu'ils sont en revue : un skill et l'agent qui l'utilise passent en revue ensemble, plutôt qu'en un tour de revue chacun.

  • Waits on (attend) : dans My submissions et la file de revue, une icône de lien avec un nombre indique ce qu'une soumission attend : ambre tant que ses dépendances sont en attente, rouge quand l'une d'elles est bloquée; cliquez dessus pour voir chacune. La page de revue le dit en toutes lettres, par exemple Waits on @team/github (in review). Dans l'éditeur, chaque dépendance a un badge ambre à côté de son nom jusqu'à sa publication, et un rouge si elle est bloquée.
  • L'approbation n'attend pas : chaque élément a sa propre revue, et les réviseurs voient la marque.
  • La publication, si : Publish reste désactivé tant que toutes les dépendances ne sont pas publiées, et la plage de versions est vérifiée par rapport à la version obtenue. Publiez d'abord les dépendances.
  • Bloqué : quand une dépendance est rejetée ou archivée, ce qui en dépend est marqué bloqué, y compris plus bas dans une chaîne. Retirez-la des dépendances, ou dépendez d'un autre élément. Une nouvelle soumission du même nom lève le blocage.
  • Rejeter une dépendance : la boîte de dialogue de rejet liste ce qui en dépend et offre Request changes on them too, activé par défaut, avec un message distinct. Chacune est une décision à part, enregistrée avec le rejet comme cause. Une soumission du modérateur lui-même est sautée et nommée. Quand vous retirez votre propre soumission, on vous indique combien d'autres en dépendent.

Ce que regardent les réviseurs

Les réviseurs trouvent les soumissions sous Reviews, dans quatre onglets : Needs review et Waiting on the author (soumission la plus ancienne en premier), To release (approbation la plus ancienne en premier) et Decided (les plus récentes en premier). Chaque onglet est paginé, 25, 50 ou 100 à la fois, avec le total. Triez par la date de l'onglet ou par nom d'élément depuis les en-têtes de colonnes, et trouvez des soumissions par une partie du nom de l'élément ou de l'auteur, ou par type; les filtres s'affichent comme des puces.

Pour chaque soumission, les réviseurs lisent :

  • Ce qu'elle peut faire : des signaux de risque déduits des fichiers, comme un hook et la commande qu'il exécute, un serveur MCP, des règles de permissions, des fichiers exécutables, des scripts shell et des adresses web. L'auteur ne peut ni les définir ni les masquer. Les signaux décrivent; le réviseur décide.
  • Les changements depuis la dernière révision, ou tous les fichiers pour la première, comme la page de l'élément montre ceux d'une version : les fichiers dans une arborescence à côté de celui que vous choisissez, chaque fichier changé marqué ajouté, modifié ou supprimé, le Markdown rendu avec sa source à un onglet de distance. Le lien d'un signal de risque ouvre son fichier à la bonne ligne. Les fichiers de .ronne/, comme la disposition d'un canevas, ne sont pas publiés, donc ils ne sont pas affichés.
  • Les vérifications, et la conversation avec l'auteur.

Décisions

  • Approve : une seule approbation par un modérateur ou le root qui n'est pas l'auteur suffit. Elle vaut pour la révision que vous consultez : si l'auteur en soumet une nouvelle entre-temps, l'approbation n'aboutit pas, et vous examinez d'abord la nouvelle révision.
  • Request changes : la soumission retourne à son auteur, avec ce qu'il faut corriger. Une soumission approuvée peut aussi être renvoyée, jusqu'à sa publication.
  • Reject : la soumission est fermée, avec la raison. Quand d'autres soumissions en dépendent, la boîte de dialogue les liste et offre de demander des changements sur elles aussi (voir Dépendances en revue).
  • Override : le root peut approuver sa propre soumission. C'est marqué comme une dérogation (override) dans la conversation et le journal d'audit, avec ou sans raison.

L'approbation, dérogation comprise, accepte un message facultatif. La demande de changements et le rejet en exigent un, pour que l'auteur sache quoi corriger, ou pourquoi la soumission a été fermée : il le voit en haut de la page de sa soumission, et sous son nom dans My submissions. Chaque décision est enregistrée dans la conversation et le journal d'audit.

Où les trouver : dans Reviews, chaque ligne de Needs review se termine par Request changes et Reject, et chaque ligne de To release par Request changes. Toutes les décisions sont dans l'en-tête de la page de revue d'une soumission, que son nom ouvre. Pour en approuver plusieurs à la fois, utilisez Approve selected.

Votre propre soumission : les décisions s'affichent, mais grisées : un autre modérateur ou le root décide. Le root a aussi Approve (override) sur les siennes. Une proposition qui a besoin d'un rebase peut être renvoyée ou rejetée, mais pas approuvée avant d'être rebasée.

Approuver en bloc

Dans Reviews, sous Needs review, chaque soumission que vous pouvez approuver maintenant a une case à cocher. Cochez celles que vous voulez, ou Select all, puis Approve selected. Select all couvre la page affichée : affichez 100 soumissions par page, ou filtrez d'abord, pour en approuver davantage à la fois.

  • Certaines ne peuvent pas être sélectionnées, et leur case indique pourquoi : la soumission d'un modérateur lui-même (un autre réviseur l'approuve), ou une proposition de changement périmée, que son auteur doit d'abord rebaser.
  • Dans la confirmation, la liste défile de façon indépendante : filtrez-la par nom, type ou auteur, et décochez celles que vous voulez exclure.
  • La confirmation les liste en commençant par celles qui ont des signaux de risque, chaque signal nommé, pour que rien de risqué ne passe inaperçu. Celles du root sont marquées : elles sont approuvées comme dérogations.
  • Un seul message facultatif accompagne chaque approbation, comme s'il était tapé sur chaque page. Laissez-le vide pour n'en mettre aucun.
  • Chacune est approuvée séparément, et enregistrée comme une approbation normale dans sa conversation et le journal d'audit. Une soumission tranchée par quelqu'un d'autre, retirée ou devenue périmée entre-temps est signalée, et les autres sont quand même approuvées.

La demande de changements et le rejet restent une soumission à la fois, puisque chacun exige son propre message : chaque ligne les propose. La publication se fait toujours depuis chaque soumission approuvée.