Journal
Privilégier les données factuelles plutôt que les affirmations : ce qui a changé, ce que l'expérience nous a réellement appris, et comment le positionnement du projet lui-même a été redéfini sur la base de preuves.
Tout dans cette section est associé à une date, et chaque date peut être vérifiée par rapport à l’historique du référentiel. C’est le but de cette section : une affirmation que vous ne pouvez pas contredire ne vaut pas la peine d’être publiée.
Ce sont des documents de travail internes, présentés tels qu’ils ont été écrits : le vocabulaire propre au projet, les noms de phases et de fichiers inclus, sans être réécrits pour une meilleure lisibilité. Un journal nettoyé a posteriori cesse d’être une preuve.
À quoi sert chaque enregistrement
Le journal de développement enregistre les décisions, et non les commits : il explique pourquoi quelque chose a changé d’une certaine manière, et quel était le coût des alternatives. Il est rédigé pendant le travail, ce qui explique parfois qu’il soit maladroit : il comprend également les revirements, y compris la soirée où l’affirmation de positionnement du projet lui-même a été réécrite sur la base de preuves concrètes plutôt que d’intuition.
Comment les modèles se comportent enregistre ce que les modèles de langage font réellement avec cet outil, y compris ce qu’ils font de mal.
L’accessibilité web enregistre ce que les sources publiques répondent réellement à l’étape de découverte d’un agent — en comptant, et non en supposant. La constatation →
Pourquoi les échecs se produisent ici
Un projet qui ne publie que ses succès ne vous en dit rien sur le jour où il ne fonctionnera pas pour vous. Ce journal enregistre un véritable problème non détecté qui a modifié la propre description du projet, une réelle fuite de confinement découverte et corrigée le même jour, ainsi que les mesures qui ont permis de les identifier.