# Ce que la session de recette détenait et qui n'était écrit nulle part

Écrit le 23/08 à la demande de la **conversation chapeau**, qui a relevé que
trois éléments cités dans la consignation ne vivaient que dans la conversation.
Elle avait raison. Ce document les fixe, **avec leurs mesures**.

## 1. Les deux décisions à prendre AVANT d'écrire la page de lotissement

Enguerran veut une page consultable depuis son mobile : pour chaque issue, le
jalon GitHub actuel (inchangé), une **proposition** de lot, et deux boutons
**VALIDER / REFUSER**. Aucun jalon n'est modifié tant qu'il n'a pas validé.

⚠️ **Ces deux décisions changent la STRUCTURE de la page, pas sa décoration.**
Les trancher seul, c'est refaire l'erreur que cette session a passé deux jours
à corriger.

### Décision 1 — par où les clics reviennent

| option | ce qu'elle coûte |
|---|---|
| **la page mémorise, on la relit** | tu cliques du mobile quand tu veux, rien à recopier. Demande d'activer la persistance sur l'artefact. **Recommandée par la session sortante.** |
| la page fabrique un texte à coller | aucune dépendance technique, mais un geste manuel à chaque fois et le risque d'en oublier une partie |
| tout dans GitHub (label `proposition: …`) | cohérent avec « rien n'existe hors du dépôt », mais **355 issues à traiter dans l'interface GitHub sur mobile** |

### Décision 2 — que mettre pour les 310 issues non instruites

⚠️ **Le fond du problème** : proposer un lot pour les 355, c'est fabriquer 310
jugements que personne ne peut tenir. Ne proposer que pour les 45 examinées,
c'est laisser 87 % du registre vide.

| option | ce qu'elle coûte |
|---|---|
| colonne vide, « à instruire » | honnête, mais 87 % du registre sans proposition |
| **dérivation mécanique depuis le jalon GitHub existant**, marquée comme telle | traçable, non inventé, et la colonne distingue visuellement « instruite » de « dérivée ». ⚠️ **130 issues n'ont AUCUN jalon** : elles restent vides quoi qu'il arrive |
| lecture au cas par cas des 310 | le plus complet, mais le risque est de produire 310 jugements rapides au lieu de 45 solides |

**Avis de la session sortante** : les 45 instruites + la dérivation mécanique
pour celles qui ont un jalon, les deux distinguées à l'écran. Les 130 sans jalon
deviennent la file d'instruction — **c'est un chantier, pas une case à cocher**.

## 2. « Le lien front↔back n'existe mécaniquement nulle part » — la mesure

Affirmé d'abord sans preuve. **Mesuré le 23/08**, sur 143 issues du dépôt FRONT
et 200 issues échantillonnées sur les deux dépôts :

| forme du lien | nombre |
|---|---:|
| exprimé dans le **titre** (« volet FRONT de BACK#396 ») | **12** |
| exprimé dans le **corps** seulement | **60** |
| **aucun lien exprimé** | **71** |
| **sous-issues natives GitHub** (`sub_issues`) | **0 sur 200** |
| champ `parent` | **absent** |

Un seul label approche du sujet : **`train-couple`** — *« Ne part jamais seule :
PR empilée ou paire back/front à merger ensemble »*. Il est posé sur **7 issues
au total** (5 BACK, 2 FRONT), et ⚠️ **il ne dit pas AVEC QUOI** : il renvoie à un
commentaire, donc à de la prose.

**Conclusion, maintenant fondée** : le lien existe sous quatre formes, dont
**aucune n'est lisible par une machine**. Rien ne peut donc s'alarmer qu'un côté
avance sans l'autre — ce qui a produit FRONT#154 : issue fermée le 16/08 en même
temps que son volet BACK#396, correctif jamais poussé, défaut vivant sept jours.

⚠️ **Le préalable à toute automatisation est de choisir OÙ ce lien vit.** Les
sous-issues natives existent et ne sont pas utilisées : c'est la première piste
à instruire, pas à adopter d'office.

## 3. Pourquoi le plan de bascule est PARQUÉ

**Il ne l'est pas en entier.** La distinction est le point utile :

- **Le SERVEUR continue** — machine, dimensionnement, conversion MyISAM→InnoDB
  (#136), rattrapage de migrations (#137), reprise des accès OVH, réglages.
  **Rien de tout cela ne dépend du lotissement** : le choix de la machine ne
  change pas selon qu'une issue est en L5 ou après.
- **La SÉQUENCE est parquée** — « qu'est-ce qui doit être fait avant de
  basculer » n'est qu'une liste tirée du lotissement. ⚠️ **Tant que la liste
  bouge, la séquence est du sable.**

**Et la dépendance joue dans les deux sens** : si la conversion InnoDB révèle un
blocant — des lignes orphelines empêchant de créer les clés étrangères, signalé
sur #136 — **cela change le lotissement**, pas seulement la séquence.

⚠️ **Ce qu'il ne faut PAS faire** : demander à la session bascule de traiter le
lotissement. Deux sessions sur les mêmes 355 issues reproduiraient exactement
#575 contre #626 — deux conversations, deux issues contradictoires sur le même
fichier de déploiement, découvertes après coup.