Rendu: aidd-level #41

Activity

1. JonaPlaz

   added

   renduProjet renduProjet rendu

   on Aug 31, 2026
2. blafourcade commented on Sep 4, 2026

   

   blafourcade

   on Sep 4, 2026

   Contributor

   More actions

   Merci pour ce rendu. Voici ce qu'on en a retenu, après l'avoir installé, lancé
   sur les huit profils dans un conteneur isolé, et lu de bout en bout.

   Ce qu'on a regardé

   • Vidéo. Dans le dépôt, avec le scénario écrit à côté.
   • Dépôt. 304 fichiers, licence MIT, un README qui liste les commandes, dit ce que l'outil lit et ce qu'il ne lit pas, et recopie la sortie réelle en entier.
   • Documentation. Dix specs numérotées, plus la méthode, la calibration, le format de sortie, et un journal.
   • Harnais. AGENTS.md comme source unique, CLAUDE.md pour les spécificités, trois agents, trois skills, sept scripts dont cinq déclenchés automatiquement.
   • Intégration continue. Deux workflows. Tests, analyse statique au niveau maximum, détection de copier-coller, et les tests de tes propres hooks.
   • Tests. 247 tests et 763 vérifications, tous verts en une fraction de seconde, plus onze jeux d'essai que tu as construits.
   • Interface. Pas d'écran. Une commande, une sortie texte, très détaillée.
   • Le calcul. Lu ligne par ligne, et testé sur tes onze jeux d'essai.
   • Un dossier abîmé exprès, pour voir comment il réagit.

   Comment ton outil marche

   • Le niveau est le plus bas des quatre axes. Quand plusieurs sont à égalité, tu les gardes tous au lieu d'en désigner un seul.
   • Quand un axe est incertain, l'incertitude remonte au verdict sous forme de fourchette. Le résultat n'est déclaré confirmé que si aucun axe n'en porte.
   • Une donnée absente n'est jamais transformée en zéro. Elle ouvre la fourchette.
   • Les seuils vivent dans le code, et chacun porte son origine juste au-dessus. Soit une source citée, soit la mention que tu l'as posé faute de mieux.
   • Cinq contrôles à l'entrée, dans l'ordre. Si l'un cède, tu dis « non évaluable » au lieu de calculer sur du vide.
   • Tu n'ouvres jamais la session ni le code, seulement leur présence. C'est un choix, et tu l'expliques.

   Ce qui marche bien

   • L'outil apporte son environnement. Une commande construit l'image, une autre lance l'évaluation dedans toute seule. Rien à installer, rien qui reste après.
   • Chaque chiffre indique d'où il vient, au format fichier › champ = valeur. C'est un verdict qu'on peut défendre devant la personne évaluée.
   • On voit ce que tu as emprunté et ce que tu as inventé. Certains seuils citent leur source. D'autres écrivent noir sur blanc « adaptation supposée, non sourcée ».
   • La calibration se rejoue en une commande et redonne les quatre niveaux annoncés dans le sujet. Ta doc date la lecture, cite le commit source, et affirme qu'aucun seuil n'a été ajusté après coup.
   • Le refus est un statut, pas un plantage. Un profil non évaluable est écarté sans interrompre les autres.
   • La médiane plutôt que le record, expliquée dans la sortie. « La moitié des PR fait mieux, l'autre moitié moins. » Ça coupe court à la contestation avant qu'elle arrive.

   Ce qu'on a préféré

   La fourchette au lieu du zéro. Un champ absent donne « entre Green et Copper », et tu nommes le manque au champ près. « Manque 9 pull requests. » On sait exactement quoi fournir.

   Et ton journal. Un fichier où tu notes les moments qui n'ont pas produit de commit. Un repli, une limite atteinte, un quota épuisé, chaque ligne avec sa référence. C'est la trace qu'on ne pense jamais à garder.

   Ce qu'on améliorerait

   • Quand l'activité git manque, tu n'as pas de seconde source. Ton choix de ne jamais ouvrir la session se défend, et il est documenté. Mais il a une conséquence. Le verdict devient « non évaluable » alors que la session raconte tout. Quelqu'un dont les dépôts appartiennent à ses clients reste hors de portée, et c'est justement le cas où ton outil rendrait le plus service. Garde git comme source principale, et ouvre la session en secours avec une confiance basse.
   • La preuve qui décide n'est pas toujours celle qui s'affiche. Sur un cas où c'est une relance encadrée qui fait monter l'axe, la sortie met en avant une autre justification. Afficher celle qui a tranché rendrait le raisonnement limpide.
   • Une seule forme de sortie, longue, et faite pour être lue. Le parti pris est bon. Un mode court et une sortie machine ouvriraient la CI et la comparaison entre deux dates.
   • Un fichier de contexte absent ne devient pas une fourchette, alors que tes autres signaux absents le deviennent.
   • Les pull requests sont analysées mais pas encore exploitées. Le fichier est lu, aucun calcul ne s'en sert pour l'instant.

   En résumé

   Un évaluateur PHP à trois couches, des specs numérotées, des jeux d'essai construits un par un, des hooks testés en intégration continue, un journal de ce qui n'a pas abouti, et son propre conteneur.

   Chaque seuil cite son origine, chaque chiffre affiché nomme son fichier, et une donnée absente devient une fourchette au lieu d'un zéro. Ta calibration se rejoue en une commande et redonne les quatre niveaux du sujet.

   Ce qu'on garde

   Le trio seuil nommé, origine écrite juste à côté, test qui le fige. Et ton journal de ce qui n'a pas abouti. C'est souvent là que se trouve l'apprentissage.

   ❤️React with ❤️1Reacted by Jonathan Plazanet
3. JonaPlaz commented on Sep 8, 2026

   

   JonaPlaz

   on Sep 8, 2026

   Author

   More actions

   Merci pour le temps passé :)