Comment ça marche

Chinaski est un système en deux pièces avec une boucle simple : éditez tant que le CMS est privé, buildez à la demande, et servez ce qu'il a écrit. Cette page rassemble tout le cycle de vie en un seul endroit.

La boucle

1. Éditer: connectez-vous à l'administration et gérez tout : pages, billets, blocs, snippets, catégories, redirections, navigation, formulaires et médias. Tout vit dans un seul fichier de base de données SQLite.
2. Builder: un processus builder séparé lit cette base de données, rend vos gabarits et écrit le site achevé sous forme de fichiers statiques sur disque. Le build n'arrive que quand vous ou un webhook le dites : c'est une opération explicite avec un vrai journal, pas un effet de bord en arrière-plan.
3. Servir: votre serveur web distribue les fichiers construits directement depuis le disque. Les visiteurs ne touchent jamais l'application CMS ni la base de données.
4. Répéter: changez le contenu, cliquez sur Build (ou laissez un webhook ou l'API le déclencher), et la prochaine copie statique se met en place.

Pourquoi cette forme

• L'administration est privée. En production, le CMS ne se lie qu'à une adresse de loopback ; les visiteurs d'Internet atteignent l'hôte statique, jamais l'application de rédaction ni la base de données.
• Le site public n'a aucune application à attaquer. Ce qui est livré, c'est un simple répertoire de HTML et d'assets. Il n'y a aucun rendu par requête et aucun JavaScript à l'exécution : rien à injecter, rien à fuiter, et un traqueur n'a aucun mécanisme pour exister.
• La défaillance d'un processus ne peut pas toucher l'autre. Un build échoué ne fait jamais tomber le site : la sortie est écrite dans un répertoire de staging et renommée en place seulement quand elle est complète ; sinon le build précédent continue de servir.

Ce que les visiteurs obtiennent réellement

• Des pages et billets comme fichiers index.html à leurs propres chemins, par langue, sous la sous-arborescence de chaque langue dans output/
• Des assets partagés synchronisés dans chaque arborescence de langue (médias, polices, favicons)
• Des fichiers générés par langue : sitemap, index de recherche, flux RSS, robots.txt, page d'erreur, et extras PWA quand activés
• Des pages de redirection et une configuration de redirection serveur générée, pour que les URL retirées continuent de fonctionner

Les deux exceptions délibérées au « tout statique »

• Les formulaires publics (blocs contact/newsletter) se soumettent vers /forms/<slug>, que la configuration serveur par défaut mandate vers le CMS pour que les soumissions puissent être stockées.
• Les pages protégées par mot de passe embarquent leur contenu dans le HTML et se déverrouillent dans le navigateur du visiteur, une vérification côté client, clairement un compromis pour l'intimité au niveau de la page sur un site statique.

Sous le capot

• Une instance = un fichier SQLite. Pas de serveur de base de données, pas d'identifiants, pas de réseau entre l'application et le stockage. Plusieurs instances (par client, par étape) portent chacune leur propre fichier.
• La mise à niveau consiste à lancer le service : chaque démarrage exécute automatiquement des migrations de schéma idempotentes, si bien que les instances réparent leur schéma en chemin.
• L'intégrité est prouvable : chaque build signe un manifeste conservé séparément de la sortie, si bien que le site en ligne peut être attesté contre le build qui l'a produit.

Se lancer dès le premier jour

Une installation neuve vous confie un compte administrateur de remplacement : le navigateur est redirigé vers /setup à la première visite, où vous définissez le vrai mot de passe administrateur (au moins 12 caractères avec majuscules, minuscules et un chiffre), choisissez les langues de l'interface et initiales, et réglez l'URL du site. Après cela, la page de configuration disparaît, et la boucle ci-dessus est à vous de piloter.