Le samedi où le build a cessé de discuter

Les correctifs qui ne produisent pas de capture d'écran sont ceux qui décident si votre runtime est livré ou non. RakuAI a passé une semaine à éliminer les points faibles pour que les huit prochains mois de construction ne discutent plus jamais avec le build.

Il existe une catégorie de travail qui ne produit pas de capture d’écran. Elle produit un build qui passe au vert sur des machines qui le faisaient passer au rouge. Elle produit une exécution CI qui cesse d’expirer. Elle produit une trace de pile qui ne se matérialise plus parce que le pointeur nul qui la causait est désormais intercepté à la frontière. La semaine qui s’est achevée ce samedi était de cette nature.

Dix-huit DLL au vert sous Linux

Le runtime est livré sous forme de dix-huit DLL natives. Jusqu’à il y a deux semaines, ces DLL compilaient proprement sous Windows et proprement sous macOS et cassaient sous Linux sur une erreur de visibilité de symboles. Le correctif est arrivé dans la PR #1463 le 11 avril.

L’histoire est du genre peu glamour. GCC rend par défaut chaque symbole visible dans les bibliothèques partagées. MSVC rend par défaut chaque symbole caché sauf s’il est explicitement exporté. Le code du runtime avait été écrit en supposant le comportement par défaut de MSVC, avec __declspec(dllexport) sur les symboles devant traverser la frontière de la DLL. Sous Linux, ces déclarations sont des no-op, ce qui signifie que chaque symbole était visible, ce qui signifie que l’éditeur de liens ne pouvait pas déterminer les bonnes liaisons intra-DLL, ce qui signifie qu’un certain nombre des dix-huit DLL ne compilaient pas.

Le correctif est -fvisibility=hidden comme drapeau de compilateur pour les builds GCC, avec des attributs de visibilité explicites sur les symboles qui doivent être exportés. Le diff est petit. Le rayon d’impact est large. Le build Linux est maintenant une cible de première classe. L’agent qui livre un changement de runtime peut désormais le faire tester automatiquement sous Linux par la matrice CI. Les déploiements serveur, les images conteneur, les fermes de build cloud, tout cela est maintenant à portée.

C’est le genre de correctif qui a l’air d’une déduction fiscale. Il ne fait pas avancer le produit. Il ne le bloque plus non plus. Cela suffit.

Garde-fous de longueur de prompt sur chaque appelant LLM

L’autre commit d’avril qui mérite d’être consigné est le balayage des garde-fous de longueur de prompt. Le runtime invoque désormais Claude à plusieurs endroits : le cerveau de comportement des PNJ, le modèle de dialogue, le narrateur d’événements du monde, l’ensemenceur de contenu procédural. Chacun de ces appelants construit un prompt en concaténant contexte, instructions, et état courant. Chacun de ces appelants peut produire un prompt qui dépasse la fenêtre d’entrée du modèle si le contexte grossit suffisamment.

Le mode d’échec naïf est que l’appel LLM renvoie une erreur. Le mode d’échec dangereux est que l’appel LLM renvoie une réponse tronquée, que l’appelant ne détecte pas la troncature, et que le moteur agisse sur une réponse malformée. Des PNJ qui s’arrêtent en plein milieu d’une phrase. Des arbres de dialogue qui bifurquent vers rien. Des événements du monde qui se déclenchent avec les mauvais paramètres.

La PR #1465 a ajouté un garde-fou à chaque appelant LLM : estimer le nombre de tokens avant l’appel, refuser d’envoyer si le nombre dépasse le budget, et émettre une erreur structurée à laquelle l’appelant peut réagir. La PR #1466 a audité l’ensemble du code pour vérifier que le garde-fou est en place à chaque point d’appel. La PR #1467 a ajouté de la documentation pour que le prochain appelant connaisse la discipline.

La raison pour laquelle cela compte est que les appels IA à l’intérieur d’un runtime ne sont pas occasionnels. Ils se produisent de nombreuses fois par image au pic. Un bug dans la construction du prompt qui fait grossir un prompt de quelques tokens par appel est invisible pendant cent images et catastrophique à mille. Le garde-fou rend l’échec bruyant et borné au lieu de silencieux et illimité.

Stabilisation de l’espace de noms de l’API

Le troisième commit est le plus discret des trois et possiblement le plus lourd de conséquences. Le runtime expose une API REST pour que les outils externes, les tableaux de bord, et le SDK puissent lui parler. Cette API a vécu sous /api/v2/ pendant les six derniers mois parce qu’elle succédait à un /api/v1/ antérieur qui était strictement interne.

/api/v2/ est le mauvais nom. Il laisse entendre que la v1 était publique et dépassée, ce qui n’était pas le cas. Il laisse aussi entendre qu’une v3 est en route, ce qui n’est pas le cas. La PR #1464 a parcouru chaque référence dans le code et chaque référence dans la documentation et a renommé l’espace de noms de /api/v2/ à /api/raku/. Le nom est maintenant stable. Il n’y a plus de numéro de version à négocier plus tard. La compatibilité ascendante au sein de l’espace de noms est le contrat.

C’est le genre de renommage qui doit se produire exactement une fois et doit se produire avant qu’un développeur externe n’écrive du code contre l’espace de noms. Nous l’avons attrapé à temps. La prochaine fois que quelqu’un hors de l’équipe écrira un script qui frappe l’API, il verra /api/raku/ et n’aura pas à refaire son travail dans six mois.

La sécurité pointeur-nul comme balayage

Le commit le plus récent sur le runtime, il y a deux jours le 30 avril, est 58c3a806 : « fix(build): resolve all build errors, warnings, and null-pointer safety ». L’expression « sécurité pointeur-nul » fait beaucoup de travail dans ce titre. Le changement en dessous est un balayage du code à la recherche de chaque endroit où un pointeur pouvait être nul et était déréférencé sans contrôle.

Le motif qui a déclenché le balayage était un rapport de plantage provenant de l’une des applications d’exemple. Un chargeur de texture recevait un pointeur nul pour le manifeste d’asset, le déréférençait, et plantait. Le correctif était un contrôle au point d’entrée. L’audit était la question : combien d’autres endroits dans le code ont le même motif.

La réponse était plusieurs dizaines. Tous n’étaient pas exploitables. Beaucoup étaient des chemins de code qui n’avaient jamais été atteints parce que le code appelant ne se trouvait jamais, par hasard, passer un nul. Ce n’est pas une défense. La défense est le contrôle à la frontière.

Le balayage a ajouté les contrôles. Il n’a pas changé le comportement dans le chemin nominal. Il a ajouté une valeur de retour (RAKU_ERR_INVALID_PARAM) et une ligne de journal pour le chemin d’échec. Le runtime est désormais plus bruyant dans les cas qui étaient auparavant des plantages silencieux. Bruyant vaut mieux que silencieux. Les plantages silencieux dans un runtime AR sont le pire genre de bug.

Pourquoi ce genre de semaine est le bon genre à avoir

La tentation, quand on fait tourner un projet de moteur au rythme du week-end avec une flotte d’agents, est de continuer à livrer de nouvelles fonctionnalités. Chaque samedi matin, la file d’attente se remplit à nouveau. Chaque samedi soir, le diff est plus gros qu’il ne l’était la semaine précédente. Le rythme récompense le mouvement vers l’avant.

Le rythme tolère aussi la dette technique. Chaque PR fusionnée au cours des huit derniers mois a fait une petite hypothèse sur l’environnement de build, la surface de l’API, la fenêtre d’entrée du LLM, ou le contrat de sécurité des pointeurs nuls. Aucune de ces hypothèses n’était fausse en elle-même. Ensemble, elles formaient une liste de points faibles qui, tôt ou tard, allaient craquer.

Une semaine à arrêter le mouvement vers l’avant pour corriger les points faibles n’est pas du temps perdu. C’est la semaine après laquelle les huit prochains mois de mouvement vers l’avant peuvent se produire sans discuter avec le build, l’API, l’entrée LLM, ou le pointeur nul. C’est la discussion qui gaspille le temps. C’est cette discussion que le nettoyage a fait cesser.

Ce qui vient ensuite

Les agents sont de retour à la file d’attente ce week-end. Le prochain lot de tickets est celui que je dépose ce samedi matin. Ce ne sont plus des tickets de nettoyage. Ce sont des tickets de fonctionnalité. Le build ne discutera pas avec eux.

C’est ce qu’achète un build propre. Pas une capture d’écran. La permission de livrer.