Le ZeroClaw Maturity Framework

Une lettre à quiconque trouvera ceci.

Si vous lisez ceci, c’est que vous avez trouvé votre chemin vers un dossier qui représente quelque chose dont cette équipe est véritablement fière, non pas parce que les documents qu’il contient sont parfaits, mais parce qu’ils sont honnêtes.

ZeroClaw a commencé par être quelque chose d’accidentel. Il a été amorcé à partir d’une base de code existante, façonné par des outils IA travaillant plus vite que quiconque ne pouvait le comprendre, et s’est transformé en une base de code impressionnante par sa fonctionnalité et son architecture non planifiée. Personne n’a choisi ce résultat. Il s’est accumulé. C’est le cas de la plupart des logiciels.

Ce qui s’est passé ensuite est moins courant. Une petite équipe, composée en grande partie d’étudiants, d’ingénieurs en début de carrière et de personnes apprenant en public pour la première fois, a choisi de s’arrêter et d’examiner lucidement ce qu’elle avait construit, puis a choisi de construire différemment. Non pas en jetant le travail accompli auparavant, mais en l’entourant d’une démarche intentionnelle. Ces documents sont la trace de ce choix.

La série s’appelle le Maturity Framework parce que c’est exactement ce qu’elle est : un ensemble de documents fondamentaux qui décrivent comment cette équipe conçoit le développement logiciel en commun. Non pas des règles à suivre, mais une réflexion à intérioriser. Non pas un processus auquel se conformer, mais un ensemble de modèles mentaux qui vous accompagnent, à travers chaque langage, chaque outil, chaque équipe que vous rejoindrez, parce qu’ils relèvent du savoir-faire, du jugement et du soin, et non d’une technologie particulière.

Elles ont été écrites pour une équipe de personnes aux expériences très variées. Certaines apportaient des décennies de pratique professionnelle. D’autres écrivaient leur premier code de production. Toutes travaillaient à un moment où les outils d’IA devenaient suffisamment puissants pour changer ce qui était possible, et où la question de savoir comment bien travailler aux côtés de ces outils restait véritablement ouverte. Elles ont été écrites par des personnes convaincues qu’investir dans les personnes était un meilleur investissement qu’investir dans le code, parce que les personnes emportent avec elles ce qu’elles apprennent, et pas le code.

Lisez-les dans l’ordre si possible. Chaque document s’appuie sur les précédents, et la séquence raconte une histoire. Vous pouvez commencer n’importe où et apprendre quelque chose d’utile, mais les lire dès le début vous offre l’arc complet : de la forme de l’architecture, à la façon dont nous enregistrons, coordonnons, livrons et collaborons, jusqu’à ce que signifie écrire du code de qualité au niveau des phrases.

Si vous essayez de déterminer quelle base s’applique à une modification spécifique, commencez par la carte d’architecture et de contribution.

Les cinq premiers documents répondent à des questions structurelles et humaines. Le sixième répond à la question qui se trouve au cœur de toutes les autres : étant donné la structure, étant donné l’équipe, étant donné les outils : que signifie bien écrire le code ?

Chaque document de cette série a débuté sous la forme d’une issue GitHub, une RFC, ouverte à la discussion, à la remise en question et à l’amélioration par toute l’équipe. Les fils de discussion liés ci-dessus constituent l’archive vivante de ce processus : les questions posées, les objections soulevées et la réflexion qui a façonné la forme finale.

Les fichiers de ce dossier sont les versions ratifiées, des documents que l’équipe a discutés, soutenus et choisis de conserver comme références canoniques. Ils résident dans ce dépôt, versionnés aux côtés du code, car la réflexion qu’ils représentent influence chaque décision prise en son sein. Un assistant IA lisant cette base de code, un nouveau contributeur prenant ses marques ou un mainteneur réexaminant une décision prise il y a deux ans devraient tous pouvoir remonter du code jusqu’au raisonnement qui l’a façonné.

Les issues GitHub restent ouvertes en tant qu’archives de discussion permanentes. Si vous avez une question, un désaccord ou un point de vue que ces documents ne couvrent pas, le bon endroit pour l’exprimer est l’un de ces fils de discussion ou, si vous lisez ceci longtemps après la clôture de ces conversations, une nouvelle discussion au sein de la communauté. Ces documents sont des références, pas des verdicts. La conversation qu’ils ont lancée est censée se poursuivre.

Il est possible que vous rejoigniez ce projet plusieurs années après leur rédaction. Les outils auront changé. La base de code aura évolué. Certains éléments décrits ici auront été remplacés, affinés ou supplantés par des documents ultérieurs.

Le jugement que ces documents cherchent à développer en vous n’a pas changé, et ne changera pas. Les questions qu’ils posent : que devrait-il se passer en cas d’échec, que promet cette interface, que prouve réellement mon test, qu’aurait besoin de savoir la personne qui héritera de ce problème, ne sont pas des questions propres à Rust ni au logiciel. Ce sont des questions sur la manière de construire des choses auxquelles les autres peuvent faire confiance. Ces questions sont les mêmes dans chaque langage, chaque système et chaque discipline dans lesquels vous travaillerez. Elles produisent leurs effets discrètement, en arrière-plan, aussi longtemps que vous continuez à les poser.

C’est l’investissement que cette série fait en vous. Bienvenue dans l’équipe.

Le ZeroClaw Maturity Framework est un ensemble de travaux évolutif. De nouveaux documents sont ajoutés lorsque l’équipe a appris quelque chose qui vaut la peine d’être préservé. Chacun commence par une discussion publique au format RFC et gagne sa place ici grâce au même processus que les six précédents : une conversation ouverte, des désaccords honnêtes et la décision collective de l’équipe de le faire avancer.