Référence de développement

Le modèle, en une ligne

commit → feature → develop → main + tag : grain, chantier, intégration, livraison, jalon figé. Quatre lignes de travail coexistent dans l'atelier :

• la branche de chantier (feat/<sujet>) — un sujet, une branche, ouverte depuis le tronc d'intégration ; supprimée après intégration, ses commits restant acquis ;
• le tronc d'intégration (develop) — où converge le travail de toutes les branches de chantier : l'état consolidé, mais pas encore livré. C'est une branche d'intégration, à ne pas confondre avec un simple environnement de démonstration ;
• la branche de production (main) — n'avance que par livraison (intégration du tronc) ou par correctif, et porte à chaque arrivée un jalon de version (tag SemVer) immuable ;
• la branche de correctif urgent (hotfix) — ouverte depuis le jalon de prod concerné, jamais depuis le tronc d'intégration, pour ne corriger que ce qui est réellement livré ; le correctif est ensuite propagé, obligatoirement, dans le tronc d'intégration (anti-régression).

Atelier & vitrine

Le dépôt de développement souverain — chez APCOM, Forgejo auto-hébergé — a vocation à être l'atelier : dans le modèle cible, il détient toute la vérité, branches de travail, commits intermédiaires, allers-retours, historique granulaire, développement et production. Le dépôt public — GitHub — est la vitrine : il ne reçoit que la production livrée — la branche de production et ses jalons de version — jamais le tronc d'intégration ni les branches de chantier. Les deux historiques divergent volontairement. La vitrine n'a qu'une utilité externe — offrir un historique de release lisible et rejoindre les habitudes des clients et partenaires, qui consultent GitHub ; l'historique de développement complet, lui, ne quitte pas l'atelier.

Cette barrière n'est pas qu'une commodité : elle est fondée par la Règle 24 du KERNEL — séparation entre l'IA et les dépôts de production hors infrastructure souveraine. Seul l'humain pousse vers le dépôt public, et il nomme toujours ce qu'il livre.

La même logique gouverne la donnée, pas seulement le code. Le CORPUS est l'atelier de fichiers : l'IA commerciale n'y lit que des contenus dont le traitement lui est légalement (droit suisse) et éthiquement admissible. Les données de production et le cloud d'entreprise traditionnel — chez APCOM, un second Nextcloud auto-hébergé — lui restent fermés. Atelier de code, atelier de fichiers : l'IA n'opère que dans les ateliers souverains ; la production et la vitrine publique ne sont jamais son terrain.

Les neuf bascules

Les neuf bascules numérotées sur le schéma — la légende, par cas.

Features et versions

Hotfix

Rollback (théorique)

Garde-fous

Le garde-fou qualité — le test live. Dans le modèle cible, chaque branche poussée est déployée sur un environnement de test dédié (test live), pour qu'une fonction soit vue fonctionner avant d'être intégrée ; aujourd'hui ce test se fait par environnement (démo, test) attaché à une branche, le déploiement par branche de chantier restant à généraliser. Le verrou cible — non encore acquis — lie ce test à la protection des branches : tant que le test est au rouge, l'intégration vers le tronc ou la production reste impossible.

Deux règles d'or prolongent directement les disciplines posées pour la mémoire — la consolidation comme acte de gouvernance, et la consolidation en lot (local d'abord, distant ensuite, sur décision explicite) :

• ne jamais pousser large vers la vitrine — on nomme toujours ce qu'on publie, la branche de production et le jalon livré, jamais une poussée globale ;
• ne jamais réécrire un jalon publié — un tag de version poussé est immuable, comme un historique partagé ne se réécrit pas ; une version mauvaise appelle un correctif incrémenté, pas une réécriture.

Cette ligne fixe le modèle, pas l'état de chaque projet : le tronc d'intégration, les jalons de version, le correctif depuis le tag, la propagation et le retour arrière sont la part prescriptive, en cours de généralisation — comme l'est le rattachement effectif de chaque logiciel à l'atelier souverain, certains lisant encore un miroir du dépôt public.

Traçabilité — deck · commit · timesheet

Chaque commit s'inscrit dans la routine projet (du besoin client au livrable validé), dont le point névralgique est la convention deck-commit-timesheet :

• Chaque carte Deck représente une demande contractuelle (un ticket).
• Chaque commit Git porte la (les) référence(s) Deck dans son message — préfixe [DECK-{id}]. Un commit peut référencer plusieurs cartes si un changement transverse résout plusieurs tickets.
• Chaque saisie timesheet mentionne le hash complet du commit auquel elle correspond.

Le commit est ainsi le pivot qui relie l'effort enregistré (timesheet) à la demande contractuelle (carte Deck). Le journal de projet vivant est la simple consolidation de ces trois sources — Deck, commits, timesheet — sans rédaction supplémentaire.

Routine projet complète et conventions : STACK_TECHNIQUE/ROUTINES/PROJET.md du KERNEL.

Discipline de branche & session

Toute session n'écrit jamais directement sur la branche principale : à l'ouverture elle crée sa branche de travail, à la clôture elle la pousse ou la consolide.

Typologie des sessions

Cycle d'une session

Quand plusieurs sessions travaillent réellement en même temps — plusieurs agents IA conduits en parallèle — chacune opère dans un worktree Git distinct : un répertoire de travail séparé, rattaché au même dépôt, sur sa propre branche. La branche par session isole les écritures ; le worktree isole les espaces de travail. Ensemble, ils rendent le travail parallèle sûr par construction. La consolidation vers la branche principale n'est jamais automatique : elle prend la forme d'une fusion Git (merge --no-ff) — commit de fusion, trace explicite, pas d'écrasement silencieux.

Routines de session dev

Distinctes des rituels de session KERNEL, les routines de développement — ouverture, permanence, clôture, cycle de vie projet — encadrent le travail des équipiers sur les logiciels, dans les SPOKES. Elles reposent sur la ligne Git unique décrite ci-dessus, de la branche de chantier au jalon de production.

Checklists exactes : STACK_TECHNIQUE/ROUTINES/ du KERNEL (ouverture, permanence, clôture) et les DEV_WORKFLOW.md par logiciel.

Renvois

• Manifeste — la thèse, le modèle, la doctrine de conduite : La mémoire situative.
• KERNEL (privé) — commandes Git exactes de chaque bascule et état réel par logiciel : GLOBAL/STRUCTURE/GIT.md, qui renvoie aux DEV_WORKFLOW.md.
• Règles permanentes citées : Règle 13 (commits par bloc logique), Règle 14 (trois ordres : écrire / commiter / pousser), Règle 24 (séparation IA / dépôts de production).