Un carré vert prouve qu’une contribution a été enregistrée ce jour-là. Il ne prouve ni l’ampleur du travail, ni son lien avec un objectif précis. LifeQuest réduit cet écart en demandant de créer la quête avant le travail, puis de vérifier qu’un push GitHub admissible a eu lieu après sa création.
Imaginons Malik, étudiant à Lyon, seul devant son ordinateur à 23 h 18. Une démonstration de son projet l’attend le lendemain. L’écran de connexion échoue encore, son café est froid, et le dépôt affiche pourtant un carré vert rassurant. Ce carré vient d’une correction minuscule, un caractère remplacé dans un commentaire.
Le même carré aurait pu représenter la fonctionnalité d’authentification terminée et envoyée. À cet instant, Malik risque d’arriver avec une démo inutilisable tout en contemplant une trace qui ressemble à du progrès.
Un carré mesure une contribution, pas la promesse tenue
Le calendrier GitHub répond correctement à une question limitée: une activité comptabilisée a-t-elle eu lieu aujourd’hui? Il ne connaît pas la promesse que Malik s’était faite en début de soirée. Il ignore s’il voulait corriger une faute, terminer l’écran de connexion ou préparer une version présentable.
Cette limite devient gênante dès qu’un indicateur sert de tableau de bord personnel. Le cerveau aime les signaux simples. Une case colorée donne une impression de continuité, puis cette continuité peut se transformer en conclusion trop généreuse: « J’ai avancé sur mon projet. »
Le carré n’a pas menti sur l’activité. Il a laissé Malik lui faire dire davantage.
Le problème ressemble à celui des séries entretenues par une coche quotidienne. Une trace peut être exacte tout en restant trop pauvre pour décrire le travail accompli. C’est aussi la question posée dans Que prouvent vraiment 47 jours de série sans aucune trace de progrès?.
Déclarer la quête avant de produire la preuve
À 23 h 31, Malik change sa manière de suivre la soirée. Il crée une quête dans le domaine Craft: « Faire fonctionner la connexion dans la démo de demain. » Cette formulation fixe la cible avant le prochain push.
C’est le rôle de la règle « quête, puis push » de LifeQuest. Pour une quête de programmation admissible, la vérification GitHub cherche un push effectué après la création de la quête. Si la vérification aboutit, Malik reçoit l’XP complet. Il ne peut pas choisir après coup une ancienne activité dans son historique et l’habiller comme la preuve d’un objectif formulé plus tard.
La différence tient à l’ordre des événements:
- Malik nomme le résultat visé.
- Il travaille sur ce résultat.
- Il effectue un push admissible.
- LifeQuest vérifie que le push est postérieur à la quête.
L’intention précède ainsi la trace. Cette chronologie ne mesure pas le nombre de lignes utiles et ne juge pas la qualité du code. Elle établit une relation plus solide entre un engagement déclaré et une action observable.
LifeQuest consulte les événements publics GitHub à partir du nom d’utilisateur associé. Il ne demande ni jeton GitHub ni accès aux dépôts privés. Les événements peuvent aussi être mis en cache pendant quelques minutes, donc un push récent peut ne pas apparaître immédiatement.
Ce que la vérification peut réellement affirmer
Supposons que Malik crée sa quête, puis pousse une autre correction d’un seul caractère. La chronologie serait respectée. LifeQuest ne devrait pas prétendre que la fonctionnalité est terminée, car un push ne révèle pas à lui seul la valeur du changement.
La preuve soutient une affirmation précise: une action GitHub admissible a suivi la création de cette quête Craft. Elle rend les anciennes contributions inutilisables comme justificatifs rétroactifs et distingue mieux une soirée engagée vers un objectif d’un carré vert trouvé dans le calendrier.
Cette retenue compte. Un système de progression perd sa valeur lorsqu’il transforme chaque signal disponible en verdict absolu. Photo, minuterie serveur, push GitHub et auto-déclaration répondent à des situations différentes. LifeQuest propose les méthodes réellement adaptées à chaque quête au lieu d’afficher une case de validation identique partout.
Quand aucune preuve objective ne convient, l’auto-déclaration reste disponible pour la moitié de l’XP. L’activité n’est pas effacée. Son niveau de preuve apparaît simplement dans la récompense.
Le lendemain, le carré retrouve sa juste place
À 00 h 42, Malik effectue enfin le push lié à l’écran de connexion. La démo fonctionne sur sa machine. LifeQuest peut vérifier l’ordre entre la quête et le push, puis attribuer l’XP complet si l’événement est accepté.
Le lendemain matin, le carré vert est toujours là. Malik le regarde différemment. Il indique une contribution, rien de plus. La quête conserve la formulation de ce qu’il avait décidé d’accomplir, et la vérification conserve la trace venue ensuite.
Pour vos propres projets, écrivez donc l’objectif avant d’ouvrir l’éditeur. Donnez-lui un résultat observable, puis choisissez une preuve adaptée. Une trace devient utile lorsqu’elle répond à une promesse clairement formulée.
Commentaires
Pas encore de commentaires.