Principes de conception

Chinaski décrit son propre recueil de règles dans son matériau source : certaines règles sont des positions d'ingénierie, d'autres des promesses de comportement, d'autres encore des règles de style à destination des contributeurs. Cette page rassemble les règles auxquelles le projet se tient, utile si vous évaluez le logiciel, ou envisagez de travailler dessus.

Les promesses

Petite liste de dépendances. Il y a neuf dépendances de production, et ce nombre est une cible que le projet refuse de faire croître négligemment. Chacune se livre avec le système d'exploitation, ce qui rend les installations fraîches reproductibles et les audits praticables.
Aucun code en exécution pour les lecteurs. Le site public est de simples fichiers ; l'application de publication ne répond jamais aux requêtes des lecteurs. Les pages destinées aux lecteurs ne portent aucun JavaScript à l'exécution ; c'est structurel : il n'existe aucun mécanisme par lequel un traceur ou un beacon pourrait être ajouté, donc il ne peut pas se retrouver là « par accident ».
Le site fonctionne après l'installation sans pod de services cloud. Pas de télémétrie, pas de serveur de licence à appeler, pas de polices ni d'icônes tirées des CDN d'autrui. Le fonctionnement air-gap est une règle énoncée ; même la licence commerciale prévue a été conçue pour fonctionner hors ligne.
Les builds sont délibérés. La publication ne survient jamais silencieusement en arrière-plan : un build est quelque chose que vous déclenchez (depuis le dashboard, un webhook, ou la ligne de commande), toujours avec des journaux que vous pouvez inspecter ensuite.
Les compromis sont énoncés, pas enterrés. Le projet dit sans détour ce qu'il ne fera pas : pas encore d'éditeur drag-and-drop, pas d'écosystème de plugins, une base de données single-tenant, et la responsabilité de l'auto-hébergement vous reste. Rien dans cette liste n'est négociable par le marketing ; si ça n'existe pas, la doc dit que ça n'existe pas.

Le raisonnement derrière

L'ennui bat la ruse: le langage du noyau n'a pas changé ses idiomes depuis des décennies, la base de données traite vos données comme un fichier, et les dépendances ne se renomment pas sous vos pieds. Un programme écrit il y a des années fonctionne encore, et un exploitant qui ne connaît pas le système peut lire le code de haut en bas à 2 h du matin.
La surface d'attaque est une décision de conception. Chaque fonctionnalité que quelqu'un propose fait un pari : la capacité vaut-elle la surface qu'elle ajoute ? La position du projet est que la plupart de ces paris perdent en production, donc le défaut le plus sûr est de dire non jusqu'à preuve du contraire, d'où pas de hooks, pas de registre de plugins, pas de place de marché.
Assisté par l'IA, auditable par des humains. La base de code est développée avec l'assistance de l'IA, et le projet considère la maîtrise de l'IA, non la maîtrise de Perl, comme la compétence d'entrée des contributeurs : précisément parce qu'un code ennuyeux et stable reste lisible par les personnes comme par les LLM, trente ans d'idiome cohérent à l'appui.

Les règles des contributeurs

Si vous travaillez sur l'interface d'administration, les notes d'implémentation sont explicites :

Pas de styles inline : utilisez les classes utilitaires fournies.
Pas d'icônes décoratives ; toute icône doit être associée à un libellé textuel visible.
La palette de couleurs est fermée ; de nouvelles couleurs rompent la cohérence du système ; utilisez les propriétés personnalisées CSS existantes.
Gardez l'imbrication peu profonde ; la nommage des classes suit des conventions BEM-ish.
Les boutons dans les en-têtes et les pieds de cartes vont dans les conteneurs d'actions prescrits.

Pour les templates de blocks, la spécification des blocks est la référence faisant autorité, écrite pour être suivie par un humain ou une IA travaillant depuis la seule spécification, chaque type de block consistant en un template de builder et un partial de formulaire d'admin en paire assortie. Les types de blocks doivent être enregistrés auprès du système avant usage.

Vous travaillez plutôt dans le système de thèmes publics ? La Template Reference a ses propres règles (variables à plat, partials préfixés _, directives interdites, exigence du password gate), et elles s'appliquent aux auteurs de thèmes plutôt qu'aux contributeurs de l'interface d'admin.

Ce qui est prévu (et énoncé comme non livré)

Un éditeur visuel drag-and-drop, sur la feuille de route, bloqué sur des décisions de structure de page ; n'existe pas aujourd'hui.
Génération de contenu par LLM liée à la bibliothèque de blocks : prévu, palier commercial.
Suivi de clics avec attribution de campagne : le module commercial prévu.
Multi-tenancy avec Postgres : sur la feuille de route, pas commencé ; le chemin de migration n'est pas encore défini.

Les modules Pro commerciaux sont conçus pour être licenciés localement (fichiers de licence signés, aucune validation externe) afin que la promesse air-gap survive à la monétisation, et le noyau reste sous licence MIT avec les fonctionnalités Pro vivant dans un espace de noms séparé.

Le résumé en une ligne

Chaque règle ci-dessus se ramène à la même discipline : réduire la surface, ne préférer rien qui ait besoin du réseau ou d'un plugin pour être sûr, garder la sortie bête, journaliser abondamment, documenter les compromis honnêtement, et tenir la ligne quand une fonctionnalité tentante vous demande de rompre la règle.